Cóż za symbol wieloznaczny celowo poszerza
Konsument raportu może chcieć go otrzymać DMARC raporty dla dowolnej domeny, zamiast publikować jednego właściciela autoryzacji dla każdej relacji. RFC 9990 wyraźnie zezwala na użycie w tym celu wieloznacznego rekordu DNS . Jego przykład umieszcza a Rekord TXT Na *. _report._dmarc.example.com z co najmniej v=DMARC1. Jest to szeroka zgoda domeny odbierającej, a nie mechanizm potwierdzający, że każdy zgłaszający klient został sprawdzony.
Rozróżnienie to ma znaczenie operacyjne. Dostawca może zgodnie z prawem wybrać szerokie spożycie, jednocześnie wymagając weryfikacji na poziomie konta przed wyświetleniem danych klientowi. Rekord DNS nie implementuje tych kontroli konta. Przegląd bezpieczeństwa powinien dokładnie określić, które granice zmieniają się w przypadku symboli wieloznacznych, a za które granice odpowiada aplikacja odbierająca i jej właściciele. RFC 9990 , sekcja 4
Zachowaj dokładne zapytania widoczne pod symbolem wieloznacznym
Osoba zgłaszająca nadal tworzy wyszukiwanie autoryzacji z domeny, w której pobrano politykę, czyli plik _report. _dmarc etykiety i host docelowy. Symbol wieloznaczny to strategia publikacji DNS , która może odpowiedzieć na te zapytania; nie eliminuje to konieczności zrozumienia pytanego właściciela lub zwracanej wartości. Podczas weryfikowania konkretnego związku zachowaj dokładnego właściciela i odpowiedź.
Odpowiedź potwierdzająca musi spełniać zasady analizy zewnętrznej weryfikacji, w tym obowiązkowe pierwsze v=DMARC1. Wartość wersji pozostaje DMARC1 z wymaganą wielkością liter. Zamiar administratora dotyczący użycia symbolu wieloznacznego nie jest dowodem na to, że określone zapytanie zostanie rozwiązane zgodnie z oczekiwaniami we wdrożonym drzewie DNS . Dokładne rekordy nazw i struktura DNS mogą mieć wpływ na rzeczywistą rozdzielczość, dlatego proponowane testy muszą zachować rzeczywistą odpowiedź, a nie zakładać, że zrzut ekranu potwierdza zasięg. RFC 9990 , sekcja 4; RFC 9989 , sekcja 4.7
Oddziel uprawnienia do pobierania od własności i dostępu do danych
Symbol wieloznaczny oznacza, że domena odbierająca jest skłonna otrzymywać raporty objęte ustaleniami protokołu. Nie stwierdza się, że osoba logująca się do dashboardu kontroluje domenę wymienioną w raporcie. Nie ustala również, czy nadawca przesłanego artefaktu jest godny zaufania ani czy raport należy do konta, które go otrzymuje.
Oddzielnie zdefiniuj wymagania akceptacji na poziomie aplikacji: powiązanie domeny z dzierżawcą, uwierzytelniony dostęp, śledzenie pochodzenia, obsługa duplikatów i przegląd nieoczekiwanych domen. Są to proponowane kontrole, a nie twierdzenia dotyczące wdrożonej platformy EmailAuth . Raport zawierający wzmiankę o organizacji nie powinien automatycznie tworzyć relacji własności ani udostępniać danych pierwszemu kontu, które rości sobie prawo do tej nazwy.
Trzymaj rozliczenia, wdrażanie i autoryzację danych poza zasięgiem DNS . Szeroka chęć odbioru ruchu nie oznacza zgody na wpisanie organizacji do płatnej usługi lub opublikowanie jej obserwowanej konfiguracji. Jeśli przepływ pracy wymaga tych działań, wymaga wyraźnych decyzji i dowodów wykraczających poza rekord wieloznaczny. W przeglądzie należy wskazać odpowiedzialnego właściciela każdej granicy, a nie traktować pojedynczego wyniku DNS jako kompleksowej zgody.
Uwzględnij nadużycia i presję na zasoby
RFC 9990 ostrzega, że treść raportu może zaatakować dekompresor lub parser XML i że dane raportu mogą zostać sfałszowane. Szeroki zakres usług przyjmowania powinien zatem zakładać, że zezwolenie na otrzymywanie raportów nie gwarantuje, że każdy otrzymany plik będzie bezpieczny i dokładny. Planowanie wydajności, limity analizatora i kontrole pochodzenia są częścią projektu autoryzacji.
Zaproponuj ograniczone rozmiary wiadomości, limity rozmiaru po dekompresji, budżety czasu analizy, izolację kolejek i alerty w przypadku nieoczekiwanego wolumenu źródłowego. Wartości liczbowe należy wybrać i przetestować dla rzeczywistego środowiska, a nie kopiować z wymyślonego uniwersalnego limitu. Zachowaj powody odrzucenia i nie pozwalaj, aby jedno hałaśliwe źródło przesłaniało niepowiązane dowody klienta. Żadna z tych kontroli nie jest tutaj wdrożona ani przetestowana. RFC 9990 , sekcja 8.1 i 8.2
Wypłata i autoryzacja w pamięci podręcznej
Odbiorca raportu przytłoczony dużą liczbą danych może usunąć potwierdzający rekord DNS , ale RFC 9990 zauważono, że dodatnie buforowanie może opóźnić efekt tak długo, jak wynosi TTL rekordu. Nie obiecuj natychmiastowego zaprzestania raportów po zmianie DNS . Systemy poboru mogą również wymagać obsługi raportów już wygenerowanych lub umieszczonych w kolejce niezależnie od stanu świeżego wyszukiwania.
Plan wycofania powinien określać właściciela rekordu, ścieżkę zatwierdzenia, odpowiednie dowody TTL, zachowanie w zakresie przyjmowania podczas przejścia i obowiązki komunikacyjne. Usunięcie symbolu wieloznacznego może mieć wpływ na wiele prawidłowych relacji jednocześnie. Proponowane przejście na wyraźną autoryzację dla domeny wymaga, a nie tylko spisu tych relacji i planu weryfikacji rekord usunięcie.
Zachowaj rozróżnienie między wycofaniem DNS a cofnięciem dostępu do aplikacji. Usunięcie pozwolenia na otrzymywanie samo w sobie nie powoduje usunięcia zapisanych raportów, zamknięcia kont klientów ani anulowania istniejących sesji użytkowników. Są to oddzielne kontrole z oddzielnymi konsekwencjami autoryzacji i przechowywania. RFC 9990 , sekcja 4
Przegląd fikcyjnych granic i projekt testów
Rozważmy fikcyjnego konsumenta w witrynie reports.example.net , który proponuje plik *. _report._dmarc.reports.example.net o wartości v=DMARC1; . W przypadku hipotetycznych zasad pod adresem blue.example.com dokładne zapytanie będzie brzmiało blue.example.com._report._dmarc.reports.example.net . W tym przykładzie nie wykonano żadnego zapytania, publikacji ani elementu DNS .
Plan przypadków pozytywnych zachowa dokładne zapytanie i potwierdzi, że zwrócona wartość autoryzacji przeszła analizę. Należy ostrożnie wybrać plan przypadku negatywnego: inna domena źródłowa skierowana do tego samego szeroko autoryzowanego miejsca docelowego niekoniecznie jest nieautoryzowana, ponieważ symbol wieloznaczny celowo obejmuje ogólnie domeny źródłowe. Zamiast tego oddzielnie kontrolowany host docelowy bez pozwolenia może zilustrować granicę zewnętrznego miejsca docelowego, pod warunkiem, że jakiekolwiek rzeczywiste urządzenie jest autoryzowane i izolowane.
Arkusz powinien zawierać listę właściciela symbolu wieloznacznego, oczekiwanego zasięgu, dokładnych właścicieli testów, odpowiedzi, analizę wersji, granicę hosta docelowego i kontrole dostępu dzierżawcy. Powinien także rejestrować plan wycofywania zmian i ograniczenia przetwarzania raportów. Oczekiwane wyniki są hipotezami projektowymi do czasu przeprowadzenia rzeczywistych testów ograniczonych; nie można ich uważać za pozytywne tylko dlatego, że uzasadnienie jest wiarygodne.
Nierozwiązane oryginalne dowody i bramki zwalniające
Katalog wymaga dokładnego upoważnienia właściciela i odpowiedzi, w tym testu pozytywnego i testu nieautoryzowanego miejsca docelowego. Te pierwotne obserwacje pozostają otwarte. Ten manuskrypt zawiera proponowany projekt testu i fikcyjne nazwy, a nie działające wdrożenie symboli wieloznacznych ani ocenę dostępu do konta.
Przed publikacją jako zweryfikowany przewodnik operacyjny wykwalifikowany recenzent musi sprawdzić rzeczywiste odpowiedzi DNS i potwierdzić, że wynik testu negatywnego rzeczywiście przekracza zamierzoną granicę autoryzacji. Oryginalne dowody, weryfikacja przez człowieka, zastosowanie źródła, trasy produkcji, dostępność wizualna i zezwolenie właściciela pozostają otwarte. W związku z tą pracą nie wykonano żadnego kontaktu zewnętrznego, przesłania raportu ani modyfikacji DNS .