Защита данных: публичный доступ к S3, шифрование и класс утечек

Взлом публичного бакета и как на самом деле решается доступ

Бакеты, ключи и storage-классы ты уже знаешь из урока про хранилище. Сеньорский вопрос уже и острее: для одного GetObject — кому разрешено и что может перекрыть ошибку? Взлом из Hook — канонический: миллионы объектов наружу, потому что одна политика сказала Principal: "*". Чтобы никогда такое не выкатить, надо знать порядок, в котором S3 решает доступ, и какой контроль — последнее слово.

Доступ к объекту могут дать несколько механизмов, и они комбинируются: IAM identity-политика (что может делать principal в твоём аккаунте), bucket-политика (resource-based политика на бакете — единственная, что может дать анонимный или кросс-аккаунтный доступ) и легаси-ACL (per-object/per-bucket гранты, появившиеся раньше политик). Анонимное чтение из всего интернета случается только через bucket-политику с Principal: "*" или public-read ACL — IAM-политика никогда не сделает объект публичным, ведь у анонимных вызывающих нет IAM-идентичности. ACL — это старая модель с раскиданными грантами; AWS теперь отключает их по умолчанию (Object Ownership в режиме bucket-owner-enforced), так что современный бакет должен выражать весь доступ через одну читаемую bucket-политику, а не десятки object-ACL.

Надо всем этим стоит override, который побеждает несмотря ни на что: S3 Block Public Access (BPA). BPA — это четыре настройки, которые отклоняют публичные гранты: можно игнорировать существующие публичные ACL, блокировать новые публичные ACL, игнорировать публичные bucket-политики и ограничивать кросс-аккаунтный публичный доступ. Он применяется и на уровне аккаунта, и на уровне бакета, и когда включён, перекрывает любую политику или ACL, которые иначе сделали бы бакет публичным. Включи BPA на уровне аккаунта — и даже будущий инженер, вставивший Principal: "*", не сможет открыть данные: публичный грант просто не учитывается. Это один переключатель на весь аккаунт, побеждающий весь класс взломов:

# Защита на весь аккаунт: один вызов, нейтрализующий каждый публичный грант,
# нынешний и будущий, во всех бакетах аккаунта.
aws s3control put-public-access-block \
  --account-id 111122223333 \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# Те же четыре флага можно задать и на бакет — как defense in depth.
aws s3api put-public-access-block \
  --bucket acme-customer-data \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Чтобы дать ровно тот доступ, что ты задумал, сужай principal через conditions, а не открывай миру: aws:PrincipalOrgID ограничивает bucket-политику principal’ами внутри твоей AWS Organization, а aws:SourceArn / aws:SourceAccount привязывают кросс-сервисный доступ к тому единственному ресурсу, что должен вызывать. Failure mode самого фикса — слишком широкий кросс-аккаунтный доступ: ты даёшь другому аккаунту s3:GetObject для интеграции с партнёром, админ того аккаунта вешает wildcard на одну из своих ролей, и теперь over-privileged principal в чужом аккаунте читает твой бакет — слабым звеном была твоя политика, не их. Аудируй реальность, а не намерение, через IAM Access Analyzer, который непрерывно подсвечивает любой бакет, чья политика даёт доступ внешнему аккаунту или анонимному principal, — превращай его находки в сигнал с нулевой терпимостью.

Шифрование at rest: SSE-S3, SSE-KMS и SSE-C

Каждый объект должен быть зашифрован at rest, и S3 теперь делает это по умолчанию — но выбор ключа — реальный tradeoff. SSE-S3 использует ключи, которыми владеет и управляет AWS: бесплатно, полностью прозрачно, AES-256, ты не делаешь ничего. SSE-KMS шифрует data-key каждого объекта под customer-managed KMS-ключом (CMK) — envelope-механика разобрана в уроке IAM/KMS; здесь важно, что́ CMK тебе даёт: CloudTrail-аудит каждого encrypt/decrypt, контроль через IAM/key-политику над тем, кто может расшифровать, и возможность мгновенно отозвать доступ к данным, отключив ключ — без перезаписи объектов, любое чтение просто начинает падать. SSE-C значит, что ты поставляешь и держишь ключ на каждом запросе; AWS шифрует им и тут же забывает, так что управление ключами целиком на тебе (и потеряешь данные, если потеряешь ключ).

Tradeoff SSE-KMS — стоимость и throttling. Каждый GetObject/PutObject к SSE-KMS-объекту делает KMS API-вызов, а у KMS есть квота на rate запросов на аккаунт (обычно 5 500–50 000 запросов/секунду по региону и операции). Высоконагруженный бакет может throttle’иться на KMS, а не на S3, и KMS-запросы тарифицируются за вызов (~$0.03 за 10 000). S3 Bucket Keys это чинят: S3 генерирует короткоживущий bucket-level ключ из твоего CMK и защищает им многие объекты, срезая прямые KMS-вызовы до ~99% — что рубит и стоимость, и риск throttling. Включай Bucket Key всегда, когда используешь SSE-KMS на масштабе. Задай default encryption на бакете, чтобы ничего не приземлялось нешифрованным:

{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:111122223333:key/abcd-1234"
      },
      "BucketKeyEnabled": true
    }
  ]
}

Шифрование in transit и enforcement политикой

Шифрование at rest ничего не делает для байтов на проводе; ещё нужен TLS in transit, и сеньорский ход — принудить его, а не надеяться, что клиенты используют HTTPS. Bucket-политика может запретить любой запрос, где aws:SecureTransport равно false, так что plain-HTTP GetObject отклоняется напрочь. Та же политика может запретить загрузки, не несущие требуемый тобой заголовок шифрования, так что ничего не приземлится нешифрованным, даже если клиент забыл. Failure mode забыть про это: клиентская библиотека дефолтится в HTTP, креды и байты объекта идут по сети в открытом виде, и атакующий с сетевой позиции их читает — шифрование at rest данных и не видело. Принудь оба одной политикой:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::acme-customer-data",
        "arn:aws:s3:::acme-customer-data/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "DenyUnEncryptedUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::acme-customer-data/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    }
  ]
}

Чтобы держать S3-трафик целиком вне публичного интернета, маршрутизируй его через gateway VPC endpoint для S3 и прикрепи endpoint-политику; условие bucket-политики на aws:SourceVpce тогда может требовать, чтобы чтения шли только через твой endpoint, так что даже утёкшие креды бесполезны снаружи VPC. Defense in depth: BPA закрывает публичный доступ, statement deny-insecure-transport закрывает провод, а endpoint закрывает путь.

Lifecycle, снижение экспозиции и правда о misconfiguration

Самые дешёвые в защите данные — те, что ты вообще не хранил: собирай минимум и удаляй по расписанию через lifecycle-expiration, чтобы будущему взлому было что утечь меньше. Для контролируемого шаринга presigned URL лучше, чем делать что-либо публичным, но их безопасность и есть их срок: URL несёт права подписавшего на одну операцию до истечения, и presigned URL со сроком 7 дней, попавший в лог, в заголовок referrer или в сообщение Slack, — это открытая на неделю дверь к тому объекту. Подписывай на минуты, сужай до одного ключа и одной операции и никогда не переиспользуй долгоживущую идентичность подписанта для публичных URL.

Против удаления и ransomware складываются три фичи: versioning хранит каждую прежнюю версию, так что перезапись или удаление восстановимы; MFA-delete требует аппаратный/виртуальный MFA-токен для перманентного удаления версии, так что одних украденных кредов мало, чтобы стереть историю; а Object Lock (WORM — write once, read many) делает объекты неизменяемыми на срок хранения, так что даже админ или атакующий не изменит и не удалит их до истечения. Сквозная мысль через всё это: подавляющее большинство S3-взломов — это misconfiguration (публичный грант, слишком широкая кросс-аккаунтная политика, утёкший долгоживущий URL), а не сломанная криптография. AES-256 — не твоё слабое место; слабое место — конфигурация доступа перед ним.