Шифрування і захист ключів: чи дає шифрування звільнення від повідомлень про інцидент безпеки за GDPR і CRA
Шифрування є одним із найосновніших технічних заходів, які впроваджуються розробниками в продукт. Проте навіть за наявності шифрування та захисту ключів може статись інцидент безпеки або витік персональних даних, через що виникатимуть певні зобов’язання із повідомлення за GDPR і CRA. У цій статті детально розберемо суть цих обов’язків щодо повідомлення регулюючих органів та як імплементація шифрування та захисту ключів впливає на необхідність звітування.
GDPR та обов’язок повідомлення: умови та винятки
Перед тим, як вживати певних заходів для усунення витоку даних, контролер повинен спершу визначити, чи дійсно цей інцидент є витоком персональних даних. GDPR у статті 4(12) визначає витік персональних даних як “порушення безпеки, що призводить до випадкового або незаконного знищення, втрати, зміни, несанкціонованого розголошення або доступу до персональних даних, які передаються, зберігаються або іншим чином обробляються”.
Витік даних є видом інциденту безпеки.
GDPR встановлює два обов’язки щодо повідомлення для контролера у випадку витоку персональних даних: повідомлення наглядового органу (стаття 33) та повідомлення суб’єктів даних (стаття 34).
Повідомлення наглядового органу
Щодо повідомлення наглядового органу, то існує лише один випадок, коли зобов’язання за статтею 33 не буде застосовуватись до контролера – порушення, які навряд чи становитимуть загрозу для прав і свобод фізичних осіб. Гайдлайни Європейської ради захисту даних 9/2022 вказують, що порушення конфіденційності персональних даних, які були зашифровані за допомогою найсучаснішого (state of art) алгоритму, все одно є порушенням конфіденційності персональних даних і про нього необхідно повідомити. Однак якщо конфіденційність ключа збережена, тобто ключ не був скомпрометований і був згенерований таким чином, що його неможливо встановити за допомогою доступних технічних засобів будь-якою неавторизованою особою, то дані самі по собі є нерозбірливими (unintelligible).
Отже, якщо персональні дані стали нерозбірливими для сторонніх осіб і якщо ці дані є копією або існує їх резервна копія, про порушення конфіденційності, пов’язане з належним чином зашифрованими персональними даними не потрібно повідомляти наглядовий орган.
Це є наслідком того, що таке порушення навряд чи становитиме ризик для прав і свобод фізичних осіб. Проте, якщо ключ шифрування згодом буде скомпрометований або буде виявлена вразливість у шифруванні, тоді повідомлення буде обов’язковим для контролера.
Повідомлення суб’єктів даних
У певних випадках, окрім повідомлення наглядового органу, контролер також зобов’язаний повідомити про порушення фізичних осіб, яких зачепив витік персональних даних. У GDPR зазначено, що повідомлення суб’єктів даних про витік має відбуватися без невиправданої затримки, тобто якомога швидше.
Стаття 34(3) GDPR передбачає три винятки, коли повідомляти суб’єктів даних не вимагається:
- Контролер вжив відповідних технічних та організаційних заходів захисту, і ці заходи були застосовані до персональних даних, яких стосується витік, зокрема такі заходи, що роблять персональні дані нерозбірливими (наприклад через шифрування) для будь-якої неавторизованої особи.
- Контролер вжив подальших заходів, які гарантують, що високий ризик для прав і свобод суб’єктів даних більше не може матеріалізуватись.
- Повідомлення вимагало б непропорційних зусиль від контролера. У такому випадку має бути опубліковано повідомлення або вжито аналогічний захід, за допомогою якого суб’єкти даних будуть проінформовані не менш ефективним чином.
Отже, GDPR прямо вказує на те, що у випадку зашифрованих даних, повідомлення суб’єктів даних є необов’язковим. Проте варто пам’ятати, що навіть якщо спочатку повідомлення може й не вимагатись, коли немає ризику для прав і свобод фізичних осіб, проте з часом ситуація може змінитися, і ризик доведеться переоцінити. Якщо наглядовий орган визначить, що рішення контролера не повідомляти суб’єктів даних є необґрунтованим, він може розглянути можливість застосування наявних у нього повноважень та санкцій.
Cyber Resilience Act та його вимоги
CRA передбачає як вимоги щодо повідомлення наглядових органів у разі виявлення активних вразливостей або серйозного інциденту, так і основні вимоги кібербезпеки (essential cybersecurity requirements), які містять положення щодо шифрування в Додатку І.
Вони передбачають, що продукти з цифровими елементами повинні бути задизайновані, розроблені та вироблені таким чином, щоб, зокрема, забезпечувати конфіденційність даних (в тому числі і персональних та інших), які зберігаються, передаються або іншим чином обробляються, наприклад шляхом шифрування відповідних даних за допомогою найсучасніших механізмів, а також шляхом використання інших технічних засобів. Також шифрування допоможе забезпечити відповідність із вимогою повідомлення про пошкодження даних та забезпечення цілісності збережених, переданих або іншим чином оброблених даних від будь-яких несанкціонованих маніпуляцій або змін, не санкціонованих користувачем. Потрібно пам’ятати і про те, що девайси, призначені для захищеної криптообробки є критичними продуктами з цифровими елементами, що встановлює додаткові вимоги щодо сертифікації таких продуктів.
З 11 вересня 2026 року виробники продуктів з цифровими елементами зобов’язані повідомляти про вразливості, які активно експлуатуються, та серйозні інциденти, що впливають на безпеку продуктів з цифровими елементами.
| Виробники повинні подати попереднє повідомлення протягом 24 годин з моменту виявлення вразливості, а повне повідомлення – протягом 72 годин. Фінальний звіт має бути поданий не пізніше ніж через 14 днів після появи коригувальних заходів щодо активних вразливостей та протягом місяця з моменту подання 72-годинного повідомлення щодо серйозних інцидентів. |
Згідно зі статтею 24(3) CRA, обов’язки з повідомлення також поширюються на open-source стюардів з 11 грудня 2027 року. Звіти надсилаються до ENISA (Європейської агенції з кібербезпеки) та до CSIRT, призначеної координатором, через єдиний пункт прийому, а не шляхом окремого подання до кожного національного органу. Цим пунктом прийому є Єдина платформа для подання звітів, яку ENISA створює, керує та підтримує відповідно до статті 16.
Хоча CRA й передбачає обов’язок виробників продуктів з цифровими елементами захищати конфіденційність та цілісність даних, що обробляються, в тому числі персональних, через такі заходи як шифрування, проте обов’язок повідомлення не передбачає жодних винятків. Звісно, шифрування може бути одним із запобіжників виявлення активної вразливості або виникнення серйозного інциденту, проте за наявності однієї з цих двох подій повідомлення є обов’язковим і не залежить від шифрування. CRA передбачає жорсткі санкції за недотримання основних вимог кібербезпеки (в тому числі вимог, що передбачають шифрування як технічний захід) та обов’язків щодо повідомлення, а саме штраф розміром до 15 000 000 євро або 2.5% від світового обороту підприємства в залежності від більшої суми. Порушення положень про сертифікацію девайсів для криптообробки, які є критичними продуктами з цифровими елементами, тягне за собою штраф розміром до 10 000 000 євро або 2% від світового обороту.
Чеклист із практичними рекомендаціями
У випадку інциденту безпеки важливо мати алгоритм певних дій для визначення точного кола обов’язків за GDPR та CRA. Нижче ми наводимо приклад такого чеклисту, який допоможе зорієнтуватись у природі, ризиках та особливостях інциденту безпеки.
| ☐ Ви дізнались про інцидент безпеки, а також про те, чи стосується він персональних даних та чи є він витоком персональних даних в розумінні GDPR. ☐ Ви підтвердили, що шифрування було сучасним (state of art), надійним та правильно імплементованим. ☐ Ви визначили, чи був ключ шифрування скомпрометований і зловмисники не могли встановити його через наявні технічні засоби. ☐ Ви встановили, чи були втрачені персональні дані, чи є їх резервна копія, чи можливо їх відновити. ☐ Ви оцінили ризики, що несе витік персональних даних через оцінку виду витоку даних, природу, чутливість, обсяг персональних даних, легкість ідентифікації суб’єктів даних, їх число, специфіку контролера та самих суб’єктів даних. ☐ Ви прийняли рішення щодо повідомлення наглядового органу. У випадку сумнівів, варто повідомити наглядовий орган про витік. Також Ви визначили відповідний наглядовий орган для повідомлення та спосіб повідомлення. ☐ Ви визначили, чи є інцидент безпеки виявленням активно експлуатованої вразливості або серйозним інцидентом за CRA. ☐ В залежності від виду інциденту, Ви подали звіт відповідно до встановлених дедлайнів (24 години для раннього попередження, 72 години для повідомлення та 14 днів/1 місяць для фінального звіту) до ENISA та відповідного CSIRT через платформу SRP. |
Висновки
Обидва акти передбачають жорсткі зобов’язання контролерів даних та виробників продуктів з цифровими елементами щодо повідомлення про інциденти безпеки різних видів.
У контексті GDPR контролери повинні ретельно зважити якість і надійність впровадженого шифрування, зрозуміти, який рівень захисту воно насправді забезпечує, та чи він відповідає наявним ризикам. Контролери також повинні бути обізнані з особливостями функціонування свого засобу шифрування. Коли все ж стався витік даних, необхідно визначити, чи є цей інцидент власне витоком, та оцінити ризики для суб’єктів даних із можливістю переоцінки в майбутньому.
Щодо Cyber Resilience Act, шифрування не звільняє від обов’язку повідомляти про активні вразливості та серйозні інциденти, проте воно є важливим (а також обов’язковим!) елементом мінімізації ризиків кібербезпеки, що може запобігти інцидентам у майбутньому.
