Управление на DNS през 2026 г.: контроли при регистратора, готови за одит

В 07:42 в понеделник сутрин CISO на бързоразвиваща се финтех компания получава съобщението, което никой не иска да види. Клиентите нямат достъп до платежния портал, системата за обслужване на заявки е претоварена, електронната поща не работи, а SOC не открива нито зловреден софтуер, нито отказ на защитна стена, нито инцидент при доставчик на облачни услуги.

Първопричината е по-тиха и по-неудобна. Достъп до акаунт при регистратора е осъществен чрез остарели администраторски удостоверителни данни, споделяни от няколко бивши ИТ служители. Нападателят е променил авторитативните сървъри за имена, модифицирал е MX записите, деактивирал е DNSSEC и е пренасочил трафика достатъчно дълго, за да събере удостоверителни данни и да наруши работата на партньорски API. Платежният портал не е бил компрометиран в традиционния смисъл. Компрометирана е била котвата на доверие на дружеството — неговият домейн.

Към 09:30 оперативната криза вече е криза на съответствието. Ръководният орган пита дали registry lock е бил активиран. Правният отдел пита дали са били експонирани лични данни. DPO пита дали това е нарушение на сигурността на личните данни по GDPR. Регулаторът иска да знае дали е засегната критична или важна функция. Клиентски одитор изисква заявката за промяна, с която е одобрена DNS модификацията.

В твърде много организации отговорът е електронна таблица, споделена пощенска кутия и конзола на регистратора, която никой не е преглеждал от шест месеца.

Управлението на DNS и регистраторите на домейни през 2026 г. вече не е нишова инфраструктурна тема. То е част от устойчивостта срещу ransomware, предотвратяването на фишинг, наличността на облачни услуги, управлението на риска от доставчици, реагирането при инциденти, непрекъсваемостта на дейността и съответствието, основано на доказателства. Ако домейнът ви може да бъде отвлечен, вашата SaaS платформа може да изчезне. Ако DNS записите ви могат да бъдат променяни без одобрение, сигурността на електронната поща, SSO, TLS сертификатите, API крайните точки и доверието на клиентите могат да бъдат подкопани за минути.

Защо управлението на DNS и регистратора принадлежи към ISMS

Името на домейн не е просто бранд актив. То е логически актив, зависимост за автентикация, зависимост за маршрутизация и често услуга, управлявана от доставчик. То свързва доставчици на идентичност, автентикация на електронна поща, валидиране на TLS сертификати, облачни крайни точки, клиентски портали, API, CDN услуги, мониторингови сонди и комуникации при инциденти.

Политиката за управление на активите - SME на Clarysec Политика за управление на активите - SME посочва това изрично в своя обхват:

Цифрови удостоверителни данни и услуги: имена на домейни, цифрови сертификати, API ключове, имейл акаунти, облачни входове

От раздел „Обхват“, клауза 2.2.4 на политиката.

Същата политика изисква повече от изброяване на името на домейна:

Собствеността, целта, привилегиите за достъп и сроковете за подновяване трябва да бъдат документирани.

От раздел „Изисквания за внедряване на политиката“, клауза 6.6.2 на политиката.

За корпоративни среди Политиката за управление на активите на Clarysec Политика за управление на активите също включва логически активи в обхвата:

Логически активи: имена на домейни, лицензи, потребителски акаунти, базови конфигурации

От раздел „Обхват“, клауза 2.2.5 на политиката.

Това е отправната точка на управлението. Инвентарът на DNS и регистратора трябва да документира:

• Име на домейн, регистър, регистратор, доставчик на DNS хостинг и авторитативни сървъри за имена
• Бизнес собственик, технически собственик, собственик по сигурността и одобряващ при извънредна ситуация
• Цел, например продукционен портал, API, електронна поща, SSO, маркетинг, тестова среда или защитна регистрация
• Оценка на критичността и картографиране на зависимостите към бизнес услуги
• Статус на DNSSEC, статус на DS запис, собственост върху ключовете и процес за ротация на ключове
• Статус на registry lock и registrar lock
• Модел за MFA и привилегирован достъп за акаунти при регистратора и DNS доставчика
• Дата на подновяване, статус на автоматично подновяване, собственик на плащането и предупреждения за изтичане
• Изисквания за контрол на промените при редакции на зони и промени в делегирането
• Регистриране, предупреждения, мониторинг и съхранение на доказателства

Затова управлението на домейни трябва да присъства в обхвата на ISO/IEC 27001:2022 ISMS и в оценката на риска. ISO/IEC 27001:2022 изисква организациите да определят контекста, изискванията на заинтересованите страни, правните и договорните задължения, интерфейсите и зависимостите с външни организации. DNS зависи от регистратори, регистри, доставчици на DNS хостинг, доставчици на облачни услуги, удостоверителни органи (CA), доставчици на управлявани услуги (MSP) и понякога маркетингови агенции. Ако тези интерфейси са изключени от ISMS, одитната следа ще бъде непълна.

Моделът на DNS заплахите през 2026 г.

Най-вредните DNS откази често са прости:

1. Домейн изтича, защото собствеността върху подновяването не е била ясно определена.
2. Бивша агенция все още има достъп до акаунт при регистратора.
3. DNSSEC е активиран, но DS записите са грешни след миграция към друг DNS доставчик.
4. Wildcard запис насочва трафик към изоставена облачна услуга.
5. TXT запис е променен, за да валидира SaaS среда или заявка за сертификат под контрол на нападател.
6. MX записи са модифицирани по време на фишинг кампания или кампания за прихващане на електронна поща.
7. CNAME към платформа на трета страна става уязвим за превземане.
8. Registry lock съществува за основния домейн, но не и за клиентски домейни с национален код.
9. SOC наблюдава крайни точки, но никой не наблюдава промените във файловете на зоните.

Техническите предпазни мерки са добре известни. DNSSEC помага за защита на целостта на DNS данните и автентикация на произхода. Registry lock изисква допълнителна извънканална проверка за високорискови промени на ниво регистър. Registrar lock намалява риска от неоторизиран трансфер. MFA и прегледите на привилегирован достъп намаляват вероятността от превземане на акаунт. Контролът на промените предотвратява случайни прекъсвания. Мониторингът открива неоторизирани или неочаквани промени.

Предизвикателството за съответствието е различно: можете ли да докажете, че тези предпазни мерки съществуват, имат определени собственици, преглеждат се и работят по време на инцидент?

Именно при този въпрос за доказателствата много организации се провалят.

Картографиране на управлението на DNS към ISO/IEC 27001:2022 и ISO/IEC 27002:2022

ISO/IEC 27001:2022 предоставя структурата на системата за управление, чрез която DNS контролите се превръщат в повторяеми и одитируеми процеси. Приложение A към ISO/IEC 27001:2022 и указанията за контроли в ISO/IEC 27002:2022 дават езика на контролите, който одиторите очакват.

Zenith Blueprint: 30-стъпкова пътна карта за одитора на Clarysec Zenith Blueprint третира мрежовите услуги като изрични обекти на одит. В етапа Controls in Action, стъпка 20, той инструктира екипите да валидират сигурността на мрежовите услуги:

Избройте всички вътрешни и външни мрежови услуги (DNS, VPN, SMTP, DHCP, API шлюзове, и др.).

✓ За всяка потвърдете, че използва сигурни протоколи (напр. DNSSEC, TLS 1.2+, SSH вместо Telnet). ✓ Прегледайте как се контролира достъпът до всяка услуга (напр. списъци с разрешени IP адреси, автентикация, сертификати). ✓ Ако се управлява от трети страни (напр. DNS, SD-WAN, хостван VPN), прегледайте клаузите за сигурност в SLA или договора с доставчика. Актуализирайте своя Регистър на услугите и отбележете къде се намират отговорностите по сигурността — вътрешно или външно.

От етапа Controls in Action, стъпка 20: Контроли 8.18 до 8.26.

Това дава практически одитен подход: третирайте DNS като външна мрежова услуга, документирайте как е защитена и запишете дали отговорността е вътрешна, при регистратора, при DNS доставчика или при MSP.

Zenith Controls: Междурегулаторно ръководство за съответствие на Clarysec Zenith Controls е полезно, защото управлението на DNS рядко се картографира само към една рамка. Едно и също решение за DNSSEC или registry lock подкрепя доказателства по ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 и COBIT 2019.

За мониторинг на доставчици Zenith Controls картографира контрол 5.22 от ISO/IEC 27002:2022, „Мониторинг, преглед и управление на промените в услугите на доставчици“, като превантивен контрол, подкрепящ поверителност, цялостност и наличност. За DNS това означава, че регистраторът и DNS доставчикът не са доставчици от типа „настрой и забрави“. Тяхната позиция по отношение на риска за сигурността, промените в услугите, прекъсванията, подизпълнителите по обработване и практиките за уведомяване трябва да бъдат преглеждани.

За DNSSEC и криптографската цялост Zenith Controls картографира контрол 8.24 от ISO/IEC 27002:2022, „Използване на криптография“, като превантивен контрол, съгласуван със сигурна конфигурация. DNSSEC не е криптиране на DNS трафика, но предоставя криптографско уверение за целостта на DNS данните и автентикацията на произхода.

За редакции на DNS зони Zenith Controls картографира контрол 8.32 от ISO/IEC 27002:2022, „Управление на промените“, като превантивен контрол, подкрепящ поверителност, цялостност и наличност. DNS промяната е конфигурационна промяна. Актуализация на DS запис, промяна на MX запис, миграция на CNAME, актуализация на SPF или DMARC, прехвърляне към CDN или промяна в делегирането на сървър за имена трябва да имат заявка, оценка на риска, одобрение, резултат от тест и план за връщане назад.

DNSSEC, registry lock и управление на ключове за критични домейни

Не всеки домейн има еднакъв риск. Защитен домейн, използван само за предотвратяване на имитиране на организацията, може да се нуждае от мониторинг и дисциплина при подновяване. Основният домейн на клиентски портал изисква най-силните налични контроли.

За критични домейни Clarysec обичайно препоръчва следния базов набор:

• DNSSEC е активиран и валидиран, когато се поддържа от регистъра, регистратора и DNS доставчика
• DS записите се преглеждат след всяка миграция на DNS доставчик
• Документиран процес за ротация на KSK и ZSK, когато ключовете се управляват от клиента
• Registry lock е активиран за основните продукционни, идентификационни, API, платежни и имейл домейни
• Registrar lock е активиран за всички домейни, освен ако не е документирано временно изключение
• MFA се прилага за всички потребители на регистратора и DNS доставчика
• Привилегированите потребители са ограничени, именувани, одобрени и преглеждани
• Аварийният достъп е документиран и тестван
• Мониторинг на файловете на зоните с предупреждения за промени в NS, DS, DNSKEY, MX, TXT, A, AAAA, CNAME, CAA и wildcard записи
• Външен мониторинг от множество резолвери и региони
• Доказателствата се съхраняват в хранилището на ISMS

Корпоративната Политика за криптографски контроли на Clarysec Политика за криптографски контроли предоставя управленската връзка за DNSSEC ключове:

Трябва да се поддържа централизиран Регистър за управление на ключове, за да се записват всички криптографски ключове, техният статус в жизнения цикъл, определените попечители и контекстите на използване.

От раздел „Изисквания за управление“, клауза 5.2 на политиката.

Ако вашата организация управлява DNSSEC ключове директно или контролира публикуването на DS при регистратора, Регистърът за управление на ключове трябва да документира попечителство, състояние в жизнения цикъл, дати за ротация и правомощия за одобрение. Ако DNS доставчикът управлява DNSSEC ключовете, записът за доставчика трябва да обяснява тази отговорност и да включва доказателства за уверение.

Управление на достъпа до регистратора: MFA, минимално необходим достъп и авариен контрол

Акаунтите при регистратора често се създават в ранния етап от живота на компанията и след това се забравят с нейното развитие. Основатели, агенции, разработчици, финансови потребители и MSP могат да имат исторически достъп. Това е сериозна слабост в контрола.

Политиката за управление на потребителски акаунти и привилегии - SME на Clarysec Политика за управление на потребителски акаунти и привилегии - SME посочва:

Повишените или административни привилегии изискват допълнително одобрение от Управителя или ИТ ръководителя и трябва да бъдат документирани, времево ограничени и подложени на периодичен преглед.

От раздел „Изисквания за внедряване на политиката“, клауза 6.2.2 на политиката.

Приложете това директно към достъпа до регистратора и DNS доставчика:

• Не се допускат споделени администраторски акаунти при регистратора
• MFA за всеки потребител, за предпочитане с устойчивост на фишинг, когато се поддържа
• Именувани аварийни контакти с документирани правомощия
• Разделяне на потребителите за фактуриране от техническите администратори, когато е възможно
• Незабавно премахване на бивши служители, агенции и доставчици
• Тримесечен преглед на привилегирования достъп за критични домейни
• Изключения, записани със срокове на изтичане
• Тествани процедури за аварийно отключване и възстановяване, които не създават небезопасни промени в продукционна среда

Доказателствата за registry lock трябва да включват екранни снимки или удостоверения от регистратора, показващи активиран статус, оторизирани контакти, процес за отключване и дата на последния преглед.

Контрол на промените в зони: малки DNS редакции, голямо бизнес въздействие

DNS промените изглеждат измамно малки. TXT запис може да валидира собственост върху SaaS платформа. CNAME може да пренасочи клиенти към нова среда. MX запис може да пренасочи електронната поща. CAA запис може да повлияе върху издаването на сертификати. Грешен DS запис може да доведе до отказ при валидиране на подписан домейн.

Политиката за управление на промените - SME на Clarysec Политика за управление на промените - SME посочва:

Всички промени трябва да се подават като заявка за промяна (електронна поща, формуляр или helpdesk билет).

От раздел „Изисквания за управление“, клауза 5.1.1 на политиката.

За корпоративни клиенти Политиката за управление на промените на Clarysec Политика за управление на промените повишава очакването за доказателства:

Всички заявки за промяна, прегледи, одобрения и подкрепящи доказателства трябва да бъдат записани в централизираната Система за управление на промените.

От раздел „Изисквания за внедряване на политиката“, клауза 6.1.1 на политиката.

Zenith Blueprint затвърждава това в етапа Controls in Action, стъпка 21:

Изберете 2–3 скорошни системни или конфигурационни промени и проверете дали са били обработени чрез вашия формален работен процес по управление на промените.

✓ Оценени ли са рисковете? ✓ Документирани ли са одобренията? ✓ Включен ли е план за връщане назад?

Валидирайте, че промените са внедрени според плана и че всички инциденти или неочаквани въздействия са записани. Прегледайте журнали, разлики от управление на версиите или одитни следи от инструменти като ServiceNow, Jira или Git. Запишете този процес в обобщаващ журнал на записите за промени за справка при одит.

От етапа Controls in Action, стъпка 21: Контроли 8.27 до 8.34.

Специфичната за DNS заявка за промяна трябва да включва засегнатия домейн и зона, тип запис, стойности преди и след промяната, бизнес основание, оценка на риска, прозорец за внедряване, одобряващ, изпълнител, проверяващ, проверки на DNS пропагацията, валидиране на DNSSEC, план за връщане назад, мониторинг след промяната и експортирани доказателства.

Одитният принцип е прост: DNS промените трябва да бъдат проследими от заявка през одобрение и внедряване до проверка.

Мониторинг и регистриране: открийте DNS промяната преди клиентите

Силната програма за управление на DNS приема, че превенцията може да се провали. Мониторингът трябва да открива неочаквана промяна достатъчно бързо, за да подпомогне реагирането при инциденти.

Политиката за мрежова сигурност - SME на Clarysec Политика за мрежова сигурност - SME е категорична:

DNS регистрирането трябва да бъде активирано, за да подпомага лов на заплахи и реагиране при инциденти

От раздел „Изисквания за внедряване на политиката“, клауза 6.6.3 на политиката.

Корпоративната Политика за регистриране и мониторинг Политика за регистриране и мониторинг започва от същото оперативно очакване:

Всички обхванати системи трябва да генерират журнали, които улавят:

От раздел „Изисквания за внедряване на политиката“, клауза 6.1.1 на политиката.

За управление на DNS и регистратора обхванатите системи трябва да включват портали на регистратори, конзоли за DNS хостинг, API-базирано управление на DNS, CI/CD конвейери, които внедряват DNS като код, SIEM предупреждения и външни инструменти за мониторинг.

Мониторингът трябва да бъде интегриран в реагирането при инциденти. DNS предупреждение без собственик, степен на сериозност или наръчник е само шум.

NIS2, DORA и GDPR: управлението на DNS като регулаторно доказателство

NIS2 Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки за управление на рисковете за мрежовите и информационните системи и за минимизиране на въздействието от инциденти. Управлението на DNS естествено се картографира към управление на активите, контрол на достъпа, криптография, сигурност на веригата на доставки, обработване на инциденти, непрекъсваемост на дейността и оценка на ефективността.

NIS2 Article 20 също прави киберсигурността отговорност на ръководния орган. Ръководните органи не трябва да одобряват всеки TXT запис, но трябва да разбират дали критичните домейни са защитени чрез DNSSEC, registry lock, MFA, мониторинг и тествано възстановяване. За значими инциденти NIS2 Article 23 въвежда поетапно докладване, включително ранно предупреждение в рамките на 24 часа, уведомяване за инцидент в рамките на 72 часа и окончателен доклад не по-късно от един месец след уведомяването за инцидента.

За регулирани финансови субекти DORA се прилага от 17 януари 2025 г. и действа като секторната рамка за ИКТ устойчивост там, където се припокрива с NIS2. DNS често поддържа критични или важни функции като платежни приложения, мобилно банкиране, търговски портали, клиентска идентичност, системи за предотвратяване на измами, API шлюзове и интеграции с трети страни. Доказателствата по DORA трябва да показват картографиране на зависимостите между ИКТ активите, класификация на инцидентите, тестване на устойчивостта, управление на риска от трети страни и планиране на възстановяването за сценарии на отказ на DNS и регистратора.

DNS инцидентът не е автоматично нарушение на сигурността на личните данни по GDPR. Той може да стане такъв, ако потребителите бъдат пренасочени към фишинг сайт, бъдат събрани удостоверителни данни, електронна поща, съдържаща лични данни, бъде пренасочена, трафик към системи за обработване на лични данни бъде прихванат или наличността на лични данни бъде съществено засегната. GDPR Article 5 изисква цялостност, поверителност и отчетност. Article 32 изисква подходящи мерки за сигурност при обработването. Управлението на DNS предоставя доказателства, че маршрутизацията на домейни и зависимите от DNS услуги са защитени с пропорционални технически и организационни мерки.

Изградете пакет с DNS доказателства за една седмица

Практически план за ремедиация на управлението на DNS може да бъде изпълнен бързо, ако е основан на доказателства.

Ден 1: Създайте регистър на домейните и DNS услугите

Започнете от изискването на Политиката за управление на активите - SME да се документират собственост, цел, привилегии за достъп и срокове за подновяване.

Ден 2: Прегледайте достъпа и привилегиите

Експортирайте потребителите на регистратора и DNS доставчика. Премахнете остарели акаунти. Наложете MFA. Идентифицирайте администраторите. Запишете доказателства за одобрение на привилегировани потребители и документирайте аварийния достъп.

Ден 3: Валидирайте DNSSEC и заключванията

За всеки критичен домейн проверете валидирането на DNSSEC веригата, точността на DS записите, видимостта на DNSKEY, registrar lock и registry lock. Ако DNSSEC се управлява от доставчика, документирайте отговорността на доставчика. Ако се управлява от клиента, добавете DNSSEC ключовете и попечителите в Регистъра за управление на ключове.

Ден 4: Превърнете DNS промените във формални записи за промени

Изберете последните три DNS промени и ги тествайте спрямо критериите от Zenith Blueprint, стъпка 21: оценен риск, документирано одобрение, включен план за връщане назад, внедряване според плана и записано неочаквано въздействие. Създайте обобщаващ журнал на записите за промени.

Ден 5: Свържете мониторинга с реагирането при инциденти

Потвърдете журналите и предупрежденията за вход при регистратора, промени в зони, DNSSEC промени, NS промени, MX промени, TXT промени, CAA промени и уведомления от доставчика. Изпратете тестови предупреждения до SOC или ИТ собственика. Прикачете доказателствата към хранилището на ISMS.

Ден 6: Прегледайте задълженията на доставчиците

Използвайте указанията от Zenith Blueprint, стъпка 23, за процедури при промени и мониторинг на доставчици:

Установете проста и мащабируема процедура за оценяване на промени в услугите на доставчици (5.21), като миграция към облак, нови подизпълнители по обработване или редизайн на инфраструктурата. Определете тригери, които изискват повторна оценка на сигурността. След това внедрете повтарящ се ритъм за мониторинг на доставчици (5.22), като възложите собственици на критичните доставчици и гарантирате, че резултатността, съответствието и рисковете се преглеждат най-малко ежегодно.

От етапа Controls in Action, стъпка 23: Организационни контроли 5.19 до 5.37.

Корпоративната Политика за сигурност на трети страни и доставчици на Clarysec Политика за сигурност на трети страни и доставчици предоставя договорната основа:

Договорите с доставчици трябва да включват:

От раздел „Изисквания за управление“, клауза 5.3 на политиката.

Ден 7: Проведете настолно упражнение

Симулирайте неоторизирана промяна на NS запис. Екипът трябва да я открие, класифицира, ескалира, да се свърже с регистратора, да задейства процедури за registry lock при необходимост, да възстанови правилното делегиране, да валидира DNSSEC, да уведоми заинтересованите страни, да оцени въздействието по GDPR и да реши дали са достигнати праговете за докладване по NIS2 или DORA. Запишете извлечените поуки и актуализирайте процедурите.

Одитни въпроси, чести констатации и показатели за ръководния орган

Одитът на управлението на DNS рядко се извършва само през една перспектива.

Най-честите констатации са предвидими.

Ръководните органи и управленските екипи се нуждаят от DNS показатели, формулирани на езика на устойчивостта. Полезни мерки включват процент на критичните домейни с активиран и валидиран DNSSEC, процент с registry lock, брой администратори при регистратора, процент на привилегированите потребители, прегледани през последното тримесечие, брой DNS промени, внедрени без формални заявки, средно време до откриване на неоторизирана DNS промяна, средно време до възстановяване на правилната DNS конфигурация, домейни с изтичане в рамките на 90 дни, завършени прегледи на доставчици и неразрешени предупреждения от DNS мониторинг.

Превърнете DNS от скрит риск в доказателства, готови за одит

Ако организацията ви не е преглеждала управлението на домейни и DNS през последните шест месеца, приемете, че има отклонение. Започнете с критичните продукционни домейни, след това разширете към регионални домейни, защитни домейни, тестови домейни, домейни от придобивания и домейни, управлявани от агенции или дъщерни дружества.

Clarysec може да ви помогне да преминете от разпръснати екранни снимки от регистратора към структуриран пакет от доказателства чрез:

• Zenith Blueprint: 30-стъпкова пътна карта за одитора Zenith Blueprint за поетапно валидиране на мрежови услуги, управление на промените, регистриране, мониторинг и контроли за доставчици
• Zenith Controls: Междурегулаторно ръководство за съответствие Zenith Controls за картографиране на DNSSEC, registry lock, мониторинг на доставчици и управление на промените в зони през перспективите на ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST и COBIT 2019
• Шаблони за политики на Clarysec, включително Политика за управление на активите - SME, Политика за управление на промените - SME, Политика за управление на потребителски акаунти и привилегии - SME, Политика за мрежова сигурност - SME, Политика за управление на активите, Политика за управление на промените, Политика за регистриране и мониторинг, Политика за криптографски контроли и Политика за сигурност на трети страни и доставчици

Вашият домейн е входната врата към вашия цифров бизнес. През 2026 г. одитори, регулатори, клиенти и ръководни органи ще очакват да докажете, че тази входна врата е заключена, наблюдавана, възстановима и управлявана.

Изтеглете инструментариума на Clarysec, изпълнете едноседмичното упражнение за пакет с DNS доказателства или резервирайте оценка от Clarysec, за да превърнете управлението на DNS и регистратора в доказателства, готови за одит, преди собствената ви криза в понеделник сутрин.