Przejście na zasady egzekwowania prawa to ważna decyzja dotycząca kontroli domeny, a nie koniec oszustw związanych z pocztą elektroniczną. Dokładnie zgłaszaj osiągniętą granicę: domena żąda silniejszego traktowania wiadomości, które zawodzą DMARC. Następnie wyjaśnij zagrożenia, które mogą nadal uwierzytelniać lub wykraczać poza granicę tożsamości, wraz z pracą operacyjną niezbędną do prawidłowego funkcjonowania poczty.
Podaj ochronę bez gwarancji
DMARC łączy dostosowane uwierzytelnianie domeny z opublikowanymi preferencjami obsługi i ramami raportowania. Rzeczywiste postępowanie odbiorcy może wiązać się z polityką lokalną. Nie obiecuj, że każda błędna wiadomość zostanie wszędzie odrzucona lub że pozytywne zatwierdzenie oznacza, że wiadomość jest bezpieczna. RFC 9989.
Wiadomości w domenie podobnej, podszywanie się pod wyświetlaną nazwę i napadnięci legalni nadawcy mogą pozostać niebezpieczni po egzekwowaniu zasad. Uwierzytelniony dostawca może w dalszym ciągu wysłać nieautoryzowane żądanie płatności. SPF zezwolenie, które jest szersze niż zamierzone, może również pozostawić dostępną dostosowaną trasę przejazdu. Są to powody do utrzymania uzupełniających kontroli, a nie powody do porzucenia uwierzytelniania domeny.
Sprawdź legalne trasy przed zmianą
Utrzymuj matrycę nadawcy z usługą, właścicielem odpowiedzialnym, domeną autora, domenami uwierzytelnionymi, wyrównanie dowody, krytyczni odbiorcy i ostatnia testowana data. Uwzględnij systemy o małej objętości, takie jak skanery i alerty. Cicha trasa nie musi być niewykorzystana. Rozwiąż problem z nieznanymi nadawcami, zanim potraktujesz inwentarz jako kompletny.
Udokumentuj proponowaną różnicę w zasadach i osobę, która ją zatwierdza. Zmiana od p=none Do p=reject to przykład, a nie wartość, którą można publikować w ciemno. Przejrzyj odpowiednie domeny i zależności, zaplanuj okno obserwacji i zdefiniuj wyzwalacze odzyskiwania w przypadku ważnych, uzasadnionych awarii. Użyj wygenerowanych wartości specyficznych dla usługi, a nie tożsamości demonstracyjnych tego artykułu.
Sprawdź pisemną księgę gotowości
W przypadku proponowanej poniżej zmiany p=none na p=reject załóż pojedynczy ważny widoczny nadawcy na wiadomość i określony dowód uwierzytelnienia odbiorcy. Nie jest przeprowadzana żadna rzeczywista zmiana ani test odbiornika.
- Rozliczenia: proponowany właściciel Operacje rozliczeniowe; Od invoice@billing.brand.test ; Przepustka SPF dla bounce@billing.brand.test ; DKIM zalicz z d=billing.brand.test. Obydwa identyfikatory są dokładnie dopasowane, więc hipotetyczna wiadomość zostaje przekazana. Brakuje jeszcze rzeczywistych testów dla odbiorców krytycznych i zatwierdzenia zmian.
- Wsparcie: proponowany właściciel Operacje wsparcia; Od agent@support.brand.test ; Przepustka SPF dla bounce@support.brand.test ; Przepustka DKIM z d=support.brand.test. Obydwa są dokładnie dopasowane, więc hipotetyczny komunikat przechodzi. Brakuje jeszcze rzeczywistych testów dla odbiorców krytycznych i zatwierdzenia zmian.
- Starszy skaner: właściciel niepotwierdzony; Od, SPF , DKIM i zasięg odbiorcy nieznane. Nie można wywnioskować żadnego werdyktu dotyczącego wiadomości. Wyznacz odpowiedzialnego właściciela i uzyskaj dowód trasy przed zadeklarowaniem gotowości.
Ogólna gotowość do wdrożenia nie została ustalona. Nawet dwa wymagane przebiegi nie są przestrzegane jako dowód produkcji. Właściciel proponowanej zmiany powinien wstrzymać ją do czasu rozwiązania niewiadomych, zatwierdzeń, czynników wyzwalających przywracanie i kontroli tras. Dla tej księgi nie wykonano żadnego kodu, zapytania DNS ani weryfikacji podpisu.
RFC9989 sekcja 7.4 wymaga prawidłowych podpisów DKIM podczas publikowania p=reject i odradza odrzucanie w przypadku domen, których użytkownicy mogą wysyłać posty na listy mailingowe. Następnie domeny te powinny najpierw oceniać dane zagregowane przy p=none przez co najmniej miesiąc p=quarantine przez równie długi okres. Wybierz politykę, mając na uwadze ograniczenia interoperacyjności; czysty przykład bezpośredniego wysyłania nie eliminuje ryzyka związanego z pocztą pośrednią.
Sprawdź zachowanie po zatwierdzonym wdrożeniu
W przypadku prawdziwej zmiany przechwyć opublikowaną politykę, czas, zatwierdzone różnice i testy dla każdej krytycznej trasy. Porównaj wyniki zaufanego odbiorcy z rzeczywistą obsługą i przejrzyj dostępne raporty zbiorcze wraz z limitami zasięgu. Brakujące raporty nie są dowodem na to, że żadna poczta nie została wysłana ani że nie wystąpiła żadna awaria. RFC 9990. Sprawdzaj uzasadnione wyjątki według trasy, zamiast ogólnie osłabiać ochronę bez właściciela.
Wyjaśnij pozostałe ryzyko oszustwa w taki sam sposób, jak przed egzekwowaniem prawa. Zmiany płatności nadal wymagają niezależnej weryfikacji; naruszenie bezpieczeństwa konta nadal wymaga reakcji bezpieczeństwa konta; sobowtóry wymagają wykrywania i raportowania o odpowiednim zakresie. Wytyczne FBI dotyczące weryfikacji płatności pozostają aktualne nawet po uwierzytelnieniu domeny. Wytyczne FBI.
Oświadczenie o solidnym zakończeniu zawiera nazwę zaobserwowanych zasad, przetestowanych tras, nierozwiązanych wyjątków i pozostałych kontroli. Nie należy tego mówić phishing jest rozwiązany. Utrzymuj własność i okresowe przeglądy aktywne w miarę zmiany usług, kluczy i procesów biznesowych.