З ростом мережевої інфраструктури управління привілейованим доступом до серверів, що, по суті, є основою безпеки і контролю змін, стає нагальною потребою і може до того ж бути умовою відповідності встановленим вимогам. Розглянемо проблеми, пов'язані з доступом, з якими стикаються багато компаній, а потім основні кроки, які допоможуть зробити інформаційні системи організації більш захищеними
Реєстрація на конференцію
Навіть невеликі команди адміністраторів, що працюють з малою кількістю серверів, при використанні управління привілейованим доступом відразу відчують різницю між стійкою, безпечною системою і некерованим потоком змін, який несе загрозу стабільності корпоративної інформаційної системи і цілісності даних.
Адміністратори домену: хто зайвий?
У невеликих компаніях часто практикується надання привілеїв адміністратора домену облікових записів всіх фахівців з інформаційних технологій. Це не тільки найпростіший спосіб надати повний адміністративний доступ до всіх робочих станцій і серверів (оскільки група адміністраторів домену входить в групу локальних адміністраторів, коли комп'ютери є членами домену), але і спосіб забезпечити доступ на читання / зміна об'єктів в Active Directory (AD) . Але як часто молодшим системним адміністраторам і фахівцям технічної підтримки дійсно потрібні привілеї адміністратора домену? Зовсім не обов'язково піддавати ризику всю мережеву структуру, надаючи новому співробітнику в його перший робочий день повний адміністративний доступ до неї, оскільки адміністративний доступ до робочих станцій можна забезпечити не тільки за допомогою участі в групі адміністраторів домену. Найкраще надавати повний адміністративний доступ до серверів тільки в разі реальної необхідності.
Визначення рівнів доступу
На відміну від системи безпеки UNIX, де для управління доступом до файлів використовуються індивідуальні списки контролю доступу access control lists (ACL), в Windows доступ до всіх об'єктів здійснюється про допомогою набору вбудованих груп, які значно полегшують процес призначення дозволів. Однак, незважаючи на спокуса полегшити собі життя і додати облікові записи системних адміністраторів в усі групи, робити це потрібно вкрай обережно, оскільки в даному випадку буде дуже складно контролювати зміни в системі. З іншого боку, цілком допустимо зробити системних адміністраторів учасниками груп з правами тільки на читання, таких, наприклад, як читачі журналу подій Event Log Readers, оскільки такі групи не мають адміністративного доступу до серверів.
Облікових записів служб часто потрібно адміністративний доступ або привілеї, яких немає у звичайних користувачів. Такі облікові записи можуть використовуватися і для запуску завдань за розкладом або пакетних файлів, для чого також можуть знадобитися розширені привілеї. Облікові записи, які використовуються для надання тимчасового доступу до серверів (наприклад, облікові записи аварійного доступу, firecall accounts) з метою обслуговування, також вимагають привілейованого доступу. Всі інші запити на надання постійного привілейованого доступу до серверів поза контекстом облікових записів служб або аварійних облікових записів слід ретельно зважити, оскільки в більшості випадків такий доступ не є необхідним.
попередня підготовка
Зверніть увагу, що поряд з контейнером за замовчуванням для контролерів домену (DC) створені організаційні підрозділи (OU) для облікових записів аварійного доступу, облікових записів служб і рядових серверів WS08 EC. Таким чином, службові та аварійні облікові записи будуть відокремлені від учених записів звичайних користувачів домену, що дозволить делегувати управління певними властивостями цих облікових записів обмеженому числу користувачів.
Облікові записи аварійного доступу
Перш ніж відключити вбудовані адміністраторські облікові записи і змінити паролі до них, необхідно створити обліковий запис користувача домену для кожного сервера в окремому підрозділі «Облікові записи аварійного доступу». Для того щоб додати кожного серверу відповідну обліковий запис аварійного доступу, скористаємося політикою груп з обмеженим доступом Restricted Groups. Обліковими записами аварійного доступу повинна управляти виділена група безпеки. В її функції входить включення відключених в решту часу облікових записів і генерація для них випадкових паролів, які потім надаються системним адміністраторам і діють при цьому обмежений час, після чого облікові записи знову відключаються, а паролі до них змінюються.
Кожен раз при включенні облікового запису аварійного доступу та видачі пароля системного адміністратора група безпеки докладно фіксує цей факт в журналі реєстрації. У такому випадку будь-які зміни, зроблені під час сеансу реєстрації в системі і стали причиною будь-яких проблем, можна відстежити аж до конкретного користувача, часу, коли вони були зроблені і початкового запиту на зміну. Якщо ж системні адміністратори використовують власні облікові записи для реєстрації на сервері, можна відстежити події реєстрації в системі і завершення сеансу роботи з системою, але не рівень привілеїв. В ідеалі навіть група безпеки не повинна знати паролі, призначені для облікових записів аварійного доступу, але це може зажадати розгортання окремої системи управління паролями.
Делегування доступу до управління обліковими записами аварійного доступу
У нашому прикладі для серверів додатків в підрозділі «Облікові записи аварійного доступу» створені чотири облікові записи аварійного доступу (наприклад, AppServ01_Firecall, AppServ02_Firecall). Також у нас є особлива група адміністраторів з безпеки, яка має повноваження на включення, відключення, розблокування і скидання паролів на облікових записах в OU «Облікові записи аварійного доступу».
Скористаємося оснащенням «користь-ва-ки і комп'ютери Active Directory» консолі управління MMC, щоб делегувати доступ до OU «Облікові записи аварійного доступу».
- В меню «Адміністрування» відкриємо оснащення «Користувачі та комп'ютери Active Directory» з правами адміністратора домену. У лівій панелі розгорнемо рядок домену, клацнемо правою кнопкою по OU «Облікові записи аварійного доступу» і виберемо пункт меню «Делегування управління».
- Щелкнем «Далі» на екрані вітання майстра делегування управління.
- На екрані «Користувачі та групи» натиснемо «Додати». У цьому прикладі заздалегідь створена група «Адміністратори безпеки при виконанні», якій ми делегуємо управління обліковими записами в підрозділі «Облікові записи аварійного доступу». Насправді для цих цілей можна використовувати будь-яку доменну групу. У діалоговому вікні «Виберіть користувачів, комп'ютери або групи» вводимо ім'я групи, якій потрібно делегувати управління, і натискаємо ОК. Натискаємо «Далі» на екрані «Користувачі та групи».
- На екрані «делегованих завдань» вибираємо «Створити особливе завдання для делегування» і натискаємо «Далі».
- На екрані «Тип об'єкта Active Directory» виберемо «Тільки такі об'єкти в цій папці» і «Об'єкти користувача» в нижній частині списку. Натискаємо «Далі».
- На екрані «Дозволи» виберемо «Загальні» і «Дозволи для властивостей». У списку вибираємо наступні дозволи: зміна пароля, скидання пароля, читання lockoutTime, запис lockoutTime, читання userAccountControl, запис userAccountControl. Натискаємо «Далі», а потім «Готово».
Тепер будь-який користувач з групи «Адміністратори безпеки при виконанні», який в усьому іншому є звичайним користувачем домену, зможе за допомогою оснастки «Користувачі та комп'ютери Active Directory» виконувати обмежений набір дій над обліковими записами в OU «Облікові записи аварійного доступу».
Управління привілейованим доступом до серверів за допомогою політики груп з обмеженим доступом
На екрані 1, крім базового GPO «Сервери додатків WS08», показано чотири додаткових GPO, пов'язаних з підрозділом «Сервери додатків WS08» і забезпечених префіксом «Групи з обмеженим доступом», кожен з яких підтверджено одному з чотирьох серверів, чиї облікові записи розташовані в цьому OU. Крім того, ці додаткові GPO містять фільтр WMI, щоб забезпечити застосування їх параметрів тільки до потрібного сервера. Щоб створити GPO для груп з обмеженим доступом, відкриємо управління груповою політикою з підміню «Адміністрування» в меню «Пуск» з правами адміністратора домену.
Екран 1. Оптимальна ієрархічна структура підрозділів (OU)
Перед тим як зв'язати новостворений GPO з підрозділом, необхідно додати фільтр WMI, щоб забезпечити застосування політики до потрібного сервера. В якості альтернативи можна створити окремий підрозділ OU для кожного сервера. Але і в тому і в іншому випадку буде потрібно додатковий об'єкт AD.
- Повернемося в управління груповою політикою, клацнемо правою кнопкою розділ «Фільтри WMI» в лівій панелі і виберемо пункт меню «Створити».
- У діалоговому вікні «Новий фільтр WMI» задамо ім'я фільтра MyServer1, додамо його опис та натиснемо кнопку «Додати» праворуч від поля «Запити».
- У діалоговому вікні «Запит WMI» введемо Select Win32_ComputerSystem where Name = "MyServer1" в поле «Запит» і натиснемо ОК.
- Тепер в діалоговому вікні «Новий фільтр WMI» (екран 2) натиснемо «Зберегти».
- Далі в розділі «Об'єкти групової політики» виберемо раніше створений GPO.
- У правій панелі перемкнемося на вкладку «Область». У розділі фільтра WMI в випадаючому меню виберемо щойно створений фільтр MyServer1. Натиснемо «Так» у вікні попередження, щоб застосувати фільтр.
Екран 2. Діалогове вікно «Новий фільтр WMI»
Вбудовані облікові записи адміністратора
Облікові записи служб
Облікових записів служб часто потрібно привілейований доступ, крім того, вони, подібно до облікових записів аварійного доступу, для кожного сервера свої. Обліковими записами онлайнової служби, як такими, можна управляти таким же чином, як і обліковими записами аварійного доступу, використовуючи для них окреме організаційне підрозділ і делегувавши управління ними обмеженій кількості людей.
Аудит подій реєстрації в системі і виходу з системи
Екран 3. Пересилання тільки зазначених подій для заданого користувача
Незважаючи на те що використання політики груп з обмеженим доступом - цілком надійний спосіб забезпечити участь в групі локальних адміністраторів на серверах тільки для явно зазначених облікових записів і груп, можна задіяти спеціальний сценарій для аудиту групи локальних адміністраторів, а потім порівняти результати з затвердженим списком учасників цієї групи для кожного сервера. Розміщений нижче код PowerShell використовує ADSI для перерахування учасників групи локальних адміністраторів на машині з ім'ям MyServer1:
контролери домену
Привілейований доступ до контролерів домена є певною проблемою, оскільки тут немає локальних груп, і адміністративного доступу, наданого користувачеві за допомогою вбудованої групи AD (наприклад «Оператори сервера»), досить для того, щоб користувач міг сам собі підняти повноваження, що не дозволяє повністю розділити доступ до сервера і до AD.
Екран 4. Функція «Цей користувач може входити»
мінімізація ризику
Затвердження простих процедур і делегування управління може в значній мірі знизити ризик, пов'язаний з можливим нанесенням шкоди цілісності системи ІТ-персоналом або з отриманням несанкціонованого доступу до даних компанії. Можливо, методик, описаних в цій статті, буде недостатньо, щоб задовольнити найсуворіших аудиторів, але, по крайней мере, вони направлять вас на правильний шлях. Для більших організацій можна рекомендувати продукти сторонніх виробників, такі як PowerKeeper компанії BeyondTrust і Password Manager Pro компанії ManageEngine, які допоможуть повністю автоматизувати управління привілейованими обліковими записами на сотнях серверів і забезпечити відповідність урядовим і промисловим стандартам.
Рассел Сміт ([email protected]) - незалежний ІТ-консультант, спеціалізується на управлінні системами
Поділіться матеріалом з колегами і друзями