Identity and Access Management
~ 40 минут
Аутентификация или авторизация пользователя будут невозможны, если в системе для него не заведён аккаунт. В этом уроке разберём, как завести аккаунт и дать пользователю нужные доступы.
Что такое Identity and Access Management
✏️ Identity and Access Management, или IAM, — это комплекс технологий, процессов и политик для управления идентификацией пользователей и их доступом в систему.
IAM решает несколько задач:
- Работа с учётными записями. Создание, удаление пользовательских и сервисных учётных записей, управление ими.
- Управление доступом пользователей и сервисов. Настройка ролей, их доступов и пользователей. Настройка аутентификации, авторизации пользователей, работа со cлужбой единого входа — SSO.
- Федеративное управление идентификацией (Federation Identity). Использование IAM с другими системами идентификации пользователей.
- Аудит и мониторинг. Выявление подозрительной активности и узких мест в работе системы.
В зависимости от требований бизнеса каждую из этих задач можно реализовать в одном либо нескольких сервисах. Но интеграция этих решений между собой может быть сложной или невозможной задачей. По каждому решению нужно будет постоянно отслеживать слабые места в реализации и используемых библиотеках. Если эти слабые места обнаружатся, нужно будет дописывать систему и устранять их.
Плюсы IAM
- Чувствительные данные лучше защищены. Риск несанкционированного доступа к таким данным и системам снижается.
- На администрирование учётных записей и доступов уходит меньше времени и усилий.
- IAM помогает организациям соответствовать нормативным и отраслевым стандартам по управлению доступом к данным и их защите.
- IAM обеспечивает SSO — единый вход для доступа к нескольким системам и приложениям. Это упрощает работу и улучшает пользовательский опыт.
Типы IAM
Есть два типа реализации IAM:
- On-premise — программное обеспечение развёрнуто на собственных серверах компании. Это может быть внутренняя разработка компании, платная коммерческая версия (например, MiniOrange) или open source-решение (например, Keycloak), или коробочные решения, находящиеся в инфраструктуре облаков.
☝ Использовать внутреннюю разработку крайне нежелательно. Правильно проработать все аспекты безопасности и самостоятельно протестировать их — сложная и очень дорогая задача, при этом риск ошибки очень высок. Популярные решения на рынке уже многократно протестированы и отлажены. Поэтому целесообразнее и безопаснее использовать их.
- Cloud-based — программное обеспечение развёрнуто в облаке.
В таблице ниже — преимущества и ограничения обоих типов.
Примеры сервисов для реализации IAM: AWS IAM, AWS Cognito, Firebase, Google Cloud, Microsoft Azure Active Directory (Entra), Okta, Kratos.
Модели предоставления доступа
Есть две модели разделения доступов — ролевая и атрибутивная. Как они работают и в чём между ними разница, удобнее рассмотреть на примере. Возьмём компанию по производству и продаже бионических протезов BionicPRO. Доступ к системе компании потребуется администраторам, покупателям и продавцам.
В зависимости от роли доступ будет давать пользователям права на совершение разных операций.
Дальше разберём, как для такой системы реализовать ролевую и атрибутивную модели. Начнём с ролевой — с ней вы уже немного знакомы по задачам о безопасности данных.
Модель RBAC
✏️ Role-Based Access Control (RBAC) — модель разделения доступов к данным на основе ролей.
В этой модели нужно определить, какие разрешения есть у пользователя, то есть какие действия в системе ему доступны. Дальше из этих разрешений нужно собрать роль.
Представьте, что роль — это лукошко, где лежат разные разрешения. Когда надо авторизовать пользователя на какое-либо действие, нужно посмотреть на его роль: есть ли в лукошке нужное разрешение.
Архитектура RBAC
RBAC состоит из таких сущностей:
- Subject — субъект, к которому применяется модель.
- Role — название роли пользователя, для которой определяется уровень доступа.
- Permissions — действия, которые выполняет пользователь в системе.
- Session — состояние, в рамках которого действует разрешение.
Механизм работы RBAC выглядит так:
Теперь можно попробовать описать роли для системы управления заказами в BionicPRO с помощью модели RBAC.
RBAC Policy для системы управления заказами
Вот какие разрешения можно сформулировать:
- VIEW_ALL_ORDERS: просмотр всех заказов,
- VIEW_OWN_ORDERS: просмотр своих заказов,
- CREATE_ORDER: создание заказа,
- DELETE_ORDER: удаление заказа,
- DELETE_OWN_ORDER: удаление своего заказа,
- VIEW_DELETED_ORDER: просмотр удалённых заказов
Как видно из таблицы, у такой схемы есть ограничения:
- Появляется много разрешений, которые описывают действия с одной и той же сущностью, например, «удалить заказ» и «удалить свой заказ». Со временем количество таких разрешений множится. Если, например, дополнительно разделить продавцов по филиалам, количество разрешений может очень резко вырасти. Предоставление доступов станет сложно поддерживать.
- Модель даёт общее описание ролей, но не охватывает некоторые пользовательские сценарии. Например, ситуацию, когда нужно удалить заказ, который клиент уже принял.
Из-за этих ограничений логику работы по такой модели сложнее инкапсулировать в каком-либо фреймворке.
В отличие от ролевой, атрибутивная модель позволяет описывать действия пользователей подробнее.
Модель ABAC
✏️ Attribute-Based Access Control (ABAC) — в этой модели доступ пользователю предоставляется на основе его атрибутов — объектов, действий, контекста.
Вместо ABAC часто встречаются названия Policy-Based Access Control (PBAC) и Claims-Based Access Control (CBAC), это синонимы.
В отличие от RBAC, модель ABAC не ограничена ролью как несущей конструкцией для прав, поэтому она позволяет описывать много других атрибутов.
Какие бывают категории атрибутов
- Атрибуты субъекта: возраст, роль, департамент, должность.
- Атрибуты действия: читать, просматривать, удалять, подтверждать.
- Атрибуты объекта (то, в отношении чего делается запрос): запись в медкнижке, банковский аккаунт, локация.
В каких стандартах применяется модель ABAC
- eXtensible Access Control Markup Language (XACML) — самый популярный стандарт для ABAC. XACML предоставляет язык политик для описания требований безопасности и обработки запросов на доступ. Стандарт подходит для сложных систем со множеством разнообразных ресурсов и тонкой настройкой политик безопасности.
- Abbreviated Language for Authorization (ALFA) — язык для создания политик XACML с более простым синтаксисом. ALFA подходит для организаций, которые хотят использовать возможности XACML, но нуждаются в более простом и понятном способе определения политик.
- Next Generation Access Control (NGAC) — стандарт для крупных организаций с высокими требованиями к масштабируемости. Обеспечивает высокий уровень безопасности. Его реализация может быть более сложной и требовательной к ресурсам по сравнению с другими стандартами.
Архитектура ABAC
ABAC состоит из таких сущностей:
- Policy Enforcement Point (PEP) — ответственный за защиту приложений и данных, к которым вы хотите применить модель. Он проверяет запрос и генерирует авторизационный запрос, который отсылается в PDP.
- Policy Decision Point (PDP) — «мозг» архитектуры, он проверяет входящий запрос на соответствие утверждённым политикам и возвращает положительный или отрицательный ответ для допуска. Если нужны дополнительные данные, PDP может обращаться к Policy Information Point — об этом в следующем пункте.
- Policy Information Point (PIP) — источник информации для политики. Соединяет PDP с информацией из внешних источников (например, с базой данных).
- Policy Administration Point (PAP) — точка управления политиками.
Механизм работы ABAC выглядит так:
PIP может получать данные из облачных хранилищ, базы данных и Lightweight Directory Access Protocol (LDAP, протокол прикладного уровня для доступа к службам каталогов). С первыми двумя вы уже знакомы, а с LDAP познакомитесь в следующем уроке.
Вы познакомились с устройством модели ABAC. Теперь можно посмотреть, как она работает на примере.
ABAC Policy для системы управления заказами
Чтобы создать ABAC Policy для системы управления заказами, нужно сначала определить и перечислить её атрибуты, а затем реализовать задуманную логику — написать саму политику.
Для компании BionicPRO описание атрибутов может выглядеть так:
Субъекты (Users)
- role: [administrator, customer, seller]
- id: string
- department: string
Объекты (Orders)
- id: string
- status: [created, in_progress, completed]
- creator_id: string
- customer_id: string
- created_at: datetime
Действия (Actions)
- view: просмотр заказа
- create: создание заказа
- delete: удаление заказа
Контекст (Environment)
- current_time: datetime
- is_business_hours: boolean
Этап 2. Реализация политики ABAC
Теперь пора реализовать задуманную логику в политике. Ниже в коде мы описали предыдущий пример для RBAC языком политик ABAC, используя при этом стандарт XAСML. Синтаксис этих политик ABAC, если научиться считывать его основные элементы: Policy, Target, Rule, Condition, — они описаны в документации XACML. Советуем выделить время и познакомиться в деталях с этим примером, чтобы понять, как устроена описанная политика.
XML
Готовый файл конфигурации можно загрузить в Policy Decision Point. У PDP могут быть свои требования к формату файла. Например, в Amazon Web Services, о котором речь пойдёт далее, используется собственный JSON-формат.
Вы изучили две модели предоставления доступа — RBAC и ABAC. Различия между ними наглядно показаны в таблице ниже:
Реализация IAM в Amazon Web Services
Для единого входа SSO, аутентификации и авторизации конечных пользователей в Amazon Web Services используется сервис IAM — Cognito. Вот как он выглядит:
Здесь есть группы пользователей, пользователи, роли. К каждой роли добавляются политики.
Как выглядит политика в AWS
Политики могут быть описаны в специфичном для конкретного PDP формате. Политика в AWS называется AlexaForBusinessFullAccess. Она позволяет чётко описать, что может делать конкретный субъект. По умолчанию она даёт полный доступ субъекту ко всем сервисам, которые связывает AWS.
Посмотрите на пример написания политики:
JSON
Из примера видно, что политика состоит из утверждений и каждое из них содержит:
- эффект (Effect),
- конкретные действия (Action),
- на какие ресурсы распространяется (Resource),
- при каких условиях работает (Condition).
Такое описание позволяет ёмко выразить много ситуаций с предоставлением доступов.
Задание 2
Перенесите утверждения к моделям управления доступами, для которых они характерны.
Задание 3
Выберите подходящую модель управления доступом для описанных ситуаций.
У банка сложная организационная структура из нескольких филиалов в разных странах, за сотрудниками чётко закреплены функции. Необходимо настроить доступ для корпоративной информационной системы.
ABAC
Несмотря на чёткое закрепление функций за сотрудниками, для банков со сложной структурой подойдёт настройка доступов с помощью ABAC. Эта модель более гибкая и позволит более безопасно настроить доступы.
В государственной организации работает 50 сотрудников, у каждого есть набор прав доступа к информации. Численность сотрудников за последние 3 года менялась не более, чем на 5%.
RBAC
В государственных организациях системы ролей и политики устроены сложно и распространяются на федеральном уровне. Обычно в таких случаях подходит модель ABAC. Но в этом примере речь о небольшом учреждении, численность сотрудников меняется незначительно, поэтому можно использовать модель RBAC.
Приложение компании численностью 350 сотрудников построено по монолитной архитектуре. DAU не превышает 500. Нужно быстро и просто управлять правами пользователей.
RBAC
Обе модели можно использовать и в микросервисной, и в монолитной архитектурах. Но для компании с небольшим количеством пользователей подойдёт модель RBAC. Она позволит быстро настроить доступы и экономить время и силы на её поддержку.
Приложение компании за год выросло с 300 до 800 сотрудников, и это было ожидаемо. Отделы продолжают формироваться. Руководство хочет настроить выдачу доступов сотрудникам к нужным системам. Желательно сделать это как можно быстрее, но самое главное — сохранить безопасность данных.
ABAC
В условиях активного ожидаемого роста компании подойдёт модель ABAC. Она потребует больше времени на внедрение. Но точно позволит выполнить главную для руководства цель — обеспечить безопасность данных.
Сеть клиник с множеством филиалов хранит петабайты данных и должна обеспечивать доступ к ним только тем специалистам, которые работают с пациентом.
ABAC
Данные о пациентах конфиденциальны, их безопасность должна быть на очень высоком уровне. С учётом большого количества филиалов клиники модель ABAC сможет обеспечить безопасное хранение и обработку данных.
Коммерческий проект использует межсервисную шину данных, построенную по микросервисной архитектуре. Есть множество пользовательских сценариев, единого описания у них нет. Компании важно повысить безопасность хранения и обработки данных.
ABAC
Модель ABAC позволяет настраивать доступы для сложных процессов, у которых нет чёткого описания.
Компания работает на международном рынке и соблюдает юридические и географические ограничения в странах присутствия.
ABAC
Для соблюдения требований других стран подойдёт модель ABAC. С помощью настройки атрибутов, использовании LDAP, Keycloak, а также Federated Identity можно обеспечить безопасный доступ к данным сотрудников разных странах.
О том, как это сделать, вы узнаете в следующем уроке.
Итоги
- IAM управляет идентификацией пользователей и их доступом в систему, помогает экономить ресурсы на управление учётными записями и обеспечить безопасность данных.
- Есть два типа реализации IAM — On-premise и Cloud-based. При реализации On-premise программное обеспечение развёрнуто на собственных серверах компании. При реализации Cloud-based оно развёрнуто в облаке.
- Доступы в IAM могут разделяться по двум моделями — ролевой и атрибутивной.
- Role-Based Access Control (RBAC) — модель разделения доступов к данным на основе ролей. Роль включает в себя разрешения — то, какие действия доступны пользователю. Эта модель подходит небольшим и средним организациям с чёткой структурой. Её можно быстро настроить и относительно легко поддерживать, но сложно масштабировать.
- Attribute-Based Access Control (ABAC) — в этой модели доступ пользователю предоставляется на основе его атрибутов — объектов, действий, контекста. Эту модель сложнее реализовать и поддерживать, но она подходит крупным организациям со сложной структурой. Она позволяет настраивать доступы для сложных процессов без чёткого описания и обеспечивает высокую безопасность данных.