Pod RFC 9989 §4.7, a DMARC polityka p=none nie wyraża preferencji właściciela domeny w zakresie obsługi błędów DMARC . Konfigurowanie i przeglądanie raportów stwarza możliwość dowiedzenia się, które usługi korzystają z domeny, gdzie prawidłowe wiadomości zawodzą i na jaki wpływ może mieć zmiana zasad.
Monitorowanie staje się przydatne w wyniku dochodzenia. Raporty muszą dotrzeć do systemu gromadzenia danych, źródła potrzebują właścicieli, a nierozwiązane awarie wymagają decyzji. Upływający czas lub jeden procent wysokich przejść nie pozwala stwierdzić, czy każda ważna usługa została uwzględniona.
Spraw, aby zbieranie raportów było obserwowalne
W przypadku domeny rozpoczynającej monitorowane wdrożenie, przykładowe zasady są następujące:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comPrzykład zakłada zamierzony efekt _dmarc publikacja i działający adres kolekcji w tej samej domenie. Jeśli domena ma już silniejszą zatwierdzoną politykę, nie osłabiaj jej tylko dla przykładu. Używać przebieg procesu nagrywania aby zweryfikować rzeczywistą konfigurację.
Następny RFC 9990 §4 za pozwoleniem zewnętrznym i RFC 9989 §5.3.8 w przypadku raportowania przez odbiorcę sprawdź miejsce docelowe raportowania, wszelkie wymagane uprawnienia miejsca docelowego zewnętrznego, dostarczanie poczty i analizowanie. Zachowaj tożsamość osoby zgłaszającej, okres i odpowiednią historię konfiguracji. Otrzymywanie raportów od jednego dostawcy pokazuje ścieżkę roboczą dla tej obserwacji; nie świadczy to o powszechnym zasięgu.
Klasyfikuj usługi i zachowaj niepewność
Dla każdego znaczącego wzorca źródłowego sprawdź aplikację, konto lub trasę specyficzne dla klienta, widoczne z domeny, tożsamość koperty, tożsamość podpisu i właściciela.
Użyj przejrzystych kategorii roboczych:
- Kategoria: Zatwierdzona usługa z oczekiwaną wyrównaną ścieżką; Następna akcja: Zachowaj własność i monitoruj zmiany
- Kategoria: Zatwierdzona usługa nie została uwierzytelniona lub wyrównanie; Następna akcja: Popraw i przetestuj obsługiwaną konfigurację
- Kategoria: Legalna trasa pośrednia; Następna akcja: Przeanalizuj przekazywanie, modyfikacje i obsługę odbiorcy
- Kategoria: Nieznane źródło; Następne działanie: Zachowaj niepewność i zbadaj
- Kategoria: Potwierdzone nieuprawnione użycie; Następne działanie: Zapisz dowody potwierdzające i odpowiedź
Nazwa dostawcy usług w chmurze, ASN lub kraj nie wystarczą, aby zatwierdzić nadawcę. Podobnie nieudany wiersz nie wystarczy, aby uznać każdą powiązaną wiadomość za złośliwą.
Sprawdzony przykład: ciche okno pomija listę płac
Rozważmy przykładową organizację, która przegląda dziesięciodniową pocztę pracowniczą i marketingową. Raporty wyglądają zdrowo. W tym okresie nie została wysłana miesięczna usługa kadrowo-płacowa, a jej konfiguracja podpisywania nie była testowana.
Prawidłowy wniosek jest taki, że obserwowane strumienie wyglądały zdrowo przez te dziesięć dni. Nie jest tak, że cała domena jest gotowa na bardziej restrykcyjną politykę.
Zespół może bezpośrednio zbadać i przetestować ścieżkę płacową, zidentyfikować inne usługi okresowe i rozszerzyć jej dowody. Okna obserwacji powinny odzwierciedlać rzeczywiste cykle biznesowe i odpowiednie względy dotyczące interoperacyjności, a nie uniwersalną liczbę wybieraną z pulpitu nawigacyjnego.
Wybierz politykę pasującą do domeny
Decyzja ma szerszy zakres niż docelowy współczynnik zdawalności. Wymagaj usług o znaczeniu krytycznym, odpowiedzialnych właścicieli, oszacowanej populacji poczty pośredniej, usuniętych awarii o dużym wpływie i procesu odzyskiwania.
RFC 9989 §7.4 wyraźnie przestrzega p=reject dla poczty elektronicznej ogólnego przeznaczenia i omawia domeny, których użytkownicy uczestniczą w internetowych listach mailingowych. Jej wytyczne dotyczące interoperacyjności obejmują szczegółowe etapy obserwacji i porównania dla tych dziedzin. Nie zastępuj tych wskazówek ogólną obietnicą, że każda monitorowana domena powinna ostatecznie zostać odrzucona.
Ściśle kontrolowana transakcyjna domena wysyłająca i domena używana do korespondencji personelu ogólnego mogą mieć różne ograniczenia operacyjne. Oddziel strumienie tożsamości tam, gdzie służy to rzeczywistemu celowi zarządzania, jednocześnie weryfikując wynikową konfigurację i rzeczywiste komunikaty.
Zdefiniuj dowody na potrzeby następnej decyzji
Przegląd egzekwowania prawa powinien odpowiedzieć na następujące pytania wraz z dowodami:
- Czy zidentyfikowano ważne legalne usługi, czy są one własnością i są testowane?
- Czy każda usługa, której dotyczy problem, ma obsługiwaną wyrównaną ścieżkę?
- Czy wzięto pod uwagę przepływy okresowe i o małej objętości?
- Czy listy mailingowe, przekierowania i inne drogi pośrednie są zrozumiałe?
- Czy zakres raportowania jest opisany bez traktowania go jako wszystkich wysłanych wiadomości e-mail?
- Czy wyjątki mają określony zakres, są własnością i są zaplanowane do przeglądu?
- Czy zespół może zatwierdzić, zweryfikować i naprawić proponowaną zmianę?
Decyzja może dotyczyć ulepszenia nadawcy, zmiany separacji domen, kontynuowania monitorowania lub zastosowania zasad dostosowanych do udokumentowanego użycia domeny. Zachowaj uzasadnienie wraz z protokołem zmian.
Przypisz właścicieli do ustaleń
Zapytaj, czego zespół spodziewa się dowiedzieć i kto podejmie działania w oparciu o ustalenia. Jakie usługi wysyłamy dla firmy? Które krytyczne komunikaty zawodzą? Którzy pozorni nadawcy pozostają niezidentyfikowani? Jakie dowody zadecydują o kolejnym kroku?
Uwzględnij pracę poza bezpośrednim zasięgiem zespołu IT. Miesięczne powiadomienie o liście płac lub powiadomienie o corocznym odnowieniu może być ważne, choć w niewielkim stopniu przyczynia się do ogólnej wiadomości.
Unikaj automatycznego odliczania do silniejszej polityki. Tydzień z kilkoma widocznymi awariami może oznaczać prawidłowe wysyłanie, niekompletne raporty lub usługę, która jeszcze nie została wysłana. Płać za utrzymywany inwentarz i zamknięte ustalenia, a nie tylko za upływające dni.
Kontynuuj monitorowanie po zmianie zasad
Nowe oprogramowanie, zmiany dostawców, rotacja kluczy i zmiany DNS mogą stworzyć nowe luki. Kontynuuj badanie nowych nadawców i uzasadnionych błędów po każdej zmianie zasad.
Wyjaśnij ryzyko szczątkowe liderom biznesowym: odbiorcy zachowują własne wybory dotyczące postępowania w ramach RFC 9989 §5.4, a uwierzytelnianie domeny nie zapobiega każdej podobnej wiadomości, włamaniu na konto lub fałszywemu żądaniu. Do interpretacji dowodów użyj przewodnik dotyczący raportu zbiorczego. W przypadku niepowodzenia nieprzetworzonego przejścia użyj przewodnik wyrównania.
Praktyczne dania na wynos
Wynikiem monitorowania powinien być posiadany spis nadawców, zweryfikowane trasy krytyczne i uzasadniona decyzja polityczna. Monitoruj zmiany środowiska, aby późniejsza zmiana aplikacji, klucza lub bramy nie spowodowała ponownego otwarcia tych samych luk.
Zapisz decyzję i jej ograniczenia
W przypadku fikcyjnego okna dziesięciodniowego pozostaw miesięczną listę płac jako niesprawdzoną, zamiast oznaczać ją jako zdrową. Dodaj jego właściciela, następny reprezentatywny przepływ pracy i dowody potrzebne do uzupełnienia luki. Jeśli zbieranie działa, ale aplikacja nigdy nie została wysłana, dalsza analiza tych samych raportów nie może ustalić jej uwierzytelnienia. Dla tej ilustracji nie zebrano żadnych raportów ani testów płacowych.