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/*"
}
"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/*"
}
"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"
}
"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
반응형
'DevSecOps > AWS Security' 카테고리의 다른 글
AWS IAM 정책의 Resource vs NotResource (1) | 2025.07.01 |
---|---|
AWS IAM 정책의 Action vs NotAction (0) | 2025.07.01 |
AWS IAM 정책에서 Principal과 NotPrincipal의 차이 (1) | 2025.07.01 |
[AWS Workshop] AWS Network Firewall의 세션 상태 복제 기능으로 고가용성 확보하기 (1) | 2025.06.15 |
[AWS Workshop] AWS Network Firewall 트래픽 분석 모드와 자동 도메인 보고서: 도메인 기반 제어를 자동화하는 방법 (2) | 2025.06.13 |