Соответствие GDPR в облачном хранилище: лучшие практики
Лучшие практики для соответствующего GDPR облачного хранилища: шифрование, контроль доступа, расположение данных и критерии оценки поставщиков.
Облачное хранилище, соответствующее GDPR, требует пяти уровней защиты: (1) шифрование в покое с применением AES-256 и в транзите с TLS 1.3, в идеале дополненное клиентским шифрованием для чувствительных данных; (2) Соглашение об обработке данных с провайдером, соответствующее статье 28(3); (3) задокументированная локализация данных — как правило, ЕС/ЕЭЗ для персональных данных ЕС — с прозрачностью субобработчиков; (4) детальный контроль доступа с MFA, ролевыми правами и журналами аудита не менее чем за шесть месяцев; (5) обнаружение нарушений, способное уложиться в 72-часовое окно уведомления по статье 33. В России 242-ФЗ дополнительно требует хранить первичные персональные данные российских граждан на серверах внутри страны — Роскомнадзор вправе потребовать документальное подтверждение локализации. Пропуск любого уровня превращает хранилище в слабейшее звено всего стека соответствия.
Выбор провайдера, соответствующего статье 28
Европейский рынок облачного хранилища делится на чёткие уровни. Гипер-скейлеры (AWS, Azure, Google Cloud) предлагают комплексные СОД и регионы ЕС, но несут риски по законодательству CLOUD Act. Европейские суверенные провайдеры (OVHcloud, Scaleway, Infomaniak, Hetzner, IONOS) не подпадают под американскую юрисдикцию и нередко имеют сертификации C5, SecNumCloud или ISO 27001. Специализированные провайдеры с упором на конфиденциальность (Tresorit, Proton Drive, Internxt, Nextcloud-хостинг) добавляют архитектуру нулевого знания. Выбирайте исходя из чувствительности данных: медицинские записи и оборонные данные требуют суверенных или zero-knowledge-провайдеров; общие деловые файлы работают на гипер-скейлерах при правильной конфигурации.
Шифрование на стороне сервера против шифрования на стороне клиента
Серверное шифрование — AWS S3 SSE-KMS, Azure Storage Service Encryption, управляемые клиентом ключи Google Cloud — защищает от физической кражи дисков, но не от сотрудников провайдера с доступом к ключам и не от принудительного раскрытия по требованию властей. Клиентское шифрование, при котором провайдер никогда не видит ключей (XChaCha20-Poly1305 в Tresorit, AES-256-GCM с PBKDF2-SHA-256 для формирования ключей в HexaTransfer), обеспечивает защиту нулевого знания. Для высококонфиденциальных данных по статье 9 (здоровье, биометрия, политические взгляды) клиентское шифрование — соответствующий стандарт по умолчанию; серверное одно по себе — лишь пограничный вариант.
Настройка AWS S3 для GDPR
S3 не соответствует требованиям из коробки. Для персональных данных ЕС установите регион бакета eu-central-1 (Франкфурт), eu-west-1 (Ирландия), eu-west-3 (Париж) или eu-south-1 (Милан). Включите шифрование по умолчанию с SSE-KMS, используя управляемый клиентом CMK с ротацией ключей. Заблокируйте публичный доступ на уровне аккаунта. Установите Object Lock для иммутабельного хранилища там, где юридически требуется удержание. Включите логирование S3 и AWS CloudTrail для аудита. Используйте VPC endpoints, чтобы трафик не проходил через публичный интернет. Отключите S3 Transfer Acceleration, если не можете доказать, что кэши CloudFront Edge остаются в ЕС.
Эквиваленты в Azure и Google Cloud
Azure: выбирайте West Europe (Амстердам) или North Europe (Дублин), включайте Storage Service Encryption с управляемыми клиентом ключами через Key Vault, настройте Private Endpoints, установите Azure Policy для запрета развёртываний вне ЕС и включите Microsoft Defender for Storage. Google Cloud: выбирайте europe-west1 (Бельгия), europe-west3 (Франкфурт) или europe-west9 (Париж), включайте Customer-Managed Encryption Keys через Cloud KMS, используйте VPC Service Controls для предотвращения утечки и включите Cloud Audit Logs. Оба гипер-скейлера публикуют специализированные руководства по настройке для GDPR; следуйте им дословно.
Контроль доступа по статье 32(1)(b)
Ролевой доступ — базовый уровень. Каждая идентичность — человеческая или сервисная — должна иметь минимально необходимые права, ограниченные конкретным бакетом, префиксом или папкой. MFA обязательно для консольного доступа и рекомендовано для API-ключей через токены сессий. Процессы выдачи, перемещения и отзыва прав, интегрированные с поставщиком идентичности (Okta, Azure AD, Google Workspace), предотвращают устаревший доступ. Ежеквартальные проверки доступа выявляют его расширение сверх необходимого. Для особо чувствительных файлов экстренный доступ с двойным одобрением и автоматическим истечением повышенных привилегий через 4–8 часов ограничивает ущерб от скомпрометированных административных аккаунтов.
Политики хранения, соответствующие цели
Статья 5(1)(e) (ограничение хранения) обязывает удалять данные по истечении цели обработки. Облачное хранилище провоцирует бессрочное хранение — место дёшево. Создайте политики жизненного цикла, обеспечивающие хранение, привязанное к цели: 30 дней для временных зон приёма, 13 месяцев для вложений в поддержку клиентов, 7 лет для счетов-фактур (налоговое законодательство), 10 лет для медицинских записей в ряде юрисдикций. Правила жизненного цикла S3, Azure Blob Lifecycle Management и GCS Object Lifecycle автоматизируют это. Совмещайте с Object Lock для соответствия WORM там, где юридически требуется удержание.
Управление ключами шифрования
Ключи — это центр тяжести. Кто держит ключ — держит данные. По GDPR, опека ключей определяет, является ли провайдер хранилища процессором (может расшифровать) или просто каналом передачи данных (держит зашифрованные данные). Используйте HSM-backed хранилища ключей (AWS KMS, Azure Key Vault Managed HSM, Google Cloud HSM) для серверных сценариев. Для нулевого знания формируйте ключи в браузере через Web Crypto API PBKDF2 или Argon2id (crypto_pwhash от libsodium) и никогда их не передавайте. Ротируйте ключи ежегодно или при увольнении сотрудников с доступом. Документируйте опеку ключей в реестре операций обработки по статье 30.
Шифрование и локализация резервных копий
Резервные копии нередко разрушают истории о локализации и шифровании. Бакет в eu-central-1 с правилом кросс-регионной репликации в us-east-1 для «отказоустойчивости» только что переместил каждый файл в США без обновления СОД. Проверьте конфигурации CRR и установите назначения внутри ЕЭЗ — eu-west-1 (Ирландия) и eu-central-1 (Франкфурт) хорошо сочетаются. Шифруйте резервные копии отдельным ключом, отличным от ключа основного хранилища, чтобы компрометация одного ключа не раскрыла оба экземпляра. Тестируйте восстановление ежеквартально — нерабочая резервная копия хуже, чем полное её отсутствие с точки зрения аварийного восстановления.
Обнаружение нарушений с укладкой в 72 часа
72-часовой отсчёт статьи 33 начинается с момента «осознания». Инструменты обнаружения сокращают разрыв между нарушением и осознанием. CloudTrail + GuardDuty на AWS, Microsoft Defender for Cloud на Azure и Security Command Center Premium на GCP выявляют аномальные паттерны доступа — массовые загрузки, доступ из новых гео, ключи, используемые вне рабочих часов. Направляйте оповещения в 24/7 SOC или хотя бы в ротационное дежурство. Для небольших организаций управляемые сервисы обнаружения и реагирования (Arctic Wolf, Red Canary) заполняют этот пробел. Задокументируйте план действий: кто уведомляет надзорный орган, кто составляет форму по статье 33, кто уведомляет субъектов по статье 34.
Чеклист оценки провайдера
Перед подписанием договора на облачное хранилище потребуйте: (1) СОД по статье 28, охватывающий все восемь тем; (2) сертификат ISO 27001 с описанием области применения; (3) отчёт SOC 2 Type 2 (Type 1 недостаточен — он проверяет проектирование, а не функционирование); (4) обязательство хранить данные в ЕС с указанием конкретных дата-центров; (5) реестр субобработчиков с юрисдикциями; (6) опубликованные сроки уведомления о нарушениях (≤24 часа предпочтительно); (7) документацию по шифрованию, включая управление ключами; (8) права аудита по статье 28(3)(h). HexaTransfer публикует все восемь пунктов на странице доверия; авторитетные альтернативы (Tresorit, Proton, Infomaniak) поступают так же.
Относитесь к странице доверия провайдера как к договору — если её нет, провайдер несерьёзен. Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.
Безопасная отправка больших файлов со сквозным шифрованием
Передавайте файлы до 10 ГБ бесплатно со сквозным шифрованием. Регистрация не требуется. Ваши файлы шифруются в браузере перед загрузкой — никто другой не может их прочитать.
Отправить файл