Baelog 🏝️
[Cloud] AWS IAM: 기업에서 Assume Role을 이용해 사용자 권한을 관리

[Cloud] AWS IAM: 기업에서 Assume Role을 이용해 사용자 권한을 관리


AWS Cloud IAM

IAM 리소스

사용자 그룹 (User Group)

  • 여러 IAM 사용자를 하나로 묶어 동일한 권한을 부여할 수 있는 리소스
  • 사용자 그룹에 정책을 연결하면 해당 그룹에 속한 모든 사용자가 해당 권한을 가지게 됨
  • 개별 사용자에게 정책을 적용하지 않고도 일괄적인 권한 관리 가능

사용자 (User)

  • AWS 계정에 속한 개별 엔터티로, 각 사용자는 고유의 **자격 증명(로그인 정보)**을 가짐
  • 특정한 사람이나 애플리케이션이 AWS 리소스에 접근할 수 있도록 권한 설정

역할 (Role)

  • IAM 사용자 또는 서비스에 임시 권한을 부여하기 위한 리소스
  • 특정 엔터티가 AWS 리소스에 접근할 때 고정된 자격 증명이 아니라 임시 자격 증명을 사용하도록 함
  • 주로 신뢰 관계에 있는 서비스나 외부 사용자에게 사용됨

신뢰할 수 있는 엔터티 (Trusted Entity)

  • 역할을 위임받아 사용하는 계정이나 서비스
  • 종류
    • IAM User
    • IAM Role
      • 또 다른 역할 자체를 신뢰할 수 있는 엔터티로 지정 가능
      • 하나의 역할이 다른 역할을 위임받아 그 권한을 행사 가능
    • AWS Service
      • EC2, Lambda, ECS 작업 등이 IAM 역할을 사용해 다른 AWS 서비스에 대한 접근 요청
      • 신뢰 정책을 다른 AWS 서비스의 ARN을 지정해 서비스가 역할을 사용할 수 있게 함
    • AWS Account
      • 특정 AWS 계정 전체를 신뢰할 수 있는 엔터티로 설정
      • 해당 계정 내의 사용자, 역할, 서비스들이 지정된 역할에 접근 가능
      • 여러 AWS 계정을 운영하는 멀티 계정 환경에서 주로 사용됨
    • Identity Provider
      • AWS 외부의 SAML 2.0, Open ID Connect (OIDC) 같은 자격 증명 공급자를 통해 인증된 엔터티를 신뢰
      • 회사의 SSO 시스템을 통해 인증된 사용자가 AWS 역할에 접근하도록 설정 가능
      • 외부 시스템과 AWS 간의 연동에 유용

정책 (Policy)

  • AWS 리소스에 대한 권한을 정의하는 문서
  • JSON 형식으로 작성되며, 특정 작업을 허용하거나 거부할 수 있음
  • AmazonS3ReadOnlyAccess 예시
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*",
                "s3:Describe*",
                "s3-object-lambda:Get*",
                "s3-object-lambda:List*"
            ],
            "Resource": "*"
        }
    ]
}
  • 관리형 정책 (Managed Policy)
    • AWS에서 제공하거나 사용자가 정의한 정책을 여러 IAM에 쉽게 적용
  • 인라인 정책 (Inline Policy)
    • 특정 엔터티에 직접 연결되는 정책으로, 재사용되지 않음

자격 증명 공급자 (IdP, Identity Provider)

  • 외부 서비스 (SAML 2.0 or OIDC)를 통해 AWS 자격 증명을 인증하는 데 사용되는 리소스
  • 이를 통해 외부 시스템의 사용자들이 AWS 리소스에 접근 가능
  • 예시: 외부 CICD 파이프라인 애드온 인증을 위한 자격 증명 제공

Assume Role

  • 한 Role의 권한을 일시적으로 다른 사용자나 서비스가 사용할 수 있게 하는 것
  • 여러 AWS 계정이나 서비스 간에 보안 권한을 쉽게 위임할 수 있음

사용 사례

  1. 다중 계정 간 작업
    • A 계정의 사용자나 서비스가 B 계정의 리소스에 접근해야 할 때
    • B 계정에서 역할을 설정하고 A 계정의 사용자가 그 역할을 Assume하도록 허용
  2. 서비스 간 권한 부여
    • EC2 인스턴스가 S3 버킷에 접근해야 하는 경우
    • 해당 EC2 인스턴스가 IAM 역할을 Assume해 S3에 접근할 수 있는 권한 획득
  3. 임시 권한
    • 특정 작업을 일시적으로 수행할 때 필요한 권한만을 부여
    • 사용자가 제한된 권한을 갖고 있지만, 특정 시간에만 관리 권한을 가져야 할 경우 Assume Role을 통해 임시로 권한 위임

작동 방식

  1. Role 생성
    • IAM에서 Role을 생성하고 권한(Policy)을 지정
  2. Trust Policy 설정
    • 역할을 누가 (사용자, 서비스 등) Assume할 수 있는지 정의하는 신뢰 정책을 설정
  3. Assume Role API 호출
    • sts:AssumeRole API를 사용자가 호출해 역할을 가정
    • 호출 성공시 AWS에서 해당 역할을 임시로 사용할 수 있는 자격 증명(STS, 임시 보안 토큰)을 발급
      • STS는 일정 시간이 지나면 만료됨
  4. STS 사용
    • 발급 받은 임시 자격 증명을 사용해 해당 역할의 권한을 가진 작업 수행

실제 기업에서 사용자 권한을 중앙 관리하는 방법

  • 기업에서는 수많은 조직의 수많은 직원이 수많은 계정에 접근해 프로젝트를 수행
  • 실제로 계정마다 사용자를 다~~~ 생성하면 너무 관리가 힘들겠죠?
  • 보안 계정에서 시작해 다른 계정의 특정 역할로 전환하는 방식으로 중앙 제어
    • 계정에 역할을 생성 (e.g., sever_admin, db_admin, …)
    • 역할 신뢰 관계에 보안 계정의 사용자 추가

로그인 매커니즘

  1. AWS 보안 계정에 사용자(자신)로 로그인
  2. Assume Role로 역할 전환 -> STS 발급됨
  3. STS를 통해 리소스 사용
© 2024 Seungwon Bae 🇰🇷