본문 바로가기

DevSecOps/AWS Security

AWS IAM 정책: 리소스 기반 정책 vs ID 기반 정책 비교 정리

728x90
반응형

AWS의 보안 정책을 설계하다 보면 반드시 마주치는 두 가지 개념이 있습니다. 바로 리소스 기반 정책(Resource-based policy)ID 기반 정책(Identity-based policy) 입니다. 표면적으로는 비슷한 JSON 포맷을 사용하지만, 정책의 적용 대상, 제어 방향, 보안상 고려사항은 완전히 다릅니다.

 

이 글에서는 두 정책의 차이점을 실무 관점에서 정리하고, 어떤 상황에서 어떤 정책을 사용해야 하는지 전략적으로 정리해보겠습니다.


1. 정책의 적용 대상

 

적용 대상 IAM 사용자, 그룹, 역할 AWS 리소스(S3, Lambda, KMS 등)
주체(Principal) 명시 필요 없음 (정책을 부착한 엔터티가 주체) 필요함 (누가 접근 가능한지를 명시해야 함)
접근 제어 방향 "이 사용자가 어떤 리소스에 어떤 액션을 할 수 있는가" "이 리소스에 누가 어떤 액션을 할 수 있는가"
 

2. 정책 구성 구조

ID 기반 정책 예시

{
  "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

→ 특정 IAM 사용자 또는 역할에게 PutObject 권한을 부여.

리소스 기반 정책 예시

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:role/SomeRole"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

→ SomeRole이라는 역할이 해당 S3 객체를 읽을 수 있도록 허용.


3. 사용 위치 및 서비스 예시

 

ID 기반 정책 IAM User, Role, Group 전 서비스 공통
리소스 기반 정책 S3 Bucket, Lambda, SQS, SNS, KMS 등 일부 리소스만 지원
 

※ 예: S3 버킷은 리소스 기반 정책을 지원하지만, EC2 인스턴스는 지원하지 않음.


4. Cross-account 접근 제어에서의 차이

  • ID 기반 정책만으로는 Cross-account 허용 불가
    • 외부 계정에서 접근하려면 리소스 쪽에서 명시적으로 허용해줘야 함
  • 리소스 기반 정책은 외부 계정 명시 가능
    • Principal에 외부 계정의 ARN을 명시하여 허용 가능

예시: 외부 계정의 IAM Role이 내 S3 버킷을 읽도록 허용

"Principal": {
  "AWS": "arn:aws:iam::999988887777:role/PartnerRole"
}

5. 정책 충돌 및 병합 시 권한 평가 방식

  • AWS는 정책 병합 시 “최종 허용 여부”를 평가할 때 다음 우선순위를 따릅니다.
  • 명시적 Deny > 명시적 Allow > 암시적 Deny
  • 따라서 리소스 정책과 ID 정책이 동시에 존재할 경우
    • 둘 중 하나라도 Deny하면 최종적으로 거부됩니다
    • 둘 다 Allow여야만 권한 부여됨

6. 실무 설계 시 권장 전략

 

사내 IAM 사용자에 대한 권한 제어 ID 기반 정책
외부 계정에 리소스 공유 (Cross-account) 리소스 기반 정책
세밀한 액세스 제어 및 조건 기반 통제 ID 정책 + Condition
역할 오남용 방지 및 최소권한 구성 ID 정책 + Permissions Boundary
조직 전반에서 접근 범위 제한 SCP (Service Control Policy) 활용
 

7. 보안적 고려사항

  • 리소스 기반 정책에서 Principal이나 NotPrincipal 사용 시, 퍼블릭 접근 설정에 주의해야 함
    • 조건 없이 "*" 설정하면 누구나 접근 가능
    • CloudTrail 및 Access Analyzer로 외부 공개 여부 점검 필수
  • ID 기반 정책은 상대적으로 명확하나, Role chaining, AssumeRole 동작에 의한 간접 권한 승계에 주의 필요

마무리

AWS IAM 정책을 단순히 JSON 설정이라고 생각하면 큰 오산입니다. ID 기반 정책과 리소스 기반 정책은 접근 제어의 출발점과 방향 자체가 다르며, 이 둘을 적절히 조합해야만 실제 운영 환경에서 정교한 Least Privilege 모델을 구현할 수 있습니다.

실제 환경에서는 다음 질문을 던져가며 설계하시기 바랍니다.

  • 이 권한은 누구에게 주는 것인가?
  • 이 리소스는 누가 사용할 수 있어야 하는가?
  • 외부 계정 접근이 필요한가?
  • 향후 관리 주체가 바뀌어도 정책이 안전하게 유지될 수 있는가?
728x90
반응형