Что такое управление удостоверениями и доступом (IAM)?

В этой статье вы узнаете о некоторых основных понятиях управления удостоверениями и доступом (IAM), почему это важно и как это работает.

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

Сведения об основных терминах и понятиях см. в статье Основы идентификации.

Что делает IAM?

Системы IAM обычно предоставляют следующие основные функциональные возможности:

• Управление удостоверениями — процесс создания, хранения и управления сведениями об удостоверениях. Поставщики удостоверений (IdP) — это программные решения, которые используются для отслеживания удостоверений пользователей и управления ими, а также разрешений и уровней доступа, связанных с этими удостоверениями.
• Федерация удостоверений . Вы можете разрешить пользователям, у которых уже есть пароли в других местах (например, в корпоративной сети или с поставщиком удостоверений Через Интернет или социальные сети), получить доступ к вашей системе.
• Подготовка и отзыв пользователей . Процесс создания учетных записей пользователей и управления ими, который включает указание пользователей, имеющих доступ к тем или иным ресурсам, а также назначение разрешений и уровней доступа.
• Проверка подлинности пользователей . Проверка подлинности пользователя, компьютера или программного компонента путем подтверждения того, что они являются кем или что они говорят. Вы можете добавить многофакторную проверку подлинности (MFA) для отдельных пользователей, чтобы обеспечить дополнительную безопасность или единый вход (SSO), чтобы пользователи могли проходить проверку подлинности на одном портале, а не на нескольких разных ресурсах.
• Авторизация пользователей . Авторизация гарантирует, что пользователю предоставляется точный уровень и тип доступа к средству, на которое он имеет право. Пользователи также могут быть разделены на группы или роли, чтобы большие когорты пользователей могли быть предоставлены те же привилегии.
• Управление доступом — процесс определения того, кто или что имеет доступ к тем или иным ресурсам. Сюда входит определение ролей и разрешений пользователей, а также настройка механизмов проверки подлинности и авторизации. Контроль доступа регулирует доступ к системам и данным.
• Отчеты и мониторинг . Создавайте отчеты после действий, выполненных на платформе (например, во время входа, доступ к системам и тип проверки подлинности), чтобы обеспечить соответствие требованиям и оценить риски безопасности. Получите аналитические сведения о шаблонах безопасности и использования вашей среды.

Принцип работы IAM

В этом разделе представлен обзор процесса проверки подлинности и авторизации, а также более распространенных стандартов.

Проверка подлинности, авторизация и доступ к ресурсам

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

1. Пользователь (владелец ресурса) инициирует запрос проверки подлинности с помощью поставщика удостоверений или сервера авторизации из клиентского приложения.
2. Если учетные данные действительны, поставщик удостоверений или сервер авторизации сначала отправляет маркер идентификатора, содержащий сведения о пользователе, обратно в клиентское приложение.
3. Поставщик удостоверений или сервер авторизации также получает согласие пользователя и предоставляет клиентскому приложению авторизацию для доступа к защищенному ресурсу. Авторизация предоставляется в маркере доступа, который также отправляется обратно в клиентское приложение.
4. Маркер доступа присоединяется к последующим запросам, выполняемым к защищенному серверу ресурсов из клиентского приложения.
5. Поставщик удостоверений или сервер авторизации проверяет маркер доступа. В случае успешного выполнения запроса на защищенные ресурсы отправляется ответ в клиентское приложение.

Стандарты проверки подлинности и авторизации

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

OAuth 2.0

OAuth — это протокол управления удостоверениями с открытыми стандартами, который обеспечивает безопасный доступ для веб-сайтов, мобильных приложений, Интернета вещей и других устройств. Он использует токены, зашифрованные при передаче, и устраняет необходимость совместного использования учетных данных. OAuth 2.0, последний выпуск OAuth, является популярной платформой, используемой основными социальными медиа-платформами и потребительскими услугами, от Facebook и LinkedIn до Google, PayPal и Netflix. Дополнительные сведения см. в статье Протокол OAuth 2.0.

OpenID Connect (OIDC)

С выпуском OpenID Connect (в котором используется шифрование с открытым ключом), OpenID стал широко активных уровней проверки подлинности для OAuth. Как и SAML, OpenID Connect (OIDC) широко используется для единого входа, но OIDC использует REST/JSON вместо XML. OIDC был разработан для работы с собственными и мобильными приложениями с помощью протоколов REST/JSON. Однако основным вариантом использования SAML являются веб-приложения. Дополнительные сведения см. в статье Протокол OpenID Connect.

Веб-маркеры JSON (JWT)

JWT — это открытый стандарт, который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. JWT можно проверять и доверять, так как они подписаны цифровой подписью. Их можно использовать для передачи удостоверения пользователей, прошедших проверку подлинности, между поставщиком удостоверений и службой, запрашивающей проверку подлинности. Они также могут проходить проверку подлинности и шифроваться. Дополнительные сведения см. в статье Веб-токены JSON.

Security Assertion Markup Language (SAML)

SAML — это открытый стандарт, используемый для обмена информацией о проверке подлинности и авторизации между, в данном случае, решением IAM и другим приложением. Этот метод использует XML для передачи данных и обычно используется платформами управления удостоверениями и доступом для предоставления пользователям возможности входа в приложения, интегрированные с решениями IAM. Дополнительные сведения см. в статье Протокол SAML.

System for Cross-Domain Identity Management (SCIM)

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

Федерация веб-служб (WS-Fed)

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

Дальнейшие действия

Дополнительные сведения см. на следующих ресурсах:

• Единый вход (SSO)
• Многофакторная идентификация (MFA)
• Проверка подлинности (аутентификация) и авторизация
• OAuth 2.0 и OpenID Connect
• Типы приложений и потоки проверки подлинности
• Маркеры безопасности Центра Интернета вещей

Концепции

Ниже приведены основные концепции, необходимые для понимания работы сервиса IAM.

На этой странице

• Аккаунт
• Пользователь IAM
• Взаимосвязь аккаунта и его пользователей IAM
• Учетные данные
• Виртуальное MFA-устройство
• Группа пользователей
• Авторизация
• Разрешения
• Проект
• Представительство
• Корпоративный проект (Enterprise-проект)

Аккаунт

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

Пользователь IAM

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

Взаимосвязь аккаунта и его пользователей IAM

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

Учетные данные

Учетные данные подтверждают права пользователя, когда пользователь получает доступ к облачной платформе через консоль или API. Администратор аккаунта может управлять своими учетными данными и учетными данными созданных пользователей IAM. Учетные данные включают пароль и ключи доступа:

• Пароль — общие учетные данные для входа в консоль управления или вызова API.
• Ключ доступа — пара идентификатор ключа доступа/секретный ключ доступа (AK/SK), которая может использоваться только для вызова API.

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

Виртуальное MFA-устройство

Виртуальное MFA-устройство — это приложение, которое генерирует 6-значные проверочные коды в соответствии со стандартом алгоритма одноразовых паролей на основе времени ( TOTP Algorithm ). MFA-устройства могут быть аппаратными или программными. В настоящее время облачная платформа поддерживает программные виртуальные MFA-устройства, которые представляют собой прикладные программы, работающие на интеллектуальных устройствах, таких как мобильные телефоны.

Группа пользователей

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

По умолчанию новые пользователи IAM не имеют разрешений.

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

Авторизация

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

Разрешения

Разрешения предоставляются объектам IAM (пользователям, группам и ролям), при этом по умолчанию у этих объектов отсутствуют какие-либо разрешения.

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

IAM поддерживает как системные, так и пользовательские политики.

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

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

Проект

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

Представительство

Представительство — это доверительные отношения, которые можно установить между аккаунтами или между аккаунтом и облачным сервисом для делегирования доступа к ресурсам.

• Делегирование аккаунта — можно делегировать другой аккаунт для реализации O&M на своих ресурсах на основе назначенных разрешений.
• Делегирование облачных сервисов — сервисы облачной платформы взаимодействуют друг с другом, а некоторые облачные сервисы зависят от других сервисов. Можно создать представительство, чтобы делегировать облачный сервис для доступа к другим сервисам.

Корпоративный проект (Enterprise-проект)

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

Выбираем IAM в 2023 или, что есть кроме Keycloak

Гипотетическая ситуация — ваш работодатель поручил вам выбрать Identity and Access Management platform.

Обязательно: open-source (Apache 2.0), self-hosted, OAuth 2.0, OIDC, SAML, LDAP.

Желательно: чтобы вас не уволили в ближайшие пару месяцев после внедрения.

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

С такими вводными 7 из 10 человек порекомендуют вам Keycloak и надо признать, не просто так. OpenIdСertified, восьмилетний матерый гигант, стал стандартом дефакто.

keycloak.org — встречает вас строгим внешним видом, обещая вам увлекательное путешествие в мир Enterprise решений и Java плагинов. О, да, вы точно полюбите Java плагины! У вас будут ваши собственные Java плагины, плагины других людей, которые вы когда-то поставили и теперь вынуждены поддерживать, т.к. их автор потерял всякий интерес к keycloak, а возможно и к жизни. Но не волнуйтесь, это ровно до тех пор, пока вы не решите обновить ваш IAM до новой, последней версии, ведь вместе с ней, половина ваших плагинов скорее всего просто перестанет работать.

Тем не менее, обилие функционала из коробки, наличие комьюнити, в том числе и русскоязычного (X5, Сбер, РСХБ) делают keycloak отличным выбором, особенно если у вас в компании уже есть Java стек.

Но как быть, если нет ни Java стека, ни моральной готовности разбираться с плагинами?

Если вы подумали, что вот бы как keycloak, но только на GO.

Знакомьтесь, CASDOOR

Casdoor — A UI‑first Identity Access Management (IAM) / Single‑Sign‑On (SSO) platform. OAuth 2.0, OIDC, SAML and CAS, integrated with Casbin RBAC and ABAC permission management.

Авторы Casbin не побоялись бросить вызов королю опенсорсных IAM’ов, что не удивительно, ведь уже не так страшно, когда твоя рабочая почта заканчивается на @qq.com, а за твоими плечами стоит такая «маленькая» компания как. Tencent.

Посмотреть как выглядит китайский IAM можно вот тут — https://door.casdoor.com.

Впечатления, как от современной китайской машины — на первый взгляд тут есть все — OAuth 2.0, OIDC, SAML, WebAuthn, синхронизация с LDAP, multi‑tenants, rate‑limit, captcha, обилие OAuth провайдеров из коробки. Для интеграции и кастомизации предлагается пакет SDK с поддержкой большинства популярных языков RESTful API и возможность зарегистрировать webHook на ключевые события в системе.

Из минусов можно отметить маленькое русскоязычное (да и англоязычное) комьюнити. Оно настолько маленькое, что его в общем то и нет. Отчасти это можно списать на молодой возраст проекта. Радует, что авторы достаточно активны на гитхабе, регулярно выпускают релизы и прислушиваются к фича реквестам. Вот пример, когда в марте попросили добавить rate‑limit на логин и в августе уже вышел релиз. Кроме того не забываем, что это не просто пет проект пары энтузиастов. Если посмотреть на родной сайт https://casbin.com, то явно видна ставка на Casbin + Casdoor.

Ну а для тех, кому мало одной альтернативы — есть вторая:

Zitadel — Молодой стартап из Швейцарии, первый релиз был выложен на гитхабе в апреле 2020. За три года компания успела получить статус OpenIdСertified, выиграть пару наград, как лучший стартап в области инфосекьюрити.

API‑first approach и Strong audit trail — декларируются как основные преимущества продукта. Цитадель предоставляет полный доступ ко всем возможностям продукта через GRPC и REST APIs. Strong audit trail — достигается за счет используемой архитектуры CQRS + event sourcing. По факту это дает как минимум две вещи: первое это — полную прозрачность происходящего в системе, второе — возможность использовать механизм Actions как реакцию на любое событие в системе. Если быть точным, такая опция появится в ближайшее время после реализации [Epic]: Action possibility on each event. Кстати, проект ведет публичный Roadmap, поэтому можно всегда быть в курсе на чем фокусируется команда.

Теперь немного о минусах.

Интеграция с LDAP еще в процессе разработки, однако уже есть draft PR add ldap provider login #5328, исходя из оригинальной задачи команда планирует успеть выпустить релиз в первом квартале 2023.

Модели доступа Zitadel поддерживает два подхода RBAC и ABAC, подробнее про реализацию можно тут. Однако в отличии от Casdoor, концепция permissions отсутствует, только Role и user‑metadata.

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

Небольшая сводная таблица характеристик

При подготовке материала использовались источники:
https://learn.microsoft.com/ru-ru/azure/active-directory/fundamentals/introduction-identity-access-management
https://cloud.ru/ru/docs/iam/ug/topics/concepts.html
https://habr.com/ru/articles/720490/