직원 ID 제휴 사용 시 권장사항

직원 ID 제휴는 싱글 사인온 (SSO)을 사용 설정하기 위해 Google Cloud 조직을 외부 ID 공급업체 (IdP)와 제휴합니다.

이러한 권장사항을 적용하여 직원 ID 제휴를 효과적으로 사용하고 보안 위험을 최소화할 수 있습니다.

적절한 아키텍처 선택

다음 섹션에서는 요구사항에 맞는 제휴 아키텍처를 선택하기 위한 주요 요소를 설명합니다.

아키텍처 고려사항:

연합 아키텍처 패턴을 선택합니다.
사용자가 아닌 서비스별로 파티션 제휴 사용량을 구분합니다.

연합 아키텍처 패턴 선택

다음 네 가지 패턴은 Google Cloud조직을 외부 IdP와 페더레이션하는 일반적인 방법을 설명합니다.

연동하기 전에 각 패턴의 장점과 제한사항을 고려하여 요구사항에 맞는 패턴을 선택하세요. 자세한 내용은 ID 제휴를 위한 아키텍처 패턴을 참고하세요.

서비스별 파티션 제휴 사용량

일반적으로 사용자가 아닌 서비스별로 제휴 사용량을 파티셔닝하는 것이 좋습니다. 서비스별로 사용량을 파티셔닝하면 전반적으로 단점이 적습니다.

복잡성을 줄이려면 Cloud ID 또는 직원 ID 제휴를 사용하는 것이 좋습니다. 하지만 요구사항에 따라 하이브리드 패턴에 설명된 대로 두 가지를 동시에 사용해야 할 수도 있습니다.

Cloud ID 제휴와 직원 ID 제휴를 동시에 사용하는 경우 다음과 같은 방법으로 사용량을 파티셔닝할 수 있습니다.

  • 사용자별 파티셔닝: 사용자를 직원 ID 제휴를 사용하는 그룹과 Cloud ID 제휴를 사용하는 그룹의 두 그룹으로 나눕니다.

    • 장점: 각 사용자는 Google 서비스 전반에서 단일 ID를 사용하며 로그인 방법도 하나입니다.

    • 단점: 사용자로 파티셔닝하면 다음과 같은 여러 단점이 있습니다.

      • IAM 허용 정책에는 주 구성원 유형의 조합이 포함되어야 하고 Cloud ID 및 직원 ID 제휴 사용자에게 동일한 그룹을 사용할 수 없기 때문에 액세스 그룹 관리가 복잡할 수 있습니다.

      • 사용자가 로그인하는 방식에 따라 Google Cloud 콘솔, Gemini Enterprise, 기타 도구에서 서로 다른 URL을 사용하므로 서로 다른 동질 집단의 사용자는 서로 링크를 공유할 수 없습니다.

      • 서로 다른 사용자 집단의 사용자는 서로 다른 기능 세트에 액세스할 수 있습니다.

  • 서비스별로 파티셔닝:Google Cloud 또는 Gemini Enterprise와 같은 각 서비스가 Workforce Identity Federation 사용자 또는 Cloud ID 사용자에게만 액세스 권한을 부여하고 둘 다에게는 부여하지 않도록 구성합니다.

    • 장점: 관리를 간소화하고 다양한 사용자 간에 일관된 기능 집합을 보장합니다.
    • 단점: 일부 직원에게는 직원 ID 제휴를 사용하는 ID와 Cloud ID를 사용하는 ID 등 두 개의 ID가 할당되어야 할 수 있습니다.

서비스별로 파티셔닝하는 것이 좋습니다. 특히 Gemini Enterprise와 NotebookLM Enterprise를 다른 서비스와 분리하세요. Gemini Enterprise와 Google Cloud 콘솔은 서로 다른 작업을 위해 설계된 별도의 도구입니다. 로그인 프로세스의 차이는 전반적인 사용자 환경에 미치는 영향이 최소화되어야 합니다.

이 파티셔닝을 적용하려면 조직 정책 제약조건을 사용하세요.

그룹 거버넌스 강화

그룹을 사용하여 액세스를 관리하고 직원 ID 제휴를 효과적으로 사용하기 위해 이러한 그룹을 관리하는 명확한 프로세스를 설정해야 합니다.

리소스에 액세스할 수 있는 사용자의 권한은 인증 중에 결정되지 않습니다. 대신 사용자가 특정 리소스에 연결된 정책에 따라 리소스에 액세스하려고 할 때 액세스가 평가됩니다. 이러한 정책에는 다음이 포함될 수 있습니다.

정책은 개별 주 구성원 또는 주 구성원 집합의 액세스를 정의합니다.

  • 주 구성원: 주 구성원 식별자로 식별되는 인증된 사용자입니다. 직원 주 구성원 식별자는 다음과 유사합니다. principal://iam.googleapis.com/locations/global/workforcePools/ POOL_ID/subject/SUBJECT

    주 구성원 식별자에는 다음이 포함됩니다.

    • POOL_ID: 직원 ID 풀을 고유하게 식별합니다.
    • SUBJECT: 특정 사용자를 고유하게 식별합니다. 값과 형식은 IdP 및 속성 매핑에 따라 다릅니다.

  • 주 구성원 집합: 특정 기준과 일치하는 사용자 직원 ID 제휴는 그룹 기반(그룹 구성원), 속성 기반, 와일드 카드 (모든 사용자)의 세 가지 주 구성원 집합을 지원합니다.

개별 주체에 대한 액세스 권한을 부여하는 것은 특정 상황에서 유용할 수 있지만 다음과 같은 문제로 인해 확장성이 떨어지는 경향이 있습니다.

  • 주 구성원을 하나씩 추가하면 허용 정책이 늘어나 관리하기가 점점 더 어려워집니다.
  • 개별 액세스 관리에는 허용 정책을 자주 변경해야 합니다.
  • 시간이 지남에 따라 정책이 점점 더 일관되지 않을 수 있습니다.

확장 가능하고 효과적인 액세스 관리를 위해 그룹 기반 주 구성원 집합을 사용하면 다음과 같은 이점이 있습니다.

  • 기존 ID 도구 및 프로세스를 사용하여 그룹에서 회원을 추가하거나 삭제하여 액세스를 관리할 수 있습니다.
  • 허용 정책의 크기와 복잡성을 줄입니다.
  • 역할이 동일한 사용자에게 동일한 리소스 액세스 권한이 있는지 확인합니다.

그룹을 사용하여 액세스를 관리하려면 특정 방식으로 외부 IdP를 구성하고 IdP가 그룹에 적용하는 제한사항을 알고 있어야 합니다.

다음 섹션에서는 그룹을 효과적으로 사용하고 IdP 제한을 방지하기 위한 권장사항을 설명합니다.

권장사항:

다양한 유형의 그룹 구분하기
액세스 그룹을 사용하여 리소스에 대한 액세스 권한을 부여합니다.
강제 적용 그룹을 사용하여 리소스에 대한 액세스를 제한하세요.
조직 및 공동작업 그룹을 사용하여 액세스를 관리하지 마세요.
Gemini Enterprise에만 조직 그룹 및 공동작업 그룹을 사용하세요.

다양한 유형의 그룹 구분하기

다음 목록에서는 조직에서 일반적으로 사용되는 네 가지 유형의 그룹을 설명합니다.

  • 액세스 그룹: Google 서비스 또는Google Cloud 리소스에 대한 액세스 권한을 부여하는 데만 사용됩니다. 직무를 나타내며 이러한 직무를 수행하는 데 필요한 역할 할당을 간소화합니다.
  • 조직 그룹: 이러한 그룹은 조직 구조의 하위 집합을 나타내며 일반적으로 인사 데이터에서 가져옵니다. 부서, 보고 구조, 지리적 위치 또는 기타 조직 그룹을 기반으로 할 수 있습니다.
  • 공동작업 그룹: 이 그룹은 프로젝트에서 공동작업하거나 특정 주제를 논의하려는 작업 그룹, 프로젝트 회원 또는 사용자를 나타내며 이메일 배포에 사용될 수 있습니다. 공동작업 그룹은 임시 셀프 서비스 방식으로 생성되는 경우가 많습니다.
  • 시정 조치 그룹: 정책 그룹이라고도 하는 시정 조치 그룹은 액세스 권한을 부여하는 데 사용되는 액세스 그룹과 달리 액세스를 제한하는 데 사용됩니다. 예를 들어 주 구성원 액세스 경계, 거부 정책 또는 다중 인증(MFA) 시행이 있습니다. 액세스 그룹을 사용하면 회원이 자발적으로 그룹을 탈퇴할 수 있습니다. 하지만 시정 조치 그룹의 멤버십은 자발적이지 않습니다.

제휴해야 하는 그룹은 사용하는 서비스에 따라 달라집니다.

  • Google Cloud의 경우 액세스 그룹과 시정 조치 그룹만 있으면 됩니다.
  • Gemini Enterprise의 경우 액세스 그룹, 시행 그룹, 데이터 수집 기반 커넥터를 사용하는 경우 특정 조직 및 공동작업 그룹이 필요합니다.

직원 ID 제휴를 구성할 때는 IdP의 토큰 한도를 방지하기 위해 관련 없는 그룹 유형을 제외하세요. 이 접근 방식을 사용하면 IdP에서 부과하는 제한을 초과할 위험을 줄이고 그룹을 더 일관되게 사용할 수 있습니다.

액세스 그룹을 사용하여 리소스에 대한 액세스 권한 부여

액세스를 효과적으로 관리하려면 액세스 그룹에 매핑되는 주 구성원 집합을 사용하는 것이 좋습니다. 액세스 그룹은 액세스 권한을 제공하기 위해서만 존재합니다. 직무를 나타내며 이러한 기능을 수행하는 데 필요한 역할을 할당하는 작업을 간소화합니다.

다음을 실행하여 액세스 그룹을 구성합니다.

  1. IdP에서 직무를 나타내는 액세스 그룹을 만듭니다.
  2. IAM에서 사용할 수 있도록 액세스 그룹을 보안 주체 집합에 매핑합니다.
  3. 각 직무에 필요한 리소스에 대한 액세스 권한을 주 구성원 집합에 부여하는 정책 바인딩을 만듭니다.
  4. 외부 IdP에서 직무에 따라 그룹에 사용자를 추가하거나 삭제합니다.

다음과 같이 액세스 권한을 부여하는 정책에 액세스 그룹을 사용합니다.

  • IAM 허용 정책
  • VPC 서비스 제어 인그레스 규칙

액세스 그룹이 충분히 세분화되어 있는지 확인합니다. 예를 들어 다음 그룹은 유효한 액세스 그룹을 나타냅니다.

  • widget-sales-dashboard-readers: 특정 BigQuery 데이터 세트 및 연결된 대시보드에 대한 읽기 액세스 권한을 부여합니다.

  • dev-ssh-users: 개발 환경의 Compute Engine VM에 OS 로그인 액세스 권한을 부여합니다.

    반면 다음 유형의 그룹은 일반적으로 액세스 그룹으로 사용하기에 적합하지 않습니다.

    • cloud-admins와 같은 광범위한 관리자 그룹은 적용되는 워크로드 또는 환경에 관한 구체성이 부족한 경우가 많습니다.

    • australia-fte와 같은 조직 그룹은 직무 기능이 아닌 팀이나 위치와 같은 그룹을 나타냅니다.

    • security-discuss와 같은 커뮤니케이션 그룹은 액세스 그룹이 아닌 이메일 목록이나 공동작업을 위해 설계되었습니다.

    액세스 그룹을 세부적으로 관리하려면 Google Cloud에 온보딩하는 각 워크로드 또는 프로젝트에 대해 새 액세스 그룹을 만드세요. 이렇게 하면 Google Cloud에서 실행하는 워크로드 수에 맞게 액세스 그룹 수를 확장할 수 있습니다.

강제 적용 그룹을 사용하여 리소스에 대한 액세스 제한

시정 조치 그룹은 액세스 그룹과 유사하지만 일반적으로 다음과 같은 차이점이 있습니다.

  • 회원이 자발적으로 그룹을 탈퇴할 수 없습니다.
  • 워크로드에 따라 달라지지 않습니다.

다음과 같이 액세스를 제한하는 정책에는 적용 그룹을 사용하세요.

  • IAM 거부 정책
  • 주 구성원 액세스 경계
  • 조직 정책

시정 조치 그룹의 예로는 users-in-restricted-locations, fedramp-low, mfa-users가 있습니다. 강제 시행 그룹의 수는 일반적으로 적으며 사용자의 총 그룹 멤버십에 영향을 미치지 않을 가능성이 높습니다.

조직 및 공동작업 그룹을 사용하여 액세스를 관리하지 마세요.

액세스를 효과적으로 관리하려면 조직 또는 공동작업 그룹 대신 액세스 그룹과 시정 조치 그룹을 사용하세요.

조직 그룹은 조직 구조의 팀 또는 하위 집합을 나타내며 일반적으로 인사 데이터에서 가져옵니다. 이러한 그룹은 다음과 같은 이유로 Google Cloud 리소스에 대한 액세스 권한을 관리하는 데 적합하지 않습니다.

  • 시간이 지남에 따라 팀의 책임과 구성이 바뀔 수 있습니다. 예를 들어 한 팀이 다른 팀에 워크로드를 넘겨주거나 두 팀이 병합될 수 있습니다. 조직 그룹으로 액세스를 관리하는 경우 이러한 전환 중에 정책 변경사항이 연속적으로 발생할 수 있습니다.
  • 조직 그룹의 구성원에게 리소스에 대한 동일한 액세스 권한이 필요한 경우는 거의 없습니다. 조직 그룹에 액세스 권한을 부여하면 일부 구성원에게 필요한 것보다 더 많은 액세스 권한이 부여되는 경우가 많습니다.

공동작업 그룹은 일반적으로 자체 관리되므로 회원은 다른 회원의 승인을 받거나 승인 없이 가입할 수 있습니다. 협업 그룹을 사용하여 액세스 권한을 부여하면 권한이 과도하게 부여되고 권한이 에스컬레이션될 수 있습니다.

조직 및 공동작업 그룹이 액세스 관리에 사용되지 않도록 하려면 직원 ID 제휴에 사용되는 토큰 또는 어설션에서 이러한 그룹 멤버십을 제외하도록 IdP를 구성하세요.

Gemini Enterprise에만 조직 그룹 및 공동작업 그룹 사용

조직 및 공동작업 그룹은 Google Cloud 리소스에 대한 액세스 권한을 관리하는 데 적합하지 않지만 Gemini Enterprise에는 필요할 수 있습니다.

  • ACL 평가: 데이터 수집 기반 커넥터를 사용하여 Gemini Enterprise를 Microsoft 365와 통합할 때 조직 및 공동작업 그룹을 참조하는 액세스 제어 목록(ACL)이 있는 문서가 발생할 수 있습니다. Gemini Enterprise가 이러한 그룹의 사용자 멤버십에 액세스할 수 없는 경우 사용자가 해당 문서에 액세스할 권한이 있는지 올바르게 평가하지 못할 수 있습니다.
  • 노트북 공유: NotebookLM을 사용하면 사용자가 노트북을 공유할 수 있습니다. 사용자가 공동작업 그룹과 노트북을 공유하도록 허용하는 것이 개별 사용자에게 공유를 제한하는 것보다 더 편리한 경우가 많습니다.

조직 및 공동작업 그룹이 Gemini Enterprise에서만 사용되도록 하려면 다음과 같이 IdP를 구성하면 됩니다.

  • SCIM을 사용하여 조직 및 공동작업 그룹과 해당 멤버십을 프로비저닝합니다.
  • 직원 ID 제휴에 사용되는 토큰 또는 어설션에서 조직 및 공동작업 그룹 멤버십을 제외합니다.

직원 ID 풀 관리

직원 ID 풀은 주 구성원 식별자의 네임스페이스를 정의하고 제휴 구성의 컨테이너 역할을 합니다. 사용자 디렉터리와 달리 풀은 사용자 또는 그룹에 관한 정보를 저장하지 않습니다.

권장사항:

IdP당 단일 풀 사용
고유하고 의미 있는 풀 이름을 선택합니다.
풀을 권한이 높은 리소스로 취급
파트너에게 제휴를 확장할 때 위험을 고려하세요.

IdP당 단일 풀 사용

직원 ID 풀은 프로젝트 수준 리소스가 아닌 조직 수준 리소스입니다. 이 설계는 직원 ID 풀이 개별 프로젝트나 워크로드가 아닌 Google Cloud 조직 전체의 인증을 관리한다는 점을 반영합니다.

대부분의 조직에서 직원 ID 풀 수는 IdP 수와 일치해야 합니다.

  • 조직에서 단일 IdP를 사용하여 인증을 관리하는 경우 단일 직원 아이덴티티 풀을 사용합니다.
  • 조직에서 인수 등의 이유로 여러 IdP를 사용하는 경우 IdP당 하나의 직원 ID 풀을 사용하세요.

직원 ID 풀 수를 제한하면 다음을 보장할 수 있습니다.

  • 새 워크로드를 Google Cloud에 온보딩할 때는 직원 ID 풀을 만들거나 수정할 필요가 없습니다.
  • IAM을 사용하여 Google Cloud 개별 사용자가 액세스할 수 있는 프로젝트와 리소스를 제어할 수 있습니다.

고유하고 의미 있는 풀 이름 선택

주 구성원 식별자를 전역적으로 고유하게 만들기 위해 직원 ID는 직원 ID 풀 이름을 주 구성원 식별자로 인코딩합니다. 직원 ID 풀의 이름을 선택할 때는 다음 제약 조건을 고려하세요.

  • 고유성: Google Cloud 에서 고유하고 다른 조직에서 사용하지 않는 이름을 선택합니다.
  • 불변성: 직원 아이덴티티 풀 이름은 변경할 수 없습니다. 일시적인 이니셔티브 이름을 피하고 시간이 지나도 의미가 있는 이름을 선택하세요.
  • 사용자 환경: 로그인 구성에 따라 사용자가 로그인 중에 풀 이름을 입력해야 할 수 있습니다. 기억하기 쉬운 닉네임을 선택하세요.

풀을 높은 권한이 부여된 리소스로 취급

직원 ID 풀과 공급자는 사용자가 로그인하는 방식을 결정하고 외부 IdP에서 ID와 그룹 멤버십이 파생되는 방식을 제어합니다. 이러한 구성요소는 인증 로직을 제어하므로 Google Cloud 조직의 보안에 매우 중요합니다. 이러한 구성요소가 손상되면 악의적인 행위자가 스푸핑 공격을 실행할 수 있습니다.

스푸핑 공격을 수행하기 위해 악의적인 행위자는 다음 작업을 시도할 수 있습니다.

  • 속성 매핑 수정: 속성 매핑을 변경하면 악의적인 행위자가 다른 사용자로 인증하고 무단으로 권한이 있는 액세스 권한을 얻을 수 있습니다.
  • 악의적인 공급자 추가: 공급자를 추가하면 악의적인 행위자가 조직의 IdP를 우회하고 자신이 관리하는 다른 IdP를 사용하여 인증할 수 있습니다.

직원 ID 풀과 제공업체는 보안이 중요한 리소스이므로 다음 보호가 필요합니다.

  • 비연동 사용자에 대한 액세스 제한: 하나 이상의 긴급 액세스 사용자를 포함하여 소수의 Cloud ID 또는 Google Workspace 사용자에 대한 관리 액세스를 제한합니다.
  • 관리 사용자 보호: 모든 관리 사용자 및 긴급 액세스 사용자에게 2단계 인증을 요구합니다.
  • 적시 액세스: Privileged Access Manager (PAM)를 사용하여 영구 액세스 권한을 부여하는 대신 적시에 관리 액세스 권한을 부여합니다.

파트너에게 제휴를 확장할 때 위험 고려

직원 ID 제휴를 사용하여 외부 IdP와 Google Cloud 를 제휴하면 트러스트 관계가 설정됩니다. 페더레이션을 사용하면 외부 IdP가 다음 작업을 수행합니다.

  • 보안 요구사항을 충족하는 다중 인증 (MFA)을 실행합니다.
  • 사용자 ID 및 그룹 멤버십에 관한 정확한 어설션을 만듭니다.
  • 사용자가 신속하게 온보딩 해제되고 그룹 멤버십이 현재 역할을 정확하게 반영하도록 하는 ID 거버넌스 프로세스를 따릅니다.

직원 ID 제휴는 외부 IdP에서 이루어진 어설션을 검증하는 제한된 메커니즘을 제공합니다. 특히 직원 ID 제휴는 Cloud Identity와 동일한 방식으로 SSO 후 MFA를 지원하지 않습니다.

직원 ID 제휴를 사용하여 외부 파트너 또는 계약업체가 Google Cloud 리소스에 액세스하도록 허용하기 전에 이 수준의 신뢰가 적절한지 확인하세요. 파트너와 파트너의 IdP가 보안 표준을 일관되게 준수한다고 신뢰하지 않는 한 파트너 액세스에 직원 ID 제휴를 사용하지 마세요.

직원 ID 풀 공급업체 관리

직원 ID 풀 공급업체는 외부 IdP와의 제휴 관계를 정의하고 다음의 구성을 포함합니다.

  • 싱글 사인온(SSO)에 사용할 IdP입니다.
  • IdP에서 제공하는 토큰 또는 어설션에서 주 구성원 식별자를 파생하는 데 사용할 속성 매핑입니다.
  • 선택사항: 그룹 멤버십 정보를 조회하는 데 사용할 SCIM 테넌트입니다.

권장사항:

의미 있는 제공업체 이름을 선택합니다.
IdP의 애플리케이션 포털을 사용하여 개별 서비스를 노출합니다.
소유자 충돌을 방지하기 위해 풀별로 단일 프로바이더를 사용합니다.
Google Cloud 콘솔과 Gemini Enterprise에 동일한 풀과 제공업체 사용
테넌트별 발급기관 URI를 사용합니다.
OpenID Connect (OIDC) 암시적 흐름을 사용하지 마세요.

의미 있는 제공업체 이름 선택

직원 ID 풀 프로바이더를 만들 때 이름을 할당해야 합니다. 직원 ID 풀 이름과 달리 이 이름은 전역적으로 고유할 필요가 없으며 주 구성원 식별자로 인코딩되지 않습니다. 하지만 로그인 구성에 따라 사용자가 로그인 중에 제공업체 이름을 입력해야 할 수 있습니다. 사용자 환경을 개선하려면 의미 있고 기억하기 쉬운 이름을 선택하세요(예: entra 또는 staff).

oidc 또는 saml과 같은 이름은 사용자에게 생소할 수 있으므로 사용하지 마세요.

IdP 애플리케이션 포털에 개별 서비스 표시

Microsoft Entra ID 및 Okta와 같은 ID 공급업체는 사용자가 할당된 애플리케이션을 검색하고 액세스할 수 있는 애플리케이션 포털을 제공합니다. 포털을 사용하여 다음을 실행하여 사용자 환경을 최적화합니다.

  • 단일 Google Cloud 링크를 표시하는 대신 관련 Google 서비스를 개별적으로 표시하도록 포털을 구성합니다.
  • 사용자를 자동으로 로그인하도록 링크를 구성합니다.

다음 표에는 직원 ID 제휴를 지원하는 일반적인 Google 서비스와 자동 로그인 URL이 나와 있습니다.

애플리케이션 URL
Google Cloud 직원 ID 제휴 콘솔(콘솔(제휴)이라고도 함) https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fconsole.cloud.google
Gemini Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fvertexaisearch.cloud.google%2Fhome%2Fcid%2FWEBAPP_ID
NotebookLM Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fnotebooklm.cloud.google%2Fglobal%2F%3Fproject%3DPROJECT_NUMBER
IAP 웹 앱 https://iap.example.com/와 같은 앱 URL

다음을 바꿉니다.

  • POOL: 직원 ID 풀 이름
  • PROVIDER: 풀 제공업체 이름
  • WEBAPP_ID: Gemini Enterprise 웹 앱 ID입니다.
  • PROJECT_NUMBER: NotebookLM Enterprise 프로젝트 번호입니다.

주체 충돌 방지를 위해 풀별로 단일 제공업체 사용

직원 ID 제휴를 사용하여 직원 풀에 여러 제공업체를 추가할 수 있습니다. 두 번째 제공업체를 추가하는 것은 사용자가 다른 IdP를 사용하여 인증하도록 일시적으로 허용하는 마이그레이션 중에 유용합니다. 일시적인 상황을 제외하고 다음과 같은 이유로 여러 제공업체를 사용하지 마세요.

  • 주체 충돌: 제공업체를 여러 개 사용하면 주체 충돌 위험이 있습니다. 이러한 충돌에서 한 제공업체의 google.subject 속성 매핑은 다른 제공업체와 동일한 값을 반환합니다. 이 충돌로 인해 여러 외부 ID가 동일한 IAM 주 구성원에 매핑되어 Cloud 감사 로그에서 외부 ID를 식별하지 못할 수 있습니다.
  • IAP 호환성: IAP에서는 인증되지 않은 사용자를 IdP로 자동 리디렉션하기 위해 직원 ID 풀에 단일 공급업체가 있어야 합니다. 추가 제공업체를 추가하면 IAP가 사용자를 인증할 수 없습니다.

여러 프로바이더와 제휴가 필요하면 여러 인력 풀을 만들고 풀마다 하나의 프로바이더를 구성합니다.

Google Cloud 콘솔과 Gemini Enterprise에 동일한 풀 및 제공업체 사용

Gemini Enterprise와 Google Cloud모두에 직원 ID 제휴를 사용하는 경우 사용자가 다시 로그인하지 않고 두 서비스에 동시에 액세스할 수 있도록 단일 제공업체를 사용하세요. 속성 매핑이 다른 별도의 제공업체를 사용하는 경우 사용자가 로그인하는 제공업체에 따라 리소스에 대한 액세스가 달라지는 상황이 발생할 수 있습니다.

테넌트별 발급기관 URI 사용

제공업체를 구성할 때 IdP를 고유하게 식별하는 발급기관 URI를 지정합니다. 하지만 IdP 구성에 따라 발급자 URI가 조직의 테넌트에 고유하지 않을 수 있습니다. 예를 들어 Microsoft Entra ID 공통 엔드포인트(https://login.microsoftonline.com/common/v2.0)와 같은 일반 또는 공유 발급기관 URI를 사용하는 경우 다른 조직의 사용자가 Google Cloud조직에 인증하도록 실수로 허용할 수 있습니다.

의도치 않은 교차 테넌트 액세스를 방지하려면 테넌트별 발급기관 URI를 사용하세요. IdP에서 테넌트별 발급기관 URI를 제공하지 않는 경우 속성 조건을 구성하여 특정 테넌트에 대한 액세스를 제한합니다.

OpenID Connect (OIDC) 암시적 흐름 사용 방지

OIDC 프로바이더를 구성할 때는 암시적 흐름보다 승인 코드 플로우를 사용하는 것이 좋습니다. 암시적 흐름은 토큰 유출 및 삽입에 취약하기 때문에 OAuth 사양 버전 2.1에서 지원 중단되었습니다. 승인 코드 플로우를 사용하면 토큰 가로채기 위험을 줄일 수 있습니다.

사용자 관리

직원 ID 제휴를 사용하여 사용자를 관리할 수 있습니다. 직원 ID 제휴는 다음 단계를 실행하여 사용자의 토큰 또는 어설션에서 사용자의 주 구성원 식별자를 파생시킵니다.

  1. google.subject의 속성 매핑을 적용하여 주체 식별자를 확인합니다. 주체 식별자는 직원 ID 풀 내에서 사용자를 고유하게 식별해야 하지만 Google Cloud전반에서 고유할 필요는 없습니다.

  2. 직원 ID 풀을 식별하는 접두사에 주제 식별자를 추가하여 주 구성원 식별자를 파생시킵니다. 결과 주 구성원 식별자는 Google Cloud 에서 고유하며 형식은 다음과 같습니다.

    principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/\
subject/SUBJECT

직원 ID 제휴를 사용하여 인증된 사용자가 리소스에 액세스하면 IAM은 주 구성원 식별자를 사용하여 허용 정책의 역할 바인딩을 평가하고 Cloud 감사 로그에 기록합니다.

권장사항:

변경 불가능한 주체 식별자 사용
주체 식별자를 재사용하지 마세요.
Microsoft Entra ID: UPN을 주체 식별자로 사용

변경할 수 없는 주체 식별자 사용

사용자의 주체 식별자가 변경되면 주 구성원 식별자가 변경됩니다. 따라서 Google Cloud 더 이상 동일한 사용자로 인식하지 않습니다.

  • 새 주 구성원 식별자가 허용 정책에 나열된 주 구성원 식별자와 더 이상 일치하지 않기 때문에 사용자가 이전에 액세스 권한을 부여받은 리소스에 액세스할 수 없습니다.
  • Cloud 감사 로그 항목에는 새 주 구성원 식별자만 포함되며 이전 주 구성원 식별자를 사용한 로그와 더 이상 상관관계를 지정할 수 없습니다.

사용자의 주 구성원 식별자를 안정적으로 유지하려면 google.subject의 값이 안정적인 속성 매핑을 사용하세요.

많은 IdP가 사용자를 위해 고유한 숫자 또는 UUID 형식 식별자를 자동으로 생성합니다. 이러한 식별자는 고유하고 안정적이므로 google.subject에 적합합니다. 하지만 이러한 식별자를 google.subject로 사용하면 작업하기 어려울 수 있는 길고 난해한 주 구성원 식별자가 생성될 수 있습니다.

google.subject의 식별자를 선택하려면 우선순위가 높은 순서대로 다음 요구사항을 고려하세요.

  1. 고유성: 값은 IdP에서 사용자를 고유하게 식별합니다.
  2. 유용성: 값이 의미가 있거나 IdP의 사용자 디렉터리에서 쉽게 검색할 수 있습니다.
  3. 불변성: 값이 불변이거나 관리자만 변경할 수 있습니다.

주체 식별자를 재사용하지 마세요.

많은 IdP가 특정 사용자 식별자에 고유성 제약 조건을 적용하지만 식별자를 재사용할 수 있도록 허용합니다. 예를 들어 IdP에서 사용자 이름이 bob인 사용자를 두 명 만드는 것을 허용하지 않을 수 있습니다. 하지만 사용자 계정 bob를 삭제하면 IdP에서 신규 사용자 계정을 만들고 사용자 이름 bob를 다시 할당할 수 있습니다.

google.subject에 대한 공급자의 속성 매핑이 재사용을 허용하는 사용자 식별자를 참조하는 경우 주체 충돌이 발생할 수 있습니다. Workforce Identity Federation은 google.subject가 동일한 경우 이전 사용자와 신규 사용자를 구분할 수 없습니다. 따라서 신규 사용자가 이전 사용자 전용 리소스에 액세스할 수 있습니다.

주체 충돌을 방지하려면 다음 중 하나 또는 둘 다를 수행하세요.

Microsoft Entra ID: UPN을 주체 식별자로 사용

이 권장사항은 Microsoft Entra ID를 IdP로 사용하는 경우에만 적용됩니다.

Microsoft Entra ID를 사용하는 경우 주체 식별자로 사용할 수 있는 식별자는 다음과 같습니다.

  • 사용자 주 구성원 이름 (upn)
  • 객체 ID (oid)
  • 이메일 주소 (proxyAddresses의 기본 주소)

이러한 옵션 중에서 다음과 같은 이유로 사용자 프린시펄 이름을 주체 식별자로 사용하는 것이 좋습니다.

  • 모든 사용자에게는 사용자 보안 주체 이름이 있습니다.
  • 사용자 보안 주체 이름은 사용자를 고유하게 식별합니다.
  • 사용자 주 구성원 이름은 의미가 있고 작업하기가 간단한 경향이 있습니다.
  • 사용자 주 구성원 이름에는 사용자가 연결된 Microsoft Entra ID 테넌트를 고유하게 식별하는 도메인 이름이 포함됩니다.
  • 조직에 사용자 주 구성원 식별자의 재사용을 금지하거나 관리하는 정책이 있을 수 있습니다.

반면 사용자의 객체 ID와 이메일 주소는 다음과 같은 이유로 적합하지 않습니다.

  • 객체 ID (oid)는 변경할 수 없지만 GUID로 형식이 지정됩니다. 이 형식은 작업하기 어렵고 사람에게 의미가 없습니다.
  • 이메일 주소는 필수 속성이 아니며 일부 사용자의 경우 채워지지 않을 수 있습니다.

어떤 식별자를 선택하든 식별자를 소문자로 강제 변환하는 등의 변환을 적용하지 않는 것이 좋습니다.

그룹 관리

직원 ID 제휴는 다음 소스에서 사용자의 그룹 멤버십을 확인할 수 있습니다.

  • IdP에서 제공하는 SAML 어설션 또는 ID 토큰입니다.
  • Microsoft Entra ID를 IdP로 사용하는 경우 Microsoft Graph API
  • 직원 ID 풀 제공업체와 연결된 SCIM 테넌트입니다.

기본적으로 직원 ID 제휴는 SAML 어설션 또는 ID 토큰만 사용합니다.

소스 Google Cloud Gemini Enterprise
SAML 또는 ID 토큰
Microsoft Graph API - -
SCIM 테넌트 - -

Microsoft Entra ID를 IdP로 사용하는 경우 추가 속성 기능을 사용 설정할 수 있습니다. 그러면 직원 ID 제휴는 Microsoft Graph API만 그룹 멤버십의 소스로 사용합니다.

소스 Google Cloud Gemini Enterprise
SAML 또는 ID 토큰 - -
Microsoft Graph API
SCIM 테넌트 - -

Gemini Enterprise를 사용하는 경우 SCIM 테넌트를 사용하도록 직원 ID 제휴를 구성할 수 있으며, 이 경우 다음과 같이 동작이 변경됩니다.

  • Gemini Enterprise는 SCIM 테넌트의 그룹 멤버십을 사용하고 SAML 어설션 또는 ID 토큰의 그룹 멤버십 정보는 무시합니다.
  • Google Cloud SAML 어설션 또는 ID 토큰의 그룹 멤버십 정보를 사용하고 SCIM 테넌트의 그룹 멤버십 정보는 무시합니다.
소스 Google Cloud Gemini Enterprise
SAML 또는 ID 토큰 -
Microsoft Graph API - -
SCIM 테넌트 -

각 그룹 멤버십에 대해 직원 ID 제휴는 다음 단계를 실행하여 주 구성원 식별자를 파생시킵니다.

  1. 다음 중 하나를 수행하여 그룹 식별자를 확인합니다.
    • SAML 어설션 또는 ID 토큰: google.groups의 속성 매핑을 적용합니다.
    • SCIM 테넌트: google.group의 클레임 매핑을 적용합니다.
    • Microsoft Graph API: 제공업체 구성에서 extra-attributes-type를 따릅니다.

  2. 직원 ID 풀을 식별하는 접두사에 그룹 식별자를 추가하여 주 구성원 식별자를 파생시킵니다. 결과 주 구성원 식별자는 Google Cloud 에서 고유하며 형식은 다음과 같습니다.

    principalSet://iam.googleapis.com/locations/global/workforcePools/\
POOL_ID/group/GROUP_ID

직원 ID 제휴를 사용하여 인증된 사용자가 리소스에 액세스하면 IAM은 이러한 주 구성원 식별자를 사용하여 허용 정책의 역할 바인딩을 평가합니다.

권장사항:

변경 불가능한 그룹 식별자 사용
어설션 또는 토큰의 그룹 멤버십 줄이기
Microsoft Entra ID: 객체 ID를 그룹 식별자로 사용.

변경 불가능한 그룹 식별자 사용

모든 IAM 정책은 주 구성원 식별자로 그룹을 참조합니다. ID 공급업체에서 그룹 이름을 변경하여 식별자가 변경되면Google Cloud 에서 더 이상 동일한 그룹으로 인식하지 않습니다.

  • 기존 IAM 역할 바인딩은 이전 주 구성원 식별자를 계속 참조하므로 무효화됩니다.
  • 그룹의 새 주 구성원 식별자가 더 이상 IAM 역할 바인딩과 일치하지 않으므로 이름이 바뀐 그룹의 구성원은 액세스 권한을 잃게 됩니다.

이러한 중단을 방지하려면 IdP에서 생성된 고유 ID와 같이 안정적이고 변경 불가능한 값을 사용하도록 속성 및 클레임 매핑을 구성하세요. 조직 변경 중에 변경될 수 있으므로 표시 이름이나 이메일 주소를 그룹 식별자로 사용하지 마세요.

어설션 또는 토큰의 그룹 멤버십 줄이기

기본적으로 IdP는 Gemini Enterprise 및 Google Cloud 리소스에 대한 액세스를 관리하는 데 필요한 것보다 더 많은 그룹 멤버십을 SAML 어설션 또는 ID 토큰에 포함할 수 있습니다. 불필요한 그룹 구성원을 포함하면 다음과 같은 여러 위험이 발생합니다.

  • 액세스 권한 부분 손실: 많은 IDP가 토큰이나 어설션에 포함할 수 있는 그룹 멤버십 수에 제한을 적용합니다. 사용자가 이 한도를 초과하면 (그룹 초과) IdP에서 일부 그룹 멤버십을 삭제하여 사용자가 특정 리소스에 액세스할 수 없게 될 수 있습니다.
  • 로그인 실패: 직원 ID 제휴는 google.groups 속성 매핑에서 생성할 수 있는 그룹 멤버십의 크기와 수를 제한합니다. 이러한 한도 중 하나를 초과하는 사용자는 로그인할 수 없습니다.
  • 일관되지 않은 그룹 사용: 그룹을 Google Cloud에 노출하는 경우 프로젝트 소유자는 특정 그룹이Google Cloud에서 사용되도록 의도하지 않았더라도 해당 그룹을 사용하여 리소스에 대한 액세스를 관리할 수 있습니다.

다음 방법을 사용하면 이러한 위험을 완화하고 어설션 또는 토큰의 그룹 멤버십 수를 줄일 수 있습니다.

  • 그룹 유형별 필터링: Microsoft Entra ID를 비롯한 일부 IDP에서는 어설션이나 토큰에 포함할 그룹을 결정하는 필터를 구성할 수 있습니다. 구성 및 사용할 서비스에 따라 관련이 없는 그룹 유형을 제외하도록 필터를 구성할 수 있습니다.

    다음 표에는 사용하려는 서비스에 따라 어설션 또는 토큰에 포함해야 하는 그룹 유형이 나와 있습니다.

    그룹 유형 Google Cloud Gemini (동기화 없음) Gemini (SCIM)
    액세스 그룹 -
    시정 조치 그룹 -
    조직 그룹 필요하지 않음 * -
    공동작업 그룹 필요하지 않음 * -

    * 데이터 수집 기반 커넥터를 사용하는 경우에만 필요합니다.

    • Google Cloud에 대한 액세스를 관리하려면 액세스 그룹과 시행 그룹을 포함해야 합니다.
    • Gemini Enterprise에 대한 액세스를 관리하는 데 필요한 필터는 SCIM 사용 여부에 따라 다릅니다. SCIM을 사용하는 경우 Gemini Enterprise는 어설션 또는 토큰에 포함된 그룹 멤버십을 무시하므로 Gemini Enterprise에만 해당하는 그룹을 포함할 필요가 없습니다. SCIM을 사용하지 않는 경우 Gemini Enterprise에 필요한 액세스 그룹과 시행 그룹을 포함해야 합니다. 데이터 수집 기반 커넥터를 사용할 계획인지에 따라 특정 조직 및 공동작업 그룹을 포함해야 할 수도 있습니다.

  • 할당: Microsoft Entra ID를 비롯한 일부 IDP에서는 토큰 및 어설션의 그룹 멤버십을 할당된 그룹으로 제한할 수 있습니다. 할당된 그룹은 신뢰 당사자 구성에 명시적으로 할당한 그룹입니다.

  • 추가 속성 필터: Microsoft Entra ID를 사용하고 추가 속성 기능을 사용 설정한 경우 --extra-attributes-filter 플래그를 사용하여 필터를 지정할 수 있습니다. 직원 ID 제휴는 그룹 멤버십을 요청할 때 이 필터를 Microsoft Graph API에 전달합니다.

필터를 테스트하거나 문제를 해결하려면 Google Cloud 콘솔에서 IDP 토큰 디버그 도구를 사용하거나 상세 감사 로깅을 사용 설정하세요.

Microsoft Entra ID: 객체 ID를 그룹 식별자로 사용

이 권장사항은 Microsoft Entra ID를 IdP로 사용하는 경우에만 적용됩니다.

Microsoft Entra ID를 사용하는 경우 그룹 식별자로 사용할 수 있는 식별자는 다음과 같습니다.

  • 객체 ID (oid)
  • 이메일 주소
  • 표시 이름

이러한 옵션 중에서 다음과 같은 이유로 객체 ID (oid)를 그룹 식별자로 사용하는 것이 좋습니다.

  • 모든 그룹에는 객체 ID가 있습니다. 반면 이메일 주소는 Microsoft 365 그룹에만 채워질 수 있는 선택사항 필드입니다.
  • 객체 ID는 고유하며 변경할 수 없습니다. 반면 그룹의 표시 이름은 변경될 수 있으며 고유하지 않을 수도 있습니다.

어떤 식별자를 선택하든 식별자를 소문자로 강제 변환하는 등의 변환을 적용하지 않는 것이 좋습니다.

액세스 관리

액세스 한도 및 적시 (JIT) 관리에 관한 권장사항

권장사항:

비상 액세스에 Cloud ID 사용자 사용
높은 권한 액세스에 Cloud ID 사용
조직 정책 제약조건을 사용하여 페더레이션 관리
풀의 모든 구성원에 액세스 권한을 부여하지 않습니다.
세션 길이 제한
JIT 액세스 요구사항에 따라 세션 길이 조정.

긴급 액세스에 Cloud ID 사용자 사용

Google Cloud 환경에 대한 지속적인 액세스를 보장하려면 각 환경에 대해 긴급 액세스 사용자를 만드세요.

긴급 액세스 사용자는 서비스가 잘못 구성되거나, 손상되거나, 정상적으로 작동하지 않을 때 Google Cloud 환경에 대한 액세스를 제공합니다. 긴급 액세스 사용자는 높은 수준의 권한을 가지고 있습니다. 직원 ID 제휴를 사용하여 긴급 액세스 사용자를 인증하면 다음과 같은 위험이 발생합니다.

  • 직원 ID 풀 공급업체 구성에 오류가 있으면 계정이 잠길 수 있습니다.
  • 외부 IdP에 영향을 미치는 서비스 중단으로 인해 가장 필요할 때 긴급 액세스 사용자를 사용하지 못할 수 있습니다.
  • 외부 IdP가 손상되면 악의적인 행위자가 긴급 액세스 사용자로 인증하고 Google Cloud리소스에 대한 광범위한 액세스 권한을 얻을 수 있습니다.

이러한 위험을 완화하려면 다른 사용자에 대해 직원 ID 제휴를 사용하더라도 비상 액세스 사용자에게는 Cloud ID 또는 Google Workspace를 사용하세요.

  • Cloud ID에서 긴급 액세스 사용자를 만듭니다.
  • 이러한 사용자를 싱글 사인온에서 제외하고 사용자 이름과 비밀번호를 사용하여 인증하도록 허용합니다.
  • 보안 키를 사용하여 2단계 인증에 등록하여 이러한 사용자를 보호하세요.

긴급 액세스 사용자에 관한 자세한 내용은 Google Cloud에 대한 지속적인 액세스를 위한 권장사항을 참고하세요.

높은 권한 액세스에 Cloud ID 사용

권한이 높은 사용자는 Google Cloud 환경에 광범위하게 액세스할 수 있습니다. 이러한 사용자의 예는 다음과 같습니다.

  • 조직 관리자 역할이 있는 사용자(roles/resourcemanager.organizationAdmin)
  • 보안 관리자 역할 (roles/iam.securityAdmin) 또는 Google Cloud 리소스 계층 구조의 중요한 부분에서 허용 정책을 수정할 수 있는 유사한 역할이 있는 사용자

권한이 높은 사용자에 직원 ID 제휴를 사용하는 경우 외부 IdP의 잘못된 구성이나 보안 침해는 Google Cloud 리소스의 보안에 영향을 미칠 수 있습니다. 특히 외부 IdP가 손상되면 악의적인 행위자가 권한이 높은 사용자로 인증하고 Google Cloud 리소스에 대한 광범위한 액세스 권한을 얻을 수 있습니다.

이러한 위험을 완화하려면 권한이 높은 사용자에게 Cloud ID를 사용하세요.

  • Cloud ID에서 권한이 높은 사용자를 만듭니다.
  • 보안 키를 사용하여 2단계 인증에 등록하여 이러한 사용자를 보호하세요.
  • Cloud ID를 외부 IdP와 제휴한 경우 이러한 사용자에 대해 추가 SSO 인증 및 2단계 인증을 사용 설정합니다.

IdP가 이미 다단계 인증을 시행하는 경우 추가 SSO 확인이 중복된 작업으로 보일 수 있지만 이 설정을 사용하면 IdP가 손상된 경우 사용자를 보호할 수 있습니다. 추가 SSO 인증은 Cloud Identity에서 지원되는 기능이지만 직원 ID 제휴에서는 사용할 수 없습니다.

조직 정책 제약 조건을 사용하여 페더레이션 관리

비상 또는 높은 권한 액세스 이외의 목적으로 Cloud ID를 사용하는 경우 서비스별로 Cloud ID 제휴 및 직원 ID 제휴 사용량을 파티셔닝하세요. 이 관행을 적용하려면 맞춤 조직 정책 제약 조건을 사용하여 특정 프로젝트에서 허용되는 주 구성원 유형을 제한하세요.

예를 들어 다음을 수행하여 직원 ID 제휴를 Gemini Enterprise로 제한할 수 있습니다.

  • MemberTypeMatches 함수를 사용하는 Gemini Enterprise 프로젝트에 커스텀 조직 정책 제약 조건을 적용하여 허용되는 주 구성원 유형을 iam.googleapis.com/WorkforcePoolPrincipal 및 iam.googleapis.com/WorkforcePoolPrincipalSet로 제한합니다. 직원 ID 제휴에서 사용하는 주 구성원 유형은 다음과 같습니다.
  • 다른 모든 프로젝트의 경우 iam.googleapis.com/WorkforcePoolPrincipal 및 iam.googleapis.com/WorkforcePoolPrincipalSet를 제외한 모든 주 구성원 유형을 허용하는 제약 조건을 적용합니다.

맞춤 조직 정책 제약 조건을 사용하면 일관성을 유지하고 잘못된 주 구성원 유형을 실수로 사용하는 것을 방지할 수 있습니다.

풀의 모든 구성원에 액세스 권한을 부여하지 않음

직원 ID 제휴는 다음 형식을 사용하는 와일드카드 주 구성원 식별자를 지원합니다.

principalSet://iam.googleapis.com/locations/global/workforcePools/
POOL_ID/*

이 식별자는 IdP가Google Cloud에 인증하도록 허용하는 모든 사용자와 일치합니다.

이 와일드카드 식별자를 사용하여 권한을 부여하지 마세요. IdP의 사용자 기반이 증가함에 따라 와일드카드 주 구성원 식별자로 액세스 권한을 부여하면 과도한 권한 부여가 발생합니다.

대신 IdP에서 액세스 그룹을 만들고 이러한 그룹을 사용하여 리소스에 대한 액세스를 관리하세요. 이 접근 방식을 사용하면 액세스가 인증 성공이 아닌 의도적인 그룹 멤버십에 의해 관리되므로 과도한 권한 부여 위험이 줄어듭니다.

세션 길이 제한

사용자가 로그인하면 직원 ID 제휴가 세션을 시작합니다. 세션을 통해 사용자는 다음 작업을 할 수 있습니다.

  • 콘솔 (제휴), Gemini Enterprise 또는 직원 ID 제휴를 지원하는 기타 포털을 사용하고 탐색합니다.
  • IAP로 보호되는 웹 애플리케이션을 사용합니다.
  • gcloud auth login을 실행하는 등 제휴 갱신 토큰과 제휴 액세스 토큰을 획득합니다.

세션은 다음 중 하나가 발생할 때까지 유효합니다.

  • 세션 길이가 직원 ID 풀에 정의된 한도에 도달합니다.
  • 세션 길이가 사용자의 SAML 어설션에 있는 SessionNotOnOrAfter 속성에 정의된 한도에 도달합니다(있는 경우).
  • 사용자가 로그아웃합니다.

세션이 장기간 유효하도록 허용하면 토큰 도난 위험이 증가하고 그룹 멤버십 정보가 오래될 수 있습니다.

  • IdP에서 권한이 취소되면 사용자가 의도한 것보다 더 오래 액세스 권한을 유지할 수 있습니다.
  • 사용자가 다시 인증하고 새 세션을 설정할 때까지 새로 부여된 액세스 권한을 행사하지 못할 수 있습니다.

이러한 위험을 완화하려면 사용자가 하루에 한 번 이상 다시 로그인해야 하도록 세션 길이를 제한하세요.

세션 길이를 JIT 액세스 요구사항에 맞게 조정

권한 있는 액세스를 관리하기 위해 IDP는 회원이 일시적으로 활성화할 수 있는 적시 (JIT) 그룹을 지원할 수 있습니다. 적시 그룹을 사용하여 Google Cloud 또는 Gemini Enterprise에 대한 권한 있는 액세스를 관리하면 다음과 같은 위험이 발생할 수 있습니다.

  • 지연된 활성화: 사용자가 적시 그룹 멤버십을 활성화하는 동안 활성 직원 ID 제휴 세션이 있는 경우 사용자가 로그아웃했다가 다시 로그인할 때까지 멤버십 변경사항이 적용되지 않습니다. 또는 직원 ID 풀 공급자가 SCIM을 사용하는 경우 그룹 멤버십 변경사항이 프로비저닝될 때까지 구성원 변경사항이 적용되지 않습니다.
  • 지연된 취소: 그룹 멤버십이 만료되더라도 사용자가 로그아웃했다가 다시 로그인하거나 SCIM을 사용하여 그룹 멤버십 변경사항이 프로비저닝될 때까지는 권한 액세스 권한이 손실되지 않습니다. 세션 길이에 따라 이 지연으로 인해 멤버십 만료의 목적이 저해될 수 있습니다.

이러한 위험을 완화하려면 직원 ID 풀 세션 길이를 충분히 짧게 구성하세요.

활동 모니터링

Google Cloud의 리소스에 영향을 미치는 의심스러운 활동이 감지되었을 때, Cloud 감사 로그는 활동이 언제 발생했는지, 어떤 사용자가 관련되었는지를 확인하는 데 중요한 정보를 제공합니다.

데이터 액세스 로그 사용 설정하기

직원 ID 제휴는 로그인 및 토큰 교환 활동을 추적할 수 있는 로그를 생성할 수 있습니다. 보안 토큰 서비스 API는 다음 메서드를 포함하는 이러한 로그를 작성합니다.

  • google.identity.sts.SecurityTokenService.WebSignIn
  • google.identity.sts.SecurityTokenService.WebSignOut
  • google.identity.sts.v1.SecurityTokenService.ExchangeToken
  • google.identity.sts.v1beta.SecurityTokenService.ExchangeToken

로그인 및 토큰 교환 활동과 관련된 모든 로그는 데이터 액세스 로그로 분류되며 기본적으로 사용 중지되어 있습니다. 이러한 로그를 캡처하려면Google Cloud 조직 전체에서 Security Token Service API에 대해 데이터 액세스 로그를 사용 설정하세요. 로그인 로그의 세부정보 수준을 더 높이려면 상세 감사 로깅을 사용 설정하세요.

기타 인증 관련 활동을 추적하려면 다음 로그를 사용 설정하고 사용하는 것이 좋습니다.

다음 단계