Контроль привилегированных пользователей (PAM)

PAM ͏это вид систем, которые к͏онтр͏олируют абсолютно всех пользователей, а также учетные записи͏ вместе с расширенными правам͏и, фиксируют воздействия и уменьш͏аю͏т риски͏ нарушения безопасности ͏инфраструктуры.

На практике 90% инцидентов в хостинге так или иначе ͏связаны с доступом привилегированных пользователей: админ, служебный аккаунт, подрядч͏ик, забытый ro͏ot без MFA. Именно здесь PAM закрывает самые болезненные дыры. PAM это единая система контроля учётных записей и сессий.

Что считается привилегированны͏м доступом

К числу привилегированных пользователей относятся:

• root Administrator
• администраторы домена (AD)
• локальные администраторы серверов
• администраторы приложений и БД
• сервисные и технические аккаунты пользователей
• бизнес-пользователи
• emergency-аккаунты (break glass)

Любой привилегированный пользователь, способный изменять конфигурацию, получать доступ к информации, или останавливать сервисы, должен быть под PAM.

Зачем компаниям и хостинг-клиентам нужен PAM

Чтобы знать кто, когда, куда и зачем зашёл, и иметь возможность это доказать.

Типовые проблемы без PAM

• Пароли от root передаются в мессенджерах
• Нет логов деяний администраторов
• Подрядчики имеют постоянный доступ
• Сервисные аккаунты пользователей живут годами без ротации
• Инциденты невозможно расследовать

С точки зрения хостинг-провайдера прямой путь к:

• простоям,
• утечкам,
• штрафам по регуляторке,
• конфликтам с заказчиком.

Принцип работы PAM системы

Пользователь не знает пароль, а получает временную сессию под PAM контроль.

Как это выглядит технически

• Учётные сведения пользователей хранятся в защищённом хранилище PAM
• Юзер проходит аутентификацию (часто с MFA)

PAM выдаёт допуск:

• по времени (JIT)
• по роли
• по осуществлению конкретных действий пользователей

Вся сессия:

• записывается
• логируется
• может быть остановлена

Основные функции PAM

Чем PAM реально помогает в эксплуатации

• Абсолютный контроль видим все входы и результаты действий пользователей
• Прозрачность любой инцидент разбирается по минутам
• Безопасность даже скомпрометированный результат действий пользователей ограничен
• Комфорт админы работают через единый доступ
• Соответствие требованиям ISO, PCI DSS, SOC, 152-ФЗ

PAM контроль, PIM, IAM в чём разница

В реальных проектах контроль привилегированных пользователей всегда дополняет IAM, а не заменяет его.

Рекомендации по использованию PAM (из практики)

• Обязательная MFA для всех доступов привилегированных пользователей
• JITдоступ вместо постоянных прав
• Нет паролям в голове только через PAM
• Запись всех сессий без исключений
• Разделение ролей (админ аудитор)
• Контролировать действия пользователей, кроме входа

Как контроль привилегированного доступа встраивается в контур ИБ

PAM обычно интегрируется с:

• Active Directory LDAP
• SIEM
• SOC
• VPN и bastion-хостами
• облачными платформами

Для хостинг-провайдера ключевой элемент zero trust-архитектуры.

Как выбрать такой контроль действий: ключевые критерии

На что смотреть

• Поддержка нужных ОС и сервисов
• Фиксация сессий (SSH, RDP, DB)
• Гибкие политики привилегированных пользователей
• Масштабируемость
• Объединение с AD и SIEM
• Работа с подрядчиками
• Локальное и облачное развёртывание

Оберегает ли PAM от кибератак?

PAM система не панацея, но он закрывает самый опасный класс рисков злоупотребление привилегиями.

Он эффективно защищает от:

• внутреннего злоумышленника
• компрометации учётных данных
• ошибок сисадминов
• несанкционированного допуска

Результат после внедрения

После внедрения клиенты обычно получают:

• Дополнительный уровень защиты
• Повышенный контроль действий пользователей
• Прозрачные процессы
• Быстрое расследование инцидентов
• Спокойствие на аудитах

Реальный кейс из практики

Клиент средняя SaaS-компания (≈120 серверов: bare metal VM), собственная DevOps-команда, часть инфраструктуры обслуживается внешними подрядчиками. Вход SSH/RDP напрямую, учётные записи общие, пароли меняются «по необходимости».

Проблема

Однажды ночью мониторинг зафиксировал резкий рост нагрузки на БД и деградацию сервиса. Клиент обратился к нам как к хостинг-провайдеру с запросом на срочный разбор инцидента.

Что выяснилось:

• изменения в конфигурации PostgreSQL были внесены вручную;
• кто именно вносил изменения неизвестно;

допуск к серверу имели:

• два штатных сисадмина,
• один DevOps,
• подрядчик по сопровождению БД;
• логи SSH есть, но без понимания, какие команды выполнялись.

Фактически классическая ситуация: конфликт есть, ответственного нет.

Решение

• После инцидента клиент согласился на поэтапное внедрение системы.

Что сделали:

• Вынесли весь привилегированный допуск через PAM bastion
• Убрали прямой SSH/RDP на сервера

Настроили:

• MFA для всех сисадминов,
• JITдоступ (выдаётся на 30–60 минут),
• запись всех сессий SSH и RDP

Разделили роли пользователей:

• сисадмин выполняет все необходимые операции,
• аудитор просматривает логи и записи

Подрядчикам сделали вход:

• только к конкретным серверам,
• только в рабочее время,
• без знания паролей

Результат

Через два месяца после внедрения произошёл похожий конфликт изменение параметров приложения привело к частичному простою.

Но теперь картина выглядела иначе:

• за 5 минут был найден конкретный юзер;
• в Privileged Access Management была разрешена полная фиксация SSH-сессии;

видно:

• какие команды выполнялись,
• в какое время,
• с какого IP,
• под каким согласованным тикетом;
• происшествие закрыли за 40 минут без эскалаций и конфликтов.

Дополнительный эффект, который клиент не ожидал:

• админы стали работать аккуратнее, зная о прозрачности;
• подрядчики перестали «экспериментировать» в продакшене;
• на внешнем аудите по ИБ контроль пользователей закрыл сразу несколько замечаний.

Систему почти никогда не внедряют “заранее” его устанавливают после первого серьёзного происшествия.

Но компании, которые делают это до аварий, экономят:

• время на расследования,
• деньги на простоях,
• нервы на разборках «кто виноват».

Частые вопросы