Domain yang sama dapat muncul di banyak observasi teknis, namun itu tidak berarti setiap observasi termasuk dalam alur kerja pelanggan yang sama. Rutekan peringatan menggunakan identitas penyewa terverifikasi, kepemilikan layanan, dan dampak bisnis. Pertahankan temuan yang ambigu dalam triase internal daripada menebak-nebak penerima pelanggan.
Bangun register perutean yang otoritatif
Untuk setiap layanan terkelola, pertahankan penyewa, domain, tujuan bisnis, pemilik aplikasi, tim operasional, tujuan yang disetujui, jam cakupan, dan kontak cadangan. Catat siapa yang menyetujui pemetaan dan kapan terakhir kali diverifikasi. Akhiran domain atau IP pengirim saja tidak dapat menetapkan pelanggan berhak menerima insiden.
Ikat pemrosesan peristiwa ke konteks pelanggan yang diautentikasi sebelum membaca domain peristiwa. Bidang masuk tidak boleh menggantikan identitas penyewa. Cocokkan domain dan layanan dalam batas tersebut. Pemetaan yang tidak diketahui atau bertentangan harus dimasukkan ke dalam antrean internal terbatas dengan penyelesai yang bertanggung jawab, bukan saluran pelanggan global.
Terjemahkan observasi menjadi dampak
RFC 9989 mendefinisikan penyelarasan Dan DMARC pengolahan; RFC 9990 menyediakan pengamatan laporan agregat. Keduanya tidak memberi tahu Anda apakah kegagalan memengaruhi penggajian, faktur, atau kampanye yang tidak aktif. Gabungkan temuan tersebut ke daftar layanan sebelum menetapkan urgensinya. Pertahankan kepercayaan diri dan laporkan liputan bersamaan dengan penilaian dampak.
Penghitungan dalam jumlah besar dari sumber yang tidak diketahui mungkin memerlukan penyelidikan tanpa membuktikan penghentian bisnis. Sejumlah kecil kegagalan dari layanan penting yang diketahui mungkin memerlukan perhatian yang lebih cepat. Hindari menyamakan p=reject dengan cakupan kendali penuh atau memperlakukan laporan yang hilang sebagai bukti pemulihan. Gunakan konsekuensi layanan dan kualitas bukti secara bersamaan.
Terapkan keputusan perutean yang dipesan
Pertama verifikasi cakupan penyewa. Selanjutnya selesaikan kepemilikan domain dan layanan. Kemudian menilai dampak bisnis, cakupan dan kepercayaan diri. Terakhir pilih tim resmi dan rute notifikasi. Simpan cadangan untuk kehilangan kepemilikan, peristiwa penting di luar jam kerja, dan pengiriman yang gagal. Setiap fallback memerlukan pemilik dan batasan pembagian data yang eksplisit.
Buat versi aturan yang ditetapkan dan pertahankan masukan keputusan pada setiap peringatan. Hal ini memungkinkan untuk menjelaskan mengapa kejadian kemarin mencapai operasional keuangan sedangkan kejadian hari ini masuk ke triase. Jangan diam-diam menulis ulang keputusan perutean historis setelah kepemilikan berubah. Evaluasi kembali insiden terbuka dengan sengaja dan pertahankan riwayat penugasan sebelumnya.
Selesaikan konflik kepemilikan domain yang sama
Misalkan peristiwa terverifikasi untuk penyewa A memberi nama domain yang juga ada dalam daftar penagihan penyewa B, namun penyewa A tidak memiliki pemetaan layanan yang disetujui untuk domain tersebut. Jangan meminjam kontak keuangan penyewa B atau mengirimkan bukti ke saluran pelanggannya. Simpan item dalam triase internal terbatas dengan pemilik yang dapat menyelesaikan otoritas yang hilang. String domain yang cocok adalah petunjuk pencarian, bukan hibah lintas pelanggan.
Dalam kasus hipotetis lainnya, dua layanan resmi berbagi domain: penggajian memerlukan peninjauan segera, sementara kampanye yang tidak aktif memiliki pertanyaan atribusi. Identitas layanan dan konsekuensi bisnis membedakan rute; pencocokan khusus domain tidak dapat mengambil keputusan tersebut. Uji kepemilikan yang sudah usang, kontak yang dicabut, peristiwa duplikat, dan pemetaan perubahan secara bersamaan di sistem sebenarnya. Tidak ada mesin perutean, pemberitahuan eksternal, atau uji isolasi yang dijalankan di sini.
Tinjau hasil dan kesenjangan kepemilikan
Ukur waktu ke pemilik yang bertanggung jawab, usia pemetaan yang belum terselesaikan, peringatan penting tanpa pengakuan, dan koreksi perutean. Nyatakan populasi yang tercakup dan periode pengamatan, bukan hanya memberikan persentase kepatuhan tunggal. Tiket tertutup atau peringatan yang diakui bukan merupakan bukti bahwa aliran email yang mendasari telah pulih.
Tinjau pendaftaran ketika pelanggan, domain, aplikasi, kontak, atau pengaturan cakupan berubah. Jaga agar pernyataan kontrol tetap sempit: perutean berfungsi untuk input yang diuji dalam konfigurasi yang direkam. Klaim kepatuhan, pengiriman, dan kemampuan produk yang lebih luas memerlukan bukti tambahan.
Kaitkan keputusan dengan hasil akhirnya
Simpan temuan, konteks penyewa tepercaya, kecocokan layanan, referensi bukti, revisi aturan, dan pemilik yang dipilih. Ketika remediasi diusulkan, kaitkan dengan keputusan tersebut dan catat verifikasi resmi yang mendukung penutupan. Pertanyaan atribusi pemasaran yang belum terselesaikan dapat tetap terbuka sementara perbaikan penggajian yang diverifikasi secara terpisah ditutup; satu hasil tidak boleh menutup hasil lainnya secara diam-diam. Ini adalah catatan yang direkomendasikan dan status hipotetis, bukan tanda terima remediasi atau tes ulang langsung yang diberikan.
Panduan multi-penyewa OWASP mendukung pengambilan konteks penyewa dari identitas tepercaya, memvalidasi akses sumber daya, dan menjaga cakupan pekerjaan asinkron. Register perutean menambah tanggung jawab bisnis; itu tidak menggantikan kontrol akses tersebut.