Identity and Access Management – определение

Данный пост есть частично перевод, частично осмысление и дополнение видео от Питера Бьорка.

Согласно Википедии, Identity and Access Management (IdM или IAM) – это набор технологий, позволяющий указанным людям в организации получать указанный доступ к информационным ресурсам в указанное время и по указанным причинам. По ходу такого определения у меня в голове сразу всплывает ряд вещей:

  • Жизненный цикл учётных записей пользователей;
  • Проверка пользователя на то, что он именно тот, за кого себя выдаёт;
  • Простота доступа (наличие IAM не должно усложнять доступ).

Разберём тему Identity and Access Management подробнее.

Для начала, IAM состоит из ряда компонентов. В сердце технологии лежит база пользовательских учёток – именно с ней производится сверка при аутентификации. База обычно реализуется как каталог LDAP. Часто это MS Active Directory, но может быть и другой вариант: OpenLDAP, IBM ISAM, ALD и т.д.

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

На этом месте я сразу обозначу определения: под аутентификацией подразумевается задача определения личности пользователя. Проверки аутентификации делятся на 4 фактора:

  • Что-то, что я знаю (пароли, пин-коды);
  • Что-то, что у меня есть (токены, смарт-карты, телефон с зашитым ключём);
  • Что я собой представляю (биометрические данные, поведенческий анализ);
  • Что обо мне знают доверенные лица.

Комбинирование нескольких факторов называют многофакторной аутентификацией (Multi-factor Authentication – MFA). По итогам успешной аутентификации система производит авторизацию – процедуру выдачи доступа.

Далее, появление новых учётных записей в базе LDAP желательно автоматизировать, равно как и изменения с ними. Обычно производят подключение IAM к кадровой системе (HRMS), чтобы появление записи о человеке порождало создание его учётной записи. В задачи автоматизации также входит рабочий процесс согласования заявок и авто-развёртывания приложений для доступа.

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

Из чего состоит Identity and Access Management
Структура IAM

Аутентификация на основе запросов

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

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

Для решения такой ситуации люди давным-давно разработали аутентификацию на основе запросов. В инфраструктуре выделяется специальный узел аутентификации (Identity Provider, далее IdP), на котором публикуются все приложения и ресурсы. Пользователь проходит аутентификацию на IdP, после чего от лица IdP получает запрос на доступ к выбранному приложению и переходит на него на автомате – Single Sign-On (SSO). Переход осуществляется в рамках домена безопасности (Realm или Security Domain) – специально настроенной зоны, компоненты которой доверяют друг другу.

Доверие

Обозначим, что входит в доверие – это процедура взаимодействия двух и более компонентов домена безопасности на основе:

  • стандартов обмена данными;
  • обмена зашифрованными ключами (сертификатами безопасности);
  • обмена файлами метаданных: сертификат, URL захода, иные дополнительные параметры;
  • По ряду стандартов требуются Client ID и “секрет” заместо сертификата безопасности.

Федерация

Доверие может осуществляться в рамках одного домена безопасности или между несколькими доменами – в таком случае принято говорить о федерации. Федерация позволяет пользователям из одного домена безопасности получать доступ к ресурсам в другом домене безопасности. При этом, доверие принято делить на уровни (Level of Assurance – LOA). Если учётная запись пользователя была заведена с соблюдением строгих мер контроля, при запросе ресурса применялась MFA, можно судить о высоком уровне доверия. Напротив, если пользователь получил учётную запись по анонимно заполненной форме, для запроса применял простой пароль, то уровень доверия к такой учётной записи невысок.

В случае недостаточного LOA, домен безопасности в федерации вправе развернуть запрос обратно в домашний домен безопасности – для прохождения процедуры повышения LOA. Для этого нужно заранее определить домашний домен для конкретной учётной записи (tenant discovery). Такую процедуру сложно автоматизировать и обойтись без взаимодействия с пользователем. Это может быть предложение ввести EMail, по которому определяется домен через суффикс организации (так поступает, например, MS Office 365). Это также может быть специально созданная ссылка, переданная для конкретной организации (например, так делают на Webex площадке вебинаров). Бывают и комбинации двух перечисленных способов.

Запрос

Осталось разобрать, что такое запрос – блок данных, который создают IdP по итогам аутентификации:

  • В минимальном своём виде он содержит уникальный идентификатор пользователя (Unique User Identifier – UUID);
  • Запрос обычно подписан сертификатом. Часто запросы целиком шифруют для дополнительной безопасности;
  • Он включает информацию о том, смог ли пользователь аутентифицироваться. Зачем это нужно? – чтобы определять в принципе возможность пользователю аутентифицироваться в домене определённым способом;
  • Уровень доверия LOA;
  • Различные атрибуты пользователя: EMail, ФИО, входит учётная запись ли в группы безопасности, какие имеет роли, организация, параметры приложений.

Запрос может быть изменён по ходу аутентификации. Трансформация запроса: при заходе на IdP пользователь предоставляет свои данные с помощью одного стандарта (например, Kerberos), после чего IdP создаёт собственный запрос, который передаёт на приложение или на другой IdP. Таким образом, можно формировать цепочки идентификации (identity chain), когда два или более IdP передают друг другу данные об учётной записи пользователя, а целевое приложение доверяет лишь последнему IdP в цепочке. Удобным способом передачи запроса является алгоритм SAML, но подробнее о нём – уже в следующей статье.

Leave a Reply

Your email address will not be published. Required fields are marked *