Доказателства за укрепване на Active Directory за одити през 2026 г.

Предупреждението пристигна в 2:17 ч. през нощта. Акаунт с високи привилегии, неактивен от шест месеца, току-що беше променил критичен обект на групова политика. Почти по същото време SOC отчете множество неуспешни опити за предварителна автентикация в Kerberos от подмрежа на работни станции. Пет минути по-късно Active Directory Certificate Services издаде сертификат за акаунт, който никога не би трябвало да е заявявал такъв.

Мария, директор „Информационна сигурност“ (CISO) на средноголяма финтех компания, знаеше какво означава това. Организацията не беше просто открила подозрителна дейност. Тя беше открила възможна атака срещу слоя за управление на идентичности.

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

„Как се случи това?“ попита главният изпълнителен директор. „Можем ли да докажем на регулаторите и клиентите си, че ключовете към кралството действително са под контрол?“

Този въпрос определя укрепването на Active Directory през 2026 г. За много организации локална или хибридна Active Directory все още поддържа достъп до файлове, ERP системи, VPN, платформи за резервно копиране, Windows сървъри, привилегировано администриране, наследени приложения, автентикация чрез Kerberos и синхронизация с Entra ID. Ако AD бъде компрометирана, бизнесът не губи само автентикация. Той губи контрол.

Регулаторите и одиторите вече разбират това. Съгласно NIS2 управителните органи трябва да одобряват мерките за управление на риска в киберсигурността и могат да носят отговорност при нарушения. Съгласно DORA финансовите субекти трябва да управляват ИКТ риска чрез документирано управление, защита, откриване, реагиране и възстановяване. Съгласно GDPR организациите трябва да защитават личните данни чрез подходящи технически и организационни мерки и да могат да доказват отчетност. Съгласно ISO/IEC 27001:2022 рисковете, свързани с Active Directory, трябва да бъдат включени в обхвата, оценени, третирани, наблюдавани и подкрепени с доказателства.

Отговорът не е поредният неуправляем контролен списък. Отговорът е защитим доказателствен модел, който свързва домейн контролерите, Kerberos, Group Policy, AD CS, привилегирования достъп, регистрирането и възстановяването със СУИС, регистъра на рисковете, Декларацията за приложимост, рамката от политики и одитната следа.

Защо Active Directory все още е риск на ниво управителен орган

Повечето компрометирания на Active Directory не са екзотични. Обикновено те комбинират прекомерни привилегии, остарели акаунти, слаба хигиена на служебните акаунти, прекалено разрешителни настройки на Group Policy, несигурно делегиране, лоша конфигурация на Kerberos, рискови шаблони за сертификати, необновени домейн контролери, непълен мониторинг и резервни копия, които никога не са възстановявани тестово.

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

ISO/IEC 27001:2022 превръща това в управленски въпрос, преди да стане технически въпрос. Клаузи 4.1 до 4.4 изискват организацията да дефинира контекста, заинтересованите страни, изискванията, обхвата и процесите на СУИС. За хибридна среда за идентичности обхватът трябва изрично да включва домейн контролери, AD CS, привилегировани администраторски работни станции, системи за резервно копиране, сървъри за синхронизация на идентичности, доставчици на управлявани услуги и зависимости от облачни идентичности.

Клаузи 5.1 до 5.3 възлагат на ръководството отчетност за политиките, ресурсите, ролите и докладването. Почистването на Domain Admins не е само инфраструктурна задача. То е управленски подкрепено решение за третиране на риска.

Клаузи 6.1.1 до 6.1.3 изискват повторяем процес за оценка и третиране на риска, включително Декларацията за приложимост. Именно там укрепването на Active Directory става одитируемо.

[ZB] Zenith Blueprint: 30-стъпкова пътна карта за одитора Zenith Blueprint описва това във фазата „Управление на риска“, стъпка 13, „Планиране на третиране на риска и Декларация за приложимост“:

SoA на практика е свързващ документ: той свързва вашата оценка/третиране на риска с реалните контроли, с които разполагате. Като го попълните, също така проверявате повторно дали не сте пропуснали контроли.

За Active Directory тази връзка е критична. Риск като „компрометиране на привилегировани акаунти в AD, водещо до разпространение на ransomware и неоторизиран достъп до лични данни“ може да бъде съпоставен с привилегирован достъп, сигурна автентикация, управление на конфигурацията, регистриране, мониторинг, резервно копиране, реагиране при инциденти и криптографски контроли. След това SoA може да обясни защо всеки контрол е приложим, кои регулаторни задължения подпомага и какви доказателства потвърждават функционирането му.

Доказателственият стек за Active Directory, който одиторите очакват

Укрепена AD среда не е готова за одит само защото настройките съществуват. Само екранни снимки са слабо доказателство. Само политики са непълни. Експорт на GPO без история на одобренията е рисков. Силните доказателства показват управление, внедряване, мониторинг и подобрение.

Пропускът в зрелостта обикновено не е липсата на всички контроли. Той е липсата на собственост, ритъм на прегледи, управление на изключения и съпоставяне. Одиторът ще попита не само дали съществува привилегирована група, а кой е нейният собственик, кой е одобрил членството, кога е преглеждана последно, какви журнали се събират и как изтичат изключенията.

Привилегирован достъп: първият AD контрол, който трябва да бъде доказан

Най-бързият път към компрометиране на Active Directory е прекомерната привилегия. Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, локалните администратори, делегираните OU администратори и администраторите на удостоверителни органи изискват изрично управление.

[P11] Политика за управление на потребителски акаунти и привилегии Политика за управление на потребителски акаунти и привилегии задава очакването на корпоративно ниво:

Хранилищата на акаунти (напр. Active Directory (AD), платформи за управление на идентичности и достъп) трябва да бъдат защитени с подходящи контроли за предотвратяване на неоторизиран достъп или подправяне.

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

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

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

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

В [ZC] Zenith Controls: ръководство за крос-съответствие Zenith Controls контрол 8.2 по ISO/IEC 27002:2022, „Права за привилегирован достъп“, е съпоставен като превантивен контрол, подпомагащ поверителността, целостта и наличността. Ръководството свързва 8.2 с управление на идентичности, права за достъп, ограничаване на достъпа до информация, сигурна автентикация, дистанционна работа, регистриране и мониторинг. То също така съпоставя контрола с GDPR Articles 5(1)(f), 25 и 32, очакванията за управление на риска по NIS2 Article 21 и управлението на ИКТ риска по DORA за финансови субекти.

Zenith Blueprint, фаза „Контроли в действие“, стъпка 19, обяснява оперативното очакване:

A.8.2 – Права за привилегирован достъп: „Разпределянето и използването на права за привилегирован достъп трябва да бъдат ограничени и управлявани.“

Контролирайте суперпотребителските права на администраторските акаунти само до лицата, които действително се нуждаят от тях, и ги управлявайте внимателно. Например използвайте отделен администраторски акаунт (без администраторски права за ежедневна работа), редовно одобрявайте и проследявайте кой получава права на domain admin или root. Използвайте и по-силни контроли за тези акаунти (като MFA и регистриране на действията им).

За AD одиторът трябва да може да избере един привилегирован потребител и да проследи цялата история: заявка, одобрение, бизнес обосновка, техническо назначаване, мониторинг, преглед, премахване и управление на изключения.

Практическият пакет с доказателства за привилегирован достъп трябва да включва:

1. Експорт на привилегировани AD групи, включително вложени групи.
2. Определен бизнес собственик за всяка привилегирована група.
3. Доказателства за тримесечен преглед на достъпа.
4. Отделни администраторски акаунти за привилегировани задачи.
5. Забрана за ежедневна електронна поща или уеб сърфиране от привилегировани акаунти.
6. MFA или устойчива на фишинг автентикация за пътищата за привилегирован достъп, когато е приложимо.
7. Модел с привилегирована работна станция или защитен администраторски бастион.
8. Регистриране на промени в членството в групи и на привилегировани операции.
9. Инвентар на аварийни акаунти („break-glass“) с компенсиращи контроли.
10. Приемане на риска за изключения със срок на валидност.

Така Мария закри непосредствената констатация за служебния акаунт. Акаунтът беше документиран като високорисков елемент, Политика за управление на потребителски акаунти и привилегии - SME беше използвана за оспорване на постоянната привилегия, собственикът на приложението определи минимално необходимия достъп, членството в Domain Admin беше премахнато, а промяната беше документирана чрез управление на промените. Записът в SoA за контрол 8.2 по ISO/IEC 27002:2022 беше актуализиран, за да покаже намаляване на риска и съпоставяне с GDPR Article 32 и NIS2 Article 21.

Kerberos и информация за удостоверяване

Kerberos осигурява мащабируема автентикация в Windows среди, но слабата конфигурация или лошата хигиена на служебните акаунти може да позволи Kerberoasting, злоупотреба с билети, replay атаки и дългосрочно устойчиво присъствие. Доказателствата трябва да обхващат информацията за удостоверяване през целия ѝ жизнен цикъл: пароли, ключове, билети, тайни на служебни акаунти, сертификати, процеси за нулиране и MFA фактори.

В Zenith Controls контрол 5.17 по ISO/IEC 27002:2022, „Информация за удостоверяване“, е съпоставен като превантивен контрол, подпомагащ поверителността, целостта и наличността. Той се свързва с управление на идентичности, сигурна автентикация, роли и отговорности, допустима употреба и съответствие с политики и стандарти. Крос-съпоставянето го свързва със съобразена с риска защита срещу неоторизиран достъп по GDPR, NIS2 Article 21(2)(j) относно MFA или непрекъсната автентикация, когато е подходящо, и изискванията на DORA за устойчиви механизми за автентикация в рамката за управление на ИКТ риска.

GDPR Article 5(1)(f) изисква личните данни да бъдат защитени срещу неоторизирано или незаконосъобразно обработване и срещу случайна загуба, унищожаване или повреждане. Article 5(2) добавя отчетност. Ако удостоверителните данни в AD дават достъп до записи на ЧР, клиентски файлове или пощенски кутии, контролите за Kerberos и автентикация се превръщат в доказателства по GDPR.

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

За финансови субекти, обхванати от DORA, зависимостите при автентикацията трябва да се разглеждат в рамката за управление на ИКТ риска. Ако AD удостоверява персонала към платежни, търговски, застрахователни, клиентски или рискови системи, доказателствата за Kerberos подпомагат оперативната устойчивост.

Управление на Group Policy и управление на конфигурацията

Group Policy е един от най-мощните механизми за сигурност в Active Directory. Чрез него могат да се прилагат защитни стени, ограничения за локални администратори, политика за одит, настройки за защита на крайните точки, правила за изпълнение на скриптове и сигурни базови конфигурации върху хиляди системи. При неправилно използване той може и да отслаби същите тези контроли.

В Zenith Controls контрол 8.9 по ISO/IEC 27002:2022, „Управление на конфигурацията“, е съпоставен като превантивен контрол за сигурна конфигурация. Той се свързва с управление на уязвимостите, управление на промените, инвентар на активите, крайни устройства, привилегирован достъп, сигурна автентикация, регистриране и мониторинг. Ръководството свързва управлението на конфигурацията с GDPR Articles 5(1)(f), 25 и 32, очакванията по NIS2 Article 21 за сигурна конфигурация и управление на риска, както и с надеждността, сигурността и устойчивостта на ИКТ системите по DORA.

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

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

От раздел „Третиране на риска и изключения“, клауза 7.5.1 на политиката.

[P05] Политика за управление на промените Политика за управление на промените изисква:

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

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

Пакетът с доказателства за GPO трябва да отговаря на четири въпроса:

1. Кой е собственик на всеки GPO със значение за сигурността?
2. Коя базова конфигурация прилага той?
3. Кой е одобрил промените по него?
4. Как се открива неоторизирано отклонение?

Zenith Blueprint, фаза „Контроли в действие“, стъпка 19, дава подхода към базовите конфигурации:

Започнете със създаване на контролни списъци за конфигурация за всички основни типове системи: Windows сървъри, Linux хостове, мрежови устройства, бази данни и облачни услуги. Тези базови конфигурации трябва да отразяват както най-добрите практики в индустрията (например CIS Benchmarks), така и вашия вътрешен рисков профил.

За AD това означава, че GPO трябва да прилагат документирани базови конфигурации, а не недокументирани предпочитания. Доказателствата трябва да включват месечни експорти на GPO, съпоставяне с изискванията на базовата конфигурация, заявки за промяна за модификации, прегледи на делегирани разрешения, записи за резервни копия на GPO и предупреждения за промени в GPO с високо въздействие.

AD CS и PKI: забравеният път за атака

Active Directory Certificate Services често остава извън прегледите за съответствие, защото работи тихо във фонов режим. Атакуващите го ценят по същата причина. Неправилно конфигурирани шаблони за сертификати, прекомерни разрешения за записване, слаби контроли при издаване или опасни настройки на Extended Key Usage могат да позволят ескалация на привилегии, имперсониране и устойчиво присъствие.

AD CS принадлежи към криптографските контроли, управлението на идентичности, привилегирования достъп и управлението на промените. Не е достатъчно да се каже: „имаме PKI“. Организацията трябва да знае кои CA съществуват, какви сертификати могат да бъдат издавани, кой може да ги заявява, кои шаблони позволяват клиентска автентикация, кой администрира CA и дали издаването се наблюдава.

[P18S] Политика за криптографски контроли - SME Политика за криптографски контроли - SME посочва:

Доставчикът на ИТ поддръжка трябва да поддържа актуален инвентар на използваните криптографски инструменти и сертификати

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

[P18] Политика за криптографски контроли Политика за криптографски контроли изрично включва:

Инфраструктура с публичен ключ (PKI)

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

NIS2 Article 21 включва политики и процедури за криптография и криптиране. GDPR Article 32 изисква сигурност на обработването, включително поверителност, цялостност, наличност и устойчивост. DORA изисква ИКТ активите, поддържащи финансови процеси, да бъдат защитени и възстановими. AD CS може да подпомогне всички тези изисквания или да ги подкопае.

Регистриране, резервно копиране и възстановяване на домейн контролери

Домейн контролерите не са обикновени сървъри. Те са системи за автентикация, реплики на директорията, точки за разпространение на политики и активи, критични за възстановяването. Ако ransomware компрометира AD, възстановяването зависи от чисти резервни копия на домейн контролерите, възстановяване на състоянието на системата, запазени журнали, надеждни GPO, резервни копия на AD CS, защитени частни ключове и документирани процедури за възстановяване.

[P22S] Политика за регистриране и мониторинг - SME Политика за регистриране и мониторинг - SME определя очакванията за журналите за автентикация:

Журнали за автентикация: успешни и неуспешни опити за влизане, продължителност на сесията, използване на MFA

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

[P22] Политика за регистриране и мониторинг Политика за регистриране и мониторинг изисква:

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

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

В среда, зависима от AD, обхванатите системи трябва да включват домейн контролери, AD CS сървъри, системи за привилегирован достъп, администраторски работни станции, сървъри за синхронизация на идентичности и конзоли за резервно копиране.

Zenith Blueprint, фаза „Контроли в действие“, стъпка 19, е категоричен:

Уверете се, че всички критични системи (сървъри, контролери на домейн, защитни стени) препращат журнали към вашия SIEM или колектор на журнали. Валидирайте, че съхранението на журналите е съобразено с политиката ви за регистриране (напр. 90 дни онлайн, 1 година архив). Изберете скорошен инцидент или събитие и покажете как сте го проследили чрез журналите си.

Той подчертава и синхронизацията на часовника, която се съпоставя с контрол 8.17 по ISO/IEC 27002:2022, „Синхронизация на часовника“. Без надеждно време корелацията на журналите по време на инцидент става крехка.

[P15S] Политика за архивиране и възстановяване - SME Политика за архивиране и възстановяване - SME задава минимално очакване за доказателства:

Тестове за възстановяване се провеждат най-малко на тримесечна база, а резултатите се документират, за да се потвърди възстановимостта

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

Релевантните контроли по ISO/IEC 27002:2022 включват 8.13 Резервно копиране на информация, 8.15 Регистриране, 8.16 Дейности по мониторинг, 8.17 Синхронизация на часовника, 5.24 Планиране и подготовка за управление на инциденти по информационна сигурност, 5.29 Информационна сигурност при прекъсване и 5.30 ИКТ готовност за непрекъсваемост на дейността.

Практическият пакет с доказателства за възстановяване трябва да включва:

1. Инвентар на домейн контролерите и собственост върху FSMO роли.
2. Обхват на резервното копиране, честота и доказателства за неизменяемост.
3. Валидиране на резервното копие на състоянието на системата.
4. Резултати от тримесечни тестове за възстановяване.
5. Процедура за резервно копиране и възстановяване на GPO.
6. Доказателства за резервно копиране на AD CS и защита на частни ключове.
7. Процедура за аварийна автентикация.
8. Конфигурация за синхронизация на часовника.
9. Наръчник за реагиране при компрометиране на AD.
10. Извлечени поуки от настолни или технически упражнения за възстановяване.

NIS2 Article 23 също е важен. Значимите инциденти може да изискват ранно предупреждение в рамките на 24 часа от узнаването, уведомление за инцидент в рамките на 72 часа и окончателен доклад не по-късно от един месец след уведомлението за инцидента. Ако прекъсване на AD наруши съществени или важни услуги, доказателствата за възстановяване и хронологиите на инцидентите се превръщат в регулаторни доказателства.

Карта за крос-съответствие при укрепване на Active Directory

Укрепването на Active Directory е ясен пример за един набор от контроли, който подпомага множество задължения.

За NIS2 това вече не е теоретично. Националните мерки се прилагат за много средни и големи съществени или важни субекти в секторите от Приложение I и Приложение II, както и за определени субекти независимо от размера, включително доставчици на удостоверителни услуги, TLD регистри, доставчици на DNS услуги и избрани критични услуги.

За DORA времевата рамка също е реална. DORA се прилага от 17 януари 2025 г. и пряко обхваща много финансови субекти. Ако външно възложен доставчик на управлявани услуги (MSP) управлява AD, изискванията на DORA за ИКТ риск от трети страни стават релевантни, включително регистри на договорите, надлежна проверка, права на одит, съдействие при инциденти, очаквания за сигурност и стратегии за изход съгласно Articles 28 и 30.

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

Изградете пакет с доказателства за укрепване на AD в един спринт

Практически двуседмичен спринт може да превърне фрагментираното укрепване на AD в пакет с доказателства, готов за одит.

Ден 1 до 2: Включете AD в обхвата на СУИС. Използвайте клаузи 4.1 до 4.4 на ISO/IEC 27001:2022, за да потвърдите дали AD, Entra Connect, домейн контролерите, AD CS, привилегированите администраторски работни станции, системите за резервно копиране и доставчиците на управлявани услуги са в обхвата. Запишете заинтересованите страни, включително регулатори, клиенти, одитори, субекти на данни, бизнес собственици и ИТ операции.

Ден 3 до 4: Добавете рисковете за AD в регистъра на рисковете. Включете компрометиране на домейн контролер, прекомерен привилегирован достъп, злоупотреба с Kerberos, подправяне на GPO, неправилна конфигурация на AD CS, компрометиране на синхронизацията на идентичности, отказ на резервно копиране и недостатъчно регистриране. Определете собственици, вероятност, въздействие и решения за третиране.

Ден 5 до 6: Актуализирайте SoA. Следвайки стъпка 13 от Zenith Blueprint, маркирайте като приложими контроли като права за привилегирован достъп, информация за удостоверяване, управление на конфигурацията, регистриране, мониторинг, резервно копиране на информация, управление на инциденти, криптографски контроли и управление на промените. Добавете бележки, които ги свързват с GDPR Article 32, NIS2 Article 21 и управлението на ИКТ риска по DORA, когато е релевантно.

Ден 7 до 9: Съберете технически доказателства. Експортирайте привилегировани групи, настройки на Kerberos, инвентар на GPO, базови конфигурации на домейн контролери, CA шаблони, журнали за издаване на сертификати, статус на задачи за резервно копиране и статус на приемане в SIEM. Добавете собственик, дата, преглеждащо лице, констатация и статус на отстраняване.

Ден 10 до 11: Проведете работна среща за преглед на контролите. ИТ, сигурност, съответствие и бизнес собственици преглеждат изключенията. Защо този служебен акаунт се нуждае от SPN? Защо тази група може да редактира GPO? Защо този шаблон може да издава сертификати за клиентска автентикация? Защо на този домейн контролер му липсва препращане на журнали?

Ден 12 до 14: Оформете одитния разказ. Създайте пакет с доказателства за укрепване на AD с резюме за ръководството, обхват, рискове, съпоставяне в SoA, доказателства за контролите, отворени констатации, план за отстраняване и график за тестване.

Резултатът е защитима история: познаваме риска, избрали сме контроли, внедрили сме ги, наблюдаваме ги, тестваме възстановяването и ръководството има видимост.

Чести одитни констатации за Active Directory и действия за закриване

Моделът за закриване е последователен: изискване от политиката, техническо внедряване, събиране на доказателства, ритъм на прегледи, управление на изключения и докладване към ръководството.

Превърнете укрепването на Active Directory в доказателства, готови за одит

Укрепването на Active Directory през 2026 г. не е еднократно почистване. То е жива система от контроли, която трябва да бъде управлявана, подкрепена с доказателства и подобрявана. Домейн контролерите, Kerberos, Group Policy, AD CS, привилегированият достъп, регистрирането и възстановяването се намират на пресечната точка между операциите по сигурността и регулаторната отчетност.

Clarysec помага на директори „Информационна сигурност“, ИТ ръководители и екипи по съответствие да изградят тази връзка. Използвайте Zenith Blueprint, за да съпоставите рисковете за AD със СУИС, регистъра на рисковете и Декларацията за приложимост. Използвайте Zenith Controls, за да съпоставите контролите по ISO/IEC 27002:2022 с GDPR, NIS2, DORA, NIST CSF 2.0 и одитните очаквания. Използвайте шаблоните за политики на Clarysec, включително Политика за управление на потребителски акаунти и привилегии, Политика за управление на промените, Политика за криптографски контроли, Политика за регистриране и мониторинг и Политика за архивиране и възстановяване - SME, за да превърнете техническото укрепване в повторяеми доказателства.

Ако следващият ви одит, искане от регулатор или клиентски въпросник за потвърждение на контролите попита как се контролира Active Directory, не отговаряйте само с екранни снимки. Изградете пакета с доказателства, свържете го с риска и покажете, че ръководството може да разчита на слоя за управление на идентичности.

Започнете с един спринт: привилегирован достъп, управление на GPO, преглед на AD CS, регистриране на домейн контролери и тестване на възстановяване. Clarysec може да ви помогне да го структурирате, да съберете доказателствата и да го защитите.