Cache klasifikasi VPN, jaga usia tetap terlihat
Sebuah observasi, kesegarannya, dan respons situs Anda menua dengan laju berbeda. Jika dijaga terpisah, klasifikasi yang di-cache tetap jujur tentang apa yang diketahuinya.
Klasifikasi yang di-cache menghemat satu pencarian dan membekukan pendapat kemarin ke dalam keputusan hari ini. Perbandingan sebenarnya bukan cache versus tanpa cache: melainkan observasi, kesegarannya, dan respons yang dipilih situs Anda. Hilangkan batas antara ketiganya dan sebuah optimasi mulai membuat kebijakan sendiri. Perbaikannya adalah pembukuan, bukan feed yang lebih baik.
Tiga catatan dengan tiga jam berbeda
Observasi adalah bidang yang Anda terima, feed asalnya, dan versi kumpulan data di baliknya. Kesegaran adalah sifat entri cache: kapan pencarian dijalankan, kapan entri berhenti dipercaya, dan apakah penyegaran terakhir mengembalikan sesuatu. Respons adalah apa yang situs Anda lakukan tentang itu untuk permintaan ini, akun ini, atau tindakan ini. Ketiganya dihasilkan pemilik berbeda dan membusuk dengan laju berbeda, karena itu satu baris bernama blocked menghancurkan pembedaan itu.
| Record | Who owns it | How long it should live | Damage when it is folded into another row |
|---|---|---|---|
| The observation | the feed's operator | until a newer dataset version replaces it | a stale lookup becomes indistinguishable from a fresh one |
| Its freshness | the application | one request's tolerance for age | a failed refresh hides behind a cache hit |
| The response | whoever owns the site policy | until that policy is reviewed | a feed outage turns into an indefinite block |
Dua jam perlu perhatian khusus. Saat pencarian Anda berjalan bukanlah saat penyedia menerbitkan kumpulan datanya, dan operator yang membaca baris itu nanti perlu tahu dari mana tiap nilai berasal di antara keduanya. Tetapkan kedaluwarsa dan penyegaran menurut model pembaruan feed yang terdokumentasi dan menurut biaya jika salah, jangan pernah menurut angka pinjaman dari situs lain.
Pertahankan bidangnya, bukan putusannya
Dokumentasi MaxMind tentang IP anonim adalah satu contoh konkret feed yang memisahkan VPN anonim, penyedia hosting, proxy publik, dan exit Tor ke bidang-bidang berbeda. Dokumen itu juga mencatat bahwa subnet VPN yang tidak terdaftar bisa muncul di bawah tanda hosting. Meratakan itu menjadi satu boolean membuang satu-satunya bagian yang bisa diaudit operator nanti.
Tidak ada arah inferensi yang aman. Label hosting tidak membuktikan bahwa terowongan dipakai, dan tidak adanya tanda VPN tidak membuktikan bahwa tidak ada apa pun di antara klien dan layanan Anda. Keduanya klaim berbeda, dan satu boolean tidak bisa menyatakan salah satunya.
Kaitkan entri ke alamat yang Anda verifikasi
Di belakang proxy terbalik, aplikasi harus memakai penanganan alamat klien yang disetujui penerapan. Header penerusan yang disediakan pemanggil tidak boleh pernah bisa memilih reputasi cache orang lain.
Kegagalan itu sekaligus bug kebenaran dan bug keamanan, karena penyerang yang mengendalikan header bisa mewarisi entri tepercaya atau memakukan korban ke entri buruk. Turunkan kunci dari koneksi yang diakhiri infrastruktur Anda sendiri, dan catat penurunan mana yang dipakai. Saat ada beberapa proxy di depan, dokumentasikan rantainya alih-alih memercayai header pertama yang tampak masuk akal. Jika rantai ambigu, catat kunci turunan dan header yang Anda tolak, karena yang kedua itulah yang akan ditanyakan tinjauan insiden.
Tidak ada bukti bukan hasil yang bersih
Batas waktu, respons cacat, dan basis data tak tersedia masing-masing berarti sesuatu yang berbeda dari pencarian berhasil yang tidak cocok dengan apa pun. Sajikan sebagai hasil terpisah, dan putuskan lebih dahulu apa yang dilakukan tindakan terlindungi saat tidak ada bukti sama sekali. Halaman hanya-baca dan tindakan akun yang sudah masuk bisa secara wajar mengikuti aturan berbeda di sana.
Mempertahankan autentikasi normal, atau meminta verifikasi yang didukung, biasanya jawaban yang lebih baik daripada memperlakukan gangguan sebagai izin menyeluruh atau larangan seluruh situs. Batasi berapa lama pencarian boleh berjalan dan hentikan badai penyegaran dengan mekanisme apa pun yang didukung integrasi. Saat nilai basi dipakai selama gangguan, tandai sebagai basi di titik keputusan, dan buat kegagalan terakhir penyegaran terlihat agar gangguan berkepanjangan tidak lolos sebagai entri sehat. Apa pun pilihannya, tuliskan di tempat kebijakan ditegakkan, bukan di komentar di samping pencarian.
Penyimpanan termasuk keputusan yang sama: pertahankan bidang yang dibutuhkan fungsi ini dan jejak tinjauan di baliknya, tidak lebih. Cache IP tidak harus menjadi riwayat penjelajahan.
Terima empat kasus, termasuk koreksi
Uji hasil segar, hasil kedaluwarsa, pencarian gagal, dan klasifikasi yang kemudian dikoreksi. Masing-masing melatih cabang berbeda, dan hanya yang terakhir menunjukkan apakah pembatasan yang keliru bisa dibatalkan.
Lalu pastikan pengguna biasa punya jalur untuk meminta tinjauan setelah blokir yang salah, karena feed kadang keliru dan antrean adalah bagian dari desain. Tulis keempat kasus itu ke runbook dengan nama pemilik kebijakan di sampingnya. Desain itu pantas mendapat tempatnya ketika ia menghapus pencarian berlebih sambil menjaga ketidakpastian tetap utuh dan keputusan tetap terlihat dimiliki oleh seseorang.