В організаціях середнього та великого бізнесу для забезпечення ідентифікації, доступу, спрощення управління та аудиту користувачами і ресурсами, а також створення масштабованої, безпечної і керованої інфраструктури доцільно розгортати доменні служби Active Directory, які є одним з найбільш важливих компонентів у всій IT-середовищі. Правильне розгортання доменних служб дозволяє використовувати всі переваги централізованої делегованої моделі управління і можливості єдиного входу. У свою чергу, перед розгортанням і експлуатацією даних служб, початківці і не досвідчені адміністратори нехтують найважливішим етапом впровадження - плануванням, яке повинно здійснюватися у суворій відповідності до вимог організації. Перед початком планування ви повинні визначити мету розгортання служб каталогів в організації, потім створити логічну структуру доменних служб, які відповідають потребам кожної філії і підрозділів, які повинні використовувати ці служби. На цьому етапі вам потрібно визначити кількість лісів, продумати, яким чином їх розбити на домени, спланувати простір імен, структуру організаційних одиниць і ретельно протестувати отриману структуру організації на лабораторних стендах до впровадження в робочу середу. Перш за все, успіх стратегії розгортання доменних служб безпосередньо залежить від правильної оцінки поточного середовища та визначення завдань, причому важливим для вирішення поставлених завдань є конфігурація існуючої мережі організації, яка, швидше за все, зажадає реструктурування мережевих служб деяких філій в разі корпоративного придбання нових одиниць інфраструктури.
Визначення вимог доменних служб організації
Перед визначенням кількості лісів і розбивкою їх на домени, необхідно досліджувати всі можливі технології, призначені для вирішення впровадження нових можливостей бізнесу і поставлених перед компанією завдань. Під час проектування доменних служб в будь-якій організації також зобов'язана брати участь і керівну ланку, яка буде основним споживачем всієї отриманої інфраструктури, ступінь залученості якої безпосередньо залежатиме від профілю організації. Саме керівництво повинно визначити кількість лісів і доменів, які після закінчення розгортання буде не просто виключити з отриманої інфраструктури підприємства. Всі основні вимоги дизайну інфраструктури доменних служб організації розподіляються на такі вимоги, як:
- Бізнес-вимоги до проектної документації;
- Функціональні вимоги до проектної документації;
- Угоди про рівень надання послуг;
- Юридичні вимоги до документації;
- Вимоги безпеки організації;
- Проектні обмеження до документації.
Всі зазначені вище вимоги будуть детально розглянуті в наступних підрозділах.
Бізнес-вимоги до проектної документації
Бізнес-вимогою називається визначення призначення програмного забезпечення, яке записується в документі про бачення і межах проекту. До бізнес-вимогам доменних служб можна віднести відповідність зовнішнім вимогам, які можуть виходити від партнерів по бізнесу або уряду країни, таким як гарантія конфіденційності та нерозголошення даних. Крім цього, до одного з бізнес-вимог можна віднести визначення можливості підвищення конкурентоспроможності наданої останньої версії поточної технології. Ще до таких вимог відносяться переваги, які можна отримати під час експлуатації технологій організації, що може істотно підвищити потенційні можливості багатьох засобів. У тому випадку, якщо в поточній технології буде виявлена нестабільність, вона повинна бути задокументована і, для досягнення необхідної стабільності, керівна ланка зобов'язана визначити, чи варто переходити на дану технологію або від неї відмовитися. У зв'язку з усіма перерахованими вище вимогами, ви повинні знати бізнес-завдання організації і зобов'язані попросити, щоб вам були надані бізнес-вимоги, описані в спеціальній документації в короткій і зрозумілій для проектування доменних служб формі.
Функціональні вимоги до проектної документації
До функціональних вимог належать визначення очікуваної поведінки отриманої інфраструктури організації, що виходить із бізнес-вимог, які повинні бути описані у функціональній специфікації (закінченому описі поведінки системи, яке потрібно розробити). Якщо бізнес-вимоги визначають завдання організації, то функціональні вимоги важливі з таких причин як забезпечення деталей проекту, призначених для того щоб команда з розгортання інфраструктури могла координувати коректність вирішення поставленого завдання, встановлення оптимального рішення відповідно до очікувань споживачів між командою з розгортання та споживачами доменних служб. Крім цього за допомогою функціональних вимог визначається кількість ресурсів витрачаються командою з розгортання.
Угоди про рівень надання послуг
Угодою про рівень надання послуг (Service Level Agreement - SLA) є формальний документ, який укладається між замовником і групою, що надає послуги з розробки інфраструктури доменних служб, що містить опис послуги, права та обов'язки сторін, а також визначення очікуваного рівня швидкодії і якості надання послуги . Для того щоб дотримати SLA оператор мережі в свою чергу укладає операційне угоду про рівень послуг (OLA) з іншими внутрішніми підрозділами від яких залежить якість надання послуг. Параметри якості послуги, зазначені в SLA повинні бути вимірними, тобто подати у вигляді числових метрик. Наприклад, вимоги можуть бути узгоджені з продуктивністю (наприклад, всі користувачі повинні мати можливість увійти в доменні служби Active Directory протягом 10 секунд після введення облікових даних) або доступ до додатків повинен бути наданий протягом 99% робочого і неробочого дня для всіх користувачів , розташованих в інтра- і екстранет. Модель SLA може включати в себе наступні розділи:
- Визначення послуг, що надаються і терміни дії угоди;
- Розподіл днів і годин надання послуг, включаючи тестування, підтримку і модернізації;
- Число і розміщення користувачів і обладнання, які використовують дану службу;
- Опис процедури запитів на зміну;
- Мінімальна доступність для кожного користувача;
- Максимальний час відгуку для кожного користувача;
- Опис платежів, пов'язаних з послугами;
- Підготовка, підтримка відповідних конфігурацій обладнання, програмного забезпечення або його зміни тільки відповідно до процедури зміни при використанні послуг;
- Процес поліпшення SLA.
У більшості випадків основа вихідних угод SLA формується на бізнес-вимогах, а також функціональних і нефункціональних вимогах, а проектна група і бізнес-спонсори відповідають за деталізацію підсумкового SLA, прийнятну ціну і рівень очікувань.
Юридичні вимоги до документації
У наш час для зберігання, збору і передачі інформації між підприємствами використовуються інформаційні технології. У зв'язку з цим більшість країн встановили певні вимоги, які регламентують умови конфіденційності та захищеності даних. В Європі для цих цілей була створена «Директива про захист даних Європейського Союзу» (European Union Data Protection Directive, EUDPD). якої дотримуються більшість країн Європи. Ця директива стандартизує захист конфіденційності даних для громадян по всьому Європейському Союзу (ЄС) і містить базові вимоги, які всі держави-учасниці повинні реалізувати в своїх національних законодавствах. Завдяки обмеженням, що накладаються цією директивою на відправку анкетних даних за межі Європейського Союзу, EUDPD впливає на захист конфіденційної особистої інформації за межами Європейського Союзу. Зазвичай EUDPD дозволяє подібну передачу тільки в регіони, де, як передбачається, реалізовані відповідні стандарти для різних питань, включаючи захист даних. Встановлене Директивами, Регламентів і Рішеннями органів ЄС право є правом особливого роду, так як для укладачів проектної інфраструктури, що сприяють здійсненню принципів, викладених в таких правових актах, надаються додаткові права, наприклад, право на обмеження подальшого втручання в складання доменних служб. Крім зазначеної вище декларації групі, що надає послуги з розробки інфраструктури доменних служб, також варто дотримуватися вимог, які надають юристи замовника.
Наприклад, деякі дані організації, які повинні бути повністю конфіденційними ви можете зберігати в окремому ліс доменних служб разом з призначеними для користувача обліковими даними, що мають права на їх використання, але так як дані не повинні виходити за межі вашої організації, в той же час повинна бути задіяна служба управління правами Active Directory. Або в тому випадку, якщо планується співпраця декількох організацій з використанням служб федерації Active Directory, визначте, чи буде в організації розміщуватися веб-ресурс, до якого необхідно надати доступ іншим організаціям через Інтернет, або ж цей веб-ресурс буде доступний співробітникам тільки конкретної організації .
Вимоги безпеки організації
Однією з ключових ролей в плануванні і розгортанні доменних служб є вимога безпеки організації, так як безпечна інфраструктура впливає на конфіденційність даних і функціонування всієї організації в цілому. На цьому етапі, перш за все, вам потрібно визначити які вимоги безпеки використовуються в організації на даний момент, а що вам належить впровадити під час розгортання доменної інфраструктури. Вам потрібно випередити, які існують невідповідності для виконання вимог безпеки на даний момент. Невідповідності бувають в більшості випадків, причому для кожної організації вони можуть бути різними. Якщо невідповідності будуть виявлені на етапі планування, але ніякі заходи не будуть вжиті, то, в кінцевому рахунку, постраждати може вся інфраструктура підприємства. Вам необхідно визначити, які завдання повинні бути реалізовані для системи безпеки всієї організації, включаючи мережу на всіх філіях.
Наприклад, в філіях компанії, де адміністратори компанії не можуть гарантувати фізичну безпеку поміщати контролер домену вельми небезпечно. Варто пам'ятати про те, що контролер домену підтримує копії всіх атрибутів для всіх об'єктів в своєму домені, включаючи такі атрибути, як дані користувача паролів, що є секретною інформацією. Тому ви повинні розгортати в філіях контролери домену тільки для читання і розгорнути політику реплікації паролів, яка дозволить кешування призначених для користувача облікових записів на контролері RODC. І оскільки контролер домену тільки для читання підтримує тільки обмежений набір облікових записів користувачів, то в разі його злому або фізичного розкрадання шкоди безпеці буде також обмеженим.
Врахуйте, що бізнес-вимоги можуть конфліктувати з вимогами безпеки, тому вам необхідно шукати найбільш оптимальні варіанти, щоб організація була максимально захищена не обходячи всі вимоги надані вам замовником.
Проектні обмеження до документації
Проектне обмеження визначає параметри всього проекту і узгоджується спеціальною проектною групою з угодою про рівень надання послуг і бізнес-вимогам організації. Основними складовими такого обмеження є обмеження можливостей, ресурсні обмеження, а також обмеження графіка проекту. Простим прикладом обмеження можливостей може послужити не сумісні компанії або недоступність переходу на новий продукт, в зв'язку з чим, необхідно відмовитися або від впровадження нового проекту, або від модифікації самої області проекту. Всім відомо, що основною складовою ресурсних обмеження є бюджет самого проекту, тобто, якщо у організації-замовника недостатньо матеріальних засобів для придбання необхідного обладнання, то продовжити розгортання доменних служб в організації знову не вийде. Також на реалізацію всього проекту може вплинути графік реалізації проекту і, якщо модифікація всієї інфраструктури підприємства може збігтися з важливим моментом в життєдіяльності організації, то можуть виникнути серйозні труднощі, як з боку замовника, так і з боку групи, розгортає доменні служби в організації.
Приклад фрагмента угоди про рівень надання послуг
Наводити весь документ угоди про рівень надання послуг недоцільно, так як його обсяг досить великий. Як приклад нижче наведена частина додатка такої угоди, в якій відображені рівні складності підтримки, які включають в себе такі компоненти як час відгуку на виниклі інциденти, а також орієнтовний час, призначене для вирішення проблем різної складності:
Рівні складності підтримки
У разі виникнення проблемних ситуацій, що виникли після закінчення процесу розгортання інфраструктури доменних служб реалізованих стороною виконавця, час відгуку залежить від рівня складності несправності, які надані в следующе таблиці: