Глава 2: Логіка побудови диспетчера pgAdmin 4

Розробка диспетчера для pgAdmin 4 була розбита на 10 критичних стадій, кожна з яких розвʼязувала окремий виклик.

Превентивна ізоляція середовища виконання

Одним із перших технічних бар’єрів стала конфліктність бібліотек. Сервери PSM часто мають власні конфігурації OpenSSL, які можуть не збігатися з тим, що очікує pgAdmin. Щоб усунути ризик збоїв, у логіку було впроваджено етап санітизації: скрипт примусово очищує змінні середовища OPENSSL_CONF та OPENSSL_MODULES безпосередньо перед запуском процесу. Це гарантує, що застосунок працюватиме у «чистому» оточенні, використовуючи лише власні перевірені компоненти.

Динамічне очікування інтерфейсу (PixelSearch)

Оскільки швидкість завантаження вебрендерингу в pgAdmin залежить від потужності сервера та поточного навантаження, використання фіксованих тайм-аутів (Sleep) було б фатальною помилкою. Замість цього ми реалізували логіку динамічного сканування. Скрипт входить у цикл очікування, де за допомогою функції PixelSearch перевіряє появу специфічного кольору в точках інтерфейсу. Тільки після того, як система побачила, що вікно готове до взаємодії, розпочинається наступна стадія.

Емуляція дій та навігація

Навігація всередині вікна була реалізована через комбінацію «гарячих клавіш» і контекстних меню. Оскільки ми не маємо прямого доступу до кнопок, диспетчер імітує натискання правої кнопки миші у визначених зонах для виклику меню реєстрації сервера, а потім використовує складні послідовності для переходу між полями введення адреси, порту та облікових даних.

Глава 3: Гібридний підхід у DBeaver — CLI та UI

У випадку з DBeaver ми пішли іншим шляхом, скориставшись перевагами командного рядка (CLI). Проте навіть наявність CLI не робить розробку тривіальною.

Комбінація методів

Підхід до автоматизації DBeaver кардинально відрізнявся від кейсу з pgAdmin. Головним інструментом тут став інтерфейс командного рядка (CLI), проте вибір на його користь був продиктований не лише прагненням до стабільності, а передусім критичними вимогами до безпеки та «гігієни» сесій. 
За стандартного «голого» запуску застосунок DBeaver за замовчуванням намагається зберегти кожен новий профіль підʼєднання у локальній конфігурації користувача. У середовищі PSM, де один сервер обслуговує сотні різних користувачів, це створює серйозний ризик: без додаткових маніпуляцій наступний адміністратор, зайшовши в застосунок, міг би побачити в історії артефакти попередніх підʼєднань — назви баз та адреси серверів.
Спроба розвʼязати цю проблему лише через емуляцію дій (кліки в меню налаштувань для вимкнення збереження) виявилася б ненадійною: інтерфейс Java-застосунків часто поводиться непередбачувано, а будь-яка зміна версії клієнта могла б зламати логіку «прибирання за собою».
Саме тому ми використали ініціалізацію через CLI, формуючи складний рядок запуску на основі даних із Vault:
"name=" & $ConnectionName & "|driver=" & $Driver & "|host=" & $TargetAddress & ... & "|save=false|savePassword=true".
Ключова перевага цього методу полягає у використанні специфічних прапорців, зокрема save=false. Це дозволило нам:

Таким чином, CLI-інтеграція стала тим самим інструментом, який дозволив реалізувати рівень безпеки, недосяжний для звичайної UI-емуляції.

Боротьба з «шумовими» вікнами

DBeaver — це застосунок на базі Java, який під час запуску може генерувати безліч діалогових вікон: повідомлення про оновлення, «поради дня» або запити на дозавантаження драйверів БД. Наш диспетчер був навчений моніторити ці вікна в реальному часі. Якщо з’являється вікно Driver settings, скрипт автоматично ініціює натискання кнопки "Download", чекає на завершення процесу і лише потім переходить до моніторингу самого підʼєднання.

Глава 4: Золоте правило — верифікація та контроль введення

Одним із найважливіших аспектів розробки став принцип контрольованого передавання прав. У стандартних (менш захищених) системах користувач бачить процес автоматизації та може втрутитися в нього, що часто призводить до помилок або спроб обійти систему безпеки.

Блокування введення (Input Block)

Ми реалізували логіку, за якої користувач залишається «глядачем» протягом усього процесу логіну. CyberArk за допомогою механізму Hardware Input Lock блокує можливість користувача натискати клавіші або рухати мишею, поки працює диспетчер. Це гарантує, що послідовність автоматизації не буде перервана випадковим кліком.

Перевірка на успішність підʼєднання

Ключовий етап — стадія верифікації. Після того як було введено пароль і натиснуто "Enter", диспетчер не завершує роботу відразу. Він переходить у режим моніторингу успішності.

Тільки після того, як система впевнилася в успішності підʼєднання, диспетчер надсилає сигнал PSMGenericClient_SendPID. Саме цей сигнал є командою для CyberArk:

Такий підхід охоплює ситуації, коли користувач опиняється перед вікном з помилкою "Access Denied" і намагається вручну вводити паролі або змінювати налаштування з’єднання.

Підсумок

Розробка кастомних конекторів для CyberArk — це мистецтво поєднання глибокого розуміння інфраструктури та навичок програмування. Кейси з pgAdmin 4 та DBeaver демонструють, що навіть за відсутності офіційних плагінів архітектура CyberArk дозволяє створювати рішення, які за рівнем безпеки та зручності не поступаються нативним інтеграціям.

Головні уроки цього досвіду:

Процес створення таких систем вимагає не лише знання CyberArk, а й досвіду розв’язання нестандартних інженерних завдань. Команда BAKOTECH готова надати професійну підтримку у розробці та впровадженні кастомних рішень будь-якої складності, допомагаючи захистити кожен куточок вашої IT-інфраструктури.