AWS[IAM-고급]

정지범·2024년 1월 23일
IAM-고급
0

aws

목록 보기
21/26

AWS Organizations

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

SCP Hierarchy

  • 관리 계정 (Management Account)
    • 관리 계정에는 SCP가 적용되지 않음
    • 모든 작업 가능
    • 모든 대상에 대해 관리자 권한을 갖는다.
  • Account A
    • Redshift 액세스 제외 모든 작업 가능
  • Account B
    • Redshift, Lamda 액세스 외 모든 작업 가능
  • Account C
    • Redshift 액세스 외 모든 작업 가능

SCP Examples - Blocklist and Allowlist strategies

SCP에는 'Blocklist (차단 목록)'과 'Allowlis (허용 목록)' 두 가지 전략이 있다.

IAM Conditions

IAM Conditions는 IAM의 내부 정책에 적용되며 사용자 정책일 수도, S3 버킷에 대한 리소스 정책일 수도, 엔드 포인트 등 어떤 정책도 될 수 있다.

  • aws:SourceIP
    • 모든 작업과 리소스를 거부하지만 조건이 있다.
    • 두 개의 IP 주소 범위에 포함되지 않는 IP 주소는 거부하는 것이다.
    • 클라이언트가 해당 IP 주소 내에서 API 호출을 하지 않으면 API 호출이 거부된다는 뜻이다.
  • aws:RequestedRegion
    • AWS로 시작하므로 글로벌 조건이며 API 호출 리전을 제한한다.
    • 위 예시에서는 eu-central-1, eu-west-1 리전에서 오는 EC2, RDS, DynamoDB 호출을 제한한다.
  • ec2:ResourceTag, aws:PrincipleTag
    • 접두사가 EC2이기 때문에 EC2 인스턴스의 태그에 적용된다.
    • 위 예시에서는 ResourceTag/Project가 DataAnalytics일 때 모든 인스턴스의 시작과 종료를 허용한다.
    • EC2 인스턴스가 올바른 태그를 갖고 있으면, 즉, procjet가 DataAnalytics이면 허용한다.
    • 다음 줄의 aws:PrincipleTag는 사용자 태그에 적용된다.
    • 상기 작업을 수행하려면 사용자의 Department가 Data여야 한다.
  • aws:MultiFactorAuthPresent
    • 정책을 보면 사용자는 EC2에서 모든 작업을 할 수 있지만 멀티팩터 인증이 있어야만 인스턴스를 중지하고 종료할 수 있다.
    • MFA가 false일 때 거부된다.

IAM for S3

  • s3:ListBucket은 s3:::test라는 ARN에 적용된다.
    • 버킷 수준의 권한이므로 버킷을 특정해야 함
  • s3:GetObject, s3:PutObject, s3:DeleteObject는 버킷 내의 객체에 적용되므로 ARN이 달라진다.
    -버킷 내의 모든 객체를 나타내는 /＊이 들어간다.
    • 객체 수준의 권한

(ARN: Amazon Resource Name의 약자로, AWS 리소스를 고유하게 식별하기 위해 사용되는 Amazon의 리소스 식별자, arn:partition:service:region:account-id:resource과 같은 형식을 갖는다.)

Resource Policies & aws:PrincipalOrgID

aws:PrincipalOrgID는 AWS 조직의 멤버 계정에만 리소스 정책이 적용되도록 제한한다.

IAM Roles vs Resource Based Policies

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

Amazon EventBridge – Security

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

SNS, SQS, Lambda에는 리소스 기반 정책, Kinesis Data Stream에는 IAM Role!!

IAM Permission Boundaries

  • IAM 권한 경계는 사용자와 역할만 지원하고 그룹은 지원하지 않는다.
  • IAM 개체가 받을 수 있는 최대 권한을 설정하기 위해 관리형 정책을 사용하는 고급 기능이다.
  • IAM 권한 경계: S3, CloudWatch, EC2를 모두 허용
    • 이를 IAM 사용자에게 연결하면 권한 경계를 설정하는 것이다. (S3, CloudWatch, EC2 내의 작업만 할 수 있 게 됨)
  • IAM 정책: iam:Createuser 액션과 ＊ 리소스를 같은 사용자에 연결하면 권한 경계와 IAM 정책을 통한 권한이 완성된다.
  • 결과적으로 어떤 권한이 생길까?
    • 놀랍게도 아무 권한도 생기지 않는다!
  • IAM 정책은 IAM 권한 경계 밖에 있기 때문에 사용자가 다른 IAM 사용자를 생성할 수 없다.

IAM Permission Boundaries

  • AWS Organizations SCP와 함께 사용할 수 있다.

    사용 사례:
  • 관리자가 아닌 사용자에게 권한 경계 내에서 책임을 위임하는 경우, 예를 들어 새 IAM 사용자 생성
  • 개발자가 자체적으로 정책을 할당하고 자신의 권한을 관리할 수 있도록 허용하면서도 "권한 상승"을 방지하여 특권을 얻을 수 없도록 함 (=자체적으로 관리자 권한 부여 불가)
  • 조직 및 SCP를 사용하면 전체 계정이 아닌 특정 사용자의 권한을 제한하는 데 유용함

IAM Policy Evaluation Logic


모든 방면에서 거부되지 않고 허용됐을 때에만 마지막 허용 여부가 결정되고 액션을 진행할 수 있다.

Example IAM Policy

  • sqs:CreateQueue를 실행할 수 있을까?
    • No!
    • sqs:*에 Deny와 ＊가 있는데, CreateQueue가 해당 블록에 포함되기 때문
  • sqs:DeleteQueue를 실행할 수 있을까?
    • No!
    • 위 쪽에는 Deny, 아래에는 Allow가 있다.
    • 하지만 명시적 거부가 있으면 바로 결정이 거부된다.
    • sqs:＊에 Deny가 명시되어 있기 때문에 sqs:* 안에 있는 sqs:DeleteQueue는 Allow가 있음에도 자동으로 거부된다.
  • ec2:DescribeInstances는 실행할 수 있을까?
    • No!
    • IAM 정책에 EC2 관련 사항은 없다.
    • 명시적 거부도 없지만 명시적 허용도 없기 때문에 해당 IAM 정책에서는 ec2:DescribeInstances를 실행할 수 없다.

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)
  • Federated Identities: Facebook, Google 등의 소셜 로그인, SAML

Integrations

  • API Gateway 및 Application Load Balancer와 통합될 수 있다.
  • API Gateway
    • 사용자는 Cognito 사용자 풀에 접속하여 토큰을 받고 검증을 위해 API Gateway로 토큰을 전달한다. 확인이 끝나면 사용자 자격 증명으로 변환되어 백엔드의 Lambda 함수로 전달된다.
  • ALB
    • Cognito 사용자 풀을 애플리케이션 로드 밸런서 위에 배치한다. 애플리케이션이 Cognito 사용자 풀에 연결한 다음 ALB에 전달해서 유효한 로그인인지 확인한다. 유효한 로그인이라면 요청을 백엔드로 리다이렉트하고, 사용자의 자격증명과 함께 추가 헤더를 전송한다.
  • API Gateway나 ALB를 통해 사용자의 로그인을 한 곳에서 확실히 검증할 수 있고 검증 책임을 백엔드로부터 백엔드의 로드를 밸런싱하는 실제 위치인 API Gateway 또는 ALB로 옮긴 것이다.

Cognito Identity Pools (Federated Identities)

  • 사용자에 대한 자격 증명을 제공하여 일시적인 AWS 자격 증명을 얻을 수 있게 한다.
  • 사용자는 Cognito 사용자 풀 내의 사용자 혹은 타사 로그인 등이 될 수 있다.
  • 사용자는 직접 또는 API Gateway를 통해 서비스에 액세스할 수 있다.
  • 자격 증명에 적용되는 IAM 정책은 Cognito에서 사전 정의되어 있다.
  • user_id를 기반으로 사용자 정의하여 세부적인 제어를 할 수 있다.
  • 게스트 사용자나 특정 역할이 정의되지 않은 인증된 사용자는 기본 IAM 역할을 상속하게 된다.

Diagram

Row Level Security in DynamoDB

  • 위 예시에서는 DynamoDB의 LeadingKey가 Cognito 자격 증명 사용자 ID와 같아야 한다는 조건이다.
  • 이 정책이 사용된 사용자는 DynamoDB 테이블의 모든 항목을 읽고 쓸 수 있는 것이 아니라, 이 조건을 통해 액세스를 얻은 항목에만 액세스할 수 있다.

Cognito: 웹이나 모바일 앱의 사용자 기반을 생성할 수 있고, 세분화된 액세스 제어를 위해 DynamoDB에서 행 수준 보안을 활성화할 수 있다. 또한 Cognito 사용자 풀과 API Gateway 또는 ALB를 통합할 수 있다.

AWS IAM Identity Center

  • AWS Single Sign-On 서비스의 후속 제품
  • 단일 로그인 기능
    • AWS Organization 내의 모든 AWS 계정
    • 비즈니스 클라우드 애플리케이션 (예: Salesforce, Box, Microsoft 365 등)
    • SAML 2.0을 지원하는 애플리케이션
    • EC2 Windows 인스턴스
  • ID 공급자
    • IAM Identity Center에 내장된 ID 저장소
    • 서드파티 ID 공급자: Active Directory (AD), OneLogin, Okta 등

AWS IAM Identity Center – Login Flow

AWS IAM Identity Center

  • 모든 것을 한 번만 로그인해도 된다는 것이 큰 장점이다. 흐름이 많이 단순화되기 때문이다.
  • 하지만 로그인했다고 해서 모든 항목에 로그인할 수 있는 것은 아니다.
  • 자격 증명 센터에서 권한 셋을 정의하여 어떤 사용자가 무엇에 액세스할 수 있는지 정의한다.

Fine-grained Permissions and Assignments

  • 다중 계정 권한 (Multi-Account Permissions)
    • AWS Organization 내의 여러 AWS 계정에 대한 액세스 관리
    • 권한 세트 (Permission Sets): 사용자 및 그룹에 할당된 하나 이상의 IAM 정책을 모아서 AWS 액세스를 정의하는 기능
  • 애플리케이션 할당 (Application Assignments)
    • SAML 2.0 비즈니스 애플리케이션(Salesforce, Box, Microsoft 365 등)에 대한 SSO(Single Sign-On) 액세스 제공
    • 필요한 URL, 인증서 및 메타데이터 제공
  • 속성 기반 액세스 제어 (Attribute-Based Access Control, ABAC)
    • 사용자의 속성에 기반한 세부적인 권한 제어
    • 예: cost center, title, locale 등과 같은 사용자 속성을 활용한 세밀한 권한 부여
    • 사용 사례: IAM 권한 세트를 한 번만 정의한 후, 이 속성을 활용하여 사용자 또는 그룹의 AWS 액세스를 수정하는 등의 유연한 권한 관리

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 (프록시)로 온프레미스 AD에 리다이렉트, 멀티팩터 인증 지원
    • 온프레미스 AD에서만 사용자를 관리할 수 있음
  • Simple AD
    • AWS의 AD 호환 관리형 디렉토리
    • Microsoft Directory를 사용하지 않으며 온프레미스 AD와도 결합되지 않는다.

온프레미스에서 사용자를 프록시한다면 AD 커넥터, AWS 클라우드에서 사용자를 관리하고 MFA를 사용해야 할 때는 AWS 관리형 AD, 온프레미스가 없을 땐 Simple AD

IAM Identity Center – Active Directory Setup

  • Directory 서비스를 통해 AWS 관리형 AD를 연결하는 경우
    • 통합은 즉시 사용 가능하다.
  • 자체 관리형 디렉터리에 연결하는 경우
    • AWS 관리형 Microsoft AD를 사용하여 양방향 신뢰 관계 구축
      • 클라우드에 있는 액티브 디렉터리에서 사용자를 관리하고 싶을 때
    • AD Connector 활용
      - API 호출만 프록시할 때 - 지연 시간이 길어지긴 함

AWS Control Tower

  • 모범 사례를 기반으로 안전하고 규정을 준수하는 다중 계정 AWS 환경을 손쉽게 설정하고 관리할 수 있다.
  • AWS Control Tower 서비스는 AWS Organizations를 사용하여 계정을 생성한다.
  • 장점:
    • 몇 번의 클릭만으로 환경 설정 자동화
    • 가드레일을 사용하여 지속적인 정책 관리 자동화
    • 정책 위반 감지 및 조치
    • 대화형 대시보드를 통한 규정 준수 모니터링

Guardrails

  • AWS Control Tower의 가드레일은 Control Tower 환경 내의 모든 AWS 계정에 대한 지속적인 거버넌스를 제공한다.
  • 예방적 가드레일 (Preventive Guardrail)
    • SCP(Security Control Policies)를 사용하여 구현
    • ex. 모든 계정에서 리전 제한을 설정하여 특정 리전의 사용을 제한
  • 탐지적 가드레일 (Detective Guardrail)
    • AWS Config를 사용하여 구현
    • ex. 태그가 지정되지 않은 리소스 식별
profile
정지범
안녕하세요
이전 포스트

AWS[Monitoring, Audit and Performance: CloudWatch, CloudTrail & AWS Config]

다음 포스트

AWS[AWS Security & Encryption]

0개의 댓글