반응형
1. OU 설계
AWS Organizations에서 환경별로 OU를 생성하여 계정을 그룹화합니다.
Root
├── Test OU
│ ├── test-account-1
│ └── test-account-2
├── Staging OU
│ ├── stg-account-1
│ └── stg-account-2
└── Production OU
├── prod-account-1
└── prod-account-2
2. 각 계정별 역할 설계
Cross-Account Access를 위해, 각 계정에 역할(Role)을 생성하고 신뢰 정책(Trust Policy)을 설정합니다.
예: Test, Staging, Production 계정의 IAM Role 이름을 통일
- 모든 계정에 동일한 이름의 역할을 생성합니다.
예: AdminRole.
3. IAM Role 설정 (각 계정)
(1) Role 이름: AdminRole
- Trust Policy를 통해 다른 계정(Main 계정)에서 접근할 수 있도록 설정.
신뢰 정책(Trust Policy) 예시:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/CrossAccountRole"
},
"Action": "sts:AssumeRole"
}
]
}
- 여기서 111111111111은 Main 계정 ID입니다.
- CrossAccountRole은 Main 계정에서 이 역할을 Assume할 수 있도록 구성된 Role입니다.
4. Main 계정에서 Cross-Account Role 설정
Main 계정에서는 각 계정을 관리하기 위해 CrossAccountRole 역할을 생성합니다.
(1) CrossAccountRole 생성
- Permission Policy: Role Assume 권한을 설정.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::222222222222:role/AdminRole", // Test 계정
"arn:aws:iam::333333333333:role/AdminRole", // Staging 계정
"arn:aws:iam::444444444444:role/AdminRole" // Production 계정
]
}
]
}
5. Cross-Account Access 흐름
Main 계정에서 각 계정 접근 방법:
AWS CLI를 사용한 Role Assume:
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/AdminRole \
--role-session-name "TestAccountSession"
- --role-arn: Test 계정의 Role ARN.
- --role-session-name: 세션 이름.
6. SCP를 활용한 추가 제어 (OU 단위)
OU 단위로 Service Control Policy(SCP)를 적용해 계정의 행동을 제한합니다.
(1) Test OU의 SCP 예시
- Test 계정에서는 중요한 리소스를 삭제하지 못하도록 제한:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:TerminateInstances",
"s3:DeleteBucket"
],
"Resource": "*"
}
]
}
(2) Production OU의 SCP 예시
- Production 계정에서는 특정 서비스만 사용 가능하도록 제한:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"s3:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "*",
"Resource": "*"
}
]
}
7. 최종 구조
Logical OU 구조 + Cross-Account Access 설계
Root
├── Test OU
│ ├── test-account-1
│ │ └── IAM Role: AdminRole
│ └── test-account-2
│ └── IAM Role: AdminRole
├── Staging OU
│ ├── stg-account-1
│ │ └── IAM Role: AdminRole
│ └── stg-account-2
│ └── IAM Role: AdminRole
└── Production OU
├── prod-account-1
│ └── IAM Role: AdminRole
└── prod-account-2
└── IAM Role: AdminRole
Main Account
└── CrossAccountRole
계정에 직접 권한을 부여하는 대신 Role을 사용하는 것이 좋습니다.
설계 방안 요약
- IAM 사용자 계정은 최소한으로 생성:
- 대부분의 경우, IAM 사용자를 직접 생성하고, 권한을 부여하는 대신, IAM 역할(Role)을 사용하는 방식으로 관리할 수 있습니다.
- 실제로 리소스를 사용하는 사용자는 IAM 역할을 Assume(수임)하여 필요한 권한을 얻습니다.
- Role을 통해 권한 위임:
- IAM 역할(Role)을 통해 필요한 권한을 지정하고, 특정 사용자나 서비스가 역할을 Assume할 수 있도록 설정합니다.
- 이를 통해 IAM 사용자나 그룹에 불필요한 권한을 직접 부여할 필요 없이, 역할 기반 접근 제어(RBAC)를 통해 효율적으로 권한을 관리할 수 있습니다.
- 권한의 최소화:
- 최소 권한 원칙(Principle of Least Privilege)을 따르기 위해, IAM 사용자 계정에는 필요한 최소한의 권한만 부여하고, 실제 작업은 역할(Role)을 통해 수행하도록 합니다.
- 예를 들어, 개발자 역할(Developer Role), 운영자 역할(Administrator Role) 등을 정의하여 특정 계정이나 서비스가 역할을 맡고, 그 역할을 통해 필요한 리소스에 접근하도록 할 수 있습니다.
이 설계의 장점
- 보안:
- 계정에 직접 권한을 부여하는 대신 역할(Role)을 사용하므로, 권한 관리가 분리되고 불필요한 권한이 계정에 부여되지 않습니다.
- 각 IAM 사용자나 서비스는 필요한 권한만을 가진 역할을 수임(Assume)하기 때문에, 권한 남용을 방지할 수 있습니다.
- 유지 관리 용이:
- Role 기반 관리는 권한 변경이 용이합니다. 예를 들어, 특정 역할의 권한을 변경하면 그 역할을 사용하는 모든 계정이나 서비스에 즉시 적용됩니다.
- 이로 인해 개별 계정에 대해 권한을 일일이 변경하는 번거로움을 줄일 수 있습니다.
- 확장성:
- 새로운 계정이나 서비스가 추가되더라도, 새로운 역할을 생성하고 해당 역할을 필요로 하는 사용자에게 수임(Assume)하도록 설정하기만 하면 됩니다.
- 역할 기반 접근 제어는 계정 수가 많아져도 관리가 용이합니다.
- Cross-Account Access:
- 다른 AWS 계정에서 이 역할을 Cross-Account로 수임할 수 있도록 설정하면, 특정 계정의 리소스에 접근할 수 있는 권한을 쉽게 관리할 수 있습니다.
- 예를 들어, 하나의 AWS 계정에서 여러 계정의 리소스에 접근할 수 있도록 설정할 수 있습니다.
반응형
'AWS' 카테고리의 다른 글
[SAP-C02] AWS 계정 간 내부 연결 (0) | 2024.12.26 |
---|---|
[SAP- C02] 하이브리드 DNS 솔루션 관련 개념 정리 (0) | 2024.12.26 |
[AWS] 스토리지 종류 별 정리 (0) | 2024.11.27 |
[AWS] 네트워크 연결 옵션(Transit Gateway, Direct Connect, PrivateLink, Site-to-Site VPN) (0) | 2024.11.27 |
[AWS] Lambda@Edge (0) | 2024.11.26 |