Дослідження Netwrix 2026 року виявило 4-кратну різницю в частоті зломів між організаціями, де ШІ значно збільшив кількість облікових записів, і тими, де цього не сталося. Статичні облікові дані – це найпростіший шлях проникнення для ШІ: паролі, ключі та токени, які не мають терміну дії та ніколи не перевіряються.
Штучний інтелект не винайшов надмірно привілейовані облікові дані – він просто знайшов найшвидший спосіб ними скористатися. Кожен агент, скрипт та інтеграція, що працюють у середовищі, проходять автентифікацію. І в більшості випадків для цього використовується пароль, ключ API або токен, які видали лише раз і про які назавжди забули. Людина з часом забуває пароль, і її обліковий запис зрештою блокується. Натомість машинний акаунт продовжує використовувати надані йому дані доти, доки за цим ніхто не стежить.
Більше облікових записів – більше компрометацій.
Цього року було опитано 2317 керівників у сфері ІТ та кібербезпеки. Результати дослідження виявилися вкрай показовими. У багатьох організаціях використання ШІ значно збільшило кількість облікових записів. Як наслідок, за останні 12 місяців рівень компрометації у таких компаніях сягнув 43%. Натомість в організаціях, де ШІ суттєво не вплинув на кількість облікових записів, цей показник склав 11%. Така 4-кратна різниця не зумовлена слабшим загальним рівнем захисту в групі з активним використанням ШІ. Як свідчать дані, за більшістю базових показників безпеки такі компанії, навпаки, випереджали інших.
Єдиним напрямком, де ці компанії не мали переваги, виявилося управління Non-Human Identities. Сімдесят шість відсотків організацій не здійснюють повноцінного контролю або моніторингу своїх сервісних облікових записів. Лише 19% компаній підтвердили наявність таких процесів. Саме через цей неконтрольований сегмент найчастіше діє штучний інтелект. Він використовує постійно зростаючий масив машинних облікових записів. Більшість із них проходять автентифікацію за допомогою секретів. Ці дані жодного разу не перевірялися з дня їх створення.
Статичні облікові дані
Статичні облікові дані не втрачають чинності самі по собі, не ротуються автоматично і не мають ліміту на кількість застосувань. Саме це робить їх вкрай небезпечними, щойно вони інтегруються в автоматизовані системи. Дії людини, що використовує викрадений пароль, з часом завжди помічають. Натомість агент ШІ або скрипт із викраденими обліковими даними безперервно функціонуватиме зі швидкістю, яку дозволяє робочий процес, аж поки його не виявлять.
Кроки для захисту облікових даних Non-Human Identities
1. Розміщення у сховищі
Першим кроком є вилучення облікових даних зі скриптів, конфігураційних файлів, електронних таблиць та вихідного коду з подальшим їх перенесенням до системи, спеціально призначеної для їх зберігання. Це звучить просто, але на практиці таким буває вкрай рідко. Сховище повинно працювати як зі стратегічними, так і із застарілими додатками. Крім того, воно має підтримувати різні шаблони доступу. Цей вибір залежить від того, як саме кожен додаток взаємодіє з обліковими даними. Також системі необхідно забезпечувати централізоване підключення. Водночас вона повинна враховувати, що певні команди завжди додаватимуть облікові дані вручну.
На практиці це вимагає багаторівневої архітектури: рівень представлення для користувачів, сервер додатків, який забезпечує виконання бізнес-логіки та контроль дозволів, а також рівень бази даних, де безпосередньо зберігаються секрети. Крім того, необхідна можливість горизонтального масштабування шляхом розгортання кількох серверів додатків для розподілу навантаження між географічно роззосередженими командами. Використання сховища – це також етап, який приносить результати найшвидше, оскільки саме він визначає різницю між обліковими даними, які може знайти будь-хто, і тими, що перебувають під суворим контролем.
2. Шифрування
Щойно облікові дані опиняються у сховищі, вони повинні залишатися зашифрованими, а управління ключами шифрування має здійснюватися так само ретельно, як і самими обліковими даними. Це вимагає значно складнішого підходу, ніж просто активація алгоритму AES і визнання завдання виконаним. Натомість агент ШІ або скрипт із викраденими обліковими даними безперервно функціонуватиме зі швидкістю, яку дозволяє робочий процес, аж поки його не виявлять.
Належним чином побудоване сховище вимагає комплексного підходу до захисту даних. Для самих облікових даних повинно використовуватися автентифіковане шифрування (AES-GCM 256). Хешування користувачів і ключів має спиратися на надійні функції формування ключів із великою кількістю ітерацій. Крім того, для обміну відкритими та закритими ключами необхідна криптографія на еліптичних кривих.Кожен контейнер секретів повинен містити власну випадково згенеровану сіль, а кожен пароль, користувач і роль – мати власну пару ключів. Таким чином доступ шифрується ієрархічно, а не обмежується єдиним спільним ключем.
Для середовищ, що синхронізуються з Active Directory, найвищим рівнем захисту має бути режим наскрізного шифрування (end-to-end), за якого сам сервер ніколи не отримує доступу до відкритих даних. Паралельно з цим має бути доступний режим головного ключа (master-key) для організацій, які потребують централізованого відновлення доступу. Сам головний ключ повинен зберігатися на апаратному рівні, а не в конфігураційному файлі, та захищатися за допомогою апаратного модуля безпеки (Hardware Security Module, HSM). Перенесення паролів із відкритого тексту до зашифрованого сховища, побудованого за таким принципом, є найпоширенішим способом, за допомогою якого організації знижують ризики для облікових даних. Це також найдоступніший крок для команд, які раніше не займалися безпекою Non-Human Identities.
3. Циклічне оновлення та ротація
Регулярна ротація облікових даних знижує ризики, пов’язані зі звільненими працівниками, зменшує загрози компрометації через старий код і скрипти, а також часто виявляє залежності, про існування яких раніше не було відомо. Водночас це найскладніший для виконання етап. За відсутності достатньої інформації про кожен скрипт та інтеграцію, що залежать від певних облікових даних, процес ротації може призвести до збоїв у продакшні, а не до зниження рівня ризику.
Ротація є ефективною лише як безперервний автоматизований процес, тісно інтегрований зі сховищем, у якому містяться облікові дані, а не як ручне завдання, що покладається на людську пам’ять. Це передбачає виконання скидання на основі тригерів, а не календарних нагадувань: облікові дані мають оновлюватися через задану кількість хвилин після їх перегляду, після того, як вони залишалися незмінними протягом визначеної кількості днів, або одразу після закінчення терміну їхньої дії. Крім того, такий процес повинен мати механізми самозахисту. Якщо автоматизоване скидання переривається через помилку під час обробки облікового запису Active Directory, локального користувача Windows чи Linux, або ж сервісного акаунта, система повинна автоматично повернути облікові дані до останнього відомого коректного значення та зафіксувати збій у журналі, а не залишати сервісний акаунт у неробочому напівзміненому стані. Кожне скидання, відкат та блокування відстежується, завдяки чому невдала ротація стає помітною миттєво, а не виявляється через три тижні у вигляді системного збою, причину якого ніхто не може пояснити.
Більшість організацій, які досягають реального прогресу, спочатку успішно налагоджують процеси розміщення облікових даних у сховищі та їх шифрування. До автоматизованої ротації на основі тригерів вони переходять пізніше – лише тоді, коли здобувають достатнє розуміння своїх залежностей, щоб налаштувати цей процес безпечно та без ризику збоїв.
Чим Netwrix Password Secure може допомогти
Сервісні облікові записи та акаунти додатків тісно пов’язані з Active Directory. Вони підпорядковуються тому самому механізму застосування політик, що й облікові записи працівників. Це правило діє незалежно від того, чи контролюється дотримання цих політик на практиці. Рішення Netwrix Password Secure забезпечує безпосередню реалізацію всіх трьох описаних вище етапів захисту.
Продукт забезпечує єдине зашифроване сховище для облікових даних користувачів, адміністраторів та сервісів. Кожен секрет у ньому захищено криптографією, що відповідає стандартам FIPS (автентифіковане шифрування AES-GCM 256, надійне формування ключів на базі PBKDF2 та обмін ключами на еліптичних кривих за стандартом NIST P-521). Завдяки управлінню доступом на основі ролей (RBAC) отримати облікові дані можуть лише авторизовані користувачі та процеси. Повноцінний журнал аудиту фіксує кожне отримання доступу, скидання та відкат, що дозволяє точно встановити, хто і коли взаємодіяв із певними обліковими даними. Крім того, процес ротації забезпечується функцією гнучкого скидання паролів на основі тригерів: облікові дані оновлюються автоматично за розкладом або за визначеною умовою. У разі відхилення змін системою передбачено механізм захисту шляхом автоматичного відкату.
Саме в цьому полягає різниця між двома підходами. Часто пароль сервісного облікового запису нескінченно довго зберігається в електронній таблиці. Його ніколи не ротують через побоювання спровокувати системний збій. Альтернативою є зберігання пароля у спеціалізованій системі. У такому середовищі він зашифрований, а доступ до нього суворо контролюється. Усі дії обов’язково протоколюються. Водночас ротація відбувається за розкладом, яким організація реально керує.
