AWS 리소스 제어 정책(RCPs) 설명: 리소스 수준 보안을 위한 실용 가이드
Source: Dev.to
위에 제공된 링크에 있는 전체 글을 번역하려면, 번역할 텍스트를 그대로 복사해서 여기 붙여 주세요.
링크 자체와 코드 블록, URL은 그대로 두고, 본문 내용만 한국어로 번역해 드리겠습니다.
현대 AWS 거버넌스와 리소스 제어 정책 (RCP)
현대 AWS 환경은 규모에 맞게 설계되었습니다 — 여러 계정, 공유 팀, 경계를 넘어 운영해야 하는 리소스 등. 이러한 유연성은 민첩성을 제공하지만, 중요한 거버넌스 문제도 발생시킵니다: IAM 정책과 SCP가 올바르게 구성되어 있어도 리소스 정책이 잘못 구성될 수 있어, 과도한 접근 권한이나 의도치 않은 노출이 발생합니다.
이 격차를 정확히 해소하기 위해 **리소스 제어 정책 (Resource Control Policies, RCP)**이 만들어졌습니다.
RCP가 하는 일
RCP는 리소스에 직접 적용되는 절대적인 규칙을 강제할 수 있게 합니다, 예를 들어:
- 이 리소스는 조직 외부에 절대 공유될 수 없습니다.
- 승인된 정체성만이 여기에서 역할을 맡을 수 있습니다.
- 관리자조차도 이 규칙을 어길 수 없습니다.
Note: RCP는 IAM이나 SCP를 대체하는 것이 아니라 — 마지막으로 부족한 거버넌스 레이어를 채웁니다.
| 레이어 | 제어 대상 |
|---|---|
| IAM | 조직 가드레일 내에서 어떤 주체가 어떤 리소스에 어떤 작업을 수행할 수 있는지 |
| SCP | 계정 또는 OU 내 IAM 주체가 가질 수 있는 최대 권한; 제한은 하지만 권한을 부여하지는 않음 |
| RCP | 계정 또는 OU 내 특정 리소스에 적용될 수 있는 최대 권한, 호출 주체와 무관하게 |
실습 데모
⚠️ RCP를 프로덕션에 적용하기 전에 개발/테스트 계정에서 테스트하는 것이 강력히 권장됩니다. 루트 레벨에 직접 적용하지 마세요.
이 데모에서는 두 가지 시나리오를 다룹니다:
- 모든 S3 버킷에 대해 HTTPS‑only 접근을 강제
- 외부 계정이 KMS 키를 복호화하지 못하도록 방지 (또는 KMS 키의 교차 계정 사용 비활성화)
시나리오 #1 – S3 버킷에 HTTPS‑only 적용
1. 과도하게 허용된 버킷 정책 생성
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3rcppolicy",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::XXXX-XXXXX-demo-XXXXXXX/*"
}
]
}버킷에는 RCP HTTPS test 라는 텍스트가 들어 있는 간단한 파일이 있습니다.
2. HTTP와 HTTPS 모두 동작하는지 확인
-
HTTP 테스트
-
HTTPS 테스트
3. 계정 수준에 HTTPS만 허용하는 RCP 적용
4. 결과 확인
-
HTTP 요청 → AccessDenied (스크린샷에 강조 표시)
-
HTTPS 요청 → 성공
핵심: RCP가 적용되면 기존 및 새로 생성된 리소스 정책 모두에 적용됩니다. RCP를 강제하기 전에 조직 전체에서 의도적으로 공유되는 리소스가 무엇인지 반드시 검토하세요.
시나리오 #2 – 외부 계정이 KMS 키를 복호화하지 못하도록 방지
이 예제는 키 정책에 화이트리스트된 주체를 제외한 모든 주체에 대해 AWS KMS 키 복호화를 차단합니다.
1. 교차 계정 접근을 허용하는 샘플 KMS 키 정책
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::714XXXXXXXXX:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::599XXXXXXXXX:root"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}2. RCP 없이 복호화 테스트
-
파일 암호화 – 계정 A(
714XXXXXXXXX)의 KMS 키 사용 -
파일 복호화 – 두 계정 모두 시도
- 계정 A(동일 계정) – 성공
- 계정 B(
599XXXXXXXXX) – 교차 계정 권한 때문에 성공
계정 A 복호화 결과
계정 B 복호화 결과 (생략)
3. 교차 계정 복호화를 금지하는 RCP 적용
계정 또는 OU 수준에 적절한 RCP를 연결하면 계정 B가 키를 복호화하려는 시도는 거부되고, 계정 A는 여전히 키를 사용할 수 있습니다.
결과: RCP가 “최대 권한”을 강제하여 교차 계정 복호화를 차단합니다.
” KMS 리소스에 대한 규칙을 적용하여 외부 주체에 대한 관대함 키 정책을 무시합니다.
요약
- IAM은 누가 무엇을 어떤 리소스에 대해 할 수 있는지를 제어합니다.
- SCP는 계정/OU에서 IAM 주체가 가질 수 있는 최대 권한을 설정합니다.
- RCP는 호출자와 관계없이 특정 리소스에 적용될 수 있는 최대 권한을 설정합니다.
RCP를 추가하면 최종 거버넌스 격차를 메우게 되며, 완벽하게 작성된 IAM 정책이나 SCP조차도 잘못 구성된 리소스 정책에 의해 우회될 수 없도록 보장합니다. 비생산 계정에서 충분히 테스트한 후, 가장 중요한 리소스를 보호하도록 전략적으로 배포하십시오.
계정 A에 RCP 적용
{
"Effect": "Deny",
"Principal": "*",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": [
"714XXXXXXXXX"
]
}
}
}
리소스 제어 정책(RCP) 구현 전
RCP는 데이터 경계를 설계하기 위한 강력한 AWS 기능입니다. 데이터 보호, 침해 차단, 실제 클라우드 경계 강제화가 가능하지만, 부주의하게 배포하면 프로덕션 워크로드를 중단시킬 수도 있습니다.
중요한 워크로드에 적용하기 전에 RCP를 생성하고 테스트해야 합니다.
어떤 RCP를 배포하기 전에 반드시 정식 테스트 사이클을 거치세요.
테스트 항목
AWS IAM Access Analyzer를 사용하여 다음을 파악합니다:
- 현재 공개된 리소스는 무엇인지
- 외부와 공유된 리소스는 무엇인지
- 교차 계정 접근에 의존하는 아이덴티티는 누구인지
이를 통해 정상적인 접근 경로가 끊어지는 일을 방지할 수 있습니다.
그 다음 정책 논리를 검증합니다:
- IAM Policy Simulator
- 제어된 샌드박스 계정
- 프로덕션 전에 개발 OU
또한 Service Control Policies (SCP)와 RCP 간의 상호 작용도 테스트하세요.
기억하세요: 둘 중 하나에서 거부가 발생하면 접근이 차단됩니다.
탐색할 기타 고영향 RCP 사용 사례
AWS는 훌륭한 실제 RCP 패턴 저장소를 유지하고 있습니다:
- 🔐 조직 전용 STS 접근 강제
- 🔑 OIDC 제공자 잠금 (GitHub Actions 등)
- 🗄️ 데이터 스토어 외부 공유 차단
신중하게 사용하면 RCP는 데이터 접근, 교차 계정 신뢰 및 구성 오류와 관련된 마지막 남은 격차를 메워줍니다.
좋은 보안은 사람을 신뢰하는 것이 아니라, 실수가 발생해도 안전하게 유지되는 시스템을 설계하는 것입니다.
읽어 주셔서 감사합니다 — 이 내용이 더 안전하고 탄력적인 AWS 환경을 구축하는 데 도움이 되길 바랍니다.