Введение
Владелец бакета хочет предоставить одной роли отчётности доступ и защитить частные данные. Вы прикрепите политику бакета, сравните её с собственной политикой роли и проверите, как соответствующий 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 | Базовая практика: Политики ресурсов и приоритет явного запрета. |
Обзор лабораторной работы

Предоставьте одной роли доступ со стороны бакета
На этом шаге вы прикрепите политику ресурса, предоставляющую 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.

Временно расширьте область чтения идентичности 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 показывает политику бакета и политику идентичности роли рядом с фактическими результатами чтения.

Удалите оба источника разрешений и выполните очистку
На этом шаге вы отзовёте оба источника политик перед удалением собственных данных. Удаления одного 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: Оценка политик идентификации и ресурсов.



