Rotuj klucze DKIM według harmonogramu, aby skradziony lub złamany metodą brute-force klucz prywatny miał krótki okres przydatności. Dla większości nadawców właściwym domyślnym ustawieniem jest rotacja co 6 miesięcy. Skróć ją do 3 miesięcy, jeśli nadal używasz klucza 1024-bitowego, a przejdź na cykl miesięczny, jeśli wysyłasz pocztę o dużej wartości lub w dużej objętości. Sztuką jest robienie tego bez psucia dostarczalności, czyli nigdy nie nadpisuj działającego klucza. Publikujesz nowy selektor, pozostawiasz stary podpisujący i rozwiązywalny przez okres wygaszania, weryfikujesz nowy w praktyce i dopiero wtedy wycofujesz stary klucz.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Po co w ogóle rotować klucze DKIM
Podpis DKIM dowodzi, że wiadomość naprawdę pochodzi z Twojej domeny i nie została zmieniona w drodze. Dowód ten opiera się wyłącznie na tym, że Twój klucz prywatny pozostaje prywatny. Jeśli ten klucz wycieknie (kopia zapasowa pozostawiona w publicznym zasobniku, skompromitowany serwer pocztowy, były współpracownik z dostępem do serwera), atakujący może podpisywać pocztę w Twoim imieniu, a ona przejdzie DKIM i dopasowanie DMARC bez zarzutu. Rotacja to mechanizm, który ogranicza okno zagrożenia. Klucz wycofywany co kwartał jest dla atakującego wart znacznie mniej niż taki, który podpisuje Twoją pocztę bez zmian od pięciu lat.
Jest i drugi powód: siła klucza się starzeje. Klucz RSA 1024-bitowy był w porządku dekadę temu, a dziś stanowi minimum, a nie cel. Rotacja to naturalny moment na przejście na 2048 bitów i wycofanie słabych kluczy, zanim staną się obciążeniem. Jeśli nie potwierdziłeś obecnej długości klucza, nasz przewodnik konfiguracji DKIM prowadzi przez generowanie klucza 2048-bitowego i publikację rekordu.
Co tak naprawdę zmienia "rotacja"
Rotacja zastępuje parę kluczy stojącą za selektorem. Selektor to etykieta w Twoim rekordzie DKIM (na przykład s1._domainkey.yourdomain.com), która wskazuje odbiorcy, który klucz publiczny pobrać. Rotować możesz, ponownie używając jednego selektora i podmieniając jego klucz, albo publikując zupełnie nowy selektor. To właśnie podejście z nowym selektorem umożliwia rotację bez przestojów, ponieważ oba klucze mogą istnieć jednocześnie.
Jak często rotować: tabela decyzyjna według profilu ryzyka
Nie ma jednego poprawnego interwału. Dopasuj częstotliwość do tego, ile kosztowałaby Cię kompromitacja, oraz do klucza, którego dziś używasz.
| Profil ryzyka | Interwał rotacji | Dlaczego |
|---|---|---|
| Standardowy nadawca biznesowy, klucz 2048-bitowy | Co 6 miesięcy | Równoważy nakład operacyjny i ekspozycję; powszechnie przywoływana wartość domyślna. |
| Dowolny klucz 1024-bitowy nadal w użyciu | Co 3 miesiące, a przy najbliższej rotacji upgrade do 2048 bitów | Krótsze klucze są tańsze do zaatakowania, więc skróć okno w trakcie migracji. |
| Nadawcy o wysokiej wartości lub dużej objętości (banki, płatności, duże strumienie marketingowe) | Co miesiąc, automatycznie | Klucz podpisujący jest tu głównym celem; częsta rotacja plus automatyzacja utrzymują mały zasięg rażenia. |
| Podejrzenie lub potwierdzenie kompromitacji klucza | Natychmiast, poza kolejnością | Zobacz procedurę awaryjną poniżej. Nie czekaj na kalendarz. |
Liczby mają mniejsze znaczenie niż dyscyplina. Zespół, który niezawodnie rotuje co 6 miesięcy, jest w znacznie lepszej sytuacji niż taki, który spisał na papierze politykę miesięczną i nigdy jej nie zautomatyzował. Wybierz najdłuższy interwał, którego zobowiążesz się przestrzegać, a następnie zacieśniaj go w miarę budowania narzędzi.
Procedura bezprzestojowej rotacji z dwoma selektorami
Scenariusz awarii, którego ludzie się boją, jest realny: nadpisz klucz podpisujący pocztę w locie, a odbiorcy zaczną zwracać DKIM fail dla wiadomości już oczekujących w kolejkach i u przekaźników. Rozwiązaniem jest nałożenie na siebie dwóch selektorów, tak aby żadna wiadomość nigdy nie została z nierozwiązywalnym kluczem.
Krok 1: Opublikuj nowy selektor
Wygeneruj świeżą parę kluczy 2048-bitowych. Opublikuj klucz publiczny pod nowym selektorem, pozostawiając bieżący nietknięty. Jeśli podpisujesz za pomocą s1, opublikuj s2:
s2._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...AB"
Na tym etapie nic jeszcze nie podpisuje za pomocą s2. Po prostu zasiewasz DNS, aby rekord miał czas rozpropagować się wszędzie, zanim będzie potrzebny.
Krok 2: Przełącz podpisywanie na nowy selektor
Gdy nowy rekord się rozpropaguje (dla bezpieczeństwa odczekaj kilka godzin, a dłużej, jeśli Twój TTL jest wysoki), poleć swojej platformie pocztowej, aby podpisywała pocztę wychodzącą za pomocą s2. Nowa poczta niesie teraz nowy podpis. Co kluczowe, pozostawiasz stary klucz publiczny s1 opublikowany i działający.
Krok 3: Utrzymuj stary klucz rozwiązywalny przez okres wygaszania
Poczta już podpisana za pomocą s1 może wciąż być w drodze, w kolejce u odbiorcy albo odbijać się przez przekaźnik przez wiele dni. Utrzymuj publiczny rekord s1 w DNS przez 7 do 30 dni, aby te wiadomości nadal dało się zweryfikować. Siedem dni pokrywa normalne dostarczanie; 30 dni to bezpieczny wybór, jeśli wysyłasz pocztę transakcyjną, która jest przekazywana dalej lub archiwizowana i sprawdzana ponownie później.
Krok 4: Zweryfikuj, potem wycofaj
Zanim cokolwiek usuniesz, potwierdź, że nowy selektor działa w prawdziwym świecie. Sprawdź nagłówek Authentication-Results w wiadomości testowej wysłanej na konto Gmail i Outlook i szukaj dkim=pass odwołującego się do nowego selektora; nasz przewodnik o czytaniu nagłówka Authentication-Results pokazuje dokładnie, na co zwrócić uwagę. Gdy nabierzesz pewności, a okres wygaszania minie, usuń rekord TXT s1 i bezpiecznie zniszcz jego klucz prywatny.
Utrzymywanie dwóch selektorów celowo jest normalne i bezpieczne. Jeśli chcesz zrozumieć, jak odbiorcy wybierają między nimi, zobacz wiele selektorów DKIM na jednej domenie.
Automatyczna rotacja z kluczami hostowanymi przez CNAME
Ręczna rotacja nie skaluje się do cyklu miesięcznego. Najczystszym sposobem jej zautomatyzowania jest zaprzestanie hostowania klucza publicznego we własnym DNS jako rekordu TXT i zamiast tego skierowanie selektora na dostawcę za pomocą CNAME:
selector1._domainkey.yourdomain.com IN CNAME selector1.dkim.provider.example
Teraz dostawca jest właścicielem materiału kluczowego stojącego za tą nazwą hosta. Gdy przeprowadza rotację, rekord, na który rozwiązuje się Twój selektor, zmienia się po jego stronie, a Ty nigdy nie dotykasz swojego DNS. Microsoft 365 stosuje dokładnie ten wzorzec z dwoma opublikowanymi selektorami, aby móc się między nimi przełączać, a wielu dostawców ESP też go oferuje. Kompromisem jest zaufanie: delegujesz kontrolę nad swoją tożsamością podpisującą do tego dostawcy, więc korzystaj z tego tylko z nadawcami, którym i tak już zaufałbyś, aby wysyłali w Twoim imieniu.
Jeśli nie możesz użyć CNAME, zaskryptuj przepływ z dwoma selektorami TXT względem API dostawcy DNS i naprzemiennie stosuj dwie nazwy selektorów przy każdym uruchomieniu. Procedura powyżej jest ta sama; po prostu pozwalasz zadaniu wykonywać kroki od 1 do 4 według harmonogramu.
Rotacja awaryjna po podejrzeniu kompromitacji
Jeśli sądzisz, że klucz prywatny wyciekł, kalendarz przestaje obowiązywać. Działaj natychmiast i zmień kolejność operacji, bo szybkość jest ważniejsza niż elegancja.
- Wygeneruj nową parę kluczy i od razu opublikuj ją pod nowym selektorem.
- Przełącz całe podpisywanie na nowy selektor, gdy tylko rekord się rozwiąże.
- Usuń teraz z DNS publiczny rekord skompromitowanego selektora, zamiast czekać do końca okresu wygaszania. Owszem, może to spowodować, że część prawidłowo podpisanej poczty w locie nie przejdzie DKIM, ale to jest właściwy kompromis: ujawniony klucz jest aktywnie niebezpieczny i musi przestać być zaufany.
- Rotuj wszelkie poświadczenia, które mogły ujawnić klucz (dostęp do serwera, tokeny API, kopie zapasowe) i zbadaj, jak doszło do wycieku.
- Obserwuj raporty DMARC przez kolejne dni pod kątem oznak, że stary klucz jest nadal nadużywany. Jeśli egzekwujesz politykę, sfałszowana poczta podpisana martwym kluczem nie przejdzie teraz dopasowania i zostanie odrzucona, co jest działaniem ochrony zgodnym z zamierzeniem. Jeśli nie jesteś jeszcze na etapie egzekwowania, zobacz polityka DMARC: none, quarantine czy reject.
Powód, dla którego rotacja awaryjna wydaje się ryzykowna, jest taki, że celowo poświęca odrobinę prawidłowej poczty, by szybko odciąć skompromitowaną tożsamość. To za każdym razem właściwa decyzja.
Najczęściej zadawane pytania
Jak często powinienem rotować klucze DKIM?
Co 6 miesięcy to rozsądne ustawienie domyślne dla standardowego nadawcy z kluczem 2048-bitowym. Rotuj co 3 miesiące, jeśli nadal używasz klucza 1024-bitowego, i co miesiąc, jeśli jesteś nadawcą o wysokiej wartości lub dużej objętości i potrafisz to zautomatyzować. Każdy interwał, którego faktycznie przestrzegasz, jest lepszy niż krótszy, który pomijasz.
Czy rotacja klucza DKIM odbije pocztę?
Nie, jeśli nałożysz na siebie selektory. Opublikuj nowy selektor, przełącz na niego podpisywanie i pozostaw stary klucz publiczny rozwiązywalny przez 7 do 30 dni, aby poczta w locie i przekazywana dalej nadal mogła się zweryfikować. Awarie powoduje tylko nadpisanie działającego klucza w miejscu.
Czy mam ponownie użyć tego samego selektora, czy utworzyć nowy?
Dla planowanej rotacji utwórz nowy selektor. To, że stary i nowy klucz publiczny są opublikowane jednocześnie, pozwala starej poczcie nadal się weryfikować, podczas gdy nowa używa nowego klucza. Ponowne użycie jednego selektora wymusza podmianę w miejscu bez nakładania.
Czy klucze DKIM hostowane przez CNAME rotują się automatycznie?
Tak. Gdy selektor jest rekordem CNAME wskazującym na Twojego dostawcę, dostawca rotuje klucz źródłowy, a Twój DNS nigdy się nie zmienia. Tak rotację obsługuje Microsoft 365 i wielu dostawców ESP. Kompromisem jest to, że delegujesz kontrolę nad kluczem podpisującym do tego dostawcy.