Odziedziczony spis nadawców to narzędzie decyzyjne, a nie lista adresów IP. Przed standaryzacją nabytych domen połącz obserwowaną pocztę z usługą specyficzną dla klienta, która ją wygenerowała, jej właścicielem biznesowym i zatwierdzonymi tożsamościami. Znany dostawca może obsługiwać zarówno legalny, jak i niechciany ruch, więc samo rozpoznanie infrastruktury nie jest równoznaczne z akceptacją.
Zacznij od wielu źródeł dowodów
Zbieraj autoryzowane eksporty konfiguracji, rejestry aplikacji, zapisy kont dostawców, obserwacje DNS i dostępne dowody pocztowe. Zapisz, skąd pochodzą poszczególne obserwacje i kiedy zostały zebrane. Raporty zbiorcze może ujawnić źródłowe adresy IP i wzorce uwierzytelniania, ale nie może samodzielnie ustalić zamiarów biznesowych organizacji ani pełnej populacji nadawców. RFC 9990.
Dla każdej usługi, cel zapisu, właściciel odpowiedzialny, konto dostawcy lub dzierżawca, krytyczność, widoczne z domeny, domena koperty, DKIM tożsamość podpisu, ostatni reprezentatywny test i dowód zatwierdzenia. Zachowaj jawność nieznanych pól. Rejestruj oddzielnie cel wysyłania i odbierania dla domen, które mogą być uśpione lub defensywne.
Przypisz tożsamości przed dodaniem uprawnień
Porównaj zaobserwowane identyfikatory z rzeczywistą konfiguracją dostawcy i przepływem pracy biznesowej. DMARC wykorzystuje wyrównanie pomiędzy domeną autora a pomyślnie uwierzytelnionym identyfikatorem; ogólny wynik przejścia bez identyfikatorów może ukryć problem, który musisz rozwiązać. RFC 9989.
Nie dodawaj nieznanego źródła do SPF po prostu dlatego, że poczta wydaje się pochodzić właśnie stamtąd. SPF autoryzuje hosty dla ocenianej tożsamości, a jej ocena uwzględnia limity wyszukiwania DNS . RFC 7208 , sekcja 4.6.4. Nowe dołączenie może rozszerzyć uprawnienia, przekroczyć limity operacyjne lub nie naprawić wyrównania. Najpierw ustal zamierzoną usługę i odpowiednią uwierzytelnioną trasę.
Oddziel zatwierdzanie i testowanie
Zatwierdzona usługa może nadal nie przejść testu migracji; uwierzytelniona wiadomość może nadal pochodzić z niezatwierdzonej usługi. Przechowuj oba stany. Dowód zatwierdzenia powinien identyfikować decyzję podlegającą odpowiedzialności, natomiast dowód badania powinien opisywać rzeczywistą transakcję, tożsamość, wynik i czas. Nie używaj przepustki testowej jako substytutu własności firmy.
Załóżmy, że odziedziczona usługa rozliczeniowa ma wyznaczonego właściciela firmy i zatwierdzony cel, ale tożsamość podpisująca konta docelowego nie została zweryfikowana. Druga usługa ma wyrównany przekaz, ale nie ma zidentyfikowanego właściciela firmy. Pierwszy wymaga udokumentowania trasy przed migracją; drugi wymaga przypisania i zatwierdzenia, zanim zostanie potraktowany jako autoryzowany serwis. Żadnej luki nie załata uspokajający wynik drugiego serwisu.
Są to hipotetyczne decyzje dotyczące inwentaryzacji, a nie wygenerowane zapisy lub przeprowadzone testy. Zachowaj osobne pola dotyczące własności, zamierzonej tożsamości, zatwierdzenia i bieżącego zasięgu testów. Gdy właściciel aplikacji dostarczy brakujące dowody konta, zaktualizuj tylko ustalony przez niego stan; nie zmieniaj automatycznie nieprzetestowanego wyniku migracji na pozytywny.
Zmień atrybucję w plan migracji
Grupuj usługi według zweryfikowanego właściciela, zależności i gotowości. Zdefiniuj zamierzone tożsamości docelowe i testy przed edycją rekordów. Zachowaj nieznane trasy do celów dochodzenia, z podaniem nazwy właściciela i terminu, zamiast po cichu je zatwierdzać lub usuwać. Zachowaj starą konfigurację i zatwierdzony plan odzyskiwania dla każdej kolejnej migracji.
Po standaryzacji należy porównać rzeczywiste obserwacje z zatwierdzonym wykazem i zbadać nowe tożsamości. Zachowaj emerytowane służby i ich decyzje w historii. Przydatny inwentarz pozostaje dokumentem operacyjnym na podstawie zmian dostawców i reakcji na incydenty, a nie arkuszem kalkulacyjnym porzuconym po zakończeniu projektu fuzji.
Ten przepływ pracy dotyczący inwentaryzacji i przeglądu jest zalecanym modelem operacyjnym. NIST SP 800-53 Rev. 5 CM-8 i CM-3 stanowią ogólną podstawę rozliczalnych zapasów i kontrolowanych zmian; nie zalecają tych pól specyficznych dla poczty e-mail ani nie udzielają zgody. Katalog kontrolny NIST.