Федерации, синхронизация и гостевые учетные записи
Многие предприятия развернули в своей организации локальные службы каталогов (такие как Active Directory) для хранения сведений о пользователях и других сущностях. В некоторых случаях эти службы существовали в течение десятилетий, и хранящиеся в них сведения являются обширными и имеют решающее значение для деятельности организации.
Когда подобные организации переходят на облако, одна из проблем, с которыми они сталкиваются, заключается в том, как контролировать доступ к облачным ресурсам, используя те же удостоверения пользователей, групп и приложений, которые они применяют для управления доступом к локальным ресурсам. Они могут использовать отдельные удостоверения и отдельные учетные данные для локальных и облачных ресурсов, но такой вариант далеко не идеальный. Если пользователь покидает организацию, его необходимо удалить как из облачного, так и из локального каталога. Кроме того, в этом случае пользователям необходимо использовать несколько учетных записей. Такой способ не только является неудобным, но и создает проблему безопасности.
Существуют технологии, позволяющие расширить локальные службы каталогов на облако, упрощая администрирование облачных ресурсов и предотвращая вход пользователей в систему для доступа к локальному ресурсу с одним набором учетных данных, а для доступа к облачному ресурсу — с другим. Одним из этих методов является федерация, другим — синхронизация. Отдельная, но связанная с этим проблема заключается в том, как предоставить внешним пользователям (например, подрядчикам, которые не являются частью организации, но работают от ее имени) доступ к облачным ресурсам организации без предоставления им учетных данных для вашей системы. Изящным и часто используемым решением является использование гостевых учетных записей. Давайте рассмотрим федерацию, синхронизацию и гостевые учетные записи, а также выясним, что они собой представляют и какую роль играют в облачном администрировании.
Федерация
Федерация предшествует облаку. Ее цель состоит в том, чтобы наладить отношения доверия между организациями, то есть чтобы Организация A могла получить доступ к сетевым ресурсам Организации B, не требуя от Организации B выдачи учетных данных участникам Организации A. Федерация применяет стандартные механизмы (такие как WS-Fed), которые определяют протоколы, используемые для распространения сведений об удостоверениях между системами. Службы федерации, такие как служба федерации Microsoft Active Directory (ADFS), реализуют протоколы WS-Fed и объединяют системы удостоверений. Таким образом, удостоверения Организации A могут использоваться в Организации B в качестве федеративных удостоверений. Иными словами, федерация позволяет внешним пользователям получать доступ к внутренним ресурсам. То есть она расширяет удостоверения организации за пределы самой организации.
Предположим, две компании, Contoso и Fabrikam, формируют деловой союз. Компании Contoso требуется, чтобы сотрудники Fabrikam имели доступ к определенным общим папкам в сети Contoso и наоборот. Эти две компании объединяют свои системы удостоверений, позволяя сотрудникам Fabrikam получать доступ к ресурсам Contoso с использованием тех же учетных данных, которые они вводят для доступа к ресурсам Fabrikam. Когда ИТ-администраторы, работающие в компании Contoso, добавляют пользователей в список пользователей, которым разрешен доступ к общим папкам, они видят сотрудников компании Contoso и сотрудников компании Fabrikam, хотя компания Contoso никогда не создавала учетные записи для сотрудников Fabrikam. Это краткое объяснение федерации.
Федерация не ограничивается подключением локальных сетей различных организаций. Ее также можно использовать для расширения локальных удостоверений до облака. Azure, AWS и GCP предлагают решения для управления удостоверениями, которые позволяют локальным службам каталогов (например, Active Directory) предоставлять сведения об удостоверениях облачным службам. Если пользователь пытается получить доступ к защищенному облачному ресурсу, запрос перенаправляется в локальное решение для работы с каталогами, которое выполняет проверку подлинности пользователя, как если бы он обращался к локальному ресурсу (рис. 3.4). Это обеспечивает централизованное управление пользователями, учетными данными и разрешениями. Благодаря этому пользователи также не смогут использовать отдельную учетную запись для доступа к облачным ресурсам своей организации.
Рис. 3.4. Поток федеративных удостоверений.
Федерация широко применяется организациями для защиты доступа к облачным ресурсам с использованием тех же сведений об удостоверении, которые обеспечивают безопасный доступ к локальным ресурсам. Однако это не идеальный вариант. Для этого требуется надежное подключение между локальной службой каталогов и облаком. Таким образом, к локальному каталогу можно обращаться каждый раз, когда пользователь обращается к облачному ресурсу, для которого требуется проверка подлинности. Одним из решений этой проблемы (другим средством совместного использования учетных данных между локальными каталогами и облаком) является синхронизация.
Синхронизация
Синхронизация является альтернативой федерации. При использовании синхронизации информация о локальных каталогах периодически синхронизируется с каталогом в облаке. Главное различие между федерацией и синхронизацией заключается в том, что в первом случае процесс проверки подлинности происходит локально, а при синхронизации — в облаке.
Синхронизация реализуется путем установки службы синхронизации в локальных системах организации (рис. 3.5). Служба периодически выполняет синхронизацию сведений о пользователях между локальным и облачным каталогами. Затем весь процесс проверки подлинности выполняется в облачном каталоге, который содержит те же сведения, что и локальный каталог.
Рис. 3.5. Синхронизированный поток удостоверений.
Главное операционное различие между федерацией и синхронизацией заключается в том, что последняя более устойчива к прерываниям подключения. Для синхронизации не требуется доступ к локальному каталогу каждый раз, когда пользователь обращается к облачному ресурсу. Доступ требуется только при синхронизации. Основным недостатком синхронизации является то, что для внесения изменений в локальный каталог требуется время для распространения этих изменений в облаке. Если администратор добавляет Алису в локальный каталог, но синхронизация происходит один раз в час, Алиса не сможет получить доступ к защищенным облачным ресурсам в течение одного часа после внесения изменений.
Такие средства, как Microsoft Entra Подключение, доступны для синхронизации каталогов. AADC синхронизирует данные, хранящиеся в локальной среде в Active Directory, с информацией, хранящейся в облаке в идентификаторе Microsoft Entra. Amazon предоставляет похожее предложение в виде AD Connector, как Google в виде Google Cloud Directory Sync (GCDS).
Решения для синхронизации, как правило, предпочтительнее подходов на основе федерации. Обычно они приводят к меньшим расходам на управление и не требуют всегда доступного подключения между службами каталогов. Эту рекомендацию поддерживает Национальный центр кибербезопасности (Соединенное Королевство)1.
Гостевые учетные записи
Еще одной проблемой, с которой сталкивается ИТ-отдел, является то, как обрабатывать действия внешних пользователей организации. К таким пользователям часто относятся подрядчики, консультанты и стажеры — пользователи, которые не являются формальной частью организации, но нуждаются в доступе к внутренним ресурсам, как если бы они были.
Одним из решений является создание внутренних учетных записей для внешних пользователей. К именам таких учетных записях часто добавляется префикс или суффикс для обозначения того, что они принадлежат внешним пользователям. Например, в корпорации Майкрософт большинство внешних учетных записей имеют такие имена, как v-jeffpro, где буква v обозначает vendor (поставщик). Однако этот подход далек от совершенства. В частности, он приводит к росту количества учетных записей. ("Вот еще одно имя пользователя для отслеживания и другой пароль, который необходимо менять каждые 60 дней, чтобы соответствовать политике, уникальной для этой организации".) Это также повышает нагрузку на администраторов из-за увеличения количества учетных записей, за которые они несут ответственность, и принудительного создания механизма или процесса распространения изменений в статусе внешних пользователей в их собственных организациях на внутренние системы управления удостоверениями. Например, если консультант с внешними учетными данными уходит в отставку или соглашается на работу в другой организации, его учетные данные необходимо отозвать, чтобы они больше не использовались для доступа к системам.
Правильнее будет использовать гостевые учетные записи. Гостевые учетные записи — это особый вид учетных записей федерации. Внешних пользователей "приглашают" присоединиться к системе управления удостоверениями организации, используя учетные данные своей организации. Создается запись пользователя, но когда гостевой пользователь выполняет проверку подлинности, он делает это в своей домашней организации. Благодаря этому пользователю не нужно управлять дополнительным набором учетных данных. Это также избавляет ИТ-специалистов от необходимости быть осведомленными об изменении состояния пользователя в их домашней организации. После удаления записей пользователей из системы домашними ИТ-специалистами эти пользователи больше не смогут проходить проверку подлинности ни в одной из систем.
Ссылки
- Национальный центр кибербезопасности (2019 г.). Защита Office 365 с улучшенной конфигурацией. https://www.ncsc.gov.uk/blog-post/securing-office-365-with-better-configuration