«Удалёнка» сегодня перестала быть чем-то необычным. Ко второй половине 2020 года про приемлемость удалённой работы штатных сотрудников узнали даже те, кто ранее об этом не хотел и слышать. А те сотрудники, которые успешно перестроили свою привычную работу на удалённый лад, осознали все её преимущества по сравнению с исключительно офисным режимом прежде всего для профессиональной продуктивности. В процессе перевода сотрудников на работу в режим домашнего офиса во всей красе проявили себя узкие места ИТ-инфраструктуры компаний. Нагрузка на инфраструктуру возросла в разы: многократно увеличилось потребление ресурсов корпоративных сетей, VPN и файловых хранилищ, увеличилась нагрузка на телефонию и, в особенности, на видеоконференцсвязь. Некоторые системы от нагрузки стали отказывать в самый неподходящий момент.
Для решения этих проблем многие компании воспользовались облачными (SaaS/PaaS) ресурсами. Этот вариант стал не только разумным компромиссом, но и зачастую единственным возможным способом быстро восполнить нехватку ИТ-ресурсов компании в связи с резким ростом нагрузки со стороны удалённо работающих сотрудников.

Проблемы в связи с переходом в облака

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

Вопрос № 1. Создание учётных записей пользователей в облаках организации

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

Как создать учётные записи сотрудников в облачной системе наиболее рационально и с минимальными затратами?

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

В современной практике хорошо себя зарекомендовал следующий архитектурный подход: строится централизованная корпоративная система аутентификации (собственный Identity Provider как решение класса IAM, Identityand Access Management). Далее к ней в роли потребителей услуг по аутентификации подключаются другие корпоративные информационные системы.

При решении задачи создания учетной записи облачный сервис получает от корпоративного Identity Provider необходимый набор атрибутов сотрудника. В этом случае создание персональной учётной записи сотрудника в облачной системе осуществляется автоматически в момент первой аутентификации данного сотрудника в SaaS-системе. Обновление данных о сотруднике происходит также автоматически.

Вопрос № 2. Управление правами доступа сотрудников в корпоративных SaaS-решениях

Как управлять правами доступа сотрудников в той или иной облачной системе?

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

В случае использования корпоративного Identity Provider каждая сессия пользователя проходит проверку через централизованный сервис аутентификации. А администраторам достаточно иметь возможность управлять учётными записями именно в нем, поэтому не требуется решать проблему контроля над распределёнными разрозненными хранилищами учётных записей. Управление доступом пользователя к приложению осуществляется средствами Identity Provider. Данные авторизации, специфичные для того или иного приложения, могут быть переданы в составе токена аутентификации, посредством SCIM API, или с использованием в связке с Identity Provider решения класса IDM.

Вопрос № 3. Защита учётных записей сотрудников в облаках

Как обеспечивать защиту данных учётных записей сотрудников в условиях «открытости» облачных ресурсов?

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

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

Вопрос № 4. Своевременный отзыв прав доступа в корпоративных SaaS-решениях

Как обеспечить своевременный отзыв прав доступа сотрудника?

Сотрудник, который ранее работал на определённой должности, но затем был уволен либо переведён в другое подразделение, технически будет продолжать обладать неправомерным доступом к ресурсам организации.
При блокировке учётной записи в централизованном сервисе аутентификации, пользователь больше не будет иметь доступ к ресурсами организации, так как все попытки его получить обязательно проходят через Identity Provider. А при наличии в централизованном сервисе аутентификации механизма управления сессиями и завершения сессии (SLO, Single Logout), администратор может в режиме реального времени приостановить работу пользователя в любой информационной системе в случае отзыва прав доступа либо компрометации учётной записи.

Вопрос № 5. Аудит безопасности корпоративных SaaS-решений

Как выполнять аудит, отслеживать получение доступа к облачным сервисам компании и пресекать обнаруженные неправомерные действия?

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

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

Вопрос № 6. Предоставление доступа сотрудникам между организациями

Как предоставлять доступ к собственным облачным ресурсам сотрудникам компаний-партнёров и контролировать его? Как получать доступ для своих сотрудников к облачным ресурсам компаний-партнёров?

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

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

Вопрос № 7. Защита наиболее критичных облачных ресурсов

Как повысить уровень защиты для наиболее критичных облачных ресурсов?

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

Средства аутентификации SAML и OpenID Connect для SaaS-ресурсов

Задача централизованной аутентификации в условиях большого количества информационных систем решалась в разное время по-разному. Некоторое время назад наибольшей популярностью в корпоративных средах пользовался подход построения аутентификации через LDAP. Этот подход позволял решать задачу централизованного управления учётными данными сотрудников. Но при этом метод LDAP-аутентификации был очень ограничен функционально с точки зрения сценариев аутентификации (ни о каком SSO через LDAP не могло идти и речи) и имел проблемы безопасности, предоставляя чрезмерные данные о сотрудниках другим слабо защищённым информационным системам. Сам по себе LDAP не предназначен для публичных сетей, поэтому предоставление доступа SaaS-приложениям к корпоративному LDAP ставит под угрозу безопасность всей ИТ-инфраструктуры компании. И, конечно же, LDAP не может выступать в роли Identity Provider.

По мере унификации средств аутентификации и развития стандартов аутентификации в распространённых корпоративных информационных системах стала появляться поддержка протокола SAML 1.1, а затем и SAML 2.0. Протокол SAML позволил организовать однократную аутентификацию для подключенных к нему систем: пользователь, единожды аутентифицировавшись в какой-либо одной информационной системе, автоматически получал доступ к другим. При этом данный протокол обеспечивал достаточную защиту учётных данных пользователя: при аутентификации посредством SAML пароль пользователя не передаётся и не обрабатывается информационной системой (как бывает в случае с LDAP-аутентификацией), а проверяется в доверенном сервисе единой аутентификации (Identity Provider). Информационная система в случае с SAML получает от Identity Provider подписанное ключом подтверждение факта успешного прохождения аутентификации с минимальным набором сведений о пользователе.

Популярные информационные системы, используемые в корпоративной среде (к примеру, решения VMWare, Citrix, SAP, G-Suite и т. д.), поддерживают либо «из коробки», либо после установки дополнительных компонентов возможность аутентификации по протоколам SAML 1.½.0, и таким образом могут быть подключены к системе SSO.
В условиях распределённой информационной инфраструктуры, в которой не всегда известен полный перечень потребителей сервиса аутентификации (например, в общедоступных сервисах), наибольшую популярность приобрели протокол аутентификации OpenID Connect (сокращённо OIDC) и фрейморк авторизации OAuth, на базе которого построен OIDC. OIDC во многом похож на SAML, особенно в части высокого уровня защищённости, так как никакие сведения об аккаунте пользователя не передаются потребителю услуг аутентификации без ведома сервиса аутентифиакции.

В среде облачных корпоративных информационных систем могут применяться как SAML, так и OIDC/OAuth. Поэтому при выборе облачного решения, которое планируется интегрировать в имеющуюся op-premise SSO-инфраструктуру, следует обращать внимание на наличие одного из указанных протоколов аутентификации.
В случае же отсутствия в SaaS-решении поддержки SAML либо OIDC/OAuth может использоваться технология аутентификации Reverse Proxy. В таком режиме служба единой аутентификации выступает в роли посредника между целевым приложением и пользователем, незаметно для пользователя выполняя аутентификацию в целевом приложении. Технология аутентификации Reverse Proxy позволяет применять сценарии аутентификации без внесения изменения в целевое приложение, за счёт чего появляется возможность подключения практически любого веб-приложения к сервису единой аутентификации.

Интеграция облачных сервисов в корпоративую инфраструктуру через SSO

На практике многие SaaS-поставщики поддерживают протоколы аутентификации SAML и OpenID Connect в корпоративную инфраструктуру. Рассмотрим подробнее несколько популярных систем.

Zoom
Крайне популярный сегодня сервис видеоконференцсвязи в корпоративном аккаунте обладает возможностью подключения к SSO с применением протокола SAML 2.0. После регистрации корпоративного аккаунта (для обычного индивидуального аккаунта данная функция недоступна) в разделе настроек «Single-SignOn» потребуется выбрать пункт «EnableSingle-SignOn».

В части настроек параметров интеграции SSO сервис Zoom проявляет настоящую гибкость: имеется возможность настройки маппинга SAML-атрибутов на учётные записи пользователей. После настройки интеграции сотруднику, работающему через Zoom, будет достаточно вместо ввода персонального аккаунта выбрать пункт «Войти в систему через СЕВ» (аббревиатура от «системы единого входа») и указать zoom-домен корпоративного аккаунта организации. После выполнения этой минимальной настройки на рабочем месте сотрудник сможет получать доступ к сервису с использованием привычного для него корпоративного средства единой аутентификации (SSO).
При использовании такой схемы снизится нагрузка на службу технической поддержки организации в части обслуживания Zoom-аккаунтов сотрудников: достаточно будет разрешить пользователю вход в Zoom в корпоративном SSO, и ему будет автоматически предоставлен доступ с персональной учётной записью для подключения к видеоконференциям. В случае увольнения сотрудника или при необходимости отключения доступа к Zoom, администратору достаточно зафиксировать факт запрета для определённого работника централизованно в SSO, и пользователь не сможет продолжить использовать видеоконференции в рамках корпоративного Zoom-ресурса. Посредством маппинга SAML-атрибутов также можно настроить передачу параметров авторизации от SSO-решения в учётную запись корпоративного пользователя Zoom.

Сервис Zoom поддерживает протокол провиженинга учётных данных SCIM. Эта возможность может быть полезна при использовании, SSO-решения в связке с IDM для автоматизации предоставления доступа к системе Zoom для принятых на работу новых сотрудников, а также для контроля и предоставления доступа различным группам сотрудников к определённым функциям в рамках корпоративного аккаунта Zoom.
Slack
Система корпоративной коммуникации поддерживает аутентификацию по протоколу SAML 2.0. Настройка интеграции осуществляется в панели администратора в разделе «Custom SAML SingleSign-On». При этом Slack требует наличия определённых атрибутов в сообщениях SAML, поэтому настройку маппинга атрибутов на понятные для Slack атрибуты потребуется произвести в корпоративном SSO.
С точки зрения управления правами доступа сотрудников Slack поддерживает провиженинг учётных данных и прав доступа по протоколу SCIM 2.0. При наличии системы IDM облачный сервис Slack может быть легко подключен к IDM и в части управления правами доступа сотрудников.
Облачный 1С
Определённые конфигурации 1С предоставляют возможность подключения к внешнему Identity Provider при помощи OpenID Connect, в основном это касается «коробочных» версий. В части облачных решений, помимо большого разнообразия конфигураций, в роли поставщиков услуг облачных 1С выступают различные компании. Требуется дополнительно уточнять возможности подключения к SSO, если используемая облачная версия поддерживает протокол OpenID Connect, то задача решается достаточно просто.

В случае, если в облачной версии 1С такой поддержки нет, то для подключения 1С к SSO подойдёт технология аутентификации Reverse Proxy. При этом учётные данные пользователей будут по-прежнему защищены, так как хранятся и обрабатываются только в SSO, а передача в целевую информационную систему осуществляется по защищённому каналу. А за счёт периодической и автоматической смены паролей учётных записей пользователей совместно с политиками управления доступом будет обеспечиваться необходимый уровень защиты информации.

SAP HANA Cloud
Для любого приложения, разработанного на платформе SAP HANA, может быть настроена аутентификация по протоколу SAML 2.0. Поэтому приложения на данной платформе могут быть интегрированы в корпоративный ИТ-ландшафт с использованием механизмов Identity Provider.

Яндекс.Облако
Яндекс.Облако — система виртуальной облачной инфраструктуры, поддерживающая функциональность федерации учётных данных посредством протокола SAML 2.0. Можно подключить сервис к корпоративному SSO, тем самым решить задачу управления учётными записями сотрудников в Яндекс.Облаке.
Для управления правами доступа пользователей можно воспользоваться REST API Яндекс. Облака, интегрировав его с IDM-решением.

GitHub
Популярный сервис управления репозиториями и разработкой поддерживает аутентификацию по протоколу SAML 2.0 и может быть легко подключен к SSO. В части управления правами доступа в GitHub имеется поддержка SCIM, поэтому GitHub может быть легко интегрирован с системой IDM для автоматизации операций назначения и отзыва прав доступа.

Выводы

В статье мы рассмотрели наиболее важные вопросы интеграции облачных ресурсов в инфраструктуру компании посредством механизма аутентификации. Механизм Identity Provider поддерживается многими популярными облачными сервисами, и поэтому внедрение IAM-решения для корпоративной централизованной аутентификации — ключевой шаг к построению современного целостного и защищённого ИТ-ландшафта компании в условиях распределённости корпоративных ИТ-инфраструктур. С внедрением SSO-решения с поддержкой всех востребованных технологий корпоративной аутентификации (SAML, OAuth, OIDC, Reverse Proxy) компания получает не только инструмент для решения текущих задач, но и системное решение качественно более высокого уровня, позволяющее при необходимости оперативно и без риска для управляемости и безопасности наращивать перечень ИТ-активов компании за счёт подключения новых on-premise и облачных сервисов.

Дмитрий Грудинин, системный архитектор Аванпост
IT-Weekly