Subdomena może być produkcyjnym API, panelem pracownika, stroną kampanii, rekordem walidacyjnym albo pozostałością po projekcie zakończonym kilka lat temu. Wszystkie te nazwy są częścią publicznego obrazu firmy, nawet gdy nie ma ich w głównym menu. Problem zaczyna się wtedy, gdy organizacja nie wie, kto je posiada, do czego służą i czy nadal są chronione. Inwentarz subdomen jest więc zadaniem zarządczym i bezpieczeństwa, a nie tylko ćwiczeniem z wyszukiwania DNS.
Warto przyjąć model dowodów. Nazwa z certyfikatu mówi, że ktoś otrzymał certyfikat dla danego hosta w określonym czasie. Rekord DNS mówi, że nazwa jest lub była delegowana. Odpowiedź HTTP pokazuje, że w chwili testu działa usługa. Żaden z tych sygnałów sam nie dowodzi własności, podatności ani przejęcia. Połączone z właścicielem, statusem i historią tworzą jednak podstawę do sensownej decyzji.
Zdefiniuj zakres domen i wildcardów
Zacznij od domen głównych, wariantów regionalnych, domen po fuzjach i nazw obronnych. Zapisz, czy zakres obejmuje tylko exact subdomain, czy także rekordy wildcard, alternatywne końcówki oraz usługi dostawców. Wildcard DNS może powodować, że wiele nazw odpowiada, mimo że nie ma osobnych rekordów. Nie twórz na tej podstawie listy aktywnych aplikacji. Najpierw sprawdź, czy host ma własną treść, certyfikat, przekierowanie lub inne potwierdzenie.
- DNS: nazwy z rekordami A, AAAA, CNAME, MX, TXT i NS.
- Certyfikaty: nazwy ujawnione w publicznych logach CT.
- Aplikacje: hosty wskazane w dokumentacji, kodzie, reklamach lub konfiguracji.
- Marka: warianty regionalne i nazwy, których istnienie ma znaczenie dla ochrony klientów.
Połącz pasywne odkrywanie z aktywną weryfikacją
Pasywne źródła, takie jak logi Certificate Transparency, pomagają znaleźć nazwy bez generowania szerokich zapytań do infrastruktury. Są szczególnie przydatne, gdy certyfikat ujawnia host, którego nie ma w dokumentacji. Następnie zweryfikuj nazwę przez DNS i, jeśli jest to dozwolone oraz bezpieczne, przez ograniczone żądanie HTTPS. Wynik „brak odpowiedzi” nie oznacza, że nazwa nie istnieje. Może być wyłączona, prywatna, filtrowana albo wymagać innego punktu dostępu.
CERT Polska opisuje funkcję infrastruktury organizacji jako sposób zobaczenia publicznie widocznych zasobów, także zapomnianych lub niezgłoszonych. To dobra ilustracja celu inwentaryzacji: znaleźć elementy do wyjaśnienia, nie ogłosić automatycznie, że każdy host jest zagrożeniem. Przy każdym wyniku zachowaj źródło, czas i dokładną nazwę, aby zespół mógł odtworzyć obserwację.
Nadaj subdomenie właściciela i klasę
Sama lista nazw szybko się starzeje. Dodaj właściciela biznesowego, technicznego, środowisko, krytyczność, dostawcę usługi, datę ostatniej weryfikacji i planowany termin kolejnego przeglądu. Klasa może oznaczać produkcję, test, kampanię, pocztę, walidację, przekierowanie, parking albo status nieznany. Jeżeli nikt nie potrafi potwierdzić funkcji, nie usuwaj hosta natychmiast. Najpierw sprawdź wpływ, powiązane certyfikaty i rekordy, a potem zaplanuj bezpieczne wyłączenie.
Sprawdź przejęcia przez dangling DNS
CNAME wskazujący na wycofaną usługę może pozostawić subdomenę w stanie wymagającym szczególnej uwagi. Nie jest to automatyczny dowód, że ktoś może ją przejąć. Trzeba potwierdzić dostawcę, stan zasobu, warunki rejestracji i to, czy firma nadal posiada kontrolę nad usługą. Podobnie nieaktywny adres A nie jest dowodem podatności. Raport powinien używać języka „do weryfikacji” i wskazywać, jaki dowód pozwoli zamknąć sprawę.
Nie próbuj rejestrować cudzych zasobów ani wykonywać testów przejęcia bez wyraźnej zgody. Bezpieczny audyt ogranicza się do publicznych odpowiedzi, identyfikacji właściciela i procedury wycofania. Jeżeli host jest ważny, zespół powinien usunąć niepotrzebny rekord lub przywrócić kontrolowany zasób zgodnie z planem zmian, a następnie ponownie zweryfikować DNS i HTTPS.
Rozpoznaj technologię dopiero po potwierdzeniu hosta
Technologia widoczna w odpowiedzi HTTP może pomóc właścicielowi zrozumieć wiek lub charakter usługi, ale nie jest pełnym skanem bezpieczeństwa. Nagłówki, certyfikat i treść są sygnałami obarczonymi niepewnością. Nie publikuj w raporcie wrażliwych szczegółów, których nie potrzebuje odbiorca. Najpierw ustal, że host należy do zakresu firmy i ma właściciela. Dopiero potem użyj klasyfikacji technologii do planowania aktualizacji, zamknięcia lub dodatkowego audytu.
Zbuduj priorytety remediacji
Priorytet wynika z połączenia ekspozycji, wartości usługi, dowodu kontroli i możliwości wpływu na klienta. Produkcyjne logowanie z nieznanym właścicielem jest ważniejsze niż stara strona kampanii. Certyfikat na nazwie administracyjnej może wymagać szybszej rozmowy niż kolejna nazwa testowa. W przypadku braku danych ustaw status nieznany, przydziel zadanie i termin potwierdzenia. Nie zastępuj analizy jednym wynikiem „ryzykowny”, bo taki wynik nie mówi, co zrobić.
- Potwierdź, czy nazwa jest aktywna i należy do organizacji.
- Ustal właściciela oraz wpływ usługi na klientów i pracowników.
- Zweryfikuj DNS, certyfikat, przekierowania i dostawcę usługi.
- Usuń, zabezpiecz albo udokumentuj zasób zgodnie z decyzją właściciela.
- Zachowaj dowód po zmianie i dodaj nazwę do kolejnego cyklu monitoringu.
Utrzymuj inwentarz po migracji i kampanii
Najwięcej zapomnianych subdomen powstaje przy szybkich wdrożeniach, zmianach agencji, integracjach marketingowych i migracjach DNS. Dodaj punkt kontrolny do procesu uruchomienia usługi: nazwa, właściciel, rekord, certyfikat, termin i plan wycofania. Przy zamknięciu projektu wykonaj odwrotną kontrolę. Usuń lub wygaszaj zasoby w kolejności, która nie zrywa walidacji certyfikatu ani ruchu do aktywnej usługi. Po zmianie sprawdź, jak odpowiedź wygląda z perspektywy użytkownika.
Przy większym portfelu automatyzuj pobieranie nazw z kilku dozwolonych kanałów i przechowuj różnice jako obserwacje. Dodaj deduplikację, datę źródła, klasyfikację confidence oraz stan unknown. Takie metadane pomagają nie mylić nowej nazwy z potwierdzoną usługą i nie kierować zespołu do fałszywej remediacji. Gdy system wykryje zmianę, człowiek powinien móc otworzyć dowód i zapytać właściwego właściciela, zanim podejmie działanie.
Celem odkrywania subdomen nie jest najdłuższa lista. Jest nim lista, za którą ktoś może wziąć odpowiedzialność.
Praktyka zarządzania powierzchnią ataku
Przykład inwentaryzacji po zmianie agencji
Firma może odkryć, że po zakończeniu kampanii nadal istnieją landing page, rekord CNAME i certyfikat dla subdomeny z nazwą produktu. Marketing uważa projekt za zamknięty, a zespół IT nie wie, czy adres odwiedzają klienci. Najpierw sprawdź ruch, DNS, treść, przekierowania i zależności w reklamach. Następnie poproś właściciela biznesowego o decyzję: utrzymać, przekierować albo wygasić. Przy wycofaniu usuń zasób w kolejności, która nie pozostawia wskazania na niekontrolowaną usługę, a po zmianie ponów obserwację.
Podobny problem występuje po migracji poczty lub aplikacji. Stara nazwa może mieć MX, rekord walidacyjny albo certyfikat, mimo że użytkownicy już z niej nie korzystają. Nie usuwaj wpisu tylko dlatego, że nie odpowiada HTTP. Sprawdź pocztę, automaty, integracje i proces odnowienia. Zapisz właściciela decyzji oraz termin ponownego sprawdzenia, ponieważ stary rekord może być używany sporadycznie przez faktury, reset hasła lub zewnętrzny system.
Zadbaj o jakość danych w inwentarzu
Każdy rekord inwentarza powinien mieć kanoniczną nazwę, źródło odkrycia, czas obserwacji, sposób weryfikacji, właściciela, krytyczność i status. Nie mieszaj nazw znalezionych w CT z nazwami potwierdzonymi przez DNS. Jeśli host pojawił się tylko w jednym certyfikacie sprzed roku, oznacz go jako historyczny sygnał. Gdy odpowiada teraz i ma własną treść, status może być aktywny. Taka dokładność ogranicza fałszywe alarmy i pozwala zespółowi skupić się na nazwach wymagających realnej decyzji.
- nowy: znaleziony, ale bez potwierdzonej usługi
- potwierdzony: DNS, certyfikat lub właściciel potwierdza zastosowanie
- wygaszany: ma plan wycofania i termin sprawdzenia
- nieznany: brak wystarczających dowodów do decyzji
- zamknięty: usunięty lub przejęty pod kontrolę firmy
Przy cyklicznym odkrywaniu deduplikuj nazwy po kanonicznym zapisie i zachowuj wszystkie źródła. Jeżeli jedna nazwa pojawia się w logu certyfikatu i w DNS, nie twórz dwóch alertów. Jeżeli zmienia się tylko data certyfikatu, nie traktuj tego jako nowej subdomeny. Zapisuj różnice tak, aby operator widział zmianę stanu, a nie powtarzającą się listę wszystkich zasobów. Przy wielu organizacjach dodaj identyfikator zakresu, aby nie pomylić marki klienta z nazwą podobnego podmiotu.
Włącz kontrolę do procesu wdrożenia
Każdy nowy host powinien mieć zgłoszenie z nazwą, celem, właścicielem, rekordem DNS, certyfikatem, środowiskiem i datą przeglądu. Przy zamknięciu projektu zgłoszenie powinno wskazywać, czy subdomena zostaje, przekierowuje czy jest usuwana. Dzięki temu odkrywanie publiczne nie jest jedynym sposobem znalezienia zasobów. W czasie przeglądu porównaj listę wdrożeń z DNS i certyfikatami. Różnica jest sygnałem do rozmowy, nie automatycznym poleceniem usunięcia.
Przy usługach zewnętrznych wpisz w umowie, kto kontroluje konto i rekord docelowy, jak działa zakończenie współpracy oraz kiedy usuwa się CNAME. Pozostawiony alias może być zwykłą pozostałością, ale wymaga wyjaśnienia, bo wpływ na zasób zależy od stanu u dostawcy. W razie niepewności zabezpiecz domenę i usuń wskazanie dopiero po potwierdzeniu, że nie łamiesz aktywnego procesu biznesowego.
- Nowy host nie trafia do produkcji bez właściciela i celu.
- Każdy CNAME do usługi zewnętrznej ma kontakt i plan wycofania.
- Certyfikat i rekord walidacyjny są powiązane z aplikacją, nie tylko z nazwą.
- Po zakończeniu projektu wykonujesz test DNS, HTTPS i przekierowania.
- Zmiany w inwentarzu zostawiają dowód oraz datę następnego przeglądu.
Wyniki odkrywania przekazuj właścicielom w formie krótkiej kolejki. Przy każdej nazwie pokaż, co potwierdzono, czego nie wiadomo i jaki następny krok jest potrzebny. Nie wysyłaj zespołowi samej listy setek hostów, bo szybko przestanie ją czytać. Grupuj nazwy według aplikacji, krytyczności i przyczyny alertu. Po zamknięciu zadania zachowaj zmianę i dowód, aby kolejny cykl nie otwierał tej samej sprawy bez kontekstu.
Nie każda subdomena powinna być publicznie opisana w raporcie dla całej firmy. Właściciel bezpieczeństwa może potrzebować pełnej listy, podczas gdy marketing potrzebuje tylko statusu nazw związanych z kampaniami. Ogranicz dostęp do szczegółów, zachowaj źródła i nie ujawniaj w materiałach publicznych informacji, które ułatwiają rozpoznanie wrażliwych hostów. Inwentaryzacja ma poprawiać kontrolę, nie tworzyć nowego katalogu dla osoby nieuprawnionej.
Dodaj do inwentarza datę ważności informacji, nie tylko datę znalezienia nazwy. Właściciel może potwierdzić host dziś, ale po zmianie agencji, aplikacji lub certyfikatu stan może być inny. Ponowne sprawdzenie po migracji i przed odnowieniem ogranicza ryzyko, że dokumentacja opisuje już nieistniejącą usługę. W razie braku odpowiedzi zachowaj status nieznany i przypisz termin eskalacji, zamiast usuwać rekord bez potwierdzenia wpływu.
Na etapie planowania migracji dodaj test starej i nowej subdomeny, aby nie pomylić przełączenia z wycofaniem. Sprawdź, czy certyfikat obejmuje nazwy, czy rekord CNAME wskazuje na właściwy zasób i czy przekierowanie nie prowadzi do obcej usługi. Po zakończeniu zapisz nowy baseline oraz listę nazw, które mają zostać usunięte w późniejszym terminie. Taka kontrola ogranicza ryzyko, że tymczasowy host pozostanie publiczny bez właściciela.
Subdomeny stają się ryzykiem dopiero wtedy, gdy są niewidoczne dla właściciela, pozostają bez kontroli lub nie pasują do aktualnej architektury. Połączenie DNS, certyfikatów, odpowiedzi usług i danych organizacyjnych pozwala odróżnić zasób działający od historycznego śladu. Powtarzaj proces po migracjach i zmianach, utrzymuj jasne statusy i traktuj niepewność jako zadanie do wyjaśnienia, nie jako dowód winy.