Inwentaryzacja poczty e-mail firmy tworzącej oprogramowanie często zaczyna się od platformy marketingowej i kończy zbyt wcześnie. Dostęp bez hasła, odpowiedzi pomocy technicznej, faktury i aktualizacje statusu mogą zależeć od różnych dostawców, danych uwierzytelniających i domen. Zawodzą także w różnych momentach. Wiadomość e-mail o stanie, która zależy od tej samej niedostępnej aplikacji, którą ma opisywać, stanowi problem z zależnością operacyjną, nawet jeśli tak jest DKIM konfiguracja jest prawidłowa.
Mapuj usługę za nadawcą
Twórz wiersze dla zdarzeń związanych z produktami, rozmów dotyczących wsparcia, rozliczeń i powiadomień na stronie stanu. Dla każdego zapisz właściciela, dzierżawcę dostawcy, wyzwalacz, z domeny, tożsamość koperty, domenę DKIM i selektor, odpowiedz w sprawie obsługi i kontaktu w sprawie odzyskiwania. Śledź, która aplikacja lub osoba może zainicjować wysyłanie. Zidentyfikuj zależności od produkcyjnej bazy danych, dostawcy tożsamości, magazynu kluczy tajnych i potoku wdrażania, a następnie zdecyduj, które są akceptowalne w przypadku komunikacji o incydentach.
Nie zatwierdzaj adresu IP, ponieważ należy on do znanego dostawcy usług w chmurze. Wspólna infrastruktura nie jest dowodem na to, że najemca firmy wysłał wiadomość. Połącz obserwację z zatwierdzonym kontem, obsługiwaną konfiguracją domeny i odpowiedzialnym właścicielem. Zachowaj niepewny ruch jako nierozwiązany, dopóki dowody nie potwierdzą przypisania.
Zdefiniuj akceptację poprzez przepływ pracy
Test zdarzenia produktu powinien rozpoczynać się wewnątrz produktu, test wsparcia w systemie wsparcia, a test rozliczeń w autoryzowanej piaskownicy. Aby uzyskać aktualizacje statusu, skontaktuj się z wyznaczonym wydawcą incydentów i sprawdź, czy ta osoba może działać podczas awarii usługi podstawowej. Potwierdź zamierzoną trasę odpowiedzi, aby klienci nie odpowiadali nieoczekiwanie na niemonitorowany adres.
RFC 9989 wspiera ocenę dopasowanego wykorzystania domeny, a nie dostępności aplikacji czy poprawności faktury. Podpis z własnej domeny dostawcy może zweryfikować, choć nie jest to zamierzone wyrównanie relacja. Wyniki uwierzytelnienia muszą zatem towarzyszyć, a nie zastępować test akceptacji przepływu pracy.
Nie pozwól, aby poczta produktowa zakrywała ścieżkę statusu
Załóżmy, że trasy produktów, wsparcia i rozliczeń korzystają z domen DKIM d= pasujących do odpowiednich domen Od, podczas gdy status.software.example jest domeną Od powiadomienia o stanie, a provider.example.net jest jej osobą podpisującą. Nawet przy założeniu prawidłowej kryptografii, ta ostatnia nie spełnia ścisłego dostosowania DKIM . Zamiast zmieniać niepowiązaną pocztę rozliczeniową, potwierdź obsługiwaną konfigurację tożsamości dostawcy statusu. Tożsamości te są hipotetyczne, nie są dostarczane podpisane próbki ani rzeczywiste wyniki weryfikacji.
Wyrównanie pojedynczego podpisu nie jest pełne DMARC werdykt: oceń inne ważne wyrównane podpisy i SPF zgodnie z obowiązującymi przepisami RFC 9989 sekcje 4.4 i 5.3.5. Dla p=reject wdrożenia, sekcje 7.4 i 8 wymagają prawidłowego DKIM , a nie polegania wyłącznie na SPF . Ani sukces podpisu, ani wyrównanie nie gwarantują, że wydawca statusu może działać podczas przestoju. Nie przeprowadzono żadnego działającego testu platformy ani testu kryptograficznego.
Przetestuj zależność od incydentu, a nie tylko DNS
Uruchom autoryzowane ćwiczenie, w którym zwykły operator produktu jest niedostępny, a wydawca incydentu zapasowego postępuje udokumentowaną trasą. Nie przerywaj celowo produkcji tylko po to, aby przetestować ten przewodnik. Rejestruj, które dane uwierzytelniające, konta i systemy były niezbędne, czy kontrolowany odbiorca otrzymał aktualizację i co zgłosiła granica odbiorcza. Jeśli rozwiązanie awaryjne wymaga niedostępnego dostawcy tożsamości, zanotuj to ograniczenie i przeprojektuj je wspólnie z właścicielem zabezpieczeń, zamiast improwizować wspólne hasło.
Aby podpisać zmiany, postępuj zgodnie z bieżącymi instrukcjami dostawcy i zachowaj dowody wycofania. Usuń przestarzałe autoryzacje dopiero po potwierdzeniu, że nie korzysta z nich żaden zachowany produkt, wsparcie lub przepływ rozliczeń. Niewielkie wpływy i rzadkie komunikaty o incydentach mogą zniknąć z krótkich okresów obserwacji, nie stając się przestarzałe.
Uczyń inwentaryzację częścią kontroli zmian
Wymagaj przeglądu trasy, gdy zespół dodaje dostawcę powiadomień, zmienia adres nadawcy, przesuwa kolejkę pomocy technicznej lub wymienia usługę statusu. Przetestuj ponownie przepływy, których to dotyczy, i zachowaj daty dowodów. Inwentarz jest kompletny jedynie w zadeklarowanym zakresie; nowe funkcje produktu mogą dodawać nowych nadawców. Każdą migrację kończ za pomocą testu zatwierdzonego przez właściciela i użytecznej procedury odzyskiwania, a nie średniej dla całej domeny.