Google Cloud, Google Marketing Platform, Google Ads를 포함한 모든 Google 서비스는 Google 로그인을 사용하여 사용자를 인증합니다. 이 문서에서는 Google 로그인이 인증 및 ID 관리를 위해 사용하는 도메인 모델을 설명합니다. 도메인 모델은 Google 로그인이 기업 환경에서 작동하는 원리, ID 관리 방법, 외부 ID 공급업체(IdP)와의 통합을 지원하는 방법을 이해하는 데 도움이 됩니다. 다음 다이어그램은 이러한 항목이 어떻게 상호작용하는지 보여줍니다.
이 다이어그램에 나와 있는 것처럼 모델 중심에는 Google 로그인에서 사용하는 Google ID가 있습니다. Googld ID는 ID 관리 측면에서 관련성이 있는 모든 다른 항목과 연관되어 있습니다.
- 일반 사용자용 Google에는 Gmail과 같은 구글 서비스의 일반 사용자 사용과 관련된 항목이 포함됩니다.
- 조직을 위한 Google에는 Cloud ID 또는 Google Workspace에서 관리하는 항목이 포함됩니다. 이러한 항목은 회사 ID 관리와 가장 관련성이 높습니다.
- Google Cloud에는 Google Cloud에 해당하는 항목이 포함됩니다.
- 외부에는 Google을 외부 IdP와 통합하는 경우의 관련 항목이 포함됩니다.
이 다이어그램에서 실선 화살표는 항목이 서로를 참조하거나 서로를 포함한다는 의미입니다. 반면에 파선 화살표는 페더레이션 관계를 나타냅니다.
Google ID
ID, 사용자, 사용자 계정은 ID 관리에서 중요한 역할을 합니다. 이 세 가지 용어는 서로 밀접하게 관련되어 있으며 경우에 따라 서로 바꿔서 사용할 수도 있습니다. 하지만 ID 관리와 관련해서는 각각의 개념을 구분하는 것이 좋습니다.
ID는 Google 서비스와 상호작용하는 사용자를 고유하게 식별하는 이름입니다. Google은 이 용도로 이메일 주소를 사용합니다. 사용자의 이메일 주소가 해당 사용자의 Google ID이기도 합니다.
사용자와 ID 간의 연결을 확인하는 프로세스를 인증 또는 로그인이라고하며, 이 프로세스를 통해 실제 자신의 ID임을 증명합니다.
각 사용자는 여러 이메일 주소를 가질 수 있습니다. Google 서비스는 이메일 주소를 ID로 사용하므로 각 사용자는 여러 ID를 갖고 있는 것으로 간주됩니다.
사용자 계정은 특정 ID가 Google 서비스와 상호작용할 때마다 적용해야 하는 속성, 활동, 구성을 추적하는 데이터 구조입니다. 사용자 계정은 즉시 생성되지 않으며 처음 로그인하기 전에 프로비저닝해야 합니다.
사용자 계정은 외부에 노출되지 않은 ID로 식별됩니다. 따라서 사용자 인터페이스 또는 API를 사용하려면 연결된 ID(예:
alice@gmail.com)를 통해 간접적으로 사용자 계정을 참조해야 합니다 이러한 간접적 참조에도 불구하고 모든 데이터 및 구성 세부정보는 ID가 아닌 사용자 계정과 연결됩니다.
대부분의 경우 사용자 계정과 ID는 일대일 관계이므로 혼용하기 쉽습니다. 그러나 다음 특이 사례에서 설명하는 것처럼 항상 그럴 수 있는 것은 아닙니다.
사용자 계정과 ID 간의 관계가 수정되지 않았습니다. 사용자와 다른 ID를 연결하는 사용자 계정의 기본 이메일 주소를 변경할 수 있습니다.
Cloud ID 또는 Google Workspace 관리자는 두 사용자의 기본 이메일 주소를 서로 바꿀 수도 있습니다. 예를 들어 Alice(
alice@example.com)와 Bob(bob@example.com)의 기본 이메일 주소를 바꿨다면 Alice는 Bob의 이전 사용자 계정을 사용하고 Bob은 Alice의 이전 사용자 계정을 사용하게 됩니다. 데이터와 구성은 ID가 아닌 사용자 계정과 연결되어 있으므로 이제 Alice는 Bob의 기존 구성 및 데이터를 사용하고 Bob은 Alice의 기존 구성 및 데이터를 사용하게 됩니다. 다음 그림에서는 이 관계를 보여줍니다.
페더레이션되지 않은 설정에서는 Alice와 Bob의 사용자 계정을 서로 바꾸기 위해 비밀번호를 재설정해야 합니다. Alice와 Bob이 외부 IdP를 사용하여 인증하는 페더레이션 설정에서는 비밀번호를 재설정할 필요가 없습니다.
ID와 사용자가 일대일 관계가 아닐 수 있습니다. 다음 다이어그램과 같이 일반 계정을 의도적으로 여러 ID와 연결할 수 있습니다.
또한 하나의 ID가 서로 다른 두 개의 사용자 계정을 참조할 수도 있습니다. 이러한 상황은 피하는 것이 좋지만 사용자 계정이 중복되는 경우 이러한 상황이 발생할 수 있습니다. 이 경우에는 인증 절차 중에 사용할 사용자 계정을 선택하라는 선택 화면 표시됩니다.
Google은 일반 사용자 계정과 관리되는 사용자 계정의 두 가지 유형으로 사용자 계정을 구분합니다. 다음 섹션에서는 두 사용자 계정 유형과 관련 항목에 대해 자세히 설명합니다.
일반 사용자를 위한 Google
alice@gmail.com과 같은 Gmail 이메일 주소가 있다면 Gmail 계정이 일반 계정이 됩니다. 마찬가지로 Google 로그인 페이지에서 계정 만들기 링크를 사용하고 가입 중에 현재 소유한 커스텀 이메일 주소(예: alice@example.com)를 제공하면 결과로 나타나는 계정이 일반 계정이 되기도 합니다.
일반 계정
일반 계정은 셀프서비스 방식으로 생성되며 주로 개인적인 용도로 사용됩니다. 일반 계정을 만든 사람은 계정 및 계정을 사용하여 만든 모든 데이터를 관리할 수 있습니다. 가입 시 사용한 이메일 주소가 일반 계정의 기본 이메일 주소가 되며, 이 이메일 주소가 ID 역할을 합니다. 해당 사용자는 일반 계정에 이메일 주소를 추가할 수 있습니다. 이러한 이메일 주소는 추가 ID 역할을 하며 로그인에도 사용할 수 있습니다.
일반 계정에서 Cloud ID 또는 Google Workspace 계정의 기본 또는 보조 도메인에 해당하는 기본 이메일 주소를 사용하는 경우 일반 계정을 관리 되지 않는 사용자 계정이라고도 합니다.
일반 계정은 여러 그룹의 구성원일 수 있습니다.
조직을 위한 Google
조직에서 Google 서비스를 사용하는 경우 관리되는 사용자 계정을 사용하는 것이 가장 좋습니다. 이러한 계정은 조직에서 수명주기 및 구성을 완전히 제어할 수 있기 때문에 관리 계정이라고 합니다.
관리되는 사용자 계정은 Cloud ID 및 Google Workspace의 기능입니다.
Cloud ID 또는 Google Workspace 계정
Cloud ID 또는 Google Workspace 계정은 사용자, 그룹, 구성, 데이터의 최상위 컨테이너입니다. Cloud ID 또는 Google Workspace 계정은 회사가 Cloud ID 또는 Google Workspace에 가입할 때 생성되며 테넌트의 개념에 해당됩니다.
Cloud ID 및 Google Workspace는 공통의 기술 플랫폼을 공유합니다. 두 제품 모두 동일한 API 및 관리 도구 모음을 사용하며 사용자 및 그룹의 컨테이너로서의 계정 개념을 공유합니다. 해당 컨테이너는 도메인 이름으로 식별됩니다. 사용자, 그룹, 인증을 관리하기 위해 두 제품은 대개 동일한 제품으로 간주됩니다.
계정은 그룹과 하나 이상의 조직 단위로 구성됩니다.
조직 단위
조직 단위(OU)는 Cloud ID 또는 Google Workspace 계정에 정의된 사용자 계정을 관리하기 쉽게 분리 세트로 분류할 수 있게 하는 사용자 계정의 하위 컨테이너입니다.
조직 단위는 계층적으로 정리됩니다. 각 Cloud ID 또는 Google Workspace 계정의 루트 OU 아래에는 필요에 따라 더 많은 OU를 만들 수 있습니다. OU를 중첩할 수도 있습니다.
Cloud ID 및 Google Workspace를 사용하면 라이선스 할당 또는 2단계 인증과 같은 특정 구성을 OU별로 적용할 수 있습니다. 이러한 설정은 OU의 모든 사용자에게 자동으로 적용되며 하위 OU에도 상속됩니다. 따라서 조직 단위는 Cloud ID 및 Google Workspace 구성을 관리하는 데 중요한 역할을 합니다.
사용자 계정은 둘 이상의 OU에 속할 수 없으며, 따라서 OU는 그룹과 구별됩니다. OU는 사용자 계정에 구성을 적용할 때 유용하지만 액세스 관리에는 사용할 수 없습니다. 액세스 관리에는 그룹을 사용하는 것이 좋습니다.
OU는 Google Cloud 폴더와 유사하지만, 두 항목은 각기 다른 용도로 사용되며 서로 관련이 없습니다.
관리되는 사용자 계정
관리되는 사용자 계정은 일반 사용자 계정과 비슷하게 작동하지만 Cloud ID 또는 Google Workspace 계정의 관리자가 완전히 제어할 수 있습니다.
관리되는 사용자 계정의 ID는 기본 이메일 주소로 정의됩니다.
기본 이메일 주소는 Cloud ID 또는 Google Workspace 계정에 추가된 기본, 보조 또는 별칭 도메인 중 하나에 해당하는 도메인을 사용해야 합니다. 관리되는 사용자 계정에는 별칭 이메일 주소 및 복구 이메일 주소를 추가할 수 있지만 이러한 주소는 ID로 간주되지 않으며 로그인에 사용할 수 없습니다. 예를 들어 Alice가 alice@example.com을 기본 이메일 주소로 사용하고 ally@example.com을 별칭 이메일 주소로, alice@gmail.com을 복구 이메일 주소로 구성한 경우 로그인에는 alice@example.com만 사용할 수 있습니다.
관리되는 사용자 계정은 조직 단위에 포함되며 여러 그룹의 구성원일 수 있습니다.
관리되는 사용자 계정은 머신이 아닌 실제 사용자가 사용하도록 고안되었습니다. 머신 사용자 계정은 사람이 아닌 애플리케이션 또는 가상 머신(VM) 인스턴스에서 사용하는 특별한 유형의 계정입니다. Google Cloud는 머신 사용자용으로 서비스 계정을 제공합니다. 서비스 계정에 대한 자세한 내용은 이 문서의 뒷부분에서 설명합니다.
그룹
그룹을 사용하면 여러 사용자를 그룹으로 묶을 수 있습니다. 그룹을 사용하여 메일링 리스트를 관리하거나 여러 사용자에게 공통 액세스 제어 또는 구성을 적용할 수 있습니다.
Cloud ID 및 Google Workspace는 이메일 주소로 그룹을 식별합니다(예: billing-admins@example.com). 사용자의 기본 이메일 주소와 마찬가지로 그룹 이메일 주소는 Cloud ID 또는 Google Workspace 계정의 기본, 보조 또는 별칭 도메인 중 하나를 사용해야 합니다. 그룹이 메일링 리스트로 사용되는 경우를 제외하고 이메일 주소가 편지함과 일치할 필요는 없습니다. 인증은 그룹 이메일이 아닌 사용자 이메일을 사용하여 이루어지므로 사용자는 그룹 이메일 주소를 사용하여 로그인할 수 없습니다.
그룹에는 다음 항목에 해당하는 구성원이 있을 수 있습니다.
- 사용자(관리되는 사용자 계정 또는 일반 계정)
- 기타 그룹
- 서비스 계정
조직 단위와 달리 그룹은 컨테이너 역할을 하지 않습니다.
- 사용자 또는 그룹은 단지 한 그룹이 아닌 여러 그룹의 구성원일 수 있습니다.
- 그룹을 삭제해도 구성원 사용자 또는 그룹은 삭제되지 않습니다.
그룹에는 Cloud ID 또는 Google Workspace 계정의 구성원은 물론 일반 계정도 포함될 수 있습니다. 조직 외부의 구성원 허용 안함 설정을 사용하여 구성원을 동일한 Cloud ID 또는 Google Workspace 계정의 사용자 계정으로 제한할 수 있습니다.
외부 ID
Cloud ID 또는 Google Workspace 계정을 외부 IdP와 페더레이션하면 직원이 기존 ID와 사용자 인증 정보를 사용하여 Google 서비스에 로그인할 수 있습니다.
기본적으로 페더레이션에는 SAML을 사용하여 싱글 사인온(SSO)을 설정하는 작업이 포함됩니다. SAML은 Cloud ID 또는 Google Workspace의 ID를 외부 IdP에서 관리하는 ID에 연결합니다. alice@example.com과 같은 ID를 연결하고 Google에 싱글 사인온(SSO)을 사용하도록 설정하려면 다음 두 가지 기본 요건을 충족해야 합니다.
- 외부 IdP는 ID
alice@example.com을 인식하고 싱글 사인온(SSO)에 사용할 수 있도록 허용해야 합니다. - Cloud ID 또는 Google Workspace 계정에는
alice@example.com을 ID로 사용하는 사용자 계정이 포함되어야 합니다. 이 사용자 계정은 첫 번째 싱글 사인온(SSO) 시도 전에 미리 존재해야 합니다.
Cloud ID 또는 Google Workspace에서 수동으로 사용자 계정을 만들고 유지보수하는 대신 SAML 기반 싱글 사인온(SSO)을 자동 사용자 프로비저닝과 결합하여 프로세스를 자동화할 수 있습니다. 자동 사용자 프로비저닝의 개념은 외부 권한 소스의 사용자 및 그룹의 전체 또는 일부를 Cloud ID 또는 Google Workspace에 동기화하는 것입니다.
SAML 기반 싱글 사인온(SSO) 및 자동 사용자 프로비저닝은 선택한 IdP에 따라 동일한 소프트웨어 구성요소에 의해 처리되거나 별도의 구성요소가 필요할 수 있습니다. 따라서 도메인 모델은 SAML ID 공급업체와 외부 권한 소스를 구분합니다.
외부 SAML ID 공급업체
외부 IdP는 유일한 인증 시스템으로, 여러 애플리케이션에 적용되는 싱글 사인온(SSO) 환경을 직원에게 제공합니다. Google 외부에 있으므로 외부 ID 공급업체라고도 합니다.
싱글 사인온(SSO)을 사용 설정하면 Cloud ID 또는 Google Workspace에서 인증 결정을 SAML IdP로 전달합니다. SAML 용어에서 Cloud ID 또는 Google Workspace는 SAML IdP를 신뢰하여 사용자의 ID를 대신 확인하는 서비스 제공업체 역할을 합니다.
각 Cloud ID 또는 Google Workspace 계정은 최대 하나의 외부 IdP를 참조할 수 있습니다. 여러 Cloud ID 또는 Google Workspace 계정은 서로 다른 SAML IdP를 참조할 수 있지만, 단일 Cloud ID 또는 Google Workspace 계정에서 여러 SAML IdP를 사용할 수는 없습니다.
일반적으로 사용되는 외부 IdP로는 Active Directory Federation Services(AD FS), Azure AD, OKta 또는 Ping Identity가 있습니다.
외부 권한 소스
ID의 권한 소스는 직원 ID를 생성, 관리, 삭제하는 데 사용하는 유일한 시스템입니다. Google 외부에 있으므로 외부 권한 소스라고도 합니다.
외부 권한 소스에서 사용자 계정 및 그룹을 Cloud ID 또는 Google Workspace에 자동으로 프로비저닝할 수 있습니다. 프로비저닝은 권한 소스 자체 또는 프로비저닝 미들웨어를 이용해 처리할 수 있습니다.
자동 사용자 프로비저닝을 적용하려면 사용자를 SAML IdP가 인식하는 ID로 프로비저닝해야 합니다. 예를 들어 Cloud ID 또는 Google Workspace의 ID alice@example.com을 SAML IdP의 u12345@corp.example.com에 매핑하는 것과 같이 ID 간에 매핑하는 경우 SAML IdP와 프로비저닝 미들웨어가 동일한 매핑을 수행해야 합니다.
외부 사용자 계정
외부 ID 공급업체는 이름, 속성, 구성을 추적하는 사용자 계정의 개념이 있다고 가정합니다.
권한 소스(또는 프로비저닝 미들웨어)는 로그인 환경을 지원하기 위해 외부 사용자 계정의 전체 또는 일부를 Cloud ID 또는 Google Workspace에 프로비저닝해야 합니다. 대부분의 경우 사용자 속성(예: 이메일 주소, 이름, 성) 중 일부만 Cloud ID 또는 Google Workspace에 전파해도 데이터 중복을 제한할 수 있습니다.
외부 그룹
외부 IdP가 그룹의 개념을 지원하는 경우 선택적으로 이러한 그룹을 Cloud ID 또는 Google Workspace 그룹에 매핑할 수 있습니다.
매핑 및 자동 프로비저닝 그룹은 선택사항이며 싱글 사인온(SSO)에는 필요하지 않지만, 두 단계 모두 기존 그룹을 재사용하여 Google Workspace 또는 Google Cloud의 액세스를 제어하려는 경우에 유용할 수 있습니다.
Google Cloud
다른 Google 서비스와 마찬가지로 Google Cloud는 Google 로그인을 사용하여 사용자를 인증합니다. 또한 Google Cloud는 Google Workspace 및 Cloud ID와 긴밀하게 통합되어 리소스를 효율적으로 관리할 수 있게 해줍니다.
Google Cloud는 조직 노드, 폴더, 프로젝트라는 개념을 사용합니다. 이러한 항목은 주로 액세스 및 구성을 관리하는 데 사용되므로 ID 관리 측면에서는 약간만 관련이 있습니다. 하지만 Google Cloud에는 서비스 계정이라는 추가 유형의 사용자 계정도 포함되어 있습니다. 서비스 계정은 프로젝트에 속하며 ID 관리에서 중요한 역할을 합니다.
조직 노드
조직은 Google Cloud 리소스 계층 구조의 루트 노드로서 프로젝트 및 폴더의 컨테이너입니다. 조직을 사용하면 리소스를 계층적으로 구조화할 수 있으며 중앙에서 효율적으로 리소스를 관리하는 데 중요한 역할을 합니다.
각 조직은 단일 Cloud ID 또는 Google Workspace 계정에 속합니다. 조직의 이름은 해당 Cloud ID 또는 Google Workspace 계정의 기본 도메인 이름에서 파생됩니다.
폴더
폴더는 Google Cloud 리소스 계층 구조의 노드로서 프로젝트나 다른 폴더, 또는 이 둘의 조합을 포함할 수 있습니다. 폴더를 사용하여 공통된 ID 및 액세스 관리(IAM) 정책 또는 조직 정책을 공유하는 리소스를 그룹화할 수 있습니다. 이러한 정책은 폴더에 포함된 모든 프로젝트에 자동으로 적용되며 하위 폴더에도 상속됩니다.
폴더는 조직 단위와 유사하지만 관련이 없습니다. 조직 단위는 사용자를 관리하고 공통된 구성 또는 정책을 사용자에게 적용하는 데 도움이 되며, 폴더는 Google Cloud 프로젝트를 관리하고 공통 구성 또는 정책을 프로젝트에 적용하는 데 도움이 됩니다.
프로젝트
프로젝트는 리소스를 담을 수 있는 컨테이너입니다. 프로젝트는 API 관리, 결제, 리소스에 대한 액세스 관리에서 중요한 역할을 합니다.
ID 관리와 관련해 프로젝트는 서비스 계정의 컨테이너이므로 관련성이 높습니다.
서비스 계정
서비스 계정(또는 Google Cloud 서비스 계정)은 애플리케이션 및 다른 유형의 머신 사용자가 사용하도록 고안된 특수한 유형의 사용자 계정입니다.
각 서비스 계정은 Google Cloud 프로젝트에 속합니다. 관리되는 사용자 계정의 경우와 마찬가지로 관리자는 서비스 계정의 수명주기 및 구성을 완전히 제어할 수 있습니다.
서비스 계정도 이메일 주소를 ID로 사용하지만, 관리되는 사용자 계정과는 달리 이메일 주소에 항상 developer.gserviceaccount.com과 같은 Google 소유 도메인을 사용합니다.
서비스 계정은 페더레이션에 관여하지 않으며 비밀번호도 없습니다. Google Cloud에서는 가상 머신(VM) 또는 Cloud Run 함수와 같은 컴퓨팅 리소스에 대한 서비스 계정의 권한을 IAM을 사용하여 제어하므로 사용자 인증 정보를 관리할 필요가 없습니다. Google Cloud 외부에서는 서비스 계정 키를 사용하여 애플리케이션이 서비스 계정을 사용하여 인증하도록 할 수 있습니다.
Kubernetes 서비스 계정
Kubernetes 서비스 계정은 Kubernetes의 개념으로 Google Kubernetes Engine(GKE)을 사용할 때와 관련이 있습니다. Google Cloud 서비스 계정과 마찬가지로 Kubernetes 서비스 계정은 사용자가 아닌 애플리케이션에 의해 사용됩니다.
Kubernetes 서비스 계정은 애플리케이션에서 Kubernetes 클러스터의 Kubernetes API를 호출할 때 인증하는 데 사용할 수 있지만 클러스터 외부에서는 사용할 수 없습니다. Kubernetes 서비스 계정은 어떤 Google API에서도 인식되지 않으므로 Google Cloud 서비스 계정을 대체하지 않습니다.
애플리케이션을 Kubernetes pod로 배포할 때 pod를 서비스 계정과 연결할 수 있습니다. 이 연결을 사용하면 인증서 또는 기타 사용자 인증 정보를 구성하거나 유지보수하지 않고도 애플리케이션에서 Kubernetes API를 사용할 수 있습니다.
워크로드 아이덴티티를 사용하면 Kubernetes 서비스 계정을 Google Cloud 서비스 계정에 연결할 수 있습니다. 이 연결을 사용하면 인증서 또는 기타 사용자 인증 정보를 구성하거나 유지보수하지 않고도 애플리케이션에서 Google API에 다시 인증할 수 있습니다.
다음 단계
- ID 관리에 관한 참조 아키텍처 검토하기