П’ять порівняно легальних способів опору ФЗ-152, Безпека ПЗ, Security & Hack, статті

Закон “Про персональні дані” (ФЗ-152) зараз є гарячою темою, оскільки він новий, жорсткий і недостатньо опрацьований. Деякі неоднозначності закону можуть трактуватися по-різному, тому компанії, які займаються інформаційною безпекою, часто закликають перестрахуватися. Їхнє бажання отримати більше грошей зрозуміло, проте невизначеності закону оператори персональних даних можуть трактувати і на свою користь.

Ми розглянемо в цій статті деякі невідповідності і намітимо шляхи їх використання для оптимізації витрат на захист персональних даних.


Спосіб перший – у семи няньок …


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


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


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


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


Спосіб другий – сам собі режисер


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


Спосіб третій – розділяй і володарюй


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


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


Спосіб четвертий – не типовий випадок


Дані можна розчленувати, але вже працюючу систему – не можна. У той же час всі російські CRM, ERP, бухгалтерії та кадрові системи проектувалися без урахування вимог закону ФЗ-152 і знеособлення даних. Я б не рекомендував перехід на іноземні системи, які в більшості своїй передбачають знеособлення – у них конвенція про захист персданних існує з 1981 року і її вимоги приймалися в розрахунок при проектуванні програмного забезпечення. Проте перехід на ці системи потребує часу і певних вкладень. Я ж пропоную використовувати інший метод – назвати такі системи спеціальними.


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


Спосіб п’ятий – моя хата з краю


У деяких випадках програма, яка обробляє персональні дані, взагалі нав’язано компанії з-поза. Наприклад, податкова інспекція може зажадати використовувати для зв’язку з нею і заповнення податкової декларації спеціального додатку. Або в деяких школах міністерство освіти вимагає використання для підготовки звітів спеціального програмного забезпечення. До таких програм також відносяться системи клієнт-банк (наприклад, для зв’язку з “Ощадбанком”) або системи СОРМ в операторів зв’язку.


Тут слід пам’ятати, що ІСПДн – це все-таки система, тобто за визначеннями ГОСТів комплекс з апаратного забезпечення, програми і навколишнього середовища. Якщо ви не можете контролювати, наприклад, програмне забезпечення, то і вся система є не вашою, а тієї компанії чи відомства, яке цю програму розробило. У той же час саме оператор, тобто власник системи, повинен піклуватися про захист оброблюваних в ІСПДн даних, а не ті компанії, на комп’ютерах яких вона встановлена.


Попередження:


Автор не несе відповідальності за те, що перевіряючі Роскомнадзора та інших відомств не прочитали цієї статті, не згодні з її положеннями або мають власну думку з описаним вище тем. Тому рекомендується звернутися до професійних консультантів, які більш коректно пропрацюють основні положення даної статті. До того ж якщо в компанію звернутися зі скаргою конкретна людина і зажадає знищення своїх персональних даних, то будь-яка компанія повинна знищити дані в триденний термін, незалежно від вимог СОРМ – ФЗ-152 має пріоритет над будь-якими вимогами підзаконних актів.


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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*