Облачное хранилище Соответствие: GDPR, HIPAA, и Beyond

Соответствие требованиям при облачном хранении данных означает доказательство четырёх вещей аудиторам: данные зашифрованы в покое и при передаче; доступ журналируется и ограничен необходимым минимумом; сроки хранения следуют задокументированной политике; географические ограничения соответствуют регуляторным границам. GDPR, HIPAA, SOC 2 Type II, PCI DSS 4.0, 152-ФЗ и CCPA добавляют нюансы — права субъектов данных по статье 17 GDPR, Security Rule HIPAA по 45 CFR 164.308-164.316, требование PCI DSS 3.5 к данным карт в покое, обязательства по локализации по 152-ФЗ, — но все они основаны на общем скелете, который можно выстроить один раз.

152-ФЗ: локализация данных и обязанности оператора

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

Практические последствия для хранилища: основное хранение через Яндекс.Облако, SberCloud, Mail.ru Cloud Solutions или московский регион AWS. Репликация за рубеж допустима как копия для аварийного восстановления, но первичная база данных должна оставаться в России. Вести учёт всех категорий обрабатываемых персональных данных и целей обработки, уведомить Роскомнадзор об операторской деятельности, назначить ответственного за обработку.

GDPR: правовое основание и право на удаление

Хранение персональных данных резидентов ЕС в облачных бакетах влечёт обязательства по GDPR независимо от расположения компании. Статья 6 требует задокументированного правового основания — согласия, договора, законного интереса или одного из трёх других — для каждого вида обработки. Статья 30 требует ведения Реестра операций обработки (ROPA) с указанием данных, цели, получателей и сроков хранения.

Статья 17 (право на удаление) — операционный гвоздь. При запросе субъекта данных на удаление у вас 30 дней, чтобы очистить его файлы из основного хранилища, резервных копий и всех реплицированных уровней. Теги на уровне объекта (data-subject-id: 4829) делают это выполнимым; в противном случае придётся искать по петабайтам. S3 Object Tagging и Azure Blob Index Tags поддерживают индексированное удаление в масштабе.

HIPAA: BAA, шифрование и шестилетний журнал

HIPAA Security Rule содержит три категории мер защиты — административные (§164.308), физические (§164.310) и технические (§164.312). Для облачного хранилища наиболее важны технические: контроль доступа (уникальные идентификаторы, автоматический выход, шифрование), аудиторские контроли (запись и анализ активности), контроль целостности и безопасность передачи.

С каждым облачным провайдером, обрабатывающим PHI, необходимо подписать Business Associate Agreement (BAA). AWS, Azure, Google Cloud и Cloudflare подписывают BAA; небольшие потребительские сервисы обычно нет. Храните журналы аудита шесть лет по §164.316(b)(2)(i). Шифрование «адресуемо», а не «обязательно», но практика правоприменения OCR относится к нему как фактически обязательному — нарушения при незашифрованных ноутбуках в среднем обходятся $1,8 млн урегулирования.

SOC 2 Type II: критерии доверительных сервисов

SOC 2 — не регулирование, а система, которую аудиторы используют для сертификации контролей в части Безопасности, Доступности, Целостности обработки, Конфиденциальности и Приватности. Отчёты Type II охватывают период наблюдения 6–12 месяцев и именно они реально требуются корпоративным клиентам перед подписанием.

Для облачного хранилища ключевые контроли: CC6.1 (логический доступ), CC6.6 (шифрование в транзите), CC6.7 (шифрование в покое), CC7.2 (мониторинг). Аудиторские свидетельства: экспорт IAM-политик, записи о ротации ключей KMS, логи CloudTrail, политики бакетов. Vanta, Drata и Secureframe автоматизируют сбор свидетельств; ручной SOC 2 стоит 400–600 инженерных часов в год.

PCI DSS 4.0: область действия данных карт

Если в бакетах есть файл с PAN (номером основного счёта), весь бакет входит в область PCI. PCI DSS 4.0 требование 3.5 обязывает PAN быть нечитаемыми везде, где они хранятся — через однонаправленное хеширование (SHA-256), усечение, токенизацию или шифрование AES-256 со строгим управлением ключами.

Требование 4.2.1 предписывает стойкую криптографию для данных карт по публичным сетям — TLS 1.2+ минимум (1.3 предпочтительно). Требование 10 предусматривает журналирование всего доступа к данным карт с ежедневным обзором. Наиболее дешёвая стратегия соответствия: не хранить PAN изначально. Токенизируйте на уровне платёжного процессора и храните в облачных файлах только токены.

Трансграничная передача данных

После Schrems II перемещение данных ЕС в США без надлежащих гарантий является нарушением. Рамочное соглашение ЕС-США о конфиденциальности данных (июль 2023) вновь разрешило передачу в сертифицированные американские компании, но не все сертифицированы. Стандартные договорные статьи (SCC) остаются резервным вариантом, а новые шаблоны SCC 2021 года требуют Оценки воздействия на передачу.

Для хранения: выбирайте регионы осознанно. AWS eu-west-3 (Париж), Azure France Central, Google europe-west9 (Париж) сохраняют данные в ЕС. Реплицируйте только в другие регионы ЕС, если передача не покрыта SCC, сертификацией DPF или явным согласием. Для данных россиян: ограничение локализации по 152-ФЗ действует независимо от GDPR — обе нормы применяются одновременно при обработке данных резидентов обеих юрисдикций.

Архитектура шифрования, удовлетворяющая всем требованиям

Общий знаменатель для GDPR, HIPAA, PCI, SOC 2 и 152-ФЗ: шифрование в покое и при передаче с задокументированным управлением ключами. Используйте AES-256-GCM в покое (AWS KMS, Azure Key Vault, Google Cloud KMS) и TLS 1.3 в транзите. Ротируйте мастер-ключи клиентов не реже одного раза в год.

Для особо чувствительных рабочих нагрузок клиентское шифрование полностью исключает открытый текст от провайдера. Инструменты с zero-knowledge E2EE — шифрование в браузере с ключами, производными от PBKDF2, загрузка только шифротекста — упрощают аргументацию соответствия, поскольку провайдер не может получить доступ к данным даже по судебному предписанию. HexaTransfer работает именно так для специальной передачи файлов в проектах, чувствительных к соответствию требованиям.

Пайплайн доказательств, а не папка с бумагами

Аудиторы хотят непрерывные свидетельства, а не снимок, собранный за неделю до проверки. Направляйте CloudTrail/Activity Log/Cloud Audit Logs в SIEM (Splunk, Elastic, Datadog). Тегируйте каждый ресурс с owner, data-classification, retention-policy. Запускайте автоматизированные проверки конфигурации через AWS Config Rules, Azure Policy или Open Policy Agent.

Документируйте контроль, источник свидетельства и владельца в единой матрице. Когда аудитор спрашивает «как вы знаете, что MFA обязательна для бакета?», ответом должен быть скриншот из ежедневного автоматизированного отчёта, а не лихорадочный поиск в консоли. Организации, легко проходящие аудит, — это те, кто воспринимает соответствие требованиям как пайплайн, а не как событие.

Попробуйте на hexatransfer.com — бесплатно, без аккаунта, до 10 ГБ.