이 문서에서는 회사 ID를 관리하기 위한 참조로 사용할 수 있는 일반적인 아키텍처를 설명합니다. 회사 ID 관리의 두 가지 핵심 원칙은 다음과 같습니다.
직원 ID를 생성, 관리, 삭제하는 데 사용하는 유일한 시스템인 ID에 대한 신뢰할 수 있는 소스. 신뢰할 수 있는 소스 시스템에서 관리되는 ID는 다른 시스템에 전파될 수 있습니다.
유일한 인증 시스템으로, 여러 애플리케이션에 걸친 직원 싱글 사인온(SSO) 환경을 제공하는 중앙 ID 공급업체(IdP).
Google Cloud 또는 다른 Google 서비스를 사용할 때 ID 공급업체로 사용할 시스템과 신뢰할 수 있는 소스로 사용할 시스템을 결정해야 합니다.
Google을 IdP로 사용
Cloud ID Premium 또는 Google Workspace를 사용하여 Google을 기본 IdP로 지정할 수 있습니다. Google에서는 널리 사용되는 타사 애플리케이션에 바로 사용할 수 있는 다양한 통합을 제공하므로 SAML, OAuth, OpenID Connect 같은 표준 프로토콜을 사용하여 커스텀 애플리케이션을 통합할 수 있습니다.
Google을 IdP 및 신뢰할 수 있는 소스로 사용
다음 다이어그램과 같이 Cloud ID Premium 또는 Google Workspace를 IdP와 신뢰할 수 있는 소스로 사용할 수 있습니다.
- Cloud ID Premium 또는 Google Workspace를 사용하여 사용자와 그룹을 관리합니다.
- 모든 Google 서비스는 Cloud ID Premium 또는 Google Workspace를 IdP로 사용합니다.
- Google을 IdP로 사용하도록 회사 애플리케이션 및 기타 SaaS 서비스를 구성합니다.
사용자 환경
이 구성에서 로그인 사용자 환경은 직원에게 다음과 같이 표시됩니다.
- 보호되는 리소스를 요청하거나 회사 애플리케이션에 액세스하는 직원은 Google 로그인 화면으로 리디렉션되고 이메일 주소와 비밀번호를 입력하라는 메시지가 표시됩니다.
- 2단계 인증을 사용 설정하면 USB 키 또는 코드와 같은 두 번째 단계를 제공하라는 메시지가 직원에게 표시됩니다.
- 인증된 직원은 보호되는 리소스로 다시 리디렉션됩니다.
장점
Google을 IdP 및 신뢰할 수 있는 소스로 사용하면 다음과 같은 장점이 있습니다.
이 아키텍처를 사용해야 하는 경우
다음 시나리오에서는 Google을 IdP 및 신뢰할 수 있는 소스로 사용하는 것이 좋습니다.
- 이미 Google Workspace를 공동작업 및 생산성 솔루션으로 사용하고 있습니다.
- 통합해야 하는 기존 온프레미스 인프라 또는 IdP가 없거나 Google Cloud, Google Ads 등의 리소스와 완전히 분리하여 유지하려는 경우에는 통합을 수행할 필요가 없습니다.
- ID를 관리하기 위해 인사 관리 정보 시스템(HRIS)과 통합할 필요가 없습니다.
Google을 신뢰할 수 있는 소스인 HRIS와 함께 IdP로 사용
인사 관리 정보 시스템(HRIS)을 사용하여 직원 온보딩 및 오프보딩 프로세스를 관리하는 경우에도 Google을 IdP로 사용할 수 있습니다. Cloud ID 및 Google Workspace는 다음 다이어그램에 표시된 것처럼 HIRS 및 기타 시스템이 사용자 및 그룹 관리를 제어할 수 있게 해주는 API를 제공합니다.
- 기존 HRIS를 사용하여 사용자 및 그룹(선택적)을 관리합니다. HRIS는 ID 관리를 위한 단일 정보 출처로 유지되며, 사용자를 Cloud ID 또는 Google Workspace에 자동으로 프로비저닝합니다.
- 모든 Google 서비스는 Cloud ID Premium 또는 Google Workspace를 IdP로 사용합니다.
- Google을 IdP로 사용하도록 회사 애플리케이션 및 기타 SaaS 서비스를 구성합니다.
사용자 환경
직원의 로그인 사용자 환경은 Google을 IdP 및 신뢰할 수 있는 소스로 사용하는 것과 동일합니다.
장점
Google을 IdP 및 신뢰할 수 있는 소스로 사용하면 다음과 같은 장점이 있습니다.
- 기존 HRIS 워크플로를 재사용하여 관리 오버헤드를 최소화할 수 있습니다.
- Google의 다단계 인증 및 휴대기기 관리 기능을 최대한 활용할 수 있습니다.
- 추가 IdP가 필요하지 않으므로 비용을 절약할 수 있습니다.
이 아키텍처를 사용해야 하는 경우
다음 시나리오에서는 Google을 신뢰할 수 있는 소스인 HRIS와 함께 IdP로 사용하는 것이 좋습니다.
- ID에 대한 신뢰할 수 있는 소스 역할을 하는 기존 HRIS 또는 기타 시스템이 있습니다.
- 이미 Google Workspace를 공동작업 및 생산성 솔루션으로 사용하고 있습니다.
- 통합해야 하거나 Google 자산에서 계속 분리하려는 기존 온프레미스 인프라 또는 IdP가 없습니다.
외부 IdP 사용
조직에서 이미 Active Directory, Microsoft Entra ID(이전의 Azure AD), ForgeRock, Okta, Ping Identity와 같은 IdP를 사용 중이라면, 페더레이션을 통해 이러한 외부 IdP를 Google Cloud 와 통합할 수 있습니다.
Cloud ID 또는 Google Workspace 계정을 외부 IdP와 페더레이션하면, 직원들은 기존 ID와 사용자 인증 정보를 사용해 Google Cloud, Google Marketing Platform, Google Ads 등의 Google 서비스에 로그인할 수 있습니다.
외부 IDaaS를 IdP 및 신뢰할 수 있는 소스로 사용
ForgeRock, Okta 또는 Ping Identity와 같은 IDaaS(Identity as a Service) 공급업체를 사용하는 경우 다음 다이어그램에 표시된 대로 페더레이션을 설정할 수 있습니다.
- Cloud ID 또는 Google Workspace는 IDaaS를 싱글 사인온(SSO)의 IdP로 사용합니다.
- IDaaS는 Cloud ID 또는 Google Workspace의 사용자 및 그룹을 자동으로 프로비저닝합니다.
- 기존 회사 애플리케이션과 기타 SaaS 서비스는 IdP인 IDaaS에 계속 연결할 수 있습니다.
Cloud ID 또는 Google Workspace와 Okta를 페더레이션하는 방법에 대한 자세한 내용은 Okta 사용자 프로비저닝 및 싱글 사인온(SSO)을 참조하세요.
사용자 환경
직원에게 로그인 사용자 환경은 다음과 같이 표시됩니다.
- 보호되는 리소스를 요청하는 직원은 Google 로그인 화면으로 리디렉션되며 이메일 주소를 입력하라는 메시지가 표시됩니다.
- Google 로그인은 IDaaS의 로그인 페이지로 리디렉션합니다.
- IDaaS에 인증합니다. IDaaS에 따라 코드와 같은 두 번째 단계를 제공해야 할 수도 있습니다.
- 인증이 완료되면 보호되는 리소스로 다시 리디렉션됩니다.
장점
외부 IDaaS를 IdP 및 신뢰할 수 있는 소스로 사용하면 다음과 같은 장점이 있습니다.
- IDaaS와 통합된 Google 서비스 및 기타 애플리케이션에 직원 싱글 사인온(SSO) 환경을 확장할 수 있습니다.
- 다단계 인증을 요구하도록 IDaaS를 구성한 경우 이 구성이 자동으로 Google Cloud에 적용됩니다.
- 비밀번호 또는 기타 사용자 인증 정보를 Google과 동기화할 필요가 없습니다.
- Cloud ID 무료 버전을 사용할 수 있습니다.
이 아키텍처를 사용해야 하는 경우
다음 시나리오에서는 외부 IDaaS를 IdP 및 신뢰할 수 있는 소스로 사용하는 것이 좋습니다.
- 이미 ForgeRock, Okta 또는 Ping Identity와 같은 IDaaS 공급업체를 IdP로 사용하고 있습니다.
권장사항
외부 ID 공급업체와 Google Cloud 페더레이션 권장사항을 참조하세요.
Active Directory를 IdP 및 신뢰할 수 있는 소스로 사용
Active Directory를 ID 관리를 위한 정보 소스로 사용하는 경우 다음 다이어그램과 같이 페더레이션을 설정할 수 있습니다.
- Google Cloud 디렉터리 동기화(GCDS)를 사용하여 Cloud ID 또는 Google Workspace용 Active Directory에서 사용자와 그룹을 자동으로 프로비저닝합니다. Google Cloud 디렉터리 동기화는 동기화 프로세스를 구현하며 Google Cloud 또는 온프레미스 환경에서 실행할 수 있는 도구로서 Google에서 무료로 제공합니다. 동기화는 단방향이므로 Active Directory는 계속 정보 소스로 유지됩니다.
- Cloud ID 또는 Google Workspace는 싱글 사인온(SSO)용 AD FS(Active Directory Federation Service)를 사용합니다.
- 기존 회사 애플리케이션과 기타 SaaS 서비스는 계속해서 AD FS를 IdP로 사용할 수 있습니다.
이 패턴의 변형으로 Active Directory Lightweight Directory Services(AD LDS) 또는 다른 LDAP 디렉터리를 AD FS 또는 다른 SAML 준수 IdP와 함께 사용할 수 있습니다.
이 접근 방식에 대한 자세한 내용은 Active Directory와 Google Cloud 페더레이션을 참조하세요.
사용자 환경
- 보호되는 리소스를 요청하는 직원은 Google 로그인 화면으로 리디렉션되며 이메일 주소를 입력하라는 메시지가 표시됩니다.
- Google 로그인은 AD FS의 로그인 페이지로 직원을 리디렉션합니다.
- AD FS의 구성에 따라 Active Directory 사용자 이름과 비밀번호를 묻는 로그인 화면이 직원에게 표시될 수 있습니다. 또는 AD FS가 Windows 로그인을 기반으로 직원 자동 로그인을 시도할 수 있습니다.
- AD FS가 직원을 인증하면 직원은 보호되는 리소스로 다시 리디렉션됩니다.
장점
Active Directory를 IdP 및 신뢰할 수 있는 소스로 사용하면 다음과 같은 장점이 있습니다.
- Google 서비스와 온프레미스 환경에 직원 싱글 사인온(SSO) 환경을 확장할 수 있습니다.
- 다단계 인증을 요구하도록 AD FS를 구성한 경우 이 구성이 자동으로 Google Cloud에 적용됩니다.
- 비밀번호 또는 기타 사용자 인증 정보를 Google에 동기화할 필요가 없습니다.
- Cloud ID 무료 버전을 사용할 수 있습니다.
- GCDS가 사용하는 API는 공개적으로 액세스할 수 있으므로 온프레미스 네트워크와 Google Cloud간에 하이브리드 연결을 설정할 필요가 없습니다.
이 아키텍처를 사용해야 하는 경우
다음 시나리오에서는 Active Directory를 IdP 및 신뢰할 수 있는 소스로 사용하는 것이 좋습니다.
- 기존 Active Directory 인프라가 있습니다.
- Windows 사용자에게 원활한 로그인 환경을 제공하려고 합니다.
권장사항
다음 권장사항을 고려하세요.
- Active Directory와 Cloud ID는 서로 다른 논리 구조를 사용합니다. 차이점을 이해하고 상황에 가장 적합한 도메인, ID, 그룹 매핑 방법을 평가하세요. 자세한 내용은 Active Directory와 Google Cloud 페더레이션 가이드를 참조하세요.
- 사용자뿐 아니라 그룹도 함께 동기화합니다. 이 방법을 사용하면 Active Directory에서 그룹 멤버십을 사용하도록 IAM을 설정하여Google Cloud의 리소스에 액세스할 수 있는 사용자를 제어할 수 있습니다.
- 회사 사용자가 액세스할 수 있도록 AD FS를 배포 및 노출하되 필요 이상으로 노출하지 않습니다. 기업 사용자는 AD FS에 액세스할 수 있어야 하지만 Cloud ID, Google Workspace 또는 Google Cloud에 배포된 애플리케이션에서 AD FS에 연결할 수 있어야 한다는 요구사항은 없습니다.
- AD FS에서 Windows 통합 인증(IWA)을 사용 설정하여 Windows 로그인을 기반으로 사용자가 자동으로 로그인되도록 하는 방법을 고려해 보세요.
- AD FS를 사용할 수 없게 되면 사용자는Google Cloud 콘솔 또는 Google을 IdP로 사용하는 다른 리소스를 사용하지 못할 수 있습니다. 따라서 AD FS와 AD FS가 사용하는 도메인 컨트롤러의 배포 및 규모가 가용성 목표를 충족하는지 확인해야 합니다.
비즈니스 연속성을 보장하기 위해 Google Cloud 를 사용하는 경우 온프레미스 AD FS에 의존하면Google Cloud 를 독립적인 배포 복제본으로 사용하려는 목적이 훼손될 수 있습니다. 이 경우, 다음 중 하나의 방법으로 Google Cloud에 관련 시스템의 복제본을 배포하는 것이 좋습니다.
- 기존 Active Directory 도메인을 Google Cloud 로 확장하고, GCDS를Google Cloud에서 실행되도록 배포합니다.
- Google Cloud에서 전용 AD FS 서버를 실행합니다. 이 서버들이Google Cloud에서 실행 중인 Active Directory 도메인 컨트롤러를 사용하도록 합니다.
- Google Cloud 에 배포된 AD FS 서버를 사용하여 Cloud ID를 싱글 사인온(SSO)으로 구성합니다.
자세한 내용은 외부 ID 공급업체와 Google Cloud 페더레이션 구성을 위한 권장사항을 참조하세요.
Entra ID를 IdP로 사용하고 Active Directory를 권한 소스로 사용하는 경우
조직이 Microsoft 365 또는 Azure 서비스를 사용 중이라면, 온프레미스 Active Directory를 Entra ID와 연결해 두었을 가능성이 있습니다. Google Cloud 에 액세스해야 할 모든 사용자 계정이 이미 Entra ID와 동기화되어 있다면, 다음 다이어그램에 표시된 것처럼, Cloud ID를 Entra ID와 페더레이션하여 기존 통합을 재사용할 수 있습니다.
- Entra ID를 사용해 사용자 및 그룹을 Cloud ID 또는 Google Workspace로 자동 프로비저닝합니다. Entra ID는 자체적으로 온프레미스 Active Directory와 통합되어 있을 수 있습니다.
- Cloud ID 또는 Google Workspace는 싱글 사인온(SSO)을 위해 Entra ID를 사용합니다.
- 기존 기업용 애플리케이션과 기타 SaaS 서비스는 IdP로서 Entra ID를 계속 사용할 수 있습니다.
이 접근 방식에 대한 자세한 내용은 Microsoft Entra ID와 Google Cloud 페더레이션을 참조하세요.
사용자 환경
- 보호되는 리소스를 요청하는 직원은 Google 로그인 화면으로 리디렉션되며 이메일 주소를 입력하라는 메시지가 표시됩니다.
- Google 로그인은 직원을 AD FS의 로그인 페이지로 리디렉션합니다.
- 온프레미스 Active Directory가 Entra ID와 연결된 방식에 따라 Entra ID는 사용자에게 사용자 이름과 비밀번호 입력을 요청할 수도 있고, 온프레미스 AD FS로 리디렉션할 수도 있습니다.
- 직원이 Entra ID를 통해 인증되면, 보호된 리소스로 다시 리디렉션됩니다.
장점
Active Directory를 권한 소스로 사용하면서 Entra ID를 IdP로 사용하는 경우 여러 가지 장점이 있습니다.
- 직원들이 Google 서비스, Entra, 그리고 온프레미스 환경 전반에서 싱글 사인온(SSO) 환경을 이용할 수 있습니다.
- Entra ID에서 다중 인증(MFA)을 필수로 설정한 경우, 해당 설정이 Google Cloud에 자동으로 적용됩니다.
- 추가 소프트웨어를 온프레미스에 설치할 필요가 없습니다.
- 온프레미스 Active Directory에서 여러 도메인이나 포리스트를 사용 중이고, 이 구조를 Entra ID 테넌트에 매핑하도록 커스텀 Entra ID Connect 구성을 설정한 경우, 이미 구성해둔 통합 작업을 그대로 활용할 수 있습니다.
- 비밀번호 또는 기타 사용자 인증 정보를 Google에 동기화할 필요가 없습니다.
- Cloud ID 무료 버전을 사용할 수 있습니다.
- Office 365 포털에 Google Cloud 콘솔을 타일로 표시할 수 있습니다.
- Entra ID에서 사용하는 API가 공개적으로 액세스 가능하므로, Entra와 Google Cloud간에 하이브리드 연결을 설정할 필요가 없습니다.
이 아키텍처를 사용해야 하는 경우
다음과 같은 시나리오에서는 Active Directory를 권한 소스로 사용하고 Entra ID를 IdP로 사용하는 구성을 고려하세요.
- 이미 Entra ID를 사용 중이며, 기존 Active Directory 인프라와 통합했습니다.
- 사용자가 Entra와 Google Cloud서비스 전반에서 끊김 없는 로그인 환경을 이용할 수 있도록 제공하려고 합니다.
권장사항
다음 권장사항을 따르세요.
- Entra ID와 Cloud ID는 서로 다른 논리 구조를 사용하므로, 그 차이점을 이해해야 합니다. 도메인, ID, 그룹을 매핑하는 방법 중 어떤 것이 조직 환경에 가장 적합한지 평가하세요. 자세한 내용은 Microsoft Entra ID와 Google Cloud 페더레이션을 참조하세요.
- 사용자뿐 아니라 그룹도 함께 동기화합니다. 이 방식으로 IAM을 설정하면, Entra ID의 그룹 멤버십을 기반으로Google Cloud리소스에 대한 액세스 권한을 제어할 수 있습니다.
- 비즈니스 연속성을 보장하기 위해 Google Cloud 를 사용하는 경우, Entra ID 인증에 의존하면, 독립적인 배포 복제본으로Google Cloud 를 사용하려는 목적이 훼손될 수 있습니다.
자세한 내용은 외부 ID 공급업체와 Google Cloud 페더레이션 구성을 위한 권장사항을 참조하세요.
다음 단계
- Active Directory와 페더레이션에 대해 자세히 알아보기
- Entra ID와 페더레이션 구성 방법 알아보기
- 계정 및 조직 계획을 위한 권장사항 및 외부 ID 공급업체와 Google Cloud 페더레이션 구성을 위한 권장사항 검토