PAM (Privileged Access Management) обычно всплывает в разговоре тогда, когда становится страшно от мысли, что у кого-то где-то есть постоянный root. Проще говоря, это отдельный класс систем, которые следят за тем, кто и как получает привилегированный доступ в инфраструктуре, и не дают этим правам жить своей жизнью.
Речь идёт не о рядовых аккаунтах, а о людях с «волшебными ключами» от продакшена: админы, DevOps, DBA, SRE и прочие специалисты, которые могут одним неверным действием уронить полкомпании. Перезапуск сервисов, дроп базы, изменения security-конфигов, деплой в прод — всё это зона ответственности PAM.
Зачем вообще связываться с PAM #
- Убрать идею постоянного root-доступа как класса. Никаких вечных суперпользователей.
- Ограничивать доступ по времени и по периметру: вот этот сервер, вот это окно, а дальше — извините.
- Добиваться того, чтобы каждый заход «поверх обычных прав» был одобрен и имел внятное обоснование.
- Записывать сессии: что делалось, куда заходили, какие команды запускали — чтобы потом можно было поднять логи и разбор полётов.
- Снижать риски злоупотреблений — и когда человек ошибся, и когда делал что-то намеренно.
Обычного IAM в этой зоне просто не хватает: ему важны аккаунты и роли, а вот кто именно и что делает в «системном» доступе, он контролирует довольно слабо.
Как это выглядит вживую #
- Инженеру нужно что-то «сделать руками» в проде. Он создаёт запрос в PAM: зачем, куда, на сколько времени.
- Кто-то (или политика) этот запрос одобряет, после чего PAM выдаёт временные права или одноразовый логин/пароль/токен.
- Доступ открывается только к указанному ресурсу и только в рамках согласованного окна.
- Вся сессия пишется: команда за командой, плюс часто ещё и экран (session recording).
- Как только время вышло или инженер вышел — доступ автоматически стопается, учётка/секрет инвалидируется.
Типичная сценка: DevOps приходит править конфиг Kubernetes-кластера. Он не логинится напрямую на мастер-нод, а идёт через PAM-шлюз, берёт доступ, скажем, на 45 минут, делает свои kubectl apply и прочие манипуляции. Если что-то пошло не так, служба безопасности может потом «прокрутить плёнку» и по шагам посмотреть, что именно происходило.
На рынке для этого есть целый зоопарк решений: CyberArk, Delinea, BeyondTrust, AWS Session Manager, Microsoft PIM в составе Azure AD и другие. Выбор зависит от того, вы в облаке, он-прем, гибрид, и какие у вас уже есть инструменты.
PAM особенно критичен в средах с высокой нагрузкой, жёсткими регуляторными требованиями (GDPR, ISO 27001, PCI DSS) и при DevSecOps-подходе, когда безопасность — часть пайплайна. Это защита не только от условного «злого хакера снаружи», а от своих же ошибок, странных скриптов и избыточных прав внутри.
Если по сути: PAM даёт прозрачность и управляемость системного доступа. Без него любой админский логин — потенциальная бизнес-угроза, о которой вы узнаете уже постфактум.
