Конфиденциальность на этапе проектирования и политики хранения данных

Privacy по принципу проектирования (PbD) — это фреймворк, разработанный Ann Cavoukian в 1990-х годах. Он рассматривает конфиденциальность как фундаментальное архитектурное требование, а не как дополнение, о котором вспоминают в последний момент. Вместо того чтобы добавлять controls конфиденциальности после создания системы, PbD интегрирует их уже на этапе принятия первого проектного решения. Статья 25 GDPR официально закрепила PbD как юридическое требование для систем, ориентированных на EU, обязав обеспечивать защиту Data по принципу проектирования и по умолчанию — то есть настройки по умолчанию всегда должны обеспечивать максимально возможный уровень защиты конфиденциальности.

Семь принципов Cavoukian таковы: Проактивность, а не реактивность — предвидеть и предотвращать события, угрожающие конфиденциальности, до их возникновения. Конфиденциальность по умолчанию — для её защиты не требуется никаких действий User. Конфиденциальность, встроенная в проектирование — она не добавляется отдельным слоем. Полноценная функциональность — конфиденциальность не требует компромиссов между Security и функциональностью. Безопасность от начала до конца — защита на всём жизненном цикле, от сбора до утилизации. Наглядность и прозрачность — операции открыты для независимой проверки. Уважение конфиденциальности User — controls, ориентированные на User, и надёжные настройки по умолчанию.

Конфиденциальность по умолчанию означает, что наиболее защищающие конфиденциальность настройки активны сразу после установки — User не должен самостоятельно отказываться от сбора данных или ограничивать их передачу; вместо этого для передачи требуется явное согласие. Практические примеры: профиль в социальной сети по умолчанию должен быть закрытым, а не общедоступным; инструмент аналитики должен по умолчанию собирать минимум данных; приложение по умолчанию не должно запрашивать разрешение на определение местоположения. Принципы PbD требуют, чтобы инженеры автоматически выбирали варианты, защищающие конфиденциальность, а не полагались на осведомлённость User.

Минимизация данных — это принцип PbD и юридическое требование GDPR: собирайте только те персональные данные, которые строго необходимы для указанной цели. Перед созданием функции инженерам следует спросить себя: «Действительно ли нам нужно это поле?» Распространённые методы минимизации включают сбор производных значений вместо исходных данных (возрастной диапазон вместо даты рождения), использование псевдонимизации (замена прямых идентификаторов токенами) и применение анонимизации, когда анализ на уровне отдельных лиц не требуется. Данные, которые Вы никогда не собираете, невозможно похитить.

Pseudonymization заменяет данные, напрямую идентифицирующие человека, искусственным идентификатором (токеном), сохраняя table соответствий, благодаря чему повторная идентификация возможна при наличии ключа. GDPR признаёт Pseudonymization методом снижения Risk, но NOT освобождает псевдонимизированные данные от требований GDPR — они по-прежнему являются персональными данными. Анонимизация необратимо устраняет возможность идентифицировать отдельных лиц. Действительно анонимные данные не подпадают под scope GDPR, однако настоящая анонимизация технически сложна: многие наборы данных, заявленные как анонимные, можно повторно идентифицировать с помощью вспомогательных данных или атак на основе вывода.

Privacy Impact Assessment (PIA), называемая в GDPR Data Protection Impact Assessment (DPIA), оценивает Risk для конфиденциальности до запуска новой системы или процесса. GDPR требует проведения DPIA, если обработка, вероятно, приведёт к высокому Risk — например, при крупномасштабной обработке чувствительных данных, систематическом профилировании или использовании новых технологий. В DPIA документируются цель обработки, оценка необходимости, выявление Risk и меры по снижению Risk. Раннее завершение DPIA предотвращает дорогостоящую переработку уже созданных систем.

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

В графиках хранения должен быть предусмотрен механизм исключений для юридических запретов на удаление данных. Когда судебное разбирательство ожидается или уже началось, организации обязаны сохранять все потенциально относящиеся к делу данные независимо от обычных графиков хранения. Уничтожение данных, подпадающих под такой запрет, может считаться уничтожением доказательств и привести к неблагоприятным решениям суда или санкциям. Программное обеспечение для юридических запретов на удаление устанавливает на затронутых данных технический флаг сохранения, предотвращая автоматическое удаление до его снятия юридической командой. На протяжении всего срока действия такие запреты необходимо отслеживать и документировать.

По истечении срока хранения данные необходимо уничтожить так, чтобы восстановление стало невозможным. Для цифровых данных применяются: криптографическое стирание (уничтожение ключей шифрования делает шифротекст бесполезным), размагничивание (для магнитных носителей), безопасная перезапись (NIST SP 800-88 Clear или Purge) или физическое уничтожение (измельчение, сжигание). Организациям следует оформлять сертификаты уничтожения — особенно при уничтожении носителей третьей стороной — в качестве доказательства для аудитов соответствия. Для облачного хранения криптографическое стирание обычно является единственным практически применимым методом.

Организации, которые используют согласие в качестве законного основания, должны хранить записи о согласии, подтверждающие: кто дал согласие, когда, на какую именно обработку и с помощью какого механизма. Эти записи необходимо хранить в течение всего периода обработки и ещё разумный срок после её окончания для разрешения споров. Платформы управления согласием (CMP) автоматизируют получение согласия на использование файлов cookie, сохранение настроек и отзыв согласия. Журнал изменений согласия имеет критическое значение: если пользователь отозвал согласие, но его данные продолжают обрабатываться, организация подвергается значительной ответственности по GDPR.

Практическая реализация принципа конфиденциальности на этапе проектирования означает, что архитекторы задаются вопросами конфиденциальности уже при проектировании. Предпочитайте рендеринг на стороне сервера аналитическим маячкам на стороне клиента. Используйте токенизацию вместо хранения исходных номеров карт. Применяйте шифрование на уровне столбцов в базах данных для конфиденциальных полей. Проектируйте уровни доступа к данным, которые обеспечивают получение минимально необходимого объёма данных для каждого запроса. Храните PII в отдельной схеме базы данных с более строгими ограничениями доступа. Применяйте дифференциальную конфиденциальность к результатам аналитики. В совокупности эти решения создают систему, которую чрезвычайно трудно взломать даже изнутри организации.

Проверьте своё понимание концепций CompTIA Security+ (SY0-701) из этого урока.

В этом уроке Вы узнали, что конфиденциальность на этапе проектирования встраивает защиту конфиденциальности в системы с самого начала с помощью семи основополагающих принципов, включая конфиденциальность как настройку по умолчанию; минимизация данных и псевдонимизация снижают ценность данных для злоумышленников, сохраняя возможность аналитики; а политики хранения данных уравновешивают юридические обязательства и риск избыточного хранения данных за счёт их безопасного уничтожения по окончании срока хранения. Далее мы рассмотрим безопасность конечных устройств: антивирусы, EDR и XDR-платформы.