Приховані дані в Active Directory

У запропонованій серії статей ми розглянемо прийоми приховування даних AD. В основі цих прийомів можуть лежати типові дозволи AD, спеціальна роздільна здатність AD під назвою List Mode і маловідомий параметр, що називається бітом конфіденційності (confidentiality bit), вперше застосований кілька років тому в Windows Server 2003 SP1. У Windows Server 2008 R2 і Windows Server 2008 з'явилися лише невеликі покращення в області дозволів для доступу до даних AD, про які також попереду

В Active Directory (AD) передбачені функції призначення об'єктам дозволів з метою делегування адміністративних повноважень користувачами, групами чи комп'ютерами будь-якому суб'єкту безпеки. Але за допомогою звичайних дозволів AD досить складно домогтися, щоб певні дані було видно лише вузькому колу користувачів.

Суть проблеми

Основна причина труднощів, що виникають при спробі приховати дані в AD, полягає в різноманітних дозволах, які призначаються в лісі AD за умовчанням. Структура AD така, що всім користувачам, що пройшли перевірку, призначаються численні дозволи на читання майже всіх нових об'єктів, створюваних у лісі, замість того щоб блокувати доступ за замовчуванням і змусити адміністраторів призначати дозволи на читання, що відповідають особливостям середовища. Звичайно, обом підходам властиві переваги та недоліки. Я навіть вважаю, що несуворі стандартні дозволи — одна з причин успіху AD: від адміністратора потрібно менше зусиль, щоб підготувати систему до роботи.

Компанії поступово усвідомлюють широкі можливості дозволів на читання (та запис), які надаються всім обліковим записам користувачів у корпоративних реалізаціях AD. Більшість компаній хотіли бпровести відмінності між співробітниками, яким дозволяється надсилати запити до всіх облікових записів AD, і зовнішніми користувачами (наприклад, підрядниками). Крім того, підприємствам, які бажають застосовувати AD не просто як каталог мережевої операційної системи (який перевіряє справжність користувачів у мережі), а й каталог LDAP (використовується іншими додатками), потрібні більш глибокий контроль над інформацією, яка є видимою різним учасникам. Крім того, в тих компаніях, де потрібно делегувати адміністративні повноваження, видимість та доступ до важливих облікових записів, — критичний аспект, який потребує ретельного планування. Це особливо актуально при аутсорсингу, коли потрібно розміщувати користувачів з різних компаній в одному лісі AD.

Крім явних дозволів кожного нового об'єкта, різні дозволи успадковуються з батьківських організаційних одиниць. Дуже важливі стандартні дозволи, зокрема, на читання всіх властивостей об'єктів користувача, надаються групі Pre-Windows 2000 Compatible Access. Одна з основних труднощів — обмежити дозволи користувачів, які пройшли автентифікацію, таким чином, щоб вони не могли побачити всі об'єкти за умовчанням. Дуже важливо розібратися у всіх тонкощах дозволів AD та їх налаштування.

Зверніть увагу на те, що я використовував термін «явні дозволи» (explicit permissions). Явні дозволи призначаються безпосередньо на об'єктах, на відміну від успадкованих дозволів, що встановлюються на об'єкті контейнера та настроюються для застосування до об'єктів усередині цього контейнера та його субконтейнерів.

Явні та успадковані дозволи

Малюнок 1. Зразкові явні дозволискасовують заборони верхнього рівня

Набори властивостей дозволів

Малюнок 2. Дозволи AD можуть застосовуватися до кількох атрибутів через набори властивостей

Більшість наборів властивостей однакові у всіх версіях Windows Server (як показано в таблиці 3), але тільки в Windows 2003 і новіших версіях реалізована важлива можливість - змінювати типові набори властивостей. Докладніше про редагування наборів буде розказано у статті.

У таблиці 3 також показано, що більшість типових наборів властивостей, як і раніше, містять таке ж число атрибутів, як і в початковій версії AD. Однак кілька наборів були оновлені в процесі оновлення схеми, коли з'явилися такі нововведення, як LastLogonTimeStamp (Windows 2003) і ManagedAccounts (Server 2008 R2).

Схема Microsoft Exchange Server також розширена завдяки різним атрибутам; деякі з них додані до типових наборів властивостей. Але лише з випуском Exchange Server 2007 фахівці Microsoft підготували нові набори властивостей дозволів Exchange. Досить цікаво, що в Exchange не використовується набір властивостей Phone and Mail Options, здавалося б, призначений для обробки повідомлень. До Exchange 2007 усі відповідні атрибути (їх лише 120) входили в один набір властивостей – Public Information. У цей набір властивостей також входять всі extensionattributes, призначені для зберігання лише загальнодоступної інформації, оскільки користувачі, що пройшли автентифікацію, за замовчуванням мають доступ на читання до цієї властивості. Набір властивостей Personal Information Exchange залишився незмінним.

Малюнок 3. Атрибутинабору властивостей Personal Information

Так чому ж набори властивостей настільки важливі для приховування даних AD? Відповідь проста. Погляньте на таблицю 1, в якій перелічені дозволи, які надаються за умовчанням кожному новому об'єкту користувача в AD. Чотири явні дозволи на читання для тих, хто пройшов перевірку справжності користувачів (General Information, Personal Information, Web Information і Public Information) призначаються набором властивостей. Згадайте і про більш високий пріоритет явних дозволів перед успадкованими заборонами, і вам стане ясно, що приховати дані атрибутів, які є частиною набору властивостей, є непростим завданням. Не можна просто призначити заборону для атрибута об'єкта на рівні OU та запровадити примусове успадкування для відповідних об'єктів. Тому адміністраторам необхідно добре знати набори властивостей і атрибути, що їм належать, щоб розуміти вплив наданих дозволів або заборон для певних атрибутів в AD.

Зверніть увагу, що використання сторонніх інструментів для керування дозволами AD зазвичай допомагає лише при призначенні нових дозволів. Але для приховування даних часто потрібно видалити дозволи, які призначаються за умовчанням. Ці дозволи необхідно скоригувати у власних дозволах каталогу (звичайно після перевірки та тестування в лабораторії).

Коли потрібно приховати дані?

Акценти в статті, безсумнівно, були б іншими, якби не було охоплення дозволів на читання за замовчуванням для тих, хто пройшов перевірку справжності користувачів AD настільки великий. Очевидно, що труднощі приховування даних в AD тісно пов'язані з трьома факторами:

* дозволи на читання за умовчанням, що надаються новим об'єктам AD;

* пріоритет успадкованих дозволів у процесі перевірки спискуACL;

* групування атрибутів AD у набори властивостей.

Більшість структур OU орієнтовані групування об'єктів одного типу чи місцезнаходження однієї OU. На малюнку 4 показано, яким чином компанія може мати одну OU для управління об'єктами в Атланті (ATL) та іншу для управління об'єктами в Феніксі (PHX). Зверніть увагу, що обидві організаційні одиниці рівня місцезнаходження мають вкладені OU, які забезпечують подальше поділ об'єктів для кожного регіону. Ці підрозділи дозволяють делегувати різні адміністративні права чи застосовувати групові політики.

Малюнок 4. Зразок архітектури OU

Зверніть також увагу на особливу вкладену OU з ім'ям Local Admins на малюнку 4. Вона повинна містити дані спеціального облікового запису для делегованих адміністраторів регіону. Щоб захистити цих користувачів від потенційних зловживань та атак із відмовою від обслуговування (DOS), корисно приховати від кінцевих користувачів організаційні одиниці Local Admins.

Інша причина для приховування користувачів або цілих OU - бажання зробити так, щоб інші користувачі не знали про існування в AD. Такий захід важливий у фінансових та державних установах, або компаніях, що займаються аутсорсингом, у яких кожна OU верхнього рівня представляє різних клієнтів, кожен із яких має бачити лише об'єкти одного клієнта.

Однак Інтернет-провайдери та інші компанії, до конфіденційності яких пред'являються підвищені вимоги, часто забороняють адміністраторам додавати користувачів з-за меж їхньої зони відповідальності (тобто організаційних одиниць, що знаходяться поза керованими ними) у свої групи. У таких випадках необхідно також приховатикористувачів, що знаходяться поза організаційними одиницями, керованими делегованим адміністратором, щоб він не міг додати цих користувачів до своїх груп або до будь-яких інших пов'язаних атрибутів, таких як атрибут manager користувача або атрибут managedBy таких об'єктів, як принтери, групи або OU.

Підсумовуючи, перерахуємо найпоширеніші причини приховування даних в AD:

* захист адміністративних облікових записів від зловживань та атак із відмовою від обслуговування (DOS);

* юридичні зобов'язання, які призводять до необхідності приховати певні об'єкти;

* дотримання принципу мінімальних повноважень для спеціальних адміністративних завдань, зокрема надання делегованим адміністраторам груп права змінювати членство для користувачів лише у своїй адміністративній галузі;

Можливі підходи до приховування даних

У таблиці 4 перераховані основні варіанти приховування даних AD, із зазначенням області (об'єкти або атрибути) і версії операційної системи для відповідного варіанту. На практиці адміністраторам часто потрібно об'єднати різні конфігурації дозволів, щоб забезпечити приховування потрібних даних AD.

Поділіться матеріалом з колегами та друзями