Zaszyfrowana wiadomość e-mail może nadal prowadzić do niezabezpieczonego raportu diagnostycznego. RFC 9989 ostrzega, że wiadomość oryginalnie zaszyfrowana lub w inny sposób zabezpieczona może pojawić się w raporcie, który nie został wysłany bezpiecznie. Dlatego też ochronę związaną z raportem awarii należy zaprojektować dla samego raportu, a nie dziedziczić z pierwotnego komunikatu.
Ten przewodnik jest listą kontrolną projektu i akceptacji po stronie odbiorcy. Nie twierdzi, że każdy odbiornik raportów obsługuje zaszyfrowane ładunki raportów o błędach, zaleca nowy DMARC otaguj lub podaj przetestowaną konfigurację dla konkretnego produktu. Przed zebraniem wrażliwych materiałów ustal rzeczywiste możliwości systemów raportowania i wykorzystania.
Oddziel trzy warstwy ochronne
Ochrona transportu dotyczy połączeń, które posiadają meldunek. Szyfrowanie na poziomie wiadomości dotyczy ładunku raportu i tego, kto może go odszyfrować. Ochrona przechowywania dotyczy zatrzymanych danych i kopii po ich otrzymaniu. Warstwy te adresują różne ścieżki ekspozycji i nie zastępują się nawzajem.
Chroniony przeskok SMTP nie dowodzi, że załącznik pozostaje zaszyfrowany w skrzynce pocztowej, eksporcie lub zgłoszeniu. Zaszyfrowany przechowywany plik nie dowodzi, że każdy przeskok transportowy był chroniony. Wynik podpisu lub uwierzytelnienia również nie gwarantuje poufności. Opisz konkretną ochronę i jej granicę zamiast oznaczać cały przepływ pracy jako szyfrowany.
Uzgodnij, co może zapewnić system raportowania
Zapytaj, czy generator może wysłać raport w wymaganym formacie uzgodnioną bezpieczną ścieżką, czy obsługuje szyfrowanie ładunku oraz w jaki sposób ustanawiana i utrzymywana jest tożsamość deszyfrująca konsumenta. Zapisz wszelkie limity wsparcia, zachowanie w przypadku awarii i dozwolone awarie. Nie zakładaj, że identyfikator URI raportowania automatycznie negocjuje zgodny schemat szyfrowania.
RFC 9991 zachęca do bezpiecznych kanałów i podkreśla minimalizację i kontrolowane miejsca docelowe. Mechanizmu raportowania ruf nie należy interpretować jako uniwersalnej gwarancji szyfrowania na poziomie wiadomości. Jeśli nie można zweryfikować wymaganych zabezpieczeń, należy rozważyć kontrolowane próbki diagnostyczne lub dane zbiorcze, zamiast domyślnie akceptować szersze gromadzenie danych wrażliwych.
Przygotuj granicę deszyfrowania
Jeśli obsługiwane jest szyfrowanie ładunku, przypisz własność kluczy odbiorców, zatwierdzonych usług deszyfrowania, rejestrowania dostępu, rotacji i odzyskiwania. Trzymaj klucze prywatne poza zwykłymi zgłoszeniami pomocy technicznej i magazynami raportów. Określ, który proces może widzieć zwykły tekst i czy ten proces tworzy pliki tymczasowe, dzienniki, podglądy czy dalsze kopie.
Traktuj pomyślne odszyfrowanie jako dostęp do niezaufanych treści, a nie sprawdzenie ich bezpieczeństwa. Oryginalna wiadomość w raporcie może zawierać złośliwe oprogramowanie lub phishing tworzywo. Stosuj oddzielne pobieranie, ograniczoną analizę i odpowiednią izolację, nawet jeśli zaszyfrowana koperta pochodzi z oczekiwanego źródła.
Przetestuj całą trasę z nieszkodliwymi urządzeniami
Przykładowy test akceptacyjny: uzgodniony system raportowania wysyła nieszkodliwe urządzenie zatwierdzoną ścieżką. Może je przetwarzać upoważniony konsument; nieautoryzowane konto nie może uzyskać dostępu do zwykłego tekstu; awarie są rejestrowane bez zapisywania treści komunikatów w logach ogólnych; a wyeksportowane dowody podlegają zatwierdzonemu procesowi redakcyjnemu.
Przetestuj także nieczytelny lub nieoczekiwany ładunek, brakującą możliwość deszyfrowania i każdą udokumentowaną procedurę zmiany klucza. Określ, czy bezpiecznym wynikiem jest kwarantanna, odrzucenie czy zatwierdzona ponowna próba. Nigdy po cichu nie wracaj do rozpowszechniania zwykłego tekstu, gdy wymagane było szyfrowanie. Są to proponowane testy, a nie twierdzenie, że jakikolwiek system je przeszedł.
Użyj nazwanego urządzenia i macierzy oczekiwanych wyników
Proponowane urządzenie oprawa-01 zawiera jedynie znacznik REPORT-TEST-ONLY i wymyślone adresy pod example.com . Konto A jest autoryzowanym kontem testowo-konsumenckim; konto B jest w przeciwnym razie zwykłym kontem bez dostępu do raportów. Używaj wyłącznie formatu szyfrowania i układu klucza testowego wyraźnie obsługiwanego przez oba systemy testowe. W tym ćwiczeniu nie bierze się pod uwagę żadnego produkcyjnego klucza prywatnego ani prawdziwej wiadomości.
Poniższa macierz ma charakter hipotetyczny i nie została porównana z usługą raportowania. Opisuje wyniki akceptacji do sprawdzenia, a nie funkcje obiecane przez określony produkt.
- Testowanie wejścia lub działania: A przetwarza nienaruszone urządzenie-01 za pomocą zatwierdzonego klucza testowego; Oczekiwany wynik do sprawdzenia: A może odczytać TYLKO RAPORT-TEST w granicach ograniczonej analizy; Dowody, które należy zachować: identyfikator testu, autoryzowane konto, czas i wynik, bez kluczowych materiałów
- Testuj wejście lub działanie: B próbuje uzyskać ten sam dostęp; Oczekiwany wynik do sprawdzenia: B nie może uzyskać dostępu do zwykłego tekstu ani usługi deszyfrowania; Dowody, które należy zachować: zdarzenie odmowy dostępu i tożsamość konta
- Testowanie wejścia lub operacji: A przetwarza urządzenie-01 z błędnym lub brakującym kluczem testowym; Oczekiwany wynik do sprawdzenia: brak wersji w postaci zwykłego tekstu; izolować lub odrzucać zgodnie z zatwierdzonym projektem awarii; brak automatycznego powrotu do tekstu jawnego; Dowody do zachowania: kod błędu i numer kwarantanny lub odrzucenia
- Dane wejściowe lub działanie testowe: A przetwarza celowo uszkodzoną kopię; Oczekiwany wynik do sprawdzenia: Wykryj błąd przetwarzania i wyizoluj go; nie renderuj częściowej treści ani nie traktuj jej po cichu jako ważnego raportu; Dowody do zachowania: Identyfikator uszkodzonego urządzenia i wynik błędu
- Testowanie danych wejściowych lub operacji: Zakończenie przetwarzania i uruchomienie tymczasowego czyszczenia; Oczekiwany wynik do sprawdzenia: Dzienniki ogólne nie zawierają znaczników urządzenia ani treści komunikatu; tymczasowe kopie w postaci zwykłego tekstu są usuwane zgodnie z zatwierdzoną zasadą czyszczenia; Dowody do zachowania: inspekcja kłód i kontrola magazynu tymczasowego
- Wejście testowe lub operacja: A eksportuje zatwierdzony wyciąg diagnostyczny; Oczekiwany wynik do weryfikacji: Eksport zawiera tylko uzgodnione pola; B nadal nie może uzyskać do niego dostępu; Dowody do zachowania: sprawdzona lista pól eksportu i kontrola dostępu do miejsc docelowych
- brakująca zdolność jest nierozwiązanym wynikiem testu, a nie pozytywnym wynikiem. Zapisz rzeczywiste wyniki wraz z tą matrycą, gdy przeprowadzany jest autoryzowany test. Jeśli uszkodzone dane wejściowe można bezpiecznie przeanalizować w ramach udokumentowanego projektu, należy dokładnie sprawdzić to zachowanie, zamiast osłabiać oczekiwany wynik po awarii.
Obejmuje życie tekstu jawnego
Po odszyfrowaniu ogranicz dostęp i zachowaj tylko to, czego potrzebuje cel diagnostyczny. Uwzględnij przekazywanie poczty, pobieranie analityków, indeksy wyszukiwania, załączniki do zdarzeń i kopie zapasowe na mapie danych. Szyfrowanie na wejściu nie uniemożliwia autoryzowanemu użytkownikowi lub integracji utworzenia niepotrzebnej kopii w postaci zwykłego tekstu.
Rejestruj dowody potwierdzające każdy poziom ochrony, właścicieli systemu i nierozwiązane ograniczenia. Użyj daty przeglądu, aby potwierdzić ciągłą zgodność i kontrolę dostępu. Dającym się obronić wynikiem jest zweryfikowana granica obsługi raportów z wyraźnymi lukami, a nie ogólne stwierdzenie, że zaszyfrowana poczta zapewnia bezpieczeństwo zgłaszania błędów.
Decyzję dotyczącą możliwości należy oddzielić od planu testów
W pisemnej sprawie ENC-01 założono, że konsument obsługuje zaszyfrowane ładunki, ale obsługa generatora jest nieznana. Dlatego też Urządzenie-01 nie zostało wysłane i każdy wynik macierzy oczekuje na realizację. Właściciel kolekcji powinien uzyskać udokumentowaną zgodność przed zatwierdzeniem nieszkodliwego testu; pomyślny TLS do skrzynki pocztowej nie zapewnia zgodności ładunku. Nie włączaj szerszego przyjmowania surowych raportów tylko dlatego, że istnieje usługa deszyfrowania. Nie użyto żadnego klucza, konta ani raportu.