그럼 ID 페더레이션에 관해 이야기해 봅시다
AWS에서 ID 페더레이션이라는 말을 많이 들으셨을 텐데
솔직히 제게는 아리송한 주제이었습니다
정말 이해하기 어려웠습니다
그래서 저는 최선을 다해 여러분께 ID 페더레이션이
어떻게 작동하는지 SAML과 코그니토와 어떻게 통합되는지를
설명드리려고 합니다
그럼 한 단계씩 나아가다 보면
강의가 끝나고 더 명확한 이해도가 생길 것입니다
페더레이션이란 AWS 밖에서
사용자가 임시 역할을 맡아 AWS 리소스에
액세스할 수 있게 하는 것입니다
무슨 뜻인지 아십니까?
사용자가 AWS에 접속하기 위해
AWS를 사용할 필요가 없다는 겁니다
이런 흑마술의 원리가 뭔지 아십니까?
사용자는 ID가 제공된 액세스
역할을 맡습니다
벌써 많은 정보가 나왔습니다
도표를 이용해서
작동 원리를 더 잘 이해해 봅시다
우리는 사용자고 회사에 있거나 모바일 앱 사용자입니다
무엇이 되었건 간에
우리는 사용자고 AWS에 계정이 없습니다
그러나 로그인을 위한
서드파티 서버에 접근할 권한이 있습니다
우리 회사 것일 수도 있고 뭐든 상관없습니다
AWS가 이 서드파티를 신뢰하기 때문에
우리는 미리 서드파티와 AWS 사이에
트러스트를 정의해 놓았습니다
사용자는 서드파티의 서버에
복잡한 프로세스를 통해 연결하게 됩니다
서드파티는 임시로
사용자인 우리에게
자격 증명을 제공합니다
사용자로서 이런 자격 증명으로 무엇을 할 수 있냐면
콘솔이나 API를 통해 AWS에
직접 액세스할 수 있습니다
ID 페더레이션은 이렇게 작동합니다
다른 곳에 저장되거나 서드파티에
저장된 ID를 사용합니다
이 과정을 이해하신다면
ID 페더레이션에 대해 이해하신 것입니다
ID 페더레이션에 대해서 이야기되고 있는
서드파티 인증은 무엇일지 이야기해 볼 것입니다
LDAP일 수도 있고 SAML과 유사한
Microsoft Active Directory일 수 있습니다
SAML은 표준이지만 Active Directory는 표준의 구현 버전입니다
또한 단일 로그인, Open ID
아니면 코그니토일 수도 있습니다
이 모든 것이 서드파티 인증이 될 수 있습니다
페더레이션을 사용할 때 기억해야 할 것은
개별 IAM 사용자를 생성할 필요가 없다는 것입니다
사용자 관리는 AWS 밖에서 이루어집니다
시험에서 ID 페더레이션에 대해 아주 구체적인 형식을
물어 볼 수 있습니다 다시 말해 SAML,
Custom broker와 코그니토가 있습니다
이제 이 세 가지를 상세히 살펴보도록 하겠습니다
첫 번째는 SAML 페더레이션입니다 기업용입니다
큰 기업이라면 Microsoft Active Directory나
사용자를 관리하는
SAML 2.0 준수 제품을
사용할 것입니다
간단하게 말하자면 이것을 AWS와 통합하려는 것입니다
그 결과 모든 사용자가 임시 자격
증명을 통해 AWS 콘솔 또는 CLI에
자동으로 접근하게 됩니다
따라서 직원마다 새로운 IAM 사용자를 만들 필요가 없습니다
이는 상당히 편리합니다
과정을 그려보자면
이런 도표로 나타내게 됩니다
이건 아주 복잡한 다이어그램일 수도 있습니다
AWS 설명서에서 그대로 가져온 것이지만
아주 명확합니다
한 번에 한 단계씩 어떤 방식인지 살펴봅시다
우린 클라이언트 앱이고
큰 기업 내에 속해 있습니다
ID 공급자 또는 SAML을 준수하는 IDP로 향합니다
Microsoft Active Directory가 될 수 있습니다
사용자 데이터베이스를 기반으로
사용자를 인증할 것입니다
그런 다음 이 IDP에 인증되면
IDP는 SAML 어설션을 보내게 됩니다
이는 간단하게 말하면 하나의 토큰입니다
토큰입니다
이제 SAML 어설션을 받게되고
자동으로 AssumeRoleWithSAML을
특별한 API인 STS로 call(호출) 합니다
STS는 이 SAML 어설션을 인식할 것입니다
반환되고 이 SAML 어설션을
임시 보안 자격 증명과 교환하는 것입니다
간단하게 말해서 로그인했고
SAML 어설션을 취득하고 STS로부터 보안 자격 증명으로 교환했습니다
이제 보안 자격 증명을 이용해 AWS에 정상적으로 액세스할 수 있습니다
예를 들어 여기 S3 버킷에서 말입니다
이는 CLI 기반 액세스를 원하는 경우입니다
콘솔 기반의 액세스를
원하시면 AWS에서 가져온 다이어그램이 있습니다
기본 개념은 정확히 일치합니다
브라우저에서 웹을 기반으로 IDP 포털에 액세스합니다
인증을 받으면 아까와 같이
IDP는 SAML 어설션을 반환할 것입니다
이제 그 SAML 어설션을 이용해
직접 AWS SSO 엔드 포인트에 로그인할 수 있습니다
뒤에서는 STS와 통신합니하고 모두 유효성이 확인되면 SAML이 STS와
교환되면 모든 것의 유효성을 검사하고 여기
AWS 관리 콘솔로 리디렉션되는 것입니다
기본 개념은 같다고 볼 수 있지 않습니까?
다시 보면 내부적으로 ID를 AWS 자격 증명과 교환합니다
간단하게 보면 주고받기의
연속입니다
이걸 이해한다면 SAML 페더레이션도 이해한 것입니다
사실 그렇게 복잡하지 않습니다
SAML 2.0가 없다면 사용자를 식별하는 방법은
Custom ID broker를 사용하는 것입니다.
SAML2가 없을 때만 해당합니다
이 경우는 좀 더 복잡한 부분이 있습니다
기본적으로 ID broker 애플리케이션이라는 것의
프로그램을 작성해야 합니다 직접 해야 하는 것입니다
그리고 이 ID broker는 적용할 IAM 정책을 결정하기 위해서
사용되어야 합니다.
다른 점은
도표를 다시 보면 사용자, 브라우저, 응용 프로그램이 있습니다
ID broker에 액세스할 것입니다
이 ID broker는 우리가 프로그램해야 하는 것입니다
이 녹색 점 원 안에 있는 것도 전부 우리가
프로그램해야 하는 것입니다
ID 브로커는 우리의 ID를 검증할 겁니다
Corporate ID Store와 같은 것과 검증할 것입니다.
인증되고 요구사항이 충족되면 STS로부터 어떤 정책이건
자격 증명을 요청할 수 있습니다
따라서 연결된 사용자만을 위해
정책을 만들어 내는 것은 ID broker에 달렸습니다
조금 더 해야 하는 일이 많은 것이고
앞의 이유로 Custom ID broker app이라고 불리는 것입니다
다시 보면 이걸 만들어서 STS로 가서
자격 증명을 요청하면
보안 자격 증명이 오게 되고
사용자에게 주어집니다
그런 후 API로 AWS에 액세스하거나
AWS 관리 콘솔로 리디렉션되어 AWS에 액세스할 수 있습니다
기본 원칙은 SAML과 정확히 같지만 SAML은 아닙니다
그래서 훨씬 더 많은 수작업을 해야 합니다
ID 브로커를 구현하기 위해서
더 많은 일을 해야 한다는 것입니다
Custom ID broker를 보게 되면 기업은 맞지만
SAML 2.0를 사용하지 않는 것입니다
전에 SAML 2.0를 보면 ID 페더레이션이 AWS와
직접 통합되었다는 것을 말해줍니다
끝으로 이것은 회사 사용자를 위한 겁니다
회사 책상에 앉아 있는 경우입니다
만약 앱인 경우에는
사용자가 S3 버킷에 파일을 넣어야 해요
방법은 다음과 같습니다
앱마다 사용자를 만드는 것은
일단 불가능한 것처럼 들립니다
그게 아니라 AWS 리소스 액세스를 사용자에게
직접 제공하는 게 목표입니다
방법은
페더레이티드 ID 공급자를 통해 로그인하거나 익명으로
로그인하면 페더레이션 ID Pool에서 AWS 자격
증명을 받을 수 있습니다
이것은 코그니토로부터 직접 옵니다
이러한 자격 증명은 미리 정의된 IAM 정책과 함께 옵니다
사용자가 해야 할 일을 할 수 있도록 해주는 것입니다
다행히도 설명을 도울 도표가 있습니다
예를 들어 S3 버킷을 일시적으로
작성하고 싶다면 예를 들어
Facebook 로그인을 사용한 경우인데
AWS C그니토와 페더레이션 ID Pool을 사용하면 됩니다
전에 들어보셨을지 모르겠지만
웹 ID 페더레이션이라는 문서 중에
코그니토를 대신할 만할 것이 있다고 합니다
이제는 AWS 문서에는 사용을 반대한다고 되어 있고
그냥 코그니토를 사용해야 한다고 합니다
왜냐하면 완전히 똑같은 기능을 하기 때문입니다
그래서 저는 웹 ID 페더레이션은 가르치지 않습니다
더는 시험에 나오지 않는 내용입니다
코그니토는 공용 앱이 AWS
리소스에 접근할 방법입니다
방법은
우리 앱은 IDP에
직접 연결되어 있습니다
코그니토 사용자 Pool일 수도 있고, 구글, 페이스북, 트위터,
SAML, 오픈 ID 등
무엇이든 상관없습니다만 이것은 앱이고 웹에 있습니다
공용이기 때문에 앱이 IDP에 로그인하고
토큰을 받을 수 있습니다
앱은 코그니토에서 페더레이션 IDP와 통신할 것입니다
ID 공급자가 인증하는 토큰을 거래할 것입니다
그리고 IDP는 STS로부터 자격 증명을 받을 것입니다
그리고 이전과 같은 패턴으로
코그니토의 페더레이션 ID가
임시 자격 증명을 보낼 것입니다
그리고 이 증명을 이용하여
우리가 필요로 하는 권한을
S3 버킷에 직접 요청할 수 있습니다
이렇게 하면 됩니다
여기서 차이점은 공용 IDP와 연결했다는 것입니다
코그니토 user pool, 구글, 페이스북과 같은 것에 말입니다
하지만 기본 개념은 정확히 같습니다
우리는 AWS 서비스에 임시 AWS 자격 증명을
얻기 위해 제3자로부터 얻은 토큰을
사용하여 교환합니다
따라서 여러분이 페더레이션을 이해하고 시간을
들여서 그래프를 검토하고 문서를
살펴보고 강의를 검토한다면 시간이 지나면
종이에 정리해 내려가다보면
이해가 될 것입니다
이런 게 어떻게 조직되는지 이해하기 힘들 때도 있습니다
이를 이해하기 위해서 시간을 많이 투자해야 하지만
일단 이해하고 나면
페더레이션에 관한 어떤 문제건 이해가 갈 것이고
더이상 두려워 하지 않고 바로 받아들이고
바로 답할 수 있어서 기쁘게 될 것입니다
이 강의가 마음에 드셨으면 합니다
다음 강의에서 뵙겠습니다