Ład DNS w 2026 r.: kontrole rejestratora gotowe do audytu

O 07:42 w poniedziałek rano CISO fintechowego scale-upu otrzymuje wiadomość, której nikt nie chce zobaczyć. Klienci nie mogą uzyskać dostępu do portalu płatności, helpdesk jest zalany zgłoszeniami, poczta elektroniczna nie działa, a SOC nie wykrył złośliwego oprogramowania, awarii zapory sieciowej ani incydentu po stronie dostawcy usług chmurowych.

Przyczyna źródłowa jest cichsza i bardziej kłopotliwa. Dostęp do konta rejestratora uzyskano przy użyciu nieaktualnych poświadczeń administratora współdzielonych przez kilku byłych pracowników IT. Atakujący zmienił autorytatywne serwery nazw, zmodyfikował rekordy MX, wyłączył DNSSEC i przekierował ruch na wystarczająco długo, aby pozyskać poświadczenia i zakłócić działanie partnerskich interfejsów API. Portal płatności nie został zhakowany w tradycyjnym znaczeniu. Zaatakowana została kotwica zaufania spółki: jej domena.

Do 09:30 kryzys operacyjny staje się kryzysem zgodności. Zarząd pyta, czy włączono registry lock. Dział prawny pyta, czy doszło do ujawnienia danych osobowych. DPO pyta, czy jest to naruszenie ochrony danych osobowych w rozumieniu GDPR. Regulator chce wiedzieć, czy naruszono funkcję krytyczną lub istotną. Audytor klienta prosi o zgłoszenie zmiany zatwierdzające modyfikację DNS.

W zbyt wielu organizacjach odpowiedzią jest arkusz kalkulacyjny, współdzielona skrzynka pocztowa i konsola rejestratora, której nikt nie przeglądał od sześciu miesięcy.

Ład DNS i nadzór nad rejestratorem domen w 2026 r. nie są już niszowym tematem infrastrukturalnym. To element odporności na ransomware, zapobiegania phishingowi, dostępności chmury obliczeniowej, zarządzania ryzykiem dostawców, reagowania na incydenty, ciągłości działania oraz zgodności opartej na dowodach. Jeżeli Twoją domenę można przejąć, Twoja platforma SaaS może zniknąć. Jeżeli rekordy DNS można zmienić bez zatwierdzenia, bezpieczeństwo poczty elektronicznej, SSO, certyfikaty TLS, punkty końcowe API i zaufanie klientów mogą zostać podważone w ciągu minut.

Dlaczego ład DNS i nadzór nad rejestratorem powinny być częścią SZBI

Nazwa domeny nie jest wyłącznie aktywem marki. Jest aktywem logicznym, zależnością uwierzytelniania, zależnością routingu i często usługą zarządzaną przez dostawcę. Łączy dostawców tożsamości, uwierzytelnianie poczty elektronicznej, walidację certyfikatów TLS, punkty końcowe chmury obliczeniowej, portale klientów, interfejsy API, usługi CDN, sondy monitorujące i komunikację incydentową.

Polityka zarządzania aktywami - MŚP Clarysec Polityka zarządzania aktywami - MŚP wskazuje to wprost w swoim zakresie:

Poświadczenia i usługi cyfrowe: nazwy domen, certyfikaty cyfrowe, klucze API, konta poczty elektronicznej, logowania do chmury obliczeniowej

Z sekcji „Zakres”, klauzula polityki 2.2.4.

Ta sama polityka wymaga więcej niż tylko wpisania nazwy domeny na listę:

Własność, cel, uprawnienia dostępu i terminy odnowienia muszą być udokumentowane.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.6.2.

W środowiskach enterprise Polityka zarządzania aktywami Clarysec Polityka zarządzania aktywami obejmuje zakresem także aktywa logiczne:

Aktywa logiczne: nazwy domen, licencje, konta użytkowników, konfiguracje bazowe

Z sekcji „Zakres”, klauzula polityki 2.2.5.

To punkt wyjścia dla ładu zarządczego. Inwentarz DNS i rejestratora powinien dokumentować:

• Nazwę domeny, rejestr, rejestratora, dostawcę hostingu DNS i autorytatywne serwery nazw
• Właściciela biznesowego, właściciela technicznego, właściciela ds. bezpieczeństwa i osobę zatwierdzającą w trybie awaryjnym
• Cel, taki jak portal produkcyjny, API, poczta elektroniczna, SSO, marketing, środowisko testowe lub rejestracja defensywna
• Ocenę krytyczności i mapowanie zależności do usług biznesowych
• Status DNSSEC, status rekordu DS, własność kluczy i proces rotacji kluczy
• Status registry lock i registrar lock
• Model MFA i dostępu uprzywilejowanego dla kont rejestratora i dostawcy DNS
• Datę odnowienia, status automatycznego odnowienia, właściciela płatności i alertowanie o wygaśnięciu
• Wymagania dotyczące kontroli zmian dla edycji stref i zmian delegowania
• Rejestrowanie, alertowanie, monitorowanie i okres przechowywania dowodów

Dlatego ład nad domenami powinien znaleźć się w zakresie SZBI i ocenie ryzyka ISO/IEC 27001:2022. ISO/IEC 27001:2022 wymaga, aby organizacje określiły kontekst, wymagania stron zainteresowanych, obowiązki prawne i umowne, interfejsy oraz zależności z organizacjami zewnętrznymi. DNS zależy od rejestratorów, rejestrów, dostawców hostingu DNS, dostawców usług chmurowych, urzędów certyfikacji, MSP, a czasem także od agencji marketingowych. Jeżeli te interfejsy zostaną wyłączone z SZBI, ścieżka audytowa będzie niekompletna.

Model zagrożeń DNS w 2026 r.

Najbardziej dotkliwe awarie DNS są często proste:

1. Domena wygasa, ponieważ nie było jasne, kto odpowiada za jej odnowienie.
2. Była agencja nadal ma dostęp do konta rejestratora.
3. DNSSEC jest włączony, ale rekordy DS są błędne po migracji dostawcy DNS.
4. Rekord wildcard kieruje ruch do porzuconej usługi w chmurze obliczeniowej.
5. Rekord TXT zostaje zmieniony, aby zweryfikować tenant SaaS kontrolowany przez atakującego albo żądanie certyfikatu.
6. Rekordy MX są modyfikowane w trakcie kampanii phishingowej lub przechwytywania poczty elektronicznej.
7. CNAME do platformy strony trzeciej staje się podatny na przejęcie.
8. Registry lock istnieje dla domeny głównej, ale nie dla krajowych domen dostępnych dla klientów.
9. SOC monitoruje punkty końcowe, ale nikt nie monitoruje zmian pliku strefy.

Techniczne środki bezpieczeństwa są dobrze znane. DNSSEC pomaga chronić integralność danych DNS i uwierzytelnianie pochodzenia. Registry lock sprawia, że zmiany wysokiego ryzyka na poziomie rejestru wymagają dodatkowej weryfikacji poza kanałem podstawowym. Registrar lock ogranicza ryzyko nieuprawnionego transferu. MFA i przeglądy dostępu uprzywilejowanego zmniejszają prawdopodobieństwo przejęcia konta. Kontrola zmian zapobiega przypadkowym zakłóceniom. Monitorowanie wykrywa zmiany nieuprawnione lub nieoczekiwane.

Wyzwanie zgodności jest inne: czy możesz wykazać, że te środki bezpieczeństwa istnieją, mają właścicieli, są przeglądane i działają podczas incydentu?

Właśnie na tym pytaniu o dowody wiele organizacji ponosi porażkę.

Mapowanie ładu DNS na ISO/IEC 27001:2022 i ISO/IEC 27002:2022

ISO/IEC 27001:2022 zapewnia strukturę systemu zarządzania potrzebną do przekształcenia kontroli DNS w powtarzalne procesy podlegające audytowi. Załącznik A ISO/IEC 27001:2022 oraz wytyczne dotyczące środków kontrolnych w ISO/IEC 27002:2022 dostarczają języka kontroli oczekiwanego przez audytorów.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Clarysec Zenith Blueprint traktuje usługi sieciowe jako wyraźne obiekty audytu. W fazie Controls in Action, krok 20, instruuje zespoły, aby walidowały bezpieczeństwo usług sieciowych:

Wypisz wszystkie wewnętrzne i zewnętrzne usługi sieciowe (DNS, VPN, SMTP, DHCP, bramy API, itp.).

✓ Dla każdej z nich potwierdź, że używa bezpiecznych protokołów (np. DNSSEC, TLS 1.2+, SSH zamiast Telnet). ✓ Sprawdź, jak kontrolowany jest dostęp do każdej usługi (np. listy dozwolonych adresów IP, uwierzytelnianie, certyfikaty). ✓ Jeżeli usługi są zarządzane przez strony trzecie (np. DNS, SD-WAN, hostowany VPN), przejrzyj klauzule bezpieczeństwa w SLA lub umowie z dostawcą. Zaktualizuj Rejestr usług i wskaż, gdzie leżą odpowiedzialności za bezpieczeństwo: wewnętrznie czy zewnętrznie.

Z fazy Controls in Action, krok 20: środki kontrolne 8.18 do 8.26.

Daje to praktyczną ścieżkę audytową: traktuj DNS jako zewnętrzną usługę sieciową, dokumentuj sposób jej zabezpieczenia i zapisuj, czy odpowiedzialność znajduje się wewnątrz organizacji, po stronie rejestratora, dostawcy DNS czy MSP.

Zenith Controls: The Cross-Compliance Guide Clarysec Zenith Controls jest przydatny, ponieważ ład DNS rzadko mapuje się wyłącznie do jednego frameworka. Ta sama decyzja dotycząca DNSSEC lub registry lock wspiera dowody dla ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

W odniesieniu do monitorowania dostawców Zenith Controls mapuje środek kontrolny ISO/IEC 27002:2022 5.22, Monitorowanie, przegląd i zarządzanie zmianami usług dostawców, jako kontrolę zapobiegawczą wspierającą poufność, integralność i dostępność. Dla DNS oznacza to, że rejestrator i dostawca DNS nie są dostawcami typu „ustaw i zapomnij”. Ich profil ryzyka w obszarze bezpieczeństwa, zmiany usług, awarie, podwykonawcy przetwarzania i praktyki powiadamiania muszą być przeglądane.

W odniesieniu do DNSSEC i integralności kryptograficznej Zenith Controls mapuje środek kontrolny ISO/IEC 27002:2022 8.24, Stosowanie kryptografii, jako kontrolę zapobiegawczą dostosowaną do bezpiecznej konfiguracji. DNSSEC nie szyfruje ruchu DNS, ale zapewnia kryptograficzne potwierdzenie integralności danych DNS i uwierzytelniania pochodzenia.

W odniesieniu do edycji stref DNS Zenith Controls mapuje środek kontrolny ISO/IEC 27002:2022 8.32, Zarządzanie zmianami, jako kontrolę zapobiegawczą wspierającą poufność, integralność i dostępność. Zmiana DNS jest zmianą konfiguracji. Aktualizacja rekordu DS, zmiana rekordu MX, migracja CNAME, aktualizacja SPF lub DMARC, przełączenie CDN albo zmiana delegowania serwerów nazw powinny mieć zgłoszenie, ocenę ryzyka, zatwierdzenie, wynik testu i plan wycofania zmiany.

DNSSEC, registry lock i zarządzanie kluczami dla domen krytycznych

Nie każda domena ma takie samo ryzyko. Domena defensywna używana wyłącznie w celu zapobiegania podszywaniu się może wymagać monitorowania i dyscypliny odnowień. Główna domena portalu klienta wymaga najsilniejszych dostępnych kontroli.

Dla domen krytycznych Clarysec zwykle rekomenduje następujący zestaw bazowy:

• DNSSEC włączony i zwalidowany tam, gdzie wspierają go rejestr, rejestrator i dostawca DNS
• Rekordy DS przeglądane po każdej migracji dostawcy DNS
• Udokumentowany proces rotacji KSK i ZSK, gdy klucze są zarządzane przez klienta
• Registry lock włączony dla głównych domen produkcyjnych, tożsamości, API, płatności i poczty elektronicznej
• Registrar lock włączony dla wszystkich domen, chyba że udokumentowano czasowy wyjątek
• MFA wymuszony dla wszystkich użytkowników rejestratora i dostawcy DNS
• Użytkownicy uprzywilejowani ograniczeni, imienni, zatwierdzeni i przeglądani
• Dostęp typu „break glass” udokumentowany i przetestowany
• Monitorowanie pliku strefy z alertami dla zmian NS, DS, DNSKEY, MX, TXT, A, AAAA, CNAME, CAA i wildcard
• Monitorowanie zewnętrzne z wielu resolverów DNS i regionów
• Dowody przechowywane w repozytorium SZBI

Enterprise’owa Polityka zabezpieczeń kryptograficznych Clarysec Polityka zabezpieczeń kryptograficznych zapewnia punkt zaczepienia dla ładu nad kluczami DNSSEC:

Należy utrzymywać scentralizowany Rejestr zarządzania kluczami w celu ewidencjonowania wszystkich kluczy kryptograficznych, ich statusu cyklu życia, przypisanych opiekunów i kontekstów użycia.

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.2.

Jeżeli organizacja zarządza kluczami DNSSEC bezpośrednio lub kontroluje publikację DS u rejestratora, Rejestr zarządzania kluczami powinien dokumentować powierzenie kluczy, stan cyklu życia, daty rotacji i uprawnienia do zatwierdzania. Jeżeli kluczami DNSSEC zarządza dostawca DNS, zapis dotyczący dostawcy powinien wyjaśniać tę odpowiedzialność i zawierać dowody zapewnienia.

Nadzór nad dostępem do rejestratora: MFA, zasada najmniejszych uprawnień i kontrola awaryjna

Konta rejestratora są często tworzone na wczesnym etapie życia firmy, a następnie zapominane w miarę dojrzewania organizacji. Założyciele, agencje, programiści, użytkownicy finansowi i MSP mogą nadal mieć historyczny dostęp. To poważna słabość kontroli.

Polityka zarządzania kontami użytkowników i uprawnieniami - MŚP Clarysec Polityka zarządzania kontami użytkowników i uprawnieniami - MŚP stanowi:

Uprawnienia podwyższone lub administracyjne wymagają dodatkowego zatwierdzenia przez Dyrektora Generalnego lub osobę odpowiedzialną za IT oraz muszą być udokumentowane, ograniczone czasowo i podlegać okresowemu przeglądowi.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.2.2.

Zastosuj to dosłownie do dostępu do rejestratora i dostawcy DNS:

• Brak współdzielonych kont administratora rejestratora
• MFA dla każdego użytkownika, najlepiej odporne na phishing tam, gdzie jest dostępne
• Imienne kontakty awaryjne z udokumentowanym upoważnieniem
• Rozdzielenie użytkowników rozliczeniowych od administratorów technicznych tam, gdzie jest to możliwe
• Natychmiastowe usuwanie byłych pracowników, agencji i dostawców
• Kwartalny przegląd dostępu uprzywilejowanego dla domen krytycznych
• Wyjątki rejestrowane wraz z datami wygaśnięcia
• Przetestowane procedury awaryjnego odblokowania i odzyskiwania, które nie powodują niebezpiecznych zmian produkcyjnych

Dowody registry lock powinny obejmować zrzuty ekranu lub potwierdzenia rejestratora pokazujące status włączenia, upoważnione osoby kontaktowe, proces odblokowania i datę ostatniego przeglądu.

Kontrola zmian strefy: małe edycje DNS, duży wpływ biznesowy

Zmiany DNS są pozornie niewielkie. Rekord TXT może potwierdzić własność platformy SaaS. CNAME może przekierować klientów do nowego środowiska. Rekord MX może przekierować pocztę. Rekord CAA może wpływać na wydawanie certyfikatów. Błędny rekord DS może spowodować, że podpisana domena nie przejdzie walidacji.

Polityka zarządzania zmianami - MŚP Clarysec Polityka zarządzania zmianami - MŚP stanowi:

Wszystkie zmiany muszą być zgłaszane jako Wniosek o zmianę (e-mail, formularz lub zgłoszenie w helpdesku).

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1.1.

Dla klientów enterprise Polityka zarządzania zmianami Clarysec Polityka zarządzania zmianami podnosi oczekiwanie dotyczące dowodów:

Wszystkie wnioski o zmianę, przeglądy, zatwierdzenia i dowody wspierające muszą być rejestrowane w scentralizowanym systemie zarządzania zmianami.

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.

Zenith Blueprint wzmacnia to w fazie Controls in Action, krok 21:

Wybierz 2–3 ostatnie zmiany systemowe lub konfiguracyjne i sprawdź, czy zostały obsłużone przez Twoją formalną ścieżkę zarządzania zmianami.

✓ Czy oceniono ryzyka? ✓ Czy zatwierdzenia zostały udokumentowane? ✓ Czy uwzględniono plan wycofania zmian?

Zweryfikuj, czy zmiany wdrożono zgodnie z planem oraz czy odnotowano wszelkie incydenty lub nieoczekiwane skutki. Przejrzyj logi, różnice w systemach kontroli wersji lub ślady audytowe z narzędzi takich jak ServiceNow, Jira lub Git. Ujmij ten proces w podsumowującym rejestrze zapisów zmian jako odniesienie na potrzeby audytu.

Z fazy Controls in Action, krok 21: środki kontrolne 8.27 do 8.34.

Zgłoszenie zmiany specyficzne dla DNS powinno obejmować domenę i strefę, której dotyczy zmiana, typ rekordu, wartości przed i po zmianie, uzasadnienie biznesowe, ocenę ryzyka, okno wdrożeniowe, osobę zatwierdzającą, osobę wdrażającą, osobę weryfikującą, kontrole propagacji DNS, walidację DNSSEC, plan wycofania zmiany, monitorowanie po zmianie i wyeksportowane dowody.

Zasada audytowa jest prosta: zmiany DNS muszą być możliwe do prześledzenia od wniosku, przez zatwierdzenie i wdrożenie, po weryfikację.

Monitorowanie i rejestrowanie: wykryj zmianę DNS, zanim zrobią to klienci

Silny program ładu DNS zakłada, że zapobieganie może zawieść. Monitorowanie musi wykrywać nieoczekiwane zmiany wystarczająco szybko, aby wspierać reagowanie na incydenty.

Polityka bezpieczeństwa sieci - MŚP Clarysec Polityka bezpieczeństwa sieci - MŚP jest jednoznaczna:

Rejestrowanie DNS musi być włączone w celu wspierania threat huntingu i reagowania na incydenty

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.6.3.

Enterprise’owa Polityka rejestrowania i monitorowania Clarysec Polityka rejestrowania i monitorowania wychodzi z tego samego oczekiwania operacyjnego:

Wszystkie systemy objęte zakresem muszą generować logi obejmujące:

Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.

W przypadku ładu DNS i nadzoru nad rejestratorem systemy objęte zakresem powinny obejmować portale rejestratora, konsole hostingu DNS, zarządzanie DNS oparte na API, potoki CI/CD wdrażające DNS jako kod, alerty SIEM i zewnętrzne narzędzia monitorujące.

Monitorowanie powinno być zintegrowane z reagowaniem na incydenty. Alert DNS bez właściciela, oceny wagi lub podręcznika operacyjnego jest tylko szumem.

NIS2, DORA i GDPR: ład DNS jako dowód regulacyjny

NIS2 Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych do zarządzania ryzykami dla sieci i systemów informatycznych oraz minimalizacji wpływu incydentów. Ład DNS naturalnie mapuje się na zarządzanie aktywami, kontrolę dostępu, kryptografię, bezpieczeństwo łańcucha dostaw, obsługę incydentów, ciągłość działania i ocenę skuteczności.

NIS2 Article 20 czyni również cyberbezpieczeństwo odpowiedzialnością organu zarządzającego. Rady nadzorcze i zarządy nie muszą zatwierdzać każdego rekordu TXT, ale powinny rozumieć, czy domeny krytyczne są chronione przez DNSSEC, registry lock, MFA, monitorowanie i przetestowane odzyskiwanie. Dla istotnych incydentów NIS2 Article 23 wprowadza etapowe zgłaszanie, w tym wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin oraz raport końcowy nie później niż miesiąc po zgłoszeniu incydentu.

W przypadku regulowanych podmiotów finansowych DORA stosuje się od 17 stycznia 2025 r. i działa jako sektorowe ramy odporności ICT tam, gdzie nakłada się na NIS2. DNS często wspiera funkcje krytyczne lub istotne, takie jak aplikacje płatnicze, bankowość mobilna, portale transakcyjne, tożsamość klienta, systemy zapobiegania oszustwom, bramy API i integracje ze stronami trzecimi. Dowody DORA powinny pokazywać mapowanie zależności aktywów ICT, klasyfikację incydentów, testowanie odporności, zarządzanie ryzykiem stron trzecich i planowanie odzyskiwania dla scenariuszy awarii DNS i rejestratora.

Incydent DNS nie jest automatycznie naruszeniem ochrony danych osobowych w rozumieniu GDPR. Może się nim stać, jeżeli użytkownicy zostaną przekierowani do strony phishingowej, poświadczenia zostaną pozyskane, poczta elektroniczna zawierająca dane osobowe zostanie przekierowana, ruch do systemów przetwarzających dane osobowe zostanie przechwycony albo dostępność danych osobowych zostanie istotnie naruszona. GDPR Article 5 wymaga integralności, poufności i rozliczalności. Article 32 wymaga odpowiednich środków bezpieczeństwa przetwarzania. Ład DNS dostarcza dowodów, że routowanie domen i usługi zależne od DNS są chronione proporcjonalnymi środkami technicznymi i organizacyjnymi.

Zbuduj pakiet dowodów DNS w tydzień

Praktyczny plan działań naprawczych w zakresie ładu DNS można zrealizować szybko, jeśli jest prowadzony w oparciu o dowody.

Dzień 1: Utwórz rejestr domen i usług DNS

Zacznij od wymagania Polityki zarządzania aktywami - MŚP, aby dokumentować własność, cel, uprawnienia dostępu i terminy odnowienia.

Dzień 2: Przejrzyj dostęp i uprawnienia

Wyeksportuj użytkowników rejestratora i dostawcy DNS. Usuń nieaktualne konta. Wymuś MFA. Zidentyfikuj administratorów. Zarejestruj dowody zatwierdzenia dla użytkowników uprzywilejowanych i udokumentuj dostęp awaryjny.

Dzień 3: Zweryfikuj DNSSEC i blokady

Dla każdej domeny krytycznej zweryfikuj walidację łańcucha DNSSEC, poprawność rekordu DS, widoczność DNSKEY, registrar lock i registry lock. Jeżeli DNSSEC jest zarządzany przez dostawcę, udokumentuj odpowiedzialność dostawcy. Jeżeli jest zarządzany przez klienta, dodaj klucze DNSSEC i opiekunów do Rejestru zarządzania kluczami.

Dzień 4: Przekształć zmiany DNS w formalne zapisy zmian

Wybierz trzy ostatnie zmiany DNS i sprawdź je względem kryteriów Zenith Blueprint krok 21: czy oceniono ryzyko, udokumentowano zatwierdzenie, uwzględniono plan wycofania, wdrożono zgodnie z planem oraz zapisano nieoczekiwany wpływ. Utwórz podsumowujący rejestr zapisów zmian.

Dzień 5: Połącz monitorowanie z reagowaniem na incydenty

Potwierdź logi i alerty dla logowania do rejestratora, zmian strefy, zmian DNSSEC, zmian NS, zmian MX, zmian TXT, zmian CAA i powiadomień dostawcy. Wyślij alerty testowe do SOC lub właściciela IT. Dołącz dowody do repozytorium SZBI.

Dzień 6: Przejrzyj obowiązki dostawców

Wykorzystaj wytyczne Zenith Blueprint krok 23 dotyczące procedur zmian i monitorowania dostawców:

Ustanów prostą, skalowalną procedurę oceny zmian usług dostawców (5.21), takich jak migracja do chmury obliczeniowej, nowi podwykonawcy przetwarzania lub przebudowa infrastruktury. Zdefiniuj wyzwalacze, które wymagają ponownej oceny bezpieczeństwa. Następnie wdroż powtarzalny cykl monitorowania dostawców (5.22), przypisując właścicieli do dostawców krytycznych oraz zapewniając, że wyniki, zgodność i ryzyka są przeglądane co najmniej raz w roku.

Z fazy Controls in Action, krok 23: środki organizacyjne 5.19 do 5.37.

Enterprise’owa Polityka bezpieczeństwa dostawców i stron trzecich Clarysec Polityka bezpieczeństwa dostawców i stron trzecich zapewnia umowne umocowanie:

Umowy z dostawcami muszą zawierać:

Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.

Dzień 7: Przeprowadź ćwiczenie typu tabletop

Zasymuluj nieuprawnioną zmianę rekordu NS. Zespół musi ją wykryć, sklasyfikować, eskalować, skontaktować się z rejestratorem, w razie potrzeby uruchomić procedury registry lock, przywrócić prawidłową delegację, zwalidować DNSSEC, powiadomić interesariuszy, ocenić wpływ na GDPR i zdecydować, czy progi raportowania NIS2 lub DORA zostały spełnione. Zapisz wnioski i zaktualizuj procedury.

Pytania audytowe, typowe ustalenia i wskaźniki dla zarządu

Audyt ładu DNS rzadko jest prowadzony wyłącznie z jednej perspektywy.

Najczęstsze ustalenia są przewidywalne.

Zarządy i zespoły kierownicze potrzebują wskaźników DNS sformułowanych językiem odporności. Przydatne miary obejmują odsetek domen krytycznych z włączonym i zwalidowanym DNSSEC, odsetek domen z registry lock, liczbę administratorów rejestratora, odsetek użytkowników uprzywilejowanych poddanych przeglądowi w ostatnim kwartale, liczbę zmian DNS wdrożonych bez formalnych zgłoszeń, średni czas wykrycia nieuprawnionej zmiany DNS, średni czas przywrócenia prawidłowej konfiguracji DNS, domeny wygasające w ciągu 90 dni, ukończone przeglądy dostawców oraz nierozwiązane alerty monitorowania DNS.

Przekształć DNS z ukrytego ryzyka w dowody gotowe do audytu

Jeżeli Twoja organizacja nie przeglądała ładu nad domenami i DNS w ostatnich sześciu miesiącach, załóż, że wystąpił dryf. Zacznij od krytycznych domen produkcyjnych, a następnie rozszerz zakres na domeny regionalne, domeny defensywne, domeny testowe, domeny przejęte w akwizycjach oraz domeny zarządzane przez agencje lub spółki zależne.

Clarysec może pomóc przejść od rozproszonych zrzutów ekranu z rejestratora do ustrukturyzowanego pakietu dowodów, wykorzystując:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint do krokowej walidacji usług sieciowych, zarządzania zmianami, rejestrowania, monitorowania i kontroli dostawców
• Zenith Controls: The Cross-Compliance Guide Zenith Controls do mapowania DNSSEC, registry lock, monitorowania dostawców i ładu nad zmianami stref w perspektywach ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST i COBIT 2019
• Szablony polityk Clarysec, w tym Polityka zarządzania aktywami - MŚP, Polityka zarządzania zmianami - MŚP, Polityka zarządzania kontami użytkowników i uprawnieniami - MŚP, Polityka bezpieczeństwa sieci - MŚP, Polityka zarządzania aktywami, Polityka zarządzania zmianami, Polityka rejestrowania i monitorowania, Polityka zabezpieczeń kryptograficznych oraz Polityka bezpieczeństwa dostawców i stron trzecich

Twoja domena jest głównym wejściem do cyfrowej działalności. W 2026 r. audytorzy, regulatorzy, klienci i zarządy będą oczekiwać wykazania, że to wejście jest zamknięte, monitorowane, możliwe do odtworzenia i objęte nadzorem.

Pobierz zestaw narzędzi Clarysec, przeprowadź tygodniowe ćwiczenie budowy pakietu dowodów DNS albo zarezerwuj ocenę Clarysec, aby przekształcić ład DNS i nadzór nad rejestratorem w dowód gotowy do audytu, zanim nadejdzie Twój własny poniedziałkowy kryzys.