[AWS] S3에서 ABAC(속성 기반 권한 제어) 설정 가이드

최근 Amazon S3(이하 S3)가 “범용 버킷(General Purpose Buckets)”에 대해 Attribute-Based Access Control(이하 ABAC) 지원을 발표했습니다.

이 기능을 잘 활용하면, 버킷마다 일일이 IAM 정책이나 버킷 정책(정적 ARN 기반)을 관리할 필요 없이, 버킷 태그만으로 접근 권한을 유연하게 관리할 수 있습니다.
아래는 S3에서 ABAC를 실제로 설정하고 운영하기 위한 단계별 가이드입니다.

왜 ABAC인가 — 기존 방식의 한계 vs 태그 기반 권한의 장점

기존에는 새 버킷을 만들거나 버킷에 접근 권한을 가진 사용자가 바뀔 때마다, IAM 정책이나 버킷 정책을 수정해야 하는 경우가 많았습니다. 특히 조직이 커지고 버킷이 많아지면 이 작업이 매우 번거롭고 실수의 여지도 늘었습니다.

 

ABAC를 사용하면:

버킷에 key-value 형태의 태그(tag)를 붙이고,

IAM 정책에 태그 기반 조건(예: aws:ResourceTag/environment = development)을 작성하면,

해당 태그를 가진 모든 버킷에 대해, 일괄적으로 권한을 부여하거나 제한할 수 있습니다.

예: 개발용 버킷에는 environment=development 태그, 운영용 버킷에는 environment=production 태그를 붙이고,
개발자 Role에는 “environment=development인 버킷만 접근 허용” 정책을 주면,
새로 생긴 ‘개발용’ 버킷은 자동으로 접근 대상이 되고, 별도 정책 수정이 필요 없습니다.

이처럼 스케일이 커져도 권한 관리가 단순해지고, 정책 수정의 부담이 크게 줄어듭니다.

S3 ABAC 활성화 — 기본 설정과 주의사항

S3의 일반 버킷에서는 기본적으로 ABAC가 비활성화 되어 있습니다.

 

따라서 태그를 기반으로 한 권한 제어를 사용하려면, 먼저 “ABAC 활성화” 절차를 거쳐야 합니다.

활성화 방법

ABAC를 활성화하려면, 콘솔 또는 API/CLI/SDK를 사용하면 됩니다.

콘솔 기준 절차는 다음과 같습니다:

S3 관리 콘솔에 로그인 → Buckets → 설정하려는 버킷 선택

“Properties” 탭 → “Bucket ABAC” 항목으로 이동 → “Enable” 토글 선택

ABAC 활성화 시, 이후 태그 변경 작업은 TagResource / UntagResource API를 사용해야 한다는 권고 확인 후 저장

CLI 예시는 다음과 같습니다:

aws s3api put-bucket-abac --bucket my-demo-bucket --abac-status Status=Enabled --region ap-northeast-2
(원한다면 Status=Disabled 로 ABAC를 끌 수도 있습니다.)

태깅 전략 설계 — 일관성 있고 안전하게

태그를 권한 제어에 사용하게 되면, 태그 설계와 관리 전략이 매우 중요해집니다. 아래는 권장되는 베스트 프랙티스입니다.

일관된 태그 키/값 명명 규칙 문서화
예: environment:development / environment:production, 혹은 proj:alpha, proj:beta 등.
서로 다른 팀이나 프로젝트 간 표준이 다르면 오작동 위험이 크므로, 초기 설계를 꼼꼼히 하는 것이 좋습니다.

자동 태깅 적용 권장
수동으로 태그를 붙이다 보면 실수하거나 누락할 수 있습니다. 따라서 IaC(예: CloudFormation) 템플릿에서 태그를 포함시키거나, 태그를 자동화된 스크립트/파이프라인으로 관리하는 것이 좋습니다.

민감 정보 금지
태그는 단순 문자열일 뿐이며, AWS는 태그에 대해 어떤 보안적 의미를 부여하지 않습니다. 따라서 개인정보(PII)나 민감한 정보를 태그에 넣는 것은 피해야 합니다.

주기적인 태그 검토 및 청소
시간이 지나면서 태그가 무분별하게 늘어나거나, 오래된 프로젝트의 태그가 남아 있을 수 있습니다. 주기적으로 태그 현황을 점검하고, 필요 없는 태그를 제거하는 것이 좋습니다.

실제 ABAC 기반 IAM 정책 예시

예를 들어, 다음과 같은 경우를 생각해볼 수 있습니다.

개발팀에게는 environment=development 태그가 붙은 버킷만 접근 허용

운영팀에게는 environment=production 태그가 붙은 버킷만 접근 허용

이럴 때, IAM 정책(JSON 예제)는 다음과 같이 작성할 수 있습니다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/environment": "development"
        }
      }
    }
  ]
}

 

 

위 정책을 ‘개발자 역할(dev-role)’에 붙이면, 해당 역할을 가지는 사용자는 environment=development 태그가 붙은 버킷에만 접근이 허용됩니다.

기존 환경 전환 시 고려사항 및 주의점

ABAC로 전환할 때 아래 사항을 꼭 확인해야 합니다.

기존에 태그-기반 조건이 있는 정책이나, 태그가 없는 버킷이 있다면, ABAC 활성화 후 의도하지 않은 권한 변화가 발생할 수 있습니다. 따라서 사전 정책 감사(audit)를 권장합니다.

ABAC 활성화 이후에는 기존 방식(tagging via PutBucketTagging / DeleteBucketTagging)이 아닌, TagResource / UntagResource API를 사용해야 합니다. 기존 코드나 스크립트가 있다면 이 부분도 점검해야 합니다.

태그가 권한 제어의 핵심이므로, 태그 키의 오타, 불일치, 누락 등으로 인해 권한이 끊기거나 예기치 않게 허용될 수 있습니다. 이 점을 항상 유의해야 합니다.

요약

S3 일반 버킷에 대해 ABAC가 새롭게 지원되면서, 태그 기반으로 권한을 자동 제어할 수 있게 되었고, 이는 특히 대규모 환경에서 매우 유용합니다.

단, ABAC를 활용하려면 태그 설계, 정책 설계, 운영 절차(태깅 자동화 포함)를 처음부터 잘 갖춰야 합니다.

기존 리소스를 전환할 경우, 정책 감사 및 태그 마이그레이션을 반드시 거쳐야 예기치 않은 권한 문제를 피할 수 있습니다.

개인적으로는, 새 프로젝트나 새 계정 구조를 설계할 때 처음부터 ABAC를 염두에 두고 태그 전략을 세우는 것이 가장 이상적이라고 생각합니다.
만약 지금 바로 설정 예시나 CloudFormation 템플릿 샘플이 필요하시다면, 원하시는 언어 (JSON, YAML, Terraform 등) 말씀해 주시면 제안 드릴 수 있습니다.