242-ФЗ виконати не можна обійти

виконати

виконати

242-фз

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

Дії в умовах невизначеності

Проблема — у широті та розпливчастості законодавства. «Поки що важко дати однозначну відповідь на питання компаній, чи локалізувати обробку даних в Україні, і чи можливо це зробити, — заявив Микола Феоктистов, партнер компанії „Уайт енд Кейс“. — Але, на нашу думку, треба зробити максимально можливе».

Одна з причин неясності в тому, що визначення таких понять, як персональні дані (ПД), їхня обробка та оператор персональних даних дуже широкі. Тому їх можна трактувати по-різному. За словами Миколи Феоктистова, на даний момент існує принаймні дві інтерпретації № 242-ФЗ – консервативна та ліберальна.

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

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

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

Незрозуміло й те, чи застосовується закон до операторів, які збирають ПД там. "Ми пропонуємо таку інтерпретацію: застосовується тільки до тих персональних даних, які збиралися в Україні", - повідомив Микола Феоктистов.

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

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

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

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

Практичні рекомендації

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

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

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

На етапі починається сама міграція даних. Щоб показати різні підходи, Дмитро Бірюков навів чотири приклади із практики PwC. Всі перелічені компанії є міжнародними, з них дві — це філії банків, один великий автовиробник, який працює з українськими контрагентами та одна філія великого виробника електроніки. Всі вони перенесли системи Active Directory та Exchange на свої сервери до України, а щодо інших систем діють по-різному.

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

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

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

Вимоги до оператора персональних даних

Наведені приклади показують, що прагнучи виконати вимоги № 242-ФЗ, іноземні компанії збираються переносити частину своїх інформаційних систем на власні сервери або місцевий дата-центр. Невипадково українські провайдери ІТ-послуг вже відзначають зростання попиту на серверні потужності.

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

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

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

Виходячи з типів загроз, компанія може визначити свій рівень захищеності (всього таких рівня чотири) та подумати про засоби захисту. За словами Григорія Атреп'єва, хмарна інфраструктура може бути побудована відповідно до вимог закону щодо розміщення ПД будь-якого рівня захищеності.

Щоправда, ПД із першим рівнем захищеності можуть бути розміщені лише в рамкахприватної хмари. «Але я поки не бачив в Україні жодної такої системи, оскільки всі намагаються привести свої ІС до нижчого рівня, — зазначив Григорій Атреп'єв. — Найбільш поширеними є рівні 2 та 3, які можна розміщувати у публічній хмарі».

На основі рівня захищеності, типу загроз та наявності підключення ІС до Інтернету можна визначити клас основних елементів ІС та засобів захисту відповідно до методології ФСТЕК, а також вибрати їх з реєстру сертифікованого ФСТЕК обладнання та ПЗ, допустимого для того чи іншого рівня захищеності.

Якщо компанія вирішить скористатися послугами аутсорсингу, важливо перевірити наявність у провайдерів послуг усіх ліцензій та сертифікатів. Григорій Атреп'єв уточнив, що мінімальний набір включає ліцензії ФСТЕК на діяльність з розробки та/або виробництва засобів захисту конфіденційності інформації та діяльність з технічного захисту конфіденційної інформації, а також ліцензію ФСБ на використання засобів криптографії.

Останній етап на цьому шляху – атестація систем персональних даних. Щоправда, для комерційних організацій це необов'язково. Але, за словами Григорія Атреп'єва, як правило, компанії проходять атестацію, оскільки це нескладно і дозволяє надалі спростити взаємини з регуляторами.