Identity Federation

 

#0 자격 증명 페더레이션(Identity Federation)이란?

ID 페더레이션은 AWS 외부에 있는 사용자에게 우리 계정 내 AWS 리소스에 대한 액세스 권한을 줄 때 사용한다. 해당 사용자는 이미 우리의 조직 디렉토리에 존재하니 특정 IAM 사용자를 따로 생성할 필요는 없다.

=> 사용자 관리가 AWS 외부에서 이루어지기 때문

이와 같은 이유로 자격 증명 페더레이션이 필요하다.

 

자격 증명 페더레이션의 활용사례

1. 회사에 Active Directory와 같은 자체 증명 시스템을 두는 경우

2. AWS 리소스에 액세스해야 하는 웹 및 모바일 애플리케이션이 있는 경우

이 이미지에서 볼 수 있는 것처럼 사용자는 AWS에 액세스하려고 할 때 자격 증명 제공자(Identity Provider)가 필요하다.

우선 AWS와 자격 증명 제공자 간 신뢰 관계가 설정되어 있어야 한다. 해당 자격 증명 제공자로부터 자격 증명을 제공받는 사실을 AWS에 알려야 한다. 이후 사용자가 해당 자격 증명 제공자를 통해 로그인을 하고 AWS에 대한 자격 증명을 반환 받으면 해당 임시 자격 증명을 가지고 AWS에 액세스한다.

 

+) 자격 증명 페더레이션의 유형 알아보기

- SAML 2.0

- Custom Identity Broker(사용자 지정 자격 증명 브로커) => Amazon Cognito를 사용하거나 더 이상 사용하지 않는 Aeb Identity Federation이 있다

- Single Sign-On(SSO) 

이 있는데 아래에서 좀 더 자세히 살펴보겠다.

 

#1 SAML 2.0 - 과거의 방식

보안 검증 마크업 언어를 나타내는 SAML 2.0은 ADFS와 같이 여러 자격 증명 제공자가 사용하는 개방형 표준이다. Microsoft Active Directory와 AWS의 자격 증명 제공자인 모든 SAML 2.0 호환 IdP를 지원한다. SAML 2.0을 통해 Console, CLI 그 외에도 임시 자격 증명을 이용하는 모든 API에 액세스할 수 있다..!

=> 따라서 우리의 ADFS 내 모든 직원에 대한 IAM 사용자를 생성할 필요가 없는 것이다.

물론 IAM과 우리가 이용하는 SAML 2.0 자격 증명 제공자 상호 간 신뢰를 생성할 필요는 있다. 이를 위해 STS 서비스가 제공하는 AssumeRoleWithSAML API를 이용할텐데 이 API가 SAML Assertion으로 임시 자격 증명을 제공한다.

앞서 말한 대로 SAML 2.0은 오래된 방식이기 때문에 Amazon SSO가 더욱 새로운 관리형이자 쓰기 쉬운 방법이다..! 기억해두면 좋다.

 

#2 웹 자격 증명 페더레이션(Web Identity Federation)의 두 가지 종류 - Cognito 🙆 / Cognito 🙅

Cognito가 있거나 없거나의 경우인데 Cognito가 없는 페더레이션은 AWS에서는 더 이상 권장하지 않으니 주의 바란다.

Cognito사용을 권장하지만 두 경우 모두 알아두면 좋다.

...

먼저 웹 자격 증명 페더레이션이란 뭘까?

=> 신뢰할 수 없는 환경일 때, 즉 회사 네트워크는 없으나 클라이언트는 알고 있는 경우 클라우드에서 클라이언트로부터 바로 서비스에 액세스하고자 할 때에 다음과 같은 타사 자격 증명 제공자를 통해 인증하는 과정이 필요하다.

(Amazon, Google, Facebook 그 외 모든 OpenID Connect 호환 IdP가 포함)

설정은 AWS를 통해 신뢰 메커니즘으로 이루어지는데 그 흐름은 다음과 같다.

Cognito를 사용하지 않을 때..!

클라이언트가 타사 IdP에 로그인하면 클라이언트와 웹 자격 증명 토큰에 대한 공유가 이루어진다. 클라이언트는 AssumeRoleWithWebIdentity API라는 특별 STS API를 이용한다. 해당 토큰을 교환하면서 AWS에 액세스할 수 있는 임시 보안 자격 증명을 발급받는 것이다. 해당 자격 증명을 이용하면 AWS 리소스에 바로 액세스할 수 있다. Cognito를 사용하지 않는 예전 방식을 살펴봤고 아래는 Cognito를 사용하는 절차인데 이 과정의 보안은 높이고 간단해지는 과정을 볼 수 있을 것이다.

Cognito를 사용할 때!

먼저 웹 자격 증명 페터레이션을 주로 사용한다. Cognito를 이용하면 최소 권한의 원칙에 의해 IAM 역할을 생성할 수 있고 OIDC IdP와 AWS간 신뢰 관계를 구축해야 한다. Cognito 서비스를 이용하면 클라이언트가 여전히 타사 자격 증명 제공자를 인증하고 토큰을 돌려받으나 토큰의 교환이 Cognito를 통해 이루어지므로 Cognito 토큰으로 반환될 것이다.

=>해당 Cognito 토큰은 STS를 통해 교환되고 AWS로부터 임시 보안 자격 증명을 발급받는다.

이를 통해 클라이언트는 AWS 리소스에 바로 액세스할 수 있다.

...

Cognito를 사용하는 이 메커니즘의 장점은 무엇일까?🧐

=> Cognito는 익명의 사용자도 지원한다는 이점이 있다.🌟🌟

MFA를 지원하고 데이터 동기화가 가능하다.

이와 같은 경우 사용하는 🌟 Cognito를 '토큰 자동 판매기'🌟로 칭하고 자격 증명을 위한 토큰의 교환을 맡기 때문이다.

 

+) 웹 자격 증명 페더레이션을 이용하면 IAM 정책을 제한할 수 있을까?

=> 가능하고 IAM 정책 변수를 사용할 수 있다.

이렇게 사용자 ID를 접두사로 하는 버킷만을 나열할 수 있는 정책이다.

GetUpdates와 PutObject 또한 특수한 접두사에 대해서만 가능하고 이처럼 웹 자격 증명 페더레이션을 사용하는 경우cognito-identity.amazonaws.com:sub나 amazon.com:user_id 등과 같은 특정 변수를 사용해서 조건과 함께 IAM 정책을 제한할 수 있고 사용자에게 필요한 제한 사항을 둘 수 있다.

 

이렇게 자격 증명 페더레이션을 정리해봤는데 Cognito를 제외하면 사실 모두 오래된 방법이다. 최신 방법인 SSO에 대해서는 나중에 정리해보려고 한다.