Контроль привілейованих користувачів (PAM)

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

На практиці 90% інцидентів в хостингу так чи інакше пов'язані з доступом привілейованих користувачів: Адмін, службовий аккаунт, підрядник, забутий root без 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 для всіх доступів привілейованих користувачів
• ЈІТдоступ замість постійних прав
• Немає паролів в голові тільки через 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 для всіх сисадмінів,
• ЈІТдоступ (видається на 30-60 хвилин),
• запис усіх сеансів SSH та RDP

Розділили ролі користувачів:

• сисадмін виконує всі необхідні операції,
• аудитор переглядає журнали та записи

Підрядникам зробили вхід:

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

Результат

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

Але тепер картина виглядала інакше:

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

видно:

• які команди виконувалися,
• в який час,
• з якого IP,
• під яким узгодженим тікетом;
• подію закрили за 40 хвилин без ескалацій і конфліктів.

Додатковий ефект, який клієнт не очікував:

• адміни стали працювати акуратніше, знаючи про прозорість;
• підрядники перестали "експериментувати" в продакшені;
• на зовнішньому аудиті по ІБ контроль користувачів закрив відразу кілька зауважень.

Систему майже ніколи не впроваджують "заздалегідь" його встановлюють після першої серйозної події.

Але компанії, які роблять це до аварій, заощаджують:

• час на розслідування,
• гроші на простоях,
• нерви на розбірках "хто винен".

Часті питання