이 문서는 ID 관리 솔루션을 Google Cloud로 확장하여 직원 사용자가 하이브리드 컴퓨팅 환경에서 인증하고 서비스를 소비할 수 있도록 하는 방법을 설명하는 문서 시리즈 중 두 번째 문서입니다.
이 시리즈는 다음 문서로 구성됩니다.
- 하이브리드 환경에서 직원 사용자 인증
- 하이브리드 환경에서 직원 사용자를 인증하는 패턴(이 문서)
소개
하이브리드 전략의 일환으로 IT 환경을 Google Cloud로 확장하는 경우 환경 전체의 ID를 관리하는 데 일관적인 접근 방법을 취하는 것이 좋습니다. 이러한 제약 조건 및 요구사항을 충족하도록 아키텍처를 설계하고 맞춤화하는 과정에서 몇 가지 일반적인 패턴에 의존할 수 있습니다. 이러한 패턴은 다음의 2가지 범주로 나뉩니다.
- 외부 ID 공급업체(IdP)와 GCP를 페더레이션하기 위한 패턴. 이러한 패턴의 목적은 Google이 직원 사용자의 IdP가 되어 Google ID가 자동으로 유지관리되고 IdP가 정확한 단일 정보 소스로 유지되도록 하는 데 있습니다.
- IdP를 Google Cloud로 확장하기 위한 패턴. 이러한 패턴에서는 Google Cloud에 배포된 애플리케이션이 IdP에 연결하거나 Google Cloud에 IdP의 복제본을 유지관리하는 방법으로 IdP를 재사용하도록 허용합니다.
외부 IdP를 Google Cloud와 페더레이션하기 위한 패턴
Google Cloud 콘솔, Google Cloud CLI 또는 Google을 IdP로 사용하는 기타 리소스에 액세스하려면 직원 사용자에게 Google ID가 있어야 합니다. 모든 직원이 이미 IdP에 계정이 있는 경우 각 직원의 Google ID를 유지관리하기가 번잡해질 수 있습니다. IdP와 Google Cloud 간에 사용자 ID를 페더레이션함으로써 Google 계정 유지보수를 자동화하고 사용자 ID의 수명 주기를 존재하는 계정에 연계할 수 있습니다. 페더레이션을 사용하면 다음과 같이 할 수 있습니다.
- IdP는 계속 ID 관리를 위한 정확한 단일 정보 출처로 유지됩니다.
- IdP가 관리하는 모든 사용자 계정 또는 이러한 계정의 선택한 하위 집합에 대해 Google 계정이 자동으로 생성됩니다.
- IdP에서 계정이 사용 중지되거나 삭제되면 해당 Google 계정도 정지되거나 삭제됩니다.
- 비밀번호 또는 기타 사용자 인증 정보의 복사를 차단하기 위해 사용자를 인증하는 행위는 IdP에 위임됩니다.
GCDS 및 AD FS를 사용하여 Active Directory와 Cloud ID 페더레이션
Active Directory를 IdP로 사용하는 경우 Google Cloud 디렉터리 동기화(GCDS)와 Active Directory Federation Services(AD FS)를 사용하여 Active Directory와 Cloud ID를 페더레이션할 수 있습니다.
- Google Cloud 디렉터리 동기화는 동기화 프로세스를 구현하는 도구로서 Google에서 무료로 제공합니다. Google Cloud 디렉터리 동기화는 보안 소켓 레이어(SSL)를 통해 Google Identity Platform과 통신하며 일반적으로 기존 컴퓨팅 환경에서 실행됩니다.
- AD FS는 Microsoft에서 Windows Server의 일부로 제공합니다. AD FS를 사용하면 페더레이션된 인증에 Active Directory를 사용할 수 있습니다. AD FS는 일반적으로 기존 컴퓨팅 환경에서 실행됩니다.
이 접근 방법에 대한 자세한 내용은 GCP와 Active Directory 페더레이션을 참조하세요.
이 패턴의 변형에 대해 Active Directory Lightweight Directory Services(AD LDS) 또는 다른 LDAP 디렉터리를 AD FS 또는 다른 SAML 준수 IdP와 함께 사용할 수 있습니다.
사용자 환경
- 보호되는 리소스를 요청하면 Google 사인온 화면으로 리디렉션되며 이 화면에는 이메일 주소를 입력하라는 메시지가 표시됩니다.
- 이메일 주소가 Active Directory에서 동기화된 계정과 연결된 것으로 확인된 경우 AD FS로 리디렉션됩니다.
- AD FS의 구성에 따라 Active Directory 사용자 이름과 비밀번호를 요구하는 사인온 화면이 표시될 수 있습니다. 또는 AD FS에서 Windows 로그인(IWA)을 기반으로 사용자가 자동으로 로그인되도록 시도할 수 있습니다.
- AD FS에서 인증된 사용자는 보호되는 리소스로 다시 리디렉션됩니다.
장점
- Google Cloud의 온프레미스 애플리케이션 및 리소스에 걸쳐 싱글 사인온(SSO) 환경이 사용 설정됩니다.
- 다단계 인증을 요구하도록 AD FS를 구성한 경우 이 구성이 자동으로 Google Cloud에 적용됩니다.
- 비밀번호 또는 기타 사용자 인증 정보를 Google에 동기화할 필요가 없습니다.
- Cloud ID API는 공개적으로 액세스 가능하므로 온프레미스 네트워크와 Google Cloud 간에 하이브리드 연결을 설정할 필요가 없습니다.
권장사항
- Active Directory와 Cloud ID는 서로 다른 논리 구조를 사용합니다. 여러 매핑 방법의 차이점을 이해하고 현재 상황에 가장 적합한 도메인, ID, 그룹 매핑 방법을 평가합니다. 자세한 내용은 Google Cloud와 Active Directory 페더레이션 가이드를 참조하세요.
- 사용자 외에 그룹을 동기화합니다. 이 방법을 사용하면 Active Directory의 그룹 멤버십으로 Google Cloud의 리소스에 액세스할 수 있는 사용자를 제어하도록 IAM을 설정할 수 있습니다.
- 직원 사용자가 액세스할 수 있도록 AD FS를 배포 및 노출하되 필요 이상으로 노출하지 않습니다. 직원 사용자는 AD FS에 액세스할 수 있어야 하지만 Google 또는 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 도메인 컨트롤러를 사용합니다.
- Cloud Identity를 구성하여 Google Cloud에 배포된 AD FS 서버를 싱글 사인온(SSO)에 사용합니다.
Azure AD와 Cloud ID 페더레이션
Microsoft Office 365 또는 Azure 고객인 경우 온프레미스 Active Directory를 Azure AD에 연결했을 수 있습니다. Google Cloud 액세스가 필요할 가능성이 있는 모든 사용자 계정이 이미 Azure AD로 동기화되고 있다면 다음 다이어그램과 같이 Cloud ID를 Azure AD와 페더레이션하여 이 통합을 재사용할 수 있습니다.
이 접근 방법에 대한 자세한 내용은 GCP와 Azure Active Directory 페더레이션을 참조하세요.
사용자 환경
- 보호되는 리소스를 요청하면 Google 사인온 화면으로 리디렉션되며 이 화면에는 이메일 주소를 입력하라는 메시지가 표시됩니다.
- 이메일 주소가 Azure AD에서 동기화된 계정과 연결된 경우 Azure AD로 리디렉션됩니다.
- 온프레미스 Active Directory가 Azure AD에 연결된 방식에 따라 Azure AD에서 사용자 이름과 비밀번호 입력을 요구할 수 있습니다. 또는 온프레미스 AD FS로 리디렉션될 수도 있습니다.
- Azure AD에서 성공적으로 인증되면 보호되는 리소스로 다시 리디렉션됩니다.
장점
- 추가 소프트웨어를 온프레미스에 설치할 필요가 없습니다.
- Office 365, Azure, Google Cloud의 리소스에 걸쳐 싱글 사인온(SSO) 환경이 사용 설정됩니다.
- 다단계(MFA) 인증이 필요하도록 Azure AD를 구성한 경우 MFA가 자동으로 Google Cloud에 적용됩니다.
- 온프레미스 Active Directory가 여러 개의 도메인 또는 포리스트를 사용하고, 이 구조를 Azure AD 테넌트에 매핑하기 위한 커스텀 Azure AD Connect 구성을 설정한 경우 이 통합 작업을 활용할 수 있습니다.
- 비밀번호 또는 기타 사용자 인증 정보를 Google에 동기화할 필요가 없습니다.
- Cloud ID API는 공개적으로 액세스 가능하므로 온프레미스 네트워크와 Google Cloud 간에 또는 Azure와 Google Cloud 간에 하이브리드 연결을 설정할 필요가 없습니다.
- Office 365 포털에 Google Cloud 콘솔을 타일로 표시할 수 있습니다.
권장사항
- Azure AD와 Cloud ID는 서로 다른 논리 구조를 사용하므로 둘의 차이점을 이해해야 합니다. 현재 상황에 가장 적합한 도메인, ID, 그룹 매핑 방법을 평가합니다. 자세한 내용은 Google Cloud와 Azure AD 페더레이션을 참조하세요.
- 사용자 외에 그룹을 동기화합니다. 이 방법을 사용하면 Azure AD의 그룹 멤버십으로 Google Cloud의 리소스에 액세스할 수 있는 사용자를 제어하도록 IAM을 설정할 수 있습니다.
- 비즈니스 연속성을 보장하기 위해 Google Cloud를 사용하는 경우 인증에 Azure AD를 사용하면 Google Cloud를 배포의 독립적인 복사본으로 사용하는 본래의 의도가 희석될 수 있습니다.
외부 IdP를 Google Cloud로 확장하기 위한 패턴
Google Cloud에 배포하고자 하는 애플리케이션 중 일부에 Cloud ID에서 제공하지 않는 인증 프로토콜이 필요할 수 있습니다. 이러한 워크로드를 지원하려면 애플리케이션이 Google Cloud 내에서 IdP를 사용할 수 있도록 허용해야 합니다.
다음 섹션에서는 Google Cloud에 배포된 워크로드에서 IdP를 사용하도록 허용하기 위한 일반적인 패턴을 설명합니다.
온프레미스 AD FS를 Google Cloud에 노출
애플리케이션이 WS-Trust 또는 WS-Federation 사용을 요구하거나 OpenID Connect를 사용할 때 AD FS 전용 기능 또는 클레임에 의존하는 경우 애플리케이션에서 직접 인증에 AD FS를 사용하도록 허용할 수 있습니다.
애플리케이션은 AD FS를 사용함으로써 사용자를 인증할 수 있습니다. 그러나 인증이 Google ID를 기반으로 하지 않으므로 애플리케이션은 사용자 인증 정보로 인증되는 API 호출을 수행할 수 없습니다. 대신 모든 Google Cloud API 호출을 서비스 계정을 사용하여 인증해야 합니다.
사용자 환경
- 보호되는 리소스를 요청하는 경우 ADFS 사인온 화면으로 리디렉션되며 이 화면에는 이메일 주소를 입력하라는 메시지가 표시됩니다. AD FS가 인터넷을 통해 공개적으로 노출되지 않은 경우 회사 네트워크 또는 회사 VPN에 연결해야 AD FS 액세스가 가능할 수 있습니다.
- AD FS의 구성에 따라 Active Directory 사용자 이름과 비밀번호를 요구하는 사인온 화면이 표시될 수 있습니다. 또는 AD FS에서 Windows 로그인을 기반으로 사용자가 자동으로 로그인되도록 시도할 수 있습니다.
- AD FS에서 인증된 사용자는 보호되는 리소스로 다시 리디렉션됩니다.
장점
- WS-Trust, WS-Federation을 포함하여 Cloud ID에서 지원되지 않는 인증 프로토콜을 사용할 수 있습니다.
- 애플리케이션이 AD FS에서 개발되어 테스트된 경우 Cloud ID를 사용하도록 애플리케이션을 전환하는 데 따르는 위험을 피할 수 있습니다.
- 온프레미스 네트워크와 Google Cloud 간에 하이브리드 연결을 설정할 필요가 없습니다.
권장사항
- 직원 사용자가 액세스할 수 있도록 AD FS를 배포 및 노출하되 필요 이상으로 노출하지 않습니다. 직원 사용자는 AD FS에 액세스할 수 있어야 하지만 Google 또는 Google Cloud에 배포된 애플리케이션에서 AD FS에 연결할 수 있어야 한다는 요구사항은 없습니다.
- AD FS를 사용할 수 없게 되면 사용자는 더 이상 애플리케이션을 사용하지 못할 수 있습니다. AD FS 및 AD FS가 의존하는 도메인 컨트롤러의 배포 및 규모가 가용성 목표를 충족하는지 확인해야 합니다.
- WS-Trust와 WS-Federation에 의존하는 애플리케이션을 SAML 또는 OpenID Connect를 사용하도록 리팩터링하는 방법을 고려합니다.
- 애플리케이션이 AD FS에서 발행하는
IdTokens의 클레임으로 노출되는 그룹 정보에 의존하는 경우 Directory API와 같은 다른 소스에서 그룹 정보를 검색하는 방법을 고려합니다. Directory API 쿼리는 Google Workspace 도메인 전체 위임용으로 사용 설정된 서비스 계정을 사용해야 하는 높은 권한 작업입니다.
온프레미스 LDAP 디렉터리를 Google Cloud에 노출
일부 애플리케이션은 사용자에게 사용자 이름 및 비밀번호 입력을 요구하고 이 사용자 인증 정보를 사용하여 LDAP 바인딩 작업을 시도할 수 있습니다. SAML과 같은 다른 수단을 사용하여 인증을 수행하도록 이러한 애플리케이션을 수정할 수 없는 경우 애플리케이션에 온프레미스 LDAP 디렉터리 액세스 권한을 부여할 수 있습니다.
장점
- 애플리케이션을 변경할 필요가 없습니다.
권장사항
- Cloud VPN 또는 Cloud Interconnect를 사용하여 Google Cloud와 온프레미스 네트워크 간에 하이브리드 연결을 설정해서 인터넷을 통해 LDAP 디렉터리를 노출할 필요가 없도록 합니다.
- 온프레미스 LDAP 디렉터리 쿼리로 인해 발생하는 지연이 사용자 환경에 부정적인 영향을 미치지 않는지 확인합니다.
- 애플리케이션과 LDAP 디렉터리 간의 통신이 암호화되는지 확인합니다. Cloud VPN을 사용하거나 Cloud Interconnect를 LDAP/S와 함께 사용하여 암호화를 달성할 수 있습니다.
- LDAP 디렉터리 또는 Google Cloud와 온프레미스 간의 비공개 연결을 사용할 수 없게 되면 사용자는 더 이상 LDAP 기반 애플리케이션을 사용하지 못할 수 있습니다. 따라서 각 서버의 배포 및 규모가 가용성 목표를 충족하는지 확인하고 중복 VPN 터널 또는 상호 연결을 사용하는 방법을 고려합니다.
- 비즈니스 연속성을 위해 Google Cloud를 사용하는 경우 온프레미스 LDAP 디렉터리에 의존하면 Google Cloud를 기존 배포의 독립적인 복사본으로 사용하는 본래의 의도가 희석될 수 있습니다. 이 경우 LDAP 디렉터리를 Google Cloud에 복제하는 방법을 대신 고려하세요.
- Active Directory를 사용하는 경우, 특히 Google Cloud에서 실행 중인 Windows 머신을 Active Directory로 도메인 조인할 계획이라면 대신 Google Cloud에서 복제본을 실행하는 방법을 고려하세요.
온프레미스 LDAP 디렉터리를 Google Cloud에 복제
온프레미스 LDAP 디렉터리를 Google Cloud에 복제하는 것은 온프레미스 LDAP 디렉터리를 Google Cloud에 노출하는 패턴과 비슷합니다. LDAP를 사용하여 사용자 이름과 비밀번호를 확인하는 애플리케이션에서 이 접근 방법의 목적은 Google Cloud에서 이러한 애플리케이션을 실행할 수 있도록 하는 데 있습니다. 이러한 애플리케이션이 온프레미스 LDAP 디렉터리를 쿼리하도록 허용하는 대신 Google Cloud에 온프레미스 디렉터리의 복제본을 유지할 수 있습니다.
장점
- 애플리케이션을 변경할 필요가 없습니다.
- Google Cloud에서 실행되는 LDAP 기반 애플리케이션의 이 가용성은 온프레미스 디렉터리 또는 온프레미스 네트워크 연결의 가용성에 의존하지 않습니다. 이 패턴은 비즈니스 연속성 하이브리드 시나리오에 적합합니다.
권장사항
- Cloud VPN 또는 Cloud Interconnect를 사용하여 Google Cloud와 온프레미스 네트워크 간에 하이브리드 연결을 설정해서 인터넷을 통해 LDAP 디렉터리를 노출할 필요가 없도록 합니다.
- 온프레미스 LDAP 디렉터리 간의 복제가 안전한 채널을 통해 수행되는지 확인합니다.
- 여러 영역 또는 리전에 걸쳐 여러 개의 LDAP 디렉터리 복제본을 배포하여 가용성 목표를 충족합니다. 내부 부하 분산기를 사용하여 같은 리전에 배포된 여러 복제본 간에 LDAP 연결을 분산할 수 있습니다.
- 별도의 Google Cloud 프로젝트를 공유 VPC와 함께 사용하여 LDAP 복제본을 배포하고 이 프로젝트에 대한 액세스 권한을 최소 권한 원칙에 따라 부여합니다.
온프레미스 Active Directory를 Google Cloud로 확장
Google Cloud에 배포하고자 하는 워크로드 중 일부는 Active Directory Domain Services에 의존할 수 있습니다. 예를 들면 다음과 같습니다.
- 도메인 조인해야 하는 Windows 머신
- 인증에 Kerberos 또는 NTLM을 사용하는 애플리케이션
- Active Directory를 LDAP 디렉터리를 사용하여 사용자 이름과 비밀번호를 확인하는 애플리케이션
이러한 워크로드를 지원하려면 예를 들어 다음 다이어그램과 같이 Google Cloud에 리소스 포리스트를 배포하고 온프레미스 Active Directory 포리스트에 연결하는 방법으로 온프레미스 Active Directory 포리스트를 Google Cloud로 확장할 수 있습니다.
하이브리드 환경에 Active Directory를 배포하기 위한 이 접근 방법 및 다른 방법에 대한 자세한 내용은 하이브리드 환경에서 Active Directory 사용 패턴을 참조하세요.
장점
- 워크로드에서 Windows 머신을 Active Directory 도메인에 조인하는 기능을 포함하여 Active Directory를 완전히 활용할 수 있습니다.
- Google Cloud에서 실행되는 Active Directory 기반 애플리케이션의 가용성은 온프레미스 리소스 또는 온프레미스 네트워크 연결의 가용성에 의존하지 않습니다. 이 패턴은 비즈니스 연속성 하이브리드 시나리오에 적합합니다.
권장사항
- Cloud VPN 또는 Cloud Interconnect를 사용하여 Google Cloud와 온프레미스 네트워크 간에 하이브리드 연결을 설정합니다.
- Google Cloud와 온프레미스 네트워크 간의 통신을 최소화하기 위해 Google Cloud 배포를 위한 별도의 Active Directory 사이트를 만듭니다. 공유 VPC당 하나의 사이트를 사용하거나, 리전 간 통신을 최소화하기 위해 공유 VPC 및 리전당 하나의 사이트를 사용할 수 있습니다.
- Google Cloud에 배포된 리소스 전용으로 별도의 Active Directory 도메인을 만들고 이 도메인을 기존 포리스트에 추가합니다. 별도의 도메인을 사용하면 복제 오버헤드와 파티션 크기를 줄이는 데 도움이 됩니다.
- 가용성을 높이려면 2개 이상의 도메인 컨트롤러를 여러 영역에 분산 배포합니다. 여러 리전을 사용하는 경우 각 리전에 도메인 컨트롤러를 배포하는 방법을 고려하세요.
- 별도의 Google Cloud 프로젝트를 공유 VPC와 함께 사용하여 도메인 컨트롤러를 배포하고 이 프로젝트에 대한 액세스 권한을 최소 권한 원칙에 따라 부여합니다. 그렇지 않은 경우 비인증 프로젝트 구성원이 비밀번호를 생성하거나 도메인 컨트롤러 인스턴스의 직렬 콘솔에 액세스하여 도메인을 손상시킬 수 있습니다.
- AD FS 서버 팜과 GCDS를 Google Cloud에 배포하는 방법을 고려합니다. 이 접근 방법을 사용하면 온프레미스 네트워크 연결 또는 리소스의 가용성에 의존하지 않고 Active Directory와 Cloud Identity를 페더레이션할 수 있습니다.
다음 단계
- Google Cloud와 Active Directory 페더레이션에 대해 자세히 알아보기
- 하이브리드 환경에서 Active Directory 사용 패턴에 대해 자세히 알아보기
- Cloud ID와 Azure AD를 페더레이션 방법 알아보기
- Google Cloud 시작 영역의 리소스 계층 구조 설계하기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기