.

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

 

Требования к установке служб федерации
Рисунок 1. Требования к установке служб федерации

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

 

Размещение серверов у поставщика IDaaS
Рисунок 2. Размещение серверов у поставщика IDaaS

Как работает IDaaS?

Поскольку для федеративного механизма SSO все равно требуются ваши удостоверения, внутри брандмауэра компании устанавливается агент или сервер, обслуживающий запросы LDAP к вашим доменам Active Directory (AD) для получения объектов пользователей и групп. Для обслуживания запросов LDAP агент устанавливает соединение по протоколу HTTPS (LDAPS) с помощью поставщика IDaaS. Посредством этого соединения нужные объекты AD зеркально отображаются в локальном хранилище LDAP — например, AD Lightweight Directory Service (AD LDS). Пароль пользователя в хранилище данных поставщика IDaaS обычно не копируется. Поскольку соединение между агентом и поставщиком устанавливается по протоколу HTTPS, для разрешения трафика не требуется открытия дополнительных портов на брандмауэре.

Для доступа к приложениям SaaS пользователь обращается к поставщику IDaaS (например, на портал http://usercompany.idaasprovider.com), подтверждая свою подлинность путем ввода корпоративной учетной записи и пароля. Поскольку поставщик IDaaS не хранит пароль пользователя, запрос на проверку подлинности возвращается локальному агенту, который фактически и выполняет эту проверку в рамках локальной реализации AD. Успешная регистрация в сеансе передается обратно поставщику IDaaS. После этого пользователю предлагается выбрать одно из приложений SaaS без требования ввода каких-либо других ID или паролей. Подобная схема — правда, в несколько ином контексте — известна как «снимок NASCAR», поскольку действительно напоминает группу логотипов спонсоров на кузове гоночного автомобиля — участника гонок NASCAR.

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

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

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

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

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

Недостатки IDaaS

Безусловно, структура любой службы имеет свои недостатки, и IDaaS не исключение. Во-первых, как специалист по ИТ-инфраструктуре с большим стажем, я испытываю некоторый дискомфорт в отношении этой конфигурации, поскольку всегда рассматриваю наихудший сценарий. Архитектура IDaaS предполагает необходимость всегда платить поставщику службы, то есть третьей стороне, за обслуживание и использование шлюза ко всем «облачным» приложениям. Как вам нравится такой тип уязвимости? Что произойдет, если вы будете стеснены в средствах либо сотрудник, обслуживающий счета, пропустит один или два платежа? Будет ли немедленно прекращено обслуживание всех ваших учетных записей? Остановятся ли сразу все зависящие от «облачных» служб операции в компании? А что если речь идет о недавно созданной компании, у которой вообще нет никакого локального хранилища удостоверений? Что будет, если она не заплатит по счету? Сможете ли она вообще работать?

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

Далее, реализуемый IDaaS метод проверки подлинности пользователей может оказаться менее безопасным, чем проверка на основе утверждений, поскольку пароли все же покидают границы брандмауэра компании (даже если они зашифрованы с помощью SSL), следуя к поставщику и от него. Таким образом, вопрос безопасности является первостепенным. Установление соединения должно осуществляться с использованием сертификатов SSL на стороне сервера, а процесс проверки подлинности агентом должен быть хорошо защищен. Напротив, проверка подлинности на основе утверждений не предусматривает паролей. Однако на корпоративном уровне технология IDaaS более безопасна, чем локальная федеративная конфигурация, благодаря всесторонним возможностям SSO, практически исключающим необходимость управления дублирующими учетными записями при взаимодействии с поставщиками SaaS, не поддерживающими федерацию.

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

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

Ввиду зависимости от единственного сеанса связи LDAPS между поставщиком удостоверений и поставщиком службы, другой потенциальный недостаток архитектуры IDaaS состоит в ее восприимчивости к атакам типа «отказ в обслуживании» (DoS). Пока кто-либо запрашивает порт 443, никто в компании не сможет использовать приложения SaaS, а также (если удостоверения переданы в ведение поставщика IDaaS) любую информацию об удостоверениях вообще. Этот вид атаки DoS безусловно способен подорвать работу многих других служб за пределами локальной инфраструктуры.

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

Рынок IDaaS

Рынок IDaaS — небольшой, однако растущий. Здесь еще предстоит сделать многое в части повышения осведомленности и образовательного уровня клиентов. Большинство компаний находятся на стадии начального ознакомления с концепцией федерации для поддержки служб «облачных» вычислений, а IDaaS представляет первый уровень абстракции за рамками данного этапа. Такие продукты, как Okta, PasswordBank, PingConnect от Ping Identity и Symplified, — первые и доминирующие игроки на этом рынке. Однако на предполагаемый рост рынка указывает то, что крупные компании, такие как Intel (с технологией Expressway Cloud Access 360), недавно выпустили собственные продукты IDaaS.

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

Шон Дьюби (sdeuby@windowsitpro.com) — старший аналитик в компании Platform Vision с 25-летним стажем работы в области корпоративных информационных систем. Внештатный редактор Windows IT Pro, имеет звание MVP