AWS IAM 고급

Siyun·2025년 3월 14일

AWS

목록 보기

29/37

AWS 조직(Organizations)

AWS 조직은 글로벌 서비스로, 여러 AWS 계정을 동시에 관리할 수 있도록 지원한다. 이를 위해 조직을 생성하게 되며, 조직 내 주요 계정은 관리 계정이라 불린다. 반면, 조직에 가입하거나 조직에서 생성된 다른 계정들은 멤버 계정이라 한다.

조직에서 관리하는 계정들은 IAM user가 아닌 하나하나의 Root user를 가진 계정이다.
SCP는 "조직 내 계정"의 IAM 사용자와 역할(Role)이 수행할 수 있는 작업을 제한하는 역할을 한다. 하지만 각 계정의 루트 사용자(root user)는 SCP의 영향을 받지 않으며, 모든 작업을 수행할 수 있다.

IAM 사용자(User)는 한 개의 AWS 계정에 속하지만, 조직은 여러 AWS 계정을 통합 관리할 수 있음.

멤버 계정은 단 하나의 조직에만 속할 수 있다. AWS 조직의 중요한 특징 중 하나는 모든 계정의 청구가 통합된다는 점이다. 따라서 관리 계정에서 단일 결제 방법을 설정하면 조직의 모든 비용을 한 번에 지불할 수 있다.

또한 조직 내 모든 계정의 사용량이 집계되므로 EC2나 S3 같은 서비스의 대량 사용 시 추가적인 가격 혜택을 받을 수 있다. 더불어, 예약 인스턴스와 절약 계획 할인도 계정 간에 공유 가능하다. 즉, 한 계정에서 사용되지 않은 예약 인스턴스가 있다면, 다른 계정이 그 혜택을 받을 수 있으며, 이를 통해 전체 조직의 비용을 절감할 수 있다.

조직 구조 및 자동화

AWS 조직에서는 계정을 자동으로 생성할 수 있는 API도 제공하므로, 계정 생성을 간편하게 할 수 있다.

조직의 구조는 조직 단위(OU, Organizational Unit) 개념을 기반으로 구성된다.

루트 OU: 가장 상위 계층이며, 그 안에 관리 계정이 위치한다.
하위 OU: 개발, 프로덕션, 테스트 등 필요에 따라 여러 개의 OU를 생성할 수 있다. 하위 OU내에 또 하위 OU를 중첩으로 생성할 수 있다.
각 OU 내에는 여러 개의 멤버 계정을 포함할 수 있다.

예를 들어,

개발 환경을 위한 개발 OU를 생성하고, 그 내부에 멤버 계정을 추가할 수 있다.
프로덕션 환경을 위한 프로덕션 OU를 생성하여 세부적으로 항공 시스템 관련 계정, 재무 관련 계정 등으로 나눌 수도 있다.

조직 구조는 비즈니스 단위별(판매/소매/재무)로 나눌 수도 있고, 환경(개발/테스트/프로덕션)별로 구분할 수도 있다. 이를 통해 계정 및 리소스를 보다 체계적으로 관리할 수 있다.

AWS 조직을 활용한 보안 및 관리

보안 강화를 위한 계정 분리
- 단일 계정 내 여러 VPC를 두는 것보다, 계정을 분리하는 것이 더 높은 수준의 보안성을 제공한다.
태그 표준 강제 적용
- 모든 계정에 대해 일관된 태그 정책을 적용할 수 있다. 이를 통해 비용 추적 및 관리가 용이해진다.
로그 중앙화
- CloudTrail을 모든 계정에 자동 활성화하여 로그를 중앙 S3 계정으로 전송할 수 있다.
- CloudWatch 로그도 중앙 로깅 계정으로 전송 가능하다.
교차 계정 역할 설정
- 관리 계정에서 멤버 계정을 직접 관리할 수 있도록 IAM 역할을 자동으로 설정 가능하다.
서비스 제어 정책(SCP, Service Control Policy) 적용
- SCP를 사용하여 특정 계정이나 OU에 IAM 정책을 적용할 수 있다.
- 이를 통해 특정 서비스 사용을 제한하거나 허용 목록(allow list)을 설정할 수 있다.

일반적으로 회사의 대표 AWS 계정(관리 계정)에서 조직(Organizations)을 생성한 후, 개발 계정과 운영 계정을 조직 내 멤버 계정으로 추가하여 통합 관리한다.

계정 구조 예시

1️⃣ 회사 계정 (조직의 관리 계정)

조직을 생성하고 모든 멤버 계정을 통합 관리함.
일반적으로 청구(Billing) 및 보안 정책(SCP)를 관리하는 용도로만 사용하며, 서비스 운영에는 사용하지 않음.

2️⃣ 개발 계정

개발자들이 개발 환경을 운영하는 계정.
IAM 사용자(User) 또는 역할(Role)을 생성하여 개발자가 접근하도록 설정.
보통 테스트, 스테이징 환경을 포함함.

3️⃣ 운영 계정

실제 프로덕션(운영) 환경을 관리하는 계정.
운영자들만 접근 가능하도록 IAM 사용자(User) 및 역할(Role) 관리.
보안 및 접근 제어가 더욱 엄격하게 관리됨.

4️⃣ (옵션) 보안/로그 계정

CloudTrail, GuardDuty, AWS Config 등의 로그 및 보안 모니터링을 위한 별도 계정.
조직 내 모든 계정에서 생성된 로그를 중앙 저장하는 용도로 사용됨.

조직을 생성할 때는 반드시 루트 계정으로

조직을 만들고 관리 계정으로 지정할 AWS 계정은 루트 사용자(root user)로 로그인한 상태에서 조직을 생성해야 한다.
IAM 사용자(User) 계정은 조직을 생성할 권한이 없으므로, IAM 사용자로는 조직을 만들 수 없다.
하지만 조직을 만든 후에는 IAM 역할(Role)과 정책을 활용해 특정 사용자에게 조직 관리 권한을 부여할 수 있다.

🛑 주의점:

관리 계정이 되면 해당 계정을 조직에서 제거할 수 없으므로, 조직을 관리할 전용 AWS 계정을 따로 만드는 것이 권장된다.
운영 서비스나 개발 환경에 직접 사용하지 않는 것이 좋다.
이유: 보안상 중요한 계정이기 때문에 청구 및 정책 관리만 담당하고, 별도로 개발 및 운영 계정을 분리하는 것이 좋다.

서비스 제어 정책(SCP)

SCP는 특정 OU 또는 계정에서 실행할 수 있는 작업을 제한하는 정책이다.
다만, SCP는 관리 계정에는 적용되지 않는다. 이는 관리 계정이 실수로 스스로를 차단하여 복구가 불가능한 상황을 방지하기 위함이다. SCP를 올바르게 활용하면 조직 내 모든 계정의 보안을 강화하고, 서비스 사용을 체계적으로 관리할 수 있다.

SCP 적용 예시

특정 서비스 차단
- 모든 작업을 허용하는 FullAWSAccess 정책을 추가해야만 특정 서비스(DynamoDB 등)의 사용을 제한할 수 있다.
허용 목록 적용
- FullAWSAccess 정책 없이 특정 서비스(예: EC2, CloudWatch)만 Allow하면 해당 서비스만 사용할 수 있다.

예를 들어,

특정 OU(이름: 샌드박스)에서 전체 AWS 액세스를 허용하면서도 S3 사용을 금지하는 SCP를 적용한다.
- 샌드박스 OU에 속하는 계정A에 전체 AWS 액세스를 허용하면서도 EC2 사용을 금지하는 SCP를 설정하면 OU, 계정의 SCP를 적용받아 S3와 EC2에 접근하지 못하게 된다.
특정 OU가 전체 AWS 엑세스 허용, 그 OU 내의 계정B에서는 전체 AWS 액세스 허용 정책을 포함하지 않고 S3 접근을 허용하면 s3에만 접근할 수 있다.

AWS Organizations 실습

조직 생성하기

1. AWS Organizations 콘솔 > Create an organization 선택

바로 조직이 생성된다.

2. 조직 내에서 계정 정의하기

루트 조직 단위가 생긴다. 조직을 만든 계정이 관리 계정이 된다.

3. 조직에 두 번째 계정 추가하기

Add an AWS account를 클릭한다.

계정 생성: 계정 이름, 이메일, 계정에 적용될 IAM role을 적용해 생성
기존의 계정 초대하기: 해당 계정과 연결된 이메일 주소나 계정ID를 입력하고 초대장을 보내면 된다.
AWS accounts > Invitations 에서 만료되지 않은, 보류 중인 모든 초대장을 볼 수 있다. 초대장은 2주 내에 수락되지 않으면 만료된다.

초대를 받은 계정은 AWS Organizations > Invitations에서 초대장을 볼 수 있고 수락, 거절할 수 있다. Dashboard에서 조직 ID와 특성 세트를 볼 수 있다. 또는 Leave this organization으로 조직을 떠날 수도 있다.

4. 조직에 OU 추가하기

Root로 가서 Children > Action > Create new를 선택해 새 unit 이름을 입력하고 생성해준다.

같은 방식으로 생성한 OU를 눌러 Children > Action > Create new로 하위 OU를 만들 수 있다.

계정의 OU 변경하기

AWS Organizations 콘솔 > AWS accounts 에서 옮기고자 하는 계정을 체크 > Actions > Move로 이동

관리 계정은 루트 아래에 두는 것이 일반적이지만 원한다면 다른 OU로 이동시킬 수 있다.

계정, OU의 SCP 설정하기

1. AWS Organizations 콘솔 > Policies 로 가서 Service control policies를 활성화해준다.

Policies에서 활성화할 수 있는 다른 정책

백업 정책은 조직 전체의 백업 계획을 배포하여 모든 계정이 규정을 준수하고 백업이 활성화되도록 할 수 있다.

태그 정책은 조직의 모든 계정 내에서 태그를 사용하는 방법을 표준화할 수 있다.

2. Service control policies를 클릭 > Create policy를 선택하여 새 정책을 생성할 수 있다.

정책명, 설명, Json문서를 편집해 정책을 정의한다.

3. AWS accounts > 원하는 OU나 계정 선택 > Policies > Attach를 클릭해 정책 연결

Policies UI에서 연결된 정책이 상위 OU에서 상속받은 것인지 확인할 수 있다.

그럼 IAM Root 계정이 User에게 준 IAM Policy와 OU에서 부여한 SCP가 충돌할 경우 무엇이 더 우선일까?

✅ SCP 허용(O) + IAM 허용(O) → 사용 가능
❌ SCP 허용(O) + IAM 거부(X) → 사용 불가능
❌ SCP 거부(X) + IAM 허용(O) → 사용 불가능

IAM Conditions

IAM 조건(Condition)은 IAM 내부의 정책(사용자 정책, 리소스 정책, 엔드포인트 정책 등)이 언제, 어떻게 적용될지를 제어하는 요소이다.

정책(Policy) 자체는 허용(Allow) 또는 거부(Deny)의 규칙을 정의한다.
조건(Condition) 을 추가하면 특정 상황에서만 정책이 적용되도록 제한할 수 있다.

IAM 조건 예시

aws:SourceIp → 클라이언트 IP 제한

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": "192.168.0.0/24"
        }
      }
    }
  ]
}

특정 IP 주소 범위에서만 API 호출을 허용하거나 거부할 때 사용됨.
예: 회사 내부 네트워크에서만 AWS에 접근 가능하도록 설정.

aws:RequestedRegion → API 호출 리전 제한

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": ["ec2:*","rds:*","dynamodb:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-central-1","eu-west-1"]
        }
      }
    }
  ]
}

특정 리전에서의 API 요청을 허용하거나 차단할 때 사용됨.
예: 유럽 리전(eu-central-1, eu-west-1)에서의 EC2, RDS, DynamoDB 호출을 차단.

ec2:ResourceTag → EC2 인스턴스 태그 기반 제한
- EC2 인스턴스가 특정 태그를 가질 때만 특정 작업을 수행 가능하도록 제한.
- 예: Project=DataAnalytics 태그가 있는 EC2 인스턴스만 시작(Start) 및 종료(Stop) 허용.
aws:PrincipalTag → 사용자(User) 태그 기반 제한
- 특정 태그가 있는 사용자만 특정 작업을 수행할 수 있도록 제한.
- 예: Department=Data 태그가 있는 사용자만 EC2 관련 작업 수행 가능.

3,4의 예시코드

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:StartInstances","ec2:StopInstances"],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Project": "DataAnalytics",
          "aws:PrincipalTag/Department": "Data"
        }
      }
    }

aws:MultiFactorAuthPresent → MFA(다중 인증) 강제 적용

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": ["ec2:StopInstances","ec2:TerminateInstances"],
      "Resource": "*",
      "Condition": {
        "BoolIfExists":{
          "aws:MultiFactorAuthPresent": false
        }
      }
    }

MFA를 사용하지 않은 사용자의 특정 작업을 차단.
예: EC2 인스턴스 중지(Stop) 및 종료(Terminate)를 하려면 반드시 MFA를 활성화해야 함.

aws:PrincipalOrgID → 조직 멤버 계정만 리소스 접근 가능

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject","s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "org-id-12345"
        }
      }
    }
}

특정 AWS 조직(Organization)의 계정만 리소스에 접근할 수 있도록 제한.
예: 조직 외부 계정이 S3 버킷을 사용하지 못하도록 차단.

S3 버킷수준의 IAM 정책과 객체 수준의 IAM 정책

S3 버킷 수준 정책은 s3:::버킷이름 형태의 ARN을 사용.
개별 객체(Object) 정책은 s3:::버킷이름/* 형태의 ARN을 사용.
예:
```
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-bucket/*"
}
```
→ my-bucket 내의 객체수준에서는 버킷명의 / 뒤에 객체명을 표시하여 객체수준의 IAM 정책을 설정해준다.

IAM 역할(Role)과 리소스 기반 정책(Resource Based Policies)의 차이

IAM 역할과 리소스 기반 정책은 AWS에서 계정 간 작업을 수행할 때 중요한 두 가지 옵션이다. 특히, S3 버킷에 대한 API 호출을 수행할 때 사용자는 user에 부여된 IAM 정책이나 경유할 AWS 서비스의 Role을 통해 호출하는 방법, 사용자를 허용하는 S3의 버킷정책을 통해 호출하는 방법이 있다. 두 방식은 비슷해 보일 수 있지만, 근본적으로 차이가 있다.

1. IAM 역할

IAM 역할을 사용하면, 사용자는 역할을 맡을 때 자신이 가진 원래의 권한을 포기하고, 그 역할에 할당된 권한만을 가지게 된다.

예시: 계정 A의 사용자가 계정 B의 S3 버킷에 접근하기 위해 계정 B의 역할을 맡게 되면, 계정 A 사용자는 계정 B에서 부여된 권한만을 사용할 수 있다. 즉, 계정 A의 원래 권한을 사용할 수 없다.
장점: 역할을 맡으면, 역할에 할당된 권한만 사용하게 되어 보다 세밀한 제어가 가능하다.
단점: 역할을 맡을 때 원래 권한을 포기해야 하기 때문에, 추가적인 권한이 필요하거나 여러 가지 작업을 할 때 불편할 수 있다.

2. 리소스 기반 정책

리소스 기반 정책을 사용하면, 주체는 역할을 맡지 않고 자신의 원래 권한을 유지하면서도 다른 계정의 리소스를 접근할 수 있다.

예시: 계정 A의 사용자가 계정 A의 DynamoDB 테이블을 스캔하고, 그 데이터를 계정 B의 S3 버킷에 덤프하려면 리소스 기반 정책을 사용하는 것이 좋다. 이 경우, 계정 A 사용자는 자신의 권한을 유지한 채 계정 B의 S3 버킷에 접근할 수 있다.
장점: 역할을 맡을 필요 없이 리소스에 접근할 수 있다.
단점: 리소스가 리소스 기반 정책을 지원하지 않으면 사용할 수 없다. 점점 더 많은 AWS 서비스와 리소스가 리소스 기반 정책을 지원하고 있다.

3. 리소스 기반 정책 지원 서비스

리소스 기반 정책을 지원하는 서비스에는 Amazon S3 버킷, SNS 주제, SQS 큐, Lambda 함수 등이 있다.

예시: EventBridge 규칙이 실행될 때 대상 서비스에 대한 권한을 제공하려면 리소스 기반 정책을 사용할 수 있다. EventBridge가 Lambda, SNS, SQS, S3 버킷 등 리소스 기반 정책을 지원하는 서비스에 호출을 할 때는 IAM 역할을 사용하지 않고 리소스 기반 정책을 추가하여 호출을 허용할 수 있다.

4. IAM 역할을 사용하는 경우

리소스 기반 정책을 지원하지 않는 경우에는 IAM 역할을 사용해야 한다. 예를 들어 Kinesis Data Streams, EC2 Auto Scaling, System Manager Run Command, ECS 작업 등에서는 IAM 역할을 사용해야 한다.

IAM 권한 경계(Permissions Boundary)

IAM 권한 경계(Permissions Boundary)는 사용자와 역할의 최대 권한을 정의하는 고급 기능이다. 이 기능은 특정 IAM 사용자나 역할이 수행할 수 있는 작업을 정밀하게 제한하는 데 사용된다. 권한 경계는 그룹에는 적용되지 않는다.

IAM 권한 경계

IAM 권한 경계는 IAM 정책과 비슷해보이지만 그 자체로는 권한을 부여하지 않는다. 대신, 특정 IAM 사용자가 수행할 수 있는 작업의 최대 범위를 제한한다.
예를 들어, S3, CloudWatch, EC2에 대한 모든 작업을 허용하는 권한 경계를 설정했다면, 그 사용자 또는 역할은 이들 서비스에 대한 작업만 할 수 있다.

s3, cloudwatch, ec2만 허용하는 권한 경계 예시

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "cloudwatch:*",
        "ec2:*"
      ],
      "Resource": "*"
    }
  ]
}

IAM 정책과 권한 경계의 관계

IAM 정책: 실제 권한을 부여한다. 예를 들어, iam:CreateUser 같은 정책을 통해 사용자가 특정 리소스에 접근할 수 있게 된다.
권한 경계: 해당 권한을 최대 범위로 제한한다. 예를 들어, 사용자가 iam:CreateUser를 허용하는 IAM 정책을 가졌다고 하더라도, 권한 경계에서 그 액션을 허용하지 않으면, 사용자는 그 액션을 수행할 수 없다.

권한 경계의 적용 예시

예시 1: John이라는 사용자가 있고, 그에게 AdministratorAccess 권한이 있다면, 원칙적으로 모든 작업을 할 수 있다. 그러나 권한 경계로 AmazonS3FullAccess를 설정하면, John은 S3 서비스에서만 작업할 수 있고, 다른 서비스에는 접근할 수 없다.
예시 2: IAM 권한 경계는 AWS Organizations SCP(Service Control Policies)와 함께 사용할 수 있다. 이 경우, 특정 조직 내에서만 특정 사용자의 권한을 제한할 수 있다.

권한 경계 설정하는 방법

IAM 콘솔 > Users > Permissions > Permissions boundary > Set boundary로 부여

IAM 정책 평가 논리

IAM에서 액션을 수행할 때 권한을 평가하는 흐름은 여러 단계로 이루어진다:
1. 외부에서 명시적 거부가 있으면 자동으로 거부된다.
2. Organizations SCP, 리소스 기반 정책(예: S3 버킷 정책), 자격 증명 기반 정책(IAM 정책), 권한 경계 순으로 평가가 이루어진다.
3. 세션 정책도 존재하며, 이는 주로 STS(Security Token Service)와 관련된 것이다.
4. 모든 평가 단계에서 거부가 없고, 허용만 있을 때 최종적으로 액션이 허용된다.

예시: 정책 평가

예시 1: sqs:*에 대해 Deny가 명시된 경우, sqs:CreateQueue나 sqs:DeleteQueue 같은 다른 SQS 관련 작업은 모두 거부된다.
- sqs:DeleteQueue에도 Allow가 있지만, Deny가 명시적 거부이므로 실행되지 않는다.
예시 2: ec2:DescribeInstances 같은 작업은 IAM 정책 내에 명시적으로 허용이 없으면 허용되지 않는다. 이 경우에는 명시적 거부도 없지만 허용이 없기 때문에 실행되지 않는다.

사용 사례

책임 위임: 관리자가 아닌 사용자에게 권한을 위임할 때 권한 경계를 사용하여 최대 권한을 제한할 수 있다.
특권 남용 방지: 개발자가 스스로를 관리자로 만드는 것을 방지할 수 있다. 권한 경계를 사용하여 자기 권한을 제한할 수 있다.
조직 단위 제한: AWS Organizations를 사용하여 특정 사용자만 제한할 수 있다.

IAM 자격 증명 센터(Identity Center)

이 서비스는 기존 AWS 싱글 사인온 서비스의 후속 제품으로, 이름만 변경된 동일한 서비스이다. 기존 AWS 콘솔이 아닌 IAM 자격 증명 센터에서 한 번만 로그인하면 나의 AWS 조직 내의 여러 AWS 계정 및 비즈니스 클라우드 애플리케이션(Salesforce, Box, Microsoft 365, slack, Dropbox 등)에 접근할 수 있는 싱글 사인온(SSO) 기능을 제공한다. SAML2.0 통합이 가능한 애플리케이션에 연결할 수 있다. 또한 EC2 Windows 인스턴스에도 싱글 로그인을 지원한다.

주요 기능

한 번의 로그인으로 모든 리소스 접근 가능
로그인 후에는 추가 비밀번호 입력 없이 바로 원하는 계정에 액세스할 수 있다.
aws 계정에 로그인하고 AWS IAM Identity Center로 들어가면 활성화된 서비스(Microsoft365, slack등)나 다른 aws계정들이 있을 것이다. 그것을 클릭하면 해당 계정으로 새로 로그인하지 않아도 로그인 된 상태로 그 계정에 접속된 AWS 콘솔을 열 수 있다.
두 가지 ID 저장소 옵션
사용자는 SSO를 위해 두 위치에 저장될 수 있다.
- IAM 자격 증명 센터: AWS 내장 ID 저장소.
- 서드파티 ID 공급자: Active Directory, OneLogin, Okta 등 외부 서비스와 연결 가능.

사용자와 권한 관리

로그인 했다고 해서 모든 항목에 액세스할 수 있는 것은 아니다. 자격 증명 센터에서 권한 셋을 정의해서 어떤 사용자가 무엇에 액세스할 수 있는지 정의해야 한다.

사용자와 그룹 관리
- IAM 자격 증명 센터에서 사용자와 그룹을 관리하며, 권한 셋을 사용해 액세스 권한을 정의한다.
권한 설정
AWS의 루트 계정은 IAM 자격 증명 센터의 전체 설정을 관리할 수 있는 권한을 가진다. 루트 계정에서 IAM 자격 증명 센터를 설정하고, 사용자, 그룹, 권한 세트를 관리하며, 외부 ID 공급자와의 통합도 설정할 수 있다.

예를 들어, 관리팀에서 조직을 만들어 내부에 개발OU, 프로덕션OU가 있고 그 하위에 각 계정들이 있다.

관리팀의 IAM 자격 증명 센터에 개발팀의 Bob과 Alice를 개발자 그룹으로 묶어 개발OU에 대해 전체 액세스 권한을 부여하려고 하면 FullAccess 권한 셋(Permission Set)을 만들어 개발 OU에 연결한다. 그리고 이 권한 셋을 개발자 그룹에 할당한다. 또 프로덕션OU에는 읽기 권한만 부여하고 싶으면 읽기만 가능한 권한 셋을 만들어 프로덕션 OU에 연결하고 개발자 그룹에도 연결한다. 그러면 Bob과 Alice는 전체 액세스를 허용하는 모든 개발자 계정에서 역할을 맡을 수 있고 프로덕션 계정에서는 읽기 액세스만 허용하는 역할을 맡을 수 있다.

세분화된 권한 및 할당
- 권한 셋을 사용하여 사용자가 무엇에 액세스할 수 있을지 정의하고, 이를 통해 그룹에 할당된 사용자들이 필요한 리소스에 접근할 수 있다.

다중 계정 관리

나의 조직에서 여러 AWS 계정에 대한 액세스를 관리할 수 있다. 권한 셋을 사용하여 사용자를 그룹에 할당하는 하나 이상의 IAM 정책을 정의한다.

예를 들어, 데이터베이스 관리자 그룹에 속한 사용자를 위한 권한 셋을 정의해 Dev 계정, Prod 계정의 RDS 또는 Aurora에 액세스할 수 있게 설정하고 데이터베이스 관리자 그룹에 권한 셋을 할당하면, 사용자에 대해 IAM 역할이 자동으로 생성된다.

즉 사용자가 IAM 자격 증명 센터를 통해 로그인해서 Dev 계정 또는 Prod 계정의 콘솔에 액세스할 때 해당 계정에서 IAM 역할을 자동으로 위임한다.

속성 기반 액세스 제어(ABAC)

속성 기반 액세스 제어(ABAC)를 통해 사용자의 속성(직책, 로케일 등)에 따라 액세스를 제어할 수 있다.
이를 통해 한 번 정의된 권한 셋만으로 사용자의 액세스를 속성에 맞춰 조정할 수 있다.

Microsoft Active Directory (AD)와 AWS Directory 서비스 비교

1. Microsoft Active Directory (AD) 개념

Microsoft AD는 Windows 서버에서 사용하는 AD 도메인 서비스 소프트웨어로, 객체의 데이터베이스이다. 사용자 계정, 컴퓨터, 프린터, 파일 공유, 보안그룹이 객체가 될 수 있다.
전체 Microsoft 생태계에서 관리되는 온프레미스의 모든 사용자는 Microsoft Active Directory의 관리 대상이 된다.
중앙 집중식 보안 관리로 계정 생성, 권한 할당 등의 작업이 가능하다.
모든 객체는 트리로 구성되며 트리의 그룹을 포리스트라고 한다.
특정 Windows 머신의 도메인 컨트롤러에서 사용자 계정을 생성하고, 같은 네트워크 내의 모든 Windows 머신들이 해당 도메인 컨트롤러에 연결되면 어떤 머신에서 사용자 계정으로 로그인을 해도 Domain Controller에서 로그인 정보를 확인한 후 인증을 처리한다.

2. AWS Directory 서비스

AWS에서는 Microsoft Active Directory를 클라우드에서 사용할 수 있도록 여러 서비스를 제공한다. 이 서비스들은 각각 다르게 동작하며, 온프레미스 AD와의 통합 방식도 차이가 있다.

AWS 관리형 Microsoft AD

AWS 관리형 AD는 AWS에서 자체적으로 Microsoft AD를 생성하고, 로컬에서 관리할 수 있으며 멀티팩터 인증(MFA)을 지원한다.
독립 실행형 AD로 온프레미스 AD와 신뢰 관계를 구축할 수 있다. 즉, AWS 관리형 AD와 온프레미스 AD가 상호 신뢰 관계를 구축하는 것이다.
양방향 신뢰 관계를 통해, AWS 관리형이 아닌 계정을 사용할 때 온프레미스 AD에서 계정을 검색할 수 있고, 온프레미스 AD 사용자가 AWS 계정을 사용해 온프레미스 AD에서 인증하려 할 때도 AWS AD에서 검색할 수 있다.
AWS 관리형 AD는 AWS 계정과의 통합을 지원한다.

AD 커넥터

AD 커넥터는 온프레미스 Active Directory에 대한 디렉토리 게이트웨이, 즉 프록시 역할을 한다. 온프레미스 AD에 리다이렉트 하며 쿼리와 연결 요청을 프록시한다. MFA를 지원한다.
사용자가 AWS에서 온프레미스 계정을 인증 시도하면, AD 커넥터가 온프레미스 AD로 요청을 전달하고, 그 결과를 사용자에게 반환한다.
사용자는 온프레미스 AD에서만 존재하고 관리되며, AWS에서 사용자 관리는 할 수 없다.

Simple AD

Simple AD는 AWS에서 관리하는 디렉터리 서비스로, Microsoft AD와는 호환되지 않으며 온프레미스 AD와 연결되지 않는다.
AWS 클라우드에서 Active Directory를 사용할 때, 온프레미스 AD가 필요 없는 경우에 적합하다.
주로 Windows EC2 인스턴스와 연동되어 사용된다.

IAM Identity Center와 액티브 디렉터리 통합 방법

AWS 관리형 Microsoft AD와 통합
- IAM Identity Center를 AWS 관리형 Microsoft AD에 통합하여 연결하면 된다.
- 이 방법은 클라우드에서 Active Directory를 관리하고 싶을 때 사용한다.
온프레미스 자체 관리형 디렉터리와 통합
온프레미스에 자체 관리형 디렉터리가 있는 경우, 연결 방법은 두 가지가 있다:
- 방법 1: AWS 관리형 Microsoft AD 사용
  - 양방향 신뢰 관계를 구축한다.
  - Directory 서비스를 이용해 AWS 관리형 Microsoft AD를 생성하고, 온프레미스 AD와 양방향 신뢰 관계를 구축한 뒤, IAM Identity Center에서 싱글 사인온(SSO)을 설정한다.
  - 이 방법은 클라우드에서 Active Directory를 관리하고 싶은 경우에 적합하다.
- 방법 2: AD 커넥터 사용
  - AD 커넥터는 IAM Identity Center와 연결하여, 모든 요청을 온프레미스 디렉터리로 프록시한다.
  - 이 방법은 API 호출만 프록시하는 방식으로, 지연 시간이 길어질 수 있다.
  - 온프레미스 AD 관리를 계속 유지하고 싶을 때 유용하다.

AWS Directory 서비스 실습

1. AWS Management Console > AWS services > Find Services 에서 directory service를 선택

2. Directory Service > Directories > Set up directory 선택

4가지 옵션이 있다.

Amazon Cognito User Pools: Cognito 서비스로 리디렉션하는 거라 Directory 서비스로 치지 않는다.
AWS Managed Microsoft AD(선택): Active Directory를 가지는데 AWS Cloud와 통합되어 온프레미스 디렉터리와 신뢰 관계가 될 수 있다. MFA를 지원한다.
Simple AD: 독립적인 관리형 디렉터리이며 Active Directory와 호환되는 API가 있지만 온프레미스 Active Directory에는 연결할 수 없다.
-AD Connector: 기존의 Microsoft Active Directory 온프레미스로
디렉터리 요청을 리디렉션하는 프록시로 두 가지 종류가 있다. 최대 500명 또는 5,000명의 사용자를 위한 커넥터가 있다.

3. 디렉토리 설정하기

설정에는 두 가지 버전이 있는데 Standard Edition은 최대 30,000 객체이고 Enterprise Edition은 최대 500,000 객체로 훨씬 더 많다.

AWS Control Tower

AWS Control Tower 서비스를 사용하면 모범 사례를 기반으로 안전하고 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정하고 관리할 수 있다. Control Tower는 AWS Organization 서비스를 활용해 계정을 자동으로 생성한다.

Control Tower의 장점

몇 번의 클릭만으로 환경을 자동으로 설정할 수 있다.
원하는 모든 항목을 미리 구성할 수 있다.
가드레일을 사용하여 지속적인 정책 관리가 가능하다.
정책 위반을 감지하고 자동으로 교정할 수 있다.
대화형 대시보드를 통해 모든 계정의 전반적인 규정 준수를 모니터링한다.

가드레일이란?

가드레일은 다중 계정 환경에서 특정 항목에 대해 한 번에 제한하거나 규정 준수를 모니터링할 때 사용된다. Control Tower 환경 내 모든 계정에 대한 거버넌스를 제공한다.

가드레일의 종류

예방(Preventive) 가드레일
- 계정을 무언가로부터 보호하는 가드레일로, 제한적이다.
- AWS Organization 서비스의 서비스 제한 정책(SCP)을 사용하여 모든 계정에 적용된다.
- 예시: 특정 리전에서만 작업하도록 제한할 수 있다 (예: us-east-1과 eu-west-2 리전).
탐지(Detective) 가드레일
- 규정을 준수하지 않는 사항을 탐지하는 가드레일이다.
- AWS Config 서비스를 사용하여 규정 준수 상태를 모니터링한다.
- 예시: 계정에서 태그가 지정되지 않은 리소스를 식별하고, 규정 준수를 위반하면 SNS 주제나 Lambda 함수를 통해 자동으로 문제를 교정할 수 있다.

Siyun

공부 기록

이전 포스트

AWS 모니터링

다음 포스트