Доступ сотрудников компании в сеть Интернет на основе политик Active Directory (часть 1)

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

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

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

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

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

Уточним местоположение устройства фильтрации, вариантов не так много:

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

В этой статье рассмотрим вариант с межсетевым экраном.

Идентификация пользователя

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

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

В этой статье рассмотрим модель, где идентификатором пользователя является его доменная учетная запись центрального каталога Active Directory.

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

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

Таким образом, можно реализовать три способа, как идентификатор пользователя будет передан на межсетевой экран.

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

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

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

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

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

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

Обсудим иной вариант, где межсетевой экран взаимодействует с доменным контроллером.

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

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

Обсудив несколько способов решить задачу идентификации, стоит их как-то сравнить. Как правило, заказчики в решении такой задачи ценят следующие критерии:

• простота использования (объем дополнительных действий, который пользователь обязан предпринимать в ходе идентификации при доступе к веб-ресурсу);
• простота управления (например, насколько затруднительно администратору добавить новую рабочую станцию или новых пользователей в процесс идентификации);
• вопросы безопасности (каким образом передаются учетные записи пользователей? Применяется ли шифрование для передаваемых данных и насколько это шифрование устойчиво к атакам подбора ключа шифрования?).

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

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

В вопросах безопасности стоит рассмотреть то, насколько процесс идентификации восприимчив к атакам злоумышленника типа man-in-the-middle (или «человек по середине»).

В решении с чтением лог-журнала доменного контроллера стоит сравнить два варианта реализации: с удаленным чтением лог-журнала и с установкой агентов на доменные контроллеры.

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

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

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

Определение профиля полномочий

Здесь стоит сделать шаг в сторону, чтобы взглянуть на модель управления полномочиями «с высоты птичьего полёта».

В модели управления полномочиями предусматривается два функциональных элемента: точка назначения полномочий (англ. Policy Decision Point) и точка контроля полномочий (англ. Policy Enforcement Point).

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

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

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

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

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

Как правило, в случае Active Directory «атрибутом полномочий» выступает атрибут memberOf, который хранит групповую принадлежность учетной записи.

И вот пример того, как атрибут memberOf учетной записи может быть запрошен в каталоге Active Directory по протоколу LDAP:

И вот как выглядит ответ каталога, содержащий значение атрибута:

Набор правил фильтрации по профилю полномочий

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

Такую роль будет играть межсетевой экран, поскольку межсетевые экраны «вооружены» необходимым набором инструментов фильтрации, применяемых как на сетевом и транспортном уровнях, например списки контроля доступа (ACL), так и на прикладном уровне и на уровне представления, например веб-фильтрация или контроль приложений (Application Control). С помощью таких инструментов мы будем создавать наборы правил фильтрации – содержимое профилей полномочий.

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

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

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

Выводы

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