У цій статті я постарався зібрати основні організаційні та технічні правила використання облікових записів адміністраторів в організації, спрямовані на підвищення безпеки в домені Windows. Використання даних рекомендацій значно підвищить захист комп'ютерів домену Active Directory від атак, аналогічних річному інциденту з шифрувальником Petya, однією з технік поширення якого між комп'ютерами домену (крім уразливості в SMBv1) був віддалений доступ за допомогою отриманих з пам'яті облікових даних адміністраторів (за допомогою утиліти аналогічної Mimikatz). Можливо деякі з рекомендацій спірні або непридатні для конкретних випадків, але до них все-таки потрібно прагнути.
Отже, в попередній статті ми розглянули основні методики захисту від вилучення паролів з пам'яті за допомогою Mimikatz. Однак всі ці технічні заходи можуть бути марними, якщо в домені Windows не застосовуються базові правила забезпечення безпеки адміністративних облікових записів.
Основне правило, яким слід користуватися - максимальне обмеження адміністративних привілеїв, як для користувачів, так і адміністраторів. Потрібно прагне, що надавати користувачам і групам підтримки тільки ті права, які необхідні для виконання повсякденних завдань.
Базовий список правил:
- Облікові записи адміністраторів домену / організації повинні використовуватися тільки для управління доменом і контролерами домена. Не можна використовувати ці облікові записи для доступу і управління робочими станціями. Аналогічна вимога має пред'являтися для облікових записів адміністраторів серверів
- Для облікових записів адміністраторів домену бажано використовувати двухфакторную аутентифікацію
- На своїх робочих станціях адміністратори повинні працювати під обліковими записами з правами звичайного користувача
- Для захисту привілейованих облікових записів (адміністратори домену, Exchange, серверів) потрібно розглянути можливість використання групи захищених користувачів (Protected Users)
- Заборона використання знеособлених загальних адміністративних акаунтів. Усі профілі адміністраторів повинні бути персоніфіковані
- Не можна запускати сервіси під обліковими записами адміністраторів (а тим більше адміністратора домену), бажано використовувати виділені облікові записи або Managed Service Accounts .
- Заборона роботи користувачів під правами локального адміністратора
Природно, потрібно політиками забезпечити достатню довжину і складність пароля як для користувачів, так і для адміністраторів і умови блокування. Я говорю про політиків розділу Computer Configuration -> Windows Settings -> Security Settings -> Account Policies (Див статтю https://winitpro.ru/index.php/2018/10/26/politika-parolej-uchetnyx-zapisej-v-active-directory/):
- Password Policy
- Account Lockout Policy
Можна зробити більш жорсткі вимоги до довжини і збереженої історії паролів для адміністраторів за допомогою Fine-Grained Password Policies.
Відносно вбудованої облікового запису на комп'ютерах користувачів. Не можна використовувати однакові паролі локального адміністратора на всіх ПК. Бажано взагалі відключити (або хоча б перейменувати) локальну учетку administrator. Для регулярної зміни пароля цього облікового запису на унікальний на кожному комп'ютері в мережі можна використовувати LAPS.
Доступ по мережі за допомогою локальних облікових записів і віддалених вхід по RDP потрібно заборонити груповими політиками. Дані політики знаходяться в розділі Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
- Deny access to this computer from the network - Відмовити в доступі до цього комп'ютера з мережі
- Deny log on through Remote Desktop Services - Заборонити вхід в систему через служби віддалених робочих столів
- Deny log on as a batch job - Відмовити у вході в якості пакетного завдання
- Deny log on as a service - Відмовити у вході в якості служби
Після закінчення адміністративного сеансу (установка ПО, настройка системи і т.д.) комп'ютер користувача краще перезавантажити. А на RDS серверах примусово завершувати призупинені сесії за допомогою політик в розділі Computer Configuration-> Policies-> Administrative Templates-> Windows Components-> Remote Desktop Services-> Remote Desktop Session Host-> Session Time Limits.
В домені з Windows Server 2016 для тимчасового надання адміністративних прав можна використовувати нову фічу Temporary Group Membership
У цій я описав першочергові правила, які допоможуть вам підвищити рівень захисту адміністративних акаунтів у вашому домені Windows. Звичайно, це стаття не претендує на повноцінних гайд по захисту і обмеження прав облікових записів адміністратора, але цілком може стати вашою відправною точкою з побудови безпечної інфраструктури. Для подальшого вивчення теми рекомендую почати з вивчення документації Microsoft: Best Practices for Securing Active Directory.
