Какие факторы влияют на определение размеров доменов безопасности

Планирование структуры доменов Active Directory на предприятии

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

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

Границы безопасности. При проектировании структуры доменов, границы политики безопасности имеют одно из важнейших значений. Некоторые политики безопасности, используемые на уровне домена, применяются ко всем учетным записям пользователей в этом домене. К таким политикам можно отнести политики паролей, политики блокировки учетных записей, политики Kerberos и многое другое. При сборе требований безопасности на уровне домена, вы должны учесть все возможные требования безопасности, которые будут применяться для всех групп вашей организации. В некоторых отделах группы пользователей могут нуждаться в более защищенных паролях к учетным записям, и поэтому вам приходится создавать подробные политики паролей, но когда количество таких пользователей увеличится, на поддержание безопасности таких групп вам понадобятся затратить большие административные усилия. В идеальном случае, для любой группы, которая имеет уникальные требования безопасности, рекомендуется разворачивать отдельный домен;
Административные границы. Сбор административных сведений позволит вам понять, каким образом будет реализовываться управление доменами и как можно эффективно разработать доменную структуру. Стоит учесть, что границы доменов также являются границами доступа к ресурсам. Изначально пользователи из одного домена не получают доступ к ресурсам в другом домене, если у них не отконфигурированы доверительные связи. На этом этапе вам нужно определить команды обслуживающего персонала, которые будут ответственны за управление доменными службами в вашей организации. Если какая-либо группа требует у вас административных привилегий, то для такой группы вам нужно будет создать новый домен;
Границы репликации. Границы домена являются границами репликации каталогов домена и информации, распложенной в папке SYSVOL на всех контролерах домена. Прежде всего, вам нужно определиться с расположением, в котором будут находиться пользователи, после чего, для каждого расположения определить количество пользователей и бизнес-единиц, к которым принадлежат пользователи. При проектировании структуры доменов важно учитывать доступную пропускную способность, использование сети и сведений о соединениях для каждого расположения вашей организации. В Active Directory предполагается, что на предприятии используется два типа сетей: высокоскоростные и более медленные. В том случае, если все расположения объединены в высокоскоростные сети, которые имеют широкую пропускную способность, дополнительная пропускная способность сети для репликации не потребуется, это означает, что будет достаточно только одного домена. Но если в вашей организации есть несколько филиалов, которые подключаются к центральному узлу с помощью ссылок WAN и могут оказаться перегруженными, дорогостоящими и нестабильными, целесообразно в таких случаях разворачивать дополнительные домены. Стоит обратить внимание на то, что репликация каталогов домена выполняется только в пределах своего домена.

Определение модели домена

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

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

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

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

Один домен целесообразно использовать для небольших и средних организаций исходя из следующих соображений:

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

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

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

Максимальное количество пользователей, содержащихся в домене, варьируется в зависимости от пропускной способности сети, предназначенной для репликации между доменами. Интенсивность трафика репликации существенно зависит от количеств изменений в каталоге за определенный промежуток времени. Например, если все контроллеры домена связаны сетью, скорость которой равняется 64 килобит в секунду с пяти процентной пропускной способностью для репликации доменных служб, то количество пользователей в домене составит 75 000, а при скорости 1500 килобит в секунду и пяти процентной пропускной способностью, максимальное количество пользователей составит 100 000.

Региональные домены целесообразно использовать в том случае, если поместить всех пользователей в один домен невозможно. Наилучшим способом разделения организации на регионы, является ее разделение на основании структуры и структуры сети. Например, если за рубежом разделяют домены на регионы в том случае, если границами выступают границы континентов, то в нашей стране принято определять границы доменов в зависимости от регионального размещения областей или автономных республик. В любом случае рекомендуется сводить к минимуму количество региональных доменов. Несмотря на то, что в лесах может быть неопределённое количество доменов, рекомендуется делить свою организацию не более чем на 10 доменов. Их выбор предопределяется следующими составляющими:

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

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

К недостаткам использования региональных доменов относится незащищённость от безответственности администраторов при разграничении сферы ответственности владельца леса и владельца домена; усложнение процесса администрирования в связи с возрастанием количества доменов; увеличение затрат на администрирование; увеличение объема репликации на уровне леса.

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

Проектирование корневого домена леса

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

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

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

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

Какие доменные зоны безопаснее?

Компания Architelos, предоставляющая услуги консультирования и менеджмента в доменной индустрии, недавно опубликовала результаты исследования безопасности доменных зон. Его предметом стали 72 доменные зоны и более 257 млн. доменов второго уровня, т.е. более 99% всех зарегистрированных имен. Для выявления потенциальных угроз применялась разработанная компанией технология NameSentry.

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

Среди всех зарегистрированных доменов опасными являются 0,4% (около 4000 на миллион).

90% опасных доменов распространяли спам, 6% — содержали вирусы или другой вредоносный софт. За год было зафиксировано 150 000 уникальных доменов, зарегистрированных для фишинга. Доменов, входящих в состав ботнетов, оказалось сравнительно мало, однако их потенциальная опасность очень высока.

Уровень безопасности 15 доменных зон (21%) Architelos оценила как отличный. В их числе — только два домена общего пользования: .tel и .xxx. Среди национальных зон самые безопасные — домены .no (Норвегия), .nz (Новая Зеландия), .ch (Швейцария), .cz (Чехия), .au (Австралия).

Хороший уровень безопасности — у 36 (50%) доменных зон. В их числе — два крупнейших национальных домена .de (Германия) и, как ни странно, .tk (Токелау). И это несмотря на то, что зона .tk, в которой можно получить домен бесплатно, уже давно пользуется дурной репутацией, не в последнюю очередь из-за сайтов с вредоносным контентом.

Удовлетворительный уровень безопасности — у 13 доменных зон. В эту категорию вошли крупнейшие домены общего пользования — .com, .net и .org, а также национальные домены .uk (Великобритания), .at (Австрия), .su (бывший СССР) и .eu (Евросоюз).

Худший уровень безопасности — у 7 доменов верхнего уровня. В их число, к сожалению, попал и российский домен .ru наряду с зонами .cn (Китай) и .us (США) и доменом общего пользования .info.

Информационная безопасность

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

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

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

Предоставление прав доступа субъектам должно быть основано на уровне доверия этому субъекту компанией и на принципе «необходимо знать» (need-to-know). Только тот факт, что компания полностью доверяет пользователю, еще не означает, что ему «необходимо знать» содержимое всех ресурсов компании. И, наоборот, если пользователю «необходимо знать» определенные файлы, которые нужны ему для работы, это не означает, что компания доверяет ему доступ ко всем остальным файлам. Эти вопросы должны быть определены и включены в критерии доступа (access criteria). Различные критерии доступа могут определяться ролями, группами, местонахождением, временем и типами транзакций.

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

Использование групп – другой эффективный способ распределения прав доступа. Если некоторым пользователям нужны одинаковые права доступа к информации и ресурсам, целесообразно поместить их учетные записи в одну группу, поскольку значительно проще управлять правами доступа и разрешениями группы, чем каждого пользователя в отдельности. Например, если права доступа к принтеру предоставлены только группе «Бухгалтерия», то когда пользователь попытается печатать на нем, система в первую очередь проверит, является ли он членом этой группы. Это один из способов обеспечения управления доступом посредством механизма логического управления доступом.

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

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

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

Механизмы управления доступом следует настроить таким образом, чтобы «по умолчанию» доступ ни к каким ресурсам не предоставлялся («no access»). Это позволит избежать многих незаметных «дыр» в безопасности. В операционных системах и приложениях существуют многочисленные варианты прав доступа, которые могут быть предоставлены пользователям и группам, например, «чтение», «запись», «удаление», «полный доступ», «нет доступа». Пока пользователю не предоставлены права индивидуально или пока он не включен в какую-либо специальную группу, у него не должно быть никаких прав доступа к ресурсам, т.е. пользователю должен быть запрещен доступ ко всем ресурсам, кроме тех, к которым он явно разрешен. Другими словами, все управление доступом должно быть основано на концепции старта с нулевым доступом и добавления прав по мере необходимости в соответствии с принципом «необходимо знать».

Например, большинство списков контроля доступа (ACL) на маршрутизаторах и межсетевых экранах с пакетной фильтрацией не предоставляют доступа «по умолчанию».

Принцип «необходимо знать» (need-to-know) похож на принцип наименьших привилегий (least-privilege). Принцип «необходимо знать» говорит о том, что человек должен иметь доступ только к той информации, которая ему совершенно необходима для выполнения своих должностных обязанностей. Предоставление излишних полномочий ведет к излишним проблемам и, вероятно, злоупотреблениям. Руководство должно решить, что пользователь должен знать или какие права доступа ему необходимы, а администратор должен настроить механизмы управления доступом таким образом, чтобы пользователь имел минимальный набор необходимых ему прав доступа, достаточный для выполнения пользователем своих обязанностей, и не более того.

Например, руководство решило, что Дэну, выполняющему обязанности по распечатке информации, необходимо знать, где хранятся файлы, подлежащие распечатке, и иметь возможность распечатывать их. Это и есть критерий «необходимо знать» для Дэна. Администратор мог бы дать Дэну полный доступ ко всем файлам, которые ему нужно печатать, однако это было бы нарушением принципа минимальных привилегий. Администратору следует ограничить доступ Дэна только правами на чтение и печать соответствующих файлов, не больше и не меньше. Иначе кто будет отвечать за то, что Дэн случайно удалит все файлы с файлового сервера? Конечно, администратор.

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

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

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

Повышение стоимости поддержки различных сред, соображения безопасности, пожелания пользователей – все вместе они привели к идее создания возможностей единого входа (SSO – single sign-on). SSO позволяет пользователям вводить свои учетные данные только один раз для получения возможности доступа ко всем ресурсам, что уменьшает время, которое пользователи тратят на процесс аутентификации. Также это позволяет администраторам рационализировать использование учетных записей и лучше управлять распределением прав доступа. SSO повышает безопасность, снижая вероятность того, что пользователь будет хранить свой пароль под клавиатурой – ведь теперь ему нужно запомнить гораздо меньше паролей (в идеале – один). Помимо этого, на повышение безопасности оказывает влияние и тот факт, что администраторы больше времени могут тратить на управление учетными записями и правами доступа пользователей, а не на сброс забытых ими паролей. Используя SSO, администратору проще приостановить или заблокировать учетную запись пользователя, т.к. нет необходимости делать это в каждой системе.

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

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

Kerberos (Цербер) – это имя трехголовой собаки в греческой мифологии, которая охраняла вход в подземный мир. Этим именем названа технология безопасности, которая реализует функции аутентификации и защищает активы компании. Kerberos – это протокол аутентификации, разработанный в середине 1980-х годов, как часть Проекта Афина MIT. Он работает на базе модели клиент-сервер и основан на криптографии с симметричным ключом. Этот протокол годами использовался в системах Unix, а в настоящее время применяется как стандартный метод аутентификации в современных серверных операционных системах Microsoft Windows. Операционные системы Apple Mac OS X, Sun Solaris и Red Hat Enterprise Linux также используют аутентификацию Kerberos. Все чаще появляются коммерческие продукты, поддерживающие Kerberos.

Kerberos – это пример системы SSO для распределенных сред и стандарт «де-факто» для гетерогенных сетей. Kerberos объединяет широкий круг технологий безопасности, предоставляя компаниям больше гибкости и масштабируемости при создании архитектуры безопасности. Он имеет четыре элемента, необходимые для корпоративного управления доступом: масштабируемость, прозрачность, надежность и безопасность. Однако эта открытая архитектура имеет некоторые проблемы совместимости. В основном они связаны с тем, что производители пользуются свободой настройки протокола, и каждый из них настраивает его по-своему, что и вызывает эти проблемы.

Kerberos использует криптографию с симметричным ключом и обеспечивает «сквозную» (end-to-end) безопасность. Хотя Kerberos использует пароли для аутентификации, он спроектирован таким образом, чтобы исключить необходимость передачи паролей по сети. Большинство реализаций Kerberos работает с общими секретными ключами.

Основные компоненты Kerberos

Центр распространения ключей (KDC – Key Distribution Center) – это самый важный компонент в среде Kerberos. Он хранит секретные ключи всех пользователей и служб. KDC реализует службу аутентификации и функции распространения ключей. Клиенты и службы доверяют целостности KDC, это доверие является основой безопасности Kerberos.

KDC предоставляет сервисы безопасности системным объектам (principal), которые могут быть пользователями, приложениями или сетевыми службами. KDC должен иметь учетную запись для каждого системного объекта и общий секретный ключ с каждым системным объектом. Для пользователей пароли преобразуются в значение секретного ключа. Секретный ключ используется для передачи критичной информации между системным объектом и KDC, а также для аутентификации пользователя.

Служба предоставления билетов (TGS – Ticket Granting Service) на KDC генерирует и передает системному объекту (например, пользователю) билет (ticket), когда ему нужно аутентифицироваться на другом системном объекте (например, сервере печати). Предположим, что Эмили нужно воспользоваться сервером печати. Для этого она должна доказать серверу печати, что она та, за кого себя выдает, и что она уполномочена использовать службу печати. Эмили запрашивает билет в TGS. TGS выдает Эмили билет, который она отправляет серверу печати. Если сервер печати принимает этот билет, Эмили разрешается использовать сервер печати.

KDC предоставляет сервисы безопасности набору системных объектов. Этот набор называется областью (realm) в Kerberos. KDC – это доверенный сервер аутентификации для всех пользователей, приложений и служб в рамках области. Один KDC может отвечать за одну или несколько областей. Области позволяют администратору логически группировать ресурсы и пользователей.

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

Процесс аутентификации Kerberos

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

Эмили приходит на работу в 8 часов и вводит свое имя и пароль на своей рабочей станции.
Программное обеспечение Kerberos на рабочей станции Эмили отправляет ее имя службе аутентификации (AS – Authentication Service) на KDC, которая в свою очередь отправляет ей билет для получения билета (TGT – Ticket Granting Tiket) зашифрованный на пароле Эмили (секретном ключе, хранящемся в KDC).
Если Эмили ввела правильный пароль, она сможет расшифровать TGT и получить доступ к рабочему столу своей локальной рабочей станции.
Когда Эмили потребуется отправить задание на сервер печати, ее система отправит TGT службе предоставления билетов (TGS), запущенной на KDC. Это позволит Эмили доказать, что она была аутентифицирована и позволит ей запросить доступ к серверу печати.
TGS создает и отправляет второй билет Эмили, который она будет использовать для аутентификации на сервере печати. Этот второй билет содержит два экземпляра одного и того же сеансового ключа, один из которых зашифрован на секретном ключе Эмили, а второй – на секретном ключе сервера печати. Также, в этот второй билет входит аутентификатор , содержащий идентификационную информацию Эмили, IP-адрес ее системы, порядковый номер и штамп времени.
Система Эмили получает второй билет, расшифровывает его и извлекает сеансовый ключ, добавляет в него второй аутентификатор, содержащий идентификационную информацию, и отправляет билет серверу печати.
Сервер печати получает билет, расшифровывает его, извлекает сеансовый ключ, а затем расшифровывает и извлекает два аутентификатора. Если сервер печати может расшифровать и извлечь сеансовый ключ, он может быть уверен, что билет создал именно KDC, т.к. только KDC имеет секретный ключ этого сервера печати. Если информация из аутентификаторов (один из которых помещен в билет KDC, а другой – пользователем) совпадает, сервер печати может быть уверен, что билет получен от корректного системного объекта (пользователя).
После завершения этого процесса, Эмили считается успешно аутентифицированной на сервере печати, и сервер печатает ее документ.

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

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

Если реализация Kerberos настроена на использование аутентификатора , пользователь отправляет серверу печати свою идентификационную информацию, штамп времени (timestamp) и порядковый номер (sequence number), шифруя всю эту информацию на общем сеансовом ключе. Сервер печати расшифровывает полученную информацию и сравнивает ее с идентификационными данными запрашивающего пользователя, полученными от KDC. Если данные совпадают, сервер печати принимает задание от пользователя. При этом штамп времени помогает противодействовать атаке повтора (replay attack). Сервер печати сравнивает штамп времени в полученном пакете со своим собственным внутренним временем, если время существенно различается, это может означать, что сетевой пакет был перехвачен атакующим, а затем отправлен повторно с целью получения несанкционированного доступа от имени легитимного пользователя. Также сервер печати проверяет порядковый номер, чтобы убедиться, что этот пакет не был получен ранее. Это другая защитная мера, позволяющая противостоять атаке повтора.

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

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

Kerberos является примером технологии SSO – пользователь вводит свой идентификатор и пароль только один раз. Билеты имеют ограниченное время жизни, которое настраивается администратором. Чаще всего время жизни TGT составляет от 8 до 10 часов, чтобы, когда пользователь придет на работу на следующий день, он представил свои учетные данные снова.

KDC может являться единой точкой отказа (single point of failure). Если KDC недоступен, никто не сможет получить доступ к ресурсам. Поэтому KDC требует избыточности.
KDC должен быть способен одновременно обрабатывать большое количество запросов. Поэтому он должен быть масштабируемым.
Секретный ключ временно хранится на рабочей станции пользователя, что может привести к его компрометации.
Сеансовый ключ хранится на рабочей станции пользователя в открытом виде в кэше или таблице ключей, что может привести к его компрометации.
Kerberos уязвим к подбору паролей, он не сможет узнать, что атакующим производится подбор пароля по словарю.
Kerberos не защищает сетевой трафик, если не включено шифрование.
Если ключ очень короткий, он может быть уязвим к атаке «грубой силы» (brute force attack).
Kerberos требует, чтобы системные часы на всех клиентах и серверах были синхронизированы.

Kerberos FAQ
MIT Kerberos Papers and Documentation web page

Проект SESAME (Secure European System for Applications in a Multi-vendor Environment) – это технология SSO, расширяющая функционал Kerberos и устраняющая его недостатки. В отличии от Kerberos, SESAME использует симметричные и асимметричные технологии криптографии для аутентификации субъектов на сетевых ресурсах.

Kerberos использует билеты для аутентификации субъектов и объектов, а SESAME использует для этого сертификаты атрибутов привилегий (PAC – Privileged Attribute Certificate), которые содержат идентификационные данные субъекта, его возможности доступа к объекту, период времени доступа и время жизни PAC. PAC подписывается ЭЦП, которую объект может проверить с помощью доверенного сервера аутентификации, называемого сервером атрибутов привилегий (PAS – Privileged Attribute Server). PAS выполняет роль, похожую на роль KDC в Kerberos. После успешной аутентификации пользователя в службе аутентификации (AS), он предоставляет токен, полученный от PAS. Затем PAS создает PAC для пользователя, который пользователь будет предоставлять ресурсам, доступ к которым ему потребуется. На рисунке 2-7 показана схема работы основных элементов SESAME.

SESAME in a Nutshell
SESAME links

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

Термин домен безопасности (security domain) основывается на определении домена, добавляя к нему факт, что ресурсы в рамках этой логической структуры (домена) работают c одной и той же политикой безопасности и управляются одной группой. Таким образом, администратор может поместить компьютеры, учетные записи и сетевые ресурсы сотрудников бухгалтерии в Домен 1, а компьютеры, учетные записи и сетевые ресурсы руководства в Домен 2. Все эти элементы попадут в эти два контейнера, поскольку они (элементы) не только выполняют однотипные задачи, но также, что более важно, имеют один и тот же уровень доверия. Общий уровень доверия позволяет управлять этими элементами одной (отдельной) политикой безопасности.

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

Домены могут быть спроектированы в виде иерархической структуры, определяющей взаимоотношения между различными доменами и способы взаимодействия субъектов, находящихся в различных доменах. На рисунке 2-8 показан пример иерархии сетевых доменов. Их коммуникационные каналы управляются агентами безопасности (списками контроля доступа межсетевых экранов и маршрутизаторов, службами каталогов) и отдельными доменами, изолированными с помощью различных масок подсетей.

Помните, что домены не обязательно связаны с сетевыми устройствами и сегментацией, они могут также применяться к пользователям и процессам. На рисунке 2-9 показано, как с пользователями и процессами могут быть связаны более детальные домены на основе уровней доверия. Группа 1 имеет высокий уровень доверия и может использовать доступ как к домену своего уровня доверия (Домен 1), так и к домену более низкого уровня доверия (Домен 2). Пользователь 1, который имеет низкий уровень доверия, может использовать только домен своего уровня доверия и не выше. Система реализует эти домены с помощью привилегий доступа и прав на уровне файловой системы и ядра операционной системы.

Почему домены включены в раздел «Единый вход»? Потому что различные виды существующих в настоящее время технологий, использующихся для определения и реализации этих доменов и связанных с ними политик безопасности, направлены на предоставление пользователям (субъектам) возможности проходить аутентификацию только один раз и получать при этом возможность доступа к различным доменам без необходимости повторного ввода учетных данных. Примерами таких технологий являются: контроллеры домена в среде Windows, продукты ERM, Microsoft Passport и различные продукты, предоставляющие функциональность SSO.

Underlining Technical Models for Information Technology Security, Recommendations of the National Institute of Standards and Technology , by Gary Stoneburner, NIST Special Publication 800-33 (Dec. 2001)
“New Thinking About Information Technology Security,” by Marshall Abrams, PhD and Michael Joyce (first published in Computers & Security , Vol. 14, No. 1, pp. 57–68)

Служба каталога – это механизм, который идентифицирует ресурсы (принтеры, файловые серверы, контроллеры доменов и периферийные устройства) в сети. Сетевая служба каталога (network directory service) содержит информацию об этих ресурсах и субъектах, которым нужен доступ к ним, и выполняет действия по управлению доступом. Если служба каталога работает на основе базы данных, построенной в соответствии со стандартом X.500, она работает в иерархической схеме, которая описывает атрибуты ресурсов, такие как имя, логическое и физическое размещение, субъектов, которые могут использовать эти ресурсы, и операции, которые субъекты могут выполнять с ними.

В базах данных, построенных в соответствии со стандартом X.500, запросы на доступ выполняются пользователями и другими системами посредством протокола LDAP. База данных такого типа обеспечивает иерархическую структуру для организации объектов (субъектов и ресурсов). Служба каталога присваивает уникальные имена каждому объекту и, при необходимости, добавляет соответствующие ему атрибуты. Служба каталога реализует политику безопасности (настроенную администратором) для управления взаимодействием субъектов и объектов.

Сетевые службы каталогов предоставляют пользователям доступ к сетевым ресурсам прозрачно, т.е. пользователям не нужно знать конкретное местоположение ресурсов или шаги, которые необходимо выполнить для доступа к ним. Сетевые службы каталогов выполняют эти задачи для пользователей в фоновом режиме. Примерами служб каталогов являются LDAP (Lightweight Directory Access Protocol), Microsoft AD (Active Directory), Novell NDS (NetWare Directory Service).

Бездисковые компьютеры (diskless computer) и тонкие клиенты (thin clients) не могут хранить много информации, т.к. они не имеют встроенных устройств хранения информации и необходимых ресурсов. Этот вид клиент-серверной технологии позволяет пользователям регистрироваться на центральном сервере для использования компьютера и доступа к сетевым ресурсам. Когда пользователь включает компьютер, он выполняет короткий список команд и затем обращается на сервер, чтобы загрузить операционную систему или работать в терминальном режиме с прикладным программным обеспечением, работающем на сервере. Это позволяет реализовать строгий контроль доступа, т.к. компьютер пользователя не может сделать ничего самостоятельно, пока не аутентифицируется на центральном сервере и не получит с сервера операционную систему, профиль и функционал. Технология тонких клиентов предоставляет собой другой тип технологии SSO для пользователей, позволяя им аутентифицироваться только на центральном сервере или мейнфрейме, который затем предоставляет им доступ ко всем необходимым и разрешенным им ресурсам.

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