Kelola insiden dari deteksi hingga pemulihan

Nyatakan insiden berdasarkan dampak

Insiden adalah kejadian yang mengganggu, menurunkan, atau mengancam layanan sehingga memerlukan respons terkoordinasi. Organisasi Anda menentukan tingkat keparahan dan aturan eskalasi. Gunakan dampak pada pengguna, data yang terdampak, durasi, dan cakupan untuk menerapkannya.

Jangan menunggu penjelasan akar penyebab yang lengkap sebelum meminta bantuan. Pernyataan jelas tentang dampak yang diamati cukup untuk memulai koordinasi. Bedakan dugaan keamanan dari kesimpulan yang telah dikonfirmasi.

Siapkan jalur respons sebelum rilis. Pastikan detail kontak, prosedur akses, runbook, dan saluran komunikasi tetap tersedia ketika layanan utama tidak tersedia. Latih jalur tersebut dengan insiden fiktif.

Tetapkan tanggung jawab sebelum membuat perubahan yang saling bertentangan

Koordinasi insiden menetapkan prioritas dan mengelola keputusan. Petugas teknis menyelidiki dan memitigasi. Komunikasi menjaga orang yang terdampak tetap mendapat informasi. Google SRE menjelaskan tanggung jawab ini sebagai peran terpisah. Tim kecil dapat menggabungkan peran, tetapi tetap harus mencakup seluruh pekerjaannya. Respons insiden.

Gunakan satu kronologi bersama. Catat waktu, pengamatan, tindakan, pelaku, dan hasil. Bedakan fakta dari hipotesis. Gunakan zona waktu yang sama dan tandai timestamp yang tidak dapat dipercaya.

Pelajari insiden fiktif

Semua waktu di bawah menggunakan UTC. Organisasi menunjuk koordinator insiden ketika kegagalan ekspor memengaruhi beberapa pelanggan.

Pembaruan pertama yang berguna menyatakan fungsi yang terdampak, cakupan yang diketahui, mitigasi, dan waktu pembaruan berikutnya. Pembaruan tersebut tidak menjanjikan waktu perbaikan tanpa bukti. Hindari menyertakan data pelanggan dalam pembaruan bersama.

Pada 09:10, kondisi insiden berubah. Memulihkan keberhasilan ekspor tidak lagi cukup. Tim perlu menilai kemungkinan pengungkapan data, mengontrol akses, mempertahankan bukti, dan melibatkan penanggung jawab keputusan yang sesuai.

Lakukan mitigasi tanpa kehilangan kendali

Gunakan runbook yang telah diuji jika sesuai. Periksa prasyarat sebelum rollback, failover, atau perubahan kredensial. Versi aplikasi sebelumnya mungkin tidak memahami skema database saat ini. Failover regional dapat memindahkan data rusak yang sama.

Izinkan asisten AI menyusun bukti yang informasi sensitifnya telah dihapus atau membandingkan hipotesis dalam batas yang disetujui. Petugas respons harus memverifikasi kesimpulannya. Log dan tiket merupakan input yang tidak tepercaya, bukan kewenangan untuk menjalankan isinya.

Akses darurat harus memiliki tujuan yang diizinkan, durasi terbatas, dan catatan audit. Keadaan mendesak tidak membuat perintah yang disarankan agen menjadi benar.

Tutup pemulihan dan tindak lanjut secara terpisah

Verifikasi alur kerja pengguna, integritas data, batas akses, dan kemutakhiran pemantauan sebelum menyatakan layanan pulih. Catat pembatasan yang tersisa. Biarkan penyelidikan keamanan tetap terbuka jika pertanyaannya belum terjawab.

Setelah itu, periksa kondisi yang memungkinkan insiden terjadi. Tetapkan pekerjaan tindak lanjut konkret dengan penanggung jawab dan kriteria verifikasi. Peninjauan tanpa menyalahkan orang bertujuan mendapatkan penjelasan yang akurat dan perubahan yang berguna. Pendekatan tersebut tidak menghapus tanggung jawab untuk menyelesaikan perubahan. Praktik postmortem.

Lanjutkan ke operasi keamanan dan menutup siklus umpan balik.