외부에서 인증된 사용자에게 액세스 권한 제공(ID 페더레이션)

사용자는 이미 회사 디렉터리 등 AWS 외부에 자격 증명을 보유할 수 있습니다. 그러한 사용자가 AWS 리소스를 사용해야 하는 경우(또는 해당 리소스에 액세스하는 애플리케이션을 사용해야 하는 경우), 해당 사용자에게도 AWS 보안 자격 증명이 필요합니다. 자격 증명이 내 조직 또는 서드 파티 자격 증명 공급자(IdP)에서 페더레이션되는 사용자의 권한을 IAM 역할을 사용하여 지정할 수 있습니다.

참고

보안 모범 사례로서, IAM 사용자를 생성하지 말고, 그 대신 아이덴티티 페더레이션을 사용하여 IAM Identity Center에서 사용자 액세스를 관리하는 것이 좋습니다. IAM 사용자가 필요한 특정 상황에 대한 자세한 내용은 IAM 사용자(역할이 아님)를 생성해야 하는 경우를 참조하세요.

Amazon Cognito를 사용하여 모바일 또는 웹 기반 앱 사용자 페더레이션

AWS 리소스에 액세스하는 모바일 또는 웹 기반 앱을 생성하는 경우, 이 앱에는 AWS에 프로그래밍 방식으로 요청하기 위해 보안 자격 증명이 필요합니다. 대부분의 모바일 애플리케이션 시나리오의 경우 Amazon Cognito 사용을 권장합니다. 이 서비스와 함께 AWS Mobile SDK for iOS 및 AWS Mobile SDK for Android and Fire OS를 사용하면 사용자의 고유 자격 증명을 생성하고 사용자를 인증하여 AWS 리소스에 안전하게 액세스하도록 할 수 있습니다. Amazon Cognito는 다음 섹션에 나열된 자격 증명 공급자를 지원할 뿐만 아니라 개발자 인증 자격 증명과 인증되지 않은(게스트) 액세스까지 지원합니다. 또한, Amazon Cognito는 사용자가 디바이스 간에 이동할 때 데이터가 보존되도록 사용자 데이터를 동기화하기 위한 API 작업도 제공합니다. 자세한 내용은 모바일 앱에 Amazon Cognito 사용 단원을 참조하십시오.

퍼블릭 자격 증명 서비스 공급자 또는 OpenID Connect를 사용하여 사용자 페더레이션

가능하면 항상 모바일 및 웹 기반 애플리케이션 시나리오에 Amazon Cognito를 사용합니다. Amazon Cognito는 퍼블릭 자격 증명 공급자 서비스를 통해 대부분의 백그라운드 작업을 수행합니다. 동일한 타사 서비스를 사용하며 익명 로그인을 지원하기도 합니다. 그러나 고급 시나리오의 경우에는 Login with Amazon, Facebook, Google, 또는 OpenID Connect(OIDC)와 호환되는 모든 IdP로 직접 작업할 수 있습니다. 이들 서비스 중 한 가지를 이용한 OIDC 페더레이션에 대한 자세한 내용은 OIDC 페더레이션 항목을 참조하세요.

SAML 2.0으로 사용자 연동하기

조직에서 SAML 2.0(Security Assertion Markup Language 2.0)을 지원하는 자격 증명 공급자 소프트웨어 패키지를 이미 사용하는 경우 IdP(자격 증명 공급자)인 조직과 서비스 공급자인 AWS 간에 신뢰를 형성할 수 있습니다. 그러면 SAML을 사용하여 사용자에게 AWS Management Console에 대한 연동 SSO(Single-Sing On) 또는 AWS API 작업을 호출하기 위한 페더레이션 액세스를 제공할 수 있습니다. 예를 들어 회사가 Microsoft Active Directory와 Active Directory Federation Services를 이용한다면, SAML 2.0을 사용해 연동할 수 있습니다. SAML 2.0를 이용한 사용자 연동에 대한 세부 정보는 SAML 2.0 연동을 참조하세요.

사용자 지정 자격 증명 브로커 애플리케이션 생성에 의한 사용자 연동

자격 증명 스토어가 SAML 2.0과 호환되지 않는다면, 사용자 지정 자격 증명 브로커 애플리케이션을 구축해 비슷한 기능을 수행할 수 있습니다. 브로커 애플리케이션이 사용자를 인증하고, AWS에게 사용자를 위한 임시 자격 증명을 요청한 다음, 이를 사용자에게 제공해 AWS 리소스에 액세스하도록 합니다.

예를 들어 Example Corp.에 회사의 AWS 리소스에 액세스하는 내부 애플리케이션을 실행해야 하는 직원들이 많다고 합시다. 직원들은 이미 회사 자격 증명 및 인증 시스템에 자격 증명이 있어서 Example Corp는 각 직원의 IAM 사용자를 별도로 생성하길 원하지 않습니다.

Bob은 Example Corp의 개발자입니다. Example Corp 내부 애플리케이션에서 회사의 AWS 리소스에 액세스하도록 하기 위해 Bob은 사용자 지정 자격 증명 브로커 애플리케이션을 개발합니다. 그 애플리케이션은 직원들이 기존 Example Corp. 자격 증명 및 인증 시스템에 로그인된 상태인지 확인하는데, 그 시스템은 LDAP, Active Directory, 또는 다른 시스템을 사용할 수 있습니다. 그 다음에 자격 증명 브로커 애플리케이션은 직원들에 대한 임시 보안 자격 증명을 획득합니다. 이 시나리오는 이전 시나리오(사용자 지정 인증 시스템을 사용하는 모바일 앱)과 유사합니다. 단지 AWS 리소스에 액세스해야 하는 애플리케이션이 모두 회사 네트워크 내에서 실행되고 회사에 기존 인증 시스템이 있다는 점만 다릅니다.

임시 보안 자격 증명을 얻기 위해 자격 증명 브로커 애플리케이션은 밥(Bob)이 사용자들에 대한 정책을 어떻게 관리하고자 하는지, 그리고 임시 자격 증명이 언제 만료되는지에 따라 AssumeRole 또는 GetFederationToken을 호출해 임시 보안 자격 증명을 획득합니다. (이러한 API 작업 간의 차이점을 보려면 IAM의 임시 보안 자격 증명 및 사용자 임시 보안 자격 증명에 대한 권한 제어를 참조하세요.) 호출은 AWS 액세스 키 ID, 보안 액세스 키, 세션 토큰으로 구성된 임시 보안 자격 증명을 반환합니다. 자격 증명 브로커 애플리케이션은 이 임시 보안 자격 증명을 내부 회사 애플리케이션에서도 사용할 수 있게 해줍니다. 그 앱은 그 임시 자격 증명을 사용해 AWS를 직접 호출할 수 있습니다. 그 앱은 자격 증명이 만료될 때까지 캐싱한 다음, 새로운 일련의 임시 자격 증명을 요청합니다. 다음은 이 시나리오를 설명한 그림입니다.

이 시나리오에는 다음과 같은 속성이 있습니다.

• 자격 증명 브로커 애플리케이션은 IAM의 보안 토큰 서비스(STS) API에 액세스하여 임시 보안 자격 증명을 생성할 수 있는 권한이 있습니다.

• 신원 증명 브로커 애플리케이션을 통해 기존 인증 시스템 내에서 직원이 인증되었는지 확인할 수 있습니다.

• 사용자는 AWS 관리 콘솔에 대한 액세스 권한을 제공하는 임시 URL(Single Sign-On이라고 함)을 가져올 수 있습니다.

임시 보안 자격 증명 생성에 대한 자세한 내용은 임시 보안 자격 증명 요청를 참조하세요 . AWS 관리 콘솔에 대한 액세스 권한을 얻는 페더레이션 사용자에 대한 자세한 내용은 SAML 2.0 페더레이션 사용자가 AWS Management Console에 액세스할 수 있게 하기 섹션을 참조하세요.