이 문서에서는 Active Directory를 IdP 및 신뢰할 수 있는 소스로 사용하기 위해 Cloud ID 또는 Google Workspace를 구성하는 방법을 설명합니다.
이 문서에서는 Active Directory의 논리적 구조를 Cloud ID 및 Google Workspace에서 사용하는 구조와 비교하고 Active Directory 포리스트, 도메인, 사용자, 그룹을 매핑하는 방법을 설명합니다. 또한 이 문서에서는 사용자의 시나리오에 가장 적합한 매핑 방법을 결정하는 데 도움이 되는 플로우 차트를 제공합니다.
이 문서에서는 사용자가 Active Directory에 익숙하다고 가정합니다.
페더레이션 구현
Google Cloud는 인증 및 액세스 관리를 위해 Google ID를 사용합니다. 모든 직원이 Active Directory에 계정을 가지고 있는 경우 각 직원의 Google ID를 수동으로 유지하면 불필요한 관리 오버헤드가 추가될 수 있습니다. Google Cloud 와 기존 ID 관리 시스템 간에 사용자 ID를 페더레이션하면 Google ID의 유지보수를 자동화하고 ID의 수명 주기를 Active Directory의 기존 사용자와 연결할 수 있습니다.
Active Directory와 Cloud ID 또는 Google Workspace 간의 페더레이션을 설정하려면 다음 두 가지가 필요합니다.
사용자 프로비저닝: 관련 사용자와 그룹이 Active Directory에서 Cloud ID 또는 Google Workspace로 주기적으로 동기화됩니다. 이 프로세스를 사용할 경우 Active Directory에서 새 사용자를 만들었을 때 연결된 사용자가 최초 로그인하기 전이라도 Google Cloud에서 이 계정을 참조할 수 있습니다. 또한 이 프로세스를 통해 사용자 삭제가 전파됩니다.
프로비저닝은 한 방향으로 이루어지므로 Active Directory에서의 변경사항이 Google Cloud로 복제되지만 반대 방향으로는 복제되지 않습니다. 또한 프로비저닝에는 비밀번호가 포함되지 않습니다. 페더레이션된 설정에서 Active Directory는 이러한 사용자 인증 정보를 관리하는 유일한 시스템으로 유지됩니다.
싱글 사인온(SSO): 사용자가 인증해야 할 때마다 Google Cloud는 보안 보장 마크업 언어(SAML) 프로토콜을 사용하여 인증을 Active Directory에 위임합니다. 이러한 위임을 통해 Active Directory에서만 사용자 인증 정보를 관리하게 되고, 적용 가능한 정책 또는 다단계 인증(MFA) 메커니즘이 적용됩니다. 하지만 로그인이 성공하려면 해당 사용자가 이미 프로비저닝되어 있어야 합니다.
페더레이션을 구현하려면 다음 도구를 사용하세요.
- Google Cloud 디렉터리 동기화(GCDS)는 동기화 프로세스를 구현하는 도구로서 Google에서 무료로 제공합니다. GCDS는 보안 소켓 레이어 (SSL)를 통해 Google Cloud와 통신하며 일반적으로 기존 컴퓨팅 환경에서 실행됩니다.
- AD FS(Active Directory Federation Service)는 Windows Server의 일부로서 Microsoft에서 제공합니다. AD FS를 사용하면 페더레이션된 인증에 Active Directory를 사용할 수 있습니다. AD FS는 일반적으로 기존 컴퓨팅 환경 내에서 실행됩니다.
Google Cloud용 API는 공개적으로 사용 가능하며 SAML은 개방형 표준이므로 여러 도구를 사용하여 페더레이션을 구현할 수 있습니다. 이 문서에서는 GCDS와 AD FS의 사용에 중점을 둡니다.
Active Directory의 논리적 구조
Active Directory 인프라에서 최상위 구성 요소는 포리스트입니다. 포리스트는 하나 이상의 도메인에 대한 컨테이너 역할을 하고 포리스트 루트 도메인에서 이름을 가져옵니다. Active Directory 포리스트 내의 도메인은 서로 신뢰하므로 한 도메인에서 인증된 사용자가 다른 도메인에 있는 리소스에 액세스할 수 있습니다. 포리스트가 포리스트 간 트러스트를 사용하여 연결되어 있지 않으면 개별 포리스트는 기본적으로 서로 신뢰하지 않으며, 한 포리스트에서 인증된 사용자가 다른 포리스트에 있는 리소스에 액세스할 수 없습니다.
Active Directory 도메인은 리소스 관리를 위한 컨테이너이며 관리 경계로 간주됩니다. 하나의 포리스트에 여러 도메인을 포함하는 것은 관리를 간소화하거나 추가 구조를 적용하기 위한 방법의 하나지만, 포리스트의 도메인은 보안 경계를 나타내지 않습니다.
Google Cloud의 논리적 구조
Google Cloud에서 조직은 모든 리소스의 컨테이너 역할을 하며 폴더와 프로젝트를 사용하여 상세하게 세분화할 수 있습니다. 따라서 조직, 폴더, 프로젝트는 Active Directory 도메인과 비슷한 역할을 합니다.
Active Directory는 사용자를 리소스로 취급하므로 사용자 관리와 인증이 도메인과 연결됩니다. 반면에 Google Cloud는 서비스 계정을 제외하고 조직의 사용자를 관리하지 않습니다. 대신 Google Cloud는 Cloud ID 또는 Google Workspace를 통해 사용자를 관리합니다.
Cloud ID 또는 Google Workspace 계정은 사용자 및 그룹의 비공개 디렉터리 역할을 합니다. 계정 관리자는 사용자 및 그룹의 수명 주기와 구성을 제어하고 인증 수행 방법을 정의할 수 있습니다.
Cloud ID 또는 Google Workspace 계정을 만들면 Google Cloud 조직이 자동으로 생성됩니다. Cloud ID 또는 Google Workspace 계정과 이와 연결된 Google Cloud 조직은 동일한 이름을 공유하며 서로 연결됩니다. 하지만 Google Cloud 조직은 다른 Cloud ID 또는 Google Workspace 계정에서 사용자와 그룹을 참조할 수 있습니다.
Active Directory와 Google Cloud 통합
Active Directory와 Google Cloud의 논리적 구조 사이에 일부 유사점이 있지만, 두 구조 간의 매핑이 모든 시나리오에서 동일하게 작동하는 경우는 하나도 없습니다. 대신 두 시스템을 통합하고 구조를 매핑하는 적절한 방식은 여러 요소에 따라 달라집니다.
- 도메인과 포리스트를 Cloud ID 또는 Google Workspace 계정에 매핑하는 방법
- DNS 도메인을 매핑하는 방법
- 사용자를 매핑하는 방법
- 그룹을 매핑하는 방법
다음 섹션에서는 이러한 각 요소에 대해 설명합니다.
포리스트 매핑
특히 대규모 조직에서는 전사적으로 ID와 액세스를 관리하기 위해 둘 이상의 Active Directory 도메인을 사용하는 경우가 많습니다. Active Directory와 Google Cloud를 페더레이션하려는 경우 가장 먼저 고려할 사항은 Active Directory 인프라의 토폴로지입니다.
단일 포리스트, 단일 도메인
하나의 포리스트에 도메인이 하나만 있으면 전체 Active Directory 포리스트를 단일 Cloud ID 또는 Google Workspace 계정에 매핑할 수 있습니다. 그러면 이 계정이 Google Cloud 리소스를 관리하는 데 사용할 수 있는 단일 Google Cloud 조직의 기반이 됩니다.
단일 도메인 환경에서 도메인 컨트롤러와 전역 카탈로그 서버는 모두 Active Directory에서 관리되는 모든 객체에 대한 액세스를 제공합니다. 대부분의 경우 GCDS의 단일 인스턴스를 실행하여 사용자 계정과 그룹을 Google Cloud에 동기화하고 단일 AD FS 인스턴스 또는 제품군이 싱글 사인온(SSO)을 처리하도록 설정할 수 있습니다.
단일 포리스트, 다중 도메인
하나의 포리스트에 여러 Active Directory 도메인이 포함되어 있으면 이를 하나의 또는 여러 개의 도메인 트리로 구성할 수 있습니다. 두 가지 경우 모두 포리스트 전체를 단일 Cloud ID 또는 Google Workspace 계정에 매핑할 수 있습니다. 그러면 이 계정이 Google Cloud 리소스를 관리하는 데 사용할 수 있는 단일 Google Cloud 조직의 기반이 됩니다.
다중 도메인 환경에서는 도메인 컨트롤러에서 검색할 수 있는 정보와 전역 카탈로그 서버에서 쿼리할 수 있는 정보에 차이가 있습니다. 도메인 컨트롤러는 로컬 도메인의 데이터만 제공하지만 전역 카탈로그 서버는 포리스트의 모든 도메인의 정보에 대한 액세스를 제공합니다. 결정적으로 전역 카탈로그 서버에서 제공하는 데이터는 부분적이며 일부 LDAP 속성이 누락되어 있습니다. 이러한 제한은 그룹을 동기화하도록 GCDS를 구성하는 방법에 영향을 미칠 수 있습니다.
사용자가 그룹을 매핑하는 방법에 따라 다중 도메인 포리스트를 Google Cloud와 페더레이션하는 데 하나 이상의 GCDS 인스턴스가 필요하지만, 싱글 사인온(SSO)을 처리하는 데는 하나의 AD FS 인스턴스 또는 제품군만 필요합니다.
포리스트 간 트러스트가 있는 다중 포리스트
대규모 조직에서는 종종 합병이나 인수의 결과로 Active Directory 포리스트가 두 개 이상 존재하는 경우가 많습니다. 사용자가 단일 포리스트의 경계를 초월하여 리소스를 공유하고 액세스할 수 있도록 양방향 포리스트 간 트러스트를 사용하여 이러한 포리스트를 결합할 수 있습니다.
모든 포리스트가 다른 포리스트와 서로 양방향 트러스트 관계이면 전체 환경을 단일 Cloud ID 또는 Google Workspace 계정에 매핑할 수 있습니다. 이 계정은 Google Cloud 리소스를 관리하는 데 사용할 수 있는 단일 Google Cloud 조직의 기반이 됩니다.
전역 카탈로그 서버는 여러 도메인의 데이터에 대한 액세스를 제공하지만 범위가 단일 포리스트로 제한됩니다. 따라서 다중 포리스트 환경에서 예를 들어 사용자의 전체 목록을 가져오려면 여러 도메인 컨트롤러 또는 전역 카탈로그 서버를 쿼리해야 합니다. 이러한 제한으로 인해 다중 포리스트 환경과 Google Cloud를 페더레이션하려면 포리스트마다 하나 이상의 GCDS 인스턴스가 필요합니다. 포리스트 간 트러스트는 사용자 인증이 포리스트 경계를 초월하여 작동하게 해주므로 단일 AD FS 인스턴스 또는 플릿으로도 싱글 사인온(SSO)을 처리할 수 있습니다.
환경에 포리스트 간 트러스트가 없는 다중 포리스트가 포함되어 있지만 Google Cloud와의 페더레이션과 관련된 모든 Active Directory 도메인이 외부 트러스트를 통해 연결되어 있으면 동일한 고려사항이 적용됩니다.
포리스트 간 트러스트가 없는 다중 포리스트
이 그림의 환경에서는 포리스트 경계를 초월하여 리소스를 인증하거나 리소스에 액세스할 수 없습니다. 또한 단일 AD FS 인스턴스 또는 플릿이 모든 포리스트의 사용자에 대해 싱글 사인온(SSO) 요청을 처리하는 것도 불가능합니다.
따라서 포리스트 간 트러스트가 없는 여러 포리스트를 단일 Cloud ID 또는 Google Workspace 계정에 매핑할 수 없습니다. 대신 각 포리스트가 별개의 Cloud ID 또는 Google Workspace 계정에 매핑되어야 하며, 이 계정은 하나 이상의 GCDS 인스턴스와 포리스트당 하나의 AD FS 서버 또는 플릿을 실행해야 합니다.
Google Cloud에서는 Cloud ID 또는 Google Workspace 계정별로 별도의 조직이 생성됩니다. 대부분의 경우에는 별도의 여러 조직을 관리할 필요가 없습니다. 조직 중에서 하나를 선택하고 이를 다른 Cloud ID 또는 Google Workspace 계정과 연결하면 여러 Active Directory 포리스트와 페더레이션된 조직을 효과적으로 만들 수 있습니다. 다른 조직은 사용되지 않는 상태로 유지됩니다.
DNS 도메인 매핑
DNS는 Active Directory와 Cloud ID 및 Google Workspace에서 모두 중요한 역할을 합니다. Active Directory와 Google Cloud를 페더레이션하려는 경우 고려할 두 번째 요소는 Active Directory와 Google Cloud 간에 DNS 도메인을 공유하거나 매핑하는 방법입니다.
Active Directory에서의 DNS 도메인 사용
Active Directory 포리스트에서 DNS 도메인은 여러 곳에서 사용됩니다.
- Active Directory DNS 도메인: 각 Active Directory 도메인이 하나의 DNS 도메인에 해당합니다. 이 도메인은
corp.example.com과 같이 전역이거나,corp.local또는corp.internal과 같이 로컬 도메인 이름일 수 있습니다. - 메일 교환(MX) 도메인: 이메일 주소는 DNS 도메인을 사용합니다. 이 도메인이 Active Directory DNS 도메인과 동일한 경우도 있지만, 대부분의 경우에는
example.com과 같이 다른(종종 더 짧은) 도메인이 사용됩니다. 원칙적으로 Active Directory의 사용자에는 선택사항인mail속성과 연결된 이메일 주소가 있습니다. - UPN 서픽스 도메인: 이 도메인은 사용자 계정 이름(UPN)에 사용됩니다. 기본적으로 사용자 도메인의 Active Directory DNS 도메인은 UPN을 빌드하는 데 사용됩니다. 따라서 도메인이
corp.example.com인 사용자 john의 기본 UPN은john@corp.example.com입니다. 하지만 포리스트가 추가 DNS 도메인을 Active Directory DNS 도메인이나 MX 도메인에 해당하지 않는 UPN 서픽스로 사용하도록 구성할 수 있습니다. UPN은 선택사항이며 사용자의userPrincipalName필드에 저장됩니다. - 엔드포인트 도메인: AD FS 서버와 같은 공용 서버에는 일반적으로
login.external.example.com과 같은 DNS 이름이 할당됩니다. 이러한 용도로 사용되는 도메인은 MX, UPN 서픽스 또는 Active Directory DNS 도메인과 중복되거나, 완전히 다른 도메인일 수 있습니다.
Google Cloud에서의 DNS 도메인 사용
Google Cloud가 인증 목적으로 사용하는 Google 로그인은 이메일 주소를 사용하여 사용자를 식별합니다. 이메일 주소를 사용하면 이메일 주소가 전역적으로 고유함을 보장하고 Google Cloud에서 이메일 주소로 알림 메시지도 전송할 수 있습니다.
Google 로그인은 이메일 주소에서 @ 뒤에 있는 도메인 부분을 기준으로 사용자를 인증하는 데 사용할 계정 디렉터리 또는 ID 공급업체를 결정합니다. 예를 들어 gmail.com 도메인을 사용하는 이메일 주소의 경우 Google 로그인은 인증에 Gmail 사용자 디렉터리를 사용합니다.
Google Workspace 또는 Cloud ID 계정에 가입하면 Google 로그인에서 인증에 사용할 수 있는 비공개 디렉터리가 생성됩니다. Gmail 디렉터리가 gmail.com 도메인과 연결되는 방식과 동일하게 Google Workspace 및 Cloud ID 계정을 커스텀 도메인과 연결해야 합니다.
세 가지 종류의 도메인을 사용할 수 있습니다.
- 기본 도메인: 이 도메인은 Cloud ID 또는 Google Workspace 계정을 식별하며 Google Cloud에서 조직의 이름으로 사용됩니다. Cloud ID 또는 Google Workspace에 가입할 때 이 도메인 이름을 지정해야 합니다.
- 보조 도메인: 기본 도메인과 함께 다른 보조 도메인을 Cloud ID 또는 Google Workspace 계정과 연결할 수 있습니다. 디렉터리의 각 사용자는 기본 도메인과 또는 보조 도메인 중 하나와 연결됩니다. 따라서
example.com이 기본 도메인이고secondary.example.com이 보조 도메인이면 두 사용자johndoe@example.com과johndoe@secondary.example.com이 별도의 사용자로 간주됩니다. - 별칭 도메인: 별칭 도메인은 다른 도메인의 대체 이름입니다.
즉,
alias.example.com이example.com의 별칭 도메인으로 설정된 경우johndoe@example.com과johndoe@alias.example.com은 동일한 사용자를 참조합니다.
모든 도메인은 다음 요구사항을 충족해야 합니다.
- 유효한 전역 DNS 도메인 이름이어야 합니다. 설정 중에 도메인 소유권을 확인하기 위해 각 DNS 영역(zone)에 대한 관리 액세스 권한이 필요할 수 있습니다.
example.com과 같은 도메인은 단일 디렉터리만 참조할 수 있습니다. 그러나subdomain.example.com과 같은 하위 도메인을 사용하여 다른 디렉터리를 참조할 수 있습니다.- 이 도메인 이름을 사용하여 구성된 이메일 주소로 보낸 메시지를 제대로 전송할 수 있도록 기본 및 보조 도메인에 올바른 MX 레코드가 있어야 합니다.
디렉터리 간에 동기화를 설정하려면 Active Directory 도메인과 Cloud ID 또는 Google Workspace에서 사용하는 도메인 간에 매핑이 필요합니다. 적절한 매핑을 결정하는 방법은 Active Directory를 사용하는 방법에 따라 다르며, 사용자가 Active Directory 포리스트에서 식별되는 방법과 Cloud ID 또는 Google Workspace에 매핑되는 방법을 상세히 고려해야 합니다.
사용자 매핑
Active Directory와 Google Cloud를 페더레이션하려는 경우 고려할 세 번째 요소는 Active Directory와 Cloud ID 또는 Google Workspace 간에 사용자를 매핑하는 방법입니다.
Active Directory에서 사용자 식별
내부적으로 Active Directory는 두 개의 식별자를 사용하여 사용자를 고유하게 식별합니다.
objectGUID: 이 전역적으로 고유한 ID는 사용자를 만들 때 생성되며 변경되지 않습니다.objectSID: SID 또는 보안 식별자는 모든 액세스 검사에 사용됩니다. 이 ID는 도메인 내에서는 고유하고 안정적이지만, 포리스트의 다른 도메인으로 이동하면 사용자에 새로운 SID가 할당될 수 있습니다.
이러한 ID는 모두 사용자가 의미를 알 수 있는 형태가 아니므로, Active Directory는 사람이 손쉽게 사용자를 식별할 수 있는 두 가지 방법을 제공합니다.
UPN(
userPrincipalName): 사용자를 식별하는 가장 좋은 방법은 UPN을 사용하는 것입니다. UPN은 RFC 822 형식의 이메일 주소를 따르며,johndoe@corp.example.com과 같이 사용자 이름을 UPN 서픽스 도메인과 결합하여 생성됩니다. UPN은 사용자를 식별하는 가장 좋은 방법이지만 선택사항이므로 Active Directory 포리스트의 일부 사용자에는 UPN이 없을 수도 있습니다.UPN이 유효한 이메일 주소인 경우가 가장 좋지만 Active Directory는 이러한 방식을 자동으로 적용하지 않습니다.
Windows 2000 이전의 로그온 이름(
sAMAccountName): 이 이름은domain<var>user형식(예:corp\johndoe)으로 NetBIOS 도메인 이름과 사용자 이름을 결합하여 사용합니다. 이 이름은 레거시로 간주되지만 여전히 일반적으로 사용되며 사용자의 유일한 필수 식별자입니다.
특히 Active Directory는 사용자를 식별하는 데 사용자의 이메일 주소(mail)를 사용하지 않습니다. 따라서 이 필드는 필수가 아니며 포리스트에서 고유할 필요도 없습니다.
이러한 식별자는 언제든지 변경할 수 있습니다.
사용자 ID 매핑
Active Directory 사용자를 Cloud ID 또는 Google Workspace 사용자에 매핑하려면 각 사용자에 두 가지 정보가 필요합니다.
- 어떤 Active Directory 사용자가 Cloud ID 또는 Google Workspace의 어떤 사용자에 해당하는지를 추적하기 위해 동기화 중에 사용할 수 있는 안정적인 고유한 ID. AD 측에서는
objectGUID가 이 목적에 완벽하게 부합합니다. - 도메인 부분이 Cloud ID 또는 Google Workspace 계정의 기본, 보조 또는 별칭 도메인에 해당하는 이메일 주소. 이 이메일 주소는 Google Cloud 전체에서 사용되므로 주소가 의미가 있는지 확인하세요.
objectGUID에서 주소를 파생시키는 방법은 자동으로 생성되는 다른 이메일 주소와 마찬가지로 비실용적입니다.
Active Directory 사용자의 경우 userPrincipalName 및 mail이라는 두 가지 필드는 Cloud ID 또는 Google Workspace 이메일 주소를 제공하기 위한 조합입니다.
사용자 기본 이름으로 매핑
userPrincipalName 필드를 사용하려면 동기화 대상인 모든 사용자에 대해 다음 두 가지 기준이 충족되어야 합니다.
- 사용자 기본 이름(UPN)은 유효한 이메일 주소여야 합니다. 또한 UPN 서픽스 도메인으로 사용되는 모든 도메인은 MX 도메인이어야 하며, 사용자의 UPN으로 전송된 이메일이 해당 이메일 받은편지함으로 전송되도록 설정되어야 합니다.
UPN 할당이 완료되어야 합니다. 동기화 대상인 모든 사용자에 UPN이 할당되어 있어야 합니다. 다음 PowerShell 명령어를 사용하면 UPN이 없는 사용자를 쉽게 찾을 수 있습니다.
Get-ADUser -LDAPFilter "(!userPrincipalName=*)"
이 두 가지 기준이 충족되면 UPN을 Cloud ID 또는 Google Workspace 이메일 주소에 안전하게 매핑할 수 있습니다. UPN 서픽스 도메인 중 하나를 Cloud ID 또는 Google Workspace의 기본 도메인으로 사용하고 다른 UPN 서픽스 도메인을 보조 도메인으로 추가할 수 있습니다.
조건 중 하나가 충족되지 않더라도 여전히 UPN을 Cloud ID 또는 Google Workspace 이메일 주소에 매핑할 수 있지만 다음과 같은 사항에 주의해야 합니다.
- UPN이 유효한 이메일 주소가 아닌 경우 사용자가 Google Cloud에서 보낸 알림 이메일을 받지 못할 수 있으며 이로 인해 사용자가 중요한 정보를 놓칠 수 있습니다.
- UPN이 없는 사용자는 동기화 중에 무시됩니다.
- 동기화를 구성하여 UPN 서픽스 도메인을 다른 도메인으로 바꿀 수 있습니다. 하나의 포리스트에서 여러 UPN 서픽스 도메인을 사용하는 경우, 모든 UPN 서픽스 도메인이 단일 도메인으로 대체되므로 이 방식을 사용하면 중복이 생성될 수 있습니다. 중복이 있는 경우 하나의 사용자만 동기화할 수 있습니다.
UPN을 사용하여 사용자를 매핑하는 경우의 주요 이점은 포리스트 전체에서 UPN이 고유하다는 점이 보장되고, 도메인의 선별된 집합을 사용하여 잠재적인 동기화 문제를 방지하는 데 도움이 된다는 점입니다.
이메일 주소로 매핑
mail 필드를 사용하려면 동기화할 모든 사용자에 대해 다음 기준이 충족되어야 합니다.
이메일 할당을 완료해야 합니다. 동기화 대상인 모든 사용자에는
mail필드가 채워져 있어야 합니다. 다음 PowerShell 명령어를 사용하면 이 필드가 채워지지 않은 사용자를 쉽게 찾을 수 있습니다.Get-ADUser -LDAPFilter "(!mail=*)"
이메일 주소가 모두 사용자가 소유한 선별된 도메인 집합을 사용해야 합니다. 일부 사용자가 파트너 회사 또는 소비자 이메일 제공자를 가리키는 이메일 주소를 사용하는 경우 이러한 이메일 주소를 사용할 수 없습니다.
포리스트에서 모든 이메일 주소가 고유해야 합니다. Active Directory는 고유성을 적용하지 않으므로 커스텀 검사 또는 정책을 구현해야 할 수도 있습니다.
모든 관련 사용자가 이러한 기준을 충족하면 이러한 이메일 주소에서 사용되는 모든 도메인을 식별하여 Cloud ID 또는 Google Workspace에서 기본 도메인과 보조 도메인으로 사용할 수 있습니다.
조건 중 하나가 충족되지 않더라도 이메일 주소를 Cloud ID 또는 Google Workspace 이메일 주소에 매핑할 수 있지만 다음 사항에 주의해야 합니다.
- 동기화 중에 이메일 주소가 없는 사용자는 무시되며 Cloud ID 또는 Google Workspace 계정과 연결되지 않은 도메인을 사용하는 이메일 주소가 있는 사용자도 무시됩니다.
- 두 사용자가 동일한 이메일 주소를 공유하면 하나의 사용자만 동기화됩니다.
- 동기화를 구성하여 이메일 주소의 도메인을 다른 도메인으로 바꿀 수 있습니다. 이 프로세스에서 중복을 만들 수 있으며, 이 경우 하나의 사용자만 동기화됩니다.
그룹 매핑
Active Directory와 Google Cloud를 페더레이션하려는 경우 고려할 네 번째 요소는 Active Directory와 Google Cloud 간에 그룹을 동기화할지 여부와 이를 매핑하는 방법입니다.
Google Cloud에서 그룹은 일반적으로 여러 프로젝트에서 액세스를 효율적으로 관리하기 위해 사용됩니다. 각 프로젝트에서 개별 사용자를 IAM 역할에 할당하는 대신, 조직에서 일반적인 역할을 모델링하는 그룹의 집합을 정의한 다음 이러한 그룹을 IAM 역할의 집합에 할당합니다. 그룹의 멤버십을 수정하여 리소스 전체 집합에 대한 사용자의 액세스를 제어할 수 있습니다.
Active Directory는 두 종류의 그룹, 즉 배포 그룹과 보안 그룹을 구분합니다. 배포 그룹은 이메일 목록을 관리하는 데 사용됩니다. Microsoft Exchange에서 Google Workspace로 마이그레이션하는 경우에 배포 그룹을 동기화하면 GCDS에서 일반 배포 그룹과 동적 배포 그룹을 모두 처리할 수 있으므로 유용합니다. 배포 그룹은 Google Cloud의 ID 및 액세스 관리에서 문제가 되지 않으므로 이 설명에서는 보안 그룹에만 중점을 둡니다.
Active Directory와 Google Cloud 간 그룹 매핑은 선택사항입니다. 사용자 프로비저닝이 설정되면 Cloud ID 또는 Google Workspace에서 직접 그룹을 만들고 관리할 수 있습니다. 즉, Active Directory가 액세스 관리가 아닌 ID 관리의 중앙 시스템으로 유지됩니다. Active Directory를 ID 관리 및 액세스 관리를 위한 중앙 시스템으로 유지하려면 보안 그룹을 Cloud ID 또는 Google Workspace에서 관리하는 대신 Active Directory에서 동기화하는 것이 좋습니다. 이 방법을 사용하면 Active Directory에서 그룹 멤버십을 사용하도록 IAM을 설정하여 Google Cloud의 특정 리소스에 액세스할 수 있는 사용자를 제어할 수 있습니다.
Active Directory의 보안 그룹
보안 그룹은 Windows 보안 및 Active Directory 액세스 관리에서 근본적인 역할을 합니다. 이 역할은 Active Directory 그룹의 세 가지 유형인 도메인 로컬 그룹, 전역 그룹, 유니버설 그룹에 의해 지원됩니다.
- 도메인 로컬 그룹
- 이 그룹은 단일 도메인의 범위 내에서만 관련이 있으며 다른 도메인에서 참조될 수 없습니다. 구성원의 목록을 포리스트에서 복제할 필요가 없기 때문에 포함할 수 있는 구성원의 유형과 관련하여 도메인 로컬 그룹이 가장 유연합니다.
- 전역 그룹
- 이 그룹은 다른 도메인에 표시되고 다른 도메인에서 참조할 수 있습니다. 하지만 구성원 목록은 복제되지 않습니다. 이러한 제약으로 인해 이 그룹에 포함될 수 있는 구성원의 유형이 제한됩니다. 이 그룹에는 사용자 및 동일한 도메인의 다른 전역 그룹만 포함될 수 있습니다.
- 유니버설 그룹
- 이 그룹은 구성원 목록과 함께 포리스트에서 복제됩니다. 따라서 다른 도메인에서 참조될 수 있으며 사용자 및 다른 유니버설 그룹뿐만 아니라 모든 도메인의 전역 그룹을 포함할 수 있습니다.
Active Directory 포리스트에 단일 도메인만 있으면 GCDS를 사용하여 세 가지 유형의 보안 그룹을 모두 동기화할 수 있습니다. Active Directory 포리스트에서 두 개 이상의 도메인을 사용하는 경우 그룹 유형에 따라 Cloud ID 또는 Google Workspace와 동기화할 수 있는지 여부 및 동기화 방법이 결정됩니다.
도메인 로컬 및 전역 그룹은 포리스트에서 완전히 복제되지 않으므로 전역 카탈로그 서버에는 이러한 그룹에 대한 불완전한 정보가 포함됩니다. 이러한 제한은 의도적이고 디렉터리 복제 속도를 높이는 데 도움이 되지만, 이러한 그룹을 Cloud ID 또는 Google Workspace와 동기화하려는 경우에는 장애가 됩니다. 특히 전역 카탈로그 서버를 소스로 사용하도록 GCDS를 구성하면 이 도구는 포리스트의 모든 도메인에서 그룹을 찾을 수 있습니다. 하지만 전역 카탈로그 서버와 동일한 도메인에 있는 그룹만 구성원 목록을 포함하며 복제에 적합합니다. 다중 도메인 포리스트의 도메인 로컬 또는 전역 그룹을 동기화하려면 도메인별로 별도의 GCDS 인스턴스를 실행해야 합니다.
유니버설 그룹은 포리스트에서 완전히 복제되기 때문에 이러한 제한이 없습니다. 단일 GCDS 인스턴스가 여러 도메인의 유니버설 그룹을 동기화할 수 있습니다.
여러 Active Directory 도메인을 Cloud ID 또는 Google Workspace와 동기화하기 위해 여러 개의 GCDS 인스턴스가 필요하다고 결론을 내리기 전에, 모든 그룹을 동기화할 필요가 없을 수도 있다는 점을 기억하세요. 이러한 이유로 Active Directory 포리스트에서 서로 다른 유형의 보안 그룹이 일반적으로 사용되는 방식을 살펴볼 필요가 있습니다.
Active Directory에서의 보안 그룹 사용
다음 섹션에서는 Active Directory에서 사용되는 보안 그룹 유형을 설명합니다.
리소스 그룹
Windows는 액세스 제어 목록(ACL)을 기반으로 하는 액세스 모델을 사용합니다. 파일 또는 LDAP 객체와 같은 각 리소스에는 액세스할 수 있는 사용자를 제어하는 ACL이 연결되어 있습니다. 리소스와 ACL은 매우 세분화되어 있으므로 많은 수가 존재합니다. ACL의 유지관리를 간소화하기 위해 자주 사용되고 함께 액세스되는 리소스를 번들로 묶는 리소스 그룹을 만드는 것이 일반적입니다. 리소스 그룹을 영향을 받는 모든 ACL에 한꺼번에 추가하고, ACL을 변경하는 대신 리소스 그룹의 멤버십을 변경하여 추가 액세스를 관리합니다.
이러한 방식으로 번들로 묶이는 리소스는 일반적으로 단일 도메인에 있습니다. 따라서 리소스 그룹은 ACL에서든 또는 다른 리소스 그룹에 의해서든 단일 도메인에서만 참조되는 경향이 있습니다. 대부분의 리소스 그룹이 로컬이므로 리소스 그룹은 일반적으로 Active Directory에서 도메인 로컬 그룹을 사용하여 구현됩니다.
역할 및 조직 그룹
리소스 그룹은 액세스 관리를 간소화하는 데 유용하지만, 대규모 환경에서 많은 수의 리소스 그룹에 새로운 사용자를 추가해야 할 수도 있습니다. 이러한 이유로, 리소스 그룹은 일반적으로 역할 그룹 또는 조직 그룹으로 보완됩니다.
역할 그룹은 조직에서 특정 역할에 필요한 권한을 집계합니다. 예를 들어 이름이 '엔지니어링 문서 뷰어'인 역할 그룹은 구성원에게 모든 엔지니어링 문서에 대한 읽기 전용 액세스 권한을 부여합니다. 실제로는 역할 그룹을 생성한 다음 이 그룹을 다양한 종류의 문서에 대한 액세스를 제어하는 데 사용되는 모든 리소스 그룹의 구성원으로 만들어서 이러한 기능을 구현합니다.
비슷한 방식으로, 조직 그룹은 조직 내의 부서에서 필요로 하는 권한을 집계합니다. 예를 들어 이름이 '엔지니어링'인 조직 그룹은 엔지니어링 부서의 구성원이 일반적으로 필요로 하는 모든 리소스에 대한 액세스 권한을 부여합니다.
기술적으로 역할 그룹과 리소스 그룹 간에는 차이가 없으며 두 그룹은 일반적으로 함께 사용됩니다. 하지만 리소스 그룹과 달리 역할 그룹과 조직 그룹은 도메인의 경계를 초월하는 관련성을 가질 수 있습니다. 이러한 그룹을 다른 도메인의 리소스 그룹에서 참조할 수 있도록 하기 위해 일반적으로 역할 그룹과 조직 그룹은 단일 도메인의 구성원으로 제한되는 전역 그룹을 사용하여 구현되며, 때로는 서로 다른 도메인의 구성원을 허용하는 유니버설 그룹으로 보완됩니다.
다음 다이어그램은 다중 도메인 Active Directory 환경에서 일반적으로 사용되는 중첩 패턴을 보여줍니다.
Cloud ID와 Google Workspace의 그룹
Cloud ID와 Google Workspace에는 한 가지 그룹 유형만 있습니다. Cloud ID와 Google Workspace의 그룹은 자신이 정의되어 있는 Cloud ID 또는 Google Workspace 계정의 범위로 국한되지 않습니다. 대신 이러한 그룹은 다른 Cloud ID 또는 Google Workspace 계정의 사용자를 포함하고, 다른 Cloud ID 계정에서 참조되고 중첩되는 것을 지원하고, 모든 Google Cloud 조직에서 사용될 수 있습니다.
사용자와 마찬가지로 Cloud ID와 Google Workspace는 이메일 주소로 그룹을 식별합니다. 이메일 주소는 실제 편지함과 일치할 필요는 없지만 각 Cloud ID 계정에 등록된 도메인 중 하나를 사용해야 합니다.
Active Directory 그룹과 달리 Cloud ID 또는 Google Workspace 그룹의 구성원에게는 동일한 그룹의 다른 구성원을 나열할 수 있는 권한이 암시적으로 부여되지 않습니다. 대신 그룹 멤버십을 쿼리하려면 일반적으로 명시적인 승인이 필요합니다.
Google Cloud에서의 그룹 사용
Google Cloud는 ACL 기반의 액세스 모델 대신 역할 기반의 액세스 모델을 사용합니다. 역할은 특정 범위 내에 속하는 특정한 유형의 모든 리소스에 적용됩니다. 예를 들어 Kubernetes Engine 개발자 역할은 주어진 프로젝트의 모든 클러스터에서 Kubernetes API 객체에 대한 전체 액세스 권한을 갖습니다. 역할의 특성 때문에 Google Cloud에서 리소스 그룹을 유지할 필요가 거의 없으며 리소스 그룹을 Google Cloud에 동기화할 필요도 거의 없습니다.
역할 그룹과 조직 그룹은 많은 사용자의 액세스 권한을 관리하기 쉽게 만들기 때문에 Active Directory에서와 마찬가지로 Google Cloud에서도 유용합니다. 역할과 조직 그룹을 동기화하면 Active Directory를 액세스 관리를 위한 기본 위치로 설정하는 데 도움이 됩니다.
리소스 그룹을 도메인 로컬 그룹으로 지속적으로 구현하고 역할 그룹과 조직 그룹을 전역 그룹 또는 유니버설 그룹으로 구현하는 경우, 그룹 유형을 사용하여 역할 그룹과 조직 그룹만 동기화되도록 할 수 있습니다.
다중 도메인 포리스트에 단일 GCDS 인스턴스를 실행하면 충분할지, 아니면 여러 GCDS 인스턴스가 필요한지 여부에 대한 질문은 전역 그룹을 사용하는지 여부에 대한 질문이 됩니다. 유니버설 그룹을 사용하여 모든 역할 및 조직 그룹을 구현하는 경우 단일 GCDS 인스턴스로 충분합니다. 그렇지 않으면 도메인별로 GCDS 인스턴스가 필요합니다.
그룹 ID 매핑
Active Directory 보안 그룹을 Cloud ID 또는 Google Workspace 그룹에 매핑하려면 공통 식별자가 필요합니다. Cloud ID와 Google Workspace에서 이러한 식별자는 도메인 부분이 Cloud ID 또는 Google Workspace 계정의 기본, 보조 또는 별칭 도메인에 해당하는 이메일 주소여야 합니다. 이 이메일 주소는 Google Cloud 전체에서 사용되므로 사람이 읽을 수 있는 주소여야 합니다. 이메일 주소는 사서함에 해당할 필요가 없습니다.
Active Directory에서 그룹은 일반 이름(cn) 또는 Windows 2000 이전의 로그온 이름(sAMAccountName)으로 식별됩니다. 사용자 계정과 마찬가지로 그룹에도 이메일 주소(mail)가 있을 수 있지만, 이메일 주소는 그룹의 선택적 속성이며 Active Directory는 고유성을 확인하지 않습니다.
Active Directory와 Cloud ID 또는 Google Workspace 간에 그룹 ID를 매핑하는 두 가지 옵션이 있습니다.
일반 이름으로 매핑
일반 이름(cn)을 사용하면 사용 가능성이 보장되고 최소한 조직 단위 내에서 고유하다는 장점이 있습니다. 그러나 일반 이름은 이메일 주소가 아니므로 이메일 주소로 변환하려면 서픽스 @DOMAIN을 추가해야 합니다.
그룹 이름에 서픽스를 자동으로 추가하도록 GCDS를 구성할 수 있습니다. Active Directory는 그룹 이름과 사용자 이름이 충돌하지 않도록 하므로 이 방법으로 파생된 이메일 주소도 충돌을 일으키지 않습니다.
Active Directory 포리스트에 도메인이 두 개 이상 포함되어 있으면 다음과 같은 사항에 주의해야 합니다.
- 서로 다른 도메인의 두 그룹이 공통의 이름을 공유하는 경우, 파생된 이메일 주소가 충돌하여 동기화 중에 한 그룹이 무시됩니다.
- 단일 포리스트의 도메인에 있는 그룹만 동기화할 수 있습니다. 별도의 GCDS 인스턴스를 사용하여 여러 포리스트의 그룹을 동기화하는 경우 공통 이름에서 파생된 이메일 주소는 어느 포리스트에 해당하는지를 나타내지 않습니다. 이러한 모호성으로 인해 GCDS 인스턴스가 이전에 다른 GCDS 인스턴스에 의해 다른 포리스트에서 생성된 그룹을 삭제하게 됩니다.
- 사용자를 매핑하는 데 도메인 대체를 사용하면 일반 이름으로 그룹을 매핑할 수 없습니다.
이메일 주소로 매핑
이메일 주소(mail)를 사용하여 사용자를 매핑하면 이메일 주소를 사용하여 계정 ID를 매핑할 때와 동일한 기준을 충족해야 합니다.
이메일 할당을 완료해야 합니다. 배포 그룹에 이메일 주소가 있는 것이 일반적이지만 보안 그룹에는 이 특성이 부족한 경우가 많습니다. ID를 매핑하는 데 이메일 주소를 사용하려면 동기화 대상인 보안 그룹에
mail필드가 채워져 있어야 합니다. 다음 PowerShell 명령어를 사용하면 이 필드가 채워지지 않은 계정을 쉽게 찾을 수 있습니다.Get-ADGroup -LDAPFilter "(!mail=*)"
이메일 주소가 모두 사용자가 소유한 선별된 도메인 집합을 사용해야 합니다. 일부 사용자가 파트너 회사 또는 소비자 이메일 제공자를 가리키는 이메일 주소를 사용하는 경우 이러한 이메일 주소를 사용할 수 없습니다.
포리스트에서 모든 이메일 주소가 고유해야 합니다. Active Directory는 고유성을 적용하지 않으므로 커스텀 검사 또는 정책을 구현해야 할 수도 있습니다.
모든 관련 그룹이 이러한 기준을 충족하면 이러한 이메일 주소에서 사용되는 모든 도메인을 식별하여 Cloud ID 또는 Google Workspace에 등록된 DNS 도메인의 목록에 이러한 도메인이 포함되는지 확인할 수 있습니다.
조건 중 하나가 충족되지 않더라도 여전히 UPN을 Cloud ID 또는 Google Workspace 이메일 주소에 매핑할 수 있지만 다음과 같은 사항에 주의해야 합니다.
- 동기화 중에 이메일 주소가 없는 그룹은 무시되며, Cloud ID 또는 Google Workspace 계정과 연결되지 않은 도메인을 사용하는 이메일 주소도 무시됩니다.
- 두 그룹이 동일한 이메일 주소를 공유하면 하나의 그룹만 동기화됩니다.
Active Directory 포리스트에 두 개 이상의 도메인이 있고 사용자를 매핑하는 데 도메인 대체를 사용하는 경우 이메일 주소를 사용한 그룹 매핑이 지원되지 않습니다.
조직 단위 매핑
대부분의 Active Directory 도메인은 조직 단위를 광범위하게 사용하여 리소스를 계층적으로 클러스터링 및 구성하고, 액세스를 제어하고, 정책을 적용합니다.
Google Cloud 조직에서 관리되는 리소스의 종류는 Active Directory에서 관리되는 리소스와 크게 다르지만, Google Cloud에서 폴더와 프로젝트는 유사한 목적을 수행합니다. 따라서 기업에 적합한 Google Cloud 폴더 계층 구조는 Active Directory의 조직 단위의 구조와 크게 다른 경향이 있습니다. 그러므로 조직 단위를 자동으로 폴더 및 프로젝트에 매핑하기는 거의 불가능하며 GCDS에서 지원되지 않습니다.
폴더와 관련이 없는 Cloud ID와 Google Workspace는 조직 단위의 개념을 지원합니다. 조직 단위는 Active Directory와 유사하게 사용자를 클러스터링하고 구성하기 위해 생성됩니다. 하지만 Active Directory와 달리 조직 단위는 그룹이 아니라 사용자에만 적용됩니다.
GCDS는 Active Directory 조직 단위를 Cloud ID 또는 Google Workspace와 동기화하는 옵션을 제공합니다. Cloud ID가 Active Directory ID 관리를 Google Cloud로 확장하는 데 거의 사용되지 않는 설정에서는 조직 단위 매핑이 일반적으로 필요하지 않습니다.
올바른 매핑 선택
이 문서의 앞부분에서 설명한 것처럼 Active Directory와 Google Cloud의 구조를 매핑하는 최선의 방법은 없습니다. 시나리오에 적합한 매핑을 선택하는 데 도움을 주기 위해 다음 결정 그래프에 이전 섹션에서 설명한 기준이 요약되어 있습니다.
먼저 다음 차트를 참조하여 필요한 Cloud ID 또는 Google Workspace 계정, GCDS 인스턴스, AD FS 인스턴스 또는 플릿의 개수를 확인하세요.
그런 다음 두 번째 차트를 참조하여 Cloud ID 또는 Google Workspace 계정에서 구성할 도메인을 확인하세요.
다음 단계
- 계정 및 조직 계획을 위한 권장사항과 Google Cloud와 외부 ID 공급업체의 페더레이션을 위한 권장사항 읽어보기
- Active Directory 사용자 및 그룹을 Cloud ID와 동기화하도록 GCDS 구성
- Active Directory와 Google Cloud 간에 싱글 사인온(SSO) 구성
- 최고 관리자 계정의 관리를 위한 권장사항 읽어보기