Identity and Access Management - 고급

AWS STS (Security Token Service)

• Allows to grant limited and temporary access to AWS resources.

• Token is valid for up to one hour (must be refreshed)

• AssumeRole
  Within your own account: for enhanced security
Cross Account Access: assume role in target account to perform actions there

• AssumeRoleWithSAML: return credentials for users logged with SAML

• AssumeRoleWithWebIdentity:

• returen creds for users logged with an IdP (Facebook, Google, OIDC...)

• AWS recommends against using this, and using Cognito instead

• GetSessionToken: for MFA, from a user or AWS account root user

Using STS to Assume a Role

• Define an IAM Role within your account or cross-account
• Define which principals can access this IAM Role
• Use AWS STS to retrive credentials and impersonate the IAM Role you have access to (AssumeRole API)
• Temporary credentials can be valid between 15 minutes to 1 hour

Identity Federation in AWS

• Federation lets users outside of AWS to assume temporary role for accessing AWS resources.
• These users assume identity provided access role.

Federations can have many flavors:

• SAML 2.0
• Custom Identity Broker
• Web Identity Federation with Amazon Cognito
• Web Identity Federation without Amazon Cognito
• Single Sign On
• Non-SAML with AWS Microsoft AD

✅ Using federation, you don't need to create IAM users (user management is outside of AWS)

AWS Security Token Service (AWS STS)를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰받는 사용자에게 제공할 수 있습니다. 임시 보안 자격 증명은 다음과 같은 차이점을 제외하고는 IAM 사용자가 사용할 수 있는 장기 액세스 키 자격 증명과 거의 동일한 효력을 지닙니다.

• 임시 보안 자격 증명은 그 이름이 암시하듯 단기적입니다. 이 자격 증명은 몇 분에서 몇 시간까지 지속되도록 구성할 수 있습니다. 자격 증명이 만료된 후 AWS는 더는 그 자격 증명을 인식하지 못하거나 그 자격 증명을 사용한 API 요청으로부터 이루어지는 어떤 종류의 액세스도 허용하지 않습니다.

• 임시 보안 자격 증명은 사용자와 함께 저장되지 않지만 동적으로 생성되어 요청시 사용자에게 제공됩니다. 임시 보안 자격 증명이 만료되었을 때(심지어는 만료 전이라도) 사용자는 새 자격 증명을 요청할 수 있습니다. 단, 자격 증명을 요청하는 해당 사용자에게 그렇게 할 수 있는 권한이 있어야 합니다.

이러한 차이점은 다음과 같은 임시 자격 증명 사용의 이점을 발생시킬 수 있습니다.

• 애플리케이션으로 장기 AWS 보안 자격 증명을 배포 또는 포함할 필요가 없습니다.
• 사용자에 대한 AWS 자격 증명을 정의하지 않고도 AWS 리소스에 대한 액세스 권한을 사용자에게 제공할 수 있습니다. 임시 자격 증명은 역할 및 ID 페더레이션을 위한 기초입니다.
• 임시 보안 자격 증명은 수명이 제한되어 있어서, 더 이상 필요하지 않을 때 교체하거나 명시적으로 취소할 필요가 없습니다. 임시 보안 자격 증명이 만료된 후에는 다시 사용할 수 없습니다. 그 자격 증명에 대해 유효 기간을 최대 한계까지 지정할 수 있습니다.

AWS STS 및 AWS 리전

임시 보안 자격 증명은 AWS STS에 의해 생성됩니다. 기본적으로 AWS STS는 https://sts.amazonaws.com에 단일 엔드포인트가 있는 전역적 서비스입니다. 그러나 지원되는 기타 다른 리전에서 엔드포인트에 대한 AWS STS API 호출을 할 수도 있습니다. 이렇게 지리적으로 더 가까운 리전에 있는 서버로 요청을 전송함으로써 지연 시간(서버 랙)을 단축할 수 있습니다. 자격 증명은 어떤 리전에서 오는지 상관없이 전역적으로 유효합니다.

임시 자격 증명과 관련된 일반적인 시나리오

임시 자격 증명은 ID 페더레이션, 위임, 교차 계정 액세스, IAM 역할 등의 시나리오에서 유용합니다.

ID 페더레이션

AWS 밖의 외부 시스템에서 사용자 자격 증명을 관리할 수 있고 해당 시스템을 통해 로그인하는 사용자에게 액세스 권한을 부여하여 AWS 작업을 수행하고 AWS 리소스에 액세스할 수 있습니다. IAM은 두 가지 ID 페더레이션 유형을 지원합니다. 두 경우 모두 자격 증명은 AWS 외부에 저장됩니다. 외부 시스템이 상주하는 위치, 즉 데이터 센터 또는 웹의 외부 서드 파티에 따라 구분됩니다.

• 엔터프라이즈 ID 페더레이션: 조직의 네트워크에서 사용자를 인증한 다음, 해당 사용자에 대한 새로운 AWS 자격 증명을 생성하지 않고 또한, 사용자에게 별도의 사용자 이름 및 암호로 로그인하도록 요구하지 않고도 AWS에 대한 액세스 권한을 사용자에게 제공할 수 있습니다. 이는 임시 액세스 권한에 대한 SSO(Single Sign-On) 접근 방식으로 알려져 있습니다. AWS STS는 SAML 2.0(Security Assertion Markup Language 2.0)과 같은 개방형 표준을 지원합니다. 이를 통해 Microsoft AD FS를 사용해 Microsoft Active Directory를 최대한 활용할 수 있습니다. 또한, SAML 2.0을 사용해 사용자 자격 증명 연동을 위한 자신만의 솔루션을 관리할 수 있습니다.

• 사용자 지정 페더레이션 브로커: 조직의 인증 시스템을 사용해 AWS 리소스에 대한 액세스 권한을 부여할 수 있습니다.
• SAML 2.0을 사용한 페더레이션: 조직의 인증 시스템과 SAML을 사용해 AWS 리소스에 대한 액세스 권한을 부여할 수 있습니다.

• 웹 ID 페더레이션 - Login with Amazon, Facebook, Google 또는 OpenID Connect(OIDC) 2.0 호환 공급자와 같은 유명한 서드 파티 자격 공급자를 사용해 사용자가 로그인할 수 있습니다. 그 공급자로부터 얻은 자격 증명을 AWS 계정 리소스 사용 권한과 교환할 수 있습니다. 이는 임시 액세스 권한에 대한 웹 ID 페더레이션을 사용하면 사용자 지정 로그인 코드를 생성하거나 자신의 사용자 자격 증명을 관리할 필요가 없습니다. 웹 ID 페더레이션을 사용하면 AWS 계정을 안전하게 보호할 수 있는 이점이 있습니다. 애플리케이션으로 IAM 사용자 액세스 키 같은 장기 보안 자격 증명을 배포할 필요가 없기 때문입니다.

모바일 애플리케이션의 경우 Amazon Cognito를 사용하는 것이 좋습니다. 이 서비스와 함께 AWS Mobile SDK for IOS 및 AWS Mobile SDK for Android and Fire OS를 사용하면 사용자의 고유 자격 증명을 생성하고 사용자를 인증하여 AWS 리소스에 안전하게 액세스하도록 할 수 있습니다. Amazon Cognito는 AWS STS와 동일한 자격 증명 공급자를 지원하고 인증되지 않은 액세스도 지원하며 사용자가 로그인할 때 사용자 데이터를 마이그레이션 할 수 있습니다. 또한, Amazon Cognito는 사용자가 디바이스간에 이동할 때 데이터가 보존되도록 사용자 데이터를 동기화하기 위한 API 작업도 제공합니다.

SAML 2.0

AWS는 많은 자격 증명 공급자(IdP: Identity Provider)가 사용하는 개방형 표준인 SAML 2.0(Security Assertion Markup Language 2.0)이라는 ID 페더레이션을 지원합니다. 이 기능은 페더레이션 통합 인증(SSO)을 활성화하므로 조직의 모든 구성원에 대해 IAM 사용자를 생성하지 않아도 사용자가 AWS Management Console에 로그인하거나 AWS API 작업을 호출할 수 있습니다. SAML을 사용함으로써 AWS로 연동을 구성하는 과정을 단순화할 수 있는데, 이는 사용자 지정 자격 증명 프록시 코드를 작성하는 대신 IdP의 서비스를 사용할 수 있기 때문입니다.

IAM 페더레이션은 다음과 같은 사용 사례를 지원합니다.

AWS에 대한 API 액세스를 위해 SAML 기반 페더레이션 사용

직원들에게 자신의 컴퓨터에서 백업 폴더로 데이터를 복사하는 방법을 제공하려 한다고 가정해 봅시다. 사용자가 컴퓨터에서 실행하는 애플리케이션을 구축합니다. 그 애플리케이션은 백엔드에서 S3 버킷에 있는 객체를 읽고 씁니다. 사용자는 AWS에 직접 액세스할 수 없습니다. 그 대신 다음 프로세스를 사용합니다.

1. 조직 내 사용자가 클라이언트 앱을 사용해 조직의 IdP로부터 인증을 요청
2. IdP가 조직의 자격 증명 스토어를 이용하여 사용자를 인증
3. IdP가 사용자에 대한 정보로 SAML 어설션을 만들어 클라이언트 앱으로 전송
4. 클라이언트 앱이 AWS STS AssumeRoleWithSAML API를 호출하면서 SAML 공급자의 ARN, 수임할 역할의 ARN, IdP로부터 받은 SAML 어설션을 전달
5. 클라이언트 앱에 대한 API 응답에는 임시 보안 자격 증명이 포함
6. 클라이언트 앱이 임시 보안 자격 증명을 사용하여 Amazon S3 API 작업을 호출

사용자 지정 자격 증명 브로커가 AWS 콘솔에 액세스할 수 있도록 하기

코드를 작성하고 실행해 조직 네트워크에 로그인하는 사용자가 AWS Management Console에 안전하게 액세스할 수 있게 하는 URL을 생성할 수 있습니다. URL에는 AWS에서 얻고 AWS에 사용자를 인증하는 로그인 토큰이 포함되어 있습니다. 조직의 사용자가 AWS Management Console에 액세스할 수 있도록 하는 경우 다음 단계를 수행하여 사용자 지정 자격 증명 브로커를 생성할 수 있습니다.

1. 사용자가 로컬 자격 증명 시스템에 의해 인증되는지 확인
2. AWS Security Token Service AssumeRole(권장) 또는 GetFederationToken API 작업을 호출하여 사용자를 위한 임시 보안 자격 증명을 얻을 수 있습니다.
3. AWS 연동 엔드포인트를 호출하고 임시 보안 자격 증명을 제공하여 로그인 토큰을 요청
4. 토큰을 포함하는 콘솔에 대한 URL 생성
5. 사용자에게 URL을 부여하거나 사용자 대신 URL 호출

Microsoft Active Directory (AD)

Microsoft AD란 AD 도메인 서비스와 함께 모든 Windows 서버에서 찾을 수 있는 소프트웨어입니다. 객체 데이터베이스이고 여기서 객체는 사용자 계정과 컴퓨터, 프린터, 파일 공유 보안 그룹이 될 수 있습니다. 전체 Microsoft 생태계에서 온프레미스로 관리되는 모든 사용자는 Microsoft AD에서 관리됩니다. 중앙 보안 관리로서 계정을 만들고 허가를 발급하는 등의 작업을 할 수 있으며 모든 객체들은 트리(tree)로 조직화되며 트리의 그룹은 포리스트(forest)라는 용어로 부릅니다.

예를 들어 도메인 제어기가 있다고 가정했을 때 여기에 계정을 만들건데 사용자 이름은 John 암호는 password입니다. 네트워크 내에 있는 모든 Windows 머신들이 이 도메인 제어기에 연결될 것이고 첫 번째 머신에 방금 만든 계정을 입력하면 제어기 내에서 계정 정보를 찾아 계정 정보가 일치할 경우 그 머신에서 로그인하게 해줍니다. 머신들이 전부 도메인 제어기에 연결되기 때문에 어떤 머신에서도 사용자가 액세스 가능하도록 할 수 있습니다. 그게 Active Directory의 대략적인 개념입니다.

AWS Directory Services

AWS Managed Microsoft AD

• 로컬에서 사용자 관리, 멀티팩터 인증 지원
• 사용자가 있는 다른 온프레미스 AD와 신뢰 관계 생성

AD Connector

• 온프레미스 AD로 리디렉트, 온프레미스 AD에서만 사용자를 관리하는 Directory Gateway
• 사용자가 AD Connector로 로그인하면 그 요청을 온프레미스 AD로 프록시하여 탐색

Simple AD

Simple AD는 다음에서 완벽하게 관뢰되는 Samba 기반 디렉터리를 생성합니다. AWS 클라우드 Simple AD를 사용하여 디렉터리를 만들 때 AWS Directory Service가 사용자를 대신하여 자동으로 두 개의 도메인 컨트롤러와 DNS 서버를 생성합니다. 도메인 컨트롤러는 VPC 내의 서로 다른 서브넷에 생성됩니다. 이 중복으로 인해 장애가 발생하더라도 디렉터리에 액세스할 수 있습니다.

온프레미스로 사용자를 프록시한다면 AD Connector 또는 AWS 내 클라우드에서 사용자를 관리하고 MFA를 받겠다면 AWS Managed AD, 온프레미스 디렉터리가 없는 경우 필요한 걸 물어본다면 Simple AD

AWS Organizations

AWS Organizations는 여러 AWS 계정을 사용자가 생성하고 중앙에서 관리하는 단일 조직으로 통합할 수 있는 계정 관리 서비스입니다. 조직을 사용하면 멤버 계정을 생성하고, 조직에 가입하도록 기존 계정을 초대할 수 있습니다. 이러한 계정을 그룹으로 구성하고 정책 기반 제어 항목을 연결할 수 있습니다.

Organizations AWS Control Tower에서 결제를 관리하고, 액세스, 규정 준수 및 보안을 제어하고, 멤버 AWS 계정 전체에서 리소스를 공유하는 일을 모두 중앙에서 처리할 수 있습니다. 계정은 조직 단위(OU)라고 하는 논리 그룹으로 그룹화됩니다.

SCP (Service Control Policies)

SCP(서비스 제어 정책)는 조직의 권한을 관리하는 데 사용할 수 있는 조직 정책 유형입니다. SCP는 조직의 모든 계정에 사용 가능한 최대 권한을 중앙에서 제어합니다. SCP를 사용하면 조직의 액세스 제어 지침에 따라 계정을 유지할 수 있습니다. SCP는 활성화된 모든 기능을 가진 조직에서만 사용할 수 있습니다. 조직이 통합 결제 기능만 지원한다면 SCP를 이용할 수 없습니다.

SCP만으로는 조직 내 계정에 권한을 부여하기에 충분하지 않습니다. SCP는 어떠한 권한도 부여하지 않습니다. SCP는 계정 관리자가 영향을 받는 계정의 IAM 사용자 및 역할에 위임할 수 있는 작업에 대해 권한 범위를 정의하거나 제한을 설정합니다.

1. 어떤 모바일 애플리케이션에서 사용자들이 S3 버킷 내의 개인 공간으로 액세스할 수 있게 만들려 합니다. 이를 위해서는 어떻게 해야 할까요 ?

• A. 애플리케이션의 각 사용자마다 IAM 사용자 자격 증명을 생성
• B. Amazon Cognito 신원 연결을 생성
• C. SAML 신원 연결을 사용
• D. 버킷 정책을 사용해 버킷을 공용으로 만들기

✅ SAML 자격 증명 연동은 Microsoft Active Directory와 같은 자격 증명 공급자 서비스를 AWS와 통합하는 데 사용됩니다. 모바일 애플리케이션에서는 작동하지 않습니다. 반면 Amazon Cognito는 모바일 사용자 계정을 연결하고 이들에게 IAM 권한을 제공하는 방식으로 S3 버킷 내의 개인 공간에 액세스할 수 있게 해줍니다.

2. SAML 2.0을 지원하지 않는 온프레미스 자격 증명 제공자가 있으며, 온프레미스 사용자들에게 여러분이 관리 중인 AWS 계정 내 리소스에 대한 액세스 권한을 부여하려 합니다. 어떻게 해야 할까요 ?

• A. 사용자 지정 자격 증명 브로커를 사용해 사용자들을 인증하고, AssumeRole 또는 GetFederationToken STS 호출을 사용해 AWS STS에서 임시 자격 증명 받기
• B. Microsoft AD 각 사용자의 모든 AWS 계정에 대해 상응하는 IAM 사용자를 생성하는 Lambda 함수를 생성
• C. SAML 신원 연결을 사용

3. 내부 감사가 완료된 AWS 서비스만을 프로덕션에 허용해야 한다는 강력한 규제 요구 사항이 있습니다. 여러분은 서비스 감사가 이루어지는 동안 팀이 개발 환경에서 실험해볼 수 있었으면 합니다. 이를 설정하기 위한 최적의 방법은 무엇일까요 ?

• A. 개발 팀에 완전히 독자적인 AWS 계정을 제공
• B. 글로벌 IAM 정책을 프로덕션 계정에 적용
• C. AWS 조직을 생성해 두 개의 프로덕션 및 Dev OU를 생성한 후, Prod OU에 SCP를 적용
• D. AWS Config 규칙을 생성

4. 온프레미스 Microsoft Active Directory 설정이 있고, 온프레미스 AD 사용자들에게 여러분이 가진 다수의 AWS 계정에 대한 액세스 권한을 부여하고자 합니다. 솔루션은 향후 있을 계정 추가를 위해 스케일링이 가능해야 합니다. 어떤 방법을 추천할 수 있을까요 ?

• A. 각 AWS 계정과 온프레미스 Microsoft AD 사이에서의 SAML 2.0 통합을 설정
• B. Microsoft AD 각 사용자의 모든 AWS 계정에 대해 상응하는 IAM 사용자를 생성하는 Lambda 함수를 생성
• C. Amazon Cognito를 통해 웹 ID 연결을 설정
• D. AWS Single Sign-On 설정

5. 기업용 AWS 계정을 관리하고 있으며, 개발자 중 한 명에게 S3 버킷 내의 파일을 읽을 수 있는 액세스 권한을 부여하려 합니다. 여러분은 버킷 정책을 업데이트 했으나, 해당 개발자는 여전히 버킷 내의 파일에 액세스할 수 없는 상태입니다. 무엇이 문제일까요 ?

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:123456789012:user/Dave"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::static-files-bucket-xxx"
    }    
  ]
}

• A. 아무 문제가 없으며, 다시 로그인해야 함
• B. 아직 버킷에 파일이 없음
• C. 객체 레벨의 권한이므로, 리소스를 arn:aws:s3:::static-files-bucket-xxx/*로 변경해야 함

6. 온프레미스 Microsoft Active Directory로 요청을 프록시하려면 다음 중 어떤 AWS 디렉토리 서비스를 사용해야 할까요 ?

• A. EC2 상의 Microsoft AD
• B. AWS가 관리하는 Microsoft AD
• C. AD Connector
• D. Simple AD

7. AWS 계정에 있는 AWS 리소스를 다른 AWS 계정들과 공유하기 위해서는 다음 AWS 서비스 중 어떤 것을 사용해야 할까요 ?

• A. AWS Resource Access Manager
• B. AWS Single Sign-On (SSO)
• C. AWS Organizations
• D. AWS 공동 책임 모델

✅ AWS Resource Access Manager (AWS RAM)를 사용하면 AWS 리소스를 AWS Organizations에 있는 조직, 또는 조직 단위(OU) 내에 있는 AWS 계정들과 안전하게 공유할 수 있습니다. IAM 역할 및 IAM 사용자들과도 리소스를 공유할 수 있습니다.

8. AWS Organizations을 사용해 관리하고 있는 5개의 AWS 계정이 있습니다. 여러분은 각 계정이 특정 AWS 서비스로 액세스하는 것을 제한하려 합니다. 이런 경우 어떻게 해야 할까요 ?

• A. IAM 역할 사용
• B. AWS Organizations SCP 사용
• C. AWS Config 사용