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

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

Case: Транспортна компанія вирішила зробити все «правильно» і загнати в скоуп проєкту одразу 5000 цільових систем за два місяці. Команда впровадження, яка складалась з трьох людей, просто падала з ніг. Почався хаос: то проблеми з політиками, то доступи зникли, то заявки на доступ висять по три дні. Чим це закінчилося? Бізнес почав скаржитись, що ІТ блокує роботу. Проєкт заморозили на півроку. Інвестиції не спрацювали, а репутація ІТ-безпеки постраждала.

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

Case: Класична історія: пʼятниця, вечір, замовник вирішує увімкнути авторотацію пароля для сервісного акаунту svc_backup. CyberArk успішно змінює пароль в Active Directory, нічого не віщує біди. О 3-й ночі падає критична база даних, бо бекап не пройшов, і транзакційні логи забили диск.

Виявилося, що цей акаунт використовувався не тільки для служби бекапу, а й був «захардкоджений» (тобто прописаний текстом) у якомусь старому скрипті 2018 року, про який нинішні адміни навіть не знали. Скрипт постукав зі старим паролем, AD заблокувала акаунт, продакшн зупинився.

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

Моя порада:якщо відчуваєте, що ваш CyberArk перетворився на «валізу без ручки», або бачите, як адміни малюють плакати «Геть PAM!» — час звернутися по консультацію. Часто проблема розвʼязується не купівлею нових модулів, а правильною зміною архітектури й підходу.

Технологія має працювати на вас, а не навпаки.