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

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

При этом задачу можно рассматривать с двух точек зрения:

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

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

Исходная ситуация
Сотрудники организации по роду деятельности должны получать доступ к данным, располагающимся в других организациях. О чем идет речь? Это, например, сведения об абонентах мобильного оператора, паспортные данные, сведения о владельцах транспортных средств. Смежными системами в данном случае выступают сети операторов электросвязи, МВД и некоторые другие организации.

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

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

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

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

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

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

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

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

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

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

Как реализована регистрация действий
Регистрация ведется средствами журнала веб-браузера Internet Explorer в терминальной сессии пользователя. Чтобы исключить очистку журнала, применяются ограничивающие политики (Windows Group Policy Object, GPO). По сути, на терминальном сервере пользователю разрешено лишь запускать браузер и не разрешено изменять его конфигурацию или чистить историю.

Для каждого пользователя в домашней директории хранится свой журнал посещений, что позволяет установить соответствие между пользователями и выполненными запросами. Журналы хранятся в контролируемом окружении – на терминальных серверах в ЦОД, но при этом «распылены» по серверам и по различным папкам и файлам в рамках сервера.

Выбранное решение работает, но имеет следующий недостаток: выполняется регистрация только той части запроса, которая присутствует в URL; если запрос выполняется методом POST, то запрашиваемые атрибуты не будут видны в URL и, как следствие, не будут зафиксированы в журнале. (Если вам известен способ регистрации POST-запросов в браузере – прошу поделиться рецептом в комментарии).

Дальнейшие шаги
Мы рассмотрели существующее решение по контролю доступа. Что хотелось бы изменить?

1. Упростить процедуру доступа сотрудников к приложениям смежных систем. Исключить утомляющие вспомогательные шаги: использование терминального подключения, ввод дополнительного идентификатора и пароля, специфичного для каждой смежной системы. По возможности – обеспечить SSO, чтобы пользователи вводили данные учетной записи один раз, после чего получали доступ к разрешенным для них приложениям без необходимости повторного ввода.
2. Упростить управление учетными записями.
3. Обеспечить регистрацию всех запросов (включая POST-запросы).

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

«Автономное» решение
В «автономном» сценарии следующее ограничение: смежные системы не затрагиваются, изменения допустимы только внутри организации.
Цели: упростить процедуру входа и не запрашивать дополнительного ввода от пользователя, упростить управление учетными записями, обеспечить регистрацию всех запросов.
Каких же результатов можно достичь?

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

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

Решение можно искать либо на стороне клиентской части, либо на пути между клиентом и приложением.

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

Значит, остается второй вариант – реализовать некий компонент-посредник на пути между клиентом и приложением. Такой прокси (в широком смысле этого слова) должен:

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

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

Например, для аутентификации по методу HTTP Basic достаточно добавить поле в HTTP-заголовок и указать в нем идентификатор и пароль в кодировке Base64.

Если приложение использует другой метод аутентификации, например, HTTP Digest или Form-Based, то принцип сохраняется, только усложняется реализация взаимодействия «прокси – приложение». В зависимости от метода аутентификации может потребоваться выполнить несколько итераций «запрос-ответ» и дополнительно хранить состояние HTTP-сессии (cookies).

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

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

Казалось бы, мы возвращаемся к исходной проблеме: требуется аутентифицировать пользователя, не требуя от него дополнительного ввода. Но в этом случае обе точки – и клиентская, и серверная часть – находятся в одной организации, под единым управлением. И, значит, могут быть использованы стандартные механизмы прозрачной аутентификации (см. «Как реализовать однократную аутентификацию (SSO) при доступе к приложениям»).
Далее приведена схема прозрачной аутентификации (SSO) на участке между рабочей станцией и прокси с применением протокола Kerberos.

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

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

Контроль доступа к прокси – альтернатива
Для полноты картины рассмотрим еще один вариант: точка контроля доступа в сети – на средствах защиты информации класса UTM/NGFW. При этом возможно получить как прозрачную аутентификацию (зачастую на основе методов, специфичных для данного производителя), так и авторизацию по LDAP.

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

Первый вариант – вести регистрацию на стороне клиентской части. В принципе такой подход можно реализовать с помощью дополнительного (агентского) программного обеспечения на рабочих станциях. Но это не лучшее решение: агент должен поддерживать все используемые операционные системы и браузеры; его нужно установить на каждую рабочую станцию; включенная в сеть станция или мобильное устройство без агента оказывается «под радаром».

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

• URL запроса и поля запросов для метода HTTP POST;
• идентификатор пользователя и его IP-адрес;
• дата и время запроса.

Далее возможна передача этих сведений в систему сбора и анализа событий (SIEM).

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

Решение в целом
Далее приведена диаграмма потоков для решения с прокси-компонентом, который реализует прозрачную аутентификацию пользователей на основе Kerberos и авторизацию на основе LDAP и обращается в смежную систему, выполняя аутентификацию в приложении по методу HTTP Basic.

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

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

• На каких компонентах можно построить такое решение Приведенная схема может быть реализована на основе веб-сервера Apache с дополнительными модулями: для прозрачной аутентификации пользователей – модуль mod_auth_kerb, реализующий протокол Kerberos; для авторизации пользователей – модуль mod_authnz_ldap, реализующий протокол LDAP; для работы в режиме обратного прокси ( reverse proxy) – модуль mod_proxy; для аутентификации прокси в смежной системе – модуль mod_headers, чтобы передать приложению смежной системы заголовок с идентификатором и паролем в рамках аутентификации HTTP Basic; для регистрации выполненных запросов – модуль mod_security и встроенные функции веб-сервера по ведению журнала событий.
  Другие направления
  Рассмотрим ситуацию, когда обе стороны готовы к изменениям и совместные усилия способны обеспечить синергетический эффект.
  При этом необходимо сформулировать требования и ограничения, ответить на ряд вопросов.Аутентификация
  Требуется ли аутентификация? И если требуется, то какая сторона ее выполняет? Как построить прозрачную аутентификацию?
  Можно ли обойтись только идентификацией?
  Можно ли вообще обойтись без идентификатора? Может быть, владельцу информационного актива достаточно только знать из какой организации пришел запрос?Авторизация
  Авторизация фактически отсутствовала в схеме с выделенными учетными записями. Все пользователи имели равные права в приложении: достаточно успешно аутентифицироваться, чтобы получить доступ.
  Так нужна ли авторизация? В общем случае – да, поскольку аутентификацию успешно проходит любой сотрудник организации, а права на доступ к определенному активу могут быть лишь у отдельной группы. Кто выполняет авторизацию?
  Как она будет реализована? На основе перечня пользователей, которым разрешен доступ? На основе групповой принадлежности, сведения о которой извлекаются из центрального каталога на основе протоколов типа LDAP? Другим способом?Регистрация
  Кто выполняет регистрацию – владелец, потребитель или и тот, и другой? Мне представляется, что в общем случае регистрацию должен выполнять владелец актива как заинтересованный субъект. И технические возможности у владельца шире: регистрация может выполняться средствами веб-сервера, средствами приложения, средствами базы данных.
  Требуется ли в журнале идентификатор пользователя или достаточно некой привязки к организации-потребителю, например, по IP-адресу?Далее полагаем, что контроль доступа возлагается на организацию-владельца информационного актива. Рассмотрим возможные решения.

  «Кооперативные» решения

  На основе цифровых сертификатов (PKI)
  В таком решении сотрудники организации-потребителя получают цифровые сертификаты. Приложение смежной организации выполняет аутентификацию, проверяя действительность сертификата пользователя на этапе установления HTTPS-соединения. Дополнительного ввода от пользователя не требуется.
  Для управления цифровыми сертификатами сотрудников предусматривается использование услуг удостоверяющего центра (Certification Authority).
  Удостоверяющий центр должен быть единым для всех участников (организаций-потребителей и организаций-владельцев информационных активов). В противном случае получим зоопарк сертификатов – подобно тому, как ранее был зоопарк идентификаторов и паролей.

  Для авторизации можно было бы использовать поле в сертификате, но это сопряжено с несколькими проблемами: под каждое приложение нужно выделять свое поле или OU; при изменении прав доступа сотрудника придется перевыпускать сертификат. Не лучшее решение. Более гибкий способ – подключаться к LDAP-серверу организации-потребителя и проверять принадлежность пользователя заранее определенной группе.

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

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

  На основе доверительных отношений и Kerberos
  В этом решении прозрачная аутентификация пользователей реализуется на основе протокола Kerberos и установления отношений доверия между различными организациями, а точнее, между соответствующими KDC-серверами (Kerberos Key Distribution Center).
  При доступе к приложению клиентская часть обращается к операционной системе (SSPI/SPNEGO API) и далее без участия пользователя получает тикет в KDC-сервере смежной организации и выполняет аутентификацию в приложении.

  Для авторизации приложение обращается к LDAP-серверу организации-потребителя и проверяет принадлежность пользователя заранее определенной группе.

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

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

  На основе доверительных отношений и SAML
  Решение на основе SAML подобно решению на основе Kerberos, но без Kerberos 
  В этом случае также применяется сервер, выдающий аналоги Kerberos-тикетов, но называется этот сервер Identity Provider (IdP) и для работы с ним используется HTTPS. Установление доверительных отношений между IdP и приложением заключается в обмене публичными ключами.

  При доступе к приложению браузер прозрачно, без участия пользователя:

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

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

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

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

  Решение обеспечивает прозрачную аутентификацию, авторизацию и регистрацию запросов. Для аутентификации и авторизации используется протокол HTTPS, применение LDAP не требуется.