[AWS SAA-C03] AWS IAM Role 정리

AWS IAM Role

• IAM 역할은 사용자와 매우 유사하다. AWS에서 ID가 수행할 수 있는 작업과 수행할 수 없는 작업을 결정하는 사용 권한 정책이 있는 ID이다.
• IAM 역할은 특정 사용자, 그룹 또는 서비스와 고유하게 연관되도록 의도된 것이 아니며 이를 필요로 하는 모든 사용자가 가정할 수 있도록 의도된 것이다.
• 역할에 연결된 정적 자격 증명(암호 또는 액세스 키)이 없으며 역할을 맡은 사용자에게 동적 임시 자격 증명이 제공된다.
• 역할은 액세스 위임에서 사용자가 제어하는 리소스에 대한 액세스를 허용하는 사용 권한을 부여하는 데 도움이 된다.
• 역할은 중요한 리소스에 실수로 액세스하거나 수정하는 것을 방지하는 데 도움이 된다.
• 역할 수정은 언제든지 수행할 수 있으며 변경 내용은 역할과 연결된 모든 엔티티에 즉시 반영된다.
• 다음 시나리오에서 IAM 역할이 매우 중요한 역할을 수행한다.
  = 다른 AWS 서비스에 액세스해야 하는 애플리케이션을 실행하는 EC2 인스턴스와 같은 서비스이다.
  = 교차 계정 액세스(Cross-Account access): 서로 다른 AWS 계정의 사용자가 다른 계정의 AWS 리소스에 액세스할 수 있도록 허용한다.
  = ID 제공자 및 연합(Federation)
  . 회사는 회사 인증 메커니즘을 사용하며 사용자가 AWS에서 두 번 인증하거나 중복 사용자를 생성하는 것을 원하지 않는다.
  . 외부 인증 매커니즘을 통한 로그인을 허용하는 응용 프로그램이다. 아마존, 페이스북, 구글 등 역할은 다음과 같이 가정할 수 있다.
• 역할은 다음과 같이 가정할 수 있다.
  = 동일한 AWS 계정 내의 IAM 사용자
  = 다른 AWS 계정 내의 IAM 사용자
  = 다른 서비스와 상호 작용하기 위한 EC2, EMR과 같은 AWS 서비스
  = SAML 2.0 또는 Open과 호환되는 외부 ID 제공자(IdP) 서비스에서 인증한 외부 사용자 ID Connect(OIDC)
  = 또는 사용자 지정 ID 브로커
• 역할에는 두 가지 정책 정의가 필요하다.
  = 신뢰 정책(Trust Policy)
  . 신뢰 정책 정의: 역할을 맡을 수 있는 사용자
  . 신뢰 정책에는 리소스를 소유하는 계정(신뢰 계정)과 리소스에 대한 액세스가 필요한 사용자를 소유하는 계정(신뢰 계정) 간에 신뢰를 설정하는 작업이 포함된다.
  = 권한 정책(Permission policy)
  . 사용 권한 정책 정의(Permissions policy defines): 사용자가 액세스할 수 있는 항목
  . 권한 정책은 권한 부여를 결정하여 역할의 사용자에게 리소스에서 원하는 작업을 수행하는 데 필요한 권한을 부여한다.
• 연합(Federation)에서 외부 ID 제공자(IdP)와 AWS 간에 신뢰 관계를 만들고 있다.
  = 사용자는 SAML과 호환되는 엔터프라이즈 ID 시스템에 로그인할 수도 있다.
  = 사용자는 Amazon, Facebook, Google 또는 다른 OpenID Connect(OIDC)와 호환되는 IdP 로그인과 같은 웹 ID 제공자에 로그인할 수 있다.
  = OIDC 및 SAML 2.0을 사용하여 이러한 외부 ID 제공자와 AWS 간의 신뢰 관계를 구성할 때 사용자는 IAM 역할에 할당되고 AWS 리소스에 액세스할 수 있는 임시 자격 증명을 받는다.
• IAM 모범 사례: EC2 인스턴스에서 실행 중인 애플리케이션에 역할 사용
• IAM 모범 사례: 딜러가 자격 증명을 공유하는 대신 역할을 사용

AWS STS 및 임시 자격 증명

• AWS STS(Security Token Service)는 신뢰할 수 있는 사용자에게 AWS 리소스에 대한 액세스를 제어하는 임시 보안 자격 증명을 생성하고 제공하는 데 도움이 된다.
• STS는 단일 끝점 https://sts.amazonaws.com을 사용하는 글로벌 서비스이다.
• AWS STS API 호출은 글로벌 엔드포인트 또는 지역 엔드포인트 중 하나로 수행할 수 있다. 지역별 엔드포인트를 통해 대기 시간을 줄이고 API 호출의 성능을 향상시킬 수 있다.
• 임시 자격 증명은 다음을 제외하고 장기 자격 증명과 유사하다.
  = 단기이며 정기적으로 순환(rotated)한다.
  = 몇 분에서 몇 시간까지 지속되도록 구성할 수 있다.
  = 포함되거나 배포될 필요가 없다.
  = 사용자와 함께 저장되거나 연결되지 않지만 동적으로 생성되어 요청에 따라 사용자에게 제공된다.

AWS Service Roles

• 일부 AWS 서비스는 다른 AWS 서비스와 상호 작용해야 한다. S3, SQS 등과 상호작용하는 EC2 IAM 사용자 자격 증명을 인스턴스에 직접 포함하거나 전달하는 대신 이러한 서비스를 IAM 역할로 할당하는 것이 가장 좋다. 장기 자격 증명을 여러 인스턴스에 배포하고 순환하는 것은 관리가 어렵고 잠재적인 보안 위험이 있기 때문이다.
• AWS는 이러한 서비스(ex: EC2 인스턴스)에 대해 애플리케이션 대신 사용할 임시 보안 자격 증명을 자동으로 제공한다.
• 실행 중인 EC2 인스턴스와 연결된 역할 또는 인스턴스 프로파일을 삭제하면 인스턴스에서 실행 중인 모든 애플리케이션이 중단된다.

실행 흐름(Complete Process Flow)

1. EC2와 같이 신뢰할 수 있는 엔티티이며 서비스에 필요한 액세스 권한을 가진 권한 정책을 정의한 IAM 역할을 만든다.
2. 인스턴스가 시작될 때 역할(실제로는 인스턴스 프로파일)을 EC2 서비스와 연결한다.
3. 임시 보안 자격 증명은 인스턴스에서 사용할 수 있으며, 유효한 집합을 항상 사용할 수 있도록 만료되기 전에 자동으로 순환된다.
4. 애플리케이션은 인스턴스 메타데이터를 직접 사용하거나 AWS SDK를 통해 임시 자격 증명을 검색할 수 있다.
5. 이제 EC2 인스턴스에서 실행 중인 애플리케이션이 역할에 정의된 사용 권한을 사용하여 다른 AWS 리소스에 액세스할 수 있다.
6. 자격 증명을 캐싱하는 경우 응용 프로그램이 만료되기 전에 올바른 자격 증명을 사용하는지 확인해야 한다.

인스턴스 프로파일(Instance Profile)

• 인스턴스 프로파일은 인스턴스가 시작될 때 역할 정보를 EC2 인스턴스에 전달하는 데 사용할 수 있는 IAM 역할의 컨테이너이다.
• AWS Management Console을 통해 EC2 인스턴스 또는 EC2를 사용하는 다른 서비스에 대해 역할이 생성된 경우 AWS는 역할과 동일한 이름의 인스턴스 프로파일을 자동으로 생성한다. 그러나 CLI를 통해 역할을 생성하는 경우 인스턴스 프로필도 생성해야 한다.
• 인스턴스 프로파일에는 IAM 역할이 하나만 포함될 수 있다. 그러나 역할은 여러 인스턴스 프로필에 포함될 수 있다.

Service-linked Roles

• 서비스 연결 역할은 AWS 서비스에 직접 연결된 고유한 유형의 IAM 역할입니다.
• 서비스 연결 역할은 서비스에 의해 미리 정의도며 사용자 대신 다른 AWS 서비스를 호출하는 데 서비스에 필요한 모든 권한이 포함된다.
• 서비스 연결 역할은 IAM 계정에 표시되며 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할에 대한 사용 권한을 볼 수 있지만 편집할 수는 없다.

Cross-Account access Roles

• IAM 사용자에게 동일한 AWS 계정 내의 역할 또는 사용자가 소유한 다른 AWS 계정에 정의된 역할을 전환할 수 있는 권한을 부여할 수 있다.
• 역할을 사용하여 타사가 소유한 AWS 계정에서 IAM 사용자에게 권한을 위임할 수 있다.
• 사용자에게 역할을 인수할 수 있는 권한을 명시적으로 부여해야 한다.
• 사용자는 AWS Management Console을 사용하여 역할로 능동적으로 전환해야 한다.
• MFA 장치로 로그인한 사용자만 역할을 맡을 수 있도록 역할에 대해 MFA(다중 요소 인증) 보호를 사용하도록 설정할 수 있다.
• 그러나 한 번에 하나의 권한 집합을 적용할 수 있다. 역할을 임시로 사용하는 사용자는 자신의 권한을 포기하고 대신 역할을 권한을 사용한다. 사용자가 역할을 종료하거나 사용을 중지하면 원래 사용자 권한이 복원된다.

Complete Process Flow

1. 계정을 신뢰하면 다음과 같은 IAM 역할이 생성된다.
   • 계정(신뢰할 수 있는 계정; trusted account)을 리소스에 액세스할 수 있는 주체로 정의하는 신뢰 정책
   • 신뢰할 수 있는 계정의 사용자가 액세스할 수 있는 리소스를 정의하는 사용 권한 정책
2. 신뢰할 수 있는 계정은 신뢰할 수 있는 계정에 계정 ID 및 역할 이름(또는 ARN)을 제공한다.
3. 신뢰 계정이 타사에 의해 소유된 경우 신뢰할 수 있는 계정을 고유하게 식별하는 데 필요한 외부 ID(추가 보안을 위해 권장)를 선택적으로 제공할 수 있다. 이 ID는 신뢰 정책에 조건으로 추가할 수 있다.
4. 신뢰할 수 있는 계정은 역할/스위치를 역할로 인계할 수 있는 권한(AWS STS(Security Token Service) AssumeRole API 호출 권한)을 가진 IAM 사용자를 생성한다.
5. 신뢰할 수 있는 계정의 IAM 사용자가 역할로 전환/역할 인수 및 역할의 ARN을 전달한다.
6. 타사에 속하는 신뢰할 수 있는 계정도 신뢰할 수 있는 계정에 매핑된 외부 ID를 전달한다.
7. AWS STS는 역할 ARN에 대한 요청, 외부 ID(있는 경우) 및 역할의 신뢰 정책과 일치하는 신뢰할 수 있는 리소스의 요청인지 확인한다.
8. 확인이 성공하면 AWS STS가 임시 자격 증명을 반환한다.
9. 임시 자격 증명을 통해 사용자는 신뢰 계정의 리소스에 액세스할 수 있다.
10. 사용자가 역할을 종료하면 사용자의 사용 권한이 역할로 전환하기 전에 보유한 원래 사용 권한으로 돌아간다.

External ID and Confused Deputy Problem

• 외부 ID를 사용하면 역할을 맡은 사용자가 자신이 작동 중인 상황을 주장할 수 있다.
• 외부 ID는 계정 소유자가 특정 상황에서만 역할을 맡을수 있도록 허용하는 방법을 제공하여 권한이 없는 고객이 리소스에 액세스하는 것을 방지한다.
• 외부 ID의 주요 기능은 "혼란스러운 대리인" 문제를 해결하고 방지하는 것이다.

혼동된 대리인 문제(Confused Deputy Problem)

1. Example Corp's의 AWS 계정은 여러 AWS 계정에 서비스(데이터 액세스, 분석 처리 및 보고서 반환)를 제공한다.
2. 선호되는 메커니즘은 각 AWS 계정 고객이 Example Corp의 계정 사용자가 맡고 행동할 수 있는 역할을 정의하도록 하는 것이다.
3. 역할 및 역할 ARN 제공을 통해 AWS 계정에 대한 Example Corp의 AWS 계정 액세스 권한을 제공한다.
4. Exmple Corp는 계정에서 작업할 때 IAM 역할을 맡고 ARN에 요청을 제공한다.
5. Example Corp는 이미 당신의 계정에 의해 신뢰되고 있으므로 임시 보안 자격 증명을 수신하고 귀하의 리소스에 대한 액세스 권한을 얻는다.
6. 만약에 다른 AWS 계정이 당신의 ARN(계정 ID를 가진 역할)을 알고 추측할 수 있다면, 그것은 Example Corp's에 동일한 것을 제공할 수 있다.
7. Example Corp's는 데이터를 처리하기 위해 ARN(사용자의 AWS 계정에 속함)을 사용하지만 동일한 데이터를 다른 AWS 계정에 제공한다.
   이러한 형태의 권한 상승은 혼란스러운 대리인 문제로 알려져 있다.

• Example Corp's는 External ID를 사용하여 고객마다 고유한 External ID를 생성한다. 이 ID는 고객에게만 알려져 있으며 비밀로 유지된다.
• Example Corp는 신뢰 정책을 정의하는 동안 조건으로 추가해야 하는 외부 ID를 제공한다.
• 역할 및 역할 ARN 제공을 통해 AWS 계정에 대한 Example Corp의 AWS 계정 액세스 권한을 제공한다.
• Example Corp는 계정에서 작업할 때 IAM 역할을 사용하고 외부 ID와 함께 ARN을 제공하며 이미 신뢰할 수 있으므로 액세스 권한을 얻을 수 있다.
• Example Corp에 등록된 다른 AWS 계정에는 고유한 외부 ID가 할당된다.
• 만약 다른 AWS 계정이 당신의 ARN(계정 ID를 가진 역할)을 알거나 추측할 수 있다면, 그것은 Example Corp에 동일한 것을 제공할 수 있다.
• Example Corp는 ARN(AWS 계정에 속함)을 사용하여 계정에 대한 액세스를 요청하지만 요청이 대신 이루어졌기 때문에 다른 AWS 계정에 속한 외부 ID를 사용한다.
• Example Corp에서 제공한 외부 ID가 역할 신뢰 정책에 정의된 조건과 일치하지 않으므로 인증이 실패하여 액세스가 거부된다.

출처: https://jayendrapatil.com/aws-iam-role/