Ответ
Amazon S3 предоставляет несколько методов шифрования для защиты данных как при хранении (encryption at rest), так и при передаче (TLS). Основные типы:
1. Шифрование на стороне сервера (Server-Side Encryption - SSE):
- SSE-S3: S3 управляет ключами шифрования (используется AES-256). Простой в использовании, не требует управления ключами. Указывается заголовком
x-amz-server-side-encryption: AES256. - SSE-KMS: Использует AWS Key Management Service (KMS) для управления ключами и контроля доступа. Позволяет использовать CMK (Customer Master Keys), создавать детализированные политики, а также аудит использования ключей через CloudTrail. Указывается заголовком
x-amz-server-side-encryption: aws:kms. Может незначительно влиять на производительность и имеет лимиты запросов. - SSE-C: Клиент предоставляет собственные ключи шифрования для S3. AWS не хранит эти ключи, они используются только для шифрования/дешифрования во время операции и должны передаваться с каждым запросом.
2. Шифрование на стороне клиента (Client-Side Encryption):
- Данные шифруются локально, до отправки в S3, с использованием собственных ключей или ключей из AWS KMS. AWS никогда не видит незашифрованные данные. Это наиболее безопасный, но и наиболее сложный в реализации метод.
Практика: В инфраструктуре как код (например, Terraform) мы всегда явно задаем шифрование для критичных бакетов:
resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
bucket = aws_s3_bucket.example.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "aws:kms"
kms_master_key_id = aws_kms_key.s3_key.arn
}
}
}По умолчанию все новые бакеты имеют настройки шифрования, но явное указание — это best practice для безопасности и compliance.
