이 문서에서는 일관되고 안전하게 페더레이션을 설정하는 데 유용한 권장사항과 안내를 제공합니다. 이 가이드는 Google Cloud에서 Cloud ID 또는 Google Workspace 사용 권장사항을 기반으로 합니다.
Google Cloud, Google Marketing Platform, Google Ads를 포함한 모든 Google 서비스는 Google 로그인을 사용하여 사용자를 인증합니다. 모든 직원이 Cloud ID 또는 Google Workspace에서 수동으로 사용자 계정을 만들고 유지보수하는 대신 Active Directory 또는 Azure Active Directory와 같은 외부 ID 공급업체(IdP)를 통해 Cloud ID 또는 Google Workspace를 페더레이션할 수 있습니다. 페더레이션을 설정하려면 일반적으로 다음을 수행해야 합니다.
- 외부 권한 소스에서 Cloud ID 또는 Google Workspace로 관련 사용자 계정을 자동으로 프로비저닝합니다.
- 사용자가 외부 IdP를 사용하여 Google 서비스에 인증할 수 있습니다.
ID 매핑
Cloud ID 또는 Google Workspace에서 관리하는 사용자 계정의 ID는 기본 이메일 주소로 정의됩니다. 기본 이메일 주소는 Google 계정 페이지에 Google 계정 이메일로 표시됩니다. 유효한 이메일로 간주되려면 기본 이메일 주소가 Cloud ID 또는 Google Workspace 계정에 추가한 도메인 중 하나를 사용해야 합니다.
기본 이메일 주소는 다음 용도로도 사용됩니다.
- 기본 이메일 주소는 사용자가 로그인할 때 제공해야 하는 사용자 이름입니다. 사용자가 Google 사용자 계정에 보조 이메일 주소 또는 별칭을 추가할 수 있지만 이러한 주소는 ID로 간주되지 않으며 로그인에 사용할 수 없습니다.
- 관리자가 잠재적인 보안 위험을 알리기 위해 사용자에게 알림을 보내야 하는 경우 이러한 알림은 기본 이메일 주소로만 전송됩니다.
Google과 외부 IdP 간에 싱글 사인온(SSO) 및 자동 사용자 프로비저닝을 설정하려면 외부 IdP의 ID를 Cloud ID 또는 Google Workspace의 해당 ID에 매핑해야 합니다. 다음 섹션에서는 이 매핑을 설정하기 위한 권장사항을 설명합니다.
모든 페더레이션 시스템에서 동일한 ID 사용
매핑을 설정하려면 IdP가 Google에 제공하는 SAML 어설션에 기존 Cloud ID 또는 Google Workspace 사용자의 기본 이메일 주소와 일치하는 값을 가진 NameID 클레임이 있는지 확인하기만 하면 됩니다. IdP는 기존 사용자에게 적합한 NameID 클레임을 파생하기 위해 적용 가능한 매핑 또는 로직을 자유롭게 사용할 수 있습니다.
많은 IdP는 이메일 주소(또는 일반적으로 RFC 822 준수 이름)를 사용하여 사용자를 식별합니다. 예를 들면 다음과 같습니다.
- Active Directory의
userPrincipalName속성은 사용자를 고유하게 식별하며 Windows 또는 AD FS(Active Directory Federation Services)에 로그인하는 데 사용할 수 있는 RFC 822 준수 이름입니다. - Azure Active Directory는
UserPrincipalName속성을 사용하여 사용자를 식별하고 로그인하도록 허용합니다.
외부 IdP에서 관리하는 사용자가 이미 이메일 주소를 ID로 사용하는 경우 Cloud ID 또는 Google Workspace의 기본 이메일 주소와 동일한 ID를 사용할 수 있습니다. 페더레이션 시스템에서 동일한 사용자 ID를 사용하면 여러 가지 이점이 있습니다.
사용자가 Google Cloud Console과 같은 Google 도구에 로그인하면 외부 IdP로 리디렉션되기 전에 먼저 Cloud ID 또는 Google Workspace 사용자의 기본 이메일 주소를 제공하라는 메시지가 표시됩니다. IdP에 따라 사용자에게 사용자 이름과 비밀번호를 요청하는 다른 로그인 화면이 표시될 수 있습니다.
이 단계에서 이메일 주소가 다를 경우 최종 사용자가 로그인 화면 순서를 혼동할 수 있습니다. 반면에 사용자가 모든 단계에서 일반 ID를 사용할 수 있는 경우 IdP 간에 기술적 차이에 드러나지 않으므로 잠재적 혼동을 최소화할 수 있습니다.
사용자 ID 간에 매핑할 필요가 없는 경우 Google Cloud 감사 로그와 온프레미스 시스템 로그의 상관관계를 쉽게 파악할 수 있습니다.
마찬가지로 온프레미스 및 Google Cloud에 배포된 애플리케이션이 사용자 ID를 포함하는 데이터를 교환해야 하는 경우 사용자 식별자를 매핑할 필요가 없습니다.
Active Directory 사용자 또는 Azure AD 사용자를 Cloud ID 또는 Google Workspace에 매핑하는 방법에 대한 자세한 내용은 Active Directory 또는 Azure AD 가이드를 참조하세요.
ID가 라우팅 가능한 이메일 주소를 사용하는지 확인
Google Cloud는 사용자의 기본 이메일 주소를 사용하여 알림 이메일을 전송합니다. 이러한 알림의 예시는 다음과 같습니다.
예산 알림: 예산 알림을 구성한 경우 예산 기준액을 초과하면 Google Cloud에서 결제 관리자 및 결제 사용자에게 알림을 보냅니다.
결제 알림: 결제 관련 알림은 해당 결제 계정에 구성된 결제 사용자의 이메일 주소로 전송됩니다.
프로젝트 초대: 프로젝트 조직과 연결된 계정이 아닌 다른 Cloud ID 또는 Google Workspace 계정에 속한 사용자에게 프로젝트 관리자 역할을 할당하면 사용자에게 초대장이 전송됩니다. 새로 부여된 역할이 적용되려면 사용자가 이메일 메시지의 링크를 클릭하여 초대를 수락해야 합니다.
지원 케이스 및 지원팀의 기타 알림에 응답합니다.
Google Workspace를 사용하고 필요한 DNS MX 레코드를 올바르게 구성한 경우 기본 이메일 주소로 전송되는 모든 알림 이메일이 해당 사용자의 Gmail 받은편지함으로 전송됩니다.
Cloud ID 사용자의 경우 Google Cloud도 알림 이메일을 전송하려고 시도하지만 기존 이메일 인프라에서 이메일을 처리해야 합니다. Cloud ID 사용자가 알림을 놓치지 않도록 하려면 기존 이메일 시스템에서 Cloud ID 사용자의 기본 이메일 주소로 전송된 메시지를 수락하고 이 이메일을 올바른 편지함으로 라우팅해야 합니다. 다음을 수행하세요.
Cloud ID에 추가된 모든 도메인에 기존 이메일 시스템을 가리키는 DNS MX 레코드가 있는지 확인합니다.
Cloud ID 사용자의 기본 이메일 주소가 이메일 시스템의 기존 편지함과 일치하는지 확인합니다. Cloud ID에서 사용하는 기본 이메일 주소와 사용자의 이메일 주소가 일치하지 않는 경우 각 기본 이메일 주소로 전송된 이메일이 올바른 편지함으로 라우팅되도록 기존 이메일 시스템에서 별칭을 구성합니다.
이러한 솔루션이 실용적이지 않다면 기존 Cloud ID 계정에 Google Workspace를 추가하고 결제를 담당하거나 지원 서비스를 이용하므로 알림을 받을 가능성이 가장 높은 주요 사용자에게 Google Workspace 라이선스를 할당하는 것이 좋습니다.
기존 일반 계정의 마이그레이션 옵션 평가
조직에서 Cloud ID 또는 Google Workspace에 가입하기 전에 조직의 직원들이 Google Ad Manager, Google 애드센스, Google 애널리틱스와 같은 Google 서비스를 사용하는 경우 직원들이 일반 계정을 사용하여 이러한 서비스에 액세스했을 수 있습니다.
직원들이 비즈니스 용도로 일반 계정을 사용하도록 허용하는 것은 위험할 수 있습니다. 이러한 위험에 대한 자세한 내용과 기존 일반 계정을 표시하는 방법은 기존 Google 계정 평가를 참조하세요.
다음과 같은 방법으로 기존 일반 계정을 처리할 수 있습니다.
- 일반 계정을 그대로 유지하여 잠재적 위험을 수용합니다.
- 전송을 시작하여 계정을 Cloud ID 또는 Google Workspace로 마이그레이션합니다.
- 비관리 사용자 계정의 소유자가 이메일 주소를 변경하여 다른 도메인을 사용하도록 합니다.
기존 일반 계정을 통합하는 방법에 대한 자세한 내용은 ID 통합 옵션 평가를 참조하세요.
일반 계정을 처리하는 방식은 페더레이션을 설정하는 방법 및 순서에 영향을 미칩니다. Cloud ID 또는 Google Workspace에서 사용자 계정을 만들거나 싱글 사인온(SSO)을 설정하기 전에 사용자가 사용하는 기존 일반 계정을 평가합니다.
ID 집합 매핑
개별 ID가 외부 IdP와 Cloud ID 또는 Google Workspace 간에 매핑되는 방식을 정의한 경우 Google 서비스에 액세스할 수 있는 ID 집합을 결정해야 합니다.
Google 서비스에 인증할 수 있는 효과적인 ID 집합은 다음 두 집합의 교차 영역입니다.
- Cloud ID 또는 Google Workspace에서 ID에 매핑하는 외부 ID
외부 IdP에서 Cloud ID 또는 Google Workspace에 대해 싱글 사인온(SSO)을 사용할 수 있는 외부 ID
싱글 사인온(SSO) 사용 권한을 제어하는 프로세스는 사용하는 IdP에 따라 다릅니다. 예를 들어 Azure AD는 할당을 사용하고 AD FS는 액세스 제어 정책을 사용합니다.
Google 서비스에 인증할 수 있는 ID 집합 제한
Google Cloud, Google Workspace, 기타 Google 도구를 사용하려는 방식에 따라 조직의 모든 직원 또는 일부 직원만 Google 서비스에 인증할 수 있어야 합니다.
조직의 일부 직원에게만 Google 서비스에 대한 액세스 권한을 부여하려면 이 사용자로 인증을 제한하는 것이 가장 좋습니다. 인증할 수 있는 사용자 수를 제한하면 실수로 액세스 제어 규칙을 너무 느슨하게 구성한 경우 유용한 추가 방어막을 구축할 수 있습니다.
다음과 같은 방법으로 Google에 인증할 수 있는 사용자를 제한할 수 있습니다.
- Cloud ID 또는 Google Workspace에서 사용자 계정 수를 최소화합니다. 매핑된 사용자 계정이 없으면 IdP에서 사용자가 싱글 사인온(SSO)을 사용하여 Cloud ID 또는 Google Workspace에 로그인하도록 허용하더라도 사용자의 인증 시도가 실패합니다.
- IdP에서 싱글 사인온(SSO)을 구성하여 Cloud ID 또는 Google Workspace에 로그인할 수 있는 사용자 수를 최소화합니다.
상황에 가장 적합한 방법은 마이그레이션해야 하는 일반 계정이 기존에 있는지 여부에 따라 다릅니다.
일반 계정을 마이그레이션해야 하는 경우 프로비저닝하는 ID 집합 제한
Cloud ID 또는 Google Workspace에서 동일한 ID를 사용하는 사용자 계정을 만들지 않은 경우에만 일반 계정을 Cloud ID 또는 Google Workspace로 마이그레이션할 수 있습니다.
마이그레이션하려는 기존 일반 계정이 있는 경우 실수로 중복 사용자 계정을 만들지 않도록 주의해야 합니다. 다음 가이드라인을 준수해야 합니다.
- 기존 일반 계정이 없는 것으로 알려진 사용자에 대해서만 새 Cloud ID 또는 Google Workspace 사용자 계정을 만들어 인증을 제한합니다.
- Cloud ID 또는 Google Workspace에서 사용자 계정을 만드는 사용자뿐만 아니라 아직 마이그레이션되지 않은 모든 일반 계정에 대해 싱글 사인온(SSO)을 허용하여 마이그레이션된 계정을 실수로 잠그지 않도록 합니다.
다음 다이어그램은 서로 다른 유형의 ID가 어떻게 중복되고 상호 연관되는지 보여줍니다.
다이어그램에서 Cloud ID 또는 Google Workspace에 사용자 계정이 있는 ID는 가장 작은(노란색) 타원입니다. 이 타원은 인증할 수 있는 ID가 포함된 두 번째(파란색) 타원에 포함되어 있습니다. 세 번째로 큰 타원(분홍색)은 다른 타원을 포함하며 IdP에 사용자 계정이 있는 ID로 구성됩니다. Active Directory, Azure AD, Okta를 구성하는 방법에 대한 자세한 내용은 별도의 권장사항 가이드를 참조하세요.
새 일반 계정 가입 방지
example.com과 같은 도메인을 Cloud ID 또는 Google Workspace 계정에 추가해도 직원이 동일한 도메인을 사용하여 새 일반 계정에 가입하는 것을 차단하지 않습니다. 이러한 새 일반 계정은 Cloud ID 또는 Google Workspace 계정에서 비관리 사용자로 표시되지만 Cloud ID 또는 Google Workspace 계정에 적용한 싱글 사인온(SSO) 또는 기타 구성은 사용할 수 없습니다.
새 일반 계정 생성을 차단하는 한 가지 방법은 동일한 이메일 주소로 Cloud ID 또는 Google Workspace에서 사용자 계정을 만드는 것입니다. 예를 들어 Cloud ID 또는 Google Workspace 계정에서 사용자 alice@example.com을 만든 경우 직원이 동일한 ID로 새 일반 계정에 가입하려는 모든 시도가 실패합니다. 하지만 Cloud ID 또는 Google Workspace에 해당 사용자가 없으면 새 일반 계정에 가입할 수 있습니다.
Cloud ID로 마이그레이션할 일반 계정이 더 이상 없는 경우 다음 구성을 적용하여 새 일반 계정 가입을 방지하세요.
관련 사용자만 Cloud ID 또는 Google Workspace에 싱글 사인온(SSO)을 사용하도록 허용하여 인증을 제한합니다.
모든 직원에 대해 Cloud ID 또는 Google Workspace 사용자를 프로비저닝합니다. 동일한 이메일 주소를 사용하여 새 일반 계정을 만들 수 없도록 사용자 계정이 직원의 회사 이메일 주소를 기본 이메일 주소 또는 별칭으로 사용하도록 합니다. 가능하다면 싱글 사인온(SSO)을 사용하도록 설정되지 않은 사용자 계정을 정지 상태로 유지합니다.
다음 다이어그램은 이 구성을 보여줍니다.
아직 일반 계정을 마이그레이션하고 있다면 가입 프로세스 중에 전송된 인증 메일을 캡처하여 신규 일반 계정 가입을 임시로 모니터링할 수 있습니다. 인증 메일에는 *@idverification.bounces.google.com과 일치하는 발신자 메일 주소가 사용됩니다.
이메일 시스템에서 이 발신자 메일 주소로 이메일을 식별하고 내부 검토를 위해 보관하는 필터를 설정합니다.
Cloud ID 또는 Google Workspace ID를 외부 IdP에 있는 ID의 하위 집합으로 설정
Cloud ID 또는 Google Workspace 계정에는 외부 IdP의 사용자에게 매핑되지 않는 ID의 사용자 계정이 포함될 수 있습니다. 이러한 사용자 계정으로 이어질 수 있는 두 가지 일반적인 시나리오는 다음과 같습니다.
- Cloud ID 또는 Google Workspace에서 새 사용자 계정을 만들고 외부 IdP의 사용자에게 매핑되지 않은 기본 이메일 주소를 사용합니다.
- Cloud ID 또는 Google Workspace에 외부 IdP의 ID에 매핑되는 사용자 계정이 있지만 외부 IdP에서 ID를 삭제합니다. 예를 들어 직원이 퇴사하는 경우 ID를 삭제할 수 있습니다.
Cloud ID 또는 Google Workspace에서 싱글 사인온(SSO)을 사용 설정하면 최고 관리자를 제외한 모든 사용자가 싱글 사인온(SSO)을 사용해야 합니다. 외부 IdP의 ID에 매핑되지 않는 Cloud ID 또는 Google Workspace 사용자 계정의 경우 싱글 사인온(SSO) 사용 시도가 실패합니다. 상대 계정이 없는 사용자 계정은 사실상 사용되지 않지만 다음과 같은 경우 계속 위험을 초래할 수 있습니다.
싱글 사인온(SSO)이 일시적으로 또는 영구적으로 사용 중지되면 사용자 계정을 다시 사용할 수 있습니다. 이렇게 하면 이전 직원이 회사 리소스에 로그인하고 액세스할 수 있습니다.
삭제된 사용자 계정의 이름이 재사용될 수 있습니다. 예를 들어 회사에 합류하는 직원은 몇 개월 또는 몇 년 전에 퇴사한 다른 직원과 동일한 이름을 공유할 수 있습니다. 이전 직원의 사용자 계정이 삭제된 경우 신규 직원에게 이전 직원이 사용한 사용자 이름을 할당할 수 있습니다.
신규 직원의 사용자 계정에 이전 직원과 다른 내부 ID가 있을 수 있습니다. 하지만 페더레이션 측면에서 두 사용자 계정 모두 Cloud ID 또는 Google Workspace의 동일한 기본 이메일 주소에 매핑되는 경우 동일한 것으로 간주됩니다. 따라서 신규 직원이 Google에 로그인하면 이전 직원의 기존 데이터, 설정, 권한을 '상속'할 수 있습니다.
Cloud ID 및 Google Workspace 최고 관리자는 싱글 사인온(SSO) 사용 요건에서 제외되지만 IdP에서 로그인이 시작되면 싱글 사인온(SSO)을 사용할 수 있습니다. IdP에서 시작한 싱글 사인온(SSO)을 사용하면 최고 관리자가 외부 IdP에 상대 계정이 없는 경우 네임 스퀏팅(name squatting)에 민감해집니다.
Cloud ID 또는 Google Workspace에 최고 관리자 alice-admin@example.com이 있고 2단계 인증을 사용하지 않는 Alice의 경우를 예로 들어 보겠습니다. 이 경우 Alice의 비밀번호를 모르는 Mallory는 alice-admin@example.com에 매핑되는 외부 IdP에서 새 사용자를 만드는 방법을 찾습니다. 새로 생성된 이 사용자 계정에는 특별한 권한이 없을 수도 있고 Alice의 사용자 계정과 관련이 없을 수도 있지만, 현재 일반 ID를 Alice의 최고 관리자와 공유한다는 사실만으로도 Mallory는 IdP에서 시작한 싱글 사인온(SSO)을 사용하고 alice-admin@example.com으로 인증할 수 있습니다.
이러한 네임 스퀏팅(name squatting) 위험을 줄이려면 Cloud ID 또는 Google Workspace ID가 외부 IdP에 있는 ID의 하위 집합이어야 합니다. 이를 위해서는 외부 IdP에서 구현한 전체 사용자 계정 수명주기를 Cloud ID 또는 Google Workspace의 사용자 계정 수명 주기에 매핑하는 것이 가장 좋습니다.
전용 최고 관리자 사용자 사용
Google Workspace 및 Cloud ID 최고 관리자 계정에는 Cloud ID 또는 Google Workspace 계정뿐만 아니라 연결된 Google Cloud 조직에도 적용되는 강력한 권한이 있습니다. 일부 활동에만 최고 관리자 권한이 필요하므로 가능한 경우 최고 관리자 액세스 권한을 가진 관리자 수를 제한하고 계정 또는 Google Cloud 조직의 일일 관리에 권한이 낮은 사용자 계정을 사용하는 것이 좋습니다.
최고 관리자 액세스 권한이 필요한 관리자를 식별한 경우 전용 최고 관리자 계정을 만듭니다. 예를 들면 다음과 같습니다.
- ID가
alice@example.com인 사용자 계정을 만들고 일반 권한을 할당합니다. 이 계정은 일상적인 활동에 매일 사용해야 합니다. ID가
alice-admin@example.com인 두 번째 사용자 계정을 만들고 수퍼 사용자 권한을 할당합니다. 최고 관리자 권한이 필요한 경우에만 이 계정을 사용하는 것이 좋습니다.다음과 같이 이 이메일 주소로 전송된 알림 이메일이 사용자의 편지함으로 수신되도록 하려면 이메일 주소
alice-admin@example.com이 별칭이거나alice@example.com에 전달되도록 Google Workspace 또는 기존 이메일 시스템을 구성합니다.
Cloud ID 또는 Google Workspace의 ID가 계속해서 외부 IdP에 있는 ID의 하위 집합이 되도록 외부 IdP가 두 ID를 모두 인식하는지 확인합니다.
감사 로그에서 계정이 사용되는 위치와 방법을 추적할 수 있도록 이러한 전용 최고 관리자 계정의 명명 체계를 따르는 것이 좋습니다. 예를 들어 이전 예시와 같이 사용자 이름에 -admin을 추가합니다.
Google Workspace 및 Cloud ID의 서비스 사용자 수 제한
외부 IdP에는 직원의 사용자 계정뿐만 아니라 애플리케이션, 도구, 백그라운드 작업과 같은 머신 사용자를 위한 사용자 계정도 포함될 수 있습니다.
반면에 Google Cloud에서 애플리케이션이 Google API를 인증하고 액세스할 수 있도록 하는 가장 좋은 방법은 다음 중 하나를 구현하는 것입니다.
최종 사용자를 대신하여 Google API 또는 서비스에 액세스해야 하는 웹 애플리케이션 또는 도구는 OAuth 2.0 또는 OpenID Connect를 사용해야 합니다. 이러한 프로토콜 중 하나를 사용하여 애플리케이션은 먼저 사용자의 데이터 액세스에 대한 최종 사용자의 동의를 구하고 동의를 받았을 때 최종 사용자를 대신하여 액세스를 수행할 수 있습니다.
API 또는 서비스에 대한 액세스 권한이 최종 사용자가 아닌 애플리케이션 자체에 있는 경우 Google Cloud 서비스 계정을 사용하여 인증한 다음 IAM을 사용하여 리소스에 서비스 계정 액세스 권한을 부여하는 것이 가장 좋습니다.
IAM에서 Google Cloud 서비스 계정에 적절한 역할이 부여되면 이를 사용하여 Cloud API를 인증하고 사용할 수 있습니다. Directory API 또는 Drive API와 같이 Google Cloud 외부의 API에 대한 액세스 권한을 서비스 계정에 부여해야 하는 경우 Google Workspace 도메인 전체 위임을 사용할 수 있습니다.
G Suite 도메인 전체 위임을 사용하면 서비스 계정이 Cloud ID 또는 Google Workspace 사용자를 대신하여 작업할 수 있습니다. 위임은 강력한 권한이므로 OAuth 접근법이 실용적이지 않은 경우에만 Google Workspace 도메인 전체 위임을 사용하는 것이 좋습니다.
Google Workspace 도메인 전체 위임이 사용 설정된 모든 Google Cloud 서비스 계정에 전용 Cloud ID 또는 Google Workspace 사용자를 사용합니다. Cloud ID 또는 Google Workspace의 사용자가 계속해서 외부 IdP에 있는 사용자의 하위 집합이 되도록 외부 IdP에서 이 사용자를 만든 다음 Cloud ID 또는 Google Workspace에 프로비저닝합니다.
Cloud ID 및 Google Workspace에서 Google Workspace 도메인 전체 위임에 사용하지 않을 서비스 사용자를 만들지 마세요.
사용자 계정 수명 주기 매핑
외부 IdP의 사용자 계정은 특정 수명 주기를 따릅니다. 일반적으로 이 수명 주기는 직원과 회사 간의 고용 관계를 반영합니다.
- 조직에 합류하는 직원에 대한 새 사용자 계정이 생성됩니다.
- 사용자 계정이 일시적으로 정지되고 나중에 다시 활성화될 수 있습니다(예: 직원이 퇴사하는 경우).
- 사용자가 퇴사하는 경우 사용자 계정은 궁극적으로 삭제되기 전에 특정 보관 기간 동안 삭제되거나 정지 상태로 유지됩니다.
다음 다이어그램은 이 수명 주기를 보여줍니다.
이 섹션에는 Cloud ID 또는 Google Workspace의 사용자 계정 수명 주기가 외부 IdP의 해당 사용자 계정 수명 주기를 따르는지 확인하기 위한 권장사항이 나와 있습니다.
외부 IdP를 정보 소스로 지정
대부분의 인사 관리 정보 시스템(HRIS), IdP 및 어댑터는 단방향 사용자 프로비저닝만 지원합니다. 즉, HRIS 또는 IdP에서 수행된 변경사항은 Cloud ID 또는 Google Workspace로 전파되지만 Cloud ID 또는 Google Workspace에서 수행된 변경사항은 다시 전파되지 않습니다.
단방향 프로비저닝으로 인한 불일치를 방지하려면 외부 IdP를 정보 소스로 지정합니다. 외부 IdP(또는 HRIS)를 단독으로 사용하여 사용자를 생성, 수정, 삭제하고 자동 프로비저닝을 사용하여 변경사항이 Google Workspace 및 Cloud ID에 전파되도록 합니다. 외부 IdP를 정보 소스로 지정하면 불일치가 발생하거나 수동 수정이 IdP에 의해 재정의될 위험을 제한할 수 있습니다.
Cloud ID 또는 Google Workspace에 대한 사용자 프로비저닝 자동화
직원이 싱글 사인온(SSO)을 사용하여 Google에 인증하도록 하려면 먼저 Cloud ID 또는 Google Workspace에서 직원의 사용자 계정을 만들어야 합니다. 외부 IdP와 일관성을 유지하려면 Cloud ID 또는 Google Workspace에서 이러한 사용자 계정을 프로비저닝하는 프로세스를 자동화하는 것이 가장 좋습니다.
- 프로비저닝을 자동화하면 Cloud ID 또는 Google Workspace ID가 항상 외부 IdP의 ID의 하위 집합인지 확인할 수 있습니다.
- Cloud ID 또는 Google Workspace의 ID와 외부 IdP의 해당 ID 간에 의도치 않게 불일치가 발생할 위험을 최소화할 수 있습니다. 이메일 주소의 맞춤법 실수와 같은 불일치가 있는 경우 직원이 로그인하는 데 문제가 발생할 수 있습니다.
- 수동 관리 작업을 최소화할 수 있습니다.
HRIS를 사용하여 온보딩 프로세스를 관리하는 경우 사용자 프로비저닝을 자동화하는 한 가지 방법은 다음 다이어그램과 같이 사용자 계정을 외부 IdP와 Cloud ID 또는 Google Workspace 모두에 프로비저닝하도록 HRIS를 구성하는 것입니다.
이 설정이 제대로 작동하려면 사용자 계정이 서로 매핑되도록 HRIS가 사용자 계정을 프로비저닝해야 합니다. 또한 HRIS는 Cloud ID 또는 Google Workspace에 프로비저닝할 사용자 계정을 결정해야 합니다.
HRIS와 독립적으로 작동하는 사용자 프로비저닝을 자동화하는 또 다른 방법은 외부 IdP를 Cloud ID 또는 Google Workspace의 사용자를 프로비저닝하기 위한 신뢰할 수 있는 소스로 사용하는 것입니다. 이 설정에서 사용자 계정 매핑 및 사용자 계정 집합의 구성은 다음 다이어그램과 같이 IdP 또는 어댑터에서 관리됩니다.
Active Directory를 IdP로 사용하는 경우 Google Cloud 디렉터리 동기화를 사용하여 이 설정을 복제할 수 있습니다. Azure AD 또는 Okta 등의 다른 IdP에는 Google Workspace에 사용자를 프로비저닝하기 위한 어댑터가 내장되어 있습니다. Google Workspace 및 Cloud ID는 동일한 플랫폼을 기반으로 하고 동일한 API를 사용하므로 이러한 어댑터를 Cloud ID에도 사용할 수 있습니다.
Cloud ID 또는 Google Workspace에 정지 이벤트 전파
직원이 일시적으로 또는 영구적으로 조직을 떠나면 직원의 Google 서비스 액세스 권한을 취소하는 것이 좋습니다. 외부 IdP에서 직원의 사용자 계정을 정지하면 싱글 사인온(SSO)을 사용하여 Google에 인증하는 기능이 취소되지만 모든 Google 서비스에 대한 액세스 권한이 완전히 취소되지는 않습니다. 다음과 같은 상황이 발생할 수 있습니다.
- Cloud ID 또는 Google Workspace 사용자에게 활성 브라우저 세션이 있는 경우 세션은 계속 작동합니다. 이미 가져온 OAuth 토큰도 계속 유효합니다.
- 사용자에게 최고 관리자 권한이 있거나 네트워크 마스크를 구성한 경우 직원은 계속해서 비밀번호를 사용하여 로그인할 수 있습니다.
- 사용자 계정은 예산 알림을 포함한 알림을 Google Cloud에서 계속 받을 수 있습니다.
- 사용자에게 Google Workspace 라이선스가 할당된 경우 이메일은 사용자의 편지함으로 계속 전송되고 사용자는 주소록에 계속 표시되며 사용자는 여전히 Google 캘린더에 연락 가능한 것으로 나열될 수 있습니다.
- 사용자가 보안 수준이 낮은 앱을 사용하도록 허용하는 경우 사용자는 앱 비밀번호를 사용하여 Gmail, Google Calendar 및 기타 데이터에 계속 액세스할 수 있습니다.
Google 서비스에 대한 액세스 권한을 완전히 취소하려면 다음 방법으로 정지 이벤트를 Cloud ID 또는 Google Workspace로 전파합니다.
사용자 계정이 외부 IdP에서 정지될 때마다 Cloud ID 또는 Google Workspace의 해당 사용자 계정도 정지됩니다. Cloud ID 또는 Google Workspace에서 사용자를 정지하면 활성 브라우저 세션이 종료되고 토큰이 무효화되며 다른 모든 액세스 권한이 취소됩니다.
마찬가지로 외부 IdP에서 사용자 계정을 재활성화할 때는 Cloud ID 또는 Google Workspace에서도 해당 사용자 계정을 재활성화해야 합니다.
Cloud ID 또는 Google Workspace에서 사용자 계정을 정지하는 것은 비파괴적인 작업입니다. 사용자 계정이 정지된 경우 사용자의 데이터는 보관되고 Google Workspace 라이선스는 연결된 상태로 유지되며 Google Cloud에서 할당된 역할은 변경되지 않습니다.
Cloud ID 또는 Google Workspace에 삭제 이벤트 전파
직원이 영구적으로 조직을 떠나면 외부 IdP에 있는 직원의 사용자 계정을 정지할 뿐만 아니라 삭제하기로 결정할 수 있습니다.
외부 IdP에 있는 사용자 계정을 삭제하지만 해당 Cloud ID 또는 Google Workspace 사용자를 삭제하지 않으면 Cloud ID 및 Google Workspace의 사용자 집합은 더 이상 외부 IdP에 있는 사용자의 하위 집합이 아닙니다. 신규 직원이 퇴사한 직원과 이름이 같은 조직에 합류하면 나중에 문제가 될 수 있습니다. IdP에서 신규 직원의 사용자 계정을 만들면 이전 직원의 사용자 이름을 재사용하여 새 사용자 계정이 Cloud ID 또는 Google Workspace의 이전 사용자 계정에 매핑될 수 있습니다. 따라서 신규 직원은 이전 직원의 데이터 및 설정에 액세스할 수 있습니다.
IdP의 해당 사용자 계정이 삭제되는 즉시 Cloud ID 또는 Google Workspace 사용자를 삭제하면 분리된 Cloud ID 또는 Google Workspace 사용자 계정과 관련된 위험을 피할 수 있습니다.
Cloud ID 또는 Google Workspace 사용자를 삭제하는 것은 파괴적인 작업으로, 특정 기간 내에만 실행 취소할 수 있습니다. 사용자를 삭제하면 사용자가 사용하는 Google 서비스에 따라 관련 데이터가 영구적으로 삭제되어 규정 준수 요구사항을 충족하지 못할 수 있습니다.
영구적으로 삭제하기 전에 사용자의 설정과 데이터를 특정 보관 기간 동안 보존하려면 다음 방법 중 하나를 구현합니다.
사용자를 특정 보관 기간 동안 정지 상태로 유지하여 외부 IdP에서 사용자 계정 삭제를 지연합니다. 보관 기간이 경과하면 IdP 및 Cloud ID/Google Workspace에서 사용자를 삭제합니다.
외부 IdP에서 사용자 계정을 삭제할 때 해당 Cloud ID 또는 Google Workspace 사용자를 정지하고 기본 이메일 주소를 충돌이 발생할 가능성이 낮은 이름으로 변경합니다. 예를 들어
alice@example.com을obsolete-yyyymmdd-alice@example.com으로 변경합니다. 여기서yyyymmdd는 외부 IdP에서의 삭제 날짜를 반영합니다. 이름이 변경된 사용자 계정을 보관 기간 동안 정지 상태로 유지하고 보관 기간이 지난 후 삭제합니다.
정지된 사용자의 Google Workspace 데이터를 보존하려면 사용자에게 할당된 Google Workspace 라이선스를 유지하거나 사용자 아카이브 라이선스로 전환하여 Google Workspace Vault 보관 규칙이 계속 적용되고 사용자의 데이터가 보존되도록 합니다.
싱글 사인온(SSO)
Google Cloud, Google Ads, YouTube와 같은 서비스를 포함한 모든 Google 제품은 Google 로그인을 사용하여 사용자를 인증합니다. 서비스는 Google 로그인 화면이 표시되고 사용자의 이메일 주소를 묻는 accounts.google.com으로 사용자를 리디렉션하여 인증 프로세스를 시작합니다. 그런 다음 제공된 이메일 주소의 도메인에 따라 사용자 계정은 Gmail, 일반 계정 디렉터리 또는 Cloud ID나 Google Workspace 계정(도메인이 기본, 보조 또는 별칭 도메인과 일치하는 경우)에서 조회됩니다.
다음 다이어그램은 이 인증 프로세스를 보여줍니다.
싱글 사인온(SSO)을 사용하도록 Cloud ID 또는 Google Workspace 계정을 구성하면 사용자가 인증을 위해 외부 IdP로 리디렉션됩니다. 외부 IdP가 인증을 완료하면 결과가 SAML 어설션을 통해 Google 로그인으로 다시 릴레이됩니다. 이 SAML 어설션은 성공적인 인증의 증거가 됩니다. 어설션은 사용자의 이메일 주소를 포함하며 Google 로그인이 인증을 확인할 수 있도록 외부 IdP 인증서로 서명됩니다.
이 프로세스를 서비스 제공업체에서 시작한 싱글 사인온(SSO)이라고 하며 최고 관리자를 제외한 모든 사용자에게 적용됩니다. 최고 관리자는 외부 IdP로 리디렉션되지 않으며 대신 비밀번호를 입력하라는 메시지가 표시됩니다.
일부 IdP는 IdP에서 시작한 싱글 사인온(SSO)도 지원합니다. 이 모델에서 사용자는 외부 IdP에서 인증한 다음 Google Cloud 또는 Google Ads와 같은 Google 서비스를 가리키는 링크를 따릅니다. Cloud ID 또는 Google Workspace 계정에 싱글 사인온(SSO)이 사용 설정된 경우 해당 계정의 모든 사용자는 최고 관리자를 포함하여 IdP에서 시작한 싱글 사인온(SSO)을 사용할 수 있습니다.
SAML 어설션에 전달된 속성 집합 최소화
사용자가 외부 IdP에서 인증하면 Cloud ID 또는 Google Workspace는 외부 IdP에서 전달한 SAML 어설션을 사용하여 세션을 설정합니다. 이 프로세스에는 신뢰성을 확인하는 것 외에도 SAML 어설션의 NameID 값에 해당하는 Cloud ID 또는 Google Workspace 사용자 계정을 식별하는 작업이 포함됩니다.
NameID 값은 인증할 사용자 계정의 기본 이메일 주소를 포함해야 합니다. 이메일 주소는 대소문자를 구분합니다. 별칭 및 보조 이메일 주소는 고려되지 않습니다.
맞춤법 실수나 대소문자 불일치를 방지하려면 사용자 계정을 자동으로 프로비저닝하는 것이 좋습니다.
SAML 어설션에는 추가 속성이 포함될 수 있지만 인증 과정에서는 고려되지 않습니다. Cloud ID 또는 Google Workspace의 사용자 계정이 이 사용자 정보의 유일한 소스로 간주되므로 사용자의 이름, 성 또는 그룹 멤버십과 같은 정보가 포함된 속성은 무시됩니다.
SAML 어설션의 크기를 최소화하려면 Google 로그인에서 요구하지 않는 속성을 포함하지 않도록 IdP를 구성합니다.
google.com을 발급기관으로 사용
Google 로그인 세션은 단일 도구 또는 도메인으로 제한되지 않습니다. 대신 세션이 설정되면 사용자에게 액세스 권한이 부여된 모든 Google 서비스에서 세션이 유효합니다. 이 서비스 목록에는 Google Cloud 및 Google Ads와 같은 서비스와 Google 검색 및 YouTube와 같은 서비스가 포함될 수 있습니다.
세션의 글로벌 특성이 SAML 프로토콜 교환에 반영됩니다. 즉, 기본적으로 Google에서는 SAML 요청에서 google.com을 발급기관(SAML 요청의 Issuer 요소)으로 사용하며 SAML 어설션은 google.com을 잠재고객(SAML 응답의 Audience 요소)으로 지정합니다.
Cloud ID 또는 Google Workspace에서 싱글 사인온(SSO)을 구성할 때 도메인별 발급기관 사용 옵션을 사용 설정하여 이 기본값을 변경할 수 있습니다. 2개 이상의 Cloud ID 또는 Google Workspace 계정(따라서 여러 도메인)이 있고 IdP가 하나의 Cloud ID 또는 Google Workspace 계정에서 시작한 로그인과 다른 계정에서 시작한 로그인을 구분해야 하는 경우에만 도메인별 발급기관 옵션을 사용 설정합니다. 이 옵션을 사용 설정하면 SAML 요청이 google.com/a/DOMAIN을 발급기관으로 사용하고 google.com/a/DOMAIN을 잠재고객으로 사용합니다. 여기서 DOMAIN은 Cloud ID 또는 Google Workspace 계정의 기본 도메인입니다.
다른 모든 경우에는 google.com을 발급기관으로 사용하도록 기본 설정을 유지하고 google.com을 SAML 어설션에서 잠재고객으로 지정하도록 외부 IdP를 구성합니다. IdP에 따라 이 설정을 발급기관, 신뢰 당사자 트러스트 식별자 또는 엔티티 ID라고도 합니다.
Google 세션 길이 및 IdP 세션 길이 조정
사용자가 싱글 사인온(SSO) 프로세스를 완료하고 세션이 설정되면 Google 로그인 세션이 특정 기간 동안 활성 상태로 유지됩니다. 이 기간이 경과하거나 사용자가 로그아웃하면 싱글 사인온(SSO) 프로세스를 반복하여 사용자에게 다시 인증하도록 요청합니다.
기본적으로 Google 서비스의 세션 길이는 14일입니다. Cloud ID Premium 또는 Google Workspace Business 라이선스가 있는 사용자의 경우 기본 세션 길이를 다른 기간(예: 8시간)으로 변경할 수 있습니다.
Google Cloud에서 사용하는 세션 길이를 제어할 수 있습니다. Google Cloud 세션은 Google Cloud Console뿐만 아니라 Google Cloud CLI 및 기타 API 클라이언트에도 적용됩니다. 모든 Cloud ID 및 Google Workspace 계정 유형에서 Google Cloud 세션 길이를 설정할 수 있습니다.
대부분의 외부 IdP는 인증된 사용자의 세션도 유지합니다. IdP 세션의 길이가 Google 세션 길이보다 길면 자동으로 다시 인증할 수 있습니다. 즉, 사용자가 IdP로 리디렉션되지만 사용자 인증 정보를 다시 입력하지 않아도 됩니다. 자동 재인증으로 인해 Google 세션의 길이가 단축될 수 있습니다.
사용자가 Google 세션이 만료된 후에 사용자 인증 정보를 다시 입력하도록 하려면 IdP 세션 길이가 Google 세션 길이보다 짧도록 Google 세션 길이와 IdP 세션 길이를 구성합니다.
최고 관리자를 위한 싱글 사인온(SSO) 사용 중지
최고 관리자의 경우 SSO는 선택사항입니다. IdP에서 로그인이 시작되면 SSO를 사용할 수 있지만 사용자 이름과 비밀번호를 사용하여 로그인할 수도 있습니다.
최고 관리자가 IdP에서 시작한 싱글 사인온(SSO)을 사용하지 않으려면 다음 절차를 따라 위험을 줄일 수 있습니다.
- 최고 관리자에 대한 전용 조직 단위를 추가합니다.
- 싱글 사인온(SSO)을 중지하는 조직 단위에 SSO 프로필을 할당합니다.
그렇지 않고 IdP에서 시작한 싱글 사인온(SSO)을 사용하려면 최고 관리자에 대해 사후 SSO 인증을 시행해야 합니다.
다중 인증(MFA)
Cloud ID 또는 Google Workspace와 외부 IdP 간에 싱글 사인온(SSO)을 사용 설정하면 직원의 사용자 환경이 개선됩니다. 사용자는 더 적은 빈도로 인증해야 하며 Google 서비스에 액세스하기 위해 별도의 사용자 인증 정보를 기억할 필요가 없습니다.
하지만 사용자가 여러 서비스 및 환경에서 원활하게 인증할 수 있게 되면 도용된 사용자 인증 정보의 잠재적 영향이 증가합니다. 사용자의 사용자 이름과 비밀번호를 분실하거나 도난당한 경우 공격자는 이러한 사용자 인증 정보를 사용하여 기존 환경뿐만 아니라 하나 이상의 Google 서비스에서 리소스에 액세스할 수 있습니다.
사용자 인증 정보 도난 위험을 줄이려면 모든 사용자 계정에 다단계 인증을 사용하는 것이 가장 좋습니다.
사용자에 다단계 인증 시행
Cloud ID 또는 Google Workspace 계정에 싱글 사인온(SSO)을 구성한 경우 최고 관리자 권한이 없는 사용자는 외부 IdP를 사용하여 인증해야 합니다.
Google에 싱글 사인온(SSO)을 사용할 때마다 다단계 인증을 시행하려면 두 번째 요소(예: 일회성 코드 또는 USB 키)을 사용하도록 IdP를 구성합니다.
외부 IdP가 다단계 인증을 지원하지 않는 경우 사용자가 외부 IdP 인증에서 돌아온 후 Google에서 추가 확인을 수행하도록 사후 SSO 인증 사용 설정을 고려합니다.
네트워크 마스크를 사용하지 마세요. 사용자에 대해 다단계 인증을 회피하는 방법으로 악용될 수 있습니다.
최고 관리자 사용자에 Google 2단계 인증 시행
최고 관리자 사용자는 Google Cloud Console 또는 다른 Google 사이트에 로그인하려고 하면 외부 IdP로 리디렉션되지 않습니다. 대신 최고 관리자에게 사용자 이름과 비밀번호로 인증하라는 메시지가 표시됩니다.
최고 관리자는 사용자 이름과 비밀번호로 인증할 수 있으므로 IdP에서 적용할 수 있는 다단계 인증 정책이 적용되지 않습니다. 최고 관리자를 보호하려면 모든 최고 관리자에 Google 2단계 인증을 적용합니다.
최고 관리자는 일반적으로 다음 두 가지 카테고리 중 하나에 속합니다.
맞춤설정된 최고 관리자: 이러한 사용자는 맞춤설정되며 단일 관리자가 사용합니다. 모든 맞춤설정된 최고 관리자에 대해 2단계 인증을 시행하는 것이 좋습니다.
머신 최고 관리자: 이러한 사용자 계정을 피하는 것이 가장 좋지만 Cloud ID 또는 Google Workspace에서 사용자와 그룹을 관리하기 위해 클라우드 디렉터리 동기화 또는 Azure AD 갤러리 앱과 같은 도구를 사용 설정해야 할 수도 있습니다.
머신 최고 관리자 수를 제한하고 가능한 경우 2단계 인증을 사용 설정합니다.
싱글 사인온(SSO)을 사용하지 않는 사용자의 경우 전 세계, 조직 단위 또는 그룹별로 계정에 2단계 인증을 시행할 수 있습니다.
2단계 인증을 사용할 수 없는 머신 최고 관리자가 없는 경우 모든 사용자에 대해 이 인증을 시행하는 것이 좋습니다. 모든 사용자에 대해 2단계 인증을 시행하면 실수로 사용자가 누락될 위험을 피할 수 있습니다.
2단계 인증을 사용할 수 없는 일부 머신 최고 관리자가 있는 경우 전용 그룹을 사용하여 2단계 인증을 제어합니다. 새 그룹을 만들고 그룹에 대해 이 인증을 시행한 다음 모든 관련 최고 사용자를 추가합니다.
2단계 인증을 사용하여 최고 관리자를 보호하는 방법에 대한 자세한 내용은 관리자 계정을 위한 보안 권장사항을 참조하세요.
최고 관리자의 사용자에 사후 SSO 인증 시행
최고 관리자는 싱글 사인온(SSO)을 사용할 필요는 없지만 IdP에서 시작하면 싱글 사인온(SSO)을 사용할 수 있습니다. 최고 관리자가 IdP에서 시작한 로그인으로 인증하더라도 항상 2단계 인증을 사용하도록 하려면 모든 최고 관리자에 추가 SSO 인증 및 2단계 인증을 사용 설정합니다.
IdP가 이미 다단계 인증을 시행하는 경우 추가 SSO 확인이 중복된 작업으로 보일 수 있지만 이 설정을 사용하면 IdP가 손상된 경우 최고 관리자를 보호할 수 있습니다.
네트워크 마스크로 싱글 사인온(SSO) 제한 안함
Cloud ID 또는 Google Workspace에서 싱글 사인온(SSO)을 구성할 때 선택적으로 네트워크 마스크를 지정할 수 있습니다. 마스크를 지정하면 마스크와 일치하는 IP 주소를 가진 사용자에게만 싱글 사인온(SSO)이 적용됩니다. 다른 사용자가 로그인하면 비밀번호를 입력하라는 메시지가 표시됩니다.
네트워크 마스크를 사용하는 경우 외부 IdP에서 시행하는 다단계 인증이 약화될 수 있습니다. 예를 들어 사용자는 위치를 변경하거나 VPN을 사용하여 네트워크 마스크 적용 여부를 제어할 수 있습니다. 외부 IdP에서 다단계 인증을 시행하는 경우 사용자 또는 공격자가 외부 IdP에 구성된 다단계 인증 정책을 우회할 수 있습니다.
사용자의 위치나 IP 주소에 관계없이 다단계 인증이 일관되게 적용되도록 하려면 네트워크 마스크로 싱글 사인온(SSO)을 제한하지 않도록 합니다.
IP 주소로 리소스에 대한 액세스를 제한하려면 외부 IdP에서 적절한 IP 허용 목록을 구성하거나 Google Cloud의 컨텍스트 인식 액세스 및 Google Workspace를 사용합니다.
다음 단계
- 추가 권장사항 알아보기
- 외부 IdP를 Google Cloud와 페더레이션하기 위한 패턴 비교