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

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

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

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

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

На основании этого идентификацию можно «поделить» на следующие категории:

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

Рассмотрим несколько реализаций, а после сравним их. Начнем с подхода Captive Portal, как вариант активной идентификации.

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

Однако есть проблема, что клиентское приложение выполняет HTTP-запросы к веб-ресурсу, а не к HTTP серверу межсетевого экрана. Чтобы «направить» пользователя на портал  аутентификации, межсетевой экран на HTTP-запрос клиентского приложения формирует ответ со статусом «HTTP 303 See other». Данный ответ указывает на то, что запрашиваемый ресурс находится по новому адресу, где указывается ссылка на портал аутентификации:

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

Как только пользователь предоставит на веб-странице свою учетную запись, клиентское приложение выполнит «HTTP POST» запрос к порталу аутентификации, в котором передаст полученную учетную запись:

Далее межсетевой экран проверяет существование полученной учетной записи в пользовательском каталоге (в случае Active Directory – по протоколу LDAP):

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

Отобразим картину идентификации пользователя в полном масштабе:

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

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

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

Чтобы рабочая станция отправляла HTTP-запросы именно на прокси-сервер, требуется явная конфигурация или клиентского приложения, или операционной системы, отсюда и название – «явный» прокси.

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

Разница «прозрачного» и «явного» прокси заключается в механизмах, отвечающих за формирование HTTP-запросов к прокси-серверу.

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

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

Обрабатывая запрос от рабочей станции без привязанного идентификатора пользователя, прокси-сервер использует рассмотренный ранее метод «HTTP 303 See other», чтобы направить пользователя на портал аутентификации. В случае «прозрачного» прокси при доступе к порталу аутентификации рабочая станция получает ответ «HTTP 401 Server Authentication Required», где предлагается один из трех способов идентификации пользователя: Basic, NTLM или Kerberos:

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

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

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

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

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

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

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

Чтобы распространить ключ шифрования, используются так называемые тикеты: первый – для рабочей станции, второй – для прокси-сервера. За генерацию и распространение тикетов отвечает механизм Kerberos, который используется в комбинации с пользовательским каталогом.

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

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

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

Теперь рассмотрим заключительный вариант: Single sign-on, как вариант пассивной идентификации. Данная реализация выполняет идентификацию пользователя, читая лог-журнал доменного контроллера, где фиксируются события успешного входа пользователей в домен.

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

Несмотря на то, что данная запись утверждает соответствие между рабочей станцией и пользователем, применить ее для идентификации пользователя по запросам не получится. Дело в том, что атрибут hostname не присутствует как сетевой атрибут в запросах рабочей станции, поэтому атрибут hostname преобразуется в IP-адрес через запрос к доменной службе DNS.

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

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

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

Какое решение выбрать?

С критериями оценивания мы определились в прошлой части:

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

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

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

• реализация Single sign-on. Данное решение является самым удобным для пользователя, поскольку идентификация для доступа к веб-ресурсам осуществляется одновременно с входом в домен. Администратор в таком решении обязан будет конфигурировать ignorelist, который может изменяться в течении времени. Риск компрометации учетной записи в процессе идентификации исключен, поскольку пароли от учетных записей никак не используются;
• реализация Kerberos и NTLM. Данное решение освобождает пользователя от необходимости вводить свою учетную запись, однако обязует пользователя запустить клиентское приложение, которое поддерживает идентификацию через Kerberos или NTLM. С другой стороны, для данной реализации клиентские приложения необходимо «подконфигурировать», что при большом количестве рабочих станций может стать проблемой для администратора в случае «ручной работы». Необходимость конфигурации объясняется тем, что клиентские приложения выполняют идентификацию через Kerberos или NTLM только с «доверенными» ресурсами, которые и утверждаются конфигурацией. Риск компрометации учетной записи прямопропорционален вероятности успешной атаки по подбору ключа шифрования (который основан на пароле). Таким образом, риск компрометации учетной записи зависит от сложности пароля пользователя (проще пароль – выше риск);
• реализация Captive Portal и Basic. Пожалуй, самый нежелаемый для пользователя способ идентификации, поскольку требует от пользователя наибольших усилий на этапе идентификации. С другой стороны, администрировать таким решением будет проще, поскольку ничего конфигурировать не требуется. В обоих реализациях используются протоколы HTTP (между рабочей станцией и межсетевым экраном) и LDAP (между межсетевым экраном и пользовательским каталогом), которые передают учетную запись в открытом виде, что повышает риск компрометации учетной записи. Для обеспечения шифрования передаваемых данных мы настраиваем механизм SSL/TLS для каждого из протоколов.

Безусловно, при выборе решения стоит учитывать и ограничения, характерные для той или иной реализации. К примеру, решение Single sign-on применимо только для рабочих станций, которые являются частью домена.

Некоторые ограничения можно «парировать», используя комбинации из нескольких реализаций. Например, мы часто используем на практике комбинацию из Single sign-on и Captive Portal, применяя пассивную идентификацию для пользователей домена и активную идентификацию для остальных случаев.

Выводы

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

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