[AWS] AWS Organizations / Config / IAM role / Control tower

AWS Organizations 기능 (features)

AWS Organizations에서는 조직을 구성할 때 사용할 수 있는 두 가지 기능 모드 존재

1. 모든 기능 (All Features)

• 가장 선호되는 방식, 최초 조직 생성 시 활성화하는 것이 default
• SCP를 통해 조직 내의 모든 계정의 AWS 리소스 접근을 중앙에서 관리 O

2. 콘솔 기반 기능 (Consolidated Billing Feature)

• 여러 AWS 계정의 비용을 하나로 통합하여 청구서를 관리
  - 통합 결제 기능으로 표현하기도 함
• 비용 관리만 가능, SCP를 통해 계정의 접근 제어 X

AWS Organizations 정책 (Policy)

조직 내의 리소스 사용 규칙

AWS Organizations의 정책은 조직 내 계정들이 AWS 리소스에 어떻게 접근할 수 있는지를 정의하는 규칙 집합으로, SCP 역시 정책의 유형에 속한다.

Policy 주의 사항

• Role 과 Policy는 기본적으로 서로 분리된 개념
  • Policy에는 Role 또는 계정을 명시적으로 할당하는 개념이 아님 주의
• Policy 자체로는 어떤 작업을 허용할지/거부할지만 정의
  • 실제로 어떤 역할(Role)이 이 정책을 사용할 수 있는지는 IAM 역할에 이 정책을 연결함으로써 결정

  ### Policy 예시, Role 또는 계정에 대한 내용은 빠져있다
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::my-bio-data-bucket/*"
      }
    ]
  }

• Policy 에는 2가지가 존재함
  • 권한 정책 (Permission Policy):누구(어떤 역할 또는 사용자)가 이 작업을 할 수 있을지는 따로 지정 X
  • 신뢰 정책 (Trust Policy): 누구(어떤 역할 또는 사용자)가 이 작업을 할 수 있을지 따로 지정 O

서비스 제어 정책(SCP)

AWS Organizations에서 조직 내 "계정"이 수행할 수 있는 "최대 작업 범위 지정"

• 조직 내 계정(또는 OU, Organizational Unit)에 적용되는 정책으로, 계정들이 사용할 수 있는 AWS 서비스와 작업을 제한합니다.
• 조직(Organization), 조직 단위(OU), 또는 개별 계정(Account)에 적용
• 조직의 Root에 적용된 SCP는 모든 하위 계층에 적용
• 조직 내 계정이 사용할 수 있는 최대 권한 범위를 설정합니다 --> 최대 권한 범위를 설정한다는 것이 "실제로 리소스에 대한 권한을 부여하는 것은 아님" 주의
• SCP는 "허용 목록(Allow List)" 또는 "거부 목록(Deny List)"의 형태로 구성
• 기본적으로 FullAWSAccess라는 SCP가 적용 (=all allow)
  - 이후에 생성되는 SCP 들에 의해 최대 권한의 범위가 축소되는 형태

SCP vs IAM

• 적용 범위: SCP는 조직 전체 또는 특정 조직 단위(OU)에 적용, IAM 정책은 개별 사용자, 역할 또는 리소스에 적용
• 정책의 역할: SCP는 전체 계정의 최대 허용 권한을 정의하며, IAM 정책은 세부적인 리소스 접근 권한 정의
• 우선순위: SCP에서 명시적으로 Deny된 작업은 IAM 정책에서 허용하더라도 실행X (SCP가 결국 계정에 대해서는 최종 접근제어)

교차 계정 IAM 엑세스

본인(A)의 리소스를 타 계정(B)에서 접근하기 위한 방법

교차 계정 IAM 엑세스 순서

1. 계정 A에서 역할(Role)을 생성하고, 신뢰 정책(Trust Policy)을 설정하여 계정 B의 사용자가 이 역할을 사용할 수 있도록 허용.
2. 계정 A에서 권한 정책(Permission Policy)을 설정하여, 이 역할이 계정 A의 리소스에 접근할 수 있는 권한을 정의.
3. 계정 B에서 사용자가 AssumeRole을 통해 계정 A의 역할을 사용하여, 리소스에 접근.
4. 임시 보안 자격 증명을 얻어 계정 A의 리소스에 접근.

단, 2번 과정에서 KMS에 의한 암호화가 걸려있을 경우 마찬가지로 KMS 리소스에 대한 권한 부여 역시 병행되어야한다. (A KMS에서 B 엑세스 권한 부여 + B계정에서 A의 KMS Role 부여)

Identity Center 통한 인증 구현 시 주의 사항

• IdP는 인증 및 권한 부여를 처리하기 위한 목적 (=AWS 리소스에 대한 직접적인 권한 부여 X)
  • 인증 요청에 대한 처리 후 SAML, OAuth 등 인증 처리만 수행
  • 이후 AWS에서 sts 기반으로 리소스 접근 권한을 부여한 뒤, 사용자에게 리소스 접속 권한 부여 (이 중간 과정에서 SSO Endpoint로 Redirect 수행)

AWS Config

AWS 리소스의 "설정변경을 추적"하고, 규정 준수 상태를 모니터링하는 도구

AWS Organizations와 통합 시 AWS Config는 여러 계정에 걸쳐 중앙에서 관리 가능

• 구성 항목, 구성 스냅샷, 구성 기록, 규정 준수상태 등을 관리
• 아쉽게도 리소스가 생성되자마자 리소스에 Tag를 추가하는 기능은 X (Service Catalog 에서 가능)

Control tower (가드레일이 하위 기능)

Control Tower는 새로운 AWS 계정들을 자동으로 구성하고 표준화를 보장하며, 기본적인 가드레일을 통해 조직 전체에서 일관된 거버넌스를 제공

• Guardrails: AWS Control Tower에서 제공하는 정책 및 규칙으로, 보안, 운영, 규정 준수와 관련된 위험을 줄여 줍니다. Guardrails는 두 가지 유형 존재
  1. 강제적 Guardrails: 반드시 적용되며, 특정 행동을 차단하여 위반되지 않도록 보장
  2. 알림형 Guardrails: 모니터링만 하며, 위반 시 알림을 제공

Control Tower는 Organizations를 기반으로 더 높은 수준의 자동화와 일관된 설정을 제공하는 관리 도구

• Control Tower를 사용하면 Organizations보다 더 쉽게 여러 계정을 운영할 수 있지만, Organizations 자체도 강력한 다중 계정 관리 기능을 제공
• 자동화된 계정 설정이 Control tower 사용의 주요 목적