Комплаєнс 152-ФЗ: де ламається захист персональних даних
Типова перевірка комплаєнсу 152-ФЗ починається не з документів, а з інфраструктури — і там знаходиться одне й те саме. Журнали доступу пишуться, але без термінів зберігання і без захисту від редагування: запис можна змінити або видалити, а довести, хто і коли читав базу, нічим. Права на бази видані широким групам — «на час», «для налагодження» — і залишаються діяти роками.
Резервні копії лежать у тому ж сховищі, що й робочі дані, часто без шифрування, а ключі шифрування даних — поруч із самими даними: відновлення зручне, але шифрування перестає щось захищати. Будь-який витік даних у такій схемі не розслідується — підтвердити, чи хтось читав копію, нічим.
Причина зазвичай одна: інфраструктура зростає швидше, ніж політики. Доступ видається під задачу і не відкликається, журнали вмикаються без ротації, копії складаються туди, де швидше, а ключі — туди, де простіше дістати під час аварії. Розмежування доступу і захист персональних даних залишаються на рівні усних домовленостей.
Перевіряють не наявність регламенту, а відтворюваність: чи доводиться незмінність журналу за потрібний період, чи відновлюється копія без доступу до робочого контуру, чи відкликається доступ того дня, коли співробітник іде.
Розбираємо, як це закривається — від рольової моделі та шифрування до термінів зберігання і контролю ключів.
Що дає вибудуваний контур захисту даних на практиці
Відповідність 152-ФЗ — це не папка з політиками, а властивості інфраструктури, які перевіряються в цифрах. Нижче — що саме змінюється, коли контур захисту даних зібрано.
Шифрування: де закривається канал витоку
Дані шифруються в трьох станах: на диску, в резервних копіях і в каналі між сервісами.
Ключі зберігаються в окремому сховищі з ротацією, доступ до них отримують сервіси за ролями, а не люди — частка даних під шифруванням доводиться до 100%, і копія бази, що опинилася не там, де потрібно, залишається марним набором блоків.
Логування: з чого збирається доказова база
Події доступу, зміни прав і операції з персональними даними пишуться в незмінний журнал: суб'єкт, час, об'єкт, результат.
Термін зберігання журналів задається політикою, а не тим, чи чистив хтось диск вручну, — вибірка за конкретною людиною або періодом збирається за хвилини, а обсяг журналів зростає передбачувано.
Контроль доступу описується ролями і підтверджується регулярною звіркою: звіт про те, у кого які права, збирається за години замість тижнів ручного обходу систем.
Відновлення після збою йде за перевіреним сценарієм — час повернення сервісу вимірюється десятками хвилин, а клас відмов «резервна копія є, але не відновлюється» зникає після навчань на окремому контурі.
Режими шифрування та зберігання: порівняння підходів
Вибір режиму шифрування визначає не стійкість алгоритму, а межу довіри: де лежить ключ і хто до нього допущений. Нижче — чотири варіанти, між якими обирають під час обробки персональних даних.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Шифрування на стороні застосунку | Дані йдуть у зовнішнє сховище або спільну базу | Ключ живе в сервісі: помилка в коді розкриває дані, пошук за полями ускладнюється |
| Шифрування диска | Захист носія та резервних копій | Поки система працює, читання прозоре — рубежем залишаються права й журнали |
| Виділене сховище ключів | Ротація, ролі та слід аудиту за кожною операцією | Виклик на шляху читання: недоступність сервісу ключів зупиняє обробку |
| Окремий контур для чутливих даних | Потрібна резидентність і вузьке коло адміністраторів | Два контури, два набори оновлень, окремі облікові записи |
Де зберігати ключі і хто ними керує
Ключі не тримають у репозиторії, змінних середовища і поруч із самими даними. Майстер-ключ лежить у виділеному сховищі, сервіс отримує короткоживучий ключ на час операції, ротація йде за розкладом, кожна видача потрапляє в журнал.
Права на управління ключами відокремлені від прав на обробку даних: інженер супроводу не може вивантажити майстер-ключ.
Розподіл даних за рівнями чутливості
Рівень чутливості задає режим шифрування, термін зберігання і коло доступу. Знеособлена аналітика залишається в загальному контурі, персональні дані — у шифрованих на стороні застосунку, а найчутливіші набори виносяться в окремий контур із резидентністю на потрібній території. Так режим посилюють точково, не перебудовуючи все сховище.
Впровадження комплаєнсу 152-ФЗ: етапи інженерної роботи
Порядок робіт вибудуваний так, що кожен крок спирається на попередній: без карти даних розмежування доступу і логування залишаються формальністю. Тому починаємо з інвентаризації, а закінчуємо перевіркою того, що заходи справді спрацьовують, а не лише описані в документах.
Інвентаризація: карта даних і потоків
Збираємо реєстр: які категорії персональних даних обробляються, в яких системах лежать, через які сервіси передаються, хто і на якій підставі має доступ.
Результат — схема потоків із точками запису, читання і вивантаження в зовнішні сервіси та із зазначенням термінів зберігання за кожним масивом.
- Інвентаризація даних і потоків — реєстр систем, категорій даних і точок передачі.
- Схема розміщення і шифрування — де дані лежать фізично, шифрування під час зберігання і в каналі, порядок роботи з ключами.
- Розмежування доступу — ролі за принципом мінімально необхідного, окремі сервісні облікові записи, відкликання доступу під час звільнення.
- Налаштування логування — події доступу до персональних даних в окреме сховище, захищене від редагування і видалення.
- Перевірка сценаріїв відновлення — навчальне розгортання з резервної копії на чистий контур; вартість розраховується після аудиту. Регламент реагування — хто, що і в який строк робить під час інциденту, кому і як повідомляє; передача документації вашій команді.
Перевірка: як переконуємося, що заходи працюють
Перевіряємо діями, а не паперами: запускаємо видалення даних конкретної людини і дивимося, що вони зникли в усіх системах; пробуємо отримати доступ поза виданою роллю і переконуємося, що відмову записано в журнал; розгортаємо копію і звіряємо цілісність. Сценарій, що не пройшов, означає, що захід ще не впроваджено.
Політики доступу, схеми шифрування і регламенти логування
Регламенти — це те, що залишається у замовника після впровадження: не налаштований сервер, а письмові процедури, за якими перевіряючий бачить, що доступ, шифрування і логування керуються, а не склалися стихійно.
Нижче — комплект артефактів, який ми передаємо в складі проєкту: кожен закриває свій пункт 152-ФЗ і GDPR.
Матриця доступу і службові облікові записи
- Матриця ролей і прав: хто зі співробітників і підрядників до яких систем і даних має доступ — з обґрунтуванням кожної ролі.
- Політика доступу: єдина точка входу, двофакторна автентифікація, мінімально необхідні права, порядок погодження і відкликання під час зміни ролі або звільнення.
- Службові облікові записи: для кожної — власник, призначення, строк життя, зберігання секрету в захищеному сховищі і заборона входу за паролем.
- Схема потоків персональних даних і політика зберігання ключів шифрування: де дані лежать, де обробляються, хто може використовувати ключ і з якою періодичністю він ротується.
Журнали: склад, терміни, захист від зміни
- Правила і терміни зберігання журналів: перелік подій, обов'язкових для запису, термін зберігання і порядок ротації.
- Захист від зміни: сховище лише на додавання, роздільні права на читання і запис, контроль цілісності, винесення журналів в окремий контур.
- Регламент відповіді на інцидент: виявлення, класифікація, терміни повідомлення регулятора і суб'єктів даних, розбір причин і виправлення прав доступу.
Комплект погоджуємо з вашим відділом інформаційної безпеки і приводимо до вигляду, придатного для внутрішнього аудиту.
Кейс: закрили зауваження аудиту щодо захисту персональних даних
Замовник — сервіс з персональними даними десятків тисяч користувачів. Перед плановою перевіркою регулятора внутрішній аудит знайшов розбіжність між політикою доступу і тим, як права видані на практиці.
Кейс впровадження починався з інвентаризації облікових записів, а не з купівлі нових засобів захисту.
Що було до: вузькі місця
Облікові записи заводилися вручну в різних системах, права накопичувалися разом зі зміною ролі: у частини адміністраторів повний доступ залишався після переходу в іншу команду.
Звіт щодо доступів збирали два тижні — вивантаження з кількох систем зводили в таблиці, і на момент погодження він частково застарівав.
Резервні копії шифрувалися не скрізь: частина копій з персональними даними лежала на спільному сховищі, доступ до якого був ширшим за коло допущених осіб. Журнали велись, але не зводилися в одне місце, тому відновити, хто читав конкретний запис, було неможливо.
Що стало після: вимірювані зрушення
Облікові записи перевели в Keycloak як єдине джерело ролей: права видаємо під роль і на строк, а не «на всякий випадок». Надлишкові права скоротили у 68% облікових записів, закриття доступу під час звільнення або переведення займає години замість тижнів.
Звіт щодо доступів збирається за 10 хвилин одним вивантаженням — видно, у кого які права і на якій підставі.
Захист резервних копій закрито шифруванням на стороні джерела, ключі винесені в окреме сховище, журнали доступу зведені в загальний контур із незмінним терміном зберігання.
Проходження перевірки — без зауважень щодо доступів і захисту копій; залишився плановий список покращень, який закриваємо за звичайним процесом супроводу.
Що робити, якщо інфраструктура вже розгорнута?
Перебудовувати працюючий контур повністю не потрібно: основна частина вимог 152-ФЗ закривається надбудовою.
Шифрування каналів і носіїв, розмежування ролей, логування операцій з персональними даними і регламент їх зберігання вмикаються поверх наявних сервісів, без переписування застосунків.
Поетапне впровадження починається з інвентаризації: де фізично лежать дані, які сервіси і зовнішні обміни до них звертаються, у кого є прямий доступ до СУБД і резервних копій.
Далі пріоритет за ризиком — спочатку ізолюються сховища з найбільшим обсягом записів і зовнішні інтеграції.
По частинах доведеться змінювати схему автентифікації, мережеву сегментацію і поводження з ключами. Тут допомагає перехідний період: новий контур піднімається поруч зі старим, сервіси переводяться групами, попередні облікові записи живуть до повного перенесення прав.
Секрети і ротацію ключів бере на себе HashiCorp Vault — сервіси отримують доступ через короткоживучі облікові дані замість статичних рядків підключення в конфігурації, і витік файлу налаштувань перестає відкривати базу.
Мінімізація змін досягається тим, що застосунки залишаються недоторканими: змінюється шар доступу, тому перехід іде без зупинки сервісів. Сесії не скидаються, права видаються групами, кожна зміна фіксується в журналі — аудитор бачить, хто, коли і до яких записів отримав доступ.
Технічні сумніви: шифрування, журнали, доступи
Перед стартом проєкту з 152-ФЗ виринають одні й ті самі питання: чи доведеться переписувати сервіси, де лежать ключі, що робити з даними поза периметром і як утримати відповідність під час змін. Нижче — відповіді, щоб ви звірили їх зі своєю архітектурою.
Чи доведеться переписувати сервіси?
Ні. Відповідність будується шарами навколо застосунку: шифрування сховища і каналу, розмежування доступу, логування. Переписувати логіку потрібно лише там, де персональні дані потрапляють у журнали або кеш у відкритому вигляді.
Хто володіє ключами?
Ключі залишаються у вашому контурі: ми налаштовуємо управління ними, але не стаємо володільцем. Ротація за розкладом і розподіл ролей — розшифрувати і видати доступ не може одна людина. Межі відповідальності фіксуємо письмово, включно з перевіркою підрядника.
Що робити з даними поза периметром?
Резервні копії, вивантаження, зовнішні інтеграції, робочі ноутбуки — найчастіша точка витоку. За кожною визначаємо: чи потрібна вона, чи можна знеособити дані, де вони лежать і коли видаляються.
Як утримати відповідність під час змін?
Відповідність — процес, а не разова перевірка. Інфраструктура описана конфігурацією, тому правила доступу, шифрування і терміни зберігання журналів застосовуються до нових сервісів автоматично, а зміни проходять перевірку до випуску.
Обговоримо задачу: що надіслати для оцінки контуру
Щоб повернутися з оцінкою робіт і планом впровадження, а не із загальними формулюваннями, потрібен мінімальний склад вихідних даних.
Чим точніші вхідні дані, тим менше припущень у кошторисі і реалістичніші терміни етапів: правки в середині проєкту коштують дорожче, ніж півгодини на розбір схеми на початку.
- Схема сервісів і потоків даних: де зберігаються записи, куди йдуть копії та вивантаження, чи є резервні майданчики і передача за межі контуру.
- Перелік оброблюваних даних і категорії суб'єктів: звичайні персональні, спеціальні категорії, знеособлені набори — від цього залежить обсяг шифрування і порядок роботи зі згодами.
- Поточні політики доступу і модель ролей: як видаються права, хто має розширені повноваження, чи залишилися спільні облікові записи без персональної відповідальності.
- Склад журналів: які події вже фіксуються, де лежать, скільки зберігаються і чи захищені від зміни заднім числом.
- Вимоги перевіряючих або внутрішнього аудиту: припис, перелік зауважень, опитувальний лист — під них вибудовуємо пріоритет етапів.
- Обмеження: регламентні вікна, заморожування релізів, вимоги щодо розміщення даних на території країни.
Повного пакета на старті не потрібно — надсилайте те, що є, включно з чернетками і вивантаженнями в довільному вигляді. Пропонуємо дзвінок щодо задачі: за розмову розберемо прогалини і домовимося, що дозібрати. За підсумками повернемося з оцінкою робіт, планом впровадження і термінами етапів.
