Security by design что это
Книга «Безопасно by design»
Привет, Хаброжители! «Безопасно by Design» не похожа на другие книги по безопасности. В ней нет дискуссий на такие классические темы, как переполнение буфера или слабые места в криптографических хэш-функциях. Вместо собственно безопасности она концентрируется на подходах к разработке ПО. Поначалу это может показаться немного странным, но вы поймете, что недостатки безопасности часто вызваны плохим дизайном. Значительного количества уязвимостей можно избежать, используя передовые методы проектирования. Изучение того, как дизайн программного обеспечения соотносится с безопасностью, является целью этой книги. Вы узнаете, почему дизайн важен для безопасности и как его использовать для создания безопасного программного обеспечения.
Безопасность должна учитываться на каждом этапе процесса разработки ПО. Подход, изложенный в книге, поможет вам реализовывать ключевые возможности программы, исходя из стремления к безопасности. В книге описаны принципы и наилучшие практики создания исключительно защищенных приложений. На уровне кода вы откроете для себя решения, способствующие повышению надежности: безопасную обработку ошибок, безопасную валидацию и использование примитивов предметной области. Вы также освоите приемы, которые сможете использовать в пределах всего конвейера сборки-тестирования-развертывания. Кроме того, авторы делятся уникальными соображениями, касающимися современных микросервисов и облачно-ориентированного проектирования.
Концепции программирования, способствующие безопасности
Мы все несем ответственность за проектирование безопасного программного обеспечения. Из данной главы вы узнаете, почему для этого не требуется дополнительное время по сравнению с разработкой слабо защищенного уязвимого ПО. В связи с этим мы разделили материал на три части, где обсуждаются разные стратегии решения проблем с безопасностью, которые вам могут встретиться в повседневной работе (табл. 4.1).
Таким образом мы попытаемся изменить ваш образ мышления, снабдить вас новым набором инструментов и дать рекомендации, которые вы сможете применять в повседневной работе. Вы также научитесь выявлять слабые места в устаревшем коде и исправлять их. Начнем с принципа неизменяемости и приведем пример того, как он помогает справляться с обновлениями.
4.1. Неизменяемость
Проектируя объект, вы должны определиться с тем, каким он должен быть: изменяемым или неизменяемым. В первом случае его состояние может меняться, а во втором — нет. Это может показаться несущественным, но с точки зрения безопасности этот аспект очень важен. Неизменяемые объекты можно безопасно разделять между потоками выполнения, с их помощью данные можно сделать высокодоступными, что очень значимо для защиты системы от DoS-атак (denial of service — «отказ в обслуживании»). А вот изменяемые объекты рассчитаны на обновление, что может привести к внесению несанкционированных изменений. Поддержка изменяемости зачастую привносится в систему из-за того, что ее требуют фреймворки, или потому, что на первый взгляд она делает код проще. Но это опасный подход, за который, возможно, придется дорого заплатить. Чтобы это проиллюстрировать, рассмотрим пример того, как использование изменяемости в архитектуре веб-магазина вызывает проблемы с безопасностью, которые можно легко решить за счет неизменяемости.
4.1.1. Обыкновенный веб-магазин
Представьте себе обыкновенный веб-магазин, клиенты которого аутентифицируются и добавляют товары в корзину покупок. У каждого клиента есть кредитный рейтинг, основанный на истории покупок и членских баллах. Низкий кредитный рейтинг позволяет платить только с помощью кредитной карты, а высокий в дополнение к этому дает возможность использовать счет-фактуру. Вычисление кредитного рейтинга требует довольно значительных ресурсов и проводится непрерывно, чтобы сделать общую нагрузку на систему более равномерной.
В целом система работала нормально — до недавних пор. Во время последней рекламной кампании на сайт магазина заходило много людей. Система плохо справлялась с нагрузкой, и клиенты жаловались на истечение времени ожидания заказа, большие задержки и нелогичные варианты оплаты. Последняя проблема казалась несущественной, но затем финансовый отдел сообщил о том, что у многих клиентов с низким кредитным рейтингом появились неоплаченные счета-фактуры. Началось полномасштабное расследование — безопасность системы под угрозой! Главным подозреваемым, естественно, был код для вычисления кредитного рейтинга, но, к всеобщему удивлению, проблема оказалась куда более серьезной — внутреннее устройство объекта Customer.
Внутреннее устройство объекта Customer
Объект Customer, показанный в листинге 4.1, имеет две интересные особенности. Первая состоит в том, что все поля инициализируются с помощью методов-сеттеров. Из этого следует, что после создания объекта его внутреннее состояние можно изменять. Это может стать источником проблем, так как мы не можем гарантировать, что объект инициализирован правильно. Еще одно наблюдение заключается в том, что каждый метод помечен ключевым словом synchronized, которое должно предотвращать конкурентное изменение полей, что, в свою очередь, может привести к конфликту потоков (это когда потоки вынуждены останавливаться и ждать, пока какой-то другой поток не снимет одну или несколько блокировок).
Пока что не совсем понятно, как эти проектные решения относятся к безопасности, но все прояснится, когда мы классифицируем проблемы веб-магазина как нарушение целостности или доступности данных.
Классификация проблем как нарушение целостности или доступности
Под целостностью данных подразумевается их согласованность на протяжении всего жизненного цикла, доступность данных — это гарантия того, что их можно получить с соблюдением ожидаемого уровня производительности в системе. Обе концепции являются ключом к пониманию причины проблем, возникших в веб-магазине. Например, невозможность извлечь данные — это проблема с доступностью, которая часто сводится к тому, что какой-то код мешает параллельному или конкурентному доступу. Аналогично анализ проблем целостности следует начинать с кода, позволяющего вносить изменения. В табл. 4.2 показаны проблемы веб-магазина, классифицированные как нарушение доступности и целостности.
Эти категории дают общее представление о том, какие участки класса Customer заслуживают особого внимания. Начнем с того, как неявное блокирование может ухудшить доступность.
Неявное блокирование ухудшает доступность
Вопрос о том, нужно ли запрещать конкурентный и параллельный доступ, зачастую становится компромиссом между производительностью и согласованностью. Если состояние всегда должно оставаться согласованным, а обновления чередуются с операциями чтения, имеет смысл прибегнуть к механизмам блокирования. Но если данные преимущественно читают, блокирование может привести к излишним конфликтам между потоками выполнения. В конфликтах, вызванных конкурентным доступом, как правило, легче разобраться, чем в тех, причина которых — параллельный доступ. Возьмем, к примеру, метод synchronized из листинга 4.1: в любой момент его может выполнять только один поток, так как для доступа к нему необходимо получить блокировку, встроенную в его объект. Все остальные потоки, пытающиеся конкурентно обратиться к этому методу, должны ждать, пока эта блокировка не будет снята, что может привести к конфликтам.
Использование ключевого слова synchronized на уровне метода также может вызвать конфликты между потоками при параллельном обращении к двум и более методам. Оказывается, чтобы получить доступ ко всем методам, объекты, помеченные как synchronized, должны получить одну и ту же встроенную блокировку. Это означает, что потоки, вызывающие эти методы параллельно, неявно блокируют друг друга и подобные конфликты иногда сложно обнаружить.
Если вернуться к нашему веб-магазину и проанализировать соотношение между операциями чтения и записи, окажется, что чтение данных о клиенте происходит намного чаще, чем их обновление. Дело в том, что изменением данных в основном занимается алгоритм вычисления кредитного рейтинга, а операции чтения выполняются в рамках многочисленных клиентских запросов, в том числе со стороны системы создания отчетов, принадлежащей отделу финансов. Это указывает на то, что параллельное и конкурентное чтение безопасны. Так почему бы и вовсе не избавиться от механизма блокирования (synchronized)?
Параллельное и конкурентное чтение, скорее всего, безопасны, но при минимизации конфликтов нельзя игнорировать операции записи. Вместо отказа от механизма блокирования необходимо подумать о другом решении. Например, можно использовать продвинутые средства блокирования наподобие ReadWriteLock, которое учитывает преобладание операций чтения. Однако механизмы блокирования усложняют код и повышают когнитивную нагрузку на разработчиков. Мы предпочитаем этого избегать.
Неизменяемые значения можно безопасно разделять между потоками выполнения без применения блокировок, что позволяет избежать конфликтов.
Есть более простая и успешная стратегия, состоящая в использовании методик проектирования, рассчитанных на параллельный и конкурентный доступ, таких как неизменяемость. В листинге 4.2 вы увидите неизменяемую версию класса Customer, которая не позволяет обновлять состояние. Это означает, что объекты Customer можно безопасно разделять между потоками без помощи блокировок. В результате получается высокий уровень доступности с небольшим числом конфликтов. Иными словами, потоки больше не блокируются.
Но нам все равно нужна возможность редактировать данные клиента. Как этого добиться, если класс Customer неизменяемый? Оказывается, для поддержки изменений можно обойтись без изменяемых структур данных. Достаточно лишь отделить чтение от записи и выполнять обновления через отдельные каналы. Это может показаться слишком сложным, но если в вашей системе наблюдается дисбаланс между чтением и записью, результат может стоить приложенных усилий. О том, как реализовать это на практике, речь пойдет в главе 7, где мы подробно обсудим шаблон проектирования «Снимок сущности».
Вы уже знаете, что неизменяемость предотвращает проблемы с доступностью на уровне проектирования, но что насчет нарушения целостности в нашем веб-магазине? Поможет ли здесь неизменяемость? Возможно. Давайте посмотрим, как изменяемая архитектура Customer и CreditScore делает вероятными проблемы с целостностью.
Изменение кредитного рейтинга:
проблема с целостностью
Прежде чем погружаться в анализ, вспомним, в чем заключается проблема с кредитным рейтингом. Каждому клиенту назначается кредитный рейтинг; если он достаточно высокий, клиент может выполнять оплату по счету-фактуре. Во время последней рекламной кампании система вышла из строя, и финансовый отдел сообщил о том, что множество клиентов с низким рейтингом имеют неоплаченные счета-фактуры. Нарушение целостности данных привело к изменению кредитного рейтинга, которое открыло доступ к дополнительному способу оплаты. Но как такое возможно? Взглянув на логику управления кредитным рейтингом в изменяемом объекте Customer (листинг 4.3), мы видим следующее:
Обсудим каждое из этих наблюдений и подумаем, каким образом они приводят к нарушению целостности данных.
Первое, что может вызвать проблему целостности, — это явное изменение кредитного рейтинга путем инициализации. Поле creditScore в классе Customer инициализируется с помощью метода setCreditScore. Это было сделано сознательно, однако такой способ инициализации поля позволяет менять кредитный рейтинг клиента в любой момент, так как не гарантирует, что его можно вызвать только один раз. Это может показаться приемлемым, поскольку клиент, как ожидается, будет выполнять только чтение данных, но изменяемый характер класса Customer не позволяет предотвратить случайное использование этого метода. Это означает, что вы не можете гарантировать целостность объекта Customer.
Класс CreditScore был спроектирован как изменяемый, поэтому мы можем вручную изменить ID клиента, вызвав функцию setCustomerId, как показано в листинге 4.4. Из этого следует, что объекты Customer и CreditScore могут иметь разные ID, а такое нарушение связи способно привести к использованию неправильного значения кредитного рейтинга в методе compute!
Чтобы исправить ситуацию, мы должны модифицировать класс CreditScore. В листинге 4.5 вы видите его неизменяемую версию. Обратите внимание на то, что мы удалили ключевое слово synchronized и зависимость от ID клиента. Дело в том, что больше не нужно получать блокировку при проверке кредитного рейтинга, так как теперь он не может измениться после передачи в конструктор. Это, в свою очередь, означает, что зависимость от определенного клиента становится лишней, поэтому архитектуру можно упростить за счет выноса вычисления кредитного рейтинга за пределы объекта. Это позволяет разделять рейтинг между потоками, причем нам не угрожают несанкционированные обновления, конфликты и блокирование.
Третий способ изменения creditScore не такой очевидный, как предыдущие два, — он связан с модификацией разделяемой ссылки на кредитный рейтинг. Если взглянуть на метод setCreditScore в изменяемой версии объекта Customer, можно заметить, что внутреннему полю присваивается внешняя изменяемая ссылка на creditScore. Это не страшно, пока данную внешнюю ссылку не используют повторно в другом объекте Customer. Но если это произойдет, вычисляемое значение кредитного рейтинга будет одинаковым для всех клиентов, которые разделяют ссылку. Это серьезное нарушение целостности, которое объясняет нелогичные варианты оплаты в веб-магазине.
Все сценарии, которые мы исследовали, могут объяснить проблемы с целостностью данных в веб-магазине, но какой из них является настоящей причиной? На самом деле это неважно. Главное здесь то, что, решив использовать изменяемые классы Customer и CreditScore, разработчики системы сделали свой код менее безопасным сразу с нескольких точек зрения. Но если выбрать подход, ориентированный на неизменяемость, то потребность в блокировках и защите от случайных изменений исчезает. Такое проектное решение само по себе повышает уровень безопасности.
Теперь вы знаете, как неизменяемость позволяет избежать проблем с целостностью и доступностью данных. Возможно, вы заметили, что в некоторых случаях некорректные данные агрессивно блокировались еще до попадания в объект. Это еще один эффективный прием обеспечения безопасности. Теперь перейдем к быстрому прекращению работы с помощью контрактов.
Для Хаброжителей скидка 25% по купону — Design
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Концепции «Secure-by-design» и «Secure-by-default»: модные слова или необходимость в индустрии безопасности?
Чтобы защитить свои данные и активы, людям нужны решения видеонаблюдения, которые считаются безопасными, созданными по концепциям “secure-by-design” и “secure-by-default”. Но что на самом деле означают эти часто используемые термины кибербезопасности? И как можно убедиться, что производитель камер видеонаблюдения и систем безопасности выполняет все свои обещания в отношении кибербезопасности? В массе случаев лучше избегать технического жаргона в пользу четких и кратких описаний, но это не всегда возможно. Некоторые термины остаются неизменными, и когда дело доходит до кибербезопасности, часто можно услышать об устройствах «защищенных по умолчанию» и «защищенных по конструкции». Но что же означают эти термины? И почему они так важны для бизнеса и стратегии кибербезопасности?
Что такое «безопасная конструкция»?
«Secure-by-design» — это философия или подход, направленный на то, чтобы обеспечить безопасность на всех этапах производственного процесса продукта. Он начинается на этапе разработки концепции, когда видеокамера или другой продукт только на чертежной доске, и продолжается через разработку и тестирование, вплоть до окончательного производства и доставки.
Но явно недостаточно думать о безопасности при разработке новых продуктов. Также должны быть конкретные шаги, которые предпринимаются для оценки безопасности на каждом этапе. Например, во время разработки важны экспертные оценки программного обеспечения устройства, чтобы свести к минимуму ошибки и убедиться, что в коде отсутствуют лазейки в безопасности. Кроме того, продукты следует подвергать тщательному тестированию на проникновение, чтобы гарантировать отсутствие легко используемых уязвимостей
А как насчет «защиты по умолчанию»?
Опять же, часто используется термин «secure-by-default», но зачастую без объяснения или контекста. Истинное значение слова «защищенный по умолчанию» заключается в том, что продукты настроены на повышенную безопасность, когда они покидают завод, даже если эти настройки означают, что некоторые функции отключены.
Как всегда, необходимо соблюдать баланс между безопасностью и функциональностью, и у пользователя всегда предусмотрен шанс уменьшить настройки безопасности и повысить функциональность продуктов — в зависимости от устойчивости к риску. Однако заводские настройки по умолчанию обеспечивают действенную кибербезопасность с первого дня установки, что считается впечатляющим стартом для начала.
Пять вопросов по кибербезопасности для производителя
Когда дело доходит до упомянутых выше концепций, все упирается в производителя системы безопасности. Вопрос в том, как узнать, достаточно ли серьезно относится к кибербезопасности выбранный производитель устройства? Действенный способ узнать это — задать производителю массу вопросов об обязательствах и методах обеспечения кибербезопасности. Вопросы вроде:
1. Считается ли «безопасная конструкция» приоритетной инвестицией для компании? Учтите, что разработка безопасного продукта с нуля обходится гораздо дороже, поэтому должен быть доступный бюджет для экспертных оценок, тестирования и других действий, которые проверяют безопасность устройства на протяжении жизненного цикла проектирования и производства.
2. Предусмотрена ли специальная команда по кибербезопасности? Производители решений видеонаблюдения, серьезно относящиеся к безопасности продуктов, включают специальную команду по кибербезопасности, которой поручено постоянно следить за процессом и проверять продукты.
3. Разглашаете ли вы подробную информацию о «безопасных» продуктах публично (в официальных документах или в других сообщениях)? Опять же, производители, серьезно относящиеся к кибербезопасности, должны быть открытыми в деталях реализации «secure-by-design». Эти данные должны быть общедоступны, желательно отмечены в официальных источниках.
4. Что произойдет, если пользователю потребуется поддержка в области кибербезопасности после установки комплекта видеонаблюдения? Производители, заботящиеся о безопасности, должны иметь специальную команду постпродажного обслуживания, которая может решить любые вопросы безопасности или проблемы, возникающие при установке.
5. Все ли продукты защищены заводскими настройками по умолчанию? Производители, что дорожат репутацией, будут делать это стандартно, но на всякий случай все же важно уточнить.
Например, компания Hikvision инвестирует миллионы долларов и тысячи часов для исследований и разработок в год, чтобы гарантировать, что ее продукты в полной мере безопасны по конструкции и по умолчанию.
На практике инженеры Hikvision внедряют функции кибербезопасности в продукты под пристальным вниманием специализированной группы по кибербезопасности — с тщательными экспертными обзорами и тестированием программного обеспечения на проникновение, проводимым на каждом этапе процессов разработки и производства. Также компания в полной мере открыта в отношении инструментов и процессов, которые использует для создания продуктов и рада поделиться этой информацией с клиентами.
Наконец, что не менее важно, все продукты и видеокамеры Hikvision поставляются в конфигурации «защищенный по умолчанию», что дает пользователю принимать собственные решения при балансировании безопасности продукта и его функциональности.
Privacy by design и privacy by default (спроектированная защита данных и конфиденциальность по умолчанию по GDPR)
В мае 2018 года вступил в силу новый закон о защите персональных данных – General Data Protection Regulation или Регламент Европейского Парламента и Совета Европейского Союза 2016/679 от 27 апреля 2016 г. о защите физических лиц при обработке персональных данных и о свободном обращении таких данных, а также об отмене Директивы 95/46/ЕС (далее GDPR), который предоставляет резидентам ЕС инструменты для полного контроля над своими персональными данными, защита которых является фундаментальным правом в Европейском союзе. Статья 25 GDPR требует от компаний создания систем со встроенной защитой персональных данных и систем конфиденциальности по умолчанию — privacy by design и privacy by default. В настоящем материале мы разберем эти понятия.
Текст статьи 25 Регламента на английском и на русском:
1. Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects.
1. Принимая во внимание состояние развития науки и техники, расходы на внедрение, характер, объем, особенности и цели обработки, а также вероятностное возникновение рисков и опасности для прав и свобод физических лиц в результате обработки, контролер должен как во время определения средств обработки, так и во время самой обработки внедрить соответствующие технические и организационные меры, например, псевдонимизацию, которые предназначены для эффективной реализации принципов защиты данных, например, минимизации данных, и для интегрирования необходимых гарантий в обработку в целях выполнения требований настоящего Регламента и защиты прав субъектов данных.
2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.
2. Контролер должен внедрить соответствующие технические и организационные меры для обеспечения того, что по умолчанию обрабатываются только те персональные данные, которые необходимы для каждой конкретной цели обработки. Указанная обязанность применяется в отношении большого количества собранных персональных данных, объема их обработки, срока их хранения и возможности доступа к ним. В частности, указанные меры должны гарантировать, что по умолчанию доступ к персональным данным не будет предоставлен неопределенному количеству физических лиц без участия отдельного лица.
3. An approved certification mechanism pursuant to Article 42 may be used as an element to demonstrate compliance with the requirements set out in paragraphs 1 and 2 of this Article.
3. Утвержденный сертификационный механизм согласно Статье 42 может использоваться в качестве элемента для подтверждения соблюдения требований, установленных в параграфах 1 и 2 настоящей Статьи.
Это означает, что контролер данных обязуется встроить систему защиты данных во все бизнес-процессы (в том числе в процессы разработки продукта или сервиса) на раннем этапе их проектирования и обязуется поддерживать такую систему непрерывно в дальнейшем. Встроенная защита данных по своему замыслу — это обязанность заблаговременно предусмотреть защиту персональных данных во всех действиях, начинаниях и решениях компании. Например, при создании мобильного приложения необходимо проанализировать и предупредить возможные риски, связанные с конфиденциальностью, и установить механизмы управления такими рисками до написания кода.
Согласно философии privacy by design, лучший способ снизить риски, связанные с конфиденциальностью, — это, в первую очередь, не создавать их.
Privacy by default
Конфиденциальность по умолчанию подразумевает, что пользователю не нужно предпринимать никакие действия для защиты своей конфиденциальности. Настройки по сохранению конфиденциальности и соответственно защите его персональных данных установлены по умолчанию. Контролеры не должны автоматически полагать, что пользователь дает согласие на обмен данными. Сбору подлежат только те данные, которые необходимы для достижения конкретных целей обработки. Для обеспечения такой конфиденциальности по умолчанию контролеры должны имплементировать соответствующие технические и организационные меры.
У сайта в профиле пользователя не должен быть автоматически отмечен чекбокс о согласии пользователя на передачу его данных третьим лицам. Пользователь должен сам отметить этот чекбокс, тем самым выразить явное согласие (см. о явном согласии ст. Статьи 4(11), 6(1)(a), 7 GDPR). Или, например, при сборе данных, необходимых для регистрации пользователя, приложение не должно требовать от пользователя предоставления данных, не являющихся необходимыми для регистрации.
Чем меньше данных компания собирает и обрабатывает, тем меньше риск нарушения GDPR.
История privacy by design, privacy by default
По мнению Европейского контролера по защите данных (European Data Protection Supervisor, далее EDPS), термины «встроенная конфиденциальность» и «конфиденциальность по умолчанию» были разработаны в 1990-х годах Энн Кавукян (Ann Cavoukian), специальным уполномоченным по информации и защите персональных данных в канадской провинции Онтарио. В 2009 году она опубликовала документ «Встроенная конфиденциальность: 7 основополагающих принципов», в котором объясняет, что «встроенная конфиденциальность» означает, что компании должны активно рассматривать вопросы конфиденциальности на протяжении всего жизненного цикла данных, начиная с фазы проектирования. Такая «защита всего жизненного цикла» (“Full Lifecycle Protection”) гарантирует, что все данные надежно сохраняются, а затем надежно своевременно уничтожаются. Таким образом, privacy by design обеспечивает непрерывное и безопасное управление жизненным циклом данных, от начала до завершения обработки. В соответствии с этими принципами эта защита может и должна действовать без ущерба для функциональности бизнеса или системы.
Кавукян разработала следующие принципы:
EDPS объясняет, что этот параметр по умолчанию означает, что субъект данных не должен нести бремя защиты своих данных при использовании каких-либо услуг или продуктов. Право на неприкосновенность частной жизни будет защищаться «автоматически» в качестве настройки по умолчанию.
Принципы privacy by design и privacy by default, разработанные Кавукян, вскоре были приняты европейскими законодателями как стандарт в области защиты персональных данных.
Проект рекомендаций
European Data Protection Board от 13 ноября 2019 года
13 ноября 2019 года независимый орган по защите персональных данных на европейском уровне European Data Protection Board (Европейский совет по защите персональных данных, далее EDPB) опубликовал проект рекомендаций по применению статьи 25 GDPR о встроенной системе конфиденциальности. Эта версия не финальная, EDPB принимает комментарии от любых заинтересованных лиц до 16 января 2020 года, после чего с учетом таких комментариев публикует финальную версию рекомендаций. Рекомендации не имеют силы закона, но несмотря на их ненормативный характер, регуляторы по защите данных в странах ЕС и компании следуют им.
Ниже перечислены основные моменты этих рекомендаций, которые помогут правильно толковать, понимать требования статьи 25 GDPR.
1. Privacy by design
4. Сертификация в соответствии со статьей 42 GDPR может также использоваться, чтобы показать соответствие принципам privacy by design и privacy by default, и обеспечить конкурентное преимущество на рынке поставщиков. Важно добавить, что существуют рекомендации по сертификации в отношении ст 42, 43 GDPR, также разработанные EDPB.
5. В рекомендациях также даны практические примеры по важным элементам privacy by design, privacy by default: прозрачность, законность, добросовестность, ограничение цели, точность, ограничение хранения, целостность и конфиденциальность.
Например, к элементу “точность” EDPB представил следующую ситуацию и потенциальное ее решение:
Контролер — это медицинское учреждение, которое ищет способы обеспечения целостности и точности персональных данных в своих клиентских регистрах. В ситуациях, когда два человека прибывают в учреждение одновременно и получают одинаковое лечение, существует риск ошибки, если единственным параметром, различающим их, является имя. Для обеспечения точности контроллеру необходим уникальный идентификатор для каждого человека и, следовательно, больше информации, чем просто имя клиента. Учреждение использует несколько систем, содержащих личную информацию клиентов, и должно гарантировать, что информация, относящаяся к клиенту, является правильной, точной и согласованной во всех системах в любой момент времени. Было выявлено несколько рисков, которые могут возникнуть, если информация изменилась в одной системе, но не в другой. Чтобы снизить риски, контроллер решает использовать метод хеширования для обеспечения целостности данных в записях о лечении. Неизменяемые хэш-подписи создаются для записей лечения и связанного с ними сотрудника, чтобы любые изменения можно было распознать, сопоставить и отследить при необходимости.
Как было указано выше, это не финальная версия рекомендаций, поэтому необходимо следить за обновлением с учетом комментариев заинтересованных лиц.
Большой штраф по ст. 25 GDPR
30 октября 2019 года немецкая риэлторская компания Deutsche Wohnen SE была оштрафована на сумму 14,5 миллионов евро за неправильное хранение данных как раз со ссылкой на статью 25 (1) GDPR. Компания использовала систему архивирования для хранения персональных данных арендаторов, не обеспечивающую возможность удаления уже ненужных данных. Персональные данные арендаторов хранились без проверки на предмет допустимости дальнейшего их хранения. Таким образом, было возможно получить доступ к личным данным, которые хранились годами, когда как они уже не служили целям их первоначального сбора. Хранились данные о личном и финансовом положении арендаторов, справки о заработной плате, формы о раскрытии информации (self-disclosure forms), выписки из трудовых договоров и договоров об обучении, данные о налогах, социальном обеспечении и медицинском страховании, а также выписки с банковского счета.
Максимальный штраф за нарушение статьи 25 (1) GDPR составляет 10 миллионов евро или 2% мирового оборота. Штраф в размере 14,5 млн евро был рассчитан с использованием руководств, ранее опубликованных BBDI (Немецкий орган по защите данных, Berliner Beauftragte für Datenschutz und Informationsfreiheit).
На этом сайте (GDPR Enforcement Tracker) можно следить за штрафами и санкциями, которые налагаются в Евросоюзе в рамках GDPR.
Статья 25 GDPR накладывает значительное бремя на обеспечение встроенной защиты персональных данных и конфиденциальности по умолчанию. Для соблюдения требований этой нормы и во избежание крупных штрафов контролеры должны проанализировать, как, где и когда они обрабатывают информацию, и обеспечить, чтобы право на неприкосновенность частной жизни учитывалось на каждом этапе обработки, начиная с проектирования продукта/услуги, нового бизнес-процесса. Это должно включать следующее: