오늘 AWS Organizations에서 관리하는 새로운 권한 부여 정책인 리소스 제어 정책(RCP)을 소개합니다. 리소스 제어 정책(RCP)은 조직 전체의 리소스에 부여할 수 있는 최대 권한을 설정하는 데 사용할 수 있습니다. 리소스 제어 정책(RCP)은 AWS 환경에 데이터 경계를 설정하고 대규모로 리소스에 대한 외부 액세스를 제한하는 데 도움이 되는 예방적 제어 수단입니다. Organizations 내에서 일괄적으로 적용되는 RCP는 AWS 계정 내의 리소스에 대한 액세스가 조직의 액세스 제어 지침에 부합한다는 것을 중앙 거버넌스 및 보안 팀이 확신할 수 있게 해줍니다.
RCP는 모든 상용 AWS 리전에서 사용할 수 있으며, 출시 시점에는 Amazon Simple Storage Service(Amazon S3), AWS Security Token Service(AWS STS), AWS Key Management Service(AWS KMS), Amazon Simple Queue Service(Amazon SQS), AWS Secrets Manager 등의 서비스에서 지원됩니다.
RCP 활성화 및 사용에 따른 추가 요금은 없습니다.
서비스 제어 정책(SCP 과 어떻게 다른가요?
RCP는 성격이 비슷하지만 서비스 제어 정책(SCP)을 보완하지만 독립적으로 작동합니다.
서비스 제어 정책(SCP)을 사용하면 AWS Identity and Access Management(IAM) 역할과 같이 조직 내 위탁자에게 부여되는 권한을 제한할 수 있습니다. Organizations 내에서 일괄적으로 이러한 권한을 제한함으로써 AWS 서비스, 특정 리소스에 대한 액세스뿐만 아니라 위탁자가 여러 AWS 계정에서 요청을 보낼 수 있는 조건도 제한할 수 있습니다.
반면 RCP를 사용하면 조직의 리소스에 부여되는 권한을 제한할 수 있습니다. Organizations 내에서 RCP를 중앙 집중식으로 구현하므로 여러 AWS 계정의 리소스에 액세스 제어를 일관되게 적용할 수 있습니다. 예를 들어 조직에 속한 위탁자만 액세스할 수 있도록 계정의 S3 버킷에 대한 액세스를 제한할 수 있습니다. RCP는 API를 요청한 주체가 누구인지에 관계없이 리소스가 액세스될 때 평가됩니다.
SCP와 RCP는 모두 어떠한 권한도 부여하지 않는다는 것을 유의하세요. 조직의 위탁자와 리소스에 부여할 수 있는 최대 권한을 설정할 뿐입니다. 따라서 ID 기반 또는 리소스 기반 정책과 같은 적절한 IAM 정책을 사용하여 권한을 부여해야 합니다.
SCP와 RCP의 할당량은 서로 완전히 별개입니다. 각 RCP는 최대 5,120자까지 포함할 수 있습니다. 조직 루트, 각 OU 및 계정에 최대 5개의 RCP를 연결할 수 있으며, 조직별로 최대 1,000개의 RCP를 생성하고 저장할 수 있습니다.
시작하기
RCP를 사용하려면 먼저 RCP를 활성화해야 합니다. RCP는 Organizations 콘솔, AWS SDK 또는 AWS Command Line Interface(AWS CLI)를 사용하여 활성화할 수 있습니다. Organizations 관리 계정 또는 위임된 관리자만 정책 유형을 활성화하거나 비활성화할 수 있으므로, 해당 계정을 사용해야 합니다.
‘모든 기능’ 옵션을 활성화하여 Organizations를 사용하고 있는지 확인합니다. ‘통합 결제 기능’ 모드를 사용하는 경우 RCP를 활성화하려면 먼저 모든 기능을 사용하도록 마이그레이션해야 합니다.
콘솔 사용자의 경우 먼저 Organizations 콘솔로 이동합니다. 정책을 선택하면 리소스 제어 정책을 활성화하는 옵션이 표시됩니다.
RCP가 활성화되면 이제 리소스 제어 정책 페이지에서 RCPFullAWSAccess라는 새 정책을 사용할 수 있습니다. 이 정책은 자동으로 생성되어 루트, 각 OU 및 AWS 계정을 비롯한 조직의 모든 엔터티에 연결되는 AWS 관리형 정책입니다.
이 정책은 모든 위탁자가 조직의 리소스에 대해 어떤 작업이든 수행할 수 있도록 허용합니다. 즉, 사용자가 자체 RCP를 생성하여 연결하기 전까지는 기존의 모든 IAM 권한이 그대로 적용됩니다.
실제 모습은 다음과 같습니다.
RCP 생성
이제 첫 번째 RCP를 생성할 준비가 되었습니다. 예를 하나 살펴보겠습니다.
기본적으로 AWS 리소스는 외부 위탁자의 액세스를 허용하지 않습니다. 리소스 소유자가 정책을 구성하여 외부 위탁자의 액세스를 명시적으로 허용해야 합니다. 개발자가 애플리케이션 요구 사항에 따라 리소스 기반 정책을 유연하게 설정할 수 있지만, RCP를 사용하면 중앙의 IT 팀이 조직 내의 리소스 전반에 대해 유효한 권한을 지속적으로 제어할 수 있습니다. 따라서 개발자가 광범위한 액세스를 허용하더라도 조직의 보안 요구 사항에 따라 외부 ID의 액세스는 여전히 제한됩니다.
조직 내의 위탁자만 액세스할 수 있도록 S3 버킷에 대한 액세스를 제한하는 RCP를 생성해 보겠습니다.
리소스 제어 정책 페이지에서 정책 생성을 선택하면 새 정책을 작성할 수 있는 페이지로 이동합니다.
이 정책의 이름을 EnforceOrgIdentities로 지정하겠습니다. 이 정책의 기능을 한눈에 쉽게 알고 적절하게 태깅할 수 있도록 명확한 설명을 입력하는 것이 좋습니다.
다음 섹션에서는 정책 문을 편집할 수 있습니다. 미리 채워진 정책 템플릿을 내 정책으로 바꿉니다.
자세히 살펴보겠습니다.
Version – IAM 정책의 표준이자 필수 요소입니다. AWS는 이전 버전과의 호환성을 유지하므로 최신 버전(현재 2012-10-17)을 사용하더라도 기존 정책을 위반하지 않고 새로운 기능을 사용할 수 있습니다.
Statement – 하나 이상의 명령문 객체를 포함하는 배열입니다. 이러한 명령문 객체 각각은 단일 권한 또는 권한 세트를 정의합니다.
Sid – 정책 관리 및 문제 해결에 유용하게 사용할 수 있는 선택적 필드입니다. 이 JSON 정책 문서의 범위 내에서 고유해야 합니다.
Effect – 앞서 설명했듯이, 기본적으로 조직의 모든 엔터티에 연결된 모든 AWS 위탁자, 작업 및 리소스에 대한 액세스를 허용하는 RCP가 적용됩니다. 따라서 제한을 적용하려면 Deny를 사용해야 합니다.
Principal – RCP의 경우 이 필드는 항상 “*”로 설정해야 합니다. 이 정책을 특정 위탁자에게만 적용하려면 Condition 필드를 사용합니다.
Action – 이 정책이 적용되는 AWS 서비스와 작업을 지정합니다. 이 예에서는 액세스 제어 지침에 부합하지 않는 Amazon S3와의 상호 작용을 모두 거부해야 합니다.
Resource – RCP가 적용되는 리소스를 지정합니다.
Condition – 각 요청에 정책을 적용할지 여부를 결정하기 위해 평가하는 조건의 모음입니다.
RCP를 적용하려면 모든 조건이 true로 평가되어야 한다는 것을 유의하세요. 이 예에서는 두 가지 조건을 적용합니다.
1. 외부 위탁자가 보낸 요청인가?
“StringNotEqualsIfExists”:
{
“aws:PrincipalOrgID”: “[MY ORG ID]”
}
이 조건은 먼저 요청에 aws:PrincipalOrgID 키가 있는지 확인합니다. 그렇지 않은 경우 이 조건은 추가 평가 없이 true로 평가됩니다.
존재하는 경우 해당 값을 조직 ID와 비교합니다. 값이 같으면 false로 평가됩니다. 즉, 모든 조건이 true로 평가되어야 하므로 RCP가 적용되지 않습니다. 이는 조직에 속한 위탁자의 액세스를 거부하지 않도록 하기 위해 의도된 동작입니다.
하지만 이 값이 조직 ID와 일치하지 않는다면 조직 외부의 위탁자가 요청을 했다는 뜻입니다. 이 경우 조건이 true로 평가됩니다. 즉, 두 번째 조건도 true로 평가된다면 RCP를 적용할 수 있습니다.
2. AWS 서비스에서 들어오는 요청인가?
“BoolIfExists”:
{
“aws:PrincipalIsAWSService”: “false”
}
이 조건은 요청에 aws:PrincipalIsAWSService라는 특수 키가 포함되어 있는지 테스트합니다. 이 키는 서명된 모든 API 요청의 요청 컨텍스트에 자동으로 삽입되며, AWS CloudTrail과 같은 AWS 서비스에서 S3 버킷에 이벤트를 쓰는 경우 true로 설정됩니다. 이 키가 없는 경우 이 조건은 true로 평가됩니다.
이 키가 있는 경우에는 그 값을 우리가 명령문에서 선언한 값과 비교하게 됩니다. 이 예에서는 값이 false인지 테스트합니다. false인 경우 true 반환합니다. 이는 AWS 서비스에서 요청한 것이 아니라 조직 외부의 사람이 요청했을 가능성이 여전히 있음을 의미하기 때문입니다. 그렇지 않으면 false를 반환합니다.
즉, 요청의 출처가 조직 내의 위탁자 또는 AWS 서비스가 아닌 경우 S3 버킷에 대한 액세스가 거부됩니다.
이 정책은 예시일 뿐이며 조직의 고유한 비즈니스 및 보안 목표에 따라 맞춤화해야 합니다. 예를 들어 비즈니스 파트너의 액세스를 허용하거나, 여러분을 대신해서만 리소스에 액세스할 수 있도록 AWS 서비스에 대한 액세스를 제한하는 등의 방법으로 이 정책을 사용자 지정할 수 있습니다. 자세한 내용은 Establishing a data perimeter on AWS: Allow only trusted identities to access company data를 참조하세요.
RCP 연결
RCP를 연결하는 프로세스는 SCP와 비슷합니다. 앞서 설명한 것처럼 조직의 루트, OU 또는 조직 내의 특정 AWS 계정에 RCP를 연결할 수 있습니다.
RCP를 연결한 후에는 영향을 받는 AWS 리소스에 대한 액세스 요청이 RCP의 제한 조건에 부합해야 합니다. RCP를 대규모로 적용하기 전에 RCP가 계정의 리소스에 미치는 영향을 철저히 테스트하는 것이 좋습니다. 첫 단계로, 개별 테스트 계정 또는 테스트 OU에 RCP를 연결할 수 있습니다.
실제 모습 보기
이제 RCP를 생성하고 연결했으니 실제로 어떤 모습인지 살펴보겠습니다. 개발자가 리소스 기반 정책을 조직의 S3 버킷에 연결하고 외부 계정의 ID에 액세스 권한을 명시적으로 부여했다고 가정해 보겠습니다.
RCP는 사용자가 RCP에서 허용하는 것보다 더 많은 액세스를 허용하는 리소스 기반 정책을 저장하는 것을 막지 않습니다. 하지만 앞서 살펴본 것처럼 권한 부여 프로세스의 일부로 RCP가 평가되므로, 외부 ID에 의한 요청은 이와 관계없이 거부됩니다.
이번에는 AWS CLI에서 이 외부 계정으로 버킷에 액세스하여 이를 확인해 보겠습니다.
환경의 RCP 배포 규모 조정
지금까지 콘솔을 사용하여 RCP를 관리하는 방법을 살펴보았습니다. 하지만 대규모 제어 관리를 위해서는 이를 코드형 인프라로 구성하고 기존의 지속적 통합 및 지속적 전송(CI/CD) 파이프라인과 프로세스에 통합되도록 해야 합니다.
AWS Control Tower를 사용하는 경우 SCP 기반 제어 외에 RCP 기반 제어도 배포할 수 있습니다. 일례로, 외부 위탁자가 조직의 S3 버킷에 액세스하지 못하도록 한 이전 예에서 생성한 것과 유사한 RCP를 AWS Control Tower를 사용하여 배포할 수도 있습니다. 그러면 RCP가 관리 계정의 리소스에 일관되게 적용되므로, 대규모 액세스 제어 거버넌스가 간소화되고 중앙 집중화됩니다.
또한 AWS Control Tower는 SCP와 마찬가지로 RCP에 대한 드리프트 탐지도 지원합니다. RCP가 AWS Control Tower 외부에서 수정되거나 제거되면 드리프트에 대한 알림이 제공되고 문제 해결 단계가 제시됩니다.
결론
리소스 제어 정책(RCP)은 조직의 AWS 리소스에 부여할 수 있는 최대 권한에 대한 중앙 집중식 관리 기능을 제공합니다. RCP는 SCP와 마찬가지로 전체 AWS 환경에 데이터 경계를 중앙에서 설정하고 의도치 않은 액세스를 대규모로 방지하는 데 유용합니다. SCP와 RCP는 다양한 일련의 보안 목표를 달성할 수 있는 독립적인 제어 수단입니다. SCP 또는 RCP만 활성화하거나 두 정책 유형을 함께 사용하여, 심층 방어 보안 모델의 일부로서 포괄적인 보안 기준을 설정할 수 있습니다.
자세히 알아보려면 AWS Organizations 사용 설명서에서 리소스 제어 정책(RCP)을 참조하세요.