Планирование внедрения служб Active Directory

В организациях среднего и крупного бизнеса для обеспечения идентификации, доступа, упрощения управления и аудита пользователями и ресурсами, а также создания масштабируемой, безопасной и управляемой инфраструктуры целесообразно разворачивать доменные службы 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. И поскольку контроллер домена только для чтения поддерживает только ограниченный набор учетных записей пользователей, то в случае его взлома или физического хищения ущерб безопасности будет также ограниченным.

Учтите, что бизнес-требования могут конфликтовать с требованиями безопасности, поэтому вам необходимо искать наиболее оптимальные варианты, чтобы организация была максимально защищена не обходя все требования предоставленные вам заказчиком.

Проектные ограничения к документации

Проектное ограничение определяет параметры всего проекта и согласовывается специальной проектной группой с соглашением об уровне предоставления услуг и бизнес-требованиям организации. Основными составляющими такого ограничения являются ограничения возможностей, ресурсные ограничения, а также ограничения графика проекта. Простым примером ограничения возможностей может послужить не совместимость компании или недоступность перехода на новый продукт, в связи с чем, необходимо отказаться или от внедрения нового проекта, или от модификации самой области проекта. Всем известно, что основной составляющей ресурсных ограничения является бюджет самого проекта, то есть, если у организации-заказчика недостаточно материальных средств для приобретения необходимого оборудования, то продолжить развертывание доменных служб в организации опять не получится. Также на реализацию всего проекта может повлиять график реализации проекта и, если модификация всей инфраструктуры предприятия может совпасть с важным моментом в жизнедеятельности организации, то могут возникнуть серьезные трудности, как со стороны заказчика, так и со стороны группы, разворачивающей доменные службы в организации.

Пример фрагмента соглашения об уровне предоставления услуг

Приводить весь документ соглашения об уровне предоставления услуг нецелесообразно, так как его объем достаточно большой. В качестве примера ниже приведена часть приложения такого соглашения, в которой отображены уровни сложности поддержки, которые включают в себя такие компоненты как время отклика на возникшие инциденты, а также ориентировочное время, предназначенное для решения проблем разной сложности:

Приложение 3.Б

Уровни сложности поддержки

В случае возникновения проблемных ситуаций, появившихся по окончании процесса развертывания инфраструктуры доменных служб реализованных стороной исполнителя, время отклика зависит от уровня сложности неисправности, которые предоставлены в следующе таблице:

Время инцидента, предназначенное для решения проблем разной сложности

Время инцидента (ориентировочное время), предназначенное для решения проблем вычисляется как разница между временем назначением исполнителем и временем полного закрытия проблемы.