Защитите бакет с помощью политики ресурса

AWSBeginner
Практиковаться сейчас

Введение

Владелец бакета хочет предоставить одной роли отчётности доступ и защитить частные данные. Вы прикрепите политику бакета, сравните её с собственной политикой роли и проверите, как соответствующий Deny влияет на доступ.

Сначала выполните работы Используйте временные учётные данные роли IAM и Предоставьте читателю отчётов минимальные привилегии. Эта новая VM предоставляет default, report-role и other-role; профили ролей уже получают временные сеансы. Используйте /home/labex/project и AWS View. Не раскрывайте учётные данные и кеши.

Связь с сертификацией

Сертификация Задача экзамена Практика
Cloud Practitioner (CLF-C02) Задача 2.3 Политики ресурсов и приоритет явного запрета.
Solutions Architect – Associate (SAA-C03) Задача 1.1 Политики ресурсов и приоритет явного запрета.
Developer – Associate (DVA-C02) Задача 2.1 Политики ресурсов и приоритет явного запрета.
CloudOps Engineer – Associate (SOA-C03) Задача 4.1 Политики ресурсов и приоритет явного запрета.
Security – Specialty (SCS-C03) Задача 4.2 Базовая практика: Политики ресурсов и приоритет явного запрета.
Data Engineer – Associate (DEA-C01) Задача 4.2 Базовая практика: Политики ресурсов и приоритет явного запрета.
DevOps Engineer – Professional (DOP-C02) Задача 6.1 Базовая практика: Политики ресурсов и приоритет явного запрета.
Solutions Architect – Professional (SAP-C02) Задача 2.3 Базовая практика: Политики ресурсов и приоритет явного запрета.

Обзор лабораторной работы

Концептуальная схема: Сравните политику идентификации роли и политику корзины S3 для запросов отчётов в одной учётной записи; подходящий явный Deny имеет приоритет над Allow.

Предоставьте одной роли доступ со стороны бакета

На этом шаге вы прикрепите политику ресурса, предоставляющую ReportReader доступ к префиксу reports. В отличие от политики идентичности, политика бакета должна указывать Principal. Используйте ARN роли IAM, который определяет роль; ARN сеанса assumed-role определяет одно её использование.

Вы предоставляли доступ со стороны идентичности; теперь владелец бакета предоставит его со стороны ресурса. Оба профиля ролей подготовлены: сохраните их доверие и сосредоточьтесь на том, как политика бакета и политика разрешений роли влияют на одинаковые запросы.

Политика ресурса хранится на ресурсе. Политика бакета S3 — один из примеров: её Principal определяет, чьи запросы охватывает оператор. Сравните это с политикой идентичности, хранящейся у пользователя или роли.

Подтвердите две активные идентичности сеансов и изначально пустой список политик разрешений роли отчётности.

cd /home/labex/project
aws sts get-caller-identity --profile report-role --query Arn --output text
aws sts get-caller-identity --profile other-role --query Arn --output text
aws iam list-role-policies --role-name ReportReader

Ожидайте assumed-role/ReportReader/report-run и assumed-role/OtherReader/other-run, а также пустой список PolicyNames. Сама аутентификация как роль не авторизует доступ S3. Проверьте текущее чтение:

aws s3api get-object --profile report-role --bucket labex-iam04-reports --key reports/today.txt before.txt || true

Ожидайте AccessDenied. || true не позволяет ожидаемой ошибке остановить вставленную последовательность. Сбои подключения не доказывают отказ.

Напишите политику бакета. GetObject разрешает чтение объектов; Resource ограничивает его reports/ в этом одном бакете. Principal роли исключает OtherReader и не предоставляет общедоступный доступ.

cat > bucket-policy.json <<'JSON'
{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"}
  ]
}
JSON
aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-policy.json
aws s3api get-bucket-policy --bucket labex-iam04-reports --query Policy --output text

Политика бакета теперь хранится на бакете, а не прикреплена к роли. В том же аккаунте этот применимый Allow ресурса может предоставить роли доступ без отдельного Allow идентичности роли, если соответствующий Deny не блокирует его.

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key reports/today.txt today.txt
cat today.txt
aws s3api get-object --profile other-role --bucket labex-iam04-reports --key reports/today.txt other-denied.txt || true
aws s3api get-object --profile report-role --bucket labex-iam04-reports --key private/payroll.txt private-denied.txt || true
aws s3api get-object --profile report-role --bucket labex-iam04-reference --key reference.txt reference-denied.txt || true

ReportReader получает Daily orders: 145; все три других запроса получают AccessDenied. Разрешение бакета не охватывает другую роль, другой префикс или другой бакет. AWS View выполняет те же фактические чтения ролей.

Защитите частные данные от дополнительного Allow идентичности

На этом шаге вы увидите, как разрешение идентичности роли объединяется с разрешением бакета, затем используете Deny бакета для защиты частных данных. Для этих запросов в том же аккаунте применимые Allow объединяются; два источника политик не пересекаются автоматически. Явный Deny в любом применимом источнике политик отменяет Allow.

Два источника политик для запросов этой работы в том же аккаунте: соответствующий явный Deny отменяет Allow.

Временно расширьте область чтения идентичности ReportReader до объектов в этом собственном бакете. Это контролируемое сравнение охватывает синтетические данные и не предоставляет доступ к другим бакетам.

cat > role-read.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/*"}]}
JSON
aws iam put-role-policy \
  --role-name ReportReader \
  --policy-name ReadAllOwned \
  --policy-document file://role-read.json
aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key private/payroll.txt private-before-deny.txt
cat private-before-deny.txt

Ожидайте Synthetic payroll: restricted. Allow идентичности применяется, хотя Allow бакета охватывает только reports/. Добавьте Deny бакета, ограниченный этой ролью и частным префиксом, сохранив Allow отчётов.

cat > bucket-policy.json <<'JSON'
{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"},
    {"Effect":"Deny","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/private/*"}
  ]
}
JSON
aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-policy.json
aws s3api get-object --profile report-role --bucket labex-iam04-reports --key private/payroll.txt private-denied.txt || true
aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key reports/today.txt today.txt
cat today.txt

Теперь private возвращает AccessDenied вопреки Allow идентичности; отчёт по-прежнему возвращает 145. Deny называет ReportReader, поэтому оператор всё ещё может изучать и сохранять подготовленный ресурс. Порядок операторов не позволяет Allow отменить соответствующий Deny.

Подтвердите, что Deny идентичности отменяет Allow бакета

На этом шаге вы проверите обратное направление: Deny идентичности роли отменяет Allow бакета. Сохраните текущее разрешение чтения и добавьте Deny записи в префикс reports.

cat > role-read.json <<'JSON'
{"Version":"2012-10-17","Statement":[
  {"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/*"},
  {"Effect":"Deny","Action":"s3:PutObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"}
]}
JSON
aws iam put-role-policy \
  --role-name ReportReader \
  --policy-name ReadAllOwned \
  --policy-document file://role-read.json

Для контролируемой проверки приоритета временно добавьте Allow бакета для той же роли и префикса записи. Сначала примените Deny идентичности, чтобы отчёт оставался защищённым.

cat > bucket-write-test.json <<'JSON'
{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"},
    {"Effect":"Deny","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/private/*"},
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:PutObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"}
  ]
}
JSON
aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-write-test.json
aws s3api put-object --profile report-role --bucket labex-iam04-reports --key reports/today.txt --body upload.txt || true

Ожидайте AccessDenied для PutObject, хотя бакет разрешает его. Deny идентичности побеждает. Сразу удалите временный Allow записи, восстановив политику с двумя операторами, сохранённую на предыдущем шаге.

aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-policy.json
aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key reports/today.txt today.txt
cat today.txt
aws s3api get-object --profile other-role --bucket labex-iam04-reports --key reports/today.txt other-denied.txt || true

Отчёт должен остаться Daily orders: 145, а OtherReader по-прежнему получает отказ. Временное разрешение записи удалено. AWS View показывает политику бакета и политику идентичности роли рядом с фактическими результатами чтения.

Политики бакета и идентичности защищают отчёт. Пример: ReportReader может читать отчёт, а обе роли не могут читать частные и эталонные объекты. Сохранённые политики показывают отдельные источники разрешений и явные запреты; раскрытый отчёт содержит фактические возвращённые байты.

Удалите оба источника разрешений и выполните очистку

На этом шаге вы отзовёте оба источника политик перед удалением собственных данных. Удаления одного Allow недостаточно, когда другая политика всё ещё разрешает то же действие.

Удалите политику бакета, затем повторите чтение отчёта. ReadAllOwned всё ещё разрешает это чтение через политику идентичности роли.

aws s3api delete-bucket-policy --bucket labex-iam04-reports
aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key reports/today.txt remaining-grant.txt
cat remaining-grant.txt

Ожидайте Daily orders: 145. Теперь удалите ReadAllOwned и проверьте снова, пока отчёт ещё существует.

aws iam delete-role-policy --role-name ReportReader --policy-name ReadAllOwned
aws s3api get-object --profile report-role --bucket labex-iam04-reports --key reports/today.txt revoked.txt || true
aws iam list-role-policies --role-name ReportReader

Ожидайте AccessDenied и пустой список политик. Подготовленные роли и их доверие вызывающим сторонам остаются целыми; вы удаляете разрешения S3, созданные в ходе этого упражнения.

aws s3api delete-object --bucket labex-iam04-reports --key reports/today.txt
aws s3api delete-object --bucket labex-iam04-reports --key private/payroll.txt
aws s3api list-objects-v2 --bucket labex-iam04-reports

Проверьте KeyCount: 0 в этом успешном ответе, затем удалите пустой бакет отчётов и подтвердите эталонные байты.

aws s3api delete-bucket --bucket labex-iam04-reports
aws s3api list-buckets --query 'Buckets[].Name'
aws s3api get-object --bucket labex-iam04-reference --key reference.txt reference.txt
cat reference.txt

Остаётся только эталонный бакет с Platform reference: keep. Сетевые ошибки не являются свидетельством удаления. Теперь AWS View показывает отсутствие политики бакета и разрешений роли и Reports bucket removed. Подготовленные идентичности, ресурсы и локальные временные кеши освобождаются при завершении временной среды.

Резюме

Вы использовали Principal для предоставления одной роли доступа через политику бакета, увидели объединение Allow идентичности и ресурса и проверили приоритет явного Deny в обоих направлениях. Запрещённая запись не изменила байты отчёта. Вы отозвали оба источника разрешений перед ограниченной очисткой и сохранили подготовленные идентичности и посторонние данные. Изучайте все применимые источники политик, когда запрос остаётся авторизованным или неожиданно запрещён.

Подробнее см. в документации AWS: Оценка политик идентификации и ресурсов.