[AWS SAA] 향상된 IAM in AWS

AWS Organizations

글로벌 서비스로 다수의 AWS 계정을 동시에 관리할 수 있게 해 줍니다

• 글로벌 서비스
• 여러 AWS 계정을 관리할 수 있습니다.
• 기본 계정은 마스터 계정입니다.
• 다른 계정은 회원 계정입니다.
• 회원 계정은 한 조직에만 속할 수 있습니다.
• 모든 계정에 대한 통합 결제 - 단일 결제 방법
• 집계된 사용량의 가격 혜택(EC2, S3에 대한 볼륨 할인...)
• 계정 전체에서 공유 예약 인스턴스 및 Savings Plans 할인
• API를 사용하여 AWS 계정 생성을 자동화할 수 있습니다.

• 위와 같이 여러 조직을 중첩가능

Organizational Units (OU)

Organization 장점

• 장점
  • 다중 계정 vs 단일 계정 다중 VPC
    • 다중계정이므로 보안이 뛰어남
  • 청구 목적으로 태깅 표준 사용
  • 모든 계정에서 CloudTrail 활성화, 중앙 S3 계정으로 로그 전송
  • CloudWatch Logs를 중앙 로깅 계정으로 전송
  • 관리 목적으로 교차 계정 역할 설정하여 관리계정에서 모든 멤버 계정 관리가능.
• 보안: 서비스 제어 정책(SCP)
  • 사용자 및 역할을 제한하기 위해 OU 또는 계정에 적용되는 IAM 정책
  • 마스터 계정에는 적용되지 않습니다(전체 관리자 권한).
  • 명시적 허용이 있어야 합니다(IAM과 같이 기본적으로 아무 것도 허용하지 않음).

SCP Hierarchy(계층)

서비스 제어정책(SCP)는 특정 OU 또는 계정에 적용되는 IAM 정책으로 해당 사용자와 역할 모두가 계정 내에서 할 수 있는 일을 제한합니다

• 관리 계정
  • 무엇이든 할 수 있음
  • (SCP가 적용되지 않음)
• 계정A
  • 무엇이든 할 수 있음
  • EXCEPT 액세스 Redshift(OU의 명시적 거부)
• 계정B
  • 무엇이든 할 수 있음
  • EXCEPT 액세스 Redshift(Prod OU의 명시적 거부)
  • EXCEPT 액세스 Lambda(HR OU의 명시적 거부)
• 계정C
  • 무엇이든 할 수 있음
  • 예외 액세스 Redshift(Prod OU의 명시적 거부)

SCP Examples 블록 목록 과 허용목록 전략들

• 차단 목록은 계정이 사용하지 못하게 할 서비스를 지정합니다
  Allow, *(별표)로 모든 서비스의 모든 작업을 허용한 다음
  Deny 문을 추가해 DynamoDB에 대한 액세스를 거부하는 식입니다

• 허용 목록은 모든 액션을 허용하지 않고 가령 EC2와 CloudWatch만 허용하는 방식입니다. 해당 SCP가 적용된 계정에서는 EC2와 CloudWatch만이 허용되며 다른 서비스는 사용할 수 없고 사용하려면 명시적 허용이 필요합니다

More examples: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_example-scps.html

---

IAM Conditions

IAM 조건은 IAM 내부의 정책에 적용되며 사용자 정책일 수도 있고 예를 들면 S3 버킷에 대한 리소스 정책일 수도 있어습니다. 또한, 엔드포인트 정책 등 어떤 정책도 될 수 있죠.

Conditions

• aws:SourceIp는 API 호출이 수행되는 클라이언트 IP를 제한합니다.
• 정책을 보면 모든 작업과 리소스를 거부(Deny)하지만 조건이 있는데, 두 개의 IP 주소 범위에 포함되지 않는 IP 주소는 거부하는 것 입니다.

• aws:RequestedRegion API 호출이 수행되는 리전을 제한합니다.
• 정책을 보면 eu-central-1와 eu-west-1 리전에서 오는 EC2, RDS, DynamoDB 호출을 제한하고 있습니다. 즉, 특정 리전에서 특정 서비스에 대한 액세스를 거부하는 거죠

• ec2:ResourceTag 태그 기반 제한
• 이 조건은 EC2 인스턴스의 태그에 적용됩니. 여기서 ResourceTag/Project가 DataAnalytics일 때 모든 인스턴스의 시작과 종료를 허용합니다. EC2 인스턴스가 올바른 태그를 갖고 있으면, 즉 Project가 DataAnalytics이면 허용됩니다.
• 다음 줄의 aws:PrincipleTag는 사용자 태그에 적용됩니다. 상기 작업을 수행하려면 사용자의 Department가 Data여야 합니다.

• aws:MultiFactorAuthPresent MFA 강제 적용

IAM for S3

• s3:ListBucket 권한은 arn:aws:s3:::test에 적용됩니다.

• => 버킷 수준 권한

• s3:GetObject, s3:PutObject,
  s3:DeleteObject는 arn:awn:s3:::test/*에 적용됩니다.

• => 객체 수준 권한

Resource Policies & aws:PrincipalOrgID

• aws:PrincipalOrgID는 AWS Organization의 멤버인 계정에 대한 액세스를 제한하기 위해 어떤 리소스 정책에서든 사용할 수 있습니다.

• 다음과 같은 정책이 적용된 S3 버킷이 있습니다 이에 따르면 PrincipleOrgID의 계정(o-yyyyyyy)에서 API 호출이 생성된 경우에만 PutObject, GetObject 작업을 할 수 있습니다.
• 조직 내의 멤버 계정만 S3 버킷에 액세스할 수 있고
• 조직 외부의 사용자는 이 S3 버킷 정책에 의해 액세스가 거부됩니다.

IAM Roles vs Resource Based Policies

• 교차 계정:
  • 리소스 기반 정책을 리소스에 연결(예: S3 버킷 정책)
  • 또는 역할을 프록시로 사용

• 역할(사용자, 응용 프로그램 또는 서비스)을 수임하면 원래 권한을 포기하고 역할에 할당된 권한을 갖게 됩니다.
• 리소스 기반 정책을 사용할 때 보안 주체는 자신의 권한을 포기할 필요가 없습니다.

  • 예: 계정 A의 사용자는 계정 A의 DynamoDB 테이블을 스캔하고 계정 B의 S3 버킷에 덤프해야 합니다.

• 지원 대상: Amazon S3 버킷, SNS 주제, SQS 대기열 등...
  
  

Amazon EventBridge – Security

• 규칙이 실행될 때 대상에 대한 권한이 필요합니다.
• 리소스 기반 정책: Lambda, SNS, SQS, CloudWatch Logs, API 게이트웨이...
• IAM 역할: Kinesis 스트림, 시스템 관리자 실행 명령, ECS 작업...

IAM 권한 경계

• IAM 권한 경계는 사용자 및 역할(그룹이 아님)에 대해 지원됩니다.
• 관리형 정책을 사용하여 IAM 엔터티가 얻을 수 있는 최대 권한을 설정하는 고급 기능.

IAM 권한 경계 예시를 살펴보겠습니다. IAM 정책과 비슷해 보이죠.
S3, CloudWatch, EC2를 모두 허용하고 있습니다. 이걸 IAM 사용자에 연결하면 권한 경계를 설정하는 겁니다. S3, CloudWatch, EC2 내의 작업만 할 수 있게 되죠 더불어 IAM 정책을 통해 IAM 권한을 지정해야 합니다.
iam:CreateUser 액션과 * 리소스를 같은 사용자에 연결하면 권한 경계와 IAM 정책을 통한 권한이 완성됩니다
하지만 놀랍게도 결과적으로 아무 권한도 생기지 않습니다.
IAM 정책은 IAM 권한 경계 밖에 있기 때문에 사용자가 다른 IAM 사용자를 생성할 수 없습니다. IAM 권한 경계에 포함되지 않았으니까요

IAM 권한 경계

• AWS Organizations SCP 조합으로 사용 가능

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html

• 사용 사례
  • 권한 범위 내에서 비관리자에게 책임 위임(예: 새 IAM 사용자 생성)
  • 개발자가 정책을 자체 할당하고 자신의 권한을 관리할 수 있도록 허용하면서 자신의 권한을 "상승"(= 자신을 관리자로 지정)할 수 없도록 합니다.
  • 하나의 특정 사용자를 제한하는 데 유용합니다(조직 및 SCP를 사용하는 전체 계정 대신).

IAM Policy Evaluation Logic

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

Example IAM Policy

• sqs:CreateQueue를 수행할 수 있습니까? NO
  • 정답은 생성할 수 없습니다 sqs:에 Deny와 가 있는데 CreateQueue가 해당 블록에 포함되기 때문에 거부
• sqs:DeleteQueue를 수행할 수 있습니까?
  -명시적 거부가 있으면 바로 결정이 거부 sqs:에 Deny가 명시되어 있기 때문에 sqs: 안에 있는 sqs:DeleteQueue는 Allow가 있음에도 자동으로 거부
• ec2:DescribeInstances 수행할 수 있습니까?
  • 보시다시피 IAM 정책에 EC2 관련 사항은 없습니다. 명시적 거부도 없지만 명시적 허용도 없기 때문에 해당 IAM 정책 내에서는 ec2:DescribeInstances를 실행할 수 없습니다.

---

Amazon Cognito

Cognito는 사용자에게 웹 및 모바일 앱과 상호 작용할 수 있는 자격 증명을 부여합니다. 일반적으로 이 사용자들은 AWS 계정 외부에 있습니다. 모르는 사용자들에게 자격 증명을 부여해 사용자를 인식(Cognito)합니다.

• 사용자에게 웹 또는 모바일 애플리케이션과 상호 작용할 수 있는 ID 제공
• Cognito 사용자 풀:
  • 앱 사용자를 위한 로그인 기능
  • API Gateway 및 Application Load Balancer와 통합
• Cognito 자격 증명 풀(연합 자격 증명):
  • AWS 리소스에 직접 액세스할 수 있도록 사용자에게 AWS 자격 증명을 제공합니다.
  • 자격 증명 공급자로서 Cognito 사용자 풀과 통합합니다.
• Cognito 대 IAM: "수백 명의 사용자", "모바일 사용자", "SAML로 인증"

Cognito User Pools (CUP) – User Features

• 웹 및 모바일 앱용 서버리스 사용자 데이터베이스 생성
• 간단한 로그인: 사용자 이름(또는 이메일) / 암호 조합
• 비밀번호 초기화
• 이메일 및 전화번호 확인
• 다단계 인증(MFA)
  .
• Federated ID: Facebook, Google, SAML의 사용자...

Cognito User Pools (CUP) - Integrations

• CUP는 API Gateway 및 Application Load Balancer와 통합됩니다.

API Gateway

• 사용자는 Cognito 사용자 풀에 접속해서 토큰을 받고 검증을 위해 토큰을 API Gateway에 전달합니다.
• 확인이 끝나면 사용자 자격 증명으로 변환되어 백엔드의 Lambda 함수로 전달됩니다.
• Lambda 함수는 처리할 사용자가 잘 인증된 구체적인 사용자라는 사실을 인식하게 됩니다.

ALB

• 애플리케이션이 Cognito 사용자 풀에 연결한 다음, 애플리케이션 로드 밸런서에 전달해서 유효한 로그인인지 확인합니다.
• 유효하다면 요청을 백엔드로 리다이렉트하고 사용자의 자격 증명과 함께 추가 헤더를 전송하죠.

• 검증 책임을 백엔드로부터 백엔드의 로드를 밸런싱하는 실제 위치, 즉 API gateway 또는 ALB로 옮긴 것입니다

Cognito Identity Pools (Federated Identities)

• 임시 AWS 자격 증명을 얻을 수 있도록 "사용자"에 대한 자격 증명 가져오기

• 사용자 소스는 Cognito 사용자 풀, 타사 로그인 등일 수 있습니다...

• 그러면 사용자가 직접 또는 API 게이트웨이를 통해 AWS 서비스에 액세스할 수 있습니다.

• 자격 증명에 적용되는 IAM 정책은 Cognito에서 정의됩니다.

• 세분화된 제어를 위해 user_id를 기반으로 맞춤화할 수 있습니다.

• 인증 및 게스트 사용자를 위한 기본 IAM 역할

Cognito Identity Pools – Diagram

웹이나 모바일 애플리케이션에서 S3 버킷 또는 DynamoDB 테이블에 직접 액세스하고 싶습니다.

• Cognito 자격 증명 풀을 사용하여 웹, 모바일 앱이 로그인해서 토큰을 받을 겁니다.
• Cognito 사용자 풀에 대한 로그인일 수도 있고 소셜 자격 증명 제공자나 SAML OpenID Connect일 수도 있습니다.
• 그런 다음 이 토큰을 Cognito 자격 증명 풀 서비스에 전달해서 토큰을 임시 AWS 자격 증명과 교환합니다.
• 이를 위해 Cognito 자격 증명 풀은 전달 받은 토큰이 올바른지, 즉 유효한 로그인인지 평가합니다.
• 다음으로는 해당 사용자에게 적용되는 IAM 정책을 생성합니다
• 관련 IAM 정책이 적용된 임시 자격 증명 덕분에 AWS의 S3 버킷이나 DynamoDB 테이블에 직접 액세스할 수 있습니다.

Cognito Identity Pools Row Level Security in DynamoDB

DynamoDB에 행 수준 보안을 설정할 수 있습니다

• Cognito 자격 증명 풀에 화면과 같은 정책이 있을 때, 이 안에 조건을 설정하는 겁니다.
• 이 예시에서는 DynamoDB의 LeadingKeys가 Cognito 자격 증명 사용자 ID와 같아야 한다는 조건입니다.
• 이 정책이 적용된 사용자는 DynamoDB 테이블의 모든 항목을 읽고 쓸 수 있는 것이 아니라 이 조건을 통해 액세스를 얻은 항목에만 액세스할 수 있습니다.

---

AWS IAM Identity Center (successor to AWS Single Sign-On)

이 서비스는 전에 AWS 싱글 사인온 서비스라고 알려진 것의 후속 제품입니다. 이름만 변경된 동일한 서비스이고, 한 번만 로그인하면 되니까 싱글 사인온이라고 하는 것입니다.

• 모든 사용자를 위한 단일 로그인(Single Sign-On)
  • AWS Organizations의 AWS 계정
  • 비즈니스 클라우드 애플리케이션(예: Salesforce, Box, Microsoft 365, ...)
  • SAML2.0 지원 애플리케이션
  • EC2 Windows 인스턴스
• ID 공급자
  • IAM Identity Center의 빌트인 ID 저장소
  • 서드파티: Active Directory(AD), OneLogin, Okta...

AWS IAM Identity Center – Login Flow

로그인 페이지로 이동하여 사용자 이름과 비밀번호를 입력하고 바로 AWS IAM 자격 증명 센터로 이동합니다.

• 이것은 제 자격 증명 센터 페이지의 스크린샷입니다. 보시다시피 제 계정에 대해 활성화해뒀기 때문에 제가 원하는 계정을 클릭하여 원하는 곳으로, 예를 들어 관리 콘솔로 바로 연결할 수 있습니다.
• 이렇게 하면 콘솔의 홈페이지로 직접 이동하고, 해당 콘솔에 로그인되어 있습니다. 그 콘솔에 로그인하는 방법을 알 필요가 없는 겁니다.
  이것이 즉 다시 비밀번호를 입력할 필요 없는 싱글 사인온입니다.

AWS IAM Identity Center - 동작

• 브라우저 인터페이스는 AWS IAM 자격 증명 센터의 로그인 페이지에 연결됩니다
• 그리고 앞에서 말씀드렸듯이, 그걸 다른 사용자 스토어와 통합해야 합니다.
• 클라우드 또는 온프레미스에 있는 Active Directory도 가능합니다.
• 여기에서 Active Directory를 사용하여 사용자와 그룹을 관리할 수 있습니다.
• 또는 IAM 자격 증명 센터를 사용할 수도 있습니다.
• 여기는 빌트인 자격 증명 스토어인데요, 여기에서 IAM에서 했던 것처 사용자나 그룹을 정의할 수 있습니다.
• 그리고 ID 센터를 여러분의 AWS 조직이나 Windows EC2 인스턴스, 비즈니스 클라우드 애플리케이션 사용자 정의 SAML2.0 지원 애플리케이션 등과 통합합니다.

IAM Identity Center

그럼 권한, 사용자, 그룹은 IAM 자격 증명 센터에서는 어떻게 연관되어 있을까요?

• 조직 하나 있다고 해봅시다, 관리 계정에 IAM 자격 증명 센터를 설정합니다
• 두 개의 OU가 있죠, 개발 OU와 프로덕션 OU가 있고, 각각의 계정이 있습니다
• 회사에는 두 명의 개발자가 있다고 해봅시다 Bob과 Alice라고 해보죠
• 먼저 IAM에서 했던 것처럼 Bob과 Alice에 대해 개발자 그룹을 만들어 보겠습니다.
• Bob과 Alice가 개발 OU에 대해 전체 액세스 권한을 갖도록 하려고 합니다.
• 따라서 권한 셋이라는 것을 만들고 거기에 관리자 액세스를 허용하겠습니다.
• 그리고 이 권한 셋을 특정 OU와 연결해야 합니다
• 즉, 개발 OU에 있는 사람과 연결하는 거죠, 그리고 이 권한 셋을 개발자 그룹에 할당합니다
• 그러면 Bob과 Alice는 전체 액세스를 허용하는 모든 개발 계정에서 역할을 맡을 수 있습니다
• 마찬가지로 프로덕션 OU에 대해 읽기 전용 액세스이라는 다른 권한 셋을 만들 수 있습니다
• 그것과 연결하고 다시 권한을 개발자 그룹에 할당합니다
• 이런 식으로 사용자를 그룹, 권한 셋, IAM 자격 증명 센터의 특정 계정 할당에 연결할 수 있습니다.

AWS IAM Identity 중앙 세분화된 권한 및 할당

• 다중 계정 권한
  • AWS Organization의 AWS 계정에 대한 액세스 관리
  • 권한 셋 정의– AWS 액세스를 정의하기 위해 사용자 및 그룹에 할당된 하나 이상의 IAM 정책 모음
• 애플리케이션 할당
  • 많은 SAML 2.0 비즈니스 애플리케이션에 대한 SSO 액세스(Salesforce, 박스, 마이크로소프트 365, ...)
  • 필수 URL, 인증서 및 메타데이터 제공
• 속성 기반 액세스 제어(ABAC)
  • IAM Identity Center Identity Store에 저장된 사용자 속성을 기반으로 세분화된 권한
  • 예:costcenter,title,locale,...
  • 사용 사례: 권한을 한 번 정의한 다음 속성을 변경하여 AWS 액세스를 수정합니다.

---

What is Microsoft Active Directory (AD)?

• AD 도메인 서비스가 있는 모든 Windows 서버에서 찾을 수 있습니다.
• 개체 데이터베이스: 사용자 계정, 컴퓨터, 프린터, 파일 공유, 보안 그룹
• 중앙 집중식 보안 관리, 계정 생성, 권한 할당
• 전체 Microsoft 생태계에서 관리되는 온프레미스의 모든 사용자는 Microsoft Active Directory의 관리 대상
• 모든 객체는 트리로 구성되며 트리의 그룹을 포리스트라고 합니다

• 첫 번째 머신에서 John과 Password를 사용하면 이 머신은 로그인 정보가 있는지 컨트롤러를 확인한 다음 로그인을 허용합니다.
• 모든 머신은 도메인 컨트롤러에 연결되어 있으므로 사용자는 어떤 단일 머신에서도 액세스할 수 있습니다.

AWS Directory Services

• AWS 관리형 Microsoft AD

  • AWS에서 자체 AD 생성, 로컬에서 사용자 관리, MFA 지원
  • 독립 실행형 Active Directory로 사용자가 있는 온프레미스 AD와 신뢰 관계를 구축

• AD 커넥터

  • 온프레미스 AD로 리디렉션하기 위한 디렉터리 게이트웨이(프록시), MFA 지원
  • 사용자는 온프레미스 AD에서 관리됩니다.

• 심플 AD

  • AWS의 AD 호환 관리 디렉토리
  • 온프레미스 AD와 조인할 수 없음

액티브 디렉터리를 사용해 Windows를 실행할 EC2 인스턴스를 생성하고
이 Windows 인스턴스는 네트워크용 도메인 컨트롤러와 결합되어 모든 로그인 정보와 자격 증명 등을 공유합니다.

• 이런 이유로 AWS에 디렉터리를 둡니다 Windows를 실행하는 EC2 인스턴스와 디렉터리를 가까이 위치시키려고요
  
  

IAM Identity Center – Active Directory Setup

• AWS Managed Microsoft AD(Directory Service)에 연결
  • 즉시 사용 가능한 통합

• 자체 관리 디렉터리에 연결
  • AWS Managed Microsoft AD를 사용하여 양방향 신뢰 관계 생성
  • AD 커넥터 생성
  • 클라우드에 있는 액티브 디렉터리에서 사용자를 관리하고 싶다면 첫 번째 솔루션이 낫고 API 호출만 프록시하려면 두 번째 솔루션이 적합합니다 지연 시간이 길어지긴 하지만요
    

AWS Control Tower

• 안전하고 규정을 준수하는 다중 계정을 설정하고 관리하는 손쉬운 방법 Best Practice 기반의 AWS 환경

• AWS Control Tower는 AWS Organizations를 사용하여 계정을 생성합니다.

• 이익:

  • 클릭 몇 번으로 환경 설정 자동화
  • 가드레일을 사용하여 지속적인 정책 관리 자동화
  • 정책 위반 감지 및 수정
  • 대화형 대시보드를 통해 규정 준수 모니터링

AWS Control Tower – Guardrails

Control Tower 환경(AWS 계정)에 대한 지속적인 거버넌스 제공

• Preventive Guardrail – SCP 사용(예: 모든 계정에서 지역 제한)
  

• 예를 들어, 예방 가드레일을 생성해 모든 계정에서 리전을 제한하고 us-east-1과 eu-west-2의 리전에서만 작업하도록 할 수 있습니다.
• Control Tower에서 Organization에 SCPs를 사용하도록 하는 것이죠.

• Detective Guardrail – AWS Config 사용(예: 태그가 지정되지 않은 리소스 식별)

규정 준수에 대해 말씀드린 것처럼 AWS Config 서비스를 사용합니다.

• 가령, 계정에서 태그가 지정되지 않은 리소스를 식별한다고 하면 Control Tower로 탐지 가드레일을 설정하고 AWS Config를 사용하면 모든 멤버 계정에 Config가 배포되어 규칙과 태그가 지정되지 않은 리소스를 모니터링 하는데,
• 규정을 준수하지 않으면 SNS 주제를 트리거 해서 관리자로서 알림을 받거나 SNS 주제도 Lambda 함수를 실행해 Lambda 함수가 자동으로 문제를 교정합니다
• 즉, 태그가 지정되지 않은 리소스에 태그를 추가하겠죠

---

AWS Certified Solutions Architect Associate 시험합격!