Налаштування аудиту привілейованих сесій (session recording)

Аудит привілейованих сесій: де втрачається контроль

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

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

Типова картина: підрядник із супроводу баз заходить на прод-сервер під root, вивантажує дамп клієнтської таблиці «для налагодження» і йде. Через кілька тижнів спливає витік, служба безпеки піднімає журнали — а там лише рядок «session opened for user root».

Хто, коли і що конкретно зробив, відновити неможливо: історія команд або вимкнена, або правиться самим адміністратором, або губиться при розриві з'єднання. Аудит привілейованих сесій закриває саме цей розрив — він фіксує не факт входу, а повний вміст сесії.

Без запису сесій адміністраторів контроль доступу привілейованих користувачів залишається декларативним: права видані, але що під ними роблять — невідомо. Розбір інциденту перетворюється на здогадки, а доказової бази для внутрішнього розслідування чи розмови з підрядником немає.

Нижче розбираємо, як це закривається технічно: де ставити перехоплення, що писати в сховище і як зберегти запис, який не можна підчистити заднім числом.

Що змінюється після впровадження запису сесій

До впровадження запису сесій розбір інциденту на продовому контурі впирається у відсутність первинних даних: у логах видно, що конфігурація змінилася, але не видно, хто саме з адміністраторів це зробив і в межах якої задачі.

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

Після включення запису привілейованих сесій розслідування спирається на відтворювану хроніку: команди, контекст і послідовність дій прив'язані до конкретного облікового запису.

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

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

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

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

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

Зникає цілий клас відмов, пов'язаних із безконтрольною зміною прав доступу, конфігурацій і маршрутів трафіку.

Окремо варто відзначити готовність до перевірок: запис сесій дає вивантаження, яке можна пред'явити аудитору або службі безпеки без ручного збору доказів. Регуляторні та внутрішні вимоги закриваються штатним механізмом, а не разовими зусиллями команди.

Способи запису: шлюз, агент на хості, проксі протоколу

Аудит привілейованих сесій можна побудувати трьома способами, і вибір між ними визначає, що взагалі потрапить у запис. Шлюз доступу ставиться перед цільовим контуром і пропускає трафік через себе — запис ведеться на вході, до того як команда досягне сервера.

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

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

Обмеження кожного способу важливо знати заздалегідь — інакше в записі виявиться сліпа пляма рівно на тій ділянці, яка цікавить службу безпеки.

Окремо варто враховувати, що запис сесій — це ще й навантаження на інфраструктуру: обсяг даних, що зберігаються, зростає разом із кількістю привілейованих підключень.

Тому вибір способу запису сесій пов'язаний із політикою зберігання та розмежуванням доступу до самих записів — інакше аудит перетворюється на джерело нових ризиків.

Як ми впроваджуємо: від інвентаризації до передачі

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

Інвентаризація та схема підключення

Збираємо всі привілейовані облікові записи: локальні адміністратори, сервісні та службові акаунти, доменні групи, доступи до гіпервізорів, СУБД і мережевого обладнання. Окремо фіксуємо, звідки йде вхід — робочі станції інженерів, jump-хости, засоби автоматизації.

На виході — реєстр облікових записів із власниками та критичністю, він же стає основою правил запису.

Далі проєктуємо схему підключення: де ставиться перехоплювач, як трафік іде через проміжний вузол, що відбувається при недоступності вузла запису. Тут же вирішуємо, чи пишемо лише команди або повний відеопотік термінала, і як це співвідноситься з навантаженням на цільові системи.

Налаштування та перевірка

Налаштування йде за групами: для кожної категорії облікових записів — свій профіль запису, свої терміни зберігання та свої правила маскування чутливих даних у виводі команд.

Паралельно налаштовуємо вивантаження подій у зовнішнє сховище, щоб журнал не можна було змінити з тієї ж облікової записи, яку він пише.

Перевірка — окремий етап із набором сценаріїв: вхід за ключем і за паролем, робота через проміжний вузол, обрив зв'язку в середині сесії, спроба відключити агент запису, відновлення після перезапуску цільового вузла.

Кожен сценарій підтверджуємо не «працює», а конкретним артефактом — записом, який можна знайти за ідентифікатором сесії.

Передача в експлуатацію

Передаємо не лише налаштовану систему, а й регламент: хто має доступ до записів, як оформлюється запит на перегляд, що робити при інциденті. Навчаємо чергову зміну та службу безпеки шукати сесію за користувачем, часом і хостом.

Після передачі залишається період супроводу — уточнюємо правила за реальним потоком подій, коли видно, які сесії записуються зайвими, а які варто додати.

Політики доступу та розмежування ролей адміністраторів

Права адміністратора описуються не «доступом до сервера», а матрицею: роль → набір дій → область дії → умова. Поки матриця живе в голові в техліда, будь-який новий інженер отримує доступ «як у всіх», і через півроку ніхто не скаже, хто і навіщо ходив на прод.

Ми переносимо її в конфігурацію систем доступу і приводимо до принципу найменших привілеїв: роль дає рівно той обсяг, який потрібен для задачі, і не більше.

Окрема вісь — права на перегляд записів. Той, хто відтворює сесію, бачить усе, що робив адміністратор, включно з вмістом конфігів і токенами в командному рядку.

Тому доступ до відтворення видається окремою роллю, що не збігається з роллю виконавця: інженер працює, служба безпеки дивиться, керівник напряму бачить лише метадані — хто, коли, на який вузол, скільки тривала сесія.

Журнал дій при цьому незмінний: записи складаються в сховище із забороною правки та видалення, термін зберігання задається політикою.

Що налаштовуємо в правах:

• Ролі адміністраторів: черговий, старший інженер, аудитор, служба безпеки — з різними наборами дій.
• Область дії: прод, стейджинг, окремий контур або конкретна група вузлів.
• Умови входу: обов'язковий другий фактор, робоче вікно, довірений сегмент мережі, підтвердження другого інженера для критичних операцій.
• Розмежування прав: виконавець не може видалити або відредагувати власний запис сесії.
• Права на перегляд записів: окрема роль з обмеженням за контурами та за типом даних.
• Терміни зберігання та правила архівації: скільки живе запис у гарячому сховищі, що йде в архів.
• Процедура перегляду: хто і як часто підтверджує, що видані права ще потрібні.
• Журнал дій за самими правами: видача, підвищення, відкликання — усе фіксується з автором зміни.

Така матриця знімає головний ризик привілейованого доступу — не «зламають ззовні», а «свій зробить зайве і ніхто не помітить».

Коли права розкладені за ролями, а записи сесій захищені від правки, розбір інциденту займає хвилини: піднімаємо журнал, дивимося сесію, бачимо команду та контекст.

Кейс: як ми закрили безконтрольний доступ підрядників

Що було до

Замовник — виробнича компанія з розподіленою інфраструктурою. Підрядники із супроводу баз даних і мережевого обладнання заходили на сервери під спільними обліковими записами: один запис на бригаду, пароль передавався в месенджері й не змінювався місяцями.

Власника у половини таких записів встановити було неможливо — людина звільнилася, а доступ залишився живим. Інвентаризація перед стартом показала 68 облікових записів із привілеями, з них 41 без закріпленого відповідального.

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

Що змінили

Ми розгорнули Teleport як єдину точку входу для привілейованого доступу. Кожен підрядник отримав персональний обліковий запис із короткоживучим сертифікатом — замість статичного пароля.

Доступ видається на конкретний вузол і роль, термін життя сесії обмежений, продовження вимагає обґрунтування в заявці.

Сесії записуються на рівні протоколу: зберігаються команди, вивід термінала, час і контекст підключення. Запис прив'язаний до особистості, а не до спільного логіна, і складається в захищене сховище з незмінним терміном зберігання.

Одночасно ми завели реєстр власників: у кожного запису з'явився відповідальний і дата перегляду, неактивні блокуються автоматично за lifecycle-правилом.

Що стало

Розбір перестав бути розслідуванням: інженер відкриває запис сесії, фільтрує за обліковим записом і інтервалом, бачить точну послідовність команд. Відкликання доступу при розірванні договору — одна операція в реєстрі замість обходу десятка вузлів.

Чим запис сесій відрізняється від журналювання команд

Журналювання команд фіксує текст: хто, коли і який рядок увів у консоль. Цього достатньо, щоб побачити намір, але недостатньо, щоб побачити результат.

Команда psql у лозі виглядає однаково і коли адміністратор зняв дамп однієї таблиці, і коли він відкрив інтерактивну сесію і працював усередині неї годинами — всі подальші дії в лог не потраплять, бо вони відбуваються вже всередині запущеного процесу, а не в оболонці.

Запис сесій працює на іншому рівні: пишеться весь потік вводу-виводу термінала, включно з інтерактивними оболонками, роботою всередині редакторів, відповідями баз даних і виводом утиліт.

На виході — не набір розрізнених рядків, а відтворюваний зліпок роботи: його можна програти з тією ж швидкістю, що й оригінал, або пролистати, бачити паузи, скасовані команди, вставки з буфера. Саме відтворення дій відповідає на питання «що реально сталося», а не «що було набрано».

Різниця підходів проявляється у двох сценаріях. Перший — розслідування інциденту: за журналом команд видно, що адміністратор підключився до сервера, і далі тиша; за записом сесії видно, що він зробив усередині.

Другий — розбір спірної операції: журнал показує одну команду видалення, запис показує, що перед нею було три перевірки і відкат, а видалення — усвідомлений крок, а не помилка.

Повнота картини досягається поєднанням: журнал дає швидкий пошук за подіями і зручний для автоматичних правил та оповіщень, запис сесії — контекст і доказову базу.

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

Що замовник отримує на руки після впровадження

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

• Конфігурації збору. Файли правил: які облікові записи та групи пишуться, глибина запису команд і виводу, термін зберігання, ротація. Усе в системі контролю версій — зміна проходить рев'ю, а не правиться руками на проді.
• Схеми підключення. Як цільові сервери та мережеве обладнання віддають потік на вузол запису, де точки відмови, що відбувається при обриві каналу: буферизація на стороні джерела та дозаливка після відновлення зв'язку.
• Політики доступу до записів. Хто дивиться, хто вивантажує, хто не може видалити. Розподіл ролей: адміністратор вузла запису не має права стирати архіви, доступ до перегляду — за заявкою та з логуванням самого перегляду.
• Регламент розбору. Покроковий порядок для інциденту: як знайти сесію за часом, обліковим записом і хостом, як вивантажити фрагмент, як оформити витяг для служби безпеки або розбору з підрядником.
• Інструкції для підтримки. Що робити при переповненні сховища, недоступності вузла запису, розсинхронізації часу на джерелі — з критеріями, коли ескалувати.
• Документація та передача. Схема стенда, матриця доступів, журнал змін і коротка сесія з вашою командою: розбираємо розбір реального інциденту від початку до вивантаження.

Окремо фіксуємо перевірку: тестова привілейована сесія, яку ми разом знаходимо в архіві та вивантажуємо. Якщо запис не знайшовся або фрагмент нечитабельний — впровадження не закрито. Опишіть вашу задачу, повернемося з оцінкою та планом.

Обговоримо ваше завдання і повернемося з оцінкою

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

Розкажіть, скільки привілейованих облікових записів і через які точки доступу вони працюють: SSH на парк серверів, RDP до Windows-хостів, панелі керування базами, вебконсолі адміністраторів хмари.

Окремо уточніть, чи є вже централізований збір подій і куди пишуться логи — від цього залежить, вбудовуємося ми в наявний контур чи розгортаємо збір з нуля.

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

Від цього напряму залежить архітектура: де стоїть брокер доступу, як влаштовано сховище сесій і як налаштовується розмежування прав на перегляд записів між службою безпеки, аудитом і самими адміністраторами.

Не менш важливо, як ви бачите відкат і сумісність. Якщо запис стане між інженером і сервером, будь-яка помилка в конфігурації заблокує доступ до продакшену — тому ми заздалегідь проєктуємо резервний шлях входу в обхід брокера і перевіряємо його на стенді.

Скажіть, чи є вимоги регулятора або внутрішнього регламенту до формату зберігання і терміну давності, і які системи мають отримувати вивантаження: SIEM, служба підтримки, архів.

Опишіть завдання у вільній формі — парк хостів, протоколи доступу, вимоги до запису та зберігання, обмеження за термінами. Ми повернемося з планом впровадження за етапами, схемою розміщення компонентів та оцінкою термінів під ваш контур.