A DKIM klucz prywatny to uprawnienie do tworzenia podpisów, które można zweryfikować z pasującym rekordem publicznym. Sama ochrona rekordu DNS nie chroni tego organu. Inwentaryzuj systemy podpisywania, konta, które mogą z nich korzystać, oraz każdą operacyjną kopię sekretu przed podjęciem decyzji o kluczu.
Zidentyfikuj opiekę, zamiast ją zakładać
Zacznij od faktycznego dostawcy lub oprogramowania do podpisywania. Usługa zarządzana może generować i przechowywać klucze; samoobsługowy podpisujący może odczytać plik, tajny magazyn lub obsługiwany interfejs sprzętowy. Modele te mają różne mechanizmy kontroli dostępu i odzyskiwania. Nie obiecuj ochrony sprzętu, braku możliwości eksportu ani rotacji zarządzanej przez klienta, chyba że wybrany produkt dokumentuje to i wdraża.
RFC 6376 §8.3 wyjaśnia konsekwencje naruszenia bezpieczeństwa klucza prywatnego: intruz może utworzyć pocztę podpisaną przez domenę publikującą odpowiedni klucz publiczny. Opisuje także wartość kontrolowanego serwera poczty wychodzącej, który uwierzytelnia nadawców i stosuje kontrolę wysyłania. Poniższe szczegółowe kroki przechowywania i przeglądania stanowią zalecenia operacyjne, a nie uniwersalne wymagania protokołu DKIM .
Zbuduj mapę aresztu, która ujawni ukryte kopie
Dla każdego selektor, zapisz domenę podpisującą, właściciela usługi, opiekuna klucza, aktywne węzły podpisujące, ścieżkę wdrożenia i obsługiwany mechanizm odzyskiwania. Śledź odniesienie lub identyfikator sekretu, a nie sam sekret. Przejrzyj repozytoria konfiguracji, etapy budowania kontenerów, tymczasowe pliki wdrożeniowe, kopie zapasowe i pakiety diagnostyczne pod kątem niezamierzonych kopii w ramach zatwierdzonego przez organizację procesu obsługi sekretów.
Syntetycznym przykładem jest klaster rozliczeniowy z dwoma węzłami podpisującymi i zadaniem wdrożenia. Klucz DNS jest publiczny i oczekiwany. Klucz prywatny ma dotrzeć tylko do dwóch węzłów, ale stary potok kompilacji osadza go również w obrazie dostępnym dla niepowiązanych projektów. Zabezpieczenie bieżących uprawnień do pliku węzła nie usunęłoby starszej ekspozycji. Zbadaj ścieżkę dystrybucji i traktuj potencjalnie ujawniony sekret zgodnie z procesem incydentu.
Nigdy nie wklejaj klucza prywatnego do publicznego pola DNS , biletu, czatu lub publicznego narzędzia sprawdzającego DKIM . Jeżeli wsparcie potrzebuje dowodów, należy przekazać publicznemu selektorowi informacje i odpowiednio kontrolowane wyniki diagnostyczne. Surowe wiadomości mogą również zawierać poufne treści; minimalizuj to, co jest udostępniane i korzystaj z zatwierdzonych kanałów.
Ogranicz liczbę osób, które mogą podpisywać i odzyskiwać tajemnice
Korzystaj z obsługiwanych przez platformę mechanizmów kontroli najniższych uprawnień zarówno w zakresie dostępu administracyjnego, jak i dostępu w czasie wykonywania. Konto, które może żądać podpisów, może być potężne, nawet jeśli nie może wyeksportować klucza. Sprawdź, kto może zmieniać dozwolone tożsamości wysyłania, przesyłać pocztę, zmieniać klucze, wdrażać konfigurację osoby podpisującej i pobierać kopie zapasowe.
Oddzielne usługi z różnymi właścicielami lub poziomami zaufania, gdzie architektura obsługuje niezależne klucze i selektory. Kopiowanie jednego klucza do każdej aplikacji utrudnia określenie zakresu incydentu, a wycofanie go powoduje większe zakłócenia. Wysoka dostępność może zgodnie z prawem wymagać współdzielonej tożsamości podpisującej, ale powinien to być jawny projekt z kontrolowaną dystrybucją, a nie przypadkowa konsekwencja skopiowanego pliku konfiguracyjnego.
Przetestuj odzyskiwanie bez rozpowszechniania klucza tajnego
Zapytaj, czy awarię można naprawić poprzez przywrócenie chronionego klucza, wygenerowanie zamiennika lub skorzystanie z zarządzanej ścieżki odzyskiwania dostawcy. Przetestuj obsługiwaną procedurę w kontrolowanym środowisku. Rejestruj czas odzyskiwania, zależności DNS i to, czy poczta w kolejce nadal korzysta ze starszego selektora. Nie twórz dodatkowych niezabezpieczonych kopii zapasowych tylko po to, aby ułatwić ćwiczenie.
Przeglądaj dzienniki i zdarzenia dostępu dostępne z platformy podpisywania i systemu zarządzania sekretami. Przydatnym pytaniem jest to, czy można wykryć i zbadać nieautoryzowaną zmianę lub użycie, a nie to, czy istnieje konkretny pulpit nawigacyjny. Dokumentuj luki w rejestrowaniu zamiast wymyślać ścieżkę audytu.
Zakończ z praktycznym zapisem cyklu życia
Trzymaj mapę opieki obok procedur rotacji i kompromisów. Usuń przestarzały dostęp po odejściu personelu lub dostawcy i ponownie sprawdź dystrybucję po zmianach w infrastrukturze. W przypadku podejrzenia narażenia należy skoordynować zabezpieczenie dostępu, czystą wymianę i konsekwencje weryfikacji wycofania starego klucza. Chroniony bieżący plik to tylko część kontrolowanego cyklu życia podpisywania.
Skorzystaj z arkusza decyzji w sprawie opieki nad dzieckiem
Dla każdej tożsamości podpisującej zapisz następujące jawne pola:
- Zastosowanie: które konta usług mogą przesyłać podpisy lub żądać podpisów oraz jakich tożsamości mogą używać.
- Odzyskiwanie: które role mogą eksportować lub przywracać klucz prywatny i gdzie znajdują się zatwierdzone kopie.
- Zmień: kto może zmieniać konfigurację osoby podpisującej, dozwolone tożsamości lub artefakty wdrożenia.
- Odzyskiwanie: czy obsługiwana ścieżka przywraca chroniony klucz, czy generuje zamiennik, z zależnościami DNS i poczty w kolejce.
- Dowody: dostępne dzienniki dostępu/podpisywania, wszelkie luki w zabezpieczeniach i właściciel odpowiedzialny za przegląd.
Jeśli stary artefakt kompilacji zawiera odsłonięty klucz, zabezpieczenie tylko aktywnego węzła jest niewystarczające: określ zakres starego ujawnienia i zdecyduj o czystej wymianie w ramach procedur incydentów. Ten arkusz stanowi wytyczne dotyczące bezpieczeństwa redakcyjnego, a nie twierdzenie, że konkretna platforma zapewnia te elementy sterujące.
Powiązane lektury
Unieważnij klucz DKIM i rozróżnij unieważnienie od brakującego rekordu DNS · Długość klucza DKIM i algorytmy: sprawdź aktualną obsługę odbiornika.