A selektor monitor może poinformować Cię, że dane weryfikacyjne uległy zmianie lub zniknęły. Nie może ustalić, czy usługa nadal wysyła, czy jej klucz prywatny jest zgodny z opublikowanym kluczem ani czy wiadomości docierają z wyrównaniem DKIM. Utwórz osobne kontrole opublikowanej konfiguracji i zaobserwowanego zachowania komunikatów.
Zacznij od znanych tras wysyłania
Utwórz spis na podstawie konfiguracji autoryzowanego nadawcy i otrzymanych wiadomości od przedstawicieli. Dla każdej trasy zapisz właściciela firmy, domenę, selektor, właściciela DNS , oczekiwany TXT lub CNAME układ, ostatni zaobserwowany czas podpisania i stan cyklu życia. Nie zakładaj, że zgadywanie wspólnych selektorów pozwala odkryć każdego podpisującego. DKIM dostarcza selektor w każdym podpisie, zamiast definiować kompletną usługę wyliczania DNS .
W przypadku podpisu z użyciem s=invoice2 i d=brand.example, sprawdź invoice2._domainkey.brand.example w sekcji RFC 6376 §3.6.2.1. Podążaj za oczekiwanym CNAME do jego danych weryfikacyjnych. Przechowuj znacznik czasu obserwacji i odcisk palca klucza publicznego, aby można było porównać zmianę z zatwierdzoną rotacją. Nigdy nie zbieraj kluczy prywatnych do systemu monitorującego.
Oddziel ustalenia monitora
Brakująca odpowiedź, przekroczenie limitu czasu DNS , unieważnienie klucza i zmieniony klucz to różne zdarzenia. RFC 6376 §6.1.2 odróżnia błąd zapytania o klucz od braku klucza, a pusta wartość p oznacza unieważnienie RFC 6376 §3.6.1. Zapisz szczegóły odpowiedzi, zamiast tłumaczyć każdy błąd na ogólną awarię.
Obecny klucz nadal wymaga sprawdzenia składni i algorytmu. RFC 8301 §3.1 zabrania podpisywania i weryfikacji rsa-sha1; RFC 8301 §3.2 aktualizuje wymagania dotyczące rozmiaru RSA: osoby podpisujące muszą używać co najmniej 1024 bitów, a powinny używać co najmniej 2048. Wsparcie produktu i bieżąca polityka kryptograficzna organizacji mogą być bardziej rygorystyczne. Sama zmiana odcisku palca nie może stwierdzić, czy rotacja została autoryzowana.
Dodaj pętlę dowodów na żywo
Wysyłaj kontrolowane wiadomości każdą ważną trasą produkcyjną do skrzynki pocztowej, której nieprzetworzone wiadomości i wyniki zaufanego uwierzytelnienia możesz sprawdzić. Zapisz zaobserwowane d i s, wynik weryfikacji oraz wyrównanie z Od. Przetestuj warianty wiadomości, na które może mieć wpływ dalsze przetwarzanie, takie jak HTML i załączniki.
Monitor ilustrujący: DNS w dalszym ciągu obsługuje fakturę2, ale nowa wiadomość zawiera nie DKIM-Signature. Sprawdzanie publikacji kończy się pomyślnie, a sprawdzanie podpisu kończy się niepowodzeniem. W innym przypadku podpis istnieje, ale jest skrót ciała kończy się niepowodzeniem po zmianie stopki bramy. Żadnego zdarzenia nie można rozwiązać, stwierdzając, że rekord DNS jest zdrowy. Są to syntetyczne przypadki testowe, a nie mierzone incydenty serwisowe.
Testy syntetyczne również mają swoje ograniczenia. Codzienna sonda nie potwierdza wszystkich przekazanych wiadomości między sondami. Połącz je z raportami odbiorców i dowodami incydentów, potwierdzając jednocześnie zakres zgłoszeń i opóźnienia.
Kieruj przydatne alerty
Dołącz alerty do trasy i właściciela. Pomiń tylko wyraźnie zatwierdzone okno konserwacji, zachowaj historię zdarzeń i potwierdź nowego podpisującego świeżą pocztą po rotacji. Eskaluj nieoczekiwane kluczowe zmiany jako możliwe zdarzenia związane z bezpieczeństwem bez deklarowania kompromisu na podstawie samej zmiany.
Celowo wycofuj nieaktualne wiersze zapasów. Stary klucz publiczny może pozostać do weryfikacji wiadomości z opóźnieniem, nawet jeśli nowe podpisywanie zostanie zatrzymane. Odróżnij stan planowany od porzuconej delegacji. Pulpit nawigacyjny powinien informować o tym, co zaobserwowano, kiedy i jaką metodą, aby stan DNS nigdy nie udawał dowodu podpisania na żywo.
Odtwórz decyzję dotyczącą alertu
Użyj czterech sond syntetycznych, aby oddzielić warstwy alertów. Podpis z d=brand.example i s=invoice2 mapuje na invoice2._domainkey.brand.example . Jeśli klucz publiczny jest obecny, ale dostarczony wynik odbiornika to błąd skrótu treści, zgłoś alert dotyczący weryfikacji wiadomości. Jeśli brakuje klucza, zgłoś alert o braku klucza. Jeśli oczekiwany rekord istnieje, ale wiadomość nie ma podpisu, zgłoś alert dotyczący braku podpisu. Aktualny klucz plus dostarczony wynik pozytywny nie daje żadnego alertu dla samej sondy.
Te cztery decyzje stanowią ilustracyjny model decyzyjny z wymyślonymi stanami DNS i dostarczonymi wynikami odbiornika. W ramach tej recenzji nie przeprowadzono żadnego zapytania DNS na żywo, testu podpisu ani weryfikacji kryptograficznej. Aby uruchomić monitor, zastąp je przestarzałymi odpowiedziami publicznymi i nieprzetworzonymi wiadomościami zawierającymi wyniki z zaufanej granicy odbiorczej. Zachowaj powiązane dowody przed określeniem trasy jako zweryfikowanej operacyjnie.
Dowody potrzebne do podjęcia kolejnej decyzji
W przypadku alertu dotyczącego skrótu treści zachowaj dostarczony wynik i sprawdź reprezentację treści, ustawienia c/l, wartość bh i zachowanie implementacji; Sama niezgodność nie oznacza, że treść została zmodyfikowana przez bramę. Oznacz trasę bez nowej sondy jako nieobserwowaną, nawet jeśli obecny jest jej klucz. Oddzielnie zapisz, czy sprawdzono wyrównanie, ponieważ sam przejazd DKIM nie jest przejazdem wyrównanym.