🚨 Не войти не в ту дверь: идентификация, аутентификация, авторизация
📣Пост навеян интересной движухой у нас на работе, а именно — проектированием системы управления доступом, IAM. Не вдаваясь в детали, проектировать будем с самого нуля и я скажу честно, это видится интересной задачей. Ввиду текущей загрузки я ей буду заниматься мало, но буду менеджерить работу по ней и помогать новому коллеге-аналитику. В любом случае будет увлекательно! 🐈
Итак, пару слов о IAM. IAM — Identity and Access Management, управление идентификацией и доступом. Этот термин включает в себя все три компонента: идентификация, аутентификация и авторизация. Чуть детальнее:
✅ Идентификация — процесс распознавания пользователя. Иными словами, необходима для того, чтобы разобраться с вопросом: "Вы кто такой? Я вас не звал..." В контексте ИТ-продуктов: пользователь предоставляет email/номер телефона/логин (классика), публичный ключ (в асимметричных схемах), Client Certificate (для mTLS), whatever, сообщая тем самым системе свой уникальный идентификатор. В результате система понимает, под каким именем вы хотите работать и должна провалидировать в принципе наличие такого идентификатора. Это не даёт доступа, это просто декларация.
✅ Аутентификация — проверка заявленной идентичности. После успешной аутентификации система создаёт для пользователя сессию (хранимую на сервере или в БД) или выдаёт подписанный токен (например, JWT). Механизмы делятся по типу проверяемого фактора:
✅ Авторизация — предоставление прав на выполнение определённых действий или доступ к ресурсам после успешной аутентификации, иными словами — разделение по ролям. В рамках одного и того же ИТ-продукта у кого-то будет годмод (например, у специалиста поддержки), а кому-то можно будет только посмотреть. Реализовать авторизацию можно непосредственно в коде приложения/микросервиса, через API Gateway или на отдельном сервере авторизации. Из современных подходов можно отметить:
Вообще, у меня был опыт работы над ролевой моделью и авторизацией на прошлом месте работы. Знаете, чем все закончилось? Я уволился и оставил это все в наследство своем другу. 😰 Но это совсем другая история. 🍔
В качестве вывода: разделение процессов IAM — основа для проектирования безопасной, понятной и масштабируемой системы управления доступом.
#SystemAnalysis #безопасность #авторизация #аутентификация #архитектура #системныйанализ #cybersecurity
📣Пост навеян интересной движухой у нас на работе, а именно — проектированием системы управления доступом, IAM. Не вдаваясь в детали, проектировать будем с самого нуля и я скажу честно, это видится интересной задачей. Ввиду текущей загрузки я ей буду заниматься мало, но буду менеджерить работу по ней и помогать новому коллеге-аналитику. В любом случае будет увлекательно! 🐈
Итак, пару слов о IAM. IAM — Identity and Access Management, управление идентификацией и доступом. Этот термин включает в себя все три компонента: идентификация, аутентификация и авторизация. Чуть детальнее:
✅ Идентификация — процесс распознавания пользователя. Иными словами, необходима для того, чтобы разобраться с вопросом: "Вы кто такой? Я вас не звал..." В контексте ИТ-продуктов: пользователь предоставляет email/номер телефона/логин (классика), публичный ключ (в асимметричных схемах), Client Certificate (для mTLS), whatever, сообщая тем самым системе свой уникальный идентификатор. В результате система понимает, под каким именем вы хотите работать и должна провалидировать в принципе наличие такого идентификатора. Это не даёт доступа, это просто декларация.
✅ Аутентификация — проверка заявленной идентичности. После успешной аутентификации система создаёт для пользователя сессию (хранимую на сервере или в БД) или выдаёт подписанный токен (например, JWT). Механизмы делятся по типу проверяемого фактора:
🔘Что вы знаете (Knowledge): пароль, pin-код;
🔘Что у вас есть (Possession): OATH TOTP (коды из приложений типа Google Authenticator), FIDO2 / WebAuthn (аппаратные ключи — Yubikey), мобильное приложение с push-подтверждением;
🔘Что вы есть (Inherence): Биометрия (отпечаток, лицо).
✅ Авторизация — предоставление прав на выполнение определённых действий или доступ к ресурсам после успешной аутентификации, иными словами — разделение по ролям. В рамках одного и того же ИТ-продукта у кого-то будет годмод (например, у специалиста поддержки), а кому-то можно будет только посмотреть. Реализовать авторизацию можно непосредственно в коде приложения/микросервиса, через API Gateway или на отдельном сервере авторизации. Из современных подходов можно отметить:
🔘RBAC (Role-Based Access Control): Классика. Пользователю назначается роль (ADMIN, EDITOR, VIEWER), а роли привязаны к разрешениям. Реализуется через таблицы в БД или специализированные сервисы.
🔘ABAC (Attribute-Based Access Control): Гибкая модель. Решение принимается на основе атрибутов пользователя, ресурса, действия и контекста.
🔘ACL (Access Control Lists): Простое прикрепление списка разрешений прямо к ресурсу («Кто может читать этот файл»). Это подходит только к очень простым сценариям.
Вообще, у меня был опыт работы над ролевой моделью и авторизацией на прошлом месте работы. Знаете, чем все закончилось? Я уволился и оставил это все в наследство своем другу. 😰 Но это совсем другая история. 🍔
В качестве вывода: разделение процессов IAM — основа для проектирования безопасной, понятной и масштабируемой системы управления доступом.
#SystemAnalysis #безопасность #авторизация #аутентификация #архитектура #системныйанализ #cybersecurity