Обзор технической защиты персональных данных. Как соблюсти GDPR и ФЗ-152?

31 мая, 2020

Обзор технической защиты персональных данных. Как соблюсти GDPR и ФЗ-152?

В рамках GDPR Online Day 2020 бизнес-консультант по безопасности CISCO Алексей Лукацкий сделал обзор технической защиты персональных данных в GDPR и ФЗ-152. Как оказалось, между этими документами гораздо больше общего, чем многие полагают.

«В начале этого года мы проводили большое исследование по различным странам мира — это и Северная, и Южная Америка, Европа, страны бывшего постсоветского пространства, это Азиатский регион. И многие компании заявляют о том, что инвестиции в обеспечение privacy являются не безвозвратными, а могут приносить определённый доход для компании, ускорять сделки, снижать различные простои, снижать штрафы и так далее», — начал своё выступление Алексей Лукацкий.

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

 

Что требует обеспечения защиты персональных данных? 

В российском ФЗ-152 «О персональных данных» вопросу защиты посвящена только одна статья 19. В ней говорится, что операторы при обработке персональных данных обязаны принимать необходимые правовые, организационные и технические меры, а дальше эти самые меры расписаны. Однако, по словам эксперта, в российском законодательстве из понятия «защита персональных данных» часто убирают понятие «защита прав субъектов персональных данных». «К сожалению, это в лишний раз говорит о том, как у нас в России часто относятся к правам субъектов в части их прав на честную обработку их персональных данных», — прокомментировал этот момент Алексей Лукацкий.

В то же время в GDPR мы найдём похожее определение защиты персональных данных, как и в ФЗ-152. Единственное, что в европейском документе оно более размыто. Однако если сравнить статью 32 GDPR и статью 19 ФЗ-152, мы увидим примерно одинаковые меры защиты. «Наш закон ни слова не говорит о риск-ориентированном подходе в явной форме, хотя подзаконные акты говорят об этом. И мы выполняем защитные мероприятия исходя из той модели угроз, которую мы должны разработать для своих информационных систем персональных данных. В европейском регламенте явно указано, что у них риск-ориентированный подход, но при этом ниже, если мы будем опускаться на уровень различных иных документов, у нас очень многие вещи будут совпадать по своей идеологии», — пояснил эксперт.

Второе важное отличие, которое можно сразу увидеть, обратив внимание на формулировки, в том, что российский закон устанавливает требования только для операторов. Однако в одном из последующих изменений в ФЗ-152 была добавлена норма о том, что при получении на обработку персональных данных оператор обязан установить требования по защите из 19 статьи. То есть по сути, хоть это явно и не звучит в 19 статье, обработчики также должны выполнять требования по защите персональных данных. В то время как GDPR не делает разницы между оператором, обработчиком, контролёром и процессором.

 

Какие требования по защите мы должны реализовать? 

«Дальше, конечно, возникает вопрос, какие требования мы должны реализовать? Есть ли какой-то перечень мер, который мы выполним и сможем спать спокойно, считая, что при проверке ФСТЭК, ФСБ или какого-то иного национального регулятора мы сможем сказать, что выполнили всё, что было прописано, и к нам никаких претензий предъявлять нельзя?» — задал вопросы аудитории Алексей Лукацкий.

Здесь и российское законодательство, и законодательство многих стран СНГ, европейское законодательство схожи в своём подходе — они не говорят, что нужно сделать обязательно, а говорят лишь о необходимо принять соответствующие технические и организационные меры по защите, соответствующей той модели рисков, которую мы сами для себя выбрали с точки зрения процессов, связанных с обработкой персональных данных. В GDPR и ФЗ-152 есть уточнение списка защитных мер. Только в российском законодательстве оно более детальное и включает в себя 9 высокоуровневых защитных мер. Что это за меры?

  • Определение угроз безопасности персональных данных при их обработке в информационных системах персональных данных;
  • Применение организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных, необходимых для выполнения требований к защите персональных данных, исполнение которых обеспечивает установленные Правительством РФ уровни защищённости персональных данных;
  • Применение прошедших в установленном порядке процедуру оценки соответствия средств защиты информации; 
  • Оценка эффективности принимаемых мер по обеспечению безопасности персональных данных до ввода в эксплуатацию информационной системы персональных данных;
  • Учёт машинных носителей персональных данных;
  • Обнаружение фактов несанкционированного доступа к персональным данным и принятие мер;
  • Восстановление персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;
  • Установление правил доступа к персональным данным, обрабатываемым в информационной системе персональных данных, а также обеспечение регистрации и учёта всех действий, совершённых с персональными данными в информационной системе персональных данных;

Контроль за принимаемыми мерами по обеспечению безопасности персональных данных и уровнем защищённости информационных систем персональных данных.
 
А вот меры, прописанные в GDPR:

  • Псевдонимизация и шифрование персональных данных;
  • Способность обеспечить постоянную конфиденциальность, целостность, доступность и устойчивость систем и сервисов обработки;
  • Способность своевременно восстанавливать доступность и доступ к персональным данным в случае возникновения физического или технического инцидента;

 

Регулярное тестирование, оценка и измерение эффективности технических и организационных мер по обеспечению безопасности обработки.

«То, что в ФЗ-152 называется определением угроз, в GDPR можно назвать анализом рисков. Хотя угроза и риск — это немного разноуровневые понятия, но и там, и там мы говорим о вероятности наступления негативного события, которое влечёт за собой тот или иной ущерб либо для самих персональных данных, либо для субъектов персональных данных. Поэтому и там, и там мы поддерживаем риск-ориентированный подход», — пояснил Алексей Лукацкий.

 

Оценка соответствия 

В ФЗ-152 говорится, что средства защиты должны пройти оценку соответствия в установленном порядке. Однако её можно сделать своими силами, необязательно проводить сертификацию средств защиты. Сертификация нужна только для государственных и муниципальных структур. Во всех остальных случаях мы вольны сами определить форму оценки соответствия.

В GDPR про это не сказано, и европейские организации в рамках GDPR могут использовать любые решения по ИБ. Но уже ведутся разговоры о введении сертификации средств и аттестации систем, связанных и в том числе с обработкой персональных данных. Например, есть европейский Cybersecurity Act, который потихонечку начинает вводить понятие Certification Framework. Это может установить единые требования для всех стран, которые подчиняются или подпадают под требования GDPR, установить требования именно по сертификации средств защиты персональных данных, а также оценке качества защиты персональных данных. «В Европе только началось такое движение в эту сторону. Поэтому в перспективе горизонта 3-5 лет такие требования будут введены. Вначале они будут добровольными для производителей и для операторов и обработчиков. Ну а потом, возможно, сделают эти требования обязательными. Поэтому держите в голове, что не каждое решение в перспективе может применяться или сможет применяться в этой части, а только, как правило, крупные игроки, которые уже уделяют достаточно много внимания вопросам сертификации по другим сферам», — добавил Алексей Лукацкий.

 

Шифрование и обилие регуляторов

Если мы обратим внимание, то в российском законе, в 19 статье, нет ни слова про шифрование. В нашем законе вообще ни разу не упоминается термин «шифрование», в отличие от GDPR. Говорится только о конфиденциальности персональных данных, то есть условиях, при которых не распространяются персональные данные субъекта без его согласия. Поэтому конфиденциальность мы можем обеспечить различными способами, и шифрование — это только один из них.

В то же время мы видим в GDPR такой термин, как «псевдонимизация» (обезличивание). В России за эту тему отвечает Роскомнадзор. Именно он уполномочен разрабатывать те или иные требования по обезличиванию. «И вот в этом как раз серьёзное различие между Россией и иными странами. Во многих странах, которые подчиняются GDPR или имеют национальное законодательство по персональным данным, как правило, есть единый национальный регулятор в этой сфере. Это может быть DPA, некий инспектор, омбудсмен, комиссия, комиссар — они называются по-разному в разных странах, но это, как правило, один регулятор, который отвечает и за защиту персональных данных, и за защиту прав субъектов персональных данных. У нас, к сожалению, в России слишком много регуляторов, которые отвечают за различные аспекты, связанные с персональными данными», — рассказал Алексей Лукацкий.

Роскомнадзор, помимо того, что отвечает за защиту прав субъектов, с технической точки зрения устанавливает требования по обезличиванию данных. Правительство, например, в рамках 119 постановлений установило определённые требования по безопасности помещений, в которых ведётся обработка персональных данных. ФСТЭК тоже отвечает за защиту персональных данных. ФСБ традиционно отвечает за все вопросы, связанные с криптографией, в том числе в области персональных данных. МВД раньше часто привлекался Роскомнадзором для проверки сохранности персональных данных (то, что во многих европейских методических рекомендациях прописано одной строкой physical security, у нас этим занимался целый отдельный орган исполнительной власти). А, например, для финансовых организаций в России есть ещё один надзорный орган — Банк России, который уже разработал порядка трёх и планирует разработать ещё два указания, связанных с моделями угроз обработки персональных данных и биометрических персональных данных. При этом разработанные ЦБ модели угроз для финансовых организаций являются обязательными. То есть больше намоделировать угроз мы можем, но меньше, к сожалению, нет. Даже если мы в рамка своего бизнес-процесса считаем, что у нас нет каких-то угроз, о которых подумал ЦБ, мы всё равно должны с ними бороться.

«Вот это большое количество регуляторов, к сожалению, приводит к классической русской, ну или англоязычной (в зависимости от того, какой язык вам ближе), поговорке: «у семи нянек дитя без глаза» («too many cooks spoil the broth»)», — отметил Алексей Лукацкий. — «Действительно, у нас очень много регуляторов, между которыми существуют определённые конфликты, нестыковки, рассогласованность. И это, понятное дело, сказывается как на операторах персональных данных, которые не всегда знают, на чьи рекомендации или требования смотреть, так и на правах субъектов, чьи данные очень часто попадают в межведомственное взаимодействие, и как следствие никто не знает, кто должен отвечает на те или иные вопросы, которые поступают от субъекта, связанные именно с защитой его персональных данных».

 

4 измерения безопасности персональных данных 

Алексей Лукацкий выделяет четыре больших направления, которые должны быть реализованы в плане безопасности персональных данных. Первое — это безопасность самой инфраструктуры, которая обрабатывает и персональные данные, и многое другое. В организации есть не только конфиденциальная информация в виде персональных данных, но и налоговая тайна, коммерческая тайна и другие виды тайн. По оценкам Алексея Лукацкого, в российском законодательстве более 70 видов сведений, которые относятся к конфиденциальной информации. И не имеет смысла делать отдельны механизмы защиты для каждого вида тайн, когда как лучше иметь некую единую базовую инфраструктуру защиты.

Второе и третье направления — требования, механизмы и меры, которые привязаны непосредственно к самим данным.  Эксперт разделяет ИБ управления данными (обеспечение безопасного хранения данных и регистрация доступа к ним на всех этапах жизненного цикла данных) и Приложения (обеспечение безопасности персональных данных в различных приложениях). Потому что защита данных в рамках ИИ или машинного обучения отличается от защиты данных, которые обрабатываются в облаках, или на личных устройствах сотрудников компаний.

И четвёртый аспект — когда произошёл инцидент с персональными данными и надо выстроить процесс реагирования на него.

 

Что взять за основу? 

Ни GDPR, ни ФЗ-152 не говорят в деталях, какие защитные меры можно реализовать. Тогда есть два варианта: придумать их из головы или взять за основу какой-то существующий Framework, который посвящён либо именно защите персональных данных, либо защите в целом конфиденциальной информации, либо выстраиванию ИТ-инфраструктуры, где защита данных является элементом этой инфраструктуры. Всё зависит от того, какую роль специалист выполняете в компании и какие именно данные ему необходимо защищать.

В интернете существует немалое количество маппингов (mapping), когда требования одного документа маппируются с требованиями другого документа. Например, на финансовые организации, обрабатывающие данные платёжных карт, распространяются требования  PCI DSS. И тут нужно понимать, как требования PCI DSS, которые уже реализуются в организации, соотносятся с требованиями GDPR — в интернете можно найти соответствующий маппинг. Или другой пример, когда в компании реализуется NIST CSF и появилась необходимость ещё и реализовать ISO 27001. И такой маппинг тоже существует. «Перейти из одного фреймворка в другой не так сложно, с технической точки зрения вам вообще ничего не придётся менять. Возможно, вам придётся чуть больше добавить бюрократии в виде написания различных документов», — пояснил Алексей Лукацкий.

Если смотреть на ситуацию с точки зрения российских законов по защите персональных данных и информации, то какой бы это закон не был, они, как правило, содержат некий общий набор защитных требований. Таких «общих» защитных мер всего 12:

  • Определение угроз безопасности, анализ уязвимостей и анализ рисков;
  • Предотвращение неправомерного доступа, уничтожения, модифицирования, блокирования, копирования, предоставления, распространения информации на объекте защиты;
  • Недопущение воздействия на технические средства обработки информации, в результате которого может быть нарушено или прекращено функционирование объекта защиты;
  • Применение прошедших в установленном порядке процедуру оценки соответствия средств защиты информации; 
  • Оценка эффективности принимаемых мер по обеспечению безопасности;
  • Учёт машинных носителей;
  • Обнаружение фактов несанкционированного доступа и принятие мер;
  • Восстановление информации, модифицированной или уничтоженной вследствие несанкционированного доступа к ней;
  • Установление правил доступа к информации, а также обеспечение регистрации и учёта всех действий, совершаемых с ней;
  • Контроль за принимаемыми мерами по обеспечению безопасности;
  • Непрерывное взаимодействие с ГосСОПКА;

Наличие ИБ-подразделения или ответственного сотрудника.

Выполняя их, мы покроем практически все текущие и даже возможные будущие изменения в «Законе о персональных данных». И придумать что-то сверх того на высоком уровне достаточно сложно.

 

Ориентация на существующие практики 

По словам Алексея Лукацкого, из-за схожего бэкграунда специалистов из России, Европы и стран СНГ, набор защитных мероприятий будет один и тот же. Поэтому стоя перед неопределённостью выбора между множеством возможных мер, можно ориентироваться на уже существующие практики. 

Первое, с чего можно начать, это документ Европейского агентства по информационной безопасности (ENISA), который описывает различные кейсы, достаточно традиционно возникающие в деятельности любой организации. К этим кейсам прописаны модель рисков, то есть прописано насколько серьёзными могут быть риски, связанные с утечкой либо с иным видом несанкционированного доступа. Также прописан ущерб для персональных данных при выплате зарплаты, при рекрутинге, при оценке персонала, при организации дистанционного образования, при видеонаблюдении, при контроле доступа в помещение и так далее. И так как ENISA является своего рода надевропейским регуляторов в области безопасности, на его документ стоит ориентироваться. «При этом даже в российском практике можно ориентироваться на данный документ, потому что он ничего не требует. Он подсказывает, он ведёт нас по различным кейсам, связанным с обработкой данных, говорит, какие риски могут возникнуть при обработке этих самых данных. И очень неплохое приложение к этому документу — это какие защитные мероприятия можно реализовать в зависимости от тех рисков, которые мы для себя выявили», — пояснил Алексей Лукацкий.

Также есть два документа от регуляторов из Великобритании.

Первый — высокоуровневый чек-лист по безопасности персональных данных от ICO.

Второй — Cyber Essentials — это базовый набор защитных мер, которые применяются к любой информации и в том числе к персональным данным.

Четвёртый вариант — рекомендации по защите от французского регулятора CNIL.

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

Дальше есть ещё один неплохой документ (он, правда, более высокоуровневый, чем требования CNIL, но он и появился чуть позже) — это Стандарт ISO 27701, задача которого применить требования набора стандартов 27 серии к теме персональных данных. В документе есть отдельный раздел с требованиями для обработчиков, операторов, вещи, связанные с выстраиванием процесса, технические мероприятия, контроль доступа, криптография, реагирование на инциденты, связанные с персональными данными, вещи, связанные с приобретением систем или ПО, которые будет обрабатывать персональные данные, какие нюансы возникают с ними. «Также хорошим подспорьем в Стандарте 27701 — это его приложения, которые позволяют смаппить его требования в другие существующие требования и стандарты: и в 29 серию по Privacy Framework, и в GDPR, и в иные документы, которые выпущены были ранее с точки зрения защиты или обработки персональных данных», — добавил Алексей Лукацкий.

Если мы посмотрим на российские требования, то они во многом похожи. И совершенно неважно, с какого документа мы начнём — и там, и там будут выполняться требования и европейских регуляторов, и российских. Единственная разница будет в точке отсчёта. Если мы ориентируемся на GDPR, то у нас, скорее всего, за основу будут взяты либо CNIL, либо ISO 27701. Если мы ориентируемся на ФЗ-152, то, скорее всего, мы возьмём за основу 21 Приказ ФСТЭК, возможно ГОСТ Центрального Банка. И разницы с точки зрения защитных мер не так много.

«Сейчас у нас нет обязательного набора защитных мер по персональным данным, есть набор рекомендуемый, который вы можете крутить в одну и другую сторону. Можете его расширять, можете его уменьшать в зависимости от модели угроз, в зависимости от принимаемых технологий обработки персональных данных», — пояснил Алексей Лукацкий. — «Не надо думать, что 21 Приказ — это набор-минимум, там более 160 требований. Вы можете из него выбрать то, что для вас подходит лучше всего. Там это прямым тестом написано, поэтому можете не бояться такой трактовки. Для российских госорганов есть отличия, но на них и 21 Приказ не распространяется, на них действует 17 Приказ, а там действительно есть некий минимальный набор требований, который надо делать в том числе и для защиты персональных данных».

 

А что-то новенькое будет? 

Также Алексей Лукацкий не исключил, что какой-то регулятор, будь то европейский, российский или из других стран СНГ, может выпустить свой набор требований или рекомендаций по защите персональных данных. «Бояться этого не стоит. Я уверен на 99%, что ничего нового по сравнению с тем, что уже есть, не будет. Потому что, как я уже сказал, одни и те же люди, один и тот же бэкграунд, одно и то же образование, примерно один и тот же склад ума и, соотвественно, они борются с одними и теми же угрозами. Поэтому и набор защитных мер у них будет один и тот же. Разница может быть только в рекомендациях по средствам защиты», — заключил эксперт.

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

10.07.2025
От айтишников всё чаще требуют развитых soft skills
10.07.2025
Хакер попытался украсть личность госсекретаря США с помощью ИИ
10.07.2025
Финрегулятор хочет раскрыть имена собственников банков
10.07.2025
«Большая часть компаний начинает инвестировать в ИБ только в ответ на требования извне»
10.07.2025
Telegram эволюционирует, скамеры — тоже
09.07.2025
Депутаты не одобрили деятельность «белых шляп»
09.07.2025
Командная игра в семь раз сократила объём NFC-хищений в России
09.07.2025
Trend Micro: У зловреда Bert — российские корни (вероятно)
09.07.2025
Только 5% компаний закладывает потери от кибератак в ИБ-бюджет
09.07.2025
В японские воды сойдёт дата-центр на 10000 тонн

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных