◇ 공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇
AWS Organizations
AWS Organizations는 여러 AWS 계정을 중앙에서 관리하기 위한 서비스이다.
AWS Organizations를 사용하면 1)여러 AWS 계정에 대한 권한 설정 및 2)각 계정의 청구 정보를 통합한 일괄 청구를 이용할 수 있다.
AWS Organizations 특징
- 중앙 관리: 여러 AWS 계정을 그룹화하고 관리할 수 있다
- 일관 청구(Consolidated Billing): 모든 계정에서의 AWS 비용을 관리 계정에서 일관해서 청구 관리 가능.
- 계정 계층화 OU(Organizational Unit): OU를 사용해 여러 계정을 논리적으로 그룹화한다.
- 서비스 제어 정책(SCP): OU(Organizational Unit) 또는 특정 계정 적용 가능한 정책
(OU용 IAM Policy라 생각하면 이해하기 쉽다.)
💵 일관 청구(Consolidated Billing)
AWS Organizations에서 관리하는 여러 AWS 계정의 청구된 비용을 하나로 통합하여 중앙에서 관리할 수 있다.
여러 계정의 비용을 하나의 청구서로 통합해 관리 가능.
Consolidated Billing의 장점
사용 중인 모든 AWS 계정의 비용 전체를 합산해서 지불함으로써 볼륨 디스카운트를 받을 수 있다.
[할인 혜택 서비스]: Reserve Instance, Compute Savings Plans
관리 계정(Management Account)에서 Reserve Instance와 Savings Plans의 할인 공유를 활성화함으로써 Organizations 내의 모든 계정의 사용량에 적용하여 효과적으로 활용할 수 있다.
👥 OU (Organizational Unit) ≈ 그룹
1개의 관리용 계정(Management Account)과 여러 개의 멤버 계정(Member Account)으로 구성된다.
- Management Account: root
- Member Account: Suspeded OU
- Member Account: Production OU
- ...
멤버 계정을 그룹화하여 이를 OU(Organizational Unit)라고 한다.
각각의 OU마다 특정 정책(SCP)를 설정 가능하다.
예시) 보안에 관한 Policy를 작성하여 계정 전체에 적용하거나 OU마다 다르게 설정할 수도 있다.
AWS Organizations OU 계층 구조 예시
AWS Organizations
├── Root
├── Production (OU)
│ ├── Prod-Applications (Account ID: 111111111111)
│ ├── Prod-Databases (Account ID: 222222222222)
├── Development (OU)
│ ├── Dev-Applications (Account ID: 333333333333)
│ ├── Dev-Databases (Account ID: 444444444444)
├── Testing (OU)
├── Test-Applications (Account ID: 555555555555)
├── Test-Databases (Account ID: 666666666666)
📜 SCP (Service Control Policy: 서비스 제어 정책)
SCP은 OU(Organizational Unit) 또는 특정 AWS 계정에 대해 AWS 서비스에 대한 접근 권한 및 사용 가능한 리소스를 제한할 수 있는 기능이다.
– SCP 예시1) OU에 속한 테스트용 계정(그룹)은 특정 서비스(예: RDS)에만 접근하도록 제한하기
– SCP 예시2) 모든 AWS 계정에 대해 MFA를 강제하도록 설정할 수 있다.
또한, SCP를 적용하는 조건(Condition)을 설정하여 특정 IAM User 또는 IAM Role에 대해서만 제한을 적용하는 등의 제어도 가능하다.
SCP 예시: 허용되지 않은 리전에서 EC2 인스턴스 생성 차단
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyEC2RunInstancesInUnauthorizedRegions",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"us-east-1",
"us-west-2",
"eu-central-1"
]
}
}
}
]
}조건 키 (condition keys)
조건 키는 특정 조건에 따라 접근 제어를 수행하기 위해 Policy의 Condition 요소 내에서 사용된다.
조건 키를 사용하면 Policy의 허가나 거부를 구체적인 조건으로 세밀하게 제어하여 접근 권한을 상세히 관리할 수 있다.
조건 키 중에서 글로벌 조건 키는 "aws:"로 시작하며, 모든 AWS 서비스에 대해 공통적으로 사용할 수 있다.
반면, 서비스 고유의 조건 키는 서비스 고유의 이름(예: "s3:")으로 시작합니다.
글로벌 조건 키 예시
- aws:PrincipalOrgID: Organization 전체
- AWS Organizations에 속한 전체 계정의 접근을 제어하는 데 사용됩니다.
- 예시) 특정 조직(Organizations) ID를 가진 계정만 특정 리소스에 접근할 수 있도록 설정
- aws:PrincipalOrgPaths: Organization의 특정 OU
- 조직 유닛(OU)의 계층을 지정하여 특정 부서나 그룹에 대한 세밀한 접근을 제어
- 예시) 특정 OU에 속한 계정들만 특정 리소스에 접근할 수 있도록 설정
- aws:PrincipalTag:
- Tag에 기반하여 접근을 제어한다.
- 예시) 특정 태그가 적용된 사용자나 역할만 리소스에 접근할 수 있도록 설정
Organizations 전체가 대상이라면 aws:PrincipalOrgID를 적용해야한다.
특정 OU가 대상이라면 aws:PrincipalOrgPaths를 적용해야한다.
예시) 조건 키 적용
아래의 Policy는 o-1234567890 조직 ID를 가진 계정만 your-bucket-name S3 버킷에 대한 s3:GetObject 및 s3:ListBucket 작업을 허가합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-bucket-name",
"arn:aws:s3:::your-bucket-name/*"
],
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-1234567890"
}
}
}
]
}
🤔 SOA 문제
회사는 AWS Organizations를 사용하여 여러 AWS 계정을 관리하고 있습니다. 회사 정책에 따르면 고객 데이터를 저장하고 처리할 수 있는 특정 AWS 리전만 허용됩니다.
SysOps 관리자는 회사 내 누구도 허용되지 않은 리전에서 Amazon EC2 인스턴스를 프로비저닝하지 못하도록 해야 합니다.
이 요구 사항을 충족하면서 가장 운영 효율적인 솔루션은 무엇입니까?
- 모든 리전에서 API 활동을 기록하도록 AWS CloudTrail을 구성합니다. 허용되지 않은 리전에서 ec2:RunInstances 이벤트를 감지하기 위해 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 생성합니다. AWS Lambda를 사용하여 생성된 EC2 인스턴스를 종료합니다.
- 각 AWS 계정에서 리전을 조건으로 사용하여 허용되지 않은 리전에서 ec2:RunInstances 작업을 거부하는 관리형 IAM 정책을 생성합니다. 이 정책을 각 AWS 계정의 모든 IAM 그룹에 연결합니다.
- 각 AWS 계정에서 리전을 조건으로 사용하여 허용되지 않은 리전에서 ec2:RunInstances 작업을 거부하는 IAM 권한 경계 정책을 생성합니다. 이 권한 경계 정책을 각 AWS 계정의 모든 IAM 사용자에 연결합니다.
- AWS Organizations에서 서비스 제어 정책(SCP)을 생성하여 허용되지 않은 리전에서 ec2:RunInstances 작업을 거부합니다. 이 정책을 조직의 루트 레벨에 연결합니다.
정답
정답. 4번
AWS Organizations에서 서비스 제어 정책(SCP)을 생성하여 허용되지 않은 리전에서 ec2:RunInstances 작업을 거부합니다. 이 정책을 조직의 루트 레벨에 연결합니다.
🤔 SAA 문제
어느 기업이 AWS Organizations를 사용하여 여러 AWS 계정을 중앙에서 관리하고 있습니다. 이 기업은 Amazon EC2 인스턴스에 대한 작업을 AWS Organizations 내의 조직 구성원에게만 제한하고자 합니다. 운영 부담을 최소화하면서 이를 실현하기 위한 가장 적절한 방법은 무엇입니까?
- IAM Role의 액세스 정책에 OU(Organizational Unit) 경로를 지정한 aws:PrincipalOrgPaths글로벌 조건 키를 추가합니다. 이를 EC2 인스턴스에 연결합니다.
- IAM Role의 액세스 정책에 특정 태그를 지정한 aws:PrincipalTag글로벌 조건 키를 추가합니다. 이를 EC2 인스턴스에 연결합니다.
- IAM Role의 액세스 정책에 조직 ID를 지정한 aws:PrincipalOrgID글로벌 조건 키를 추가합니다. 이를 EC2 인스턴스에 연결합니다.
- AWS Config를 사용하여 조직 내 모든 Amazon EC2 인스턴스의 구성 변경을 모니터링하고, 구성 규칙을 평가합니다.
정답
정답. 3번
IAM Role의 액세스 정책에 조직 ID를 지정한 aws:PrincipalOrgID 글로벌 조건 키를 추가합니다. 이를 EC2 인스턴스에 연결합니다.
위의 문제에서, 글로벌 조건 키 aws:PrincipalOrgID(조직 ID)를 지정함으로써, 특정 조직 ID를 가진 프린시펄(IAM 사용자, 그룹, 역할, 또는 AWS 서비스)만 리소스에 액세스할 수 있도록 허용할 수 있다.
OU(Organizational Unit)이나 태그(Tag)를 사용한 세부적인 제어와 비교하여, Policy 관리가 간단하며, 대규모 조직에서의 운영 부담을 줄일 수 있다.
조직 전체를 대상으로 한 일괄적인 액세스 제한을 시행하므로, 개별 계정이나 사용자에 대한 별도의 액세스 설정을 할 필요가 없어 관리가 용이해진다.
오답
1번. IAM Role의 액세스 정책에 OU(Organizational Unit) 경로를 지정한 aws:PrincipalOrgPaths 글로벌 조건 키를 추가합니다. 이를 EC2 인스턴스에 연결합니다.
aws:PrincipalOrgPaths(조직 경로)를 조건 키로 지정함으로써, Organizations의 특정 계층에 대해서만 액세스를 허용할 수 있다.
특정 OU에 한정하여 액세스 제어를 설정하는 경우에 적합하지만, 이 기업이 요구하는 것은 조직 전체에 대한 액세스 제어이므로 최적의 선택이 아니다.
2번. IAM 역할의 액세스 정책에 특정 태그를 지정한 aws:PrincipalTag 글로벌 조건 키를 추가합니다. 이를 EC2 인스턴스에 연결합니다.
aws:PrincipalTag(프린시펄 태그)를 조건 키로 지정함으로써, 설정된 태그를 기반으로 액세스 제어를 할 수 있다. 태그 기반의 액세스 제어는 매우 유연하고 강력하지만, 태그의 관리와 유지에는 운영의 부담이 따른다.
특히 대규모 조직에서는 태그의 일관성을 유지하는 것이 어려울 수 있으므로, 운영의 간소화를 중시할 경우에는 최적이 아니다.
4번. AWS Config를 사용하여 조직 내 모든 Amazon EC2 인스턴스의 구성 변경을 모니터링하고, 구성 규칙을 평가합니다.
AWS Config는 AWS 리소스의 설정을 관리하고 기록 및 평가하는 서비스이다.
