리소스 정책으로 버킷 보호하기

소개

버킷 소유자는 보고서 역할 하나에 접근을 부여하고 비공개 데이터를 보호하려 합니다. 버킷 정책을 연결하고 역할 자체의 정책과 비교한 뒤 일치하는 Deny가 접근에 미치는 영향을 테스트합니다.

먼저 IAM 역할로 임시 자격 증명 사용하기와 보고서 읽기 신원에 최소 권한 부여하기를 완료하세요. 새 VM은 default, report-role, other-role을 제공합니다. 역할 프로필은 이미 임시 세션을 얻도록 되어 있습니다. /home/labex/project와 AWS View를 사용하세요. 자격 증명과 캐시는 비공개로 유지하세요.

인증 시험 관련 주제

실습 개요

버킷에서 역할 하나에 접근 부여하기

이 단계에서는 ReportReader에 reports 접두사 접근을 부여하는 리소스 정책을 연결합니다. 신원 정책과 달리 버킷 정책에는 Principal을 지정해야 합니다. 역할을 식별하는 IAM 역할 ARN을 사용하세요. assumed-role 세션 ARN은 역할 사용 한 번을 식별합니다.

신원 측에서 접근 권한을 부여해 보았습니다. 이제 버킷 소유자가 리소스 측에서 권한을 부여합니다. 두 역할 프로파일은 준비되어 있으므로 신뢰를 그대로 유지하고, 버킷 정책과 역할 권한 정책이 같은 요청에 미치는 영향에 집중합니다.

리소스 정책은 리소스에 저장됩니다. 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는 관련 Deny가 막지 않는다면 별도 역할 신원 Allow 없이 역할에 접근을 부여할 수 있습니다.

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가 reports/만 포함해도 신원 Allow가 적용됩니다. 보고서 Allow를 유지하면서 이 역할과 비공개 접두사로 제한된 버킷 Deny를 추가하세요.

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

신원 Allow가 있어도 비공개 객체는 이제 AccessDenied를 반환하며 보고서는 여전히 145를 반환합니다. Deny가 ReportReader를 지정하므로 운영자는 제공 리소스를 계속 확인하고 보존할 수 있습니다. 문 순서로 Allow가 일치하는 Deny를 무시하게 할 수는 없습니다.

신원 Deny가 버킷 Allow보다 우선하는지 확인하기

이 단계에서는 반대 방향을 테스트합니다. 역할 신원 Deny가 버킷 Allow보다 우선합니다. 현재 읽기 권한을 유지하고 reports 접두사의 쓰기에 대한 Deny를 추가하세요.

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

버킷이 허용해도 PutObject AccessDenied를 예상하세요. 신원 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와 리소스 Allow가 결합되는 방식을 관찰했습니다. 양방향으로 명시적 Deny 우선순위를 테스트했습니다. 금지된 쓰기는 보고서 바이트를 변경하지 않았습니다. 범위를 지정한 정리 전에 두 권한 출처를 모두 회수하고 준비된 신원과 관련 없는 데이터를 보존했습니다. 요청이 계속 허용되거나 예상과 달리 거부되면 적용 가능한 모든 정책 출처를 확인하세요.

자세한 내용은 AWS 공식 문서를 참고하세요: 자격 증명 기반 정책과 리소스 기반 정책 평가.