Przejście na emeryturę A Selektor DKIM ma dwa różne skutki: nadawca może przestać używać swojego klucza prywatnego do nowych wiadomości, a DNS może przestać udostępniać publiczny klucz weryfikacyjny. Działania te nie muszą odbywać się w tym samym momencie. Podczas zwykłej planowanej rotacji ich oddzielenie może zachować weryfikację poczty już podpisanej i będącej w transporcie.
Wyjątkiem jest incydent związany z bezpieczeństwem. Jeśli stary klucz prywatny może zostać naruszony, udostępnienie jego klucza publicznego pozwoli również na korzystanie z odpowiedniej ścieżki weryfikacji. Zdecyduj wprost o równowadze pomiędzy przechowywaniem a zgodnością z opóźnioną pocztą, zamiast automatycznie stosować rutynowe nakładanie się rotacji.
Zapisz, co stary selektor nadal obsługuje
Spisuj domenę podpisującą, selektor, opiekuna klucza, systemy wysyłające i ostatnie znane użycie. Uwzględnij kolejkę poczty aplikacji, zadania wsadowe i trasy rezerwowe dostawców. Pojedyncza pomyślna wiadomość od nowego podpisującego nie oznacza, że każdy stary podpisujący przestał.
Określ, czy klucz publiczny jest publikowany bezpośrednio, czy dostępny za pośrednictwem zarządzanego przez dostawcę CNAME. Jeśli cel zostanie usunięty po zamknięciu konta, pozostawienie aliasu w DNS klienta nie wystarczy, aby zachować weryfikację. Zapytaj o faktyczne zachowanie w zakresie przechowywania i potwierdź odpowiednią zależność przed podjęciem decyzji o zamknięciu konta.
Zaplanuj przejście z osobnymi nazwami
RFC 6376 §3.1 konstrukcja selektora umożliwia wiele współbieżnych kluczy publicznych w ramach jednej domeny podpisującej. Obsługiwana rotacja może opublikować nowy selektor, potwierdzić, że jego klucz jest możliwy do odzyskania, przełączyć nowe podpisywanie, a następnie zachować stary materiał weryfikacyjny dla zatwierdzonego nakładania się. Nie zastępuj starego materiału klucza pod tą samą nazwą wyszukiwania i załóż, że wcześniej podpisana poczta będzie podążać za nowym kluczem.
Użyj bieżącego algorytmu i wskazówek dotyczących rozmiaru klucza dla nowego klucza. RFC 8301 §3.1 zabrania podpisywania i weryfikacji rsa-sha1. RFC 8301 §3.2 wymaga, aby sygnatariusze używali kluczy RSA o długości co najmniej 1024 bitów, a zalecane jest co najmniej 2048 bitów. Wsparcie dostawcy i obecne wymagania dotyczące bezpieczeństwa nadal wymagają przeglądu; zwykła zmiana etykiety selektora nie wzmacnia klucza.
Rozwiąż sprawę opóźnionych wiadomości
Przykładowa sekwencja: wiadomość A jest podpisana przez old1 przed przełączeniem i czeka w kolejce. Wiadomość B jest podpisana przez new2 po przełączeniu i dociera natychmiast. Obydwa mogą weryfikować, dopóki odpowiadające im klucze publiczne pozostają dostępne, pod warunkiem, że objęte treści i wszystkie inne obowiązujące kontrole weryfikacyjne przejdą pomyślnie. Jeśli podczas oceny A nie można odzyskać żadnego użytecznego klucza Old1, A może się nie powieść bez klucza pod kluczem RFC 6376 §6.1.2 mimo że B zdał.
Wybierz nakładanie się, korzystając ze znanego zachowania kolejki, wygaśnięcia podpisu, jeśli występuje, wymagań biznesowych i ryzyka. Żaden pojedynczy okres przechowywania nie gwarantuje weryfikacji przy każdym ponownym sprawdzeniu zarchiwizowanej poczty. Zachowaj oryginalne wyniki zaufanego uwierzytelniania, gdy liczą się dowody historyczne. Ten scenariusz opisuje oczekiwane zachowanie protokołu, a nie obserwowaną kolejkę usług.
Sprawdź gotowość do przejścia na emeryturę
Potwierdź, że każda aktywna trasa podpisuje się teraz z zamierzonym nowym selektorem i że otrzymane wiadomości przechodzą z wymaganym wyrównanie. Dokonuj przeglądu zadań o niskiej częstotliwości, zamiast polegać wyłącznie na krótkim oknie obserwacji. Zapisz każdą trasę, której nie można przemierzyć, i uzyskaj dowód konfiguracji jej właściciela lub konkretny plan dalszych działań.
Sprawdź założenia dotyczące buforowania DNS . Pod RFC 1034 §3.6, odpowiedzi zapisane wcześniej w pamięci podręcznej mogą zostać zachowane dla wcześniejszych czasów TTL; obniżenie TTL na emeryturze nie powoduje usunięcia tych pamięci podręcznych. RFC 8767 §4 pozwala również na użycie nieaktualnych rekordów w przypadku niepowodzenia autorytatywnego odświeżenia, więc wygaśnięcie TTL nie jest gwarantowanym globalnym terminem unieważnienia. Pomyślne autorytatywne odświeżenie, w tym autorytatywna NXDOMAIN , różni się od niepowodzenia odświeżenia. I odwrotnie, zachowanie klucza publicznego nie przedłuża ważności podpisu ani nie zastępuje zasad odbiorcy. Zachowaj odrębność tych mechanizmów w planie emerytalnym.
Celowo usuń władzę
Po zatwierdzonym oknie zgodności wycofaj publiczny rekord lub delegację zgodnie z obsługiwanym projektem. Pusta wartość p oznacza unieważnienie w ramach RFC 6376 §3.6.1; usunięcie klucza uniemożliwia jego odzyskanie, gdy odpowiednie odpowiedzi w pamięci podręcznej nie będą już go dostarczać. Zapisz wybraną metodę i dlaczego. Bezpieczne usuwanie klucza prywatnego i usuwanie dostępu dostawcy to osobne zadania.
W przypadku skompromitowanego klucza należy udokumentować, dlaczego konieczne jest natychmiastowe unieważnienie lub krótsze nakładanie się kluczy i na jakie prawidłowe wiadomości może to mieć wpływ. Nie przywracaj naruszonych materiałów weryfikacyjnych jedynie w celu poprawy wyniku na desce rozdzielczej. Dokonana zmiana powinna pokazywać kiedy zaprzestano podpisywania starym kluczem, kiedy zakończyła się obsługa weryfikacji starym kluczem oraz jakie dowody uzasadniały obie decyzje.
Zapisz następną decyzję
Hipotetyczny zapis wycofania powinien oddzielać ostatnie podpisanie starego klucza, weryfikację nowej trasy, dowody zaległej kolejki lub zadań o niskiej częstotliwości, utrzymanie docelowego dostawcy, założenia pamięci podręcznej i autoryzowaną decyzję o wycofaniu. Jeśli zaplanowane zadanie rozliczeniowe nie zostało sprawdzone, zaznacz jego zależność jako nierozwiązaną, zamiast wyciągać wniosek o gotowości do przejścia na emeryturę na podstawie ostatniej poczty pracownika. W przypadku podejrzenia naruszenia należy zastosować decyzję dotyczącą incydentu, a nie rutynową listę kontrolną nakładania się. Nie wykonano żadnej rotacji ani usunięcia DNS .