Planowane DKIM rotacja zmienia, który klucz prywatny podpisuje nową pocztę, zachowując jednocześnie materiał weryfikacyjny potrzebny w przypadku wiadomości już przesyłanych. Publikacja nowego klucza publicznego, zmiana osoby podpisującej i wycofanie starego selektor są odrębnymi etapami.
Zacznij od usługi podpisywania i obsługiwanej przez nią procedury rotacji. Delegowanie selektora zarządzane przez dostawcę ma inny model operacyjny niż para kluczy kontrolowana bezpośrednio przez Twoją organizację.
Ustal bieżący stan podpisania
Użyj oryginalnie otrzymanych wiadomości, aby zidentyfikować rzeczywiste domeny podpisujące d= i selektory s=. Powiąż je z usługą podpisywania, modelem zarządzania kluczami i właścicielem firmy.
Rekord DNS może istnieć i nie być używany przez bieżące wiadomości. I odwrotnie, stara wiadomość może odnosić się do selektora, który nie jest już aktywnym wyborem dla nowej poczty.
Zapisz odpowiednie odpowiedzi publiczne i stan konfiguracji. Przechowuj prywatne klucze podpisywania w autoryzowanym systemie podpisywania, a nie w zgłoszeniu, arkuszu kalkulacyjnym inwentarza lub publicznym rekordzie DNS .
Potwierdź wymagania dotyczące algorytmu i dostawcy
Przejrzyj aktualne wskazówki kryptograficzne i obsługiwane zachowania weryfikacyjne. RFC 8301 §3 wyklucza rsa-sha1 i ustala wymagania dotyczące rozmiaru klucza RSA; zaleca klucze RSA o długości co najmniej 2048 bitów. RFC 8463 §5 definiuje Ed25519-SHA256 jako metodę dodatkową.
Specyfikacja algorytmu i faktyczne wsparcie ze strony zaangażowanych nadawców, dostawców i odbiorców to różne dowody. Nie zmieniaj usługi produkcyjnej na metodę, której nie może używać obsługiwana konfiguracja.
W przypadku podpisywania zarządzanego przez dostawcę postępuj zgodnie z wygenerowanymi wartościami i procesem rotacji. Alias DNS może delegować zarządzanie kluczami bez przekazywania Twojemu zespołowi klucza prywatnego ani ręcznej kontroli przełączania.
Opublikuj nowy materiał weryfikacyjny przed przeniesieniem
Jeżeli wspierany projekt korzysta z nowego selektora, należy najpierw opublikować jego poprawny publiczny materiał weryfikacyjny. Potwierdź imię i nazwisko ostatecznego właściciela, odpowiedź i dowolny łańcuch delegacji.
Użyj innego selektora dla nowego klucza, jeśli pozwala na to obsługiwana procedura. Wymiana klucza w ramach jednego selektora może spowodować, że wiadomości podpisane starym kluczem nie będą mogły zostać zweryfikowane pod kątem wymiany.
Nie usuwaj starego klucza tylko dlatego, że nowa odpowiedź DNS wygląda poprawnie. Na tym etapie masz już ustaloną publikację, a nie to, że sygnatariusz się zmienił lub że każdy odbiorca może odzyskać zamierzony materiał.
Przełącz podpisywanie i sprawdzaj nowe wiadomości
Aby rozpocząć podpisywanie nowym kluczem, użyj procedury autoryzowanego podpisywania. Wysyłaj reprezentatywne wiadomości ważnymi drogami i sprawdzaj oryginalne otrzymane podpisy oraz wiarygodne wyniki.
W rotacji syntetycznej wcześniejsza poczta używa s=old2026 , a nowa poczta używa s=new2026. Obie publiczne nazwy weryfikacji pozostają dostępne podczas planowanego nakładania się, podczas gdy nowe otrzymane wiadomości pokazują zamierzony selektor i przechodzący podpis.
Jeśli brama zmodyfikuje wiadomość po podpisaniu, bezpośredni test przed tą bramą będzie niekompletny. Sprawdź pełną trasę biznesową i DMARC wyrównanie jak również surowy wynik podpisu.
Wybierz odejście od warunków dostawy
RFC 6376 §3.1 opisuje równoczesną publikację w okresie przejściowym, w którym poczta może nadal być przesyłana. Nie zapewnia jednego uniwersalnego czasu nakładania się dla każdej organizacji.
Oceń kolejki, zachowanie ponawiania prób, oczekiwane opóźnienia w dostarczaniu, zachowanie pamięci podręcznej DNS , wygaśnięcie odpowiednich podpisów i potrzeby weryfikacyjne. Zapisz powód wybranego nakładania się i wszelkie ograniczenia dostawcy.
Wycofaj stary materiał weryfikacyjny w ramach wspieranego procesu tylko wtedy, gdy ocena to uzasadnia. Późniejsza kontrola zapisanej wiadomości może różnić się od pierwotnego czasu dostarczenia po wycofaniu klucza.
Traktuj podejrzenie kompromisu jako inną decyzję
Rutynowa rotacja ma na celu zachowanie ciągłości. Podejrzewane naruszenie klucza prywatnego może wymagać pilnego ograniczenia lub wycofania pomimo potencjalnego wpływu weryfikacji na starszą pocztę.
Postępuj zgodnie z procesem incydentu organizacji i odpowiedzią dostawcy podpisującego. Zachowaj dowody i wyjaśnij kompromis. Nie obiecuj, że nakładka odpowiednia do rutynowej konserwacji będzie odpowiednia podczas aktywnego kompromisu.
Zakończ za pomocą weryfikowalnego protokołu podpisu
Zachowaj usługę, właściciela, starych i nowych selektorów, dowody z publikacji, obserwację przejścia, uzasadnienie nakładania się, decyzję o przejściu na emeryturę i otrzymane wyniki przedstawiciela.
The przewodnik selektora wyjaśnia wyszukiwanie tożsamości. W przypadku Microsoft 365 lub Workspace użyj ich specyficzne dla najemcy Lub wybrana-domena wskazówki dotyczące konfiguracji. Rotacja jest zakończona, gdy nowa trasa podpisywania zostanie zweryfikowana, a stara zależność zostanie wycofana z udokumentowanego powodu.
Użyj trzech oddzielnych kontroli akceptacji
Proponowana lista kontrolna nie jest rekord zakończonego obrotu. Przed przeniesieniem upewnij się, że nowy selektor przyjmuje wygenerowaną wartość publiczną, podczas gdy stary selektor pozostaje dostępny. Po przełączeniu nowo otrzymany komunikat aplikacji powinien zawierać informację s=new2026 i zamierzoną domenę d z zaufanym hasłem. Przed wycofaniem potwierdź, że uzgodnione warunki kolejki/ponownej próby i weryfikacji zostały spełnione, a następnie zapisz decyzję. Przepustka z niepowiązanej aplikacji nie zamyka danej trasy. Nie zamieniaj przykładowego interwału w uniwersalny czas oczekiwania.