[SAA] Advanced Identity in AWS

1. AWS Organizations

• 글로벌 서비스
• 여러개의 AWS 계정 관리
• 조직을 생성하면 조직의 메인 계정이 관리 계정이며, 다른 계정은 멤버 계정
• 멤버 계정은 한 개의 조직에만 속할 수 있음
• 모든 계정의 비용을 통함 결제 가능
• 집계된 사용량에 기반한 비용 할인 가능(EC2, S3 등 모든 계정의 사용량에 따른 할인)
• 계정 간 예약 인스턴스와 Saving Plans 할인 공유
• AWS 계정 생성을 자동화하기 위한 API 제공
• 장점
  • 다수의 계정을 가지므로 다수의 VPC를 가진 단일 계정에 비해 보안이 뛰어남 ( 계정 독립적)
  • 청구 목적을 위한 태그 기준 적용 가능
  • 한번에 모든 계정에 대해 CloudTrail 활성화 및 로그를 중앙 S3 계정으로 전송
  • CloudWatch Logs를 중앙 로깅 계정으로 전송
  • 관리용으로 Cross Account 역할 설정
• Security:  서비스 제어 정책(Service Control Policies, SCP)
  • OU(Organizaion Unit) 또는 계정에 적용되는 IAM 정책으로 사용자 및 역할 제한
  • SCP는 모든 계정에 적용되나 관리 계정에는 적용 X
  • 명시적 허용이 필요(IAM과 마찬가지로 기본적으로는 아무것도 허용 X)

• SCP Hierarchy
  
  
  • 관리 계정 (Management Account)
    • 관리 계정에는 SCP 적용 X
    • 모든 작업 가능
    • 모든 대상에 대해 관리자 권한
  • Account A: Redshift 액세스 제외 모든 작업 가능
  • Account B: Redshift, Lambda 액세스 제외 모든 작업 가능
  • Account C: Redshift 액세스 외 모든 작업 가능
   

 

2. IAM Roles vs Resource Based Policies

• 교차 계정의 경우
  
  
  • 리소스 기반 정책을 리소스에 연결하는 방법(S3 버킷에 S3 정책 사용
  • 리소스에 액세스할 수 있는 역할을 사용할 수 있음
• 첫번째 예시에서는 Account A의 사용자가 Amazon S3 버킷에 대한 액세스 권한이 있는 Account B의 역할 사용(IAM Role이 S3 버킷에 액세스)
• 두번째 예시에서는 Account A의 사용자가 Account B의 Amazon S3 버킷에 적용된 버킷 정책을 통해 S3 버킷에 액세스(S3 버킷 정책이 사용자의 액세스 허용)
• IAM Role: 역할(사용자, 애플리케이션, 서비스)을 맡으면 기존의 권한을 모두 포기하고 해당 역할에 할당된 권한을 상속받음
• Resource-based Polices: 주체(사용자 또는 역할)는 본인이 역할이 맡지 않으므로 자신의 권한을 포기할 필요 X
• 리소스 기반 정책은  Amazon S3 버킷, SNS 토픽, SQS 큐 등 다양한 리소스에서 지원
• 주체가 자신의 권한을 유지하면서 리소스에 대한 액세스 제어

Amazon EventBridge - Security

• Rule이 실행될 때 해당 대상(targeet)에 대한 권한 필요
• 리소스 기반 정책: Lambda, SNS, SQS, CloudWatch Logs, API Gateway 등
• IAM Role: Kinesis stream, Systems Manager Run Command, ECS 작업 등
• SNS, SQS, Lambda에는 리소스 기반 정책, Kinsis Data Stream에서는 IAM Role

IAM Permission Boundaries

• IAM 권한 경계는 사용자와 역할만 지원, 그룹 지원 X
• IAM 개체가 받을 수 있는 최대 권한을 설정하기 위해 관리형 정책을 사용하는 고급 기능
• IAM 권한 경계: S3, CloudWatch, EC2를 모두 허용
  • 이를 IAM 사용자에게 연결하면 권한 경계를 설정하는 것(S3, CloudWatch, EC2 내의 작업만 가능)
• IAM 정책: iam:Createuser 액션과 * 리소스를 같은 사용자에게 연결하면 권한 경계와 IAM 정책을 통한 권한이 완성됨
• 결과적으로는? 아무 권한도 생기지 않음
• IAM 정책은 IAM 권한경계 밖에 있기 때문에 사용자가 다른 IAM 사용자를 생성할 수 없음
• AWS Organizations SCP와 함께 사용 가능
• 예시
  • 관리자가 아닌 사용자에게 권한 경계 내에서 책임을 위임하는 경우, 예를 들어 새 IAM 사용자 생성
  • 개발자가 자체적으로 정책을 할당하고 자신의 권한을 관리할 수 있도록 허용하면서도 "권한 상승"을 방지하여 특권을 얻을 수 없ㄷ도록 함(= 자체적으로 관리자 권한 부여 불가)
  • 조직 및 SCP를 사용하면 전체 계정이 아닌 특정 사용자의 권한을 제한하는 데 유용함
• IAM Policy Evaluation Logic
  
  

3. Amazon Cognito

• 웹 또는 모바일 애플리케이션과 상호작용하는 사용자에게 식별 정보 제공
• Cognito 사용자 풀
  • 앱 사용자를 위한 로그인 기능
  • API Gateway 및 Application Load Balancer와 통합
• Cognito 자격 증명 풀(Federated Identity)
  • 사용자에게 AWS 자격 증명을 제공하여 직접 AWS 리소스에 액세스 할 수 있도록 함
  • Cognito 사용자 풀과 통합하여 신원 제공자로 사용함
• Cognito vs IAM: 수백명의 사용자, 모바일 사용자, SAML로 인증 등일 경우에 Cognito
• Cognito User Pools(CUP)
  • User Features
    • 웹 및 모바일 앱을 위한 사용자의 서버리스 데이터베이스 생성
    • 간편한 로그인: 사용자 이름(또는 이메일) / 비밀번호 조합
    • 비밀번호 재설정 기능
    • 이메일 및 전화번호 검증
    • 사용자 멀티팩터 인증 (MFA)
    • Federted Identities: Facebook, Google 등의 소셜 로그인, SAML
  • Integration
    • API Gateway 및 Application Load Balancer와 통합 가능
    • API Gateway
      • 사용자는 Cognito 사용자 풀에 접속하여 토큰을 받고 검증을 위해 API Gateway로 토큰을 전달
      • 확인이 끝나면 사용자 자격 증명으로 변환되어 백앤드의 Lambda 함수로 전달
    • ALB
      • Cognito 사용자 풀을 애플리케이션 로드 밸런서 위에 배치
      • 애플리케이션이 Cognito  사용자 풀에 연결한 다음 ALB에 전달해서 유효한 로그인인지 확인
      • 유효한 로그인이라면 요청을 백앤드로 redirect, 사용자의 자격증명과 함께 추가 헤더  전송
    • API Gateway나 ALB를 통해 사용자의 로그인을 한 곳에서 확실히 검증할  수 있고 검증 책임을 백엔드로부터 백엔드의 로드를 밸런싱하는  실제 위치인 API  Gateway 또는 ALB로 옮긴 것
• Cognito Identity Pools (Federated Identities)
  • 사용자에 대한 자격 증명을 제공하여 일시적인 AWS 자격증명을 얻을 수 있게 한다
  • 사용자는 Cognito 사용자 풀 내의 사용자 혹은 타사 로그인 등이 될 수 있음
  • 사용자는 직접 또는  API Gateway를 통해 서비스에 액세스 가능
  • 자격 증명에 적용되는 IAM 정책은  Cognito에서 사전 정의
  • user_id 를 기반으로 사용자 정의하여 세부적인 제어 가능
  • 게스트 사용자나 특정 역할이 정의되지 않은 인증된 사용자는  기본 IAM 역할을  상속
  • 웹이나 모바일 앱의 사용자 기반을 생성할 수 있고, 세분화된 액세스 제어를 위해 DynamoDB행에서 행 수준 보안을 활성화할 수 있음, 또한 Cognito 사용자 풀과 API Gateway 또는 ALB를 통합할 수 있다.

4. AWS IAM Identity Center

• AWS Single Sign-ON 서비스의 후속 제품
• 단일 로그인 기능
  • AWS Organization 내의 모든 AWS 계정
  • 비즈니스 클라우드 애플리케이션(ex. Salesforce, Box, Microsoft 365 ..)
  • SAML 2.0을 지원하는 애플리케이션
  • EC2 Windows 인스턴스
• ID 공급자
  • IAM Identity Center에 내장된 ID 저장소
  • 서드파티 ID 공급자: Active Directory(AD), OneLogin, Okta 등
• 한번만 로그인 해도 된다는 것이 가장 큰 장점, but 자격 증명 센터에서 권한셋을 정의하여 어떤 사용자가 무엇에 액세스 할 수 있는지 정의해야 함
• Fine-grained Permissions and  Assignments
  • 다중 계정 권한(Multi-Account Permissions)
    • AWS Organization 내의 여러 AWS 계정에 대한 액세스 관리
    • 권한 세트(Permission Sets): 사용자 및 그룹에 할당된 하나 이상의 IAM 정책을 모아서 AWS 액세스를 정의하는 기능
  • 애플리케이션 할당(Application Assignments)
    • SAML 2.0 Business Application(Salesforce, Box, Microsoft365 ..)에 대한 SSO(Single Sign-On) 액세스 제공
    • 필요한 URL, 인증서 및 메타 데이터 제공
  • 속성 기반 액세스 제어(Attribute-Based Access Control, ABAC)
    • 사용자의 속성에  기반한 세부적인 권한 제어
    • cost center, title, locale 등과 같은 사용자 속성을 활용한 세밀한 권한 부여
    • ex: IAM 권한 세트를 한번만 정의한 후, 이 속성을 활용하여 사용자 또는 그룹의 AWS 액세스를 수정하는 등의 유연한 권한 관리

 

5. AWS Directory Services

• What is Microsoft Active Directory(AD) ?
  • AD 도메인 서비스를 사용하는 모든 Windows 서버에 사용되는 소프트웨어
  • 객체의 데이터베이스: 사용자 계정, 컴퓨터, 프린터, 파일 공유, 보안 그룹이 객체가 될 수 있음
  • 중앙 집중식 보안 관리: 계정 생성, 권한 할당 등의 작업
  • Objects are organized in trees
  • A group of trees is a forest
• AWS Directory Services
  • AWS Managed Microsoft AD
    • AWS에 자체 AD를 생성하고 로컬에서 관리할 수 있으며 멀티팩터 인증을 지원
    • 독립 실행형 Active Directory로 사용자가 있는 온프레미스 AD와 "신뢰" 관계를 구축
  • AD Connector
    • Directory Gateway(Proxy)로 온프레미스 AD에 리다이렉트, 멀티팩터 인증 지원
    • 온프레미스 AD에서만 사용자를 관리
  • Simple AD
    • AWS의 AD 호환 관리형 디렉토리
    • Microsoft Directory를 사용하지 않으며 온프레미스 AD와도 결합되지 않는다.
• 온프레미스에서 사용자를 프록시한다면 AD Connector, AWS 클라우드에서 사용자를 관리하고 MFA를 사용해야 할 때는 AWS 관리형 AD, 온프레미스가 없을 땐 Simple AD
• IAM Identity Center - Active Directory Setup
  • Directory 서비스를 통해 AWS 관리형 AD를 연결 하는 경우 - 통합 즉시 사용 가능
  • 자체 관리형 디렉토리에 연결하는 경우
    • AWS 관리형 Microsoft AD를 사용하여 양방향 신뢰 관계 구축
      • 클라우드에 있는 액티브 디렉토리에서 사용자를 관리하고 싶을 때
    • AD Connector 활용
      • API 호출만 프록시할 때 - 지연 시긴이 길어짐

 

6. AWS Control Tower

• 모범 사례를 기반으로 안전하고 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정하고 관리할 수 있음
• AWS Control Tower 서비스는 AWS Organizations를 사용하여 계정을 생성
• 장점
  • 몇 번의 클릭으로 환경 설정 자동화
  • 가드레일을 사용하여 지속적인 정책 관리 자동화
  • 정책 위반 감지 및 조치
  • 대화형 대시보드를 통한 규정 준수 모니터링
• Guardrails
  • AWS Control Tower의 가드레일은 Control Tower 환경 내의 모든 AWS 계정에 대한 지속적인 거버넌스 제공
  • 예방적 가드레일(Preventive Guardrail)
    • SCP(Seecurity Control Policiees)를 사용하여 구현
    • ex) 모든 계정에서 리전 제한을 설정하여 특정 리전의 사용을 제한
  • 탐지적 가드레일(Detective Guardrail)
    • AWS Config를 사용하여 구현
    • ex) 태그가 지정되지 않은 리소스 식별