본문 바로가기
AWS

[AWS] 계정 설정(Logical OU 구조 + Cross-Account Access 설계)

by 간장공장공차장 2024. 11. 28.
반응형

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을 사용하는 것이 좋습니다. 

설계 방안 요약

  1. IAM 사용자 계정은 최소한으로 생성:
    • 대부분의 경우, IAM 사용자를 직접 생성하고, 권한을 부여하는 대신, IAM 역할(Role)을 사용하는 방식으로 관리할 수 있습니다.
    • 실제로 리소스를 사용하는 사용자는 IAM 역할을 Assume(수임)하여 필요한 권한을 얻습니다.
  2. Role을 통해 권한 위임:
    • IAM 역할(Role)을 통해 필요한 권한을 지정하고, 특정 사용자나 서비스가 역할을 Assume할 수 있도록 설정합니다.
    • 이를 통해 IAM 사용자나 그룹에 불필요한 권한을 직접 부여할 필요 없이, 역할 기반 접근 제어(RBAC)를 통해 효율적으로 권한을 관리할 수 있습니다.
  3. 권한의 최소화:
    • 최소 권한 원칙(Principle of Least Privilege)을 따르기 위해, IAM 사용자 계정에는 필요한 최소한의 권한만 부여하고, 실제 작업은 역할(Role)을 통해 수행하도록 합니다.
    • 예를 들어, 개발자 역할(Developer Role), 운영자 역할(Administrator Role) 등을 정의하여 특정 계정이나 서비스가 역할을 맡고, 그 역할을 통해 필요한 리소스에 접근하도록 할 수 있습니다.

이 설계의 장점

  1. 보안:
    • 계정에 직접 권한을 부여하는 대신 역할(Role)을 사용하므로, 권한 관리가 분리되고 불필요한 권한이 계정에 부여되지 않습니다.
    • 각 IAM 사용자나 서비스는 필요한 권한만을 가진 역할을 수임(Assume)하기 때문에, 권한 남용을 방지할 수 있습니다.
  2. 유지 관리 용이:
    • Role 기반 관리는 권한 변경이 용이합니다. 예를 들어, 특정 역할의 권한을 변경하면 그 역할을 사용하는 모든 계정이나 서비스에 즉시 적용됩니다.
    • 이로 인해 개별 계정에 대해 권한을 일일이 변경하는 번거로움을 줄일 수 있습니다.
  3. 확장성:
    • 새로운 계정이나 서비스가 추가되더라도, 새로운 역할을 생성하고 해당 역할을 필요로 하는 사용자에게 수임(Assume)하도록 설정하기만 하면 됩니다.
    • 역할 기반 접근 제어는 계정 수가 많아져도 관리가 용이합니다.
  4. Cross-Account Access:
    • 다른 AWS 계정에서 이 역할을 Cross-Account로 수임할 수 있도록 설정하면, 특정 계정의 리소스에 접근할 수 있는 권한을 쉽게 관리할 수 있습니다.
    • 예를 들어, 하나의 AWS 계정에서 여러 계정의 리소스에 접근할 수 있도록 설정할 수 있습니다.
반응형