Как выбрать PAM: критерии, сценарии и чек-лист

Короткий ответ: сначала определите регуляторный статус — субъект КИИ или госсектор требует сертификат ФСТЭК с проверенным сроком действия, коммерческая компания без таких обязательств выбирает свободнее. Дальше составьте список целевых систем и протоколов, к которым нужен привилегированный доступ (SSH и RDP, базы данных, веб-консоли, сеть), и сверьте его с тем, что кандидат поддерживает «из коробки».

Проверьте устройство хранилища паролей и ротацию учётных данных, нужен ли агент на целевых узлах или система работает как безагентный прокси-шлюз, есть ли workflow согласования заявок, и только в конце сравнивайте лицензирование и совокупную стоимость владения.

PAM (Privileged Access Management, управление привилегированным доступом) контролирует учётные записи с повышенными правами: администраторов серверов, баз данных и сетевого оборудования, подрядчиков и внешних аутсорсеров ИТ-услуг, сервисные и технические аккаунты приложений. Ядро типичного PAM-решения — защищённое хранилище паролей и секретов (password vault) с автоматической ротацией, шлюз или брокер доступа, который проксирует привилегированные сессии по протоколам SSH, RDP, Telnet, HTTP(S), SQL, PowerShell и записывает их в виде видео и текстового лога, и модуль контроля в реальном времени — вплоть до принудительного разрыва подозрительного подключения.

PAM — не то же самое, что SSO (единый вход закрывает вход рядовых сотрудников в бизнес-приложения по протоколам SAML/OIDC, без записи сессий и без хранения паролей от инфраструктуры) и не то же самое, что IdM (управление полным жизненным циклом обычных учётных записей — приём на работу, перевод, увольнение, согласование заявок на доступ).

PAM не назначает права — он контролирует, что реально делает уже допущенная до системы узкая группа привилегированных пользователей. На практике часть вендоров продаёт эти классы как модули одной Identity-экосистемы: например, у Индид Access Manager отвечает за SSO, а Privileged Access Manager — отдельный PAM-продукт.

PAM нужен, если в организации больше десятка администраторов, подрядчиков с доступом к инфраструктуре или технических учётных записей приложений, а пароли от них хранятся в файле или менеджере паролей общего назначения. Для субъектов КИИ и компаний с внешним ИТ-аутсорсингом порог ниже — контроль сессий подрядчика важен независимо от общего числа привилегированных учёток.

Для небольшой организации с парой серверов полноценный PAM зачастую избыточен: сначала стоит закрыть базовые классы защиты, а PAM подключать, когда появляется масштаб. Список конкретных продуктов — на странице класса PAM.

Ниже — критерии, которые стоит проверять у любого кандидата. Вес каждого меняется в зависимости от масштаба инфраструктуры, регуляторного статуса и того, кто будет систему эксплуатировать.

• Доверять номеру сертификата ФСТЭК без проверки срока действия. У части продуктов одновременно числится действующий и уже истёкший сертификат на разные версии линейки — название продукта на сайте вендора не гарантирует, что именно эта версия сертифицирована на дату закупки.
• Не сверять список протоколов с ИТ-ландшафтом до подписания договора. Отраслевые системы, старые СУБД и самописные веб-консоли часто остаются вне типового списка поддерживаемых протоколов — и выясняется это на этапе внедрения, а не выбора.
• Выбирать PAM только как хранилище паролей, без workflow согласований. Сейф с автоподстановкой пароля решает задачу удобства, но не контроля — без маршрута согласования и доступа на ограниченное время число постоянно активных привилегированных учёток продолжает расти.
• Игнорировать отказоустойчивость на этапе выбора. PAM — точка входа ко всей критичной инфраструктуре: авария шлюза доступа без продуманного резервирования оставляет администраторов без доступа даже к аварийным работам.
• Не закладывать в TCO стоимость интеграции с целевыми системами. Цена лицензии — обычно меньшая часть расходов; настройка под нетиповые системы, обучение и сопровождение часто считают отдельно и позже, что искажает сравнение вендоров.

1. Определите, обязателен ли для вас сертификат ФСТЭК (субъект КИИ, госорган, компания с госучастием).
2. Составьте список целевых систем и протоколов (SSH, RDP, СУБД, веб-консоли, сеть) и сверьте с тем, что кандидат поддерживает без доработки.
3. Проверьте архитектуру хранилища паролей и частоту автоматической ротации учётных данных.
4. Уточните, работает ли система в безагентном режиме или требует установки агента на целевых узлах.
5. Проверьте наличие workflow согласования заявок и доступа на ограниченное время (just-in-time).
6. Оцените готовые интеграции с вашим IdM и SIEM, если они есть или планируются в контуре.
7. Спросите про архитектуру отказоустойчивости и процедуру аварийного доступа при отказе системы.
8. Посчитайте TCO на 3 года: лицензия, внедрение, интеграция с целевыми системами, обучение и сопровождение.
9. Уточните SLA техподдержки вендора и наличие сертифицированных партнёров-интеграторов в регионе.
10. Запросите пилот на реальном фрагменте инфраструктуры, а не на демо-стенде вендора, и сверьте срок действия сертификата ФСТЭК в госреестре СЗИ ФСТЭК перед подписанием договора.

Критерии выше помогают сузить список кандидатов, но финальный выбор — это сравнение конкретных продуктов по вендору, статусу в реестре, сертификату и покрытию протоколов. На SecRadar это два инструмента: каталог класса и радар — визуальное сопоставление по возможностям, присутствию и комплаенсу.

Смежные классы, которые часто внедряют вместе с PAM: IdM — управляет полным жизненным циклом обычных учётных записей и определяет, кому положен привилегированный доступ, SSO — закрывает вход рядовых сотрудников в бизнес-приложения по отдельному протоколу федерации, MFA — многофакторная аутентификация, которую большинство PAM-систем требует перед выдачей привилегированного доступа. Для субъектов КИИ регуляторные требования к системе безопасности разобраны в разделе «КИИ» на SecRadar.