이 문서에서는 Microsoft Entra ID(이전의 Azure AD)를 IdP 및 ID의 소스로 사용하기 위해 Cloud ID 또는 Google Workspace를 구성하는 방법을 설명합니다.
이 문서에서는 Microsoft Entra ID의 논리적 구조를 Cloud ID 및 Google Workspace에서 사용하는 구조와 비교하고 Microsoft Entra ID 테넌트, 도메인, 사용자, 그룹을 매핑하는 방법을 설명합니다.
페더레이션 구현
Google Cloud는 인증 및 액세스 관리를 위해 Google ID를 사용합니다. 모든 직원이 이미 Microsoft Entra ID에 계정을 가지고 있는 경우 각 직원의 Google ID를 수동으로 유지관리하면 불필요한 관리 오버헤드가 추가될 수 있습니다. Google Cloud와 기존 ID 관리 시스템 간에 사용자 ID를 페더레이션하면 Google ID의 유지보수를 자동화하고 ID의 수명 주기를 Microsoft Entra ID의 기존 사용자와 연결할 수 있습니다.
Microsoft Entra ID와 Cloud ID 또는 Google Workspace 간의 페더레이션을 설정하려면 다음 두 가지가 필요합니다.
사용자 프로비저닝: 관련 사용자와 그룹이 Microsoft Entra ID에서 Cloud ID 또는 Google Workspace로 주기적으로 동기화됩니다. 이 프로세스를 사용할 경우 Microsoft Entra ID에서 새 사용자를 만들거나 Active Directory에서 Microsoft Entra ID로 새 사용자를 동기화할 때 Google Cloud에서도 이 사용자를 사용할 수 있으므로 연결된 사용자가 최초 로그인하기 전이라도 Google Cloud에서 이 사용자를 참조할 수 있습니다. 또한 이 프로세스를 통해 사용자 삭제가 전파됩니다.
프로비저닝은 한 방향으로 이루어지므로 Microsoft Entra ID에서의 변경사항이 Google Cloud로 복제되지만 반대의 방향으로는 복제되지 않습니다. 또한 프로비저닝에는 비밀번호가 포함되지 않습니다.
싱글 사인온(SSO): 사용자가 인증해야 할 때마다 Google Cloud는 보안 보장 마크업 언어(SAML) 프로토콜을 사용하여 인증을 Microsoft Entra ID에 위임합니다. Microsoft Entra ID 구성에 따라 Microsoft Entra ID는 다음 중 하나를 수행합니다.
- 자체 인증 수행
- 통과 인증 또는 비밀번호 해시 동기화 사용
- 온프레미스 AD FS 서버에 인증 위임
Cloud ID 또는 Google Workspace에서 Microsoft Entra ID로 인증을 위임하면 비밀번호를 Google Cloud에 동기화할 필요가 없고 Microsoft Entra ID 또는 AD FS에서 구성한 모든 관련 정책 또는 다중 인증(MFA) 메커니즘도 적용됩니다.
Microsoft Entra ID의 논리적 구조
Azure를 사용하는 경우 디렉터리라고도 하는 Microsoft Entra ID 테넌트를 하나 이상 사용합니다. Microsoft Entra ID 테넌트는 최상위 구조입니다. 이 테넌트는 관리 경계로 간주되며 사용자, 그룹, 리소스, 리소스 그룹을 위한 컨테이너 역할을 합니다.
각 Microsoft Entra ID 테넌트에는 연결된 DNS 도메인이 하나 이상 있습니다. 이 DNS 도메인은 사용자 기본 이름 또는 UPN이라고 하는 사용자 이름에 반영되며 name@domain과 같은 형식을 사용합니다. 여기서 domain은 해당 테넌트와 연결된 DNS 도메인 중 하나입니다.
기업에서 Microsoft Entra ID 테넌트를 여러 개 유지하는 경우도 있습니다. 테넌트를 여러 개 유지보수하는 일반적인 이유에는 조직의 여러 부서를 구별하고, 프로덕션 리소스를 개발 및 테스트 리소스와 분리하고, 온프레미스 Active Directory의 여러 포리스트를 통합하기 위해 별도의 테넌트를 사용하는 것 등이 있습니다.
Google Cloud의 논리적 구조
Google Cloud에서 조직은 모든 리소스의 컨테이너 역할을 하며 폴더와 프로젝트를 사용하여 상세하게 세분화할 수 있습니다. 하지만 서비스 계정을 제외하고 사용자와 그룹을 관리하는 데 조직이 사용되지 않는다는 점에서 Microsoft Entra ID 테넌트와 다릅니다.
사용자와 그룹을 관리하기 위해 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 계정에서 사용자와 그룹을 참조할 수 있습니다.
Microsoft Entra ID와 Google Cloud 통합
Microsoft Entra ID와 Google Cloud의 논리적 구조 사이에는 유사점이 있지만 두 구조 사이의 매핑이 모든 시나리오에서 동일하게 작동하는 경우는 하나도 없습니다. 대신 두 시스템을 통합하고 구조를 매핑하는 적절한 방식은 여러 요소에 따라 달라집니다.
- Microsoft Entra ID 테넌트를 Cloud ID 또는 Google Workspace 계정에 매핑하는 방법
- DNS 도메인을 매핑하는 방법
- 사용자를 매핑하는 방법
- 그룹을 매핑하는 방법
다음 섹션에서는 이러한 각 요소에 대해 설명합니다.
Google Cloud는 온프레미스 Active Directory가 아닌 Microsoft Entra ID와만 상호작용합니다. 따라서 온프레미스 Active Directory의 포레스트와 도메인을 Microsoft Entra ID에 매핑한 방식은 중요하지 않습니다.
Microsoft Entra ID 테넌트 매핑
다음 섹션에서는 이러한 시나리오에서 Microsoft Entra ID 테넌트를 매핑하는 방법을 설명합니다.
단일 테넌트
Microsoft Entra ID 테넌트를 하나만 사용하는 경우 이 테넌트를 단일 Cloud ID 또는 Google Workspace 계정에 매핑하고 둘 사이에 페더레이션을 설정할 수 있습니다. 그러면 이 Cloud ID 또는 Google Workspace 계정이 모든 Google Cloud 리소스를 관리하는 데 사용할 수 있는 단일 Google Cloud 조직의 기반이 됩니다.
여러 테넌트
대규모 조직에서는 Microsoft Entra ID 테넌트가 2개 이상 있는 경우가 드물지 않습니다. 테스트 환경과 프로덕션 환경을 구별하거나 조직의 다른 부서를 구별하는 데 여러 테넌트를 사용할 수 있습니다.
여러 Microsoft Entra ID 테넌트를 단일 Cloud ID 또는 Google Workspace 계정에 매핑하고 그에 따라 사용자 프로비저닝 및 싱글 사인온(SSO)을 설정할 수 있습니다. 하지만 이러한 N:1 매핑은 Microsoft Entra ID 테넌트 간의 격리를 약화시킬 수 있습니다. 여러 Microsoft Entra ID 테넌트에 단일 Cloud ID 또는 Google Workspace 계정에서 사용자를 만들고 수정할 수 있는 권한을 부여하면 이러한 테넌트가 서로의 변경사항을 방해하고 변조할 수 있습니다.
일반적으로 여러 Microsoft Entra ID 테넌트와 통합하는 더 나은 방법은 각 테넌트에 대해 Cloud ID 또는 Google Workspace 계정을 별도로 만들고 각 쌍 사이에 페더레이션을 설정하는 것입니다.
Google Cloud에서는 Cloud ID 또는 Google Workspace 계정별로 별도의 조직이 생성됩니다. Google Cloud는 단일 조직 내 프로젝트 및 폴더를 사용하여 리소스를 구성할 수 있으므로 조직이 둘 이상이 되면 실용적이지 않은 경우가 많습니다. 하지만 조직 중에서 하나를 선택하고 이를 다른 Cloud ID 또는 Google Workspace 계정과 연결하면 여러 Active Directory 포리스트와 페더레이션된 조직을 효과적으로 만들 수 있습니다. 다른 조직은 사용되지 않는 상태로 유지됩니다.
외부 사용자
Microsoft Entra ID B2B를 사용하면 외부 사용자를 Microsoft Entra ID 테넌트에 게스트로 초대할 수 있습니다. 각 게스트별로 새 사용자가 생성되며 Microsoft Entra ID는 게스트 사용자에게 자동으로 UPN을 할당합니다. Microsoft Entra ID가 생성하는 UPN에는 prefix#EXT#@tenant.onmicrosoft.com과 같이 초대 대상자의 이메일 주소에서 파생된 프리픽스가 테넌트의 초기 도메인과 결합되어 사용됩니다.
Microsoft Entra ID에서 Cloud ID 또는 Google Workspace로 게스트 사용자를 프로비저닝할 때 다음 제한사항이 적용됩니다.
onmicrosoft.com은 Cloud ID 또는 Google Workspace에서 추가하고 확인할 수 없는 도메인이기 때문에 Cloud ID 또는 Google Workspace의 이메일 주소에 게스트 사용자의 UPN을 매핑할 수 없습니다. 따라서 UPN 외의 속성을 사용하여 사용자를 매핑해야 합니다.- 게스트 사용자가 홈 테넌트에서 정지되면 Cloud ID 또는 Google Workspace의 해당 사용자가 활성 상태로 유지되며 Google Cloud 리소스에 대한 액세스가 제대로 취소되지 않을 수도 있습니다.
다른 Microsoft Entra ID 테넌트에서 시작된 게스트 사용자를 처리하는 더 좋은 방법은 이전 섹션에 설명된 대로 서로 다른 Microsoft Entra ID 테넌트로 페더레이션된 여러 Cloud ID 또는 Google Workspace 계정을 만드는 것입니다. 자세한 내용은 Microsoft Entra ID B2B 사용자 프로비저닝 및 싱글 사인온(SSO)을 참고하세요.
외부 사용자에게 특정 Google Cloud 리소스에 대한 액세스 권한을 부여하기 위해 사용자가 Cloud ID 또는 Google Workspace에 사용자 계정을 만들 필요는 없습니다. 정책에서 제한하지 않는 한, 사용자에게 Google ID가 있는 경우 각 프로젝트, 폴더 또는 조직에 구성원으로 외부 사용자를 직접 추가할 수 있습니다.
DNS 도메인 매핑
DNS는 Microsoft Entra ID와 Cloud ID 및 Google Workspace에서 모두 중요한 역할을 합니다. Microsoft Entra ID와 Google Cloud를 페더레이션할 때 고려할 두 번째 요소는 Microsoft Entra ID와 Google Cloud 간에 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 레코드가 있어야 합니다.
Microsoft Entra ID에서 DNS 도메인 사용
Cloud ID 및 Google Workspace가 DNS를 사용하는 방식은 Microsoft Entra ID가 DNS를 사용하여 Microsoft Entra ID 테넌트를 구별하고 사용자 이름을 테넌트에 연결하는 방법과 비슷합니다. 다음 두 가지 주요 차이점에 유의하세요.
초기 도메인: Microsoft Entra ID 테넌트를 만들면 테넌트는
onmicrosoft.com의 하위 도메인인 초기 도메인과 연결됩니다. 이 도메인은 도메인을 소유하지 않고 각 DNS 영역에 대한 관리 액세스 권한이 없다는 점에서 등록할 수 있는 커스텀 도메인 이름과 다릅니다.Cloud ID에는 초기 도메인에 상응하는 도메인이 없으며 대신에 사용자가 Cloud ID 계정과 연결된 모든 도메인을 소유해야 합니다. 다시 말해
onmicrosoft.com하위 도메인을 Cloud ID 도메인으로 등록할 수 없습니다.사용자 식별자에 사용된 도메인: Microsoft Entra ID는 이메일 주소 MOERA(Microsoft Online Email Routing Addresses)와 UPN을 구별합니다. 둘 다 RFC 822 형식(
user@domain)을 따르지만 다른 용도로 사용됩니다. UPN은 사용자 식별과 로그인 양식에 사용되고 MOERA는 이메일 전송에만 사용됩니다.UPN에서 사용하는 도메인 서픽스는 Microsoft Entra ID 테넌트의 등록된 도메인 중 하나와 일치해야 합니다. 이메일 주소에는 이 요구사항이 적용되지 않습니다.
Cloud ID와 Google Workspace는 UPN의 개념을 활용하지 않고 사용자의 이메일 주소를 식별자로 사용합니다. 따라서 이메일 주소에서 사용하는 도메인은 Cloud ID 또는 Google Workspace 계정의 등록된 도메인 중 하나와 일치해야 합니다.
Microsoft Entra ID 테넌트와 Cloud ID 또는 Google Workspace 계정은 동일한 DNS 도메인을 사용할 수 있습니다. 동일한 도메인을 사용할 수 없는 경우 도메인 이름 대신 사용자 프로비저닝과 싱글 사인온(SSO)을 구성할 수 있습니다.
위에 설명된 두 가지 차이점을 고려하여 Microsoft Entra ID와 Cloud ID 또는 Google Workspace 간에 사용자를 매핑하는 방법을 기반으로 도메인을 매핑해야 합니다.
Map users(사용자 매핑)
Microsoft Entra ID와 Google Cloud를 페더레이션하려는 경우 고려할 세 번째 요소는 Microsoft Entra ID와 Cloud ID 또는 Google Workspace 간에 사용자를 매핑하는 방법입니다.
Microsoft Entra ID 사용자를 Cloud ID 또는 Google Workspace의 사용자에 성공적으로 매핑하려면 각 사용자에 다음 두 가지 정보가 필요합니다.
- 어떤 Microsoft Entra ID 사용자가 Cloud ID 또는 Google Workspace의 어떤 사용자에 해당하는지를 추적하기 위해 동기화 중에 사용할 수 있는 안정적인 고유한 ID
- 도메인 부분이 Cloud ID 기본, 보조 또는 별칭 도메인에 해당하는 이메일 주소 이 이메일 주소는 Google Cloud 전체에서 사용되므로 사람이 읽을 수 있는 주소여야 합니다.
내부에서 Microsoft Entra ID는 ObjectId로 사용자를 식별하는데, 이는 임의로 생성되며 전역적으로 고유한 ID입니다. 이 ID는 안정적이므로 첫 번째 요구사항을 충족하지만 사람에게는 의미가 없으며 이메일 주소 형식을 따르지 않습니다. UPN 또는 이메일 주소로 매핑하는 것이 사용자를 매핑하는 유일한 실질적인 방법입니다.
사용자가 Microsoft Entra ID로 싱글 사인온(SSO)을 사용하도록 구성된 Cloud ID 또는 Google Workspace 계정에 속하는 이메일 주소를 입력하면 Microsoft Entra ID 로그인 화면으로 사용자가 리디렉션됩니다.
Microsoft Entra ID는 이메일 주소가 아닌 UPN을 사용하여 사용자를 식별하므로 로그인 화면에 UPN을 입력하라는 메시지가 표시됩니다.
Microsoft Entra ID 테넌트가 로그인에 AD FS를 사용하도록 구성된 경우 사용자가 AD FS 로그인 화면으로 리디렉션됩니다. AD FS는 Active Directory UPN 또는 Windows 2000 이전의 로그인 이름(domain\user)으로 사용자를 식별할 수 있습니다.
Cloud ID 또는 Google Workspace에 사용된 이메일 주소, Microsoft Entra ID에 사용된 UPN, Active Directory에 사용된 UPN이 모두 다른 경우 최종 사용자는 로그인 화면 순서를 혼동할 수 있습니다. 반면에 식별자 세 가지가 모두 스크린샷 예시(johndoe@example.com)와 같은 경우 UPN과 이메일 주소의 차이점이 드러나지 않으므로 사용자가 크게 혼동하지 않을 것입니다.
UPN으로 매핑
사용자 환경에서 보자면 Microsoft Entra ID UPN을 Cloud ID 또는 Google Workspace 이메일 주소에 매핑하는 것이 가장 좋은 방법일 수 있습니다. UPN을 사용할 경우 또 다른 이점은 Microsoft Entra ID가 고유성을 보장하므로 이름이 충돌될 위험이 없다는 점입니다.
하지만 Microsoft Entra ID UPN을 Cloud ID 이메일 주소에 매핑하려면 다음 요구사항을 충족해야 합니다.
- Google Cloud에서 보낸 모든 알림 이메일이 사용자의 편지함에 올바르게 전송되도록 Microsoft Entra ID UPN이 유효한 이메일 주소여야 합니다. 아직 그렇지 않다면 사용자가 알림 이메일을 받을 수 있도록 별칭 이메일 주소를 구성할 수 있습니다.
- Microsoft Entra ID에서 관련된 모든 사용자의 UPN은 커스텀 도메인을 서픽스로 사용해야 합니다(
user@custom-domain). Microsoft Entra ID 초기 도메인을 사용하는 UPN(user@tenant.onmicrosoft.com)은 Cloud ID의 이메일 주소에 매핑할 수 없습니다. 초기 도메인은 사용자가 아닌 Microsoft에서 소유하기 때문입니다. - Microsoft Entra ID가 UPN에 사용하는 모든 커스텀 도메인은 Cloud ID에도 등록되어야 합니다. 다시 말해 각 DNS 영역에 대한 액세스 권한이 있어야 도메인 유효성 검사를 수행할 수 있다는 뜻입니다.
Microsoft Entra ID에서 도메인 소유권을 확인하기 위해 만든 기존
TXTDNS 레코드를 재정의하지 않으려면CNAME레코드를 사용하여 Cloud ID에서 도메인 소유권을 확인할 수 있습니다.
이메일 주소로 사용자 매핑
Microsoft Entra ID UPN을 Cloud ID 또는 Google Workspace 이메일 주소에 매핑할 수 없다면 이메일 주소로 사용자를 매핑할 수 있습니다.
Active Directory에서 이메일 주소를 지정하면 각 user 객체의 mail 속성에 저장되고 Microsoft Entra ID Connect는 값을 Microsoft Entra ID의 Mail 속성에 동기화합니다. Microsoft Entra ID는 사용자 프로비저닝에 이 속성을 사용 가능하도록 하기 때문에 Cloud ID 또는 cloudid_name_short의 이메일 주소에 속성을 매핑할 수 있습니다.
결정적으로 Microsoft Entra ID Mail 속성은 현재 Azure 포털에 표시되지 않으므로 API 또는 PowerShell을 통해서만 보고 편집할 수 있습니다. 사용자 인터페이스를 사용하여 이메일 주소와 보조 이메일 주소를 지정할 수 있더라도 이 두 값 모두 Mail 속성에 저장되지 않아 Cloud ID 또는 cloudid_name_short에 프로비저닝하는 데 사용할 수 없습니다.
따라서 이메일 주소로 사용자 매핑은 Microsoft Entra ID가 아닌 Active Directory에서 대부분의 사용자 생성과 편집을 수행하는 경우에만 실용적입니다.
이메일 주소로 사용자를 매핑하려면 다음 추가 요구사항을 충족해야 합니다.
- 이메일 할당을 완료해야 합니다. 동기화 대상인 모든 사용자는 이메일 주소가 할당되어야 합니다. 특히 온프레미스 Active Directory에서 사용자를 동기화할 경우
mail이 Active Directory의 선택사항 사용자 속성이므로 이메일 주소가 할당되지 않을 수 있습니다. Microsoft Entra IDMail속성에 이메일 주소가 없는 사용자는 동기화 중 자동으로 무시됩니다. - 이메일 주소는 Microsoft Entra ID 테넌트 전체에서 고유해야 합니다. Active Directory는 사용자 생성 시 고유성을 확인하지 않지만, Microsoft Entra ID Connect는 기본적으로 충돌을 감지하며 이로 인해 영향을 받는 사용자의 동기화가 실패할 수 있습니다.
- 이메일 주소에서 사용하는 도메인은 Microsoft Entra ID에 등록할 필요가 없지만 Cloud ID 또는 Google Workspace에 등록되어 있어야 합니다. 다시 말해 각 DNS 영역에 대한 액세스 권한이 있어야 도메인 유효성 검사를 수행할 수 있고
gmail.com과 같이 소유하지 않은 도메인이 포함된 이메일 주소 사용을 제외한다는 것을 뜻합니다.
사용자 수명 주기 매핑
Microsoft Entra ID 사용자와 Cloud ID 또는 Google Workspace 사용자 간의 매핑을 정의한 후에는 프로비저닝할 사용자 집합을 결정해야 합니다. 이 결정을 내리는 방법에 대한 안내는 ID 집합 매핑 권장사항을 참조하세요.
Microsoft Entra ID 테넌트의 모든 사용자를 프로비저닝하지 않으려면 사용자 할당 또는 범위 지정 필터를 사용하여 사용자의 하위 집합에 대해 프로비저닝을 사용 설정하면 됩니다.
다음 표는 Microsoft Entra ID 프로비저닝의 기본 동작을 요약하며 Cloud ID 또는 Google Workspace에서 Microsoft Entra ID가 수행할 작업을 사용자가 제어하도록 프로비저닝을 사용 설정 또는 중지하는 방법을 보여줍니다.
| Microsoft Entra ID 사용자에 대해 프로비저닝 사용 설정 | Cloud ID 또는 Google Workspace의 사용자 상태 | Microsoft Entra ID에서 수행된 작업 | Cloud ID 또는 Google Workspace에서 수행된 작업 |
|---|---|---|---|
| 아니요 | (존재하지 않음) | 프로비저닝 사용 설정 | 새 사용자 만들기(*) |
| 아니요 | 존재(활성) | 프로비저닝 사용 설정 | 기존 사용자 업데이트 |
| 아니요 | 존재(사용중지됨) | 프로비저닝 사용 설정 | 기존 사용자 업데이트, 정지 상태 유지 |
| 예 | 존재 | 사용자 수정 | 기존 사용자 업데이트 |
| 예 | 존재 | UPN/이메일 주소의 이름 바꾸기 | 기본 이메일 주소 변경, 이전 주소를 별칭으로 유지 |
| 예 | 존재 | 프로비저닝 사용 중지 | 사용자 그대로 유지 |
| 예 | 존재 | 사용자 소프트 삭제 | 사용자 사용중지 |
| 예 | 존재 | 사용자 영구 삭제 | 사용자 사용중지, 이메일 주소에 del_ 프리픽스 추가 |
(*) 동일한 이메일 주소를 가진 일반 계정이 있는 경우 일반 계정은 삭제됩니다.
그룹 매핑
Microsoft Entra ID와 Google Cloud를 페더레이션하려고 계획할 때 고려할 네 번째 요소는 Microsoft Entra ID와 Google Cloud 간에 그룹을 동기화할지 여부와 매핑하는 방법입니다.
Google Cloud에서 그룹은 일반적으로 여러 프로젝트에서 액세스를 효율적으로 관리하기 위해 사용됩니다. 각 프로젝트에서 개별 사용자를 IAM 역할에 할당하는 대신 조직에서 일반적인 역할을 모델링하는 그룹의 집합을 정의합니다. 이러한 그룹을 IAM 역할의 집합에 할당합니다. 그룹의 멤버십을 수정하여 리소스 전체 집합에 대한 사용자의 액세스를 제어할 수 있습니다.
Microsoft Entra ID와 Google Cloud 간에 그룹을 매핑하는 것은 선택사항입니다. 사용자 프로비저닝이 설정되면 Cloud ID 또는 Google Workspace에서 직접 그룹을 만들고 관리할 수 있습니다. 즉, Google Cloud 액세스 관리가 아닌 Active Directory 또는 Microsoft Entra ID가 ID 관리의 중앙 시스템으로 유지됩니다.
Active Directory 또는 Microsoft Entra ID를 ID 관리 및 액세스 관리를 위한 중앙 시스템으로 유지하려면 그룹을 Cloud ID 또는 Google Workspace에서 관리하는 대신 Microsoft Entra ID에서 동기화하는 것이 좋습니다. 이 방법을 사용하면 Active Directory 또는 Microsoft Entra ID에서 그룹 멤버십을 사용하도록 IAM을 설정하여 Google Cloud의 리소스에 액세스할 수 있는 사용자를 제어할 수 있습니다.
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 계정에 등록된 도메인 중 하나를 사용해야 합니다.
IAM에서 그룹을 사용할 때 이름이 아닌 이메일 주소로 그룹을 지정해야 하는 경우가 많습니다. 따라서 그룹에 의미 있는 이름뿐 아니라 의미 있고 인식 가능한 이메일 주소를 사용하는 것이 좋습니다.
Microsoft Entra ID의 그룹
Microsoft Entra ID는 다양한 사용 사례에 맞춰 여러 그룹 유형을 지원합니다. 그룹은 단일 테넌트로 범위가 지정되고 객체 ID로 식별됩니다. 이는 임의로 생성되며 전역적으로 고유한 ID입니다. 그룹은 중첩될 수 있으며 동일한 테넌트의 사용자 또는 Azure B2B를 사용하여 다른 테넌트에서 초대된 사용자를 포함할 수 있습니다. Microsoft Entra ID는 쿼리에 따라 구성원이 자동으로 결정되는 동적 그룹도 지원합니다.
Microsoft Entra ID를 Cloud ID 또는 Google Workspace와 통합하는 경우 그룹의 두 가지 속성, 즉 그룹에 메일이 사용 설정되었는지와 보안이 사용 설정되었는지가 중요한 사항입니다.
- 보안 사용 설정 그룹을 사용하여 Microsoft Entra ID의 리소스에 대한 액세스를 관리할 수 있습니다. 따라서 모든 보안 사용 설정 그룹은 Google Cloud 환경에서 잠재적으로 관련이 있습니다.
- 메일 사용 설정 그룹에는 관련된 이메일 주소가 있습니다. Cloud ID와 Google Workspace에서 그룹을 이메일 주소로 식별하기 때문입니다.
Microsoft Entra ID에서는 보안 또는 Office 365 유형 그룹(통합 그룹이라고도 함)을 만들 수 있습니다. 온프레미스 Active Directory의 그룹을 동기화하거나 Office 365 유형을 사용할 때 배포 목록 그룹 유형을 만들 수도 있습니다.
다음 표에는 그룹 종류(메일 사용 설정 또는 보안 사용 설정)에 따른 차이점과 Active Directory 그룹 유형에 매핑하는 방식이 요약되어 있습니다. 기본 Microsoft Entra ID Connect 구성을 사용한다고 가정합니다.
| 소스 | Active Directory 그룹 유형 | Microsoft Entra ID 그룹 유형 | 메일 사용 설정 | 보안 사용 설정 |
|---|---|---|---|---|
| Microsoft Entra ID | - | Office 365 그룹 | 항상 | 선택사항 |
| Microsoft Entra ID | - | 보안 그룹 | 선택사항 | 항상 |
| 온프레미스 | 보안 그룹(이메일 포함) | 보안 그룹 | 예 | 예 |
| 온프레미스 | 보안 그룹(이메일 없음) | 보안 그룹 | 아니요 | 예 |
| 온프레미스 | 배포 목록(이메일 포함) | 배포 목록 | 예 | 아니요 |
| 온프레미스 | 배포 목록(이메일 없음) | (Microsoft Entra ID Connect에서 무시) |
사용자와 달리 Microsoft Entra ID에서는 그룹에 할당된 이메일 주소에 Microsoft Entra ID에서 커스텀 도메인으로 등록된 도메인을 사용해야 합니다. 이 요구사항에 따라 다음과 같은 기본 동작이 실행됩니다.
- Active Directory의 그룹이 이전에 Microsoft Entra ID에 등록된 도메인을 사용하는 이메일 주소를 사용하면 이 이메일 주소는 Microsoft Entra ID에 동기화하는 동안 올바르게 유지됩니다.
- Active Directory의 그룹이 Microsoft Entra ID에 등록되지 않은 이메일 주소를 사용하면 Microsoft Entra ID는 동기화 중에 새 이메일 주소를 자동으로 생성합니다. 이 이메일 주소에는 테넌트의 기본 도메인이 사용됩니다. 테넌트가 초기 도메인을 기본 도메인으로 사용하면 결과적으로 이메일 주소는
[name]@[tenant].onmicrosoft.com과 같은 형태가 됩니다. - Microsoft Entra ID에서 Office 365 그룹을 만들면 Microsoft Entra ID도 테넌트의 기본 도메인을 사용하는 이메일 주소를 자동으로 생성합니다.
그룹 ID 매핑
Microsoft Entra ID 그룹을 Cloud ID 또는 Google Workspace 그룹에 성공적으로 매핑하려면 공통 식별자가 필요하며 이 식별자는 이메일 주소여야 합니다. 이 요구사항으로 Microsoft Entra ID에서 다음과 같은 2가지 옵션을 사용할 수 있습니다.
- Microsoft Entra ID에서 그룹의 이메일 주소를 사용하여 Cloud ID 또는 Google Workspace 이메일 주소에 매핑할 수 있습니다.
- Microsoft Entra ID의 그룹 이름에서 이메일 주소를 추출하고 Cloud ID 또는 Google Workspace의 이메일 주소에 가져온 주소를 매핑할 수 있습니다.
이메일 주소로 매핑
이메일 주소로 그룹을 매핑하는 것은 가장 확실한 방법이지만 몇 가지 요구사항을 충족해야 합니다.
- 동기화 대상인 모든 그룹에 이메일 주소가 있어야 합니다. 실제로 메일이 사용 설정된 그룹만 동기화할 수 있습니다. 이메일 주소가 없는 그룹은 프로비저닝 중 자동으로 무시됩니다.
- 이메일 주소는 테넌트 전체에서 고유해야 합니다. Microsoft Entra ID는 고유성을 적용하지 않으므로 커스텀 검사 또는 정책을 구현해야 할 수도 있습니다.
- 이메일 주소에 사용하는 도메인은 Microsoft Entra ID와 Cloud ID 또는 Google Workspace에 모두 등록되어 있어야 합니다.
tenant.onmicrosoft.com도메인을 포함하여 Cloud ID 또는 Google Workspace에 등록되지 않은 도메인을 사용하는 이메일 주소가 있는 그룹은 동기화되지 않습니다.
모든 관련 그룹이 이러한 기준을 충족하면 이러한 이메일 주소에서 사용되는 도메인을 식별하고 Cloud ID 또는 Google Workspace에 등록된 DNS 도메인의 목록에 이러한 도메인이 포함되는지 확인합니다.
이름으로 매핑
이메일 주소로 그룹을 매핑하는 데 필요한 기준을 충족하는 것은 어려울 수 있습니다. Cloud ID 또는 Google Workspace에 프로비저닝하려는 보안 그룹 중 상당수에 메일이 사용 설정되지 않은 경우에는 특히 더 어려울 수 있습니다. 이 경우에는 그룹의 표시 이름에서 이메일 주소를 자동으로 추출하는 것이 더 적합할 수 있습니다.
이메일 주소를 추출하는 데는 두 가지 문제점이 있습니다.
- 그룹 이름에서 추출된 이메일 주소가 사용자의 이메일 주소와 충돌할 수 있습니다.
- Microsoft Entra ID는 그룹 이름에 고유성을 적용하지 않습니다. Microsoft Entra ID 테넌트의 여러 그룹에서 같은 이름을 공유하면 이 이름에서 파생된 이메일 주소 간에 충돌이 발생하여 그룹 중 하나만 동기화될 수 있습니다.
첫 번째 문제점은 생성된 이메일 주소에 사용자가 사용하는 도메인과 다른 도메인을 사용하여 해결할 수 있습니다. 예를 들어 모든 사용자가 도메인이 example.com인 이메일 주소를 사용하는 경우 groups.example.com을 모든 그룹에 사용할 수 있습니다. Cloud ID 또는 Google Workspace에 하위 도메인을 등록할 때는 도메인 확인이 필요하지 않으므로 DNS 영역 groups.example.com은 존재할 필요도 없습니다.
두 번째 문제점인 중복된 그룹 이름은 기술적으로 객체 ID에서 그룹 이메일 주소를 추출하는 방법으로만 해결할 수 있습니다. 생성되는 그룹 이름은 상당히 복잡하고 사용하기 어려우므로 Microsoft Entra ID에서 중복된 그룹 이름을 식별하고 이름을 바꾼 다음 Cloud ID 또는 Google Workspace에 프로비저닝을 설정하는 것이 좋습니다.
그룹 수명 주기 매핑
Microsoft Entra ID 그룹과 Cloud ID 또는 Google Workspace 그룹 간의 매핑을 정의한 후에는 프로비저닝할 그룹 집합을 결정해야 합니다. 사용자와 마찬가지로 그룹 할당 또는 범위 지정 필터를 사용하여 그룹의 하위 집합에 대해 프로비저닝을 사용 설정할 수 있습니다.
다음 표는 Microsoft Entra ID 프로비저닝의 기본 동작을 요약하며 Cloud ID 또는 Google Workspace에서 Microsoft Entra ID가 수행할 작업을 그룹이 제어하도록 프로비저닝을 사용 설정 또는 중지하는 방법을 보여줍니다.
| Microsoft Entra ID 그룹에 프로비저닝 사용 설정 | Cloud ID 또는 Google Workspace의 그룹 상태 | Microsoft Entra ID에서 수행된 작업 | Cloud ID 또는 Google Workspace에서 수행된 작업 |
|---|---|---|---|
| 아니요 | (존재하지 않음) | 프로비저닝 사용 설정 | 새 그룹 만들기 |
| 아니요 | 존재 | 프로비저닝 사용 설정 | 구성원 추가, 모든 기존 구성원 유지 |
| 예 | 존재 | 그룹 이름 바꾸기 | 그룹 이름 바꾸기 |
| 예 | 존재 | 설명 수정 | 설명 업데이트 |
| 예 | 존재 | 구성원 추가 | 구성원 추가, 모든 기존 구성원 유지 |
| 예 | 존재 | 구성원 삭제 | 구성원 삭제 |
| 예 | 존재 | 프로비저닝 사용 중지 | 그룹 그대로 유지(구성원 포함) |
| 예 | 존재 | 그룹 삭제 | 그룹 그대로 유지(구성원 포함) |
다음 단계
- 계정 및 조직 계획을 위한 권장사항과 Google Cloud와 외부 ID 공급업체의 페더레이션을 위한 권장사항 읽어보기
- Microsoft Entra ID와 Cloud ID 간에 프로비저닝과 싱글 사인온(SSO)을 구성하는 방법 알아보기
- 최고 관리자 계정 관리를 위한 권장사항 읽어보기