Case: Ритейл-компания внедрила PAM и закрыла прямой доступ к серверам файрволом. Через неделю CISO позвонил нашей команде с жалобой: «CyberArk тормозит работу, а администраторы не успевают закрывать тикеты». Когда начали разбираться, оказалось, что ведущий администратор, чтобы не играться с веб-порталом, открыл себе «черный ход» на файрволе и продолжал подключаться напрямую. На вопрос «Почему?» он честно сказал: «Мне неудобно». В результате компания месяц жила с иллюзией защиты, имея огромную дыру в безопасности.

Рекомендация: Не ломайте людям привычный флоу. В CyberArk есть Native Experience. Настройте прокси так, чтобы админ продолжал использовать свой любимый RDP-менеджер, PuTTY или WinSCP. Он даже не заметит, что сессия идет через PSM и записывается. Безопасность должна быть незаметной, иначе ее обойдут — это закон.

Case: Транспортная компания решила сделать все «правильно» и загнать в скоуп проекта сразу 5000 целевых систем за два месяца. Команда внедрения, состоявшая из трех человек, просто валилась с ног. Начался хаос: то проблемы с политиками, то пропали доступы, то заявки на доступ висят по три дня. Чем это кончилось? Бизнес начал жаловаться, что IT блокирует работу. Проект заморозили на полгода. Инвестиции не сработали, а репутация IT-безопасности пострадала.

Рекомендация: Забудьте о перфекционизме — ешьте слона по частям. Начните с Domain Admins. Всего несколько десятков аккаунтов, но это настоящие ключи от царства. Затем критические *nix root — это закроет 80% реальных рисков взлома. Принтеры и рабочие станции бухгалтеров могут подождать до следующего года. Лучше иметь железный функциональный контроль над ядром, чем хаос на периметре.

Case: Классическая история — пятница, вечер, заказчик решает включить авторотацию пароля для сервисного аккаунта svc_backup. CyberArk успешно меняет пароль в Active Directory, ничего не предвещает беды. В 3 часа ночи падает критическая база данных, потому что бэкап не прошел, и транзакционные логи забили диск.
Оказалось, что этот аккаунт использовался не только для службы бэкапа, но и был «захардкоджен» (т. е. прописан текстом) в каком-то старом скрипте 2018 года, о котором нынешние админы даже не знали. Скрипт постучал со старым паролем, AD заблокировала аккаунт, продакшн остановился.

Рекомендация: Никогда не включайте принудительную ротацию до тех пор, пока не найдете все зависимости. Сначала Discovery — всегда. Не включайте Enforcement (принуждение), пока сканеры (например DNA или EPM) не покажут полную карту зависимостей. Сначала лечим «технический долг» и вычищаем хардкод, только потом включаем ротацию. И никогда, слышите, никогда не делайте это в пятницу вечером.

Мой совет: если чувствуете, что ваш CyberArk превратился в «чемодан без ручки», или видите, как админы рисуют плакаты «Долой PAM!» — время обратиться за консультацией. Зачастую проблема решается не покупкой новых модулей, а правильным изменением архитектуры и подхода.

Технология должна работать на вас, а не наоборот.