IAM (Identity and Access Management) — это про то, кто к чему имеет доступ в вашей инфраструктуре и на каких условиях. Не только люди, но и сервисные аккаунты, боты, внешние подрядчики, временные пользователи и API-клиенты — все они где-то авторизуются и что-то могут. IAM как раз и отвечает за то, кто именно и к каким ресурсам под каким соусом допускается.
Ключевая идея здесь — принцип наименьших привилегий: доступ даётся ровно настолько, насколько нужно для работы, и не дальше. Это сильно режет риски: и от ошибок сотрудников, и от случайных утечек, и от ситуаций, когда взломали какую-то учётку и пытаются через неё пролезть дальше.
Обычно в IAM-платформах есть несколько базовых блоков функциональности:
- централизованная аутентификация и авторизация, одна точка управления доступами;
- модели управления правами: ролевая (RBAC) или на основе атрибутов (ABAC);
- поддержка многофакторной аутентификации (MFA);
- аудит и отчёты по действиям пользователей: кто что делал и когда;
- автоматическое назначение и отзыв прав при онбординге, переводе, увольнении;
- SSO (Single Sign-On), когда пользователь один раз логинится и дальше ходит по всем согласованным системам без повторного ввода пароля.
На практике это выглядит, например, так: в крупной компании развёрнут AWS IAM или Azure AD. DevOps-инженеру можно поднимать инстансы в тестовом кластере, но прямого доступа к продакшн-базе у него нет. Финансовому директору разрешено видеть отчёты, но не править их структуру. Все действия пишутся в логи, а при нарушении политик срабатывают оповещения.
Без внятного IAM жизнь быстро превращается в хаос: доступы раздаются «по дружбе», не отзываются годами, никто толком не знает, кто к чему имеет ключи. Плюс регуляторы вроде GDPR, ISO 27001, SOC 2 требуют внятного управления аккаунтами и правами. Поэтому IAM — это фактически фундамент для Zero Trust-подхода и нормальной кибербезопасности в любой компании, которая вышла за пределы «пять человек и один сервер под столом».
