A DKIM kunci pribadi adalah wewenang untuk membuat tanda tangan yang dapat memverifikasi terhadap catatan publik yang cocok. Melindungi data DNS saja tidak melindungi otoritas tersebut. Inventarisasi sistem penandatanganan, akun yang dapat menggunakannya, dan setiap salinan operasional rahasia sebelum memutuskan kunci dikendalikan.
Identifikasi hak asuh daripada mengasumsikannya
Mulailah dengan penyedia sebenarnya atau perangkat lunak penandatanganan. Layanan terkelola dapat menghasilkan dan menyimpan kunci; penanda tangan yang dioperasikan sendiri dapat membaca file, penyimpanan rahasia, atau antarmuka yang didukung perangkat keras. Model-model ini memiliki kontrol akses dan pemulihan yang berbeda. Jangan menjanjikan perlindungan perangkat keras, non-ekspor, atau rotasi yang dikelola pelanggan kecuali produk yang dipilih mendokumentasikan dan menerapkannya.
RFC 6376 §8.3 menjelaskan konsekuensi dari kompromi kunci pribadi: penyusup dapat membuat email yang ditandatangani oleh domain yang menerbitkan kunci publik terkait. Hal ini juga menjelaskan nilai server email keluar terkontrol yang mengautentikasi pengirim dan menerapkan kontrol pengiriman. Langkah-langkah penyimpanan dan peninjauan khusus di bawah ini adalah rekomendasi operasional, bukan persyaratan protokol DKIM universal.
Buat peta hak asuh yang memperlihatkan salinan tersembunyi
Untuk masing-masing pemilih, catat domain penandatanganan, pemilik layanan, penjaga kunci, node penandatanganan aktif, jalur penerapan, dan mekanisme pemulihan yang didukung. Lacak referensi atau pengidentifikasi rahasia, bukan rahasia itu sendiri. Tinjau repositori konfigurasi, langkah-langkah pembuatan kontainer, file penerapan sementara, cadangan, dan paket diagnostik untuk salinan yang tidak diinginkan melalui proses penanganan rahasia yang disetujui organisasi.
Contoh sintetiknya adalah kluster penagihan dengan dua node penandatanganan dan tugas penerapan. Kunci DNS bersifat publik dan diharapkan. Kunci privat dimaksudkan untuk menjangkau dua node saja, namun pipeline build lama juga menyematkannya dalam gambar yang dapat diakses oleh project yang tidak terkait. Mengamankan izin file simpul saat ini tidak akan menghapus paparan lama tersebut. Selidiki jalur distribusi dan perlakukan rahasia yang berpotensi terbongkar sesuai dengan proses kejadian.
Jangan pernah menempelkan kunci pribadi ke kolom DNS publik, tiket, obrolan, atau pemeriksa DKIM publik. Ketika dukungan memerlukan bukti, berikan informasi kepada pemilih publik dan hasil diagnostik yang dikontrol dengan tepat. Pesan mentah mungkin juga berisi konten sensitif; meminimalkan apa yang dibagikan dan menggunakan saluran yang disetujui.
Kurangi siapa yang bisa menandatangani dan siapa yang bisa mengambil rahasia
Gunakan kontrol dengan hak paling rendah yang didukung platform untuk administrasi dan akses runtime. Akun yang dapat meminta tanda tangan mungkin kuat meskipun tidak dapat mengekspor kuncinya. Tinjau siapa yang dapat mengubah identitas pengiriman yang diizinkan, mengirimkan email, merotasi kunci, menerapkan konfigurasi penanda tangan, dan mengambil cadangan.
Pisahkan layanan dengan pemilik atau tingkat kepercayaan berbeda yang arsitekturnya mendukung kunci dan penyeleksi independen. Menyalin satu kunci ke dalam setiap aplikasi membuat insiden lebih sulit untuk dicakup dan penghentian menjadi lebih mengganggu. Ketersediaan tinggi mungkin secara sah memerlukan identitas penandatanganan bersama, namun hal itu harus merupakan desain eksplisit dengan distribusi terkontrol dan bukan konsekuensi yang tidak disengaja dari file konfigurasi yang disalin.
Uji pemulihan tanpa menyebarkan rahasianya
Tanyakan apakah pemadaman listrik dapat dipulihkan dengan memulihkan kunci yang dilindungi, membuat kunci pengganti, atau menggunakan jalur pemulihan terkelola penyedia. Uji prosedur yang didukung dalam lingkungan yang terkendali. Catat waktu pemulihan, ketergantungan DNS , dan apakah email dalam antrean masih menggunakan pemilih lama. Jangan membuat salinan cadangan tambahan yang tidak dilindungi hanya untuk mempermudah latihan.
Tinjau log dan akses peristiwa yang tersedia dari platform penandatanganan dan sistem manajemen rahasia. Pertanyaan yang berguna adalah apakah perubahan atau penggunaan yang tidak sah dapat dideteksi dan diselidiki, bukan apakah ada dasbor tertentu. Dokumentasikan kesenjangan pencatatan dibandingkan membuat jejak audit.
Selesaikan dengan catatan siklus hidup yang dapat ditindaklanjuti
Simpan peta hak asuh di samping prosedur rotasi dan kompromi. Hapus akses usang ketika staf atau vendor keluar, dan periksa kembali distribusi setelah perubahan infrastruktur. Jika ada dugaan paparan, koordinasikan pengendalian akses, penggantian bersih, dan verifikasi konsekuensi dari penghentian kunci lama. File saat ini yang dilindungi hanyalah satu bagian dari siklus proses penandatanganan yang terkontrol.
Gunakan lembar kerja keputusan hak asuh
Untuk setiap identitas penandatanganan, catat kolom non-rahasia berikut:
- Penggunaan: akun layanan mana yang dapat mengirimkan atau meminta tanda tangan, dan identitas mana yang dapat mereka gunakan.
- Pengambilan: peran mana yang dapat mengekspor atau memulihkan kunci privat, dan di mana salinan yang disetujui berada.
- Perubahan: siapa yang dapat mengubah konfigurasi penandatangan, identitas yang diizinkan, atau artefak penerapan.
- Pemulihan: apakah jalur yang didukung memulihkan kunci yang dilindungi atau menghasilkan pengganti, dengan DNS dan dependensi email antrean.
- Bukti: log akses/penandatanganan yang tersedia, kesenjangan cakupan, dan pemilik yang bertanggung jawab untuk meninjaunya.
Jika artefak build lama berisi kunci yang terekspos, mengamankan node aktif saja tidak cukup: cakupan eksposur lama dan putuskan penggantian bersih berdasarkan prosedur insiden. Lembar kerja ini merupakan panduan keamanan editorial, bukan klaim bahwa platform tertentu menyediakan kontrol ini.
Bacaan terkait
Cabut kunci DKIM dan bedakan pencabutan dari data DNS yang hilang · Panjang kunci DKIM dan algoritma: periksa dukungan receiver saat ini.