Организационно-штатная структура компании "Рога Копыта"

Размещено на http://www.allbest.ru/

Введение

операционный windows доменный пространство

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

Одним из таких механизмов, заслуживающим особого внимания является служба каталогов Active Directory. «Активный каталог» -- служба каталогов корпорации Microsoft, разработанная для операционных систем семейства Windows NT. Active Directory позволяет администраторам использовать групповые политики для обеспечения единообразия настройки пользовательской рабочей среды, разворачивать программное обеспечение на множестве компьютеров через групповые политики или посредством System Center Configuration Manager (ранее Microsoft Systems Management Server), устанавливать обновления операционной системы (ОС), прикладного и серверного программного обеспечения (ПО) на всех компьютерах в сети, используя Службу обновления Windows Server [5]. Поскольку данная служба каталогов хранит данные и настройки среды в централизованной базе данных, а для аутентификации пользователей по умолчанию используется надежный протокол Kerberos, это позволяет использовать данный механизм не только в коммерческих компаниях, но и в сферах, требующих повышенной защиты. А интегрирование службы Active Directory с DNS и стеком протоколов TCP/IP в значительной степени упрощает развертывания и настройку данной службы каталогов для сетевых администраторов.

Представление Active Directory состоялось в 1999 году, продукт был впервые выпущен с Windows 2000 Server, а затем подвергался модификации и улучшению при выпуске всех последующих серверных операционных систем семейства Windows Server, вплоть до Windows Server 2008 и Windows Server 2008 R2.

В ходе выполнения данной работы были рассмотрены вопросы определения необходимого количество лесов для организации, порядка их разбиения на домены, планирования доменного пространства имен организации и структуры доменов, определены механизмы разделения ресурсов компании по организационным подразделениям, рассмотрены основные вопросы (проблемы) конфигурации сайтов и разработана стратегия для управления учетными записями пользователей компании, а также произведено тестовое развертывание разработанной модели каталога Active Directory на база серверной операционной системы Windows Server 2008 применительно к центральному офису компании.



1.Определение количества лесов для сети компании

1.1 Определение леса

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

Согласно определению, лесом называется набор из одного либо нескольких доменов Active Directory (административных единиц внутри которых совместно используются определенные возможности и характеристики), не образующих непрерывного пространства имен. Он представляет собой наивысший уровень иерархии логической структуры доменных служб. Первый установленный в лесу домен называется корневым. Лес содержит единственное описание конфигурации и один экземпляр каталога схемы, хранящийся в корневом домене. В связи с этим крайне нежелательным является переименование или удаление корневой домен, поскольку это повлечет за собой удаление всего леса Active Directory [4].

Леса представляют собой крайние границы зон безопасности. Между лесами невозможно административное управление или пользовательский доступ, если на то нет явного разрешения в конфигурации. Для этого предназначен тип доверия, введенный в Windows Server 2003, -- доверие к лесу (forest trust), применяемый при управлении отношениями между двумя лесами.

Доверительные отношения - это специальный механизм, позволяющий объектам в одном домене/лесе (доверяемом) обращаться к ресурсам в другом (доверяющем). При этом стоит отметить, что доверие к лесу не является транзитивным на уровне лесов, т.е., если первый лес доверяет второму, а второй -- третьему, то это еще не означает, что первый автоматически доверяет третьему. Также необходимо учитывать, что для использования доверия к лесу нужно, чтобы оба леса находились на функциональном уровне Windows 2008 -- все контроллеры доменов в обоих лесах должны работать под управлением Windows Server 2008 [2].

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

1.2 Единый лес

Данная модель является простейшей моделью леса и считается низкоуровневой, так как все объекты каталога принадлежат одному лесу и все сетевые ресурсы контролирует одна централизованная ИТ-группа. Такой проект требует минимальных административных расходов и считается самым рентабельным среди всех моделей. Модель одного леса является удачным выбором для малых и средних организаций, где действует лишь одна ИТ-группа и все ее филиалы управляются этой группой из центрального офиса [3].

Преимущества:

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

- Аутентификация Kerberos: обеспечивает обоюдную аутентификацию и делегирование полномочий.

- Автоматические транзитивные доверительные отношения: между всеми доменами в лесе созданы транзитивные доверительные отношения в иерархическом порядке.

- Один глобальный каталог объектов: информация всех объектов леса сохраняется в каталоге, в котором можно выполнять поиск.

- Низкая стоимость.

Недостатки

- Невозможность обеспечить независимость от владельцев служб: невозможность обеспечить автономность службы одного леса, если нет согласия в настройке конфигурации службы.

- Невозможно обеспечить изоляцию от владельцев служб: администратор организации может аннулировать параметры безопасности, установленные владельцами отдельных доменов.

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

1.3 Несколько лесов

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

Реализация данной структуры допускается в следующих случаях:

Объединение двух существующих организаций

Независимо от того, слияние это или поглощение, можно столкнуться с тем, что появятся два полностью раздельных леса, которые нужно связать друг с другом для совместного использования ресурсов.

2) Создание автономного подразделения.

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

Административная автономия предполагает полный административный контроль над некоторыми компонентами леса на уровне леса, домена или подразделения. Тем не менее, автономия не означает получения эксклюзивного контроля. Существуют администраторы с более широкими полномочиями, которые тоже могут управлять этими ресурсами и при необходимости могут лишить полномочий подчиненных администраторов.

Создание изолированного подразделения

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

Однако, прежде чем приступить к планированию структуры нескольких лесов, необходимо принять к сведению, что большая часть функциональности, доступной в пределах одного леса, недоступна между лесами. Кроме того, поддержка нескольких лесов требует значительно больше усилий в администрировании, чем поддержка одного леса [2].

Архитектура с несколькими лесами имеет следующие недостатки:

При поиске ресурсов от пользователей требуется более высокий уровень подготовки.

Сотрудники, которым требуется входить на компьютеры, включенные во внешние леса, должны указывать при входе основное имя пользователя (User Principal Name, UPN) по умолчанию.

Администраторам приходится хранить несколько схем.

Для каждого леса используются отдельные контейнеры конфигурации. Изменения в топологии необходимо реплицировать в другие леса.

Любую репликацию информации между лесами приходится настраивать вручную.

Администраторам приходится настраивать списки управления доступом (ACL) к ресурсам, чтобы соответствующие группы из разных лесов могли обращаться к этим ресурсам, а также создавать новые группы, чтобы можно было использовать роли одних лесов в других лесах.

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

В соответствие с данными задания компания «Рога&Копыта» осуществляет свою деятельность на территории Украины и имеет древовидную топологию объединяющая центральный офис, находящийся в г. Киеве, с региональными центрами: западный (Львов), восточный (Донецк), центральный (Чернигов), южный (Симферополь), а региональные центры - с областными подразделениями. При этом в соответствие с основными задачами центрального подразделения компании головной офис должен обеспечивать и организовывать производственную деятельности компании, вести финансово-коммерческую деятельность и координировать и организовывать работы региональных центров. Очевидно, что для выполнения данных целевых задач, структурная схема каталога Active Directory должна предоставлять возможности централизованного управления всей деятельностью компании, включая удаленные филиалы. Кроме того, коммерческая компания «Рога&Копыта» имеет единый центр управления, а региональные центры являются подотчетными центральному офису организации и не нуждаются в административной автономии либо изоляции. В связи с этим наиболее предпочтительной моделью развертывания Службы каталогов представляется Модель единого леса.



2.Определение порядка разбиения лесов

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

Домен - единая область, в пределах которой обеспечивается безопасность данных в компьютерной сети под управлением ОС Windows. Это важнейшая часть в иерархической структуре корпоративной сети. Ей подчинены абсолютно все остальные структурные единицы, такие как серверы, приложения, пользовательские устройства и даже сетевые принтеры. Они используются для разделения большого леса на более мелкие компоненты для целей репликации или администрирования и являются основным и важнейшим элементом логической структуры Службы каталогов [1].

Основными свойствами домена, которые необходимо учитывать при планировании доменной структуры являются:

1) Граница репликации: границы домена являются границами репликации для раздела домена каталога и для информации домена, хранящейся в папке Sysvol на всех контроллерах домена. В то время как другие разделы каталога (раздел схемы, конфигурации и GC) реплицируются по всему лесу, раздел каталога домена реплицируется только в пределах одного домена.

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

3) Граница политики безопасности: некоторые политики безопасности могут быть установлены только на уровне домена, например, политика паролей, политика блокировки учетных записей и политика билетов Kerberos, применяются ко всем учетным записям домена.

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

2.1 Применение одного домена

Простейшая модель Active Directory -- единственный домен. В модели с единственным доменом все объекты находятся в одной зоне безопасности, поэтому не приходится заниматься планированием доверительных отношений с другими доменами или реализовать кросс-доменные аутентификацию и разрешения. Кроме того, при использовании одного домена гораздо проще обеспечить централизованное управление сетью. Модель с единственным доменом упрощает управление пользователями и группами, а также реализацию групповых политик. По сути, становится легче выполнять почти все операции по управлению сетью, а значит, требуется меньше усилий на планирование, администрирование и устранение неполадок, что в итоге приведет к сокращению общих затрат [2].

Преимущества:

- упрощение управления пользователями и группами.

- нет необходимости планировать доверительные отношения.

- для делегирования прав применяются организационные подразделения.

Недостатком использования модели с единым доменом в лесу можно назвать сложность технической реализации развертывания одного домена и непрактичность данного решения в случае большой территориальной распределенности ресурсов производственной компании, для которой выполняется развертывание Службы каталогов.

Поскольку производственно - коммерческая компания «Рога&Копыта» осуществляет свою деятельность на всей территории Украины и имеет многоуровневую и хорошо разветвленную древовидную структуру организации филиалов, использование схемы развертывания леса с единым доменном представляется экономически, технически и организационно нецелесообразным.

2.2 Использование нескольких доменов

Хотя однодоменная модель дает существенное преимущество -- простоту, иногда приходится использовать несколько доменов. Использование многодоменной структуры леса является предпочтительным в тех случаях, если:

1) Трафик репликации должен быть ограничен: раздел каталога домена, который является самым большим и наиболее часто изменяемым разделом каталога, копируется на все контроллеры домена в домене.

2) Между офисами компании существуют медленные сетевые подключения или в офисах имеется много пользователей: единственный способ ограничить в этом случае трафик репликации состоит в том, чтобы создать дополнительные домены.

3) Любые офисы компании, связь между которыми обеспечивается только простым протоколом передачи почты (SMTP), должны конфигурироваться как отдельные домены: информация домена не может реплицироваться через связи сайта, использующие протокол SMTP.

4) Единственный способ иметь различную политику паролей, политику блокировки учетных записей и политику билетов Kerberos состоит в развертывании отдельных доменов.

5) Необходимо ограничивать доступ к ресурсам и иметь административные разрешения.

6) В некоторых случаях дополнительные домены создаются потому, что лучший путь перехода для организации состоит в модернизации нескольких уже имеющихся доменов.

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

Особенности многодоменной модели:

- возможность реализации разных политик безопасности.

- децентрализованное управление.

- оптимизация трафика.

- разные пространства имен.

- необходимо сохранить существующую архитектуру доменов Windows NT.

- размещение хозяина схемы в отдельный домен.

Поскольку производственно - коммерческая компания «Рога&Копыта» имеет территорильно-распределенную организационную структуру более предпочтительной моделью разбиения леса представляется проектирование нескольких доменов в соответствие с территориальным признаком.

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

На основе анализа приведенных моделей построения леса для рассматриваемой компании «Рога &Копыта» наиболее целесообразной представляется модель единого леса, в котором каждый регион являться дочерним доменом центрального домена. Данный выбор основывался на следующих выводах:

1) Поскольку, региональные домены являются дочерними, между ними и центральным офисом автоматически создаются транзитивные доверительные отношения, что избавляет администратора от ручного конфигурирования доверия между доменами, как этого требую иные две модели;

2) Сокращение количества компьютеров - контроллеров домена из-за отсутствия корневого "пустого" домена, что в свою очередь ведет к снижению экономических затрат на развертывание и поддержания доменной структуры;

3) Структурное подчинение регионов, позволяющие реализацию централизованного управления филиалами из головного офиса.



3.Определение порядка назначения доменных имен и проектирование инфраструктуры DNS

3.1 Общие сведения

Следующим этапом планирования развертывания службы каталогов является проектирование инфраструктуры DNS.

DNS (англ. Domain Name System -- система доменных имён) -- компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись) [5].

Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу. Основой DNS является представление об иерархической структуре доменного имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения -- другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.

Система DNS поддерживает иерархическую структуру именования. Имена начинаются с корня и расширяются при добавлении уровней в иерархию. Реальным корнем иерархии DNS является сама точка (.). Однако эта точка не используется в именовании Интернета. Обычно в Интернете регистрируются стандартные корневые имена, такие как .com. .biz, .net, .info, .ms, .edu, .gov, .org и т. д. Организации могут связываться с Интернетом, присоединяя к корневому имени общее имя. Например, иерархия Microsoft.com содержит два уровня ниже корневого имени и три -- ниже реального корня DNS (Рис.3.1); имя Technet.microsoft.com содержит три уровня шоке имени и четыре -- ниже корня DNS [1].

Рис.3.1 - Иерархия DNS

В сети Windows Server 2008 с доменными службами Active Directory (AD DS) каждое связанное с каталогом устройство также будет связано с системой разрешения имен DNS, на которую оно будет полагаться при идентификации всех служб во время взаимодействия. Например, при загрузке компьютера, присоединенного к домену, выполняется стандартный процесс, который начинается с идентификации записей ресурсов SRV (Service Location Record) на DNS-сервере для определения ближайшего контроллера домена. Затем, после выполнения системой DNS своей части работы, начинается процесс проверки подлинности между компьютером и контроллером домена. Однако без разрешения системой DNS имен записей ресурсов SRV службам AD DS будет довольно сложно выполнить проверку подлинности рядового компьютера [1].

Однако, поскольку в службе Active Directory все домены имеют DNS-имена, прежде чем использовать данную службу в сети, необходимо спланировать пространство имен DNS. Ключевое решение проекта состоит в том, чтобы определить, где расположить домены Active Directory в пределах этого пространства имен[2]. Проектирование инфраструктуры DNS состоит из нескольких этапов.



3.2 Исследование существующей инфраструктуры DNS

Первый шаг в проектировании инфраструктуры DNS должен состоять в исследовании уже имеющейся инфраструктуры DNS. В большинстве случаев служба DNS в Active Directory должна взаимодействовать с имеющейся инфраструктурой DNS. Это может означать просто конфигурирование ретранслятора в существующем сервере DNS, использование имеющегося DNS-сервера как основного для Active Directory или отсутствие развертывания DNS в Windows Server 2008. Active Directory требует, чтобы работала служба DNS, однако существует несколько вариантов ее развертывания [5].

3.3 Выбор доменных имен DNS

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

Для внедрения Active Directory существуют два вида пространств имен (внутреннее и внешнее), при этом пространство имен Active Directory совпадает с заданным зарегистрированным пространством имен DNS или отличается от него.

3.4 Совпадающие внутреннее и внешнее пространства имен

Согласно этому сценарию, организация использует одно и то же имя для внутреннего и внешнего пространств имен - имя компании применяется как внутри, так и вне организации. При реализации этого сценария пользователи внутренней частной сети компании должны иметь доступ как к внутренним, так и к внешним серверам (по обе стороны брандмауэра). Для защиты конфиденциальной информации клиенты, осуществляющие доступ извне, не должны иметь доступ к внутренним ресурсам компании или иметь возможность разрешать свои имена. Кроме того, необходимы две раздельные зоны DNS, одна из которых, за пределами брандмауэра, обеспечивает разрешение имен для общедоступных ресурсов. Она не сконфигурирована для разрешения имен внутренних ресурсов, поэтому доступ к ним извне получить нельзя [2].

3.5 Отличающиеся внутреннее и внешнее пространства имен

В этом случае компания использует различные внутреннее и внешнее пространства имен - изначально в зонах по разные стороны брандмауэра имена различаются. Для этого необходимо зарегистрировать два пространства имен в DNS Интернета. Если имя не зарезервировано, внутренние клиенты не смогут отличить внутреннее имя от имени, зарегистрированного в общедоступной сети пространства имен DNS. Таким образом, устанавливаются две зоны: одна отвечает за разрешение имен во внешнем пространстве, другая - во внутреннем. Пользователям не составит труда различать внутренние и внешние ресурсы [1].

Для рассматриваемой в данной работе производственной компании «Рога&Копыта», основной задачей которой является осуществление производственно-коммерческой деятельности на территории Украины, что автоматически предусматривает предоставление авторизованным клиентам доступа к определенным выделенным ресурсам компании предлагается выбрать модель Совпадающего внутреннего и внешнего пространства имен. Выбор данной модели предполагается экономически более целесообразным, поскольку не требует дополнительных расходов на регистрацию второго пространства имен. Возникающие же при выборе данной модели вопросы защиты конфиденциальной информации предприятия предлагается решить за счет разработки и последующего внедрения соответствующей политики безопасности, предполагающей, в частности, предоставление доступа только авторизованных клиентов компании и только к ограниченному списку ресурсов предприятия.

Результаты проектирования порядка назначения доменных имен представлены в Приложении Г. Разработанная в соответствие с выбранными ранее моделями построения единого леса, в котором каждый домен является дочерним доменом центрального домена, предлагает назначение доменных имен в соответствие с территориальным признаком. Для центрального домена предлагается выбрать имя RGCenter.Gonchar.com, для дочерних доменов, являющихся региональными центрами, имена, указывающие территориальное положение региона в соответствие со стороной света - South.RGCenter.Gonchar.com, West. RGCenter.Gonchar.com, East. RGCenter.Gonchar.com и North. RGCenter.Gonchar.com.

3.6 Проектирование структуры OU

После определения структуры домена организации и планирования доменного пространства имен необходимо разработать структуру организационных единиц (organizational unit (OU) или подразделений - ОП). OU позволяют разделить домен на зоны административного управления, т.е. создавать единицы административного управления внутри домена [1].

Проектирование OU позволяет:

1) Отразить структуру компании и организации внутри домена: без OU все пользователи поддерживаются и отображаются в одном списке независимо от подразделения, местоположения и роли пользователя;

2) Делегировать управление сетевыми ресурсами, но сохранить способность управлять ими, то есть присваивать административные полномочия пользователям или группам на уровне OU;

3) Изменять организационную структуру компании;

4) Группировать объекты так, чтобы администраторы легко отыскивали сетевые ресурсы.

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

Стоит отметить, что при планировании иерархии OU важно соблюсти следующие правила:

- Хотя глубина иерархии OU не ограничена, производительность мелкой иерархии выше, чем глубокой.

- OU должны отражать неизменные структурные единицы организации.

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

Поскольку OU имеют иерархическую структуру в них можно выделить верхний и нижний уровни. Особое внимание следует уделить верхнему уровню структуры OU, который всегда должен отражать относительно неизменную часть структуры предприятия, чтобы его не приходилось изменять в случае реорганизации [3].

На этапе планирования развертывания Active Directory важно определить на основание какого критерия или критериев будет разрабатываться структура OU компании. Стандартных модели, которые могут быть положены в основу иерархии OU приведены в Приложении Д.

Для рассматриваемой в данной работе производственной компании «Рога&Копыта» предполагается использовать две различные модели для центрального и региональных доменов. В центральном домене предлагается выбрать Модель структуры OU на основе структуры организации, поскольку она позволяет обеспечивать определенный уровень автономии для каждого отдела и упрощенное администрирование. Для региональных же доменов предлагается использовать Смешанную модель структуры OU - сначала по местоположению, затем по структуре организации. Данный выбор позволяет отразить структуру компании внутри каждого домена и упрощает для администраторов обеспечение различных требований безопасности каждого из отделов организации. Это является весьма важным фактором, поскольку в ряде отделов рассматриваемой в работе организации предполагается циркулирование конфиденциальной информации не предназначенной для широкого пользования. А использование в смешанной модели распределения OU вначале по местоположению позволяет отразить географическое местоположение филиалов, а также способствует устойчивости модели в случае реорганизации. Результаты разработки структуры OU компании «Рога&Копыта» представлены в Приложении Е.



4.Разработка стратегии управления учетными записями пользователей и группами безопасности на предприятии

Следующим этапом в планировании развертывания Службы каталогов Active Directory после определения механизма разделения ресурсов компании по организационным подразделениям является разработка стратегии управления учетными записями пользователей компании и требований к группам безопасности предприятия.

Принципалы безопасности (Security Principal), которые предоставляют пользователей, группы или компьютеры, которым требуется доступ к определенным ресурсам в сети, являются основополагающим компонентом доменных служб в каждой организации. Именно таким объектам, как принципалам безопасности можно предоставлять разрешения доступа к ресурсам в сети, причем каждому принципалу во время создания объекта присваивается уникальный идентификатор безопасности (SID) - числовое представление, которое уникально идентифицирует принципал безопасности [3].

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

4.1 Учетные записи пользователей

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

Объекты учетных записей пользователей можно отнести к самым распространенным объектам в Active Directory. Такие объекты представляют собой набор атрибутов, причем только одна пользовательская учетная запись может содержать свыше 250 различных атрибутов, что в несколько раз превышает количество атрибутов на рабочих станциях и компьютеров, работающих под операционной системой Linux. Важно обратить внимание на то, что одни атрибуты являются обязательными (основными), а остальные опциональными (вспомогательными). Основных атрибутов учетной записи шесть: CN (Full name), SAM Account Name (User Logon Name), Instance Type, Object Category, Object Class, Object SID. Первые два вышеперечисленных атрибута конфигурируются на основе данных, обеспечиваемых при создании учетной записи, а остальные конфигурируются автоматически.

Учетные записи пользователей позволяют идентифицировать пользователей, входящих в сеть, задавать, к каким ресурсам они вправе обращаться, и указывать о них всевозможную информацию. Администраторы также являются пользователями, но с более широкими правами доступа к ресурсам, связанным с управлением сетью. Учетные записи пользователей предоставляют пользователям возможность входить в домен или на локальный компьютер и обращаться к ресурсам. Объекты учетных записей пользователей содержат информацию о пользователях и связывают с ними определенные привилегии или ограничения. Каждый объект Active Directory связан со списком управления доступом (AccessControl List, ACL), который представляет собой список разрешений на доступ к объекту, заданных для пользователей и групп [2].

В Windows Server 2008 существует два основных типа учетных записей пользователей:

Локальные учетные записи пользователей, создаваемые в базе данных защиты локального компьютера и управляющие доступом к ресурсам этого компьютера, являющегося изолированным или входящим в рабочую группу.

Доменные учетные записи пользователей, создаваемые в Active Directory и дающие возможность пользователям входить в домен и обращаться к любым ресурсам сети. Такие учетные записи пользователей реплицируются на все контроллеры в домене, поэтому после репликации любой контроллер домена сможет аутентифицировать пользователя.

Помимо этих учетных записей, Windows Server 2008 автоматически создает несколько таких учетных записей пользователей, которые называются встроенными. И на локальных компьютерах, и в доменах создается две ключевые учетные записи Администратор и Гость [6].

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

Контроллеры домена должны проверять идентификацию пользователя или компьютера, прежде чем предоставить доступ к системным и сетевым ресурсам. Такая проверка называется аутентификацией и выполняется всякий раз при входе в сеть.

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

- политика блокировки учетных записей;

- ограничение времени, в которое разрешен вход;

- политика истечения сроков билетов (tickets) (значение по умолчанию - 10 часов);

- не использовать административные учетные записи для обычной работы.

- переименовать или отключить встроенные учетные записи.

Еще одним важнейшим аспектом, на котором строится сетевая безопасность являются пароли, поскольку при аутентификации пользователь удостоверяет свою личность введением своего логина и пароля. В связи с этим политику определения паролей пользователей необходимо тщательно продумать и жестко регламентировать, программно ограничив рядовому пользователю любые возможности несоответствия предъявляемым политикой паролей требованиям [2].

4.2 Стратегия управления учетными записями пользователей компании

Создание учетных записей пользователей Active Directory может осуществляться путем использования одной из нижеследующих средств:

- через интерфейс средствами оснастки Active Directory Users and Computers; - посредством команды командной строки (dsadd);

- через утилиты CSVDE и LDIFDE;

- посредством оболочки Windows PowerShell.

Кроме того, при создании учетной записи пользователя через интерфейс средствами оснастки Active Directory Users and Computers для создания нескольких типовых пользователей могут быть использованы шаблоны учетных записей пользователей. Это специально созданные, отключенные учетные записи, содержащие уже настроенные типовые установки и свойства.

Таким образом, основываюсь на анализе существующей организационный структуры рассматриваемого в работе предприятия, а также на базе вышеозначенных правил и рекомендаций по разработке стратегии управления учетными записями пользователями, были разработаны и предложены следующие основные элементы механизма управления учетными записями для предприятия «Рога&Копыта».

1. Поскольку численность центрального подразделения компании составляет 100 человек, а количество рабочего персонала в каждом из 26 структурных (областных) подразделений компании насчитывается в диапазоне от 300 до 500 человек, для упрощения создания учетных записей пользователей в каждом из организационных подразделений предлагается создать шаблоны учетных записей пользователей с базовыми настройками, соответствующими характеристикам персонала соответствующего отдела предприятия. Таким образом, при добавлении новых работников в отдел администратору не нужно будет задавать весь перечень свойств новой учетной записи, а лишь изменить некоторый типовые настройки.

2. При назначении основного имени пользователя UPN придерживаться следующего формата: Инициалы.Фамилия.Должность, с целью облегчения идентификации и запоминания имен пользователей.

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

4. Разрешенное время входа в домен для всех учетных записей пользователей без исключения ограничивается рабочим временем предприятия - с 8:00 до 20:00 в будние дни и запрещено в выходные.

5. Пароль учетных записей пользователей должен быть не менее 10 символов для пользователей группы Рабочие, не менее 15 символов - для участников группы Руководители отделов и не менее 17 символов для членов групп Президенты и административных учетных записей.

6. Срок действия пароля 45 дней.

7. Блокирование входа в случае 5-кратной ошибки аутентификации для обычных пользователей и 3-кратной для пользователей, входящих в группы Руководители отделов, Президенты и административных учетных записей.



4.3 Планирование групп безопасности

Как уже было сказано ранее назначать доступ к сетевым ресурсами рекомендуется группам, а не индивидуально для каждого отдельного пользователя, поскольку в противном случае списки контроля доступа ACL вскоре станут неуправляемыми и при изменении отдела пользователем администратору нужно будет учесть все возможные разрешения доступа. Чаще всего группы используются для идентификации ролей пользователей и компьютеров, фильтрации групповой политики, назначения уникальных политик паролей, прав, разрешений доступа, приложений электронной почты и многое другое. Сами по себе, группы представляют собой принципалы безопасности с уникальными SID, которые могут содержать в атрибуте Member такие принципалы безопасности, как пользователи, компьютеры, группы и контакты.

Active Directory включает в себя два типа групп (безопасности и распространения) домена с тремя областями действия (локальная в домене, глобальная и универсальная) в каждой из них.

Группы безопасности - относятся к принципалам безопасности с SID-идентификаторами. В связи с этим данный тип группы считается самым распространенным и группы такого типа можно использовать для управления безопасностью и назначения разрешений доступа к сетевым ресурсам в списках ACL. В свою очередь, группа распространения изначально используется приложениями электронной почты, и она не может быть принципалом безопасности. Кроме того, важно также отметить, что группы безопасности можно использовать как с целью назначения доступа к ресурсам, так и с целью распространения электронной почты, что в свою очередь позволяет организации использовать только этот тип группы [3].

Область действия группы определяет диапазон, в котором применяется группа внутри домена. Помимо того, что группы могут содержать пользователей и компьютеры, они могут быть членами других групп, ссылаться на списки ACL, фильтры объектов и групповых политик и пр. Граница диапазона области действия группы может определяться заданием режима работы домена [4].

В Active Directory существует три области действия групп, рассмотрим подробнее каждую из них:

Локальная группа в домене - предназначена для управления разрешениями доступа к ресурсам и функционируют в том случае, если домен работает на функциональном уровне не ниже Windows 2000. Локальную группу в домене можно добавлять в списки ACL любого ресурса на любом рядовом компьютере домена. В локальную группу в домене могут входить пользователи, компьютеры, глобальные и локальные группы в текущем домене, любом другом домене леса, а также универсальные группы в любом домене леса. В связи с этим, локальные группы в домене обычно используют для предоставления правил доступа во всем домене, а также для членов доверительных доменов.

Глобальная группа - основной целью данной группы безопасности является определение коллекции объектов доменов на основании бизнес-правил и управление объектами, которые требуют ежедневного использования. Глобальная группа может содержать пользователей, компьютеры и другие глобальные группы только из одного домена. Несмотря на это, глобальные группы могут быть членами любых универсальных и локальных групп как в своем домене, так и доверяющем домене. Помимо этого, глобальные группы можно добавлять в списки ACL в домене, лесу и в доверяющем домене, что делает управление группами более простым и рациональным.

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

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

4.4 Определение требование к группам безопасности на предприятии

Группы безопасности упрощают предоставление разрешений пользователям, поскольку назначить разрешения группе и добавить пользователей в эту группу гораздо проще, чем по отдельности назначать разрешения многочисленным пользователям и управлять этими разрешениями, а когда пользователи входят в группу, для изменения того или иного разрешения всех этих пользователей достаточно одной операции. В связи с этим для управления разрешениями доступа к ресурсам производственной компании «Рога&Копыта» приняты следующие решения:

1. Поскольку верховный административный менеджмент предприятия должен иметь неограниченный доступ к информационным ресурсам предприятия от президента до начальников региональных центров компании (Приложение А), к группе безопасности, в которую должны входить учетные записи этих пользователей предъявляются следующие требования:

- назначенные разрешения должны действовать при попытке доступа к ресурсам нескольких доменов;

- группа должна существовать вне границ доменов;

- в группу могут входить пользователей и другие группы в пределах леса.

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

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

3. Поскольку рядовой персонал центрального офиса и подразделений не требуется доступ к ресурсам компании вне пределов их домена, для них предлагается создавать локальную группу безопасности Рабочие.



5.Конфигурация сайтов

Финальным этапом в планировании развертывания Службы каталогов Active Directory является определение физической инфраструктуры компании и планирование на ее основе конфигурации сайтов, позволяющей оптимизировать трафик Службы каталогов, протекающий в компьютерной сети предприятия.

Сайт - это группа контроллеров домена, которые расположены в единой или нескольких IP-подсетях, связанных быстрым и надежным сетевым соединением. Поскольку сайты основаны на IP-подсетях, они обычно соответствуют топологии сети, а значит соответствуют и географической структуре компании. Сайты соединяются с другими сайтами WAN-каналами. Если домены Active Directory - основные элементы логической структуры Службы каталогов, то сайты являются элементами физической структуры.

Таким образом, структура сайта связана с физической средой и поддерживается отдельно от логической среды и структуры домена, позволяя отделить логическую организацию структуры каталогов (структуры лесов, доменов и OU) от физической структуры сети. Стоит отметить, что поскольку сайты не зависят от структуры доменов, в один домен может входить несколько сайтов, или, наоборот, один сайт может содержать несколько доменов или частей нескольких доменов. Сайты содержат объекты только двух типов: контролеры доменов, входящие в сайт, и связи сайтов (site links), настраиваемые для соединения с другими сайтами [2]. В целом сайты служат для управления трафиком по WAN-каналам. Основная задача сайта - обеспечивать хорошее сетевое соединение.



5.1 Планирование структуры сайта

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

Основной информацией, учитываемой при разработке конфигурации сайтов являются данные о физической структуре сети и сведения о выбранной ранее логической архитектуре Active Directory.

5.2 Создание модели сайта

Как только информация о сети компании собрана, можно приступать к проектированию сайта. После определения количества сайтов для Active Directory осуществляется проектирование каждого сайта. Каждый сайт в ActiveDirectory связан с одной или более подсетями IP, поэтому нужно определить, какие подсети будут включены в каждый сайт. Также при проектировании сайта необходимо определить места размещения серверов, необходимых для обеспечения нужных служб каталога Active Directory, среди которых особо важными являются:

1) DNS-сервера

Без службы DNS пользователи не смогут находить контроллеры домена Active Directory, а контроллеры домена не смогут находить друг друга для репликации. DNS должна быть развернута в каждом офисе организации, за исключением, быть может, только очень маленьких офисов с несколькими пользователями [1].

2) Контроллеры домена

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

3) Сервера глобального каталога

GC-серверы нужны пользователям для входа на домены, которые работают на функциональном уровне Windows 2000, или когда пользователи делают поиск информации каталога в Active Directory. Если домен работает на основном функциональном уровне Windows 2000, то нужно поместить GC-сервер в каждый сайт. В идеале все это должно быть сбалансировано трафиком репликации, который создается в результате помещения GC-сервера в каждом сайте. Общее правило состоит в том, чтобы размещать GC-сервер в каждом сайте и несколько GC-серверов - в крупных сайтах [2].