참조 아키텍처

이 문서에서는 회사 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 서비스를 구성합니다.

사용자 환경

이 구성에서 로그인 사용자 환경은 직원에게 다음과 같이 표시됩니다.

1. 보호되는 리소스를 요청하거나 회사 애플리케이션에 액세스하는 직원은 Google 로그인 화면으로 리디렉션되고 이메일 주소와 비밀번호를 입력하라는 메시지가 표시됩니다.
2. 2단계 인증을 사용 설정하면 USB 키 또는 코드와 같은 두 번째 단계를 제공하라는 메시지가 직원에게 표시됩니다.
3. 인증된 직원은 보호되는 리소스로 다시 리디렉션됩니다.

장점

Google을 IdP 및 신뢰할 수 있는 소스로 사용하면 다음과 같은 장점이 있습니다.

• Google의 다단계 인증 및 휴대기기 관리 기능을 최대한 활용할 수 있습니다.
• 추가 IdP가 필요하지 않으므로 비용을 절약할 수 있습니다.

이 아키텍처를 사용해야 하는 경우

다음 시나리오에서는 Google을 IdP 및 신뢰할 수 있는 소스로 사용하는 것이 좋습니다.

• 이미 Google Workspace를 공동작업 및 생산성 솔루션으로 사용하고 있습니다.
• 통합해야 하는 기존 온프레미스 인프라 또는 IdP가 없거나 Google ( 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를 이미 사용하고 있다면 페더레이션을 사용하여 Google Cloud 와 이 외부 IdP를 통합할 수 있습니다.

Cloud ID 또는 Google Workspace 계정을 외부 IdP와 페더레이션하면 직원이 기존 ID 및 사용자 인증 정보를 사용하여 Google 서비스(예: Google Cloud, Google Marketing Platform, Google Ads)에 로그인할 수 있습니다.

외부 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)을 참조하세요.

사용자 환경

직원에게 로그인 사용자 환경은 다음과 같이 표시됩니다.

1. 보호되는 리소스를 요청하는 직원은 Google 로그인 화면으로 리디렉션되며 이메일 주소를 입력하라는 메시지가 표시됩니다.
2. Google 로그인은 IDaaS의 로그인 페이지로 리디렉션합니다.
3. IDaaS에 인증합니다. IDaaS에 따라 코드와 같은 두 번째 단계를 제공해야 할 수도 있습니다.
4. 인증이 완료되면 보호되는 리소스로 다시 리디렉션됩니다.

장점

외부 IDaaS를 IdP 및 신뢰할 수 있는 소스로 사용하면 다음과 같은 장점이 있습니다.

• IDaaS와 통합된 Google 서비스 및 기타 애플리케이션에 직원 싱글 사인온(SSO) 환경을 확장할 수 있습니다.
• 다단계 인증을 요구하도록 IDaaS를 구성한 경우 이 구성이 자동으로 Google Cloud에 적용됩니다.
• 비밀번호 또는 기타 사용자 인증 정보를 Google과 동기화할 필요가 없습니다.
• Cloud ID 무료 버전을 사용할 수 있습니다.

이 아키텍처를 사용해야 하는 경우

다음 시나리오에서는 외부 IDaaS를 IdP 및 신뢰할 수 있는 소스로 사용하는 것이 좋습니다.

• 이미 ForgeRock, Okta 또는 Ping Identity와 같은 IDaaS 공급업체를 IdP로 사용하고 있습니다.

권장사항

Google Cloud 를 외부 ID 공급업체와 제휴하기 위한 권장사항을 참고하세요.

Active Directory를 IdP 및 신뢰할 수 있는 소스로 사용

Active Directory를 ID 관리를 위한 정보 소스로 사용하는 경우 다음 다이어그램과 같이 페더레이션을 설정할 수 있습니다.

• Google Cloud 디렉터리 동기화(GCDS)를 사용하여 Cloud ID 또는 Google Workspace용 Active Directory에서 사용자와 그룹을 자동으로 프로비저닝합니다. Google Cloud 디렉터리 동기화는 동기화 프로세스를 구현하며 Google Cloud 또는 온프레미스 환경에서 실행할 수 있는 도구로서 Google에서 무료로 제공합니다. Google Cloud 동기화는 단방향이므로 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와 함께 사용할 수 있습니다.

이 방법에 대한 자세한 내용은 Google Cloud 와 Active Directory의 페더레이션을 참고하세요.

사용자 환경

1. 보호되는 리소스를 요청하는 직원은 Google 로그인 화면으로 리디렉션되며 이메일 주소를 입력하라는 메시지가 표시됩니다.
2. Google 로그인은 AD FS의 로그인 페이지로 직원을 리디렉션합니다.
3. AD FS의 구성에 따라 Active Directory 사용자 이름과 비밀번호를 묻는 로그인 화면이 직원에게 표시될 수 있습니다. 또는 AD FS가 Windows 로그인을 기반으로 직원 자동 로그인을 시도할 수 있습니다.
4. 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 로 확장하고Google Cloud에서 실행할 GCDS를 배포합니다.
  • Google Cloud에서 전용 AD FS 서버를 실행합니다. 이 서버는Google Cloud에서 실행 중인 Active Directory 도메인 컨트롤러를 사용합니다.
  • Cloud ID를 구성하여 Google Cloud 에 배포된 AD FS 서버를 싱글 사인온(SSO)에 사용합니다.

자세한 내용은 Google Cloud 를 외부 ID 공급업체와 제휴하기 위한 권장사항을 참고하세요.

Azure AD를 신뢰할 수 있는 소스인 Active Directory와 함께 IdP로 사용

Microsoft Office 365 또는 Azure 고객이라면 온프레미스 Active Directory를 Azure AD에 연결했을 수 있습니다. Google Cloud 에 액세스해야 하는 모든 사용자 계정이 Azure AD와 이미 동기화된 경우 다음 다이어그램과 같이 Cloud ID를 Azure AD와 페더레이션하여 이 통합을 재사용할 수 있습니다.

• Azure AD를 사용하여 사용자와 그룹을 Cloud ID 또는 Google Workspace에 자동으로 프로비저닝합니다. Azure AD 자체는 온프레미스 Active Directory와 통합될 수 있습니다.
• Cloud ID 또는 Google Workspace는 싱글 사인온(SSO)용으로 Azure AD를 사용합니다.
• 기존 회사 애플리케이션과 기타 SaaS 서비스는 Azure AD를 IdP로 계속 사용할 수 있습니다.

이 접근 방식에 대한 자세한 내용은 Azure Active Directory와 Google Cloud 페더레이션을 참고하세요.

사용자 환경

1. 보호되는 리소스를 요청하는 직원은 Google 로그인 화면으로 리디렉션되며 이메일 주소를 입력하라는 메시지가 표시됩니다.
2. Google 로그인은 직원을 AD FS의 로그인 페이지로 리디렉션합니다.
3. 온프레미스 Active Directory가 Azure AD에 연결되는 방식에 따라 Azure AD는 사용자 이름과 비밀번호를 입력하라는 메시지를 표시하거나 온프레미스 AD FS로 리디렉션할 수 있습니다.
4. Azure AD에 인증된 직원은 보호되는 리소스로 다시 리디렉션됩니다.

장점

Azure AD를 신뢰할 수 있는 소스인 Active Directory와 함께 IdP로 사용하면 다음과 같은 장점이 있습니다.

• Google 서비스, Azure, 온프레미스 환경에 직원 싱글 사인온(SSO) 환경을 확장할 수 있습니다.
• 다단계 인증을 요구하도록 Azure AD를 구성한 경우 이 구성이 자동으로 Google Cloud에 적용됩니다.
• 추가 소프트웨어를 온프레미스에 설치할 필요가 없습니다.
• 온프레미스 Active Directory가 여러 개의 도메인 또는 포리스트를 사용하고, 이 구조를 Azure AD 테넌트에 매핑하기 위한 커스텀 Azure AD Connect 구성을 설정한 경우 이 통합 작업을 활용할 수 있습니다.
• 비밀번호 또는 기타 사용자 인증 정보를 Google에 동기화할 필요가 없습니다.
• Cloud ID 무료 버전을 사용할 수 있습니다.
• Office 365 포털에 Google Cloud 콘솔을 타일로 표시할 수 있습니다.
• Azure AD가 사용하는 API는 공개적으로 액세스할 수 있으므로 Azure와 Google Cloud간에 하이브리드 연결을 설정할 필요가 없습니다.

이 아키텍처를 사용해야 하는 경우

다음 시나리오에서는 Azure AD를 신뢰할 수 있는 소스인 Active Directory와 함께 IdP로 사용하는 것이 좋습니다.

• Azure AD를 이미 사용하고 있고 기존 Active Directory 인프라와 통합했습니다.
• Azure와 Google Cloud에서 사용자에게 원활한 로그인 환경을 제공하려고 합니다.

권장사항

다음의 권장사항을 따르세요.

• Azure AD와 Cloud ID는 서로 다른 논리 구조를 사용하므로 둘의 차이점을 이해해야 합니다. 상황에 가장 적합한 도메인, ID, 그룹 매핑 방법을 평가합니다. 자세한 내용은 Azure AD와 Google Cloud 페더레이션을 참고하세요.
• 사용자 외에 그룹을 동기화합니다. 이 방법을 사용하면 Azure AD의 그룹 멤버십으로Google Cloud의 리소스에 액세스할 수 있는 사용자를 제어하도록 IAM을 설정할 수 있습니다.
• 비즈니스 연속성을 위해 Google Cloud 를 사용하는 경우 인증에 Azure AD를 사용하면Google Cloud 를 배포의 독립적인 복사본으로 사용하는 본래의 의도가 희석될 수 있습니다.

자세한 내용은 Google Cloud 를 외부 ID 공급업체와 제휴하기 위한 권장사항을 참고하세요.

다음 단계

• Active Directory와 페더레이션에 대해 자세히 알아보기
• Azure AD와 페더레이션을 설정하는 방법 알아보기
• 계정 및 조직 계획을 위한 권장사항과 외부 ID 공급업체와의 페더레이션 Google Cloud 을 위한 권장사항을 검토하세요.