Post

[AWS-Security] 3.2. 기존 접근관리시스템과의 통합

Posted Updated
By haksuperman
views 11 min read
[AWS-Security] 3.2. 기존 접근관리시스템과의 통합

1. 개요

  • 이미 Active Directory와 같은 다른 ID 또는 접근관리시스템을 사용하고 있을 수 있다. 이러한 시스템을 IAM과 통합해 시스템 간의 중복 작업량을 줄일 수 있는 방법이 있다.
  • SAML 기반 ID 시스템(ex. Active Directory) 및 OpenID Connect 시스템(ex. 구글 로그인)과 통합하는 방법이 있다. 하지만 이러한 시스템이 IAM과 통합될 수 있는 유일한 시스템은 아니다.
  • 통합할 수 있는 시스템과 사용 가능한 모든 옵션 구성에 대해서는 AWS 공식 문서에서 확인할 수 있다.
    https://aws.amazon.com/identity/federation/

2. Active Directory 및 다른 SAML 시스템과의 통합

2.1. AD Connector

기존에 사용하던 사내 Active Directory ID를 그대로 사용하여 AWS Management Console에 접근할 수 있게 해주는 방법이다.
AWS용으로 별도의 계정(자격 증명)을 추가로 만들고 관리할 필요가 없다.

  1. 초기 설정
    1. 온프레미스에 있는 Active Directory의 세부 정보를 AWS Directory Service에 추가한다.
    2. 새로 연결된 디렉터리의 ‘앱 및 서비스’ 설정을 통해 AWS Managemant Console 접근을 활성화 한다.
  2. 역할(Role) 생성 및 매핑
    1. Directory Service의 ‘앱 및 서비스’ 메뉴에서 ‘AWS Management Console에 대한 접근 관리 링크’를 클릭한다.
    2. 버튼을 클릭해 ‘신규 역할’을 생성한다.
    3. AD 사용자 또는 그룹에 부여할 ‘ID 정책’을 입력한다.
    4. 역할을 매핑할 ‘AD 사용자 또는 그룹의 이름’을 입력한다.
    5. 클릭해서 ‘역할 할당’을 완료한다.

    Diretory Service 콘솔에서 진행하는 것이 권장된다. AD ID가 해당 역할을 맡을 수 있도록 올바른 리소스 정책을 자동으로 만들어 준다.

  3. 로그인
    1. https://<alias>.awsapps.com/console 형식으로 된 디렉터리 서비스 콘솔의 링크를 사용한다.
    2. 해당 링크에 Active Directory 자격 증명(ID/PW)을 입력하면, 본인에게 매핑된 역할(Role) 중 하나를 선택하여 로그인할 수 있는 옵션이 제공된다.

2.2. AD Connector의 한계점

AD Connector가 설정이 간편하지만, 항상 정답은 아니다.
아래와 같은 제약 사항을 고려해야 한다.

  1. 네트워크 연결 요구 사항 : 기존 AD 환경과 AWS 계정의 VPC 사이에 반드시 VPN이나 Direct Connect(전용선)가 설정 되어야만 한다.
  2. 포트 개방 : AD 환경과 VPC 간에 통신을 위한 여러 포트를 열어두어야 한다.
  3. 프로그래밍 방식 접근 불가 : AD Connector는 AWS Management Console 화면에서의 연합 로그인은 지원하지만, AWS CLI나 SDK를 통한 프로그래밍 방식의 접근에 대한 연합은 지원하지 않는다.

위와 같은 제약 사항들로 인해 AD Connector를 사용할 수 없는 경우, 일반적인 SAML 2.0 연합 방법을 사용해야 한다.

3.1. SAML 2.0 연합

이 방법으로 Active Directory를 통합하는 절차는 AD Connector를 사용하는 것보다 복잡하다.

  1. 사내의 AD 서버를 AWS용 SAML 공급자로 설정한다.
    (조직의 정보를 설명하는 XML 파일을 제공하는 작업 포함)
  2. 사용자가 AWS Management Console에 접근하려고 요청할 때, 이 요청이 AWS SAML 엔드포인트를 통과하도록 라디렉션 설정 한다.
  3. AWS IAM 콘솔에서 SAML ID 공급자를 생성하고, 1단계에서 만들었던 것과 동일한 XML 파일을 첨부하여 서로 신뢰할 수 있게 연결한다.
  4. Active Directory 사용자 또는 그룹에 매핑할 역할을 생성한다.
    (IAM 콘솔에서 역할을 생성하고, 올바른 리소스 정책을 직접 세팅해야 한다.)
  5. SAML 메타데이터 XML 파일을 Active Directory installation에 설치하여, AWS를 서비스 공급자로 식별하도록 한다.

3. OpenID Connect

3.1. 필요한 이유

모바일 애플리케이션 사용자가 앱을 통해 AWS S3 버킷에 파일을 업로드해야 하는 경우

  • 앱이 s3:PubOjbect 작업을 수행할 수 있는 AWS 자격 증명이 필요하다.
  • 잘못된 방법 : 앱 소스 코드 안에 수명이 긴 AWS 자격 증명을 하드코딩하여 배포한다. 이는 악의적인 사용자가 이를 탈취할 수 있으므로 매우 취약하다.
  • 해결책 (웹 ID 연합) : 애플리케이션에 자격 증명을 직접 심어두는 대신, 고객이 이미 사용 중인 Google ID로 로그인하게 하고, 웹 ID 연합 기능을 통해 AWS로부터 S3에 접근할 수 있는 임시 자격 증명을 발급받아 사용하는 것이 안전하다.

3.2. OpenID Connect 자격 증명 사용자에게 IAM 권한 부여

  1. IAM에서 OpenID Connect ID 공급자를 생성한다.
  2. 연합 사용자에게 부여하려는 권한으로 신규 관리형 정책을 생성한다.
  3. 연합 사용자가 수임할(맡을) 역할을 생성한다.
  4. 관리형 정책을 역할에 연결한다.

3.2.1. ID 공급자 리소스 생성

IAM에서 ID 공급자를 생성하려면 아래 세 가지 정보가 필요하다.

  1. 로그인 URL : Google ID 로그인 설정 시 확인 가능
  2. 애플리케이션 클라이언트의 ID : Google ID 로그인 설정 시 확인 가능
  3. root CA thumbprint : AWS IAM 콘솔을 통해 자동으로 찾거나, AWS 설명서를 참조하여 확인 (http://mng.bz/aJKX)
1
2
3
4
5
6

#!/bin/bash

aws iam create-open-id-connect-provider \
    --url https://mysigninurl.com \
    --client-id-list my-client-id \
    --thumbprint-list thumbprint

3.2.2. 권한 정책 및 역할 생성

모바일 앱 사용자가 특정 권한을 가질 수 있도록 정책과 역할을 생성한다.

  1. 필요한 권한을 담은 신규 정책 생성
    1
2
3
4

     #!/bin/bash
 aws iam create-policy \
     --policy-name MobileAppPolicy \
     --policy-document file://mobile_app_identity_policy.json
    • mobile_app_identity_policy.json (사용자에게 어떤 행동을 허락할지 정의한 JSON 문서)
      1
2
3
4
5
6
7
8
9
10

       {
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Action": "s3:PutObject",
     "Resource": "arn:aws:s3:::my-bucket/*"
   }
 ]
 }
  2. 사용자가 실제로 부여받을 역할 생성
    (3.2.1. 에서 생성한 ID 공급자를 신뢰할 수 있도록 설정된 리소스 정책 문서 연결)
    1
2
3
4

     #!/bin/bash
 aws iam create-role \
     --role-name MobileAppRole \
     --assume-role-policy-document file://mobile_app_resource_policy.json
    • mobile_app_resource_policy.json
      (이 역할을 누가 맡을 수 있는지 정의한 JSON 문서)
      1
2
3
4
5
6
7
8
9
10
11
12

        {
  "Version": "2012-10-17",
  "Statement": [
      {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Principal": {
          "Federated": "accounts.google.com"
      }
      }
  ]
  }

Google ID 로그인 시에는 accounts.google.com을 식별자로 사용한다. Facebook ID 로그인 시에는 graph.facebook.com을 식별자로 사용한다.

3.3. 실제 작동 방식

  1. 사용자가 모바일 앱에서 Google ID로 로그인하면, Google 인증 시스템이 ‘인증 토큰’을 제공한다.
  2. 앱은 이 구글 인증 토큰과 방금 생성한 역할의 ARN을 가지고 AWS에 권한을 요청한다.
  3. 구글 로그인 토큰(–web-identity-token), 역할 ARN(–role-arn), 접근 추적을 위한 세션 이름
    (–role-session-name)을 전달한다.
    1
2
3
4
5
6

     #!/bin/bash
	
 aws sts assume-role-with-web-identity \
     --role-arn arn:aws:iam::123456789012:role/MobileAppRole \
     --role-session-name MobileAppSession \
     --web-identity-token authToken
  4. 이 호출이 성공하면, AWS는 S3에 파일을 쓸 수 있는 임시 자격 증명을 앱에 반환한다.

모바일 애플리케이션은 위험하게 소스 코드에 자격 증명을 하드코딩하지 않아도 S3 버킷에 안전하게 접근할 수 있다. 동일한 절차를 응용하여 다른 모바일 앱에 다른 종류의 권한을 부여하거나, Google이 아닌 다른 OpenID Connect ID 공급자(ex. Facebook, Apple 로그인 등)도 동일한 원리로 사용할 수 있다.

CLOUD, AWS
cloud aws public cloud
This post is licensed under CC BY 4.0 by the author.