이 문서는 Google 계정 대신 IAP(Identity-Aware Proxy)와 함께 외부 ID를 사용하는 방법에 대한 추가 정보를 제공합니다.
개요
IAP는 Google Cloud에서 실행되는 App Engine 앱 및 Compute Engine VM에 대한 액세스를 제어합니다. 사용자 ID와 요청의 컨텍스트를 활용하여 사용자에게 액세스를 허용해야 하는지 판단합니다. IAP는 직원이 VPN을 사용하지 않고도 신뢰할 수 없는 네트워크에서 업무를 처리할 수 있게 하는 엔터프라이즈 보안 모델인 BeyondCorp의 기본 구성 요소입니다.
기본적으로 IAP는 Google ID 및 IAM을 사용합니다. 대신 Identity Platform을 활용하면 다음과 같은 광범위한 외부 ID 공급업체로 사용자를 인증할 수 있습니다.
- 이메일/비밀번호
- OAuth(Google, Facebook, Twitter, GitHub, Microsoft 등)
- SAML
- OIDC
- 전화번호
- 맞춤
- 익명
이는 애플리케이션이 이미 외부 인증 시스템을 사용 중이며 사용자를 Google 계정으로 마이그레이션하는 것이 비효율적인 경우에 유용합니다.
멀티테넌시
Identity Platform 멀티 테넌시는 원래 한 회사가 다른 회사에 서비스를 판매하는 B2B 시나리오를 위해 설계되었습니다. 이러한 경우 개발자가 사용자 모집단을 격리된 풀로 분리하려고 하는 것이 일반적입니다. 이러한 사일로를 테넌트라고 합니다.
아래의 가상의 관계 다이어그램을 고려합니다.
이 예시에서 Acme는 Identity Platform을 사용하여 대리점(테넌트)에 서비스를 제공하는 자동차 제조업체(에이전트)입니다. 이러한 판매 대리점은 고객, 직원, 계약자에게 서비스를 제공합니다. 제조업체가 서비스를 소유하고 있지만 각 대리점은 인증을 위해 고유한 ID 공급업체 세트를 사용할 수 있습니다. 사용자 세션 및 데이터는 테넌트 단위로 범위가 지정되므로 사용자가 여러 대리점과 관계가 있는 경우 각각 독립적으로 처리됩니다.
사용 사례에 따라 테넌트 계층 구조를 구성할 수 있는 여러 가지 방법이 있습니다.
테넌트 없음
리소스를 분리해야 하는 경우 멀티 테넌시만 필요합니다. 모든 애플리케이션에 이 요구사항이 있는 것은 아닙니다. 예를 들어 단일 App Engine 앱이 있고 네트워크 외부의 모든 사용자에 대한 액세스를 차단하려는 경우 멀티 테넌시가 필요하지 않습니다. 기본적으로 Identity Platform은 프로젝트별로 사용자를 저장하고 인증하므로 이 경우 추가 구성이 필요하지 않습니다.
또 다른 예시는 여러 자회사가 있는 대기업입니다. 각 자회사에 자체 관리 인증 시스템(OIDC 또는 SAML 사용)이 있어도 모든 직원은 의료, 휴가, 급여와 같은 동일한 높은 수준의 혜택을 공유할 수 있습니다. 이 경우 프로젝트 수준에서 인증하면 충분합니다.
리소스당 하나의 테넌트
기본적으로 비테넌트 Identity Platform 토큰은 프로젝트 수준에서 유효합니다. 이론적으로는 사용자가 하나의 IAP 리소스로 인증한 다음 토큰을 사용하여 동일한 프로젝트의 다른 서비스에 액세스할 수 있습니다. 이는 보안 위험입니다.
토큰 누출을 방지하려면 각각의 테넌트를 할당하여 각 IAP를 격리합니다. 테넌트별 컨텍스트에서 발행된 토큰은 해당 특정 테넌트에만 유효합니다. 사용자가 다른 테넌트를 사용하는 다른 IAP 리소스에 액세스하려고 하면 다시 인증하라는 메시지가 표시됩니다.
리소스당 여러 테넌트
단일 IAP 리소스에는 여러 테넌트가 연결될 수 있습니다.
사용자가 리소스에 액세스하면 사용할 테넌트를 결정할 수 있는 몇 가지 옵션이 있습니다. 예를 들어 사용자에게 먼저 이메일 주소를 입력하도록 한 다음 이메일 도메인과 일치하는 테넌트를 프로그래매틱 방식으로 찾을 수 있습니다. 또는 모든 유효한 테넌트를 나열하는 UI를 표시하고 사용자에게 하나를 선택하도록 요청할 수 있습니다.
사용자는 다양한 수준의 액세스 권한을 가진 멀티 테넌트에 속할 수 있습니다. IAM을 사용하여 외부 ID로 액세스 제어를 관리할 수는 없지만 IAP에서 생성한 JSON 웹 토큰은 Identity Platform ID 토큰에서 클레임을 전달하며 애플리케이션은 이러한 클레임을 기반으로 액세스를 필터링할 수 있습니다.
멀티 테넌시 시나리오의 예시는 많은 고객이 단일 웹 포털을 공유하는 직원 혜택 회사입니다. 사용자가 포털을 방문하면 먼저 회사(테넌트)를 선택한 다음 고용주가 회사 사용자 인증 정보로 사용하는 모든 제공업체를 인증합니다.