RansomLeak | Blog

Активності Місяця обізнаності з кібербезпеки: план на 31 день

Thu, 10 Sep 2026 00:00:00 GMT

Більшість жовтневих кампаній — це плакат, лист на всю компанію і одне 45-хвилинне відео, яке люди проклацують із вимкненим звуком. Далі частка кліків падає на три тижні й повертається до норми.

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

Що робить активність Місяця обізнаності робочою?

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

Два правила тримають план у формі. Кожна активність цілиться в одне рішення, а не в одну тему, бо «будьте обережні з поштою» — це не те, що хтось може зробити в понеділок зранку.

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

Як насправді лягає жовтень 2026

1 жовтня 2026 року — четвер, а закривається місяць у суботу 31-го. Це дає 22 робочі дні, тобто більше простору, ніж більшість припускає.

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

Контекст про теми 2026 року і про те, яку з них ставити на плакат, є в матеріалі Місяць обізнаності з кібербезпеки 2026.

Запуск: 1 і 2 жовтня

День 1, четвер. Надішліть стартовий лист від керівника бізнесу, а не від безпеки. Лист від операційного директора про місяць прочитають. Той самий лист зі скриньки безпеки відфільтрують.

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

День 2, п’ятниця. Опублікуйте календар. Люди планують навколо того, що бачать, а видимий розклад не дає кампанії перетворитися на серію засідок.

Тиждень 1, 5-9 жовтня: фішинг і повідомлення

Перший тиждень усі очікують, тож використайте його, щоб змінити те, що ви вимірюєте, а не те, що говорите.

Понеділок. Проведіть базову фішингову симуляцію. Без попередження і поки без листа з поясненням. Це ваше число «до».
Вівторок. Опублікуйте результат одним числом, без імен. Спершу частка повідомлень, потім частка кліків.
Середа. Проведіть Цільовий фішинг як 15-хвилинну вправу на робочому місці. Вона показує персоналізований підхід, який загальне навчання про фішинг оминає.
Четвер. Проведіть Основи повідомлення про інциденти. Більшість людей розуміє, що щось не так, і все одно мовчить, бо ніхто не пояснив, що станеться після натискання кнопки.
П’ятниця. П’ятнадцятихвилинний відкритий дзвінок. Спитайте, які листи цього тижня збивали з пантелику, і розберіть їх наживо.

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

Тиждень 2, 12-16 жовтня: паролі, MFA й облікові записи

Другий тиждень про самі облікові дані. Тримайте його практичним, бо теорію всі вже чули.

Понеділок. Звички з менеджером паролів. Якщо у вас є корпоративний менеджер, це тиждень, щоб довести до нього останні 30% людей.
Вівторок. Ризики автозаповнення в браузері. Автозаповнення — тиха частина крадіжки облікових даних, якої не покриває жоден документ політики.
Середа. Проведіть 20-хвилинну сесію про push-сповіщення MFA, конкретно про те, що робити, коли приходить запит, якого ви не ініціювали.
Четвер. Основи привілейованого доступу для всіх, хто має адмінправа, постійний доступ до продакшену або спільні сервісні акаунти.
П’ятниця. Проведіть перегляд доступів разом із тимлідами. Попросіть кожного назвати акаунти людей, які пішли цього року.

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

Тиждень 3, 19-23 жовтня: офіс, якого ніхто не навчає

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

Понеділок. Основи чистого столу. Далі справді пройдіть один поверх після роботи: нічого не фотографуйте, все порахуйте.
Вівторок. Роздруківки без нагляду. Усе, що лежить у спільному лотку, належить тому, хто дійде першим.
Середа. Безпечна утилізація документів. Смітник — це місце зберігання, а не утилізація, і більшості людей ніколи не пояснювали різницю.
Четвер. Безпека адміністратора принтера для IT та офіс-менеджменту. Мережевий принтер — це комп’ютер із вебконсоллю, і чимало з них досі відповідають на заводські облікові дані.
П’ятниця. Вправа з тейлгейтингу біля головного входу. Один волонтер, один зчитувач карток і короткий розбір, скільки людей притримали двері.

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

Тиждень 4, 26-30 жовтня: дім, відрядження й передача далі

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

Понеділок. Безпека домашнього роутера. Більшість домашніх мереж досі працює на прошивці, з якою приїхала.
Вівторок. Безпечні онлайн-зустрічі. Посилання на зустріч пересилають, а незапрошені учасники зазвичай просто мовчать.
Середа. Надмірна відкритість у соцмережах. Саме звідси береться матеріал для цільового фішингу наступного кварталу.
Четвер. Проведіть настільну вправу за інцидентом. Візьміть щось із каталогу реальних інцидентів і проведіть міжфункціональну групу через першу годину.
П’ятниця. Опублікуйте розклад на листопад-січень. Зробіть це до кінця жовтня, поки людям ще не байдуже.

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

Як закрити місяць 31 жовтня?

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

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

Далі назвіть три речі, які змінилися в результаті. Не три речі, які ви дізналися. Три речі, які інакші 1 листопада: змінений пароль принтера, вимкнений акаунт або шредер, який нарешті з’явився на другому поверсі.

Як провести все це без бюджету?

Кожна вправа за посиланнями вище безкоштовна й не потребує акаунта, що закриває навчальну половину плану. Решта набору є в каталозі обізнаності з безпеки.

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

Щодо матеріалів: National Cybersecurity Alliance дає зареєстрованим Champions безкоштовні плакати й графіку для соцмереж, а CISA публікує власний набір для кампанії. Зареєструйтеся до жовтня, і матимете матеріали кампанії без жодного дизайну.

Як зрозуміти, чи спрацював жовтень?

Дочекайтеся січня. Це незручна відповідь і єдина чесна.

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

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

Поставте жовтень у календар

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

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

Місяць обізнаності з кібербезпеки 2026: теми та дати

Thu, 10 Sep 2026 00:00:00 GMT

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

Що таке Місяць обізнаності з кібербезпеки?

Місяць обізнаності з кібербезпеки — це щорічна кампанія, яка проходить кожного жовтня з 2004 року і яку спільно проводять американське агентство CISA та National Cybersecurity Alliance. Вона дає організаціям фіксоване вікно в календарі, щоб навчити працівників розпізнавати фішинг, працювати з паролями, багатофакторною автентифікацією та оновленнями, спираючись на безкоштовні публічні набори матеріалів.

Місяць не має юридичної сили. Ніхто не аудитує вас за участь, і жодна норма її не вимагає.

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

Коли Місяць обізнаності з кібербезпеки 2026?

З 1 до 31 жовтня 2026 року. Місяць відкривається в четвер і закривається в суботу.

Ця форма важливіша, ніж здається. Ви отримуєте чотири повні робочі тижні плюс четвер і п’ятницю на початку, тому більшість робочих планів будують саме на чотирьох тематичних тижнях, а 1 і 2 жовтня використовують як запуск.

Якщо потрібна версія з розбивкою по днях, ми зібрали її в 31-денному жовтневому плані.

Яка тема Місяця обізнаності з кібербезпеки 2026?

Їх дві, і вони належать двом співзасновникам кампанії.

CISA проводить кампанію під темою «Securing the Next 250» («Захистити наступні 250»), приуроченою до 250-річчя США та спрямованою насамперед на операторів, які тримають електроенергію, воду та інші критичні послуги. National Cybersecurity Alliance проводить «Don’t Make It Easy for Them» («Не полегшуйте їм роботу») і наполягає, що безпека в мережі виростає зі звичок у дрібних щоденних моментах, а не з одного ідеального рішення.

Виберіть ту, що пасує вашій аудиторії. Команди критичної інфраструктури та державного сектору отримають більше від формулювання CISA. Усі інші, особливо звичайний офісний загал, легше сприймуть формулювання Alliance без відчуття пресрелізу.

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

Чого CISA очікує від організацій у 2026 році?

CISA і далі починає з чотирьох дій для людини, і за три роки вони майже не змінилися:

Уникати фішингу та повідомляти про нього
Використовувати надійні паролі
Використовувати багатофакторну автентифікацію (MFA) та менеджер паролів
Оновлювати програмне забезпечення

Для організацій CISA додає журналювання, резервні копії даних, шифрування, повідомлення про інциденти до CISA та план реагування на інциденти, який ви справді перевіряли.

Новіша частина адресована операторам критичної інфраструктури. CISA називає її 3R: Reduce, Replace, Recover. Зменшити відкриті вразливості, замінити пристрої, які вийшли з підтримки, і вміти відновитися достатньо швидко, щоб продовжити роботу.

Якщо у вас OT, медичні пристрої чи системи будівлі, 3R — це та частина матеріалів 2026 року, яку варто нести керівництву, а не на загальні збори.

Чого насправді варто навчати цього жовтня?

Чотири дії CISA добре лягають на практику, і саме практику більшість жовтневих кампаній пропускає. Плакат повідомляє людині, що MFA існує. Він не вчить, що робити, коли о другій ночі приходить шість push-сповіщень від входу, якого ви не починали.

Ось як ми зв’язали б ці чотири дії з чимось, що люди роблять, а не читають:

Фішинг. Проведіть симуляцію, а далі зробіть вимірюваною поведінкою повідомлення, а не клік. Культура повідомлення побудована навколо моменту, коли людина вирішує, чи варто взагалі комусь казати.
MFA. Шквал push-запитів — це атака, яка обходить впровадження MFA, і вона не схожа на атаку. Атака шквалом push-запитів ставить людину під цей потік сповіщень.
Оновлення. Більшість відкладає перезавантаження, бо не знає, для чого було оновлення. Оновлення ОС та основи патчів пов’язує відкладений ребут із тим, що він залишає відкритим.
Відновлення. З 3R працівники впливають на те, чи справді їхня робота має резервну копію. Найкращі практики резервного копіювання показують, що копія має пережити програму-вимагача, а не лише мертвий ноутбук.

Усі чотири безкоштовні й не потребують реєстрації. Решта безкоштовного набору живе в каталозі обізнаності з безпеки.

Чого офіційні теми не охоплюють?

ШІ. Жодна з тем 2026 року його не називає, і обидві мають рацію, бо CISA та Alliance пишуть для цілої країни, а базові речі досі зупиняють більшість атак.

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

Якщо ваша аудиторія — офісні працівники, додайте п’ятий трек про синтетичні медіа та соціальну інженерію з ШІ. Ми розібрали поточні сценарії атак у матеріалі про діпфейки в соціальній інженерії, а практичні версії лежать у каталозі безпеки ШІ.

Де взяти безкоштовні матеріали для Місяця обізнаності?

Три місця, і жодне нічого не коштує.

CISA публікує на своєму сайті набір матеріалів для Місяця обізнаності з кібербезпеки з повідомленнями та графікою. National Cybersecurity Alliance дає зареєстрованим Champions набір, куди входять пам’ятка про шахрайські схеми, вісім плакатів для друку та 32 графіки для соцмереж у статичному й відеоформаті, а також доступ до спікерів і щорічного дослідження поведінки людей у кібербезпеці.

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

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

Як зробити, щоб жовтень не був єдиним місяцем, що має значення?

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

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

Ставтеся до кампанії як до запуску дванадцятимісячної програми, у якої просто гучний перший місяць. Альтернатива — щорічна подія, яку працівники вчаться перечікувати.

Почніть планувати жовтень зараз

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

31-денний жовтневий план містить версію по тижнях із конкретними вправами на конкретні дні.

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

Джерела

10 безкоштовних вправ OWASP MCP Top 10

Wed, 02 Sep 2026 00:00:00 GMT

Кожна категорія OWASP MCP Top 10 тепер має присвячену вправу на RansomLeak. Десять сценаріїв, що охоплюють десять способів, якими ламається зʼєднання між AI-агентом та його інструментами. Усі безкоштовні, акаунт не потрібен.

OWASP MCP Top 10 каталогізує ризики безпеки Model Context Protocol, стандарту, що дозволяє агентам викликати зовнішні інструменти та читати зовнішні дані. Цей курс перетворює кожну категорію на сценарій, який ви проходите, а не на визначення, яке читаєте.

Що таке навчальний курс OWASP MCP Top 10?

Навчальний курс OWASP MCP Top 10 — це набір із десяти інтерактивних вправ, по одній на кожну категорію ризику в OWASP MCP Top 10. Model Context Protocol є стандартом, що підключає AI-агентів до інструментів, джерел даних та сервісів, а список OWASP ранжує те, що ламається на цьому зʼєднанні: витік токенів, надто широкі дозволи, отруєні описи інструментів, підмінені залежності, інʼєкція команд, підміна наміру, відсутня автентифікація, порожній журнал аудиту, незареєстровані сервери та контекст, що перетікає між клієнтами. Кожна вправа поміщає вас усередину робочої системи, де один із цих збоїв уже триває, а потім просить його знайти, локалізувати та перевірити, що виправлення втрималося. Вправи працюють у браузері як інтерактивні симуляції, тривають пʼять-десять хвилин кожна та не потребують акаунту чи встановлення. Курс живе в каталозі безпеки AI та LLM поряд із курсами про LLM та агентний AI.

Курс охоплює всі десять категорій ризику OWASP MCP:

Витік токенів MCP: Довгоживучий токен із конфігураційного файлу потрапляє в транскрипт чату, а потім відтворюється проти справжнього API клієнтів
Агент Scope Creep: Залишкові OAuth-дозволи дають агенту сортування вставити приватний ключ підпису в публічну гілку
Описи отруєних інструментів: Опис схваленого інструмента переписано так, щоб агент слав приховану копію кожного повідомлення на зовнішню адресу
Пакет Typosquatted MCP: Postinstall-хук залежності-двійника відправляє файли з обліковими даними ще до того, як хтось прочитає код
Введення команд MCP: Крапка з комою в аргументі інструмента відкриває root-реверс-шелл, поки інструмент повертає порожній результат
Намір захопленого агента: Інструкція, закладена через публічну форму підтримки, змушує агента-підсумовувача надіслати платіжні дані назовні
Неавтентифікований сервер MCP: Схвалений сервер, привʼязаний до 0.0.0.0, відповідає на tools/list фінансовими даними без жодних облікових даних
Відсутній журнал аудиту MCP: Скарга потрапляє в дводенну прогалину логування, і ніщо налаштоване потім її не відновить
Тіньові сервери MCP: Скан виявлення знаходить три працюючі сервери, яких не було в жодній конфігурації клієнта
Витік контексту між клієнтами: Рахунок та дані картки одного клієнта зʼявляються в сесії іншого без жодного зловживання інструментом

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

Чому командам потрібне навчання безпеки MCP прямо зараз?

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

Виміряна картина не заспокоює. Equixly оцінила популярні реалізації MCP та повідомила в березні 2025 року, що 43% мали вразливості інʼєкції команд, 22% дозволяли обхід каталогів або довільне читання файлів, а 30% допускали необмежене завантаження URL. Із повідомлених вендорів 45% відхилили знахідки як теоретичні, а 25% не відповіли взагалі.

Invariant Labs опублікували перше широко цитоване дослідження отруєння інструментів у квітні 2025 року, показавши, що сервер може отримати схвалення на чесному формулюванні та змінити це формулювання потім. Жоден із цих збоїв не дає сповіщення у стандартному стеку моніторингу.

Практична проблема в тому, що ризики MCP виглядають як звичайна робота, поки тривають.

Хтось схвалює інструмент. Хтось просить асистента розібратися з поламаним зʼєднанням і вставляє конфіг. Хтось піднімає сервер для денного тесту і ніколи його не вимикає.

Чим ці вправи відрізняються від курсів LLM та агентного AI?

Три курси відповідають трьом шарам, і ламаються вони в різних місцях.

Курс LLM працює на шарі моделі. Ви маніпулюєте входами та спостерігаєте шкідливі виводи, а поверхнею атаки є те, що модель читає й пише.

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

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

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

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

З яких вправ почати вашій команді?

Складайте послідовність за тим, хто реально може спричинити або спіймати кожен збій.

Усім, хто користується підключеними AI-інструментами, варто пройти Описи отруєних інструментів та Намір захопленого агента. Обидві атаки приходять через звичайну роботу, і обидві запускаються схваленням чогось або проханням до асистента щось підсумувати. Жодна не вимагає, щоб учасник щось налаштовував.

Інженерам та платформним командам варто додати Витік токенів MCP, Пакет Typosquatted MCP, Введення команд MCP та Неавтентифікований сервер MCP. Це ті чотири, що вирішуються під час інтеграції, коли токен записують у конфіг, залежність встановлюють, аргумент вставляють у рядок shell-команди або сервер привʼязують ширше, ніж планували.

Командам безпеки та ІТ варто пройти Тіньові сервери MCP, Відсутній журнал аудиту MCP та Витік контексту між клієнтами. Усі три є проблемами виявлення. Політикою їм не запобігти, і кожна винагороджує знання того, як виглядає здорова траса, ще до того, як доведеться читати зламану.

Тим, хто переглядає доступи, варто пройти Агент Scope Creep. Вправа переставляє перегляд доступів на питання про те, куди дозвіл дістає сьогодні, а не для чого його спочатку просили, і саме це питання більшість квартальних процесів пропускає.

Як цей курс вписується в ширшу програму безпеки AI?

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

Почніть із курсу OWASP LLM Top 10, якщо ваша організація ще не проводила навчання з безпеки AI. Prompt injection та отруєння даних легше розпізнати в чат-боті, ніж у маніфесті інструмента, а обидва патерни зʼявляються в списку MCP під іншими назвами.

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

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

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

Усі десять вправ OWASP MCP Top 10 доступні в нашому каталозі навчання з безпеки AI. Почніть з Описів отруєних інструментів, прочитайте пояснення OWASP MCP Top 10 або перегляньте повний каталог навчання, щоб побудувати шлях для вашої команди.

Джерела

Hoxhunt проти KnowBe4: адаптивний фішинг чи глибина контенту?

Wed, 02 Sep 2026 00:00:00 GMT

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

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

Швидке порівняння (TL;DR)

Вимір	Hoxhunt	KnowBe4
Заснування / походження	2016, Фінляндія, фішинг перш за все	2010, США, платформа навчання перш за все
Основний рушій	AI підлаштовує складність для кожного працівника в реальному часі	Велика бібліотека шаблонів із плануванням кампаній
Бібліотека контенту	Зосереджена на фішингу, легша поза ним	ModStore, тисячі модулів, 35+ мов
Дизайн залучення	Лідерборди, серії, позитивне підкріплення	Призначені модулі, окремі сюжетні серії
Фокус звітності	Рівень повідомлень і показники стійкості	Проходження, ризик-скоринг, докази для комплаєнсу
Експорт SCORM	Немає	Підтримується, пріоритет власній консолі
Розміщення даних	ЄС (Фінляндія) і США	США з додатком про обробку в ЄС
Ціна	За запитом, преміальний рівень	Приблизно $1,50–3,25 за користувача на місяць за публічними відгуками
Кому підходить	Програмам навколо безперервних фішинг-симуляцій	Програмам, яким потрібні ширина, мови й докази комплаєнсу

Де Hoxhunt справді виграє

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

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

Метрика теж інша. Hoxhunt оптимізує рівень повідомлень, а не рівень кліків. Коли працівники активно повідомляють про підозрілу пошту, вони стають шаром виявлення, який живить чергу вашого SOC. Це корисніший результат, ніж відсоток кліків, що знижується.

Покупці з ЄС отримують додаткову перевагу: база у Фінляндії з доступним хостингом у ЄС спрощує розмови про GDPR і NIS2, які американські вендори закривають додатками до договору.

Де KnowBe4 справді виграє

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

Якщо ваш обовʼязок — документувати щорічне навчання для SOC 2, ISO 27001, HIPAA, PCI DSS чи NIS2, KnowBe4 надає ці докази безпосередньо. Hoxhunt для цього не будувався, і команди часто докуповують другу платформу під комплаєнс, що повністю знищує економію.

Ширина фішингових інструментів теж на боці KnowBe4. PhishER обробляє тріаж реальної повідомленої пошти в обсязі, PhishFlip перетворює повідомлений фішинг на симуляцію, Smart Delivery обходить фільтри. Рушій Hoxhunt розумніший для окремого працівника; рушій KnowBe4 ширший для операцій.

SCORM — третій розрив. KnowBe4 експортує SCORM-пакети. Hoxhunt не експортує навчання як SCORM узагалі, тож організації з основною LMS постійно тримають дві системи. Це реальна операційна вартість, і вона зʼявляється після контракту, а не під час демо.

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

Запитайте, для чого ваша програма.

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

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

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

Чесно про вартість

KnowBe4 публікує рівні, і публічні відгуки ставлять його приблизно у $1,50–3,25 за користувача на місяць на річних умовах. Hoxhunt працює лише за запитом і перебуває у преміальному сегменті вендорів human risk.

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

Що обрати?

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

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

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

Де тут RansomLeak

Ми не заміна адаптивному рушію Hoxhunt, і про це варто сказати прямо.

RansomLeak — це інтерактивна практика. Працівники входять у сценарії, ухвалюють рішення й бачать їхню ціну: фішинг, програми-вимагачі, соціальна інженерія, приватність і AI-загрози, включно з ризиками OWASP LLM Top 10, промпт-інʼєкціями та дипфейковими голосовими атаками. Ми запускаємо email-симуляції через Microsoft 365 і Google Workspace та SMS-симуляції для смішингу, а помилка одразу веде до відповідної вправи. SCORM 1.2, SCORM 2004 і LTI 1.3 повноцінні, тож контент працює у вашій наявній LMS, а не в другій консолі.

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

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

Ширший огляд — у хабі порівняння платформ, в альтернативах Hoxhunt та альтернативах KnowBe4, а також в огляді найкращих платформ для 2026 року. Прямі порівняння — RansomLeak проти Hoxhunt і RansomLeak проти KnowBe4.

KnowBe4 проти Proofpoint: яка платформа виграє?

Wed, 02 Sep 2026 00:00:00 GMT

KnowBe4 і Proofpoint Security Awareness — два імені, які потрапляють майже до кожного корпоративного шортлиста. Вибір між ними зазвичай зводиться до питання, що взагалі не стосується навчання: чи використовуєте ви вже Proofpoint для захисту пошти? Якщо так, продукт Proofpoint успадковує threat intelligence, який KnowBe4 відтворити не може. Якщо ні, ширина й інструментарій KnowBe4 зазвичай перемагають.

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

Швидке порівняння (TL;DR)

Вимір	KnowBe4	Proofpoint Security Awareness
Заснування / походження	2010, окремий вендор навчання	Напрям навчання всередині платформи email-безпеки
Бібліотека контенту	ModStore, тисячі модулів, 35+ мов	Відеомодулі й тести, вужчий каталог
Фішинг-симуляції	PhishER, PhishFlip, Smart Delivery, велика бібліотека шаблонів	Кампанії, націлені за даними TAP
Threat intelligence	Незалежний від вендора, власного шлюзу немає	Реальні атаки на вашу організацію живлять симуляції
Експорт SCORM	Підтримується, але основний шлях — власна консоль	Обмежений, пріоритет власній платформі
Модель розгортання	Окремо, працює з будь-яким поштовим стеком	Найсильніша у зв’язці з Proofpoint email security
Ціна	Приблизно $1,50–3,25 за користувача на місяць за публічними відгуками	За запитом, часто в складі пакета
Кому підходить	Командам, яким потрібна найглибша бібліотека та інструменти симуляцій	Командам, які вже стандартизувалися на Proofpoint

Де Proofpoint справді виграє

Диференціатор — threat intelligence, і він реальний. Proofpoint керує поштовим шлюзом, тому його продукт знає, які атаки насправді дійшли до ваших працівників. Дані Targeted Attack Protection формують симуляції навколо кампаній, спрямованих на вашу організацію цього кварталу, а не навколо загальної бібліотеки шаблонів.

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

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

Де KnowBe4 справді виграє

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

Інструменти симуляцій також зріліші. PhishER для тріажу на рівні скриньки, PhishFlip для перетворення повідомленого фішингу на симуляцію та Smart Delivery для обходу фільтрів — це операційні інструменти, які будувалися десятиліття.

Третя перевага — незалежність. KnowBe4 байдуже, який у вас поштовий шлюз. Організації на Microsoft Defender, Mimecast чи Google Workspace отримують повний продукт. Цінність Proofpoint помітно падає, якщо ви не на його стеку: перевага threat intelligence зникає, і залишається вужча бібліотека за корпоративною ціною.

Питання прив’язки до вендора

Купівля навчання у власного вендора email-безпеки — це рішення про зв’язування продуктів, і його варто обговорити явно, а не за замовчуванням.

Зв’язка окупається, доки ви залишаєтеся на Proofpoint. Вона коштує вам на виході. Зміна постачальника email-безпеки означає або втрату переваги threat intelligence, що виправдовувала покупку навчання, або перемовини щодо двох продуктів одночасно зі слабшої позиції.

KnowBe4 несе протилежний компроміс: окремий вендор і окрема консоль, але рішення про навчання лишається незалежним від рішення про пошту.

Стиль контенту та проходження

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

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

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

SCORM, LTI та ваша основна LMS

Організаціям із наявною LMS треба знати, чи подорожує контент.

KnowBe4 підтримує експорт SCORM, але продукт побудований навколо власної консолі, і саме туди йде інженерна увага. Підтримка SCORM у Proofpoint ще обмеженіша, і платформа очікує бути поверхнею доставки.

Жоден вендор не документує запуск через LTI 1.3 з автоматичною передачею оцінок. Якщо ваша вимога — щоб контент був повноцінним у Cornerstone, Workday Learning, SuccessFactors, Moodle чи Canvas, обидві платформи чинитимуть опір. Порушіть це питання на першому дзвінку, а не під час впровадження. Наш посібник з інтеграції LMS описує, як виглядає повна портабельність.

Ціни

KnowBe4 публікує рівні (Silver, Gold, Platinum, Diamond) з калькулятором. Публічні відгуки ставлять ефективний діапазон приблизно у $1,50–3,25 за користувача на місяць на річних контрактах.

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

Ширший контекст категорії — у нашому посібнику з цін на security awareness training.

Що обрати?

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

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

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

Де тут RansomLeak

Ми — третій варіант, а не спосіб розсудити ці дві платформи, і підходимо не всім.

RansomLeak побудований навколо інтерактивних сценаріїв, де працівники ухвалюють рішення й бачать наслідки, а не дивляться відео з питаннями після нього. Каталог AI-загроз покриває ризики OWASP LLM Top 10, промпт-інʼєкції та дипфейкові голосові атаки глибше, ніж обидві платформи. SCORM 1.2, SCORM 2004 і запуск через LTI 1.3 є повноцінними, тому контент працює всередині вашої наявної LMS.

Де ми не конкуруємо: бібліотека шаблонів і тріаж PhishER у KnowBe4 зріліші за наші, а власного поштового шлюзу в нас немає, тому таргетингу за threat intelligence, як у Proofpoint, ми не пропонуємо.

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

Ширший огляд — у хабі порівняння платформ, в альтернативах KnowBe4 та в огляді найкращих платформ security awareness training для 2026 року. Прямі порівняння — RansomLeak проти KnowBe4 і RansomLeak проти Proofpoint.

OWASP MCP Top 10: ризики Model Context Protocol

Wed, 02 Sep 2026 00:00:00 GMT

Агент підтримки в SaaS-компанії був підключений до того самого CRM-інструмента чотири місяці. Він читав тікети та готував відповіді. Ніхто не торкався його конфігурації з дня, коли інструмент схвалили.

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

Агент підкорився. Він не мав як відділити документацію від інструкції, бо для моделі, що читає маніфест інструмента, різниці немає. Це одна категорія з OWASP MCP Top 10, і це один із десяти способів, якими розпадається зʼєднання між агентом та його інструментами.

Що таке OWASP MCP Top 10?

OWASP MCP Top 10 — це ранжований перелік ризиків безпеки, специфічних для Model Context Protocol, стандарту, який підключає AI-агентів до зовнішніх інструментів, даних та сервісів. Опублікований Open Worldwide Application Security Project, він охоплює десять категорій: неправильне поводження з токенами та розкриття секретів, ескалація привілеїв через розповзання дозволів, отруєння інструментів, атаки на ланцюг постачання та підміна залежностей, інʼєкція та виконання команд, підміна наміру, недостатня автентифікація та авторизація, брак аудиту й телеметрії, тіньові MCP-сервери, інʼєкція контексту та надмірний обмін ним. Перелік лежить під шаром моделі, який описує OWASP LLM Top 10, і поряд із шаром автономії, який описує OWASP Agentic AI Top 10. Його предмет — сантехніка: сервери, токени та маніфести інструментів, що перетворюють рішення моделі на дію в реальній системі. OWASP позначає проєкт як бета-версію v0.1 у пілотному тестуванні, тому формулювання категорій ще можуть змінитися.

Чим безпека MCP відрізняється від безпеки LLM та агентного AI?

Три списки OWASP описують три різні шари, і контроль, що працює на одному шарі, нічого не дає на іншому.

LLM Top 10 — про модель. Prompt injection, отруєння даних та небезпечна обробка виводу є збоями того, що входить у модель і що з неї виходить. Радіус ураження зупиняється на відповіді.

Agentic AI Top 10 — про автономію. Захоплення цілей, отруєння памʼяті та каскадні збої описують, що стається, коли модель зʼєднує рішення в ланцюг через багато кроків без людського схвалення на кожному з них.

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

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

Чому опис інструмента поводиться як інструкція?

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

Змініть опис і ви зміните поведінку, без змін в обробнику, схемі чи наданих дозволах. Код-ревʼю цього не спіймає, бо переглянутий репозиторій не є місцем, де живе цей текст. Invariant Labs опублікували перший широко цитований розбір цього патерну у квітні 2025 року, назвавши і прямий випадок, і rug pull, коли сервер отримує схвалення на чесному формулюванні, а потім підміняє його.

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

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

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

Що ламається ще до того, як агент запуститься?

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

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

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

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

Ланцюг постачання іде четвертим. MCP-сервер зазвичай є звичайним пакетом, а встановлення пакета запускає його інсталяційні скрипти від імені поточного користувача ще до того, як хтось прочитає код. Вправа про typosquatted MCP-пакет простежує залежність, опубліковану на один символ далі від довіреної назви, чий postinstall-хук відправляє файли з обліковими даними на хост атакувальника, поки термінал виглядає звично.

Чому MCP-сервер захищати важче, ніж API?

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

Equixly провела оцінювання безпеки популярних реалізацій MCP та опублікувала результати в березні 2025 року. Вона знайшла вразливості інʼєкції команд у 43% протестованих серверів, обхід каталогів або довільне читання файлів у 22%, а необмежене завантаження URL у 30%. Коли про знахідки повідомили, 30% вендорів випустили виправлення, 45% назвали ризик теоретичним, а 25% не відповіли взагалі.

Інʼєкція команд — категорія пʼять. Кожен аргумент, який отримує MCP-інструмент, є недовіреним входом, і вставляння цього входу в рядок shell-команди означає, що крапка з комою перестає бути даними.

У вправі про інʼєкцію команд MCP ви знаходите інʼєктований аргумент у трасі агента, поки інструмент повертає звичайний порожній результат, а root-реверс-шелл виносить облікові дані бази. Далі ви замінюєте виклик через shell на параметризований.

Недостатня автентифікація — категорія сім, і саме її найчастіше вважають закритою. Схвалення процесом управління не є автентифікацією. У вправі про неавтентифікований MCP-сервер зареєстрований і схвалений сервер привʼязали до 0.0.0.0 заради пілота, і неавтентифікований tools/list тепер повертає інструменти фінансового сховища, які віддають імена рахунків та суми контрактів.

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

Чого не можна виправити після початку інциденту?

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

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

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

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

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

Як навчати організацію ризикам MCP?

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

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

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

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

Усі десять категорій охоплені нашим навчальним курсом OWASP MCP Top 10, який працює в браузері без реєстрації. Якщо ви будуєте програму безпеки AI за всіма трьома списками OWASP, напишіть нам про послідовність шарів моделі, агента та протоколу для ваших команд.

Джерела

AWS IAM: практики проти ескалації привілеїв

Fri, 28 Aug 2026 00:00:00 GMT

Обліковий запис build-агента повинен вміти завантажувати артефакти й читати власну конфігурацію. Більше нічого. На папері це короткий список, який легко перевірити.

На практиці політика, прикріплена до нього, часто виглядає як "Action": "*", "Resource": "*", тому що wildcard був “достатньо близьким” до того, що потрібно пайплайну, і ніхто не повернувся, щоб звузити його. Цей обліковий запис тепер є адміністратором під нудною назвою, і той, хто його видав, може про це навіть не знати.

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

Що таке безпека AWS IAM?

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

CIS AWS Foundations Benchmark виділяє керування ідентичностями та доступом в окремий домен контролю саме тому. Більшість хмарних інцидентів це не новий експлойт проти самого AWS. Це дозвіл, виданий коректно, яким скористався той, кому він ніколи не призначався.

Які основні ризики ескалації привілеїв через IAM?

Згруповано за тим, де саме ламається довіра, тому кожен пункт має свого власника й свій фікс.

Обсяг політики: wildcard і передача ролей

Політика, що надає всі дії на всіх ресурсах, за визначенням непіддається аудиту. Гірше те, що iam:PassRole дозволяє викликачу передати привілейовану роль сервісу, який виконає її замість нього, тож викликач ескалує права, ніколи не приймаючи цю роль сам. Вправа Over-Permissive IAM дає прочитати політику облікового запису build-агента, передати роль адміністратора аварійного доступу у функцію, яку ви створюєте, а потім переписати політику до названих дій на названих ресурсах із межею дозволів під нею.

Життєвий цикл ключів: довговічні й витекли облікові дані

Статичний ключ доступу не має терміну дії, тож розрив між витоком і зловживанням обмежений лише тим, коли хтось це помітить. Ключі витікають у логи збірок, клієнтський код і старі коміти, і продовжують автентифікувати місяцями пізніше, бо зі статичним ключем із часом нічого не змінюється. Вправа Long-Lived Access Keys дає повторно використати ключ, узятий із весняного лога збірки, проти осіннього продакшн-акаунта, а потім замінити його федерацією, що видає короткоживучі облікові дані на кожен запуск замість свіжішого статичного ключа.

Ідентичність інстансу: крадіжка через сервіс метаданих

Будь-який процес на хмарному інстансі може запитати в сервісу метаданих облікові дані цього інстансу, і за замовчуванням сервіс не перевіряє, хто саме запитує. Вада, що дозволяє серверу робити запит за посиланням користувача, яка інакше була б незначною, перетворюється на спосіб украсти весь набір облікових даних ролі. Вправа Instance Metadata Abuse веде функцію завантаження за URL прямо до такої крадіжки, а потім закриває її вимогою токена сесії та лімітом переходів в одиницю.

Ідентичність функції: надмірні привілеї serverless

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

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

Межі акаунтів: довіра між акаунтами

Акаунт це найсильніша межа радіуса ураження, яку дає хмара, але вона тримається лише тоді, коли довіра, спрямована в нього, звужена. Обліковий запис пісочниці без жодних цінних даних стає небезпечним у ту мить, коли може прийняти продакшн-роль, бо за пісочницями стежать значно рідше, ніж за продакшном. Вправа Multi-Account Boundaries дає пройти саме цим шляхом, а потім поставити над акаунтом сервісну контрольну політику, щоб межа тримала навіть проти продакшн-адміністратора, який намагається її розширити назад.

Які практики безпеки AWS IAM застосувати першими?

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

Пишіть політики через перелічені дії й ресурси, ніколи не wildcard з обох боків. Список, який можна прочитати повністю, це список, який можна перевірити. Wildcard це обіцянка, яку неможливо перевірити.
Додайте межу дозволів поверх кожної переліченої політики. Вона ловить wildcard, до якого хтось сягне під тиском дедлайну, а саме тоді початкова помилка зазвичай і повторюється.
Замініть статичні ключі федерованими короткоживучими обліковими даними, де це можливо для навантаження. Ключ, що сам спливає, неможливо відтворити через місяці після витоку.
Вимагайте IMDSv2 і встановіть ліміт переходів в одиницю. Обмін токеном сесії зупиняє один підроблений запит від досягнення сервісу метаданих узагалі.
Звужуйте кожну роль виконання serverless до конкретного ресурсу, з яким працює функція. Доступ до всього сховища чи бази даних майже ніколи не потрібен самій функції.
Виносьте секрети зі змінних середовища в кероване сховище секретів, яке функція читає під час виконання. Це фіксує кожен доступ у журналі аудиту й робить ротацію можливою без повторного деплою.
Називайте конкретну роль у кожній політиці довіри між акаунтами й вимагайте зовнішній ідентифікатор. Політика довіри, що називає весь акаунт, віддає продакшн будь-чому, що цей акаунт коли-небудь запустить.
Поставте сервісну контрольну політику над акаунтом для всього, що скомпрометований адміністратор ніколи не повинен мати змогу скасувати. Фікси всередині акаунта можна скасувати зсередини акаунта. SCP, що діє над акаунтом, скасувати не можна.

Як навчати інженерів безпеки AWS IAM?

Чекліст вчить дотримання правил. Він не вчить того рішення о шостій вечора, коли деплой падає через помилку дозволів, а найшвидший фікс це wildcard. Той, хто ніколи не бачив, що саме дає цей wildcard, все одно за нього візьметься.

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

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

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

Часті запитання

Чи буває прийнятною політика IAM із wildcard?

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

Чому ротація витеклого ключа доступу має значення, якщо його вже відкликано?

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

Чи повністю закриває вимога IMDSv2 зловживання сервісом метаданих?

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

Чим роль виконання serverless відрізняється від звичайної ролі IAM?

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

Чому довіра між акаунтами потребує сервісної контрольної політики поверх звуженої політики довіри?

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

Почніть з однієї політики

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

Наші вправи Cloud Infrastructure Security безкоштовні для тестування, а щоб розгорнути їх на всю інженерну команду, звʼяжіться з нами.

Помилки конфігурації AWS, які варто виправити першими

Fri, 28 Aug 2026 00:00:00 GMT

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

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

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

Що таке помилка конфігурації хмарної безпеки?

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

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

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

Які найпоширеніші помилки конфігурації AWS?

Згруповано за рівнем, де живе настройка, бо в кожного свій власник і свій фікс.

Сховище: бакети, що відповідають незнайомцям

Назви бакетів слідують конвенціям компанії й зʼявляються в коді сторінок, мобільних застосунках і документації підтримки, тож зловмиснику рідко доводиться вгадувати наосліп. Перелік вмісту бакета й читання обʼєктів це окремі дозволи, які видають разом випадково, і саме так анонімний запит завершується поверненням клієнтського експорту. Вправа Public Storage Buckets дає знайти й прочитати саме таку експозицію, а потім закрити її block-public-access на рівні акаунта як страхувальним контролем і політикою бакета, яка називає, хто саме може читати.

Мережа: security groups, відкриті в інтернет

Security group це фаєрвол, і одне поле в одному правилі вирішує, чи база даних доступна лише з рівня застосунку, чи з будь-якої адреси в інтернеті. Відкритий порт бази даних це запрошення, а не злам сам по собі, але команди, які вважають порт недосяжним, рідко ставлять за ним надійний логін. Вправа Cloud Network Exposure дає підключитися прямо до продакшн-бази даних без застосунку на шляху, а потім звузити правило до підмережі застосунку й обґрунтувати, чому базам даних узагалі не місце в публічних підмережах.

DNS: субдомени, що вказують у нікуди

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

Видимість: журнали аудиту, що не покривають акаунт

Журнал аудиту, що покриває один регіон і жодного іншого, має сліпу зону, яку зловмисник з будь-якою точкою опори знайде і використає негайно, а вимкнення журналу посеред інциденту ховає все, що станеться після. Неможливо відтворити те, що ніколи не було записано. Вправа Cloud Audit Logging Gaps дає розслідувати інцидент, де сталося саме це, а потім виправити це журналюванням на весь акаунт, перевіркою цілісності журналу, тривогою на будь-яку зміну конфігурації самого трейла й доставкою логів в акаунт, до якого джерело не має доступу.

Які помилки конфігурації AWS виправити першими?

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

Увімкніть block-public-access на рівні акаунта до того, як чіпати будь-яку окрему політику бакета. Це страхувальний контроль, який тримає навіть тоді, коли хтось наступного кварталу знову напише необережну політику.
Видавайте перелік вмісту бакета й читання обʼєктів як окремі, свідомі дозволи. Ставлення до них як до одного гранту і є тим, як анонімний запит закінчується читанням даних, які ніхто не планував публікувати.
Звужуйте кожне правило security group до підмережі чи сервісу, якому справді потрібен порт, ніколи не 0.0.0.0/0. Правило, що відповідає всьому інтернету, рідко є свідомим рішенням.
Тримайте бази даних поза публічними підмережами взагалі. Правило фаєрвола відділяє одну настройку від помилки. Приватна підмережа прибирає експозицію як категорію.
Видаляйте DNS-запис того самого дня, коли ресурс виводиться з експлуатації, а не пізнішим тікетом. Висячий запис це назва, яку можна заявити собі, доки вона існує.
Скануйте на записи, що досі вказують на ресурси, якими ви більше не володієте. Виведення з експлуатації зазвичай відбувається швидше, ніж хтось це документує, тож сканування знаходить те, що самою лише політикою пропустять.
Увімкніть журнал аудиту хмари на весь акаунт, у кожному регіоні, до того, як він знадобиться. Трейл, що покриває лише той регіон, у якому ви розгорнулися першим, це сліпа зона з вашим імʼям на ній.
Увімкніть перевірку цілісності файлів журналу й тривогу на будь-яку зміну конфігурації самого трейла. Вимкнення журналювання це та єдина дія, успіх якої ховає всі дії після неї.

Як навчати інженерів помилок конфігурації хмари?

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

Альтернатива це пройти експозицію самому до того, як вона стане живою в продакшні. Інженер, який перелічив вміст бакета без облікових даних і побачив, як повертається клієнтський експорт, після цього перевіряє block-public-access на кожному акаунті без нагадувань.

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

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

Часті запитання

Як зловмисники знаходять публічні S3-бакети, якщо не знають назви?

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

Чи достатньо виправити одну політику бакета, коли знайдено експозицію?

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

Чому захоплення субдомену працює, навіть якщо наш домен ніколи не був скомпрометований?

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

Чим security group відрізняється від network ACL?

Security group зі станом і привʼязана до ресурсу, тож правило, яке дозволяє вхідний трафік, автоматично дозволяє відповідну вихідну відповідь. Network ACL без стану й привʼязана до підмережі, оцінюється до того, як трафік узагалі дістанеться security group. Більшість експозицій зводяться до правила security group, бо саме його команди редагують найчастіше.

Чи відновлює увімкнення журналу аудиту після інциденту те, що було пропущено?

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

Почніть з одного бакета

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

Безпека API: OWASP API Top 10 на практиці

Tue, 25 Aug 2026 00:00:00 GMT

Розробник створює ендпоінт, який повертає замовлення клієнта. Він перевіряє токен сесії, завантажує замовлення за ідентифікатором з URL і повертає його. Усі тести проходять, рев’ю схвалює, API виходить у продакшн.

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

Ця одна відсутня перевірка є пунктом API1 в OWASP API Security Top 10 і досі залишається найпоширенішим способом витоку даних із реальних API. Вона ж показує, чому практики безпеки API читаються інакше, ніж практики безпеки вебзастосунків.

Уразливість тут не в payload, не в помилці кодування і не у відсутньому заголовку. Це бізнес-правило, яке ніхто не записав.

Що таке практики безпеки API?

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

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

Помилка в тому, що сервер підтвердив особу і пропустив питання про дозвіл. Саме тому OWASP API Security Top 10 виглядає так несхоже на вебсписок: дві найвищі позиції — це зламаний контроль доступу, розділений за тим, до чого дістається виклик, до чужого об’єкта чи до функції, яку його роль не має викликати.

Чому API ламаються інакше, ніж вебзастосунки?

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

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

Це змінює те, що можна вважати даністю. Відповідь і є API, а не екран, і тіло запиту повністю контролює зловмисник, включно з полями, яких ваша форма ніколи не показувала.

Ідентифікатор у шляху — це параметр, а не факт. Усе, що надсилає клієнт, може відредагувати той, хто тримає токен.

Як OWASP API Security Top 10 групує реальні збої?

Редакція 2023 року легше лягає в навчання, якщо згрупувати її за питанням, яке сервер забув поставити.

Авторизація: чи належить цей об’єкт цьому виклику?

Broken object level authorization, API1, це саме той випадок із початку статті. Сервер завантажує названий у запиті об’єкт і повертає його без порівняння власності, тож будь-який автентифікований виклик може перебирати ідентифікатори та збирати записи. Наша вправа з BOLA ставить вас по обидва боки: підмініть ідентифікатор і прочитайте чужу поїздку, а потім додайте перевірку власності, яка це зупиняє.

Broken function level authorization, API5, це рольова версія тієї самої прогалини. Адмінські маршрути живуть у тому самому API, що й користувацькі, елементи керування сховані в інтерфейсі, а самі ендпоінти не мають перевірки ролі, тож до них дістається будь-який дійсний токен. У вправі з BFLA ви викликаєте службові ендпоінти з облікового запису аналітика лише для читання, а потім виправляєте це на рівні роутера, а не обробника.

Автентифікація: чи можна перебрати перевірку?

Broken authentication, API2, рідко означає зламану перевірку облікових даних. Зазвичай це коректна перевірка без жодного захисту від автоматизації, і це стає вирішальним, коли обліковий елемент короткий.

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

Дані: що насправді є у відповіді?

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

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

Масове призначення — та сама проблема, спрямована в інший бік. Коли ендпоінт оновлення прив’язує кожне поле з тіла запиту до моделі, клієнт може додати role чи balance до PATCH і записати атрибути, яких форма ніколи не показувала. Вправа з масового призначення створює бонусний баланс двома зайвими ключами, а потім прив’язує лише редаговані поля.

Ліміти та інвентаризація: про що ви забули?

Unrestricted resource consumption, API4, охоплює ендпоінти без серверного обмеження на обсяг одного запиту. Розмір сторінки, взятий просто з рядка запиту, перетворює звичайну пагінацію на повний експорт таблиці. Подивіться, як це працює, у вправі з необмеженого споживання ресурсів.

Improper inventory management, API9, це версія, яку не полагодити в коді, на який ви дивитесь. Застаріла v1, задокументована як виведена з експлуатації, але ніколи не вимкнена, досі відповідає, і без жодного контролю, який додала v2. Вправа з інвентаризації API читає записи через стару версію, а потім коректно закриває її статусом 410 Gone.

Security misconfiguration, API8, завершує набір. Політика CORS, яка відображає будь-який Origin і дозволяє облікові дані, дає можливість будь-якому сайту прочитати авторизований акаунт, і жодної помилки в застосунку для цього не потрібно.

Які практики безпеки API справді зменшують ризик?

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

Перевіряйте власність на рівні даних, а не обробника. Запит із фільтром за ідентифікатором того, хто викликає, неможливо забути так, як умовний оператор. Обробники копіюють, методи репозиторію перевикористовують.
Ставте перевірки ролей на роутері. Захист, застосований на маршруті, аудиюється в одному файлі. Захист усередині кожного обробника аудиюється лише читанням їх усіх.
Серіалізуйте за білим списком. Опишіть поля, які може містити відповідь. Усе, що додадуть до моделі пізніше, лишається приватним, доки хтось свідомо його не опублікує.
Прив’язуйте теж за білим списком. Приймайте з тіла запиту названий набір записуваних полів і відкидайте решту, щоб нова колонка ніколи не стала випадково доступною для запису з клієнта.
Обмежуйте розмір сторінки та частоту на сервері. Задайте жорсткий максимум, який не підніме жоден параметр запиту, і обмежуйте частоту на акаунт, а не на IP.
Логуйте читання, а не лише записи. Авторизований доступ — єдина категорія зловживань, яка не порушує жодного контролю, тож журнал аудиту є єдиним механізмом виявлення. Вправа з недостатнього логування та моніторингу показує агента підтримки, який дістає профіль клієнта без тікета й не лишає слідів.
Ведіть інвентар і дотримуйтеся дат виведення з експлуатації. Застаріла версія, яка досі відповідає, це продакшн, що б не писала документація.
Параметризуйте кожен запит. Ін’єкції старші за REST і досі виходять у реліз. Вправа з ін’єкцій в API перетворює пошук у каталозі на повне читання бази, а потім параметризує запит так, щоб введення лишалося даними.

Як навчати розробників безпеці API?

Читання OWASP API Security Top 10 дає словник. Воно не дає рефлексу, бо впізнати BOLA на слайді і помітити, що щойно написаний метод репозиторію приймає ідентифікатор і не приймає користувача, це різні навички.

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

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

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

Як виміряти, чи спрацювало навчання з безпеки API?

Відсоток проходження вимірює відвідуваність. Поведінку вимірюють три сигнали.

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

Усі три рахуються із систем, які у вас уже працюють. Жоден не потребує опитування.

Часті запитання

Яка вразливість API найпоширеніша?

Broken object level authorization, пункт API1 в OWASP API Security Top 10. API підтверджує, що виклик має дійсну сесію, а потім повертає будь-який названий у запиті об’єкт без перевірки, що той належить саме цьому користувачеві. Вона поширена, бо перевірку треба свідомо написати для кожного маршруту з ідентифікатором, а зелені тести ніяк не вказують на її відсутність.

Чи відрізняється OWASP API Security Top 10 від OWASP Top 10?

Так. Вебсписок покриває класи рівня застосунку, як-от ін’єкції, криптографічні збої та помилки конфігурації, по всьому застосунку. Список для API обмежений інтерфейсами, які споживає код, а не браузер, тому авторизація там має два окремі пункти, для об’єктів і для функцій, і додано інвентаризацію забутих версій та хостів.

Як часто проводити навчання з безпеки API?

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

Чи можна закрити безпеку API шлюзом або WAF?

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

Що розробнику виправити першим у наявному API?

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

Почніть з одного ендпоінта

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

Далі дайте розробникам на чому потренуватися. Наші вправи з безпеки API безкоштовні, а про впровадження в інженерній команді можна поговорити з нами.

Безпека контейнерів: практики для образів і runtime

Tue, 25 Aug 2026 00:00:00 GMT

Збірка передає токен розгортання в крок RUN, використовує його й видаляє файл наступним рядком. Dockerfile виглядає акуратно. Образ публікується в публічний реєстр.

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

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

Що таке безпека контейнерів?

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

NIST SP 800-190, Application Container Security Guide, ділить задачу так само: ризики образів, ризики реєстрів, ризики оркестратора, ризики середовища виконання та ризики хостової ОС. Більшість інцидентів припадає на перші чотири, і більшість із них є конфігурацією, а не кодом.

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

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

Уразливість застосунку дає зловмиснику одне: рівно те, що дозволяє ця конкретна вада. Слабкості контейнера вирішують, наскільки далеко це одне зайде.

Ін’єкція команд у сервісі, який працює під непривілейованим користувачем у distroless-образі, дає зловмиснику одну команду без шелу й без інструментів. Та сама вада у привілейованому контейнері з монтуванням хоста дає root на машині.

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

Мережа додає третю змінну. Прив’язку порту створює середовище виконання контейнерів на хості, тож у рев’ю security group вона не з’являється взагалі.

Які основні ризики безпеки контейнерів?

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

Збірка: що потрапляє всередину образу

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

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

Роздуті runtime-образи є тихішою проблемою збірки. Продакшн-образ із менеджером пакетів, компілятором, шелом і мережевими утилітами перетворює обмежену ваду на робочий набір інструментів. Вправа «Мінімальні образи контейнерів» стискає 412 МБ runtime багатоетапною збіркою й доводить, що шелу в підсумковому образі більше немає.

Постачання: звідки взявся базовий образ

Плаваючий тег базового образу означає, що шар під вашим кодом змінюється без чийогось рішення. Застарілий тег означає, що опубліковані відомі вразливості їдуть у продакшн з кожним деплоєм, у шарі, про який не згадує жоден файл залежностей. Вправа «Вразливі базові образи» сканує розгорнутий образ, закріплює базу за digest, переходить на slim-варіант і пересканує, щоб довести, що знахідки більше немає.

Гірше, коли база була ворожою від початку. Опублікувати образ під назвою, схожою на довірену, може будь-хто, і без перевірки підписів рядок FROM є просто рядком. Вправа «Шкідливі базові образи» простежує криптомайнер до видавця-двійника, а потім переводить перевірку підписів на момент завантаження, а не на момент інциденту.

Розповсюдження: хто може читати й писати у ваш реєстр

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

Вправа «Незахищеність реєстру контейнерів» покриває обидві половини й завершується обмеженими правами на запис і замороженими релізними тегами.

Runtime: що видали контейнеру

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

Docker API еквівалентний root і постачається без автентифікації. Демон, якому сказали слухати мережевий порт з вимкненим TLS, відповість кожному, хто до нього дістанеться, і на відміну від втечі з контейнера тут не потрібен жоден плацдарм. Вправа «Відкритий Docker-демон» починається з публічної сторінки статусу, яка називає продакшн-вузол, і завершується взаємним TLS зі скоупленим проксі до сокета.

Мережа: що насправді опублікувала прив’язка порту

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

У мережі bridge за замовчуванням кожен контейнер також дістається до кожного іншого. Вправа «Незахищеність мережі контейнера» підключається до опублікованого порту бази без участі застосунку, прив’язує мапінг до loopback і сегментує сервіси у власну мережу.

Які практики безпеки контейнерів застосувати першими?

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

Скануйте образи в CI і зупиняйте збірку на критичних знахідках у базовому шарі. Це ловить категорію, яку не покриває жодне рев’ю залежностей.
Закріплюйте базові образи за digest. Тег є рухомою ціллю. Digest є саме тим, що ви протестували.
Використовуйте secret mount під час збірки, а не build-аргументи. Облікові дані з --build-arg записуються в образ. Secret mount у BuildKit не записується.
Розділяйте збірку та runtime багатоетапною збіркою. Компілятори, менеджери пакетів і шели належать етапу збірки й більше нікуди.
Запускайте від імені не-root користувача й типово скидайте capabilities. Задайте користувача в образі, щоб деплой не зміг тихо повернутися до root.
Ніколи не запускайте privileged, а монтування хоста зробіть точкою рев’ю. І те, і те іноді потрібне і завжди варте свідомого рішення.
Вимагайте автентифікацію в реєстрі та заморожуйте релізні теги. Анонімне завантаження є витоком даних. Анонімний запис є компрометацією ланцюга постачання.
Прив’язуйте опубліковані порти до loopback, якщо сервіс справді не публічний. Публічні ставте за проксі, який контролюєте ви.
Ніколи не виставляйте Docker-демон на TCP-порт без взаємного TLS. Якщо контейнеру потрібен сокет, поставте перед ним скоуплений проксі.
Перевіряйте підписи образів під час завантаження. Походження є єдиним захистом від бази, яка ніколи не була легітимною.

CIS Docker Benchmark покриває ту саму територію значно детальніше, і його варто запускати як аудит. Сприймайте список вище як порядок виправлень, а бенчмарк як запис того, що ви виправили.

Як навчати розробників безпеці контейнерів?

Більшість матеріалів про контейнери є чеклістами, а чеклісти вчать відповідності, а не судженню. Розробник може виконати кожне правило вище і все одно дописати --privileged о шостій вечора, щоб збірка пройшла, бо ніщо в чеклісті не показало йому, що саме цей прапорець видає.

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

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

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

Часті запитання

Чи є контейнер межею безпеки?

Не за замовчуванням. Контейнер є набором просторів імен ядра та cgroups, і деплой може вимкнути майже всі з них так, що нічого не виглядатиме зламаним. Межею він стає тоді, коли працює від не-root користувача, скидає capabilities, обходиться без privileged і монтувань хоста, а ядро хоста лишається пропатченим.

Чи прибирає видалення секрету в Dockerfile його з образу?

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

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

Чим безпека контейнерів відрізняється від безпеки хмари?

Безпека контейнерів є підмножиною. Вона покриває образ, реєстр, середовище виконання й мережу контейнерів, тоді як безпека хмари покриває ще керування ідентичностями та доступом, конфігурацію сховищ, мережеві межі на рівні провайдера й control plane.

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

Що робити спершу, сканувати образи чи міняти базові?

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

Чи менш безпечний Docker за Kubernetes?

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

Почніть з одного образу

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

Далі дайте розробникам на чому потренуватися. Наші вправи з безпеки контейнерів безкоштовні, а про впровадження в інженерній команді можна поговорити з нами.

Найкращі платформи навчання безпечного коду 2026

Tue, 04 Aug 2026 00:00:00 GMT

Найкраща платформа навчання безпечного коду у 2026 році залежить від того, як саме навчаються ваші розробники і наскільки широкий у вас стек. Secure Code Warrior лідирує за кількістю мов і бенчмаркінгом на рівні організації. Veracode Security Labs підходить командам, які вже стандартизувалися на скануванні Veracode. RansomLeak виграє за глибиною «зламай, потім полагодь» у вебі, API, Git, хмарі, мобільних застосунках і фронтенді. Цей огляд порівнює вісім вендорів application security training за прозорою методологією.

Оновлено у серпні 2026.

Що таке навчання безпечного коду?

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

Категорія межує з security awareness training, але не перетинається з ним. Програми обізнаності вчать бухгалтера ставити під сумнів запит на переказ коштів. Програми безпечного коду вчать бекенд-інженера, чому конкатенація рядків у побудові запиту віддає атакувальнику всю таблицю.

Покупці оцінюють ці платформи за чотирма речами. Чи є лабораторні роботи справді практичними, чи це відео з тестом. Скільки мов і фреймворків покрито. Як каталог мапується на OWASP Top 10. І чи виходить покриття за межі вебзастосунків до API, пайплайнів і конфігурації хмари.

Як ми ранжували цих вендорів application security training

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

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

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

Третій — актуальність OWASP. OWASP Top 10:2025 анонсували у листопаді 2025 і фіналізували у січні 2026: додано Software Supply Chain Failures як A03 та Mishandling of Exceptional Conditions як A10, а SSRF згорнуто у Broken Access Control. Самі класи вразливостей стабільні, а от мапування каталогів і підписи у звітності — ні, тому питайте кожного вендора, на яку редакцію він мапується сьогодні.

Четвертий — вимірюваність. За звітом Veracode State of Software Security 2025, половина організацій має критичний безпековий борг, а середній час виправлення дефектів зріс на 47% з 2020 року. Платформу, яка не може показати, чи зрушила вона ці цифри, важко продовжити на наступний рік.

1. RansomLeak

RansomLeak — це платформа інтерактивного навчання, чий каталог з application security ставить розробника по обидва боки кожної вразливості. Ви починаєте як атакувальник проти навмисно вразливого застосунку у симульованому браузері, потім перемикаєтесь на роль appsec-інженера, впроваджуєте виправлення і повторно запускаєте початковий payload уже проти власного патча. Компанію створила команда, що стоїть за Kontra Application Security Training.

Покриття виходить за межі вебового Top 10. Поряд із каталогом API Security платформа має треки з Git і контролю версій, DevOps та хмари (Docker, Kubernetes, AWS, Azure, GCP), мобільних застосунків і фронтенду. Вразливий код і його виправлення відображаються у JavaScript, TypeScript, Java, C#, Python, Scala, PHP, Ruby, Go та Kotlin.

База даних у кожній вправі справжня і вбудована, тому запити видно у панелі Network браузера, а не описано на слайді. Спробуйте SQL-ін’єкцію, broken object level authorization або server-side request forgery, щоб побачити формат до того, як з кимось говорити.

Сильні сторони: схема «зламай, потім полагодь» у кожній вправі, широта від вебу та API до Git, хмари, мобільних і фронтенду, відображення коду десятьма мовами, безкоштовний браузерний каталог без реєстрації, доставка через SCORM та LTI 1.3 у наявну LMS.

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

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

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

2. Secure Code Warrior

Secure Code Warrior — найбільший незалежний вендор категорії і точка відліку, з якої стартує більшість покупців. Матеріали вендора описують Learning Platform як 600+ годин контенту у 70+ комбінаціях мов і фреймворків, з практичними лабораторними роботами, навчальними траєкторіями, оцінюваннями та гейміфікованими турнірами.

Найсильніша відмінність — вимірювання. SCW Trust Score, запущений у травні 2024, бенчмаркує навички команди проти великого масиву даних по клієнтах, що дає безпековому керівнику цифру, яку можна захистити перед радою директорів. У березні 2026 компанія випустила Trust Agent, який відстежує, які моделі вплинули на коміт, і може блокувати на етапі pull request.

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

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

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

Про ціни: індивідуальні, за місцем на розробника. Не публікуються.

3. Security Journey

Security Journey — це об’єднаний продукт HackEDU і Security Journey, які злилися після придбання у травні 2022 і консолідувалися під назвою Security Journey у серпні того ж року. Платформа побудована як програма поясів: від базового білого пояса до практичної роботи, специфічної для конкретної мови.

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

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

Слабкі сторони: більше відео порівняно з lab-first платформами, впізнаваність бренду досі розподілена між двома історичними назвами, слабше покриття хмарних і пайплайнових тем.

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

Про ціни: індивідуальні, за місцем.

4. Veracode Security Labs

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

Основна вага платформи походить від решти Veracode. Якщо ваші знахідки SAST і SCA вже потрапляють туди, маршрут від конкретної знахідки до лабораторної про цей клас дефектів дуже короткий. Окремо від екосистеми навчання важче обґрунтувати проти спеціалізованих вендорів, хоча для окремих розробників існує безкоштовна Community Edition.

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

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

Кому підходить: командам, які вже працюють із Veracode і хочуть прив’язати навчання з виправлення до результатів сканування.

Про ціни: індивідуальні, зазвичай у пакеті з ширшою платформою Veracode.

5. Security Compass

Security Compass продає application security training поряд із SD Elements, своєю платформою перетворення політик на вимоги. У лютому 2024 компанія придбала Kontra у ThriveDX, додавши інтерактивні вправи Kontra до портфеля, що вже містив навчальну програму з 50+ курсів AppSec і практикантські набори під спільним брендом з ISC2.

Найпомітніша можливість — just-in-time навчання всередині SD Elements. Контрзаходи, згенеровані для конкретного проєкту, несуть прив’язані мікромодулі, тож розробник отримує потрібний урок разом із вимогою, а не під час щорічного навчання. Курси мапуються на NIST 800-53, PCI DSS, ISO/IEC 27034, HIPAA та SOC 2.

Сильні сторони: доставка just-in-time, прив’язана до проєктних вимог, глибоке мапування на стандарти, інтерактивні вправи Kontra, формальні сертифікаційні траєкторії.

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

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

Про ціни: індивідуальні, зазвичай у котируванні разом із SD Elements.

6. SecureFlag

SecureFlag проводить навчання у справжніх середовищах розробки, даючи розробнику робочу IDE і живий застосунок замість симульованого редактора. Каталог містить велику бібліотеку практичних лабораторних у 45+ технологічних стеках, що охоплюють код застосунків, infrastructure as code і конфігурацію контейнерів.

Саме покриття інфраструктури та контейнерів є причиною внести SecureFlag у short-лист. Команди, чий ризик сидить у Terraform і маніфестах Kubernetes не менше, ніж у коді застосунку, знайдуть тут більше релевантного матеріалу, ніж у веборієнтованих каталогах.

Сильні сторони: справжні IDE та середовища виконання, сильне покриття infrastructure as code і контейнерів, широкий перелік технологічних стеків, контент із моделювання загроз.

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

Кому підходить: платформенним і DevOps-орієнтованим інженерним командам, які хочуть лабораторні у тих інструментах, якими реально користуються.

Про ціни: індивідуальні, за місцем.

7. Snyk Learn

Snyk Learn — це безкоштовна безпекова освіта для розробників від Snyk, що покриває класи вразливостей у JavaScript, Java, C#, Python, PHP, Go, Rust, Ruby та C++, а також теми Kubernetes, AI та LLM. Уроки пояснюють, як працює вразливість, показують її у коді та розбирають виправлення.

Це найкращий безкоштовний старт у цьому списку і розумне доповнення до платної програми. Але це не корпоративна навчальна програма. Тут немає управління місцями, призначення за ролями та звітності для відповідності, тому самостійно вона не закриє вимогу аудиту.

Сильні сторони: справді безкоштовно, добрий розкид мов, зрозумілий виклад, без циклу закупівлі, корисні уроки з безпеки AI та LLM.

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

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

Про ціни: безкоштовно.

8. Avatao

Avatao — європейська платформа навчання безпечного коду для малих і середніх інженерних команд, із практичними лабораторними, змапованими на ISO 27001, PCI DSS, SOC 2 та NIS2. Мапування на стандарти і є основною пропозицією, і вона справді працює для команд, чий бюджет на навчання існує тому, що аудитор попросив докази.

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

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

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

Кому підходить: SMB і командам середнього бізнесу, яких веде вимога ISO 27001, SOC 2 або NIS2.

Про ціни: індивідуальні, у сегменті нижче корпоративних вендорів.

Що має покривати application security training у 2026 році?

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

API заслуговують на власний трек. Broken object level authorization і mass assignment поводяться не так, як вебові вразливості, їх рідко видно на відрендереній сторінці, і саме вони найчастіше зливають записи у великих обсягах. Питайте, чи вендор вважає OWASP API Security Top 10 повноцінним курсом, чи парою прикручених уроків.

Контроль версій і пайплайни тепер першокласні теми. Секрети, закомічені у Git, надмірно широкі токени workflow і отруєні кроки збірки стоять за чималою часткою нещодавніх інцидентів, і саме тому оновлення OWASP 2025 підняло supply chain failures до A03.

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

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

Розробка з AI-асистентами змінює навантаження. Асистенти швидко генерують небезпечні патерни, а це підвищує цінність розробника, який упізнає їх на рев’ю. Дивіться ризики безпеки AI-асистентів для коду та курс OWASP LLM Top 10 для цього боку програми.

Чим навчання безпечного коду відрізняється від security awareness training?

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

Більшість стандартів вимагають обох. SOC 2, ISO 27001 і PCI DSS просять і загальну обізнаність персоналу, і рольове навчання для тих, хто будує та підтримує системи, тому програми, що роблять лише одне з двох, отримують зауваження.

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

Яка платформа навчання безпечного коду підходить вашій команді?

Скористайтеся цим, щоб швидко звузити short-лист.

Великі поліглотні інженерні організації (500+ розробників). Починайте з Secure Code Warrior за широтою мов і бенчмаркінгом. Додайте RansomLeak, якщо потрібна глибина «зламай, потім полагодь» і покриття поза вебом у Git, хмарі, мобільних і фронтенді. Додайте Security Journey, якщо обґрунтована рольова прогресія важливіша за реалістичність лабораторних.

Продуктові команди середнього бізнесу (50 до 500 розробників). Найкраще підходять RansomLeak, Security Journey і SecureFlag. Обирайте RansomLeak за практику по обидва боки атаки на всьому стеку. Обирайте SecureFlag, якщо більшість ризику у Terraform, контейнерах і Kubernetes.

Невеликі команди та стартапи (менш ніж 50 розробників). Почніть із безкоштовного Snyk Learn, а платну платформу додайте, коли аудит чи анкета клієнта змусять. Avatao має ціну під цей сегмент, коли тригером є ISO 27001 або SOC 2.

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

Регульовані підприємства з формальними вимогами до SDLC. Security Compass побудований саме для цього, особливо там, де SD Elements уже генерує контрзаходи для проєктів. Перед підписанням уточніть, яку редакцію OWASP відображає мапування відповідності кожного вендора.

Організації, що працюють через LMS. Якщо навчання має йти всередині Cornerstone, Workday чи Moodle, а не в новій консолі, підтвердіть доставку через SCORM або LTI на ранньому етапі. Кілька appsec-вендорів працюють лише у власній консолі. Дивіться SCORM-навчання з кібербезпеки, як цей чинник спрацьовує на практиці.

Часті запитання

Яка платформа навчання безпечного коду найкраща у 2026 році?

Єдиної найкращої платформи немає. Secure Code Warrior лідирує за широтою мов і бенчмаркінгом для великих поліглотних організацій, а Snyk Learn є найкращим безкоштовним варіантом. RansomLeak найкраще підходить командам, які хочуть, щоб розробник спершу проексплуатував дефект, а потім виправив його, з покриттям вебу, API, Git, хмари, мобільних і фронтенду.

Скільки коштує навчання безпечного коду?

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

Чи справді навчання безпечного коду зменшує кількість вразливостей?

Це цілком залежить від формату. Навчання, що просить розробника впізнати вразливість, дає впізнавання. Навчання, що просить її спричинити, потім залатати, а потім повторити початковий payload проти патча, дає відтворювану навичку. Звіт Veracode State of Software Security 2025 показав, що середній час виправлення дефектів зріс на 47% з 2020 року, а це натякає, що програми лише на впізнавання цю цифру не рухають.

Як часто розробники мають проходити навчання безпечного коду?

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

На яку редакцію OWASP Top 10 мапувати програму: 2021 чи 2025?

Мапуйте програму на 2025 і очікуйте, що каталоги вендорів відставатимуть. Редакція 2025 додала Software Supply Chain Failures на A03 та Mishandling of Exceptional Conditions на A10, а SSRF згорнула у Broken Access Control. Самі класи вразливостей не змінилися, тому вправи з SSRF чи XXE залишаються чинними незалежно від того, під якою категорією вендор їх подає.

Чи може навчання безпечного коду працювати у нашій наявній LMS?

Іноді. Вендори, орієнтовані на власну консоль, очікують, що розробник заходитиме на їхню платформу, а це реальна перешкода для впровадження, коли решта навчання вже живе у корпоративній LMS. RansomLeak доставляє через SCORM 1.2, SCORM 2004 та LTI 1.3 з поверненням статусу завершення. Підтвердіть це на демо, а не за даташитом.

Чи потрібен security awareness training, якщо розробники проходять навчання безпечного коду?

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

Підсумок

Ринок навчання безпечного коду у 2026 році ділиться на три частини. Вендори широти й бенчмаркінгу (Secure Code Warrior, Security Journey) конкурують розміром каталогу та звітністю на рівні програми, тоді як екосистемні вендори (Veracode, Snyk, Security Compass) конкурують близькістю до інструментів, які вже породжують ваші знахідки. Вендори глибини практики (RansomLeak, SecureFlag) конкурують тим, наскільки реальною відчувається лабораторна.

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

Запустіть одну і перевірте. Зламайте форму входу через SQL-ін’єкцію, пройдіться по ID об’єктів API через broken object level authorization або підсадіть payload через збережений міжсайтовий скриптинг, потім впровадьте виправлення і повторіть власну атаку проти нього. Перегляньте каталоги application security та API security або напишіть нам про розгортання на всю інженерну організацію.

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

Діпфейки і Закон ЄС про ШІ: прозорість за Статтею 50

Tue, 09 Jun 2026 00:00:00 GMT

Закон ЄС про ШІ не забороняє діпфейки. Він трактує їх як проблему прозорості, тож обовʼязок полягає не в тому, щоб зупиняти синтетичні медіа, а в тому, щоб люди знали, коли контент штучний.

Цей обовʼязок живе у Статті 50, і він розподіляє відповідальність між компанією, що будує інструмент генерації, і компанією, що публікує результат. Хибний розподіл — це те, як маркетинговий ролик чи навчальне відео перетворюється на прогалину у відповідності.

Як Закон ЄС про ШІ регулює діпфейки?

За Законом ЄС про ШІ (Регламент (ЄС) 2024/1689) діпфейк — це згенероване або змінене ШІ аудіо, зображення чи відео, що нагадує реальних людей, обʼєкти чи події і помилково видається автентичним. Стаття 3(60) задає це визначення. Стаття 50 відносить діпфейки до рівня обмеженого ризику й накладає обовʼязки щодо прозорості: штучну природу контенту треба розкрити, щоб звичайна людина не була введена в оману.

Це легший режим, ніж правила високого ризику, що керують системами на кшталт відбору резюме чи кредитного скорингу. Тут стурбованість у чесності, а не в безпеці, і виправлення — це позначка, а не заборона. Про те, як цей рівень стоїть поряд з іншими, читайте наш посібник із категорій ризику Закону ЄС про ШІ.

Чого Стаття 50 вимагає для синтетичних медіа?

Стаття 50 задає два окремі обовʼязки, що часто стосуються того самого фрагмента контенту. Постачальники генеративного ШІ загального призначення мають позначати свій результат як штучно згенерований у машинозчитуваному форматі, щоб системи нижче за течією могли його виявити. Впроваджувачі, що створюють або публікують діпфейк, мають розкрити, що контент штучно згенеровано або змінено, у спосіб, який людина здатна сприйняти.

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

Обовʼязок	На кого лягає	Як це виглядає на практиці
Позначити результат як згенерований ШІ	Постачальник системи GenAI	Машинозчитуваний водяний знак чи метадані, стійкі й виявні
Розкрити діпфейк глядачам	Впроваджувач, що його публікує	Видимий підпис, позначка чи екранне повідомлення
Розкрити, що чат-бот — це ШІ	Впроваджувач, що запускає бота	Заява до початку розмови
Повідомити, коли текст згенеровано ШІ	Впроваджувач, що публікує текст ШІ з питань суспільного інтересу	Розкриття, якщо текст не пройшов людську редактуру з редакційною відповідальністю

Вправа «Прозорість і розкриття ШІ» проводить маркетингову команду через правильне позначення кожного з цих випадків, зокрема відгуку з клонованим голосом і покращеного ШІ зображення продукту.

Хто має розкривати діпфейк: постачальник чи впроваджувач?

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

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

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

Чи є винятки для мистецтва, сатири чи правоохоронних органів?

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

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

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

Як обовʼязки розкриття діпфейків повʼязані з ризиком шахрайства?

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

Ставки конкретні. У 2024 році інженерна фірма Arup підтвердила, що співробітника в її гонконгському офісі ошукали виплатити близько US$25 мільйонів після відеодзвінка, повністю заповненого діпфейк-відтвореннями старших керівників, як повідомили CNN і Financial Times. Жоден водяний знак тут не допоміг би, бо інструментарієм керували шахраї.

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

Діпфейк реальної людини майже завжди є обробкою персональних даних, тож Закон про ШІ лягає поверх GDPR, а не замінює його. Стаття 50 керує розкриттям, тоді як GDPR (Регламент (ЄС) 2016/679) усе ще керує законною підставою, правами особи й безпекою базових даних. Використання чийогось обличчя чи клонованого голосу без дійсної підстави — це проблема захисту даних незалежно від будь-якої позначки.

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

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

Як RansomLeak навчає обізнаності з діпфейками та розкриттю

RansomLeak трактує Статтю 50 як операційну навичку, а не юридичну абстракцію. Вправа «Прозорість і розкриття ШІ» ставить учнів усередину перегляду управління контентом, де вони правильно позначають згенеровані ШІ, створені за допомогою ШІ та синтетичні медіа й переписують чат-бота, що приховує свою ШІ-природу. Сценарій навчає обовʼязку розкриття, змушуючи людей застосовувати його, а не зачитуючи їм статтю.

Бік атаки йде паралельно. Вправа «Виявлення діпфейк-аудіо» навчає персонал ставити під сумнів клонований голос у дзвінку, а вправа «Вейлінг із діпфейком» відпрацьовує сценарій видавання за керівника, що так дорого коштував Arup, — той самий патерн, який наш посібник із вейлінгу розбирає докладно. Обидві живуть у каталозі безпеки ШІ, поряд з інʼєкціями в підказки й ризиками LLM, що мають той самий корінь.

Розкриття також належить до вашої програми відповідності, тому каталог приватності та відповідності містить курс із Закону ЄС про ШІ поряд зі сценаріями GDPR. Для розбору регламенту від початку до кінця наш посібник із навчання за Законом ЄС про ШІ накладає кожен обовʼязок на конкретну вправу. Щоб побачити, як обовʼязки щодо синтетичних медіа перетворюються на рольове навчання, замовте демонстрацію з нашою командою.

Поширені запитання

Чи забороняє Закон ЄС про ШІ діпфейки?

Ні. Закон ЄС про ШІ не забороняє діпфейки; він трактує їх як обмежений ризик і накладає обовʼязки щодо прозорості за Статтею 50. Контент дозволено, але його штучну природу треба розкрити, щоб глядачі не були введені в оману. Заборонені практики за Статтею 5 — це окрема й значно менша категорія.

Яке юридичне визначення діпфейка за Законом ЄС про ШІ?

Стаття 3(60) визначає діпфейк як згенерований або змінений ШІ контент у вигляді зображення, аудіо чи відео, що нагадує реальних осіб, обʼєкти, місця, сутності чи події і помилково видається людині автентичним або правдивим. Визначення тримається на схожості з реальністю й потенціалі ввести в оману, а не на конкретній техніці, використаній для створення.

Хто відповідає за позначення діпфейка?

Відповідальність розподілена. Постачальник генеративної системи ШІ має позначати результат як штучно згенерований у машинозчитуваний спосіб, а впроваджувач, що публікує діпфейк, має розкрити глядачам, що контент штучний. Правильний водяний знак від інструмента не знімає обовʼязку видавця дати видиме розкриття.

Коли правила прозорості щодо діпфейків починають діяти?

Обовʼязки щодо прозорості за Статтею 50 застосовуються з 2 серпня 2026 року — тієї самої дати, коли набирає чинності більшість решти положень регламенту. Сам Закон про ШІ набув чинності 1 серпня 2024 року, а заборонені практики й обовʼязки щодо грамотності ШІ діють уже з 2 лютого 2025 року.

Чи є штрафи за нерозкриття діпфейка?

Так. Порушення обовʼязків щодо прозорості може потягнути штрафи до €15 мільйонів або 3% глобального річного обороту за Статтею 99, залежно від того, що більше, причому нижча цифра застосовується до малих і середніх підприємств. Точний штраф залежить від порушення, розміру організації та виявленої співпраці.

Чи застосовується Стаття 50 до синтетичних медіа, що використовуються всередині?

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

Підсумок

Закон ЄС про ШІ регулює діпфейки через розкриття, а не заборону. Стаття 50 просить постачальників позначати синтетичний результат машинним способом і просить впроваджувачів сказати своїй аудиторії, що контент штучний, а більшість організацій несуть обовʼязок впроваджувача куди частіше, ніж усвідомлюють.

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

Джерела

Закон ЄС про ШІ і GDPR: де ці два закони перетинаються

Tue, 09 Jun 2026 00:00:00 GMT

Команди часто сприймають Закон ЄС про ШІ як новенький звід правил, що лягає на чистий стіл. Це не так. Якщо ваша система ШІ торкається персональних даних, GDPR уже був на тому столі, а Закон про ШІ накладається поверх нього.

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

Закон ЄС про ШІ і GDPR — це два регламенти ЄС, що діють разом. GDPR (Регламент 2016/679) регулює, як організації поводяться з персональними даними, тоді як Закон про ШІ (Регламент 2024/1689) регулює системи ШІ за рівнем ризику. Система ШІ високого ризику, що обробляє персональні дані, має задовольняти обидва, тож Закон про ШІ додає обовʼязки поверх GDPR, а не замінює його.

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

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

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

Тема	Обовʼязок за GDPR	Обовʼязок за Законом ЄС про ШІ
Оцінка впливу	DPIA для обробки високого ризику (Стаття 35)	FRIA для окремих впроваджувачів високого ризику (Стаття 27)
Якість даних і керування ними	Принципи точності й мінімізації (Стаття 5)	Керування даними для систем високого ризику (Стаття 10)
Записи	Записи про діяльність з обробки (Стаття 30)	Технічна документація й журналювання
Прозорість	Інформування субʼєктів даних (Статті 13 і 14)	Розкриття взаємодії з ШІ та синтетичного контенту (Стаття 50)
Міжнародні передачі	Запобіжники Розділу V	Окремого режиму передач немає; дані регулює GDPR
Обовʼязок щодо інцидентів	Повідомлення про витік персональних даних (Статті 33 і 34)	Звітування про серйозні інциденти для систем високого ризику

Патерн послідовний. GDPR регулює дані всередині системи, а Закон про ШІ регулює систему, що діє на ці дані. Вправа «ШІ та захист даних» проводить медичну модель через обидва режими одночасно, щоб команди відчули, де обовʼязки сходяться.

DPIA проти FRIA: чи потрібні обидві?

Часто так. Оцінка впливу на захист даних за Статтею 35 GDPR розглядає ризик, який діяльність з обробки створює для прав людей на їхні дані. Оцінка впливу на основні права за Статтею 27 Закону про ШІ розглядає ширший ризик, який система ШІ високого ризику створює для основних прав, і вона застосовується до публічних органів та окремих впроваджувачів високого ризику перед першим використанням.

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

Розумний хід — провести їх як одну узгоджену вправу, а не як дві відірвані одна від одної форми. Вправа «Оцінка впливу на захист даних за GDPR» тренує половину DPIA, а вправа «Оцінка впливу на основні права» тренує половину FRIA, тож команда бачить, як одна живить іншу, замість дублювати роботу.

Воно спирається на інвентаризацію, яку ви вже маєте мати. Стаття 30 GDPR вимагає записів про діяльність з обробки — задокументовану карту того, які персональні дані ви тримаєте, навіщо й куди вони течуть. Стаття 10 Закону про ШІ далі вимагає, щоб системи високого ризику використовували навчальні та вхідні дані, що є релевантними, репрезентативними й керованими за якістю.

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

Саме тому чесна карта даних окуповується двічі. Вправа «Картування даних і записи про обробку за GDPR» тренує дисципліну Статті 30, а вправа «Керування даними для ШІ» поширює її на навчальні набори, тож та сама карта служить і вашому відділу приватності, і власнику управління ШІ.

Так, і Закон про ШІ їх не змінює. Закон про ШІ не має окремого режиму передач, тож коли навчальні дані ШІ містять персональні дані й переміщуються за межі ЄС, переміщення регулює Розділ V GDPR. Це означає рішення про адекватність, стандартні договірні умови або інший дійсний запобіжник.

Це застає команди зненацька з моделями в хмарі. Надсилання європейських персональних даних до точки доступу моделі в іншому регіоні — це передача, навіть коли дані «лише» використовуються для донавчання чи запуску інференсу. Ярлик ШІ не звільняє дані від Розділу V.

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

Як узгоджуються обовʼязки щодо витоку та ШІ-інциденту?

Вони стоять поруч і можуть обидва спрацювати від однієї події. Статті 33 і 34 GDPR вимагають повідомити наглядовий орган, а іноді й постраждалих людей, після витоку персональних даних. Закон про ШІ додає обовʼязок звітувати про серйозні інциденти для систем високого ризику, націлений на збої та шкоду, а не на розкриття даних.

Один інцидент може запустити обидва годинники. Якщо система ШІ високого ризику дає збій і цей збій також розкриває персональні дані, ви можете бути винні повідомлення про витік за GDPR і звіт про інцидент за Законом про ШІ на термінах, що перетинаються.

Команди реагування мають знати, що обидва обовʼязки існують, до інциденту, а не під час нього. Вправа «Реагування на інциденти безпеки за GDPR» репетирує відлік повідомлення про витік під тиском, а поєднання цієї мʼязової памʼяті з обізнаністю щодо ШІ-інцидентів не дає одній події перетворитися на два пропущені дедлайни.

Чи може одна програма навчання охопити обидва закони?

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

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

Розгалуження — там, де кожен закон іде своїм шляхом. Каталог приватності та відповідності містить сценарії GDPR поряд із курсом про Закон ЄС про ШІ, тож єдиний навчальний шлях може охопити права субʼєктів даних і засоби контролю ризиків ШІ, не проводячи людей через дві непов’язані навчальні програми.

RansomLeak навчає перетину як повʼязаних сценаріїв, а не як двох ізольованих курсів. Курс із Закону ЄС про ШІ й курс із GDPR мають спільний хребет керування даними, тож той, хто розуміє записи про обробку, уже має опору для керування даними ШІ, а той, хто провів DPIA, бачить, як FRIA її поширює.

Кожен модуль експортується у SCORM для LMS, яку перевірятиме аудитор, а це важить, коли потрібно показати, що люди, які оперують ШІ на персональних даних, справді пройшли навчання за обома режимами. Для розбору регламентів від початку до кінця наш посібник із навчання за Законом ЄС про ШІ і посібник із навчання GDPR накладають кожен обовʼязок на конкретну вправу.

Глибший контекст живе у двох супутніх статтях. Наш посібник із категорій ризику Закону ЄС про ШІ пояснює чотирирівневу модель, що вирішує, які обовʼязки щодо ШІ застосовуються, а посібник із графіка відповідності Закону ЄС про ШІ викладає поетапні дати. На боці приватності надійна програма навчання працівників за GDPR і базові принципи захисту даних GDPR охоплюють роботу з даними, від якої залежить ШІ високого ризику.

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

Поширені запитання

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

Яка різниця між DPIA і FRIA?

DPIA за Статтею 35 GDPR оцінює ризик, який діяльність з обробки створює для прав людей на захист даних. FRIA за Статтею 27 Закону про ШІ оцінює ширший ризик, який система ШІ високого ризику створює для основних прав, і вона застосовується до публічних органів та окремих впроваджувачів високого ризику перед першим використанням. Багатьом проєктам ШІ високого ризику потрібні обидві.

Так, щоразу, коли навчальні дані містять персональні дані. Законна підстава, мінімізація даних і права субʼєктів даних усе ще застосовуються до цих даних, а переміщення їх за межі ЄС однаково запускає запобіжники передачі за Розділом V GDPR. Закон про ШІ додає обовʼязки щодо керування даними поверх, але не вимикає GDPR.

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

Так. Якщо система ШІ високого ризику дає збій і цей збій також розкриває персональні дані, ви можете бути винні повідомлення про витік за Статтями 33 і 34 GDPR та звіт про серйозний інцидент за Законом про ШІ. Ці два обовʼязки діють на термінах, що перетинаються, тож команди реагування мають планувати обидва ще до того, як інцидент станеться.

Чи мають малі підприємства якесь полегшення за цими правилами?

GDPR масштабує деякі обовʼязки за ризиком і обсягом, а Закон про ШІ встановлює межі штрафів, що беруть менше з двох значень для SME. Та суттєві обовʼязки все ж застосовуються. Мала компанія, що запускає систему ШІ високого ризику на персональних даних, винна ті самі базові засоби контролю, що й велика, лише з пропорційною штрафною експозицією.

Підсумок

Закон ЄС про ШІ і GDPR — не конкурентні зводи правил. GDPR регулює персональні дані, Закон про ШІ регулює систему, що діє на них, а проєкт високого ризику, що торкається персональних даних, має подолати обидва водночас.

Ставлення до них як до однієї узгодженої програми — ефективний і обороноздатний шлях. Побудуйте карту даних один раз, розгалужтеся на DPIA і FRIA, записи й керування даними ШІ, обовʼязки щодо витоку та інциденту, і навчіть людей, які оперують ШІ, за обома режимами, а не за одним.

Якщо хочете навчання на основі сценаріїв, що охоплює Закон про ШІ і GDPR разом, перегляньте каталог приватності та відповідності або поспілкуйтеся з нашою командою.

Джерела

Навчання з грамотності ШІ: Стаття 4 Закону ЄС про ШІ

Tue, 09 Jun 2026 00:00:00 GMT

Більша частина Закону ЄС про ШІ стосується вузького набору систем високого ризику. Стаття 4 — виняток, бо вона сягає кожної організації, яка створює або використовує ШІ, хоч би яким нешкідливим виглядав інструмент.

Вона до того ж діє з 2 лютого 2025 року, раніше за обовʼязки для систем високого ризику, що настають у серпні 2026 року. Тож поки команди планують важчі обовʼязки, положення про грамотність уже діє і вже підлягає виконанню.

Що таке грамотність ШІ за Законом ЄС про ШІ?

Навчання з грамотності ШІ — це освіта персоналу, що задовольняє Статтю 4 Закону ЄС про ШІ, яка вимагає від постачальників і впроваджувачів забезпечити достатній рівень грамотності ШІ серед персоналу, який керує ШІ від їхнього імені. Воно охоплює критичну оцінку результатів ШІ, перевірку перед дією і дисципліновану роботу з даними, незалежно від рівня ризику системи.

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

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

Що насправді вимагає Стаття 4?

Стаття 4 встановлює єдиний обовʼязок простою мовою. Постачальники й впроваджувачі мають вживати заходів, щоб забезпечити, наскільки це в їхніх силах, достатній рівень грамотності ШІ серед свого персоналу та інших осіб, які керують системами ШІ від їхнього імені.

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

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

Кому потрібне навчання з грамотності ШІ?

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

Таблиця нижче зіставляє поширені ролі з грамотністю, яка потрібна кожній. Розподіл не про посади, а про те, що кожна людина може зробити зі ШІ і якої шкоди може завдати помилка.

Аудиторія	Чим керують	Фокус грамотності
Загальний персонал	Чат-боти, копілоти, інструменти написання й резюмування	Виявлення помилок, перевірка результатів, захист конфіденційних даних
Менеджери й ті, хто ухвалює	ШІ, що підтримує рішення про найм, скоринг чи тріаж	Людський нагляд, розуміння, коли перевизначити, ескалація
Технічні та ШІ-команди	Моделі, які вони створюють, донавчають чи інтегрують	Обовʼязки постачальника, керування даними, упередженість, документація
Закупівлі та юристи	Вендорський ШІ, що заходить у бізнес	Класифікація ризиків, контракти, ролі постачальника та впроваджувача

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

Що має охоплювати навчання з грамотності ШІ?

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

По-перше, критична оцінка. Персонал має ставитися до результату ШІ як до чернетки, а не відповіді, чого й навчає вправа «Відповідальне використання інструментів ШІ на роботі» на реалістичних робочих сценаріях.

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

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

Чим грамотність ШІ відрізняється від загальної обізнаності з безпеки?

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

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

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

Як щодо моделей ШІ загального призначення?

ШІ загального призначення підвищує ставки грамотності, бо та сама модель живить десятки непов’язаних задач у бізнесі. Базова модель за чат-ботом, асистентом для написання коду й дослідницьким інструментом переносить ті самі сліпі плями в кожен із них.

GPAI також приносить власні правила. Окремі обовʼязки для моделей загального призначення набули чинності 2 серпня 2025 року, і саме тому персонал, що будує рішення поверх цих моделей, має розуміти їхні межі — фокус вправи «Обовʼязки моделей ШІ загального призначення (GPAI)».

Для ролей, що погоджують рішення за підтримки ШІ, грамотність і нагляд стають однією навичкою. Знати, коли перевизначити модель, — це практичне ядро Статті 14, і вправа «Значущий людський нагляд» репетирує саме той момент, коли докази не збігаються з рекомендацією.

Як підтвердити грамотність ШІ перед аудитором?

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

Більшість ваги несуть три артефакти. Журнал завершень із вашої LMS, запис про те, які ролі отримали яку глибину навчання, і політика, що привʼязує програму до вашого реєстру ШІ. Навчання, що експортується у SCORM, заводить ці завершення в систему, якій аудитор уже довіряє.

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

Хороша новина в тому, що ці самі докази виконують подвійну роботу. Записи про завершення, які ви ведете для Статті 4, також підтверджують історію людського нагляду за Статтею 14 і ширшу картину управління, на яку розраховує аудит за GDPR, тож один добре впорядкований журнал навчання відповідає на кілька запитань одразу.

Як RansomLeak проводить навчання з грамотності ШІ

RansomLeak перетворює Статтю 4 на рольові сценарії замість документа з політикою, якого ніхто не читає. Курс із безпеки ШІ проводить персонал через реальні рішення — безпечне використання інструмента, перевірку результату, перевизначення поганої рекомендації, — тож грамотність проявляється як поведінка, а не бал за тест.

Покриття охоплює всю аудиторію, якої сягає обовʼязок. Каталог безпеки ШІ містить вправи з грамотності, управління й нагляду для загального й технічного персоналу, а каталог приватності та відповідності стоїть поряд для обовʼязків з роботи з даними, на яких будується грамотність ШІ. Кожен модуль експортується у SCORM, тож завершення потрапляють у LMS, яку перевірятиме аудитор.

Для розбору регламенту від початку до кінця наш посібник з навчання за Законом ЄС про ШІ накладає кожен обовʼязок на конкретну вправу. Посібник з категорій ризику Закону ЄС про ШІ пояснює чотири рівні, що визначають, які важчі обовʼязки застосовуються, а посібник з термінів відповідності показує, де Стаття 4 стоїть у ширшому графіку. Якщо хочете побачити, як навчання на основі сценаріїв задовольняє обовʼязок щодо грамотності, перегляньте повний набір можливостей або замовте демонстрацію з нашою командою.

Поширені запитання

Чи є навчання з грамотності ШІ обовʼязковим за Законом ЄС про ШІ?

Так. Стаття 4 вимагає від постачальників і впроваджувачів забезпечити достатній рівень грамотності ШІ серед персоналу й інших осіб, які керують системами ШІ від їхнього імені, і вона діє з 2 лютого 2025 року. Обовʼязок сягає кожної організації, що використовує ШІ, а не лише тих, хто експлуатує системи високого ризику.

Кого охоплює вимога щодо грамотності ШІ за Статтею 4?

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

Який штраф за невиконання обовʼязку щодо грамотності ШІ?

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

Коли набув чинності обовʼязок щодо грамотності ШІ?

Обовʼязок щодо грамотності ШІ за Статтею 4 став застосовним 2 лютого 2025 року, тієї самої дати, що й заборони за Статтею 5. Це робить його одним із найбільш ранніх діючих обовʼязків у Законі ЄС про ШІ, задовго до обовʼязків для систем високого ризику, що застосовуються з 2 серпня 2026 року.

Чим грамотність ШІ відрізняється від загальної політики щодо ШІ?

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

Чи застосовується навчання з грамотності ШІ за межами ЄС?

Може. Закон ЄС про ШІ сягає постачальників і впроваджувачів, чий результат роботи ШІ використовується в межах ЄС, тож організація, заснована деінде, може потрапити в сферу дії. Багато компаній застосовують єдиний базовий рівень грамотності для всього персоналу, а не відстежують, де перебуває кожен користувач.

Підсумок

Стаття 4 — найширший обовʼязок у Законі ЄС про ШІ і той, що вже діє. Вона вимагає від кожної організації, що використовує ШІ, переконатися, що люди за цими інструментами можуть оцінювати результат, перевіряти перед дією і дбайливо поводитися з даними.

Розвʼязання практичне, а не юридичне. Підлаштуйте навчання під кожну роль, ведіть запис, який зможе прочитати аудитор, і оновлюйте його, щойно надходять нові інструменти. Якщо хочете навчання з грамотності ШІ на основі сценаріїв, що зіставлене зі Статтею 4 й експортується у вашу LMS, перегляньте каталог безпеки ШІ або поспілкуйтеся з нашою командою.

Джерела

Закон ЄС про ШІ: терміни відповідності до 2027

Wed, 03 Jun 2026 00:00:00 GMT

Закон ЄС про ШІ не набирає чинності в один день. Він застосовується поетапно між 2024 і 2027 роками, і кожен етап вмикає окремий набір обовʼязків для організацій, які створюють або використовують системи ШІ в Європі.

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

Що таке графік Закону ЄС про ШІ?

Графік Закону ЄС про ШІ — це поетапний розклад, який вводить у дію Регламент (ЄС) 2024/1689 між 2024 і 2027 роками. Закон набрав чинності 1 серпня 2024 року. Заборонені практики й обовʼязки щодо грамотності ШІ застосовуються з 2 лютого 2025 року, правила щодо ШІ загального призначення — з 2 серпня 2025 року, а обовʼязки для систем високого ризику — з 2 серпня 2026 року.

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

Дата	Що застосовується	Кого стосується	Найвищий рівень штрафу
1 серп. 2024	Регламент набирає чинності	Усі в межах дії	Ще не підлягає виконанню
2 лют. 2025	Заборонені практики (Стаття 5) і грамотність ШІ (Стаття 4)	Кожен постачальник і впроваджувач	€35 млн або 7% обороту
2 серп. 2025	Правила щодо ШІ загального призначення, управління і штрафи (Стаття 99)	Постачальники GPAI, органи	€15 млн або 3% обороту
2 серп. 2026	Обовʼязки для систем високого ризику з Додатка III і більшість решти правил	Постачальники й впроваджувачі систем високого ризику	€15 млн або 3% обороту
2 серп. 2027	Системи високого ризику в складі регульованих продуктів (Додаток I)	Виробники продуктів	€15 млн або 3% обороту

Коли Закон ЄС про ШІ набрав чинності?

Закон про штучний інтелект, формально Регламент (ЄС) 2024/1689, набрав чинності 1 серпня 2024 року. Це перший у світі горизонтальний закон про ШІ, і він регулює постачальників, впроваджувачів, імпортерів і дистрибʼюторів систем ШІ, що використовуються в Європейському Союзі.

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

Дія сягає за межі ЄС. Закон застосовується, коли результат роботи системи ШІ використовується в Союзі, що втягує в сферу дії велику частку світового ринку ШІ навіть для компаній зі штаб-квартирами в інших країнах.

Що застосовується з 2 лютого 2025 року?

Першими ввімкнулися два обовʼязки, і обидва вагомі. Заборона прихованих практик ШІ за Статтею 5 та обовʼязок щодо грамотності ШІ за Статтею 4 стали обовʼязковими до виконання з 2 лютого 2025 року.

Заборонений перелік охоплює вісім категорій, зокрема соціальний скоринг, нецільовий збір зображень облич, маніпулятивні чи експлуататорські системи та розпізнавання емоцій на робочих місцях і в школах. Їх узагалі не можна виводити на ринок ЄС, а порушення заборони тягне найвищий рівень штрафу — €35 мільйонів або 7% глобального річного обороту. Команди продукту, закупівель і юристи мають розпізнати заборонене використання ще до запуску, і саме на цьому зосереджена вправа «Заборонені практики ШІ».

Стаття 4 — це найширший обовʼязок у всьому регламенті. Вона вимагає від постачальників і впроваджувачів забезпечити достатній рівень грамотності ШІ серед персоналу й будь-кого, хто керує ШІ від їхнього імені, незалежно від рівня ризику задіяних систем.

Вправа «Основи грамотності ШІ» тренує три поведінки, яких насправді очікує стаття: критичну оцінку результатів ШІ, перевірку перед дією і дисципліновану роботу з даними. Повний розбір Статті 4 дивіться в нашому посібнику з навчання за Законом ЄС про ШІ.

Що змінилося 2 серпня 2025 року?

Другий етап додав правила для ШІ загального призначення та механізм правозастосування для всього регламенту. З 2 серпня 2025 року стали застосовними обовʼязки щодо моделей GPAI, розділ про управління і режим штрафів за Статтею 99.

Постачальники ШІ загального призначення тепер несуть обовʼязки з документування, прозорості та авторського права, з додатковими вимогами для моделей із системним ризиком. Впроваджувачі, які будують рішення поверх цих моделей, успадковують відповідальність нижче по ланцюгу, і цей розподіл по ролях розкриває вправа «Обовʼязки моделей ШІ загального призначення (GPAI)».

Та сама дата запустила Офіс ЄС з питань ШІ всередині Європейської Комісії та зобовʼязала держави-члени призначити національні компетентні органи. Вправа «Штрафи та правозастосування Закону ЄС про ШІ» проводить через трирівневу структуру штрафів, щоб команди розуміли, який обовʼязок стоїть за яким фінансовим ризиком.

Що застосовується з 2 серпня 2026 року?

Це найближчий термін у календарі, і він найважчий. З 2 серпня 2026 року застосовуються обовʼязки для систем високого ризику, перелічених у Додатку III, а більшість решти положень регламенту стають обовʼязковими.

Додаток III охоплює вісім сфер, де ШІ є високого ризику за замовчуванням: біометрія, критична інфраструктура, освіта, працевлаштування, основні публічні та приватні послуги, правоохоронна діяльність, міграція й прикордонний контроль, а також відправлення правосуддя. Постачальники й впроваджувачі цих систем стикаються з найглибшими засобами контролю в Законі, від управління ризиками і керування даними до людського нагляду й моніторингу після виходу на ринок. Вправа «ШІ високого ризику: обовʼязки впроваджувача» перевіряє, чи готовий запуск за сімома напрямами, які аудитор перевірить першими.

Більшість підприємств є впроваджувачами кількох систем високого ризику і постачальниками кількох. Банк із моделлю кредитного скорингу, лікарня з інструментом тріажу і рекрутер, що відбирає резюме за допомогою ШІ, — усі вони в межах Додатка III, тож дата серпня 2026 року не є вузькою проблемою.

Що залишається на 2 серпня 2027 року?

Одна категорія виходить за межі 2026 року. Системи високого ризику, вбудовані як компоненти безпеки в продукти, що вже регулюються правом ЄС і перелічені в Додатку I, мають час до 2 серпня 2027 року.

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

Якщо ваш ШІ — це функція всередині регульованого фізичного продукту, ваша дата — 2027 рік. Для всього в Додатку III робочим терміном залишається 2 серпня 2026 року.

Чи застосовується Закон ЄС про ШІ до компаній поза межами ЄС?

Так, у багатьох випадках. Закон сягає постачальників і впроваджувачів, заснованих поза межами ЄС, коли вони виводять системи ШІ на ринок ЄС або коли результат роботи системи використовується в Союзі.

Постачальник програмного забезпечення зі США, що продає інструмент найму на основі ШІ європейським клієнтам, є постачальником у межах дії. Компанія зі штаб-квартирою поза Європою, чий ШІ генерує результати, які споживає філія в ЄС, може бути впроваджувачем у межах дії. Територіальне охоплення повторює екстериторіальну логіку, яка зробила GDPR світовим стандартом.

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

Як підготуватися до кожного терміну Закону ЄС про ШІ

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

Крок 1: Побудуйте реєстр систем ШІ. Перелічіть кожну систему ШІ, яку ваша організація створює або використовує, хто нею володіє і яких даних вона торкається. Вправа «Управління ШІ у вашій організації» показує, як побудувати реєстр і зупинити тіньовий ШІ, перш ніж він потрапить у поле зору регулятора.

Крок 2: Класифікуйте кожну систему за рівнем ризику. Розподіліть кожен запис реєстру на заборонений, високий, обмежений чи мінімальний ризик. Рівень визначає, які обовʼязки застосовуються, а наш посібник з категорій ризику Закону ЄС про ШІ пояснює, як зробити кожне рішення.

Крок 3: Проведіть навчання з грамотності ШІ для всього персоналу. Стаття 4 уже обовʼязкова до виконання, тож це найдешевший перший крок до загальної готовності. Навчіть загальний персонал безпечному щоденному використанню, а технічним і наглядовим ролям дайте глибші модулі.

Крок 4: Призначте людський нагляд і обробку інцидентів. Назвіть людей, відповідальних за нагляд за системами високого ризику, і визначте, як персонал звітує про збої ШІ. Вправи «Звітування про інциденти ШІ» і «Відповідальне використання інструментів ШІ на роботі» відпрацьовують обидві процедури.

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

Закон про ШІ рідко приходить сам. Організаціям ЄС зазвичай доводиться узгоджувати його з GDPR, NIS2 та іншими рамками одночасно, і навчальний контент перетинається більше, ніж очікує більшість команд.

Рамка	Обовʼязок, повʼязаний із навчанням	Перетин із Законом про ШІ
GDPR (ЄС 2016/679)	Законна обробка, права субʼєктів даних, реагування на витоки	Керування даними, системи ШІ, що обробляють персональні дані
NIS2 (ЄС 2022/2555)	Управління кіберризиками, звітування про інциденти, навчання керівництва	Обробка інцидентів, управління, ланцюг постачання
Закон ЄС про ШІ (ЄС 2024/1689)	Грамотність ШІ, класифікація ризиків, людський нагляд	Основний набір обовʼязків

Програма навчання працівників за GDPR уже охоплює роботу з даними, від якої залежать системи ШІ високого ризику. Програма навчання за NIS2 охоплює процедури звітування про інциденти, які Закон про ШІ використовує повторно. Організації, що будують одну програму обізнаності, узгоджену через рамки, витрачають значно менше за тих, хто проводить паралельні навчання, — про цю модель ми розповідаємо в посібнику з навчання для відповідності.

Як RansomLeak підтримує готовність до Закону ЄС про ШІ

Навчання RansomLeak інтерактивне, на основі сценаріїв і задокументоване у спосіб, який наглядові органи впізнають. Окремий курс із Закону ЄС про ШІ охоплює регламент, поетапний графік, чотири рівні ризику й щоденні практики, яких очікує Стаття 4, а кожен модуль експортується у SCORM для LMS, яку перевірятиме орган.

Каталог приватності та відповідності містить повний курс із Закону ЄС про ШІ поряд зі сценаріями GDPR. Каталог безпеки ШІ охоплює інʼєкції в підказки, дипфейки й маніпуляції з LLM, які проблема тіньового ШІ вводить у сферу дії. Рольові треки створюють відкалібровану, задокументовану грамотність, якої прямо вимагає регламент.

Якщо хочете побачити, як навчання на основі сценаріїв накладається на кожен термін Закону про ШІ, замовте демонстрацію з нашою командою.

Поширені запитання

Коли Закон ЄС про ШІ застосовується повністю?

Регламент набрав чинності 1 серпня 2024 року й застосовується поетапно. Заборонені практики і грамотність ШІ застосовуються з 2 лютого 2025 року, правила щодо ШІ загального призначення — з 2 серпня 2025 року, а обовʼязки для систем високого ризику з Додатка III — з 2 серпня 2026 року. Системи високого ризику, вбудовані в регульовані продукти за Додатком I, мають час до 2 серпня 2027 року. Повне застосування досягається саме на цю останню дату.

Який термін Закону ЄС про ШІ найтерміновіший зараз?

Для більшості організацій це 2 серпня 2026 року, коли застосовуються обовʼязки для систем високого ризику з Додатка III, а більшість решти положень стають обовʼязковими. Банки, лікарні, рекрутери й оператори публічних послуг, що використовують ШІ в цих сферах, стикаються з найглибшими засобами контролю в Законі на цю дату. Обовʼязок щодо грамотності ШІ за Статтею 4 уже діє, тож він має бути в роботі вже зараз.

Якими є штрафи за пропущений термін Закону ЄС про ШІ?

Стаття 99 встановлює три рівні. Порушення заборонених практик сягають до €35 мільйонів або 7% глобального річного обороту. Більшість інших обовʼязків, зокрема грамотність ШІ, прозорість і обовʼязки впроваджувача, сягають до €15 мільйонів або 3%. Надання оманливої інформації органам сягає до €7,5 мільйона або 1,5%. Малі та середні підприємства сплачують меншу з двох величин, а не більшу.

Чи застосовується Закон ЄС про ШІ до малого бізнесу?

Так. Обовʼязки застосовуються залежно від ролі, яку ви відіграєте, і рівня ризику ваших систем ШІ, а не від розміру компанії. Малі та середні підприємства й стартапи отримують пропорційне ставлення, зокрема нижній край діапазонів штрафів і спрощену технічну документацію, але обовʼязок щодо грамотності ШІ за Статтею 4 застосовується незалежно від чисельності персоналу.

Як забезпечується виконання Закону ЄС про ШІ?

Правозастосування здійснюється через національні компетентні органи в кожній державі-члені та Офіс ЄС з питань ШІ всередині Європейської Комісії. Офіс наглядає за ШІ загального призначення безпосередньо й координує Європейську раду зі штучного інтелекту. Національні органи здійснюють ринковий нагляд, можуть запитувати документацію і накладати штрафи за Статтею 99.

Що нам зробити першим, щоб підготуватися?

Побудуйте реєстр кожної системи ШІ, яку ви використовуєте або створюєте, класифікуйте кожну за рівнем ризику й почніть навчання з грамотності ШІ для всього персоналу. Обовʼязок щодо грамотності вже діє і створює документацію, яка живить глибші обовʼязки, що настають у 2026 і 2027 роках. Наш посібник з категорій ризику Закону ЄС про ШІ пояснює, як класифікувати кожну систему.

Підсумок

Закон ЄС про ШІ — це поетапний регламент, і ставлення до нього як до єдиного майбутнього терміну — найшвидший спосіб відстати. Два етапи вже обовʼязкові, режим високого ризику настає 2 серпня 2026 року, а останні системи, вбудовані в продукти, настають у 2027 році.

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

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

Джерела

Категорії ризику Закону ЄС про ШІ: 4 рівні

Wed, 03 Jun 2026 00:00:00 GMT

Закон ЄС про ШІ не ставиться до кожної системи однаково. Він побудований на основі ризику, тож обовʼязки для спам-фільтра геть не схожі на обовʼязки для інструмента відбору резюме чи моделі кредитного скорингу.

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

Якими є категорії ризику Закону ЄС про ШІ?

Закон ЄС про ШІ розподіляє кожну систему ШІ на чотири категорії ризику: неприйнятний ризик (заборонено повністю), високий ризик (суворо регульований), обмежений ризик (обовʼязки щодо прозорості) і мінімальний ризик (без додаткових правил). Категорія визначає, які обовʼязки застосовуються. Більшість повсякденних бізнес-інструментів потрапляють до обмеженого чи мінімального ризику, але рівень треба перевіряти для кожного впровадження.

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

Рівень ризику	Що означає	Приклади	Основний обовʼязок
Неприйнятний	Заборонено за Статтею 5	Соціальний скоринг, нецільовий збір облич, розпізнавання емоцій на роботі	Не можна виводити на ринок
Високий	Суворо регульований (Додаток III і Додаток I)	Відбір резюме, кредитний скоринг, медичний тріаж, біометрична ідентифікація	Управління ризиками, керування даними, людський нагляд, FRIA
Обмежений	Обовʼязки щодо прозорості (Стаття 50)	Чат-боти, дипфейки, розпізнавання емоцій	Розкрити взаємодію з ШІ та синтетичний контент
Мінімальний	Без додаткових обовʼязків	Спам-фільтри, ШІ в іграх, прогнозування запасів	Лише грамотність ШІ за Статтею 4

Якими є неприйнятні (заборонені) практики ШІ?

Системи неприйнятного ризику заборонено повністю. Стаття 5 перелічує вісім категорій практик ШІ, які взагалі не можна виводити на ринок ЄС чи вводити в експлуатацію, бо ризик для основних прав визнано надто високим, щоб керувати ним засобами контролю.

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

Цей рівень несе найвищий штраф у регламенті — до €35 мільйонів або 7% глобального річного обороту. Розпізнати заборонене використання, перш ніж продукт вийде, — це навичка для команд закупівель і продукту, і саме її тренує вправа «Заборонені практики ШІ».

Що вважається системою ШІ високого ризику?

Системи високого ризику дозволені, але лише за найсуворіших засобів контролю в Законі. Система є високого ризику, якщо вона зʼявляється в Додатку III або є компонентом безпеки продукту, що вже регулюється правом ЄС у Додатку I.

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

Більшість організацій є впроваджувачами кількох систем високого ризику, навіть не усвідомлюючи цього. Вправа «ШІ високого ризику: обовʼязки впроваджувача» проводить через сім напрямів відповідності, які вирішують, чи готовий запуск високого ризику, чи його слід заблокувати.

Які обовʼязки застосовуються до систем ШІ високого ризику?

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

Людський нагляд є центральним. Стаття 14 вимагає, щоб системи високого ризику були спроєктовані так, аби людина могла розуміти, відстежувати й перевизначати їх, і вправа «Значущий людський нагляд» відпрацьовує перевизначення рекомендації ШІ, коли докази не збігаються. Керування даними важить не менше, бо упереджений чи дірявий набір для навчання дає невідповідну систему, і цей ризик унаочнює вправа «Керування даними для ШІ».

Два додаткові обовʼязки застосовуються до окремих впроваджувачів. Публічні органи й деякі оператори високого ризику мають провести Оцінку впливу на основні права перед першим використанням, що охоплює вправа «Оцінка впливу на основні права (FRIA)». А оскільки дискримінація — часта причина збоїв, вправа «Упередженість і дискримінація в ШІ» показує, як проксі-змінні ховаються всередині моделі відбору резюме.

Якими є системи ШІ обмеженого ризику?

Системи обмеженого ризику підпадають під обовʼязки щодо прозорості, а не під повний режим високого ризику. Тут стурбованість у тому, що люди мають знати, коли мають справу зі ШІ або з контентом, згенерованим ШІ.

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

Правильне виконання цих розкриттів — це радше операційне завдання, ніж юридичне. Вправа «Прозорість і розкриття ШІ» тренує команди правильно позначати чат-боти й синтетичні медіа за Статтею 50.

Що таке ШІ мінімального ризику?

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

Єдиний обовʼязок, що все ж застосовується, — це вимога щодо грамотності ШІ за Статтею 4, яка сягає кожного постачальника й впроваджувача незалежно від рівня. Персонал, що користується навіть інструментами мінімального ризику, має розуміти, що система може і чого не може.

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

Як класифікувати рівень ризику системи ШІ?

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

Працюйте згори вниз по рівнях, і перший збіг визначає класифікацію:

Чи заборонено використання за Статтею 5? Якщо так, це неприйнятний ризик, і воно не може продовжуватися.
Чи зʼявляється воно в Додатку III або входить до регульованого продукту за Додатком I? Якщо так, це високий ризик.
Чи спрацьовують обовʼязки щодо прозорості за Статтею 50, як-от чат-бот чи дипфейк? Якщо так, це обмежений ризик.
Усе, що залишається, є мінімальним ризиком.

Вправа «Класифікація ризиків ШІ» проводить реальні впровадження саме через цей процес сортування, і це найкорисніша навичка для будь-кого, хто будує реєстр ШІ. Про терміни, привʼязані до кожного рівня, дивіться наш посібник із графіка Закону ЄС про ШІ.

Хто класифікує ризик: постачальник чи впроваджувач?

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

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

Більшість підприємств є впроваджувачами багатьох систем і постачальниками кількох. Визначення ролі для кожної системи — частина побудови обороноздатного реєстру ШІ, і про це ми розповідаємо в посібнику із графіка Закону ЄС про ШІ.

Закон про ШІ і GDPR застосовуються одночасно, і система ШІ високого ризику, що обробляє персональні дані, має задовольняти обидва. Категорія ризику за Законом про ШІ не замінює ваші обовʼязки щодо захисту даних; вона лягає поверх них.

Система високого ризику, що профілює людей, часто запускає Оцінку впливу на захист даних за GDPR поряд з Оцінкою впливу на основні права за Законом про ШІ. Законна підстава, мінімізація даних і права субʼєктів даних усе ще застосовуються. Вправа «ШІ та захист даних» проводить медичний ШІ через обидва режими одночасно, щоб команди побачили, де обовʼязки збігаються, а де відрізняються.

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

Як RansomLeak навчає класифікації ризиків Закону ЄС про ШІ

RansomLeak перетворює рамку на основі ризику на рольові сценарії, а не на набори слайдів. Окремий курс із Закону ЄС про ШІ охоплює всі чотири рівні, процес класифікації й обовʼязки, привʼязані до кожного рівня, а кожен модуль експортується у SCORM для LMS, яку перевірятиме аудитор.

Каталог приватності та відповідності містить повний курс із Закону ЄС про ШІ поряд зі сценаріями GDPR, а каталог безпеки ШІ охоплює інʼєкції в підказки, дипфейки й ризики LLM, що перетинаються з OWASP LLM Top 10. Для розбору регламенту від початку до кінця наш посібник із навчання за Законом ЄС про ШІ накладає кожен обовʼязок на конкретну вправу.

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

Поширені запитання

Якими є чотири рівні ризику Закону ЄС про ШІ?

Закон ЄС про ШІ визначає чотири рівні ризику: неприйнятний ризик (заборонені системи за Статтею 5), високий ризик (суворо регульовані системи в Додатку III і Додатку I), обмежений ризик (системи з обовʼязками щодо прозорості за Статтею 50, як-от чат-боти й дипфейки) і мінімальний ризик (усе інше, без обовʼязків понад грамотність ШІ за Статтею 4). Рівень визначає, які обовʼязки застосовуються.

Який приклад системи ШІ високого ризику?

Поширені приклади високого ризику охоплюють ШІ для відбору кандидатів на роботу, оцінки кредитоспроможності, підтримки медичного тріажу чи біометричної ідентифікації. Вони зʼявляються в Додатку III, бо ухвалюють або підтримують рішення, що впливають на засоби до існування, безпеку чи основні права людей. ШІ, що використовується як компонент безпеки в регульованому продукті, як-от медичний виріб, також є високого ризику.

Які практики ШІ заборонені Законом ЄС про ШІ?

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

Хто вирішує категорію ризику системи ШІ?

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

Чи може категорія ризику Закону ЄС про ШІ змінюватися?

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

Що буде, якщо неправильно класифікувати систему високого ризику?

Ставлення до системи високого ризику як до обмеженого чи мінімального ризику означає пропуск засобів контролю, яких вимагає Закон, а це невідповідність. Штрафи за порушення більшості обовʼязків сягають до €15 мільйонів або 3% глобального річного обороту, а порушення заборони за Статтею 5 сягає €35 мільйонів або 7%. Точна класифікація — це і є засіб контролю, що запобігає обом.

Підсумок

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

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

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

Джерела

Кібербезпека віддаленої роботи: практичний посібник

Wed, 03 Jun 2026 00:00:00 GMT

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

Цей зсув змінив, де починаються витоки. Експлуатація вразливостей була початковим вектором доступу в 20% витоків минулого року, зі стрибком на 34%, причому зловмисники зосереджувалися на VPN і пристроях периметра, за даними Verizon 2025 Data Breach Investigations Report. Незакритий маршрутизатор та постійно ввімкнений VPN більше не є винятковими випадками.

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

Що таке кібербезпека віддаленої роботи?

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

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

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

Чому віддалена робота розширює поверхню атаки?

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

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

Зловмисники розуміють цю прогалину. Вони націлюються на технології, що відкривають віддалений доступ, тому VPN-пристрої та домашні маршрутизатори так часто стають першим плацдармом. Verizon 2025 DBIR виявив, що людський фактор задіяний приблизно в 60% витоків, і це число тримається стабільно, бо умови, що його породжують, не покращилися.

Якими є найбільші ризики безпеки віддаленої роботи?

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

Домашня мережа — невідома територія

Більшість людей не уявляють, що ще підключено до їхнього домашнього Wi-Fi, чи отримує маршрутизатор досі оновлення, чи змінювали колись пароль адміністратора за замовчуванням. Скомпрометований маршрутизатор може перехоплювати трафік ще до того, як запуститься VPN.

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

VPN створює оманливу впевненість

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

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

Незакриті пристрої запрошують відомі експлойти

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

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

Особисті телефони несуть робочий доступ

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

Bluetooth розкриває більше, ніж звук

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

Права адміністратора множать шкоду

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

Як захистити домашню мережу для роботи?

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

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

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

Що має охоплювати навчання кібербезпеці віддаленої роботи?

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

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

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

Поширені запитання

Який найбільший ризик кібербезпеки для віддалених працівників?

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

Чи робить VPN віддалену роботу безпечною?

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

Як часто віддалені працівники мають оновлювати пристрої?

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

Чи є використання особистих пристроїв ризиком для віддаленої роботи?

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

Що має бути в політиці безпеки віддаленої роботи?

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

Чим навчання безпеці віддаленої роботи відрізняється від офісного?

Офісне навчання може припускати кероване, моніторингове середовище з ІТ-підтримкою поруч. Віддалене не може. Воно має навчити працівників захищати власну мережу, оновлювати власні пристрої та перевіряти підозрілі запити без колеги для поради. Зміст зміщується від «дотримуйтесь офісних правил» до усвідомлення, що працівник тепер сам є периметром.

Підсумок

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

Зі зростанням експлуатації вразливостей на 34% як точки входу та середньою вартістю витоку 4,44 млн доларів США (IBM Cost of a Data Breach Report 2025) домашній офіс варто захищати належно. Коротка сценарна практика — це засіб контролю, що масштабується на розподілену команду.

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

Джерела

Сім принципів захисту даних GDPR на практиці

Wed, 03 Jun 2026 00:00:00 GMT

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

Розрив має значення, бо саме на принципах ґрунтується правозастосування. Сукупні штрафи за GDPR перевищили 7,1 млрд євро з травня 2018 року, за даними DLA Piper GDPR Fines and Data Breach Survey (January 2026). Більшість цих штрафів сягають корінням до порушеного принципу: дані зберігали надто довго, збирали без потреби або обробляли без правової підстави.

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

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

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

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

Якими є сім принципів і як команди їх порушують?

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

Принцип	Що вимагає	Поширений провал
Законність, справедливість, прозорість	Дійсна правова підстава, без прихованої обробки	Обʼєднана згода, темні патерни
Обмеження мети	Використання даних лише із заявленою метою	Перепрофілювання маркетингових даних
Мінімізація даних	Збирати лише потрібне	Надто широкі форми, поля «про всяк випадок»
Точність	Тримати дані правильними та актуальними	Застарілі записи, відсутність виправлення
Обмеження зберігання	Видаляти дані, коли мета вичерпана	Безстрокове зберігання, відсутність видалення
Цілісність і конфіденційність	Захищати дані належними засобами	Слабкі сеанси, незакриті вразливості, надмірний обмін
Підзвітність	Доводити відповідність записами	Відсутність документації та плану реагування

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

Законність, справедливість і прозорість

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

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

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

Обмеження мети

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

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

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

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

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

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

Що таке захист даних за задумом та за замовчуванням?

Захист даних за задумом та за замовчуванням (privacy by design) — це вимога статті 25 вбудовувати захист даних у системи від самого початку, а не прикручувати його пізніше. За замовчуванням мають діяти найбільш захисні налаштування, які застосовуються без жодних дій користувача.

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

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

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

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

Як принцип безпеки виявляється в щоденній роботі?

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

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

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

Як права субʼєктів даних повʼязані з принципами?

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

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

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

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

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

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

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

Поширені запитання

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

Яка різниця між мінімізацією даних та обмеженням зберігання?

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

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

Штрафи залежать від того, яке положення порушено. Порушення базових принципів статті 5 належать до вищого рівня, зі штрафами до 20 млн євро або 4% світового річного обороту, залежно від того, що більше. Порушення нижчого рівня тягнуть штрафи до 10 млн євро або 2% обороту. Регулятори також можуть наказати припинити обробку.

Чим підзвітність відрізняється від інших принципів?

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

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

Підсумок

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

Сукупні штрафи понад 7,1 млрд євро та середня вартість витоку 4,44 млн доларів США (IBM Cost of a Data Breach Report 2025) роблять цю арифметику важко ігнорувати. Навчання, що повʼязує кожен принцип із щоденним рішенням за ним, є найдешевшим засобом контролю, який ви маєте.

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

Джерела

Ціни на навчання з кібербезпеки (2026)

Mon, 11 May 2026 00:00:00 GMT

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

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

Хочете спершу побачити контент? Каталог вправ із кібербезпекової обізнаності має 200+ інтерактивних сценаріїв, доступних безкоштовно без реєстрації.

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

Скільки коштує навчання з кібербезпекової обізнаності на одного користувача?

Публічна ціна за місце у категорії потрапляє у три смуги. SMB та freemium-плани коштують $0–$12 за користувача на рік. Mid-market-плани — $15–$30 за користувача на рік.

Enterprise-плани коштують $30–$50 за користувача на рік, зі знижками при більшій кількості місць і довших термінах контрактів.

Ці діапазони підтверджуються відгуками на G2, цінниками вендорів там, де вони існують, та опублікованими post-mortem закупівель. Gartner Magic Quadrant for Security Awareness Computer-Based Training 2024 кваліфікує вартість понад $40 за користувача на рік як premium-positioned. Звіт Verizon Data Breach Investigations Report 2024 ставить людський фактор на 68% інцидентів, і саме це створює тиск для покупки.

KnowBe4 публікує тарифні рівні (Silver, Gold, Platinum, Diamond) із калькулятором пропозиції на сайті, але кінцева ціна залежить від кількості місць і тривалості контракту. Hoxhunt, SoSafe, Living Security, CybSafe та Proofpoint Security Awareness — усі quote-only.

Wizer має безкоштовний baseline із платними рівнями від низького боку SMB-смуги. 200+ інтерактивних вправ RansomLeak безкоштовні без реєстрації, а платні розгортання котируються за кількістю місць і обсягом функцій.

Для організацій до 500 місць очікуйте початкові річні контракти у діапазоні $5,000–$15,000. Для 500–5,000 місць — $15,000–$100,000. Для 5,000+ місць типові кастомні річні контракти $50,000–$500,000, перед фі за впровадження та add-on-модулями.

Чому більшість вендорів приховує ціни?

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

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

Конкурентна розвідка працює в обидва боки. KnowBe4 підвищує ціни на enterprise-ренеуелах вище за SMB-прайс, а Hoxhunt продає з премією до своїх публічних відгуків. Прайс-сторінка заморозила б цю гнучкість.

Результат — асиметрична інформація на користь продавця. Три покупці ідентичних платформ, ідентичної кількості місць і ідентичного набору функцій можуть платити у 2–3 рази різні ставки залежно від переговорів, терміновості та квартального плану AE. Закупівельні команди, які бенчмаркують через G2, профільні Slack-групи та конкурентні пропозиції, зазвичай отримують 25–40% знижки від першої усної ціни.

Якщо потрібна детальна паралельна порівняльна стаття для одного вендора, порівняння RansomLeak vs KnowBe4 проходить конкретні функції та різниці у цінах. Для широкого огляду ринку найкраще навчання кібербезпекової обізнаності 2026 охоплює вісім платформ із публічними діапазонами цін, де вони доступні.

Які фактори визначають ціну навчання з обізнаності?

Шість змінних пояснюють більшість варіацій між пропозиціями за однакову кількість співробітників.

Кількість місць і рівень. Ціна за користувача зазвичай падає на 15–30% між порогами 500 і 5,000 місць. Понад 10,000 місць — ще 10–20% знижки. Менші організації платять верхній бік прайс-листа.

Тривалість контракту. Річні контракти йдуть за одною ставкою; дворічні та трирічні забезпечують додаткові 10–20% знижки. Багаторічні умови також фіксують вендора проти підвищень за місце на ренеуелі, які у категорії в середньому становлять 8–15% на рік.

Глибина контенту. Базові пакети включають основні модулі з фішингу та обізнаності. Доплати (deepfake-навчання, GDPR-детальні пакети, рольовий контент, кастомно-брендовані сценарії, exec-таргетовані модулі) піднімають ставку за користувача на 30–100%. Вправа за реальним інцидентом MGM Resorts — приклад контенту на базі реального кейсу, який зазвичай продається як premium-модуль; RansomLeak віддає його в базовому каталозі.

Каденс фішингових симуляцій. Щомісячні симуляції — стандарт. Щотижневі кампанії та continuous-engines (флагман Hoxhunt) піднімають ціну. SANS Security Awareness Reports рекомендують принаймні щомісячні точки контакту, тож від цього функціоналу рідко відмовляються.

Інтеграції та SSO. SAML SSO, SCIM-провіжнінг, конектори Microsoft 365 та Slack-інтеграції іноді ховаються за enterprise-тарифом. Mid-market-плани без SSO обходяться дорожче у роботі ІТ, ніж заощаджують на ліцензії.

Модель підтримки. Self-service-підтримка входить у вартість. Виділений Customer Success Manager (CSM) додається на enterprise-рівні та виноситься окремо нижче. CSM-кероване розгортання скорочує time-to-value, але додає 10–25% до контракту.

Як порівняти безкоштовний, mid-market та enterprise рівні?

Тарифікація у категорії послідовніша, ніж здається з заголовкових цифр. Ось що насправді дає кожна смуга.

Безкоштовно і SMB ($0–$12 за користувача на рік). Тут Wizer, безкоштовний phishing test від KnowBe4 та кілька freemium-інструментів. Очікуйте стартову бібліотеку контенту, базові фішингові тести без справжньої автоматизації та self-service-підтримку. Підходить командам до 100 співробітників без аудиторських зобовʼязань.

Стаття безкоштовне навчання кібербезпекової обізнаності розбирає 12 безкоштовних варіантів за якістю контенту.

Mid-market ($15–$30 за користувача на рік). Повні бібліотеки контенту, щомісячні фішингові симуляції, аналітика завершень та SCORM-експорт. Сюди потрапляють KnowBe4 Silver, SoSafe Standard, NINJIO та стандартний рівень RansomLeak. Підходить командам від 100 до 2,000 співробітників із квартальною звітністю на рівні борда.

Enterprise ($30–$50+ за користувача на рік). Виділений CSM, SSO і SCIM, кастомний контент, AI-загрозні модулі, зокрема тренування MFA fatigue-атаки та deepfake-реагування, а також роле-орієнтовані шляхи. Тут KnowBe4 Platinum і Diamond, флагманський рівень Hoxhunt, SoSafe Premium, Proofpoint Security Awareness та enterprise-пакет RansomLeak.

Підходить регульованим галузям, мультирегіональним розгортанням і організаціям з аудиторськими зобовʼязаннями за SOC 2, ISO 27001, HIPAA, PCI DSS чи NIS2.

Об’ємні знижки понад 5,000 місць переформатовують математику. Контракт на 10,000 місць часто потрапляє у верхній бік mid-market-ставки за користувача, а не у заголовкову enterprise-ставку. Сила закупівельних переговорів важить так само, як вибір рівня.

Скільки насправді бере кожен вендор?

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

Вендор	Опубліковані ціни	Про що повідомляють покупці
KnowBe4	Рівні (Silver, Gold, Platinum, Diamond) з калькулятором	Приблизно $1,50–3,25 за користувача на місяць на річних умовах
Cofense	Стартова ціна через листинги реселерів	Від приблизно $10 за місце на рік
Wizer	Безкоштовний рівень і платні тарифи опубліковані	Платні плани до $2 за користувача на місяць
CanIPhish	Безкоштовний рівень плюс оплата за використання	Оплата за обсягом, найнижчий поріг входу в категорії
NINJIO	Лише за запитом	Річні контракти за користувача, mid-market діапазон
Hoxhunt	Лише за запитом	Преміальний діапазон серед чистих HRM-вендорів
SoSafe	Лише за запитом	Mid-market та enterprise, річні контракти
CybSafe	Лише за запитом	Преміальний діапазон, корпоративні контракти
Proofpoint Security Awareness	Лише за запитом	Зазвичай узгоджується в межах ширшого пакета
Living Security	Лише за запитом	Enterprise, орієнтація на Fortune 1000
MetaCompliance	Лише за запитом	Mid-market та enterprise, фокус на Великій Британії та ЄС
Huntress (Curricula)	Лише за запитом	За місце в пакеті через канал MSP
usecure	Лише за запитом	За місце через MSP-партнерів, SMB-діапазон
Phished	Лише за запитом	Mid-market та enterprise, річні контракти
RansomLeak	Повний каталог вправ безкоштовний, без реєстрації	Ціна за запитом за кількістю місць і обсягом функцій

Скільки коштує KnowBe4?

KnowBe4 — єдиний великий вендор, який відкрито публікує структуру рівнів. Публічні відгуки та матеріали про закупівлі ставлять ефективну ставку приблизно у $1,50–3,25 за користувача на місяць, тобто близько $18–39 за користувача на рік на річних умовах.

Silver покриває навчання та фішинг-симуляції. Gold додає щомісячний контент і ширшу звітність. Platinum і Diamond додають розширені функції, включно з інструментами навколо PhishER та AI Defense Agents. Понад кілька тисяч місць кількість місць і тривалість контракту впливають на суму більше, ніж вибір рівня.

Чому Hoxhunt і NINJIO виглядають дешевшими або дорожчими, ніж є

Hoxhunt перебуває у преміальному діапазоні, але покриває фішинг, а не весь обовʼязок з навчання. Команди, яким потрібен ще й комплаєнс-контент, купують другу платформу, і сумарна цифра часто перевищує вартість одного ширшого вендора. NINJIO коштує у mid-market діапазоні за коротке відео: дешево за модуль і дорого за зміну поведінки, якщо ваша справжня проблема не в проходженні.

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

Які приховані витрати очікувати поза ліцензією за місце?

Ліцензія за користувача — це заголовкова цифра, а не повна вартість.

Впровадження та онбординг. Більшість enterprise-розгортань містить плату за setup $2,500–$25,000, залежно від складності платформи, обсягу SSO-інтеграції та кастомізації контенту. Деякі вендори списують її при багаторічному контракті; інші виставляють окремою professional-services-лінією.

Add-on-модулі. Бібліотеки фішингових симуляцій, compliance-курси (GDPR, навчання з HIPAA, ширші пакети навчання з відповідності) та AI-загрозний контент зазвичай ідуть як окремі SKU. Платформа з прайсом $20 за користувача на рік може опинитися на $35 після додавання AI-модуля та compliance-пакету.

Розробка кастомного контенту. Брендовані сценарії, контент для топ-менеджменту та галузеві модулі зазвичай коштують $5,000–$50,000 за одиницю. Вправа з шахрайства з рахунками — приклад контенту для фінансових команд, який заслуговує місця у зрілих програмах; побудова еквівалентного кастомного контенту виходить у пʼятизначні суми.

Преміум-підтримка. Цілодобова підтримка, іменний CSM та квартальні бізнес-огляди зазвичай входять у enterprise-рівень, але виносяться окремо на mid-market-цінах.

Ескалація на ренеуелі. Підвищення на 8–15% щорічно на ренеуелі — звичайна справа. Багаторічні контракти обмежують це. Однорічні залишають покупця відкритим.

Втрата продуктивності від поганого контенту. Це найбільша прихована вартість, яку більшість покупців ігнорує. IBM 2024 Cost of a Data Breach Report ставить середню глобальну вартість інциденту на рівні $4.88 мільйона. Програма навчання, яка не змінює поведінку, залишає цей ризик на столі. Найдешевша ліцензія — не найдешевша програма.

Для технічних команд, які потребують навчання з патчингу ендпоінтів і EDR-алертів, переконайтеся, що роле-орієнтований контент входить у пакет, а не виставляється як custom-development-доплата. Це часта пастка на mid-market-рівні.

Як оцінити загальну вартість навчання з обізнаності у 2026

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

Порахуйте місця. Активні співробітники плюс підрядники з доступом до корпоративної пошти. Округліть угору.
Виберіть рівень. Зіставте свої compliance-зобовʼязання (SOC 2, ISO 27001, HIPAA, NIS2) та потреби у звітності зі смугою SMB, mid-market чи enterprise.
Визначте потрібні add-on. Каденс фішингових симуляцій, AI-загрозний контент, кастомний брендинг, роле-орієнтовані шляхи, compliance-курси.
Оцініть впровадження. Додайте 10–20% від ліцензії першого року на setup, SSO-інтеграцію та кастомізацію контенту.
Спрогнозуйте ренеуели. Додайте 10% на рік на другий і третій роки. Закладіть багаторічний кеп, щоб згладити це.

Для mid-market-розгортання на 1,000 місць математика типово виглядає так: $22 за користувача × 1,000 місць = $22,000 ліцензії, плюс $5,000 впровадження, плюс $10,000 за AI-модуль. Загальна вартість першого року: $37,000. Тримічна без капу на ескалацію: $122,000.

Чим ціноутворення RansomLeak відрізняється від конкурентів?

Навчання RansomLeak інтерактивно-симуляційне, а не «відео плюс квіз». Це міняє рівняння вартості у три способи.

Повний каталог із 200+ вправ працює без реєстрації, тож покупці оцінюють контент до дзвінка, а не після. Це скорочує цикл оцінки на тижні.

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

SCORM-експорт входить у mid-market і вище. Організації з наявним LMS (Cornerstone, Workday Learning, SuccessFactors, Moodle) розгортають контент RansomLeak як SCORM-пакети та не платять за хмарні функції, якими не користуватимуться.

Часті запитання

Скільки коштує навчання з обізнаності на одного користувача на рік?

Публічна ціна за місце потрапляє у три смуги: SMB та freemium $0–$12, mid-market $15–$30 та enterprise $30–$50+ за користувача на рік. Знижки застосовуються при більшій кількості місць і довших термінах контрактів.

Чому KnowBe4, Hoxhunt і SoSafe приховують свої ціни?

Enterprise-вендори ведуть quote-only-продажі, бо публічний прайс зменшує розмір угоди та позбавляє переговорної гнучкості. Три покупці ідентичних платформ можуть платити у 2–3 рази різні ставки залежно від сили закупівельної команди. Покупці, які бенчмаркують через G2, профільні групи та конкурентні пропозиції, зазвичай отримують 25–40% знижки від першої усної ціни.

Чи існує безкоштовне навчання з обізнаності, яке справді працює?

Так. Wizer пропонує безкоштовний baseline-рівень для малих команд, а 200+ інтерактивних вправ RansomLeak доступні без реєстрації і відображають той же контент, який отримують платні клієнти. Маркетингові безкоштовні інструменти від великих вендорів (наприклад, KnowBe4 Phishing Test) — це лід-магніти, а не повноцінні навчальні програми.

Яка чесна ціна для enterprise-навчання з обізнаності?

Для 1,000–5,000 місць чесний загальний річний контракт у діапазоні $15,000–$75,000, залежно від add-on та тривалості. Для 5,000+ місць очікуйте $50,000–$500,000 з багаторічними умовами. Усе, що понад $50 за користувача на рік для розгортання на 5,000 місць, переоцінено, якщо вендор не постачає кастомний контент.

Скільки коштує впровадження навчання з обізнаності?

Фі за впровадження $2,500–$25,000 для enterprise-розгортань, залежно від складності SSO-інтеграції, кастомізації контенту та кількості локалей. Деякі вендори списують його при багаторічному контракті; інші виставляють окремо. Уточніть письмово до підписання.

Як уникнути підвищень цін на ренеуелі?

Зафіксуйте багаторічний контракт із капом ренеуела 5% або менше. Однорічні контракти — найдорожча форма SAT, бо вендори підвищують ціни на 8–15% щорічно. Трирічні контракти з 5%-капом зазвичай заощаджують 15–25% порівняно з трьома однорічними ренеуелами.

Чи змінює SCORM-експорт цінову математику?

Так. SCORM-пакетований контент дозволяє організаціям із наявним LMS (Cornerstone, Workday Learning, SuccessFactors, Moodle, Docebo) не платити за хмарні функції вендора, якими не користуватимуться. RansomLeak, SoSafe, NINJIO, CybSafe, Living Security та MetaCompliance підтримують SCORM; Hoxhunt — ні.

Який найдешевший спосіб запустити програму обізнаності?

Поєднайте безкоштовний baseline (Wizer чи безкоштовний каталог RansomLeak) з платним phishing-simulation-інструментом на перші пів року. Виміряйте показники кліків, повідомлень і time-to-report. Використайте ці дані, щоб укласти платний контракт з позиції доказів, а не здогадок.

Оминіть демо-марафон

Пройдіть вправу самостійно до будь-якої розмови. Бібліотека вправ відкрита, безкоштовна, і займає 5–10 хвилин на сценарій.

Для письмової пропозиції звʼяжіться з командою із кількістю місць і compliance-вимогами. Цифру повернемо протягом одного робочого дня.

HIPAA §164.308(a)(5): навчання та аудити OCR

Sat, 25 Apr 2026 00:00:00 GMT

Навчання з обізнаності HIPAA є обовʼязковим адміністративним заходом захисту (Administrative Safeguard) за HIPAA Security Rule. Кожна охоплена організація (covered entity) і кожен бізнес-партнер (business associate) мають проводити програму навчання для всіх членів свого персоналу, включно з керівництвом, і документація повинна витримувати аудити OCR, які можуть вибірково перевіряти записи за останні шість років.

Сам текст правила короткий. Очікування навколо нього аж ніяк. Охоплені організації, які ставляться до навчання HIPAA як до пʼятнадцятихвилинного щорічного відео, зазвичай дізнаються про це тяжко, найчастіше під час розслідування витоку або через Resolution Agreement, що коштує шестизначних чи семизначних сум.

Повний розбір рамки §164.308(a)(5) дивіться в нашому рамковому посібнику з навчання з безпекової обізнаності HIPAA. Ця стаття зосереджена на тому, що інспектори OCR справді вибірково перевіряють під час аудиту.

Що HIPAA вимагає від навчання з обізнаності

HIPAA Security Rule у 45 CFR §164.308(a)(5) перелічує «Security Awareness and Training» як стандарт серед адміністративних заходів захисту. Текст правила вимагає, щоб охоплені організації «впроваджували програму обізнаності та навчання з безпеки для всіх членів свого персоналу, включно з керівництвом».

Цей стандарт із восьми слів підкріплений чотирма імплементаційними специфікаціями, усі з яких класифіковано як «addressable» (адресовані), а не «required» (обовʼязкові). Адресоване не означає необовʼязкове. Це означає, що субʼєкт має або впровадити специфікацію, або впровадити еквівалентну альтернативу, або задокументувати, чому специфікація не є розумною й доречною в його середовищі, та задокументувати розумну альтернативу.

На практиці OCR (Office for Civil Rights) і більшість аудиторів очікують, що всі чотири специфікації будуть впроваджені у тій чи іншій формі. Заявити, що специфікація не є розумною й доречною, можливо, але це рідко приймається без додаткового обґрунтування.

Privacy Rule у 45 CFR §164.530(b) додає паралельний обовʼязок щодо навчання на стороні приватності: навчання щодо політик і процедур приватності для кожного члена персоналу, з навчанням щодо нових або змінених політик у розумний час після зміни. Навчання за Privacy Rule є «required», а не «addressable».

Бізнес-партнери (business associates) повʼязані тим самим обовʼязком навчання за Security Rule через §164.308 і через сам Business Associate Agreement (BAA).

4 стовпи навчання HIPAA

За §164.308(a)(5) чотири імплементаційні специфікації визначають, що повинна охоплювати програма навчання. Кожна мапується на конкретні модулі, які можна тренувати.

Security Reminders (§164.308(a)(5)(ii)(A))

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

Protection from Malicious Software (§164.308(a)(5)(ii)(B))

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

Log-in Monitoring (§164.308(a)(5)(ii)(C))

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

Password Management (§164.308(a)(5)(ii)(D))

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

Окрім цих чотирьох стовпів, керівні матеріали OCR і ресурси HHS послідовно додають теми, які Security Rule прямо не називає: розпізнавання інцидентів, терміни звітування про витоки, стандарт мінімально необхідного (minimum necessary), безпека мобільних пристроїв і безпека робочих місць за §164.310.

Навчання HIPAA для різних ролей

Поняття «персонал» (workforce) визначене широко у 45 CFR §160.103. Воно включає працівників, волонтерів, стажистів та будь-яких інших осіб, чия поведінка під час виконання роботи для охопленої організації знаходиться під прямим контролем субʼєкта, незалежно від того, чи їм платять.

Клінічний персонал потребує навчання найвищої частоти, бо він постійно має доступ до PHI (захищеної медичної інформації). Сценарії повинні охоплювати обробку запитань пацієнтів, спілкування з членами родини, уникання розмов у коридорах, безпечні повідомлення в системах EHR і розпізнавання спроб соціальної інженерії, спрямованих на сестринські пости.

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

ІТ та персонал безпеки потребує додаткової глибини щодо контролю доступу, перегляду журналів аудиту, реагування на інциденти зі шкідливим ПЗ і технічних заходів захисту за §164.312. Вони часто першими помічають інциденти безпеки, що запускають таймери Breach Notification Rule.

Бізнес-партнери (Business Associates) мають навчати власний персонал щодо обовʼязків BAA, обробки PHI та повідомлень про інциденти назад до охопленої організації. Багато охоплених організацій тепер вимагають доказів навчання BA як частину перевірки постачальника.

Штрафи HIPAA за неналежне навчання

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

Рівень	Провина	Мін. за порушення	Макс. за порушення	Річне обмеження на категорію
1	Розумна ретельність (не знав)	приблизно $137	приблизно $68 928	приблизно $2,07 млн
2	Розумна причина	приблизно $1 379	приблизно $68 928	приблизно $2,07 млн
3	Свідома недбалість, виправлено	приблизно $13 785	приблизно $68 928	приблизно $2,07 млн
4	Свідома недбалість, не виправлено	приблизно $68 928	приблизно $2,07 млн	приблизно $2,07 млн

Точні цифри щорічно змінюються з інфляцією. Перевіряйте поточне повідомлення у Federal Register для актуальних значень.

Окрім штрафів за порушення, OCR часто укладає Resolution Agreements, що вимагають багаторічних Corrective Action Plans, моніторингу третьою стороною та конкретних виправлень у навчанні. Генеральні прокурори штатів також мають незалежні повноваження щодо правозастосування HIPAA за HITECH і їх застосовували.

Breach Notification Rule у 45 CFR §§164.400-414 додає репутаційну вартість. Витоки, що зачіпають 500 або більше осіб, публікуються на «стіні ганьби» HHS і запускають медіа-сповіщення у відповідному штаті.

Як часто має проводитися навчання HIPAA?

Security Rule описує навчання як «періодичне», не визначаючи каденцію. Privacy Rule конкретніший: навчання щодо нових або змінених політик у розумний час після зміни.

Галузева практика та керівні матеріали OCR збігаються щодо такої каденції:

Нові співробітники мають отримувати навчання до того, як вони матимуть доступ до PHI, а не через тижні
Щорічне оновлення є широко прийнятою базою для всіх членів персоналу
Тригери зміни політики вимагають цільового навчання при оновленні політик
Постінцидентне навчання має слідувати за значними інцидентами, особливо успішними фішинговими або ransomware-подіями
Тригери зміни ролі вимагають перенавчання, коли члени персоналу беруть на себе нові обовʼязки з обробки PHI

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

Вимоги до документації навчання HIPAA

Security Rule у §164.530(j) вимагає, щоб охоплені організації зберігали документацію протягом шести років від дати створення або дати останньої чинності, залежно від того, що пізніше. Записи про навчання прямо входять у сферу дії.

Записи, що зазвичай витримують перевірку OCR, включають:

Імена та ролі членів персоналу, які пройшли кожне навчання
Дату завершення та дату будь-яких оновлень
Поданий зміст, включно з номерами версій і будь-якими оновленнями
Оцінки оцінювань там, де вони застосовні
Підписані підтвердження політик там, де це необхідно
Записи про усунення для членів персоналу, які не склали оцінювання

Дашборди зручні, але недостатні. Запити OCR на вибірки регулярно вимагають вихідних записів, а не зведеного перегляду.

Навчання щодо фішингу та програм-вимагачів у сфері охорони здоровʼя

Сфера охорони здоровʼя була найбільш атакованим сектором програм-вимагачів у США протягом кількох років поспіль. Дані Програми кібербезпеки HHS і звіти OCR про витоки послідовно показують, що зломи й ІТ-інциденти є провідною причиною великих витоків.

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

Видавання себе за медичних постачальників під час міграцій EHR
Підроблені портали пацієнтів і листи скидання пароля порталу
Підроблені дзвінки з верифікації страхування, що збирають інформацію про пацієнтів
Програми-вимагачі, доставлені через сторонніх постачальників циклу доходів
Атаки vishing проти сестринських постів і служб ІТ-підтримки

Програма навчання, специфічна для сфери охорони здоровʼя, повинна проводити сценарії, взяті з реальних інцидентів у секторі. Наш каталог обізнаності з безпеки охоплює фішинг, vishing, smishing та шахрайство з технічною підтримкою у занурювальних 3D-вправах, які члени персоналу проходять за десять-пʼятнадцять хвилин кожна.

Навчання BAA та управління постачальниками

За §164.308(b) і §164.504(e) охоплені організації повинні мати Business Associate Agreement з кожним бізнес-партнером, який створює, отримує, зберігає або передає PHI. BA несе пряму відповідальність за порушення Security Rule згідно з Omnibus Rule 2013 року.

Ефективне управління постачальниками тепер включає перевірку щодо навчання. Перед укладенням BAA охоплені організації повинні переконатися, що бізнес-партнер має задокументовану програму навчання, що члени персоналу, які обробляють PHI, пройшли навчання, і що навчання щодо повідомлення про інциденти є на місці, аби BA міг дотриматися терміну повідомлення за §164.410 назад до охопленої організації.

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

Як RansomLeak охоплює навчання HIPAA

Навчання RansomLeak базується на сценаріях і документується на рівні, який запитують аудитори OCR. Каталог охоплює як стовпи Security Rule, так і теми Privacy Rule, а записи про проходження експортуються, щоб задовольнити правило шестирічного зберігання за §164.530(j).

Каталог приватності й відповідності охоплює обробку даних, реагування на інциденти та сценарії доступу пацієнтів, суміжні з DSAR. Каталог обізнаності з безпеки охоплює фішинг, розпізнавання шкідливого ПЗ, гігієну паролів і моніторинг входу так, щоб мапуватися на чотири специфікації Security Rule.

Наш посібник з мапування відповідності повʼязує кожну вимогу §164.308 і §164.310 із конкретними вправами, що її охоплюють, тож офіцери з безпеки HIPAA можуть подати аудитору документ простежуваності, а не стос PDF-файлів.

Часті запитання

Чи є навчання HIPAA обовʼязковим?

Так. 45 CFR §164.308(a)(5) вимагає програми обізнаності та навчання з безпеки для всіх членів персоналу. 45 CFR §164.530(b) окремо вимагає навчання з приватності. Обидва положення стосуються охоплених організацій, а §164.308 поширюється на бізнес-партнерів через BAA.

Як довго слід зберігати записи про навчання HIPAA?

Шість років від дати створення або дати останньої чинності запису, залежно від того, що пізніше. Правило знаходиться у 45 CFR §164.530(j) для приватності та §164.316(b)(2)(i) для документації з безпеки.

Чи стосується навчання HIPAA волонтерів і підрядників?

Так. Поняття «персонал» за 45 CFR §160.103 включає працівників, волонтерів, стажистів та інших осіб, чия поведінка знаходиться під прямим контролем субʼєкта, незалежно від того, чи їм платять. Якщо вони можуть мати доступ до PHI, вони у сфері дії.

Як часто потрібне навчання HIPAA?

Security Rule вимагає «періодичного» навчання. Щорічне оновлення є прийнятою базою. Навчання також запускається при зміні політик (Privacy Rule), коли члени персоналу беруть на себе нові ролі та після інцидентів безпеки, що виявляють прогалини у навчанні.

Які штрафи за провал навчання членів персоналу?

Цивільні грошові штрафи OCR коливаються приблизно від $137 до понад $68 928 за порушення з річними обмеженнями близько $2,07 млн на категорію, скоригованими щорічно на інфляцію. Свідома недбалість, що не виправлена, тягне за собою найвищі штрафи. Генеральні прокурори штатів мають паралельні повноваження.

Чи потрібно бізнес-партнерам навчати свій персонал?

Так. Бізнес-партнери несуть пряму відповідальність за Omnibus Rule 2013 року щодо обовʼязків Security Rule, включно з навчанням персоналу. BAA повинен визначати очікування щодо навчання та терміни повідомлення про інциденти.

Які теми має охоплювати навчання HIPAA?

Як мінімум, чотири специфікації §164.308(a)(5): нагадування з безпеки, захист від шкідливого ПЗ, моніторинг входу та управління паролями. Більшість програм також охоплює розпізнавання інцидентів, терміни звітування про витоки, стандарт мінімально необхідного та безпеку робочого місця.

Чи можна проводити навчання HIPAA онлайн?

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

Як навчання HIPAA взаємодіє з законами штатів про приватність?

Деякі закони штатів накладають додаткові обовʼязки щодо навчання, особливо Каліфорнія (CCPA/CPRA), Техас (HB 300) і Нью-Йорк (SHIELD Act). Програма HIPAA зазвичай покриває вимогу HIPAA, але може потребувати доповнень для специфічних для штату прав доступу пацієнтів і термінів повідомлення про витоки.

Що має бути у записі про проходження навчання HIPAA?

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

Підсумок

Навчання з обізнаності HIPAA є адміністративним заходом захисту, з яким взаємодіє майже кожен член персоналу. Це також той захід, який найчастіше недодають, через що Resolution Agreements OCR так часто включають коригувальні плани, повʼязані з навчанням.

Будуйте програму навколо чотирьох специфікацій §164.308(a)(5), документуйте на рівні, який буде вибірково перевіряти OCR, налаштовуйте зміст за ролями та проводьте її частіше за раз на рік. Організації охорони здоровʼя, що ставляться до навчання серйозно, знижують свою частоту витоків, а коли витоки все ж стаються, вони, як правило, потрапляють до нижчих штрафних рівнів OCR, а не до смуг свідомої недбалості.

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