Защита данных в облаке

Как сделать так, чтобы даже при ошибке в доступе или утечке диска данные оставались нечитаемыми — и чтобы публичный бакет не стал заголовком новостей.

Шифрование данных в облаке делится на два режима: at-rest (данные на дисках, в бакетах, бэкапах) и in-transit (данные в пути по сети). Ключи к этому шифрованию хранит и контролирует KMS (Key Management Service).

Защита данных — последний рубеж. Даже если IAM дал сбой или диск физически украли, корректное шифрование оставляет атакующему бесполезный набор байт. Но шифрование «работает» лишь тогда, когда правильно настроено: включено по умолчанию, ключи под контролем, а доступ к хранилищу не открыт всему интернету.

Зачем это знать защитнику

Самые громкие облачные утечки — это не криптоанализ, а открытый доступ к незашифрованным данным: публичный бакет с персональными данными, реплика базы без TLS, бэкап на диске без шифрования. Защитник снижает ущерб двумя независимыми слоями: шифрованием (данные нечитаемы без ключа) и контролем доступа (до данных нельзя дотянуться). Эти слои дополняют, а не заменяют друг друга.

Полезно помнить про модель общей ответственности: провайдер отвечает за безопасность самого облака (физика дата-центров, гипервизор, надёжность сервиса KMS), а вы — за безопасность в облаке: какие данные кладёте, включено ли шифрование, кому открыт доступ, как настроены ключи. Никакая «облачность» не спасёт, если бакет публичен, — это ваша зона. И ещё один важный нюанс: данные опаснее всего там, где о них забыли. Старые снапшоты, временные дампы для отладки, тестовые реплики «боевой» базы — всё это полноценные копии данных, которые часто остаются незашифрованными и с широким доступом. Поэтому защита данных начинается с вопроса «а где вообще лежат наши данные и все их копии».

Шифрование at-rest

Включайте шифрование хранилищ по умолчанию — для бакетов, дисков, баз, очередей, бэкапов. В облаке это обычно один флаг, но его забывают. Лучше задать его в IaC, чтобы безопасное состояние было «по коду»:

# Шифрование бакета включено через управляемый ключ KMS
resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data.arn
    }
  }
}

Шифрование in-transit

Любой трафик с данными должен идти по TLS: клиент → API, сервис → база, между микросервисами. Запрещайте незашифрованные подключения на уровне политики — например, отклоняйте запросы к бакету без TLS:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::data-bucket/*",
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}

Так даже случайный http://-запрос будет отвергнут, а не выполнен в открытую.

Управление ключами (KMS) и envelope encryption

Безопасность шифрования сводится к безопасности ключей. KMS хранит ключи, ограничивает доступ к ним политиками и пишет каждое использование в аудит. Шифровать терабайты напрямую мастер-ключом дорого, поэтому применяется envelope encryption: данные шифруются быстрым data key, а сам data key шифруется мастер-ключом KMS и хранится рядом в зашифрованном виде.

Envelope encryption — схема:
1) KMS выдаёт data key: открытый (для шифрования сейчас) + зашифрованный мастер-ключом.
2) Данные шифруются открытым data key; открытый ключ стирается из памяти.
3) Рядом с данными хранится только зашифрованный data key.
4) Для расшифровки: KMS расшифровывает data key (проверив права) -> им расшифровывают данные.

Дополнительно: ротация ключей по расписанию, отдельные ключи на разные классы данных, и доступ к расшифровке только у тех ролей, кому он действительно нужен (см. предыдущий урок про IAM).

Классификация данных

Нельзя защитить одинаково всё — да и не нужно. Классификация делит данные по чувствительности и задаёт уровень защиты для каждого класса:

Классификация подсказывает, где включить дополнительный аудит, маскирование/токенизацию и более жёсткие политики KMS, а где достаточно базовых мер. Для персональных данных помните и про правовые требования к хранению.

Защита от утечки через мисконфиг

Шифрование не спасёт, если хранилище открыто, а доступ к ключу выдан слишком широко. Базовые меры против «случайной публикации»:

• Блокировка публичного доступа к бакетам на уровне аккаунта (а не только бакета).
• Сканирование IaC и облака на открытые/незашифрованные хранилища (см. урок про IaC).
• Предотвращение утечки секретов в код (gitleaks/trufflehog в CI), ротация при утечке.
• Узкие политики KMS: право на расшифровку — только нужным ролям.
• Логирование доступа к данным и алерты на аномальную выгрузку.

Как это работает под капотом

Server-side encryption встроено в сервис хранилища: при записи объект прозрачно шифруется data key, при чтении — расшифровывается, если у вызывающей роли есть права и на объект, и на ключ KMS. Поэтому доступ к данным фактически защищён двумя политиками: к ресурсу и к ключу. TLS защищает данные в пути симметричным сеансовым ключом, согласованным в ходе рукопожатия. KMS никогда не отдаёт мастер-ключ наружу — операции шифрования/расшифровки происходят внутри сервиса, а каждое обращение фиксируется в логах аудита, что даёт и контроль, и расследование.

Как защититься

• Включай шифрование at-rest по умолчанию для всех хранилищ и бэкапов, задавай это в IaC.
• Требуй TLS для всего трафика с данными и отклоняй незашифрованные подключения политикой.
• Храни ключи в KMS, используй envelope encryption, включай ротацию и узкий доступ к расшифровке.
• Классифицируй данные и усиливай защиту пропорционально чувствительности.
• Закрывай главный вектор утечки — мисконфиг: блокировка публичного доступа, сканирование, защита секретов, логирование доступа.

Юридическое напоминание: тестировать защиту данных можно только в своих системах/стенде. Персональные данные дополнительно регулируются законом; несанкционированный доступ к чужим данным наказуем (УК РФ ст. 272).

Итоги

• Шифрование (нечитаемость) и контроль доступа (недосягаемость) — два дополняющих слоя защиты данных.
• At-rest и in-transit включают по умолчанию; безопасное состояние закрепляют в IaC.
• KMS и envelope encryption делают управление ключами безопасным и аудируемым.
• Большинство утечек — это мисконфиг доступа к незашифрованным данным; именно его закрывают в первую очередь.