Google Cloud Platform과 Active Directory의 페더레이션: 소개

이 기사는 기존 Active Directory 기반의 ID 관리 솔루션을 Google Cloud Platform(GCP)으로 확장하는 방법을 설명하는 기사 시리즈의 첫 번째입니다. 이 기사에서는 하이브리드 컴퓨팅 환경에서 일관성 있는 인증 및 승인 메커니즘을 설정하는 방법에 대해 설명합니다. 이 문서에서는 Cloud ID 사용 방법을 중점적으로 설명하지만 일부 G Suite에 해당되는 내용도 있습니다.

시리즈는 다음과 같은 부분으로 구성됩니다.

기업의 IT 부서에서는 흔히 Active Directory를 사용하여 사용자 계정을 관리하고 애플리케이션 및 컴퓨팅 리소스에 대한 액세스를 제어합니다. 이러한 신뢰성 때문에 Active Directory는 IT 환경과 온프레미스 인프라의 기반이 되었습니다.

하이브리드 전략의 일환으로 기존 IT 환경을 GCP로 확장할 때는 ID를 관리하는 단일 지점을 유지해야 합니다. 단일 ID 관리 솔루션을 사용하면 관리 작업이 최소화되고 사용자와 애플리케이션이 하이브리드 환경에서 안전하게 인증됩니다.

이 기사에서는 Active Directory와 GCP의 논리 구조를 비교하고, 페더레이션을 구현하기 위해 Active Directory 계정을 GCP의 사용자 및 그룹 계정에 매핑하는 여러 가지 방법을 설명합니다. 기사의 끝부분에 있는 순서도는 사용자의 시나리오에 맞게 Active Directory와 GCP 간의 매핑을 위한 최선의 방법을 결정하는 데 도움이 됩니다.

이 기사에서는 사용자가 Active Directory에 대해 잘 알고 있다고 가정합니다.

페더레이션 구현

GCP는 인증 및 액세스 관리에 Google ID를 사용합니다. GCP 리소스에 액세스하려면 직원에게 Google ID가 있어야 합니다. 모든 직원이 Active Directory에 계정을 가지고 있는 경우 각 직원의 Google ID를 수동으로 유지관리하려면 번거로울 수 있습니다. Active Directory와 GCP 간에 사용자 ID를 페더레이션하면 Google 계정의 유지관리를 자동화하고 계정의 수명 주기를 Active Directory의 계정과 연결할 수 있습니다. 페더레이션을 사용하면 다음과 같이 할 수 있습니다.

  • Active Directory가 ID 관리를 위한 단일 정보 출처가 됩니다.
  • Active Directory의 모든 사용자 계정 또는 선택된 일부 사용자 계정에 대한 Google 사용자 계정이 자동으로 생성됩니다.
  • 계정이 Active Directory에서 사용 중지되거나 삭제되면 해당 Google 계정도 일시정지되거나 삭제됩니다. 반면에 Google 계정을 일시정지하거나 삭제하면 다음 동기화 시 Google 계정이 자동으로 다시 생성되므로 Active Directory에 아무런 영향을 미치지 않습니다.
  • Active Directory에서 사용자 인증을 처리하므로 비밀번호를 GCP와 동기화할 필요가 없습니다.

Google 측에서는 Cloud ID를 사용하여 Google 계정을 만들고 관리할 개인 사용자 계정 디렉토리를 설정할 수 있습니다. Active Directory를 Cloud ID와 페더레이션하려면 두 가지 조건이 필요합니다.

Active Directory와 Cloud ID 페더레이션

  • 계정 동기화: 관련 사용자 계정과 그룹이 Active Directory에서 Cloud ID로 주기적으로 동기화됩니다. 이 프로세스를 사용할 경우 Active Directory에서 새 계정을 만들면 연결된 사용자가 처음으로 로그인하기 전에도 GCP에서 이 계정을 참조할 수 있습니다. 이 프로세스는 또한 계정 삭제가 전파되도록 합니다.

    동기화는 한 방향으로 이루어지므로 Active Directory에서의 변경사항이 Cloud ID로 복제되지만 반대 방향으로는 복제되지 않습니다. 또한 동기화에는 비밀번호가 포함되지 않습니다. 페더레이션된 설정에서 Active Directory는 이러한 사용자 인증 정보를 관리하는 유일한 시스템으로 유지됩니다.

  • 싱글 사인온(SSO): 사용자가 GCP에서 인증해야 할 때마다 Cloud ID는 보안 보장 마크업 언어(SAML) 프로토콜을 사용하여 인증을 Active Directory에 위임합니다. 이러한 위임을 통해 Active Directory에서만 사용자 인증 정보를 관리하게 되고, 적용 가능한 정책 또는 다단계 인증(MFA) 메커니즘이 적용됩니다. 하지만 로그인이 성공하려면 해당 계정이 이미 동기화되어 있어야 합니다.

페더레이션을 구현하려면 다음 도구를 사용하세요.

  • Google 클라우드 디렉토리 동기화는 동기화 프로세스를 구현하는 도구로서 Google에서 무료로 제공합니다. 클라우드 디렉토리 동기화는 보안 소켓 레이어(SSL)를 통해 Google Identity Platform과 통신하며 일반적으로 기존 컴퓨팅 환경에서 실행됩니다.
  • AD FS(Active Directory Federation Service)는 Windows Server의 일부로서 Microsoft에서 제공합니다. AD FS를 사용하면 페더레이션된 인증에 Active Directory를 사용할 수 있습니다. AD FS는 일반적으로 기존 컴퓨팅 환경 내에서 실행됩니다.

Google Identity Platform용 API는 공개적으로 사용 가능하며 SAML은 개방형 표준이므로 여러 도구를 사용하여 페더레이션을 구현할 수 있습니다. 이 기사는 클라우드 디렉토리 동기화와 AD FS의 사용에 중점을 둡니다.

Active Directory의 논리적 구조

Active Directory 인프라에서 최상위 구성 요소는 포리스트입니다. 포리스트는 하나 이상의 도메인에 대한 컨테이너 역할을 하고 포리스트 루트 도메인에서 이름을 가져옵니다. Active Directory 포리스트 내의 도메인은 서로 신뢰하므로 한 도메인에서 인증된 사용자가 다른 도메인에 있는 리소스에 액세스할 수 있습니다. 포리스트가 포리스트 간 트러스트를 사용하여 연결되어 있지 않으면 개별 포리스트는 기본적으로 서로 신뢰하지 않으며, 한 포리스트에서 인증된 사용자가 다른 포리스트에 있는 리소스에 액세스할 수 없습니다.

Active Directory 인프라

Active Directory 도메인은 리소스 관리를 위한 컨테이너이며 관리 경계로 간주됩니다. 하나의 포리스트에 여러 도메인을 포함하는 것은 관리를 간소화하거나 추가 구조를 적용하기 위한 방법의 하나지만, 포리스트의 도메인은 보안 경계를 나타내지 않습니다.

GCP의 논리적 구조

GCP에서는 조직의 리소스를 관리할 수 있으며, 폴더와 프로젝트를 사용하여 세분화를 더 상세하게 수행할 수 있습니다. 따라서 조직, 폴더, 프로젝트는 Active Directory 도메인과 비슷한 역할을 합니다.

Active Directory는 사용자 계정을 리소스로 취급하므로 사용자 계정 관리와 인증이 도메인과 연결됩니다. 반면에 GCP는 서비스 계정을 제외하고 조직의 사용자 계정을 관리하지 않습니다. 대신 GCP는 Cloud ID 또는 G Suite를 통해 사용자 계정을 관리합니다.

Cloud ID를 사용하면 사용자 계정 및 그룹의 비공개 디렉토리를 만들고 관리할 수 있습니다. 이러한 디렉토리는 각각 독립적으로 관리되므로, 예를 들어 디렉토리에서 허용되는 인증 방법 또는 적용되는 비밀번호 정책이 서로 다를 수 있습니다. Cloud ID에서는 디렉토리를 Cloud ID 계정이라고 하며 도메인 이름으로 식별합니다.

GCP ID 인프라

포리스트와 포리스트 루트 도메인이 항상 Active Directory에서 서로 연결되어 생성되는 것처럼, Cloud ID 계정은 항상 GCP 조직과 병행하여 생성됩니다. 또한 포리스트 루트 도메인과 포리스트가 같은 이름을 공유하고 서로 분리할 수 없는 것과 마찬가지로, Cloud ID 계정과 GCP 조직도 같은 이름을 공유하고 서로 연결되어 있습니다. 하지만 GCP 조직은 추가 Cloud ID 계정에서 사용자와 그룹을 참조할 수 있습니다.

Active Directory와 GCP 통합

Active Directory와 GCP의 논리적 구조 간의 유사성에도 불구하고, 두 구조 간의 매핑이 모든 시나리오에서 동일하게 작동하는 경우는 하나도 없습니다. 대신 두 시스템을 통합하고 구조를 매핑하는 적절한 방식은 여러 요소에 따라 달라집니다.

  • 도메인과 포리스트를 Cloud ID 계정에 매핑하는 방법
  • DNS 도메인을 매핑하는 방법
  • 사용자 계정을 매핑하는 방법
  • 그룹을 매핑하는 방법

다음 섹션에서는 이러한 각 요소에 대해 설명합니다.

포리스트 매핑

특히 대규모 조직에서는 전사적으로 ID와 액세스를 관리하기 위해 둘 이상의 Active Directory 도메인을 사용하는 경우가 많습니다. Active Directory와 GCP를 페더레이션하려는 경우 가장 먼저 고려할 사항은 Active Directory 인프라의 토폴로지입니다.

단일 포리스트, 단일 도메인

단일 포리스트, 단일 도메인

하나의 포리스트에 도메인이 하나만 있으면 전체 Active Directory 포리스트를 단일 Cloud ID 계정에 매핑할 수 있습니다. 그러면 이 계정이 GCP 리소스를 관리하는 데 사용할 수 있는 단일 GCP 조직의 기반이 됩니다.

단일 도메인 환경에서 도메인 컨트롤러와 전역 카탈로그 서버는 모두 Active Directory에서 관리되는 모든 객체에 대한 액세스를 제공합니다. 대부분의 경우 Cloud Directory Sync의 단일 인스턴스를 실행하여 사용자 계정과 그룹을 GCP에 동기화하고 단일 AD FS 인스턴스 또는 플릿이 싱글 사인온(SSO)을 처리하도록 설정할 수 있습니다.

단일 포리스트, 다중 도메인

단일 포리스트, 다중 도메인

하나의 포리스트에 여러 Active Directory 도메인이 포함되어 있으면 이를 하나의 또는 여러 개의 도메인 트리로 구성할 수 있습니다. 두 가지 경우 모두 포리스트 전체를 단일 Cloud ID 계정에 매핑할 수 있습니다. 그러면 이 계정이 GCP 리소스를 관리하는 데 사용할 수 있는 단일 GCP 조직의 기반이 됩니다.

다중 도메인 환경에서는 도메인 컨트롤러에서 검색할 수 있는 정보와 전역 카탈로그 서버에서 쿼리할 수 있는 정보에 차이가 있습니다. 도메인 컨트롤러는 로컬 도메인의 데이터만 제공하지만 전역 카탈로그 서버는 포리스트의 모든 도메인의 정보에 대한 액세스를 제공합니다. 결정적으로 전역 카탈로그 서버에서 제공하는 데이터는 부분적이며 일부 LDAP 속성이 누락되어 있습니다. 이러한 제한은 그룹을 동기화하도록 클라우드 디렉토리 동기화를 구성하는 방법에 영향을 미칠 수 있습니다.

사용자가 그룹을 매핑하는 방법에 따라 다중 도메인 포리스트를 GCP와 페더레이션하는 데 하나 이상의 클라우드 디렉토리 동기화 인스턴스가 필요하지만, 싱글 사인온(SSO)을 처리하는 데는 하나의 AD FS 인스턴스 또는 플릿만 필요합니다.

포리스트 간 트러스트가 있는 다중 포리스트

포리스트 간 트러스트가 있는 다중 포리스트

대규모 조직에서는 종종 합병이나 인수의 결과로 Active Directory 포리스트가 두 개 이상 존재하는 경우가 많습니다. 사용자가 단일 포리스트의 경계를 초월하여 리소스를 공유하고 액세스할 수 있도록 양방향 포리스트 간 트러스트를 사용하여 이러한 포리스트를 결합할 수 있습니다.

모든 포리스트가 다른 포리스트와 서로 양방향 트러스트 관계이면 전체 환경을 단일 Cloud ID 계정에 매핑할 수 있습니다. 이 계정은 GCP 리소스를 관리하는 데 사용할 수 있는 단일 GCP 조직의 기반이 됩니다.

전역 카탈로그 서버는 여러 도메인의 데이터에 대한 액세스를 제공하지만 범위가 단일 포리스트로 제한됩니다. 따라서 다중 포리스트 환경에서 예를 들어 사용자 계정의 전체 목록을 가져오려면 여러 도메인 컨트롤러 또는 전역 카탈로그 서버를 쿼리해야 합니다. 이러한 제한으로 인해 다중 포리스트 환경과 GCP를 페더레이션하려면 포리스트마다 하나 이상의 클라우드 디렉토리 동기화 인스턴스가 필요합니다. 포리스트 간 트러스트는 사용자 인증이 포리스트 경계를 초월하여 작동하게 해주므로 단일 AD FS 인스턴스 또는 플릿으로도 싱글 사인온(SSO)을 처리할 수 있습니다.

환경에 포리스트 간 트러스트가 없는 다중 포리스트가 포함되어 있지만 GCP와의 페더레이션과 관련된 모든 Active Directory 도메인이 외부 트러스트를 통해 연결되어 있으면 동일한 고려 사항이 적용됩니다.

포리스트 간 트러스트가 없는 다중 포리스트

포리스트 간 트러스트가 없는 다중 포리스트

이 그림의 환경에서는 포리스트 경계를 초월하여 리소스를 인증하거나 리소스에 액세스할 수 없습니다. 또한 단일 AD FS 인스턴스 또는 플릿이 모든 포리스트의 사용자에 대해 싱글 사인온(SSO) 요청을 처리하는 것도 불가능합니다.

따라서 포리스트 간 트러스트가 없는 여러 포리스트를 단일 Cloud ID 계정에 매핑할 수 없습니다. 대신 각 포리스트가 별개의 Cloud ID 계정에 매핑되어야 하며, 이 계정은 하나 이상의 클라우드 디렉토리 동기화 인스턴스와 포리스트당 하나의 AD FS 서버 또는 플릿을 실행해야 합니다.

GCP에서는 Cloud ID 계정별로 별도의 조직이 생성됩니다. 대부분의 경우에는 별도의 여러 조직을 관리할 필요가 없습니다. 조직 중에서 하나를 선택하고 이를 다른 Cloud ID 계정과 연결하면 여러 Active Directory 포리스트와 페더레이션된 조직을 효과적으로 만들 수 있습니다. 다른 조직들은 사용되지 않는 상태로 남아 있습니다.

DNS 도메인 매핑

DNS는 Active Directory와 Cloud ID에서 모두 중요한 역할을 합니다. Active Directory와 GCP를 페더레이션하려고 계획할 때 고려할 두 번째 요소는 Active Directory와 GCP 간에 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 도메인과 중복되거나, 완전히 다른 도메인일 수 있습니다.

GCP에서의 DNS 도메인 사용

GCP가 인증을 위해 사용하는 Google Identity Platform은 이메일 주소를 사용하여 사용자를 식별합니다. 이메일 주소를 사용하면 이 주소가 전역적으로 고유함을 보장할 뿐만 아니라 GCP에서 이 주소로 알림 메시지를 전송할 수 있습니다.

Google Identity Platform은 이메일 주소에서 @ 뒤에 있는 도메인 부분을 기반으로 사용자를 인증하는 데 사용되는 디렉토리 또는 ID 공급업체를 결정합니다. 예를 들어 gmail.com 도메인을 사용하는 이메일의 경우 Google Identity Platform은 인증에 Gmail 사용자 계정의 디렉토리를 사용합니다.

GCP에서 DNS 도메인 사용

G Suite 또는 Cloud ID 계정에 가입하면 기본적으로 Google Identity Platform에서 인증에 사용할 수 있는 비공개 디렉터리가 생성됩니다. Gmail 디렉토리가 gmail.com 도메인과 연결되어 있는 것과 같은 방식으로 G Suite 및 Cloud ID 계정을 커스텀 도메인과 연결해야 합니다. 세 가지 종류의 도메인을 사용할 수 있습니다.

  • 기본 도메인: 이 도메인은 Cloud ID 디렉토리를 식별하며 GCP에서 조직의 이름으로도 사용됩니다. Cloud ID에 가입할 때 이 도메인 이름을 지정해야 합니다.
  • 보조 도메인: 기본 도메인과 함께 추가 보조 도메인을 Clod ID 디렉토리와 연결할 수 있습니다. 디렉토리의 각 계정은 기본 도메인과 또는 보조 도메인 중 하나와 연결됩니다. 따라서 example.com이 기본 도메인이고 secondary.example.com이 디렉토리의 보조 도메인이면 두 개의 계정 johndoe@example.comjohndoe@secondary.example.com이 별도의 계정으로 간주됩니다.
  • 별칭 도메인: 별칭 도메인은 기본 도메인의 대체 도메인입니다. 즉, alias.example.com이 별칭 도메인으로 설정된 경우 johndoe@example.comjohndoe@alias.example.com이 동일한 계정을 참조합니다. 별칭 도메인은 기본 도메인의 대체 이름만 제공할 수 있습니다. 보조 도메인에는 별칭 도메인을 추가할 수 없습니다.

모든 도메인은 다음 요구 사항을 충족해야 합니다.

  • 유효한 전역 DNS 도메인 이름이어야 합니다. Active Directory에서 일반적으로 사용되는 corp.local 또는 corp.internal과 같은 로컬 도메인 이름은 사용할 수 없습니다. 설정 중에 도메인 소유권을 확인하기 위해 각 DNS 영역에 대한 관리 액세스가 필요할 수 있습니다.
  • example.com과 같은 도메인은 단일 디렉토리만 참조할 수 있습니다. 하지만 다른 하위 도메인(예: subdomain.example.com)을 사용하여 다른 디렉토리를 참조할 수 있습니다.
  • 기본 및 보조 도메인에는 유효한 MX 레코드가 있어야 합니다. 그러면 이 도메인 이름을 사용하여 형성된 이메일 주소로 보내는 메시지를 제대로 전송할 수 있습니다.

디렉토리 간에 동기화를 설정하려면 Active Directory 도메인과 Cloud ID에서 사용하는 도메인 간에 매핑이 필요합니다. 적절한 매핑을 결정하는 방법은 Active Directory를 사용하는 방법에 따라 다르며, 사용자 계정이 Active Directory 포리스트에서 식별되는 방법과 Cloud ID에 매핑되는 방법을 상세히 고려해야 합니다.

사용자 계정 매핑

Active Directory와 GCP를 페더레이션하려고 계획할 때 고려할 세 번째 요소는 Active Directory와 Cloud ID 간에 사용자 계정을 매핑하는 방법입니다.

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\user 형식(예: corp\johndoe)으로 NetBIOS 도메인 이름과 사용자 이름을 결합하여 사용합니다. 이 이름은 레거시로 간주되지만 여전히 일반적으로 사용되며 사용자 계정의 유일한 필수 식별자입니다.

특히 Active Directory는 사용자를 식별하는 데 사용자의 이메일 주소(mail)를 사용하지 않습니다. 따라서 이 필드는 필수가 아니며 포리스트에서 고유할 필요도 없습니다.

이러한 식별자는 언제든지 변경할 수 있습니다.

계정 ID 매핑

Active Directory 계정을 Cloud ID 계정에 매핑하려면 각 사용자 계정에 두 가지 정보가 필요합니다.

  • 동기화 중에 어떤 Active Directory 계정이 어떤 Cloud ID 계정에 해당하는지를 추적하기 위해 사용할 수 있는 안정적인 고유한 ID. AD 측에서는 objectGUID가 이 목적에 완벽하게 부합합니다.
  • 도메인 부분이 Cloud ID 기본, 보조 또는 별칭 도메인에 해당하는 이메일 주소. 이 이메일 주소는 GCP 전체에서 사용되므로 주소가 의미가 있는지 확인하세요. objectGUID에서 주소를 파생시키는 방법은 자동으로 생성되는 다른 이메일 주소와 마찬가지로 비실용적입니다.

Active Directory 사용자 계정에서 userPrincipalNamemail이라는 두 가지 필드는 Cloud ID 이메일 주소를 제공하기 위한 조합입니다.

사용자 기본 이름으로 매핑

userPrincipalName 필드를 사용하려면 동기화 대상인 모든 계정에 대해 두 가지 기준이 충족되어야 합니다.

  • UPN이 유효한 이메일 주소여야 합니다. 또한 UPN 서픽스 도메인으로 사용되는 모든 도메인은 MX 도메인이어야 하며, 사용자의 UPN으로 전송된 이메일이 해당 이메일 받은편지함으로 전송되도록 설정되어야 합니다.
  • UPN 할당이 완료되어야 합니다. 동기화 대상인 모든 사용자 계정에 UPN이 할당되어 있어야 합니다. 다음 PowerShell 명령어를 사용하면 UPN이 없는 계정을 쉽게 찾을 수 있습니다.

    Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

이 두 가지 기준이 충족되면 UPN을 Cloud ID 이메일 주소에 안전하게 매핑할 수 있습니다. UPN 서픽스 도메인 중 하나를 Cloud ID의 기본 도메인으로 사용하고 다른 UPN 서픽스 도메인을 보조 도메인으로 추가할 수 있습니다.

조건 중 하나가 충족되지 않더라도 UPN을 Cloud ID 이메일 주소에 매핑할 수 있지만, 다음과 같은 사항에 주의해야 합니다.

  • UPN이 유효한 이메일 주소가 아닌 경우 사용자가 GCP에서 보낸 알림 이메일을 받지 못할 수 있습니다. 이로 인해 사용자가 중요한 정보를 놓칠 수 있습니다.
  • UPN이 없는 계정은 동기화 중에 무시됩니다.
  • 동기화를 구성하여 UPN 서픽스 도메인을 다른 도메인으로 바꿀 수 있습니다. 하나의 포리스트에서 여러 UPN 서픽스 도메인을 사용하는 경우, 모든 UPN 서픽스 도메인이 단일 도메인으로 대체되므로 이 방식을 사용하면 중복이 생성될 수 있습니다. 중복이 있는 경우 하나의 계정만 동기화할 수 있습니다.

UPN을 사용하여 사용자를 매핑하는 경우의 주요 이점은 포리스트 전체에서 UPN이 고유하다는 점이 보장되고, 도메인의 선별된 집합을 사용하여 잠재적인 동기화 문제를 방지하는 데 도움이 된다는 점입니다.

이메일 주소로 매핑

mail 필드를 사용하려면 동기화할 모든 계정에 대해 다음 기준이 충족되어야 합니다.

  • 이메일 할당이 완료되어야 합니다. 동기화 대상인 모든 사용자 계정에 mail 필드가 채워져 있어야 합니다. 다음 PowerShell 명령어를 사용하면 이 필드가 채워지지 않은 계정을 쉽게 찾을 수 있습니다.

    Get-ADUser -LDAPFilter "(!mail=*)"
  • 이메일 주소가 모두 사용자가 소유한 선별된 도메인 집합을 사용해야 합니다. 일부 계정이 파트너 회사 또는 소비자 이메일 제공자를 가리키는 이메일 주소를 사용하는 경우 이러한 이메일 주소를 사용할 수 없습니다.

  • 포리스트에서 모든 이메일 주소가 고유해야 합니다. Active Directory는 고유성을 적용하지 않으므로 커스텀 검사 또는 정책을 구현해야 할 수도 있습니다.

모든 관련 계정이 이러한 기준을 충족하면 이러한 이메일 주소에서 사용되는 모든 도메인을 식별하여 Cloud ID에서 기본 도메인과 보조 도메인으로 사용할 수 있습니다.

조건 중 하나가 충족되지 않더라도 여전히 이메일 주소를 Cloud ID 이메일 주소에 매핑할 수 있지만 다음 사항에 주의해야 합니다.

  • 동기화 중에 이메일 주소가 없는 계정은 무시되며 Cloud ID 디렉터리와 연결되지 않은 도메인을 사용하는 이메일 주소가 있는 계정도 무시됩니다.
  • 두 계정이 동일한 이메일 주소를 공유하면 하나의 계정만 동기화됩니다.
  • 동기화를 구성하여 이메일 주소의 도메인을 다른 도메인으로 바꿀 수 있습니다. 이 프로세스에서 중복을 만들 수 있으며, 이 경우 하나의 계정만 동기화됩니다.

그룹 매핑

Active Directory와 GCP를 페더레이션하려고 계획할 때 고려할 네 번째 요소는 Active Directory와 GCP 간에 그룹을 동기화할지 여부와 이를 매핑하는 방법입니다.

GCP에서 그룹은 일반적으로 여러 프로젝트에서 액세스를 효율적으로 관리하는 방법으로 사용됩니다. 각 프로젝트에서 개별 사용자를 Cloud Identity and Access Management(Cloud IAM) 역할에 할당하는 대신, 조직에서 일반적인 역할을 모델링하는 그룹의 집합을 정의한 다음 이러한 그룹을 Cloud IAM 역할의 집합에 할당합니다. 그룹의 멤버십을 수정하여 리소스의 전체 집합에 대한 사용자의 액세스를 제어할 수 있습니다.

Active Directory는 두 종류의 그룹, 즉 배포 그룹과 보안 그룹을 구분합니다. 배포 그룹은 이메일 목록을 관리하는 데 사용됩니다. Microsoft에서 G Suite로 마이그레이션하는 경우에 배포 그룹을 동기화하면 클라우드 디렉토리 동기화에서 일반 배포 그룹과 동적 배포 그룹을 모두 처리할 수 있으므로 유용합니다. 배포 그룹은 GCP의 ID 및 액세스 관리에서 문제가 되지 않습니다. 따라서 이 설명에서는 보안 그룹에만 중점을 둡니다.

Active Directory와 GCP 간에 보안 그룹을 매핑하는 것은 선택사항입니다. 사용자 계정이 페더레이션되면 Cloud ID에서 직접 그룹을 만들고 관리할 수 있습니다. 즉 Active Directory가 액세스 관리가 아닌 ID 관리의 중앙 시스템으로 유지됩니다. Active Directory를 ID 관리 및 액세스 관리를 위한 중앙 시스템으로 유지하려면 보안 그룹을 Cloud ID에서 관리하는 대신 Active Directory에서 동기화하는 것이 좋습니다. 이 방법을 사용하면 Active Directory의 그룹 멤버십을 사용하여 GCP의 특정 리소스에 액세스할 수 있는 사용자를 제어할 수 있도록 Cloud IAM을 설정할 수 있습니다.

Active Directory의 보안 그룹

보안 그룹은 Windows 보안 및 Active Directory 액세스 관리에서 근본적인 역할을 합니다. 이 역할은 Active Directory 그룹의 세 가지 유형인 도메인 로컬 그룹, 전역 그룹, 유니버설 그룹에 의해 지원됩니다.

AD의 보안 그룹

도메인 로컬 그룹
이 그룹은 단일 도메인의 범위 내에서만 관련이 있으며 다른 도메인에서 참조될 수 없습니다. 구성원의 목록을 포리스트에서 복제할 필요가 없기 때문에 포함할 수 있는 구성원의 유형과 관련하여 도메인 로컬 그룹이 가장 유연합니다.
전역 그룹
이 그룹은 다른 도메인에 표시되고 다른 도메인에서 참조할 수 있습니다. 하지만 구성원 목록은 복제되지 않습니다. 이러한 제약으로 인해 이 그룹에 포함될 수 있는 구성원의 유형이 제한됩니다. 이 그룹에는 사용자 계정과 같은 도메인의 다른 전역 그룹만 포함될 수 있습니다.
유니버설 그룹
이 그룹은 구성원 목록과 함께 포리스트에서 복제됩니다. 따라서 다른 도메인에서 참조될 수 있으며 사용자 계정과 다른 유니버설 그룹뿐만 아니라 모든 도메인의 전역 그룹을 포함할 수 있습니다.

Active Directory 포리스트에 단일 도메인만 있으면 클라우드 디렉토리 동기화를 사용하여 세 가지 유형의 보안 그룹을 모두 동기화할 수 있습니다. Active Directory 포리스트에서 두 개 이상의 도메인을 사용하는 경우 그룹 유형에 따라 Cloud ID와 동기화할 수 있는지 여부 및 동기화 방법이 결정됩니다.

도메인 로컬 및 전역 그룹은 포리스트에서 완전히 복제되지 않으므로 전역 카탈로그 서버에는 이러한 그룹에 대한 불완전한 정보가 포함됩니다. 이러한 제한은 의도적이며 디렉토리 복제 속도를 높이는 데 도움이 되지만, 이러한 그룹을 Cloud ID와 동기화하려는 경우에는 장애가 됩니다. 특히 전역 카탈로그 서버를 소스로 사용하도록 클라우드 디렉토리 동기화를 구성하면 이 도구는 포리스트의 모든 도메인에서 그룹을 찾을 수 있습니다. 하지만 전역 카탈로그 서버와 동일한 도메인에 있는 그룹만 구성원 목록을 포함하며 복제에 적합합니다. 다중 도메인 포리스트의 도메인 로컬 또는 전역 그룹을 동기화하려면 도메인별로 별도의 클라우드 디렉토리 동기화 인스턴스를 실행해야 합니다.

유니버설 그룹은 포리스트에서 완전히 복제되기 때문에 이러한 제한이 없습니다. 단일 클라우드 디렉토리 동기화 인스턴스가 여러 도메인의 유니버설 그룹을 동기화할 수 있습니다.

여러 Active Directory 도메인을 Cloud ID와 동기화하기 위해 여러 개의 클라우드 디렉토리 동기화 인스턴스가 필요하다고 결론을 내리기 전에, 모든 그룹을 동기화할 필요가 없을 수도 있다는 점을 기억하세요. 이러한 이유로, Active Directory 포리스트에서 서로 다른 유형의 보안 그룹이 일반적으로 사용되는 방식을 살펴볼 필요가 있습니다.

Active Directory에서의 보안 그룹 사용

리소스 그룹

Windows는 액세스 제어 목록(ACL)을 기반으로 하는 액세스 모델을 사용합니다. 파일 또는 LDAP 객체와 같은 각 리소스에는 액세스할 수 있는 사용자를 제어하는 ACL이 연결되어 있습니다. 리소스와 ACL은 매우 세분화되어 있으므로 많은 수가 존재합니다. ACL의 유지관리를 간소화하기 위해 자주 사용되고 함께 액세스되는 리소스를 번들로 묶는 리소스 그룹을 만드는 것이 일반적입니다. 리소스 그룹을 영향을 받는 모든 ACL에 한꺼번에 추가하고, ACL을 변경하는 대신 리소스 그룹의 멤버십을 변경하여 추가 액세스를 관리합니다.

이러한 방식으로 번들로 묶이는 리소스는 일반적으로 단일 도메인에 있습니다. 따라서 리소스 그룹은 ACL에서든 또는 다른 리소스 그룹에 의해서든 단일 도메인에서만 참조되는 경향이 있습니다. 대부분의 리소스 그룹이 로컬이므로 리소스 그룹은 일반적으로 Active Directory에서 도메인 로컬 그룹을 사용하여 구현됩니다.

역할 및 조직 그룹

리소스 그룹은 액세스 관리를 간소화하는 데 유용하지만, 대규모 환경에서 많은 수의 리소스 그룹에 새로운 사용자를 추가해야 할 수도 있습니다. 이러한 이유로, 리소스 그룹은 일반적으로 역할 그룹 또는 조직 그룹으로 보완됩니다.

역할 그룹은 조직에서 특정 역할에 필요한 권한을 집계합니다. 예를 들어 이름이 '엔지니어링 문서 뷰어'인 역할 그룹은 구성원에게 모든 엔지니어링 문서에 대한 읽기 전용 액세스 권한을 부여합니다. 실제로는 역할 그룹을 생성한 다음 이 그룹을 다양한 종류의 문서에 대한 액세스를 제어하는 데 사용되는 모든 리소스 그룹의 구성원으로 만들어서 이러한 기능을 구현합니다.

비슷한 방식으로, 조직 그룹은 조직 내의 부서에서 필요로 하는 권한을 집계합니다. 예를 들어 이름이 '엔지니어링'인 조직 그룹은 엔지니어링 부서의 구성원이 일반적으로 필요로 하는 모든 리소스에 대한 액세스 권한을 부여합니다.

기술적으로 역할 그룹과 리소스 그룹 간에는 차이가 없으며 두 그룹은 일반적으로 함께 사용됩니다. 하지만 리소스 그룹과 달리 역할 그룹과 조직 그룹은 도메인의 경계를 초월하는 관련성을 가질 수 있습니다. 이러한 그룹을 다른 도메인의 리소스 그룹에서 참조할 수 있도록 하기 위해 일반적으로 역할 그룹과 조직 그룹은 단일 도메인의 구성원으로 제한되는 전역 그룹을 사용하여 구현되며, 때로는 서로 다른 도메인의 구성원을 허용하는 유니버설 그룹으로 보완됩니다.

다음 다이어그램은 다중 도메인 Active Directory 환경에서 일반적으로 사용되는 중첩 패턴을 보여줍니다.

다중 도메인 AD 환경에서 사용되는 중첩 패턴

Cloud ID의 그룹

Cloud ID에는 단일 유형의 그룹만 존재하며, 이는 Active Directory의 유니버설 그룹과 유사하게 작동합니다. 즉 그룹이 자신이 정의되어 있는 Cloud ID 계정의 범위로 국한되지 않습니다. 대신 그룹은 서로 다른 Cloud ID 계정의 사용자 계정을 포함할 수 있습니다. 이러한 그룹은 다른 Cloud ID 계정에서 참조되고 중첩되는 것을 지원하며, 모든 GCP 조직에서 사용될 수 있습니다.

Active Directory 그룹과 달리 Cloud ID 그룹의 구성원에게는 동일한 그룹의 다른 구성원을 나열할 수 있는 권한이 암시적으로 부여되지 않습니다. 대신 그룹 멤버십을 쿼리하려면 일반적으로 명시적인 승인이 필요합니다.

GCP에서의 그룹 사용

GCP는 ACL 기반의 액세스 모델 대신 역할 기반의 액세스 모델을 사용합니다. 역할은 특정 범위 내에 속하는 특정한 유형의 모든 리소스에 적용됩니다. 예를 들어 Kubernetes Engine 개발자 역할은 주어진 프로젝트의 모든 클러스터에서 Kubernetes API 객체에 대한 전체 액세스 권한을 갖습니다. 역할의 특성 때문에 GCP에서 리소스 그룹을 유지관리할 필요가 거의 없으며 리소스 그룹을 GCP에 동기화할 필요도 거의 없습니다.

역할 그룹과 조직 그룹은 많은 사용자의 액세스 권한을 관리하기 쉽게 만들기 때문에 Active Directory에서와 마찬가지로 GCP에서도 유용합니다. 역할과 조직 그룹을 동기화하면 Active Directory를 액세스 관리를 위한 기본 위치로 설정하는 데 도움이 됩니다.

역할 및 조직 그룹 동기화

리소스 그룹을 도메인 로컬 그룹으로 지속적으로 구현하고 역할 그룹과 조직 그룹을 전역 그룹 또는 유니버설 그룹으로 구현하는 경우, 그룹 유형을 사용하여 역할 그룹과 조직 그룹만 동기화되도록 할 수 있습니다.

다중 도메인 포리스트마다 하나의 클라우드 디렉토리 동기화 인스턴스를 실행하는 것으로 충분한지 아니면 여러 클라우드 디렉토리 동기화 인스턴스가 필요한지의 문제는 곧 전역 그룹을 사용하는지 여부의 문제입니다. 유니버설 그룹을 사용하여 모든 역할 그룹과 조직 그룹을 구현하는 경우에는 단일 클라우드 디렉토리 동기화 인스턴스로 충분하지만, 그렇지 않으면 도메인마다 하나의 클라우드 디렉토리 동기화 인스턴스가 필요합니다.

그룹 ID 매핑

Active Directory 보안 그룹을 Cloud ID 그룹에 매핑하려면 공통 식별자가 필요합니다. Cloud ID에서 이러한 식별자는 도메인 부분이 Cloud ID의 기본, 보조 또는 별칭 도메인에 해당하는 이메일 주소여야 합니다. 이러한 이메일 주소는 GCP 전체에서 사용되므로 사람이 읽을 수 있는 주소여야 합니다. 이메일 주소는 사서함에 해당할 필요가 없습니다.

Active Directory에서 그룹은 일반 이름(cn) 또는 Windows 2000 이전의 로그온 이름(sAMAccountName)으로 식별됩니다. 사용자 계정과 마찬가지로 그룹도 이메일 주소(mail)를 가질 수 있지만 이메일 주소는 그룹의 선택적 속성이며 Active Directory는 고유성을 확인하지 않습니다.

Active Directory와 Cloud ID간에 그룹 ID를 매핑하는 두 가지 옵션이 있습니다.

일반 이름으로 매핑

일반 이름(cn)을 사용하면 사용 가능성이 보장되고 최소한 조직 단위 내에서 고유하다는 장점이 있습니다. 그러나 일반 이름은 이메일 주소가 아니므로 이메일 주소로 변환하려면 서픽스 @[DOMAIN]을 추가해야 합니다.

그룹 이름에 서픽스를 자동으로 추가하도록 클라우드 디렉토리 동기화를 구성할 수 있습니다. Active Directory는 그룹 이름과 사용자 계정 이름이 충돌하지 않도록 하므로, 이 방법으로 파생된 이메일 주소도 충돌을 일으키지 않습니다.

Active Directory 포리스트에 도메인이 두 개 이상 포함되어 있으면 다음과 같은 사항에 주의해야 합니다.

  • 서로 다른 도메인의 두 그룹이 공통의 이름을 공유하는 경우, 파생된 이메일 주소가 충돌하여 동기화 중에 한 그룹이 무시됩니다.
  • 단일 포리스트의 도메인에 있는 그룹만 동기화할 수 있습니다. 별도의 클라우드 디렉토리 동기화 인스턴스를 사용하여 여러 포리스트의 그룹을 동기화하는 경우, 공통 이름에서 파생된 이메일 주소는 어느 포리스트에 해당하는지를 나타내지 않습니다. 이러한 모호성으로 인해 클라우드 디렉토리 동기화 인스턴스가 이전에 다른 클라우드 디렉토리 동기화 인스턴스에 의해 다른 포리스트에서 생성된 그룹을 삭제하게 됩니다.
  • 사용자 계정을 매핑하는 데 도메인 대체를 사용하면 일반 이름으로 그룹을 매핑할 수 없습니다.

이메일 주소로 매핑

이메일 주소(mail)를 사용하여 그룹 ID를 매핑하면 이메일 주소를 사용하여 계정 ID를 매핑할 때와 동일한 기준을 충족해야 합니다.

  • 이메일 할당이 완료되어야 합니다. 배포 그룹에 이메일 주소가 있는 것이 일반적이지만 보안 그룹에는 이 특성이 부족한 경우가 많습니다. ID를 매핑하는 데 이메일 주소를 사용하려면 동기화 대상 보안 그룹에 mail 필드가 있어야 합니다. 다음 PowerShell 명령어를 사용하면 이 필드가 채워지지 않은 계정을 쉽게 찾을 수 있습니다.

    Get-ADGroup -LDAPFilter "(!mail=*)"
  • 이메일 주소가 모두 사용자가 소유한 선별된 도메인 집합을 사용해야 합니다. 일부 계정이 파트너 회사 또는 소비자 이메일 제공자를 가리키는 이메일 주소를 사용하는 경우 이러한 이메일 주소를 사용할 수 없습니다.

  • 모든 이메일 계정이 포리스트에서 고유해야 합니다. Active Directory는 고유성을 적용하지 않으므로 커스텀 검사 또는 정책을 구현해야 할 수도 있습니다.

모든 관련 그룹이 이러한 기준을 충족하면 이러한 이메일 주소에서 사용되는 모든 도메인을 식별하여 Cloud ID에 등록된 DNS 도메인의 목록에 이러한 도메인이 포함되는지 확인할 수 있습니다.

조건 중 하나가 충족되지 않더라도 UPN을 Cloud ID 이메일 주소에 매핑할 수 있지만 다음 사항에 주의해야 합니다.

  • 동기화 중에 이메일 주소가 없는 그룹은 무시되며, Cloud ID 디렉토리와 연결되지 않은 도메인을 사용하는 이메일 주소도 무시됩니다.
  • 두 그룹이 동일한 이메일 주소를 공유하면 하나의 그룹만 동기화됩니다.

Active Directory 포리스트에 두 개 이상의 도메인이 있고 사용자 계정을 매핑하는 데 도메인 대체를 사용하는 경우 이메일 주소를 사용한 그룹 매핑이 지원되지 않습니다.

조직 단위 매핑

대부분의 Active Directory 도메인은 조직 단위를 광범위하게 사용하여 리소스를 계층적으로 클러스터링 및 구성하고, 액세스를 제어하고, 정책을 적용합니다.

GCP 조직에서 관리되는 리소스의 종류는 Active Directory에서 관리되는 리소스와 크게 다르지만, GCP에서 폴더와 프로젝트는 유사한 목적을 수행합니다. 따라서 기업에 적합한 GCP 폴더 계층 구조는 Active Directory의 조직 단위의 구조와 크게 다른 경향이 있습니다. 그러므로 조직 단위를 자동으로 폴더 및 프로젝트에 매핑하기는 거의 불가능하며 클라우드 디렉토리 동기화에서 지원되지 않습니다.

폴더와 관련이 없는 Cloud ID는 조직 단위의 개념을 지원합니다. 조직 단위는 Active Directory와 유사하게 사용자 계정을 클러스터링하고 구성하기 위해 생성됩니다. 하지만 Active Directory와 달리 조직 단위는 그룹이 아니라 사용자 계정에만 적용됩니다.

클라우드 디렉토리 동기화는 Active Directory 조직 단위를 Cloud ID 조직 단위와 동기화하는 옵션을 제공합니다. Cloud ID가 Active Directory ID 관리를 GCP로 확장하는 데 거의 사용되지 않는 설정에서는 조직 단위 매핑이 일반적으로 필요하지 않습니다.

올바른 매핑 선택하기

이 기사의 시작 부분에서 언급했듯이, Active Directory와 GCP의 구조를 매핑하는 단 하나의 최선의 방법은 없습니다. 시나리오에 적합한 매핑을 선택하는 데 도움을 주기 위해 다음 결정 그래프에 이전 섹션에서 설명한 기준이 요약되어 있습니다.

먼저 다음 차트를 참조하여 필요한 Cloud ID 계정, 클라우드 디렉토리 동기화 인스턴스, AD FS 인스턴스 또는 플릿의 개수를 확인하세요.

필요한 플릿 또는 인스턴스의 수를 결정하기 위한 결정 그래프

그런 다음 두 번째 차트를 참조하여 Cloud ID 계정에서 구성할 도메인을 확인하세요.

Cloud ID에서 구성할 도메인을 식별하기 위한 결정 그래프

다음 단계