Google 그룹스 사용 권장사항

이 문서에서는 Google 그룹을 사용하여 Identity and Access Management(IAM)로 Google Cloud 리소스에 대한 액세스를 관리하는 방법에 관한 몇 가지 권장사항을 설명합니다.

그룹 유형

여기에 나열된 그룹 유형은 Google 그룹에 대해 생각하고, 사용하고, 관리하는 한 가지 방법입니다. 이러한 그룹 유형은 Google 그룹 속성에 의해 설정되지 않습니다. 그러나 이러한 그룹 유형을 Google 그룹 관리에 대한 전반적인 접근 방식에 사용하면 일반적인 보안 문제를 피하는 데 도움이 될 수 있습니다.

이 문서에서는 다음 유형의 그룹을 사용합니다.

• 조직 그룹

  조직 그룹은 조직 구조의 하위 집합을 나타내며 일반적으로 인사 데이터에서 가져옵니다. 부서, 보고 구조, 지리적 위치 또는 기타 조직 그룹을 기준으로 할 수 있습니다.

  직원이 조직에 가입하거나, 다른 부서로 이동하거나, 조직을 떠나면 조직 그룹의 구성원이 변경됩니다.

  비즈니스가 재구성되면 조직 그룹의 전반적인 구조가 변경될 수 있습니다. 재구성하면 새 그룹이 생성되거나 기존 그룹이 지원 중단될 수 있습니다.

  조직 그룹의 예로는 org.marketing-fte, org.finance-all, org.msmith-reports, org.apac-all, org.summer-interns가 있습니다.

  조직 그룹은 일반적으로 이메일 커뮤니케이션에 사용됩니다.

• 공동작업 그룹

  공동작업 그룹은 프로젝트에서 공동작업하거나 특정 주제를 논의하려는 작업 그룹, 프로젝트 회원 또는 사용자를 나타냅니다.

  공동작업 그룹의 구조는 조직 구조와 연결되지 않습니다. 임시 셀프서비스 방식으로 생성되는 경우가 많습니다.

  공동작업 그룹의 멤버십은 제한되지 않으므로 조직의 모든 사용자가 가입할 수 있습니다. 또는 공동작업 그룹을 자체 관리할 수 있습니다. 즉, 특정 회원이 그룹에 포함할 다른 사용자를 결정할 수 있습니다.

  공동작업 그룹의 몇 가지 예로는 collab.security-discuss 및 collab.website-relaunch가 있습니다.

  공동작업 그룹은 일반적으로 이메일 커뮤니케이션에 사용됩니다.

• 액세스 그룹

  액세스 그룹은 액세스 권한을 제공하기 위한 목적으로만 사용됩니다. 직무 기능을 나타내며 이러한 직무 기능을 수행하는 데 필요한 역할 할당을 간소화하는 데 사용됩니다. 개별 주 구성원에게 역할을 부여하는 대신 그룹에 역할을 부여한 다음 그룹 멤버십을 관리합니다.

  액세스 그룹의 구조는 조직의 리소스 또는 워크로드 구조에 영향을 받습니다. 새 리소스 또는 워크로드를 배포하려면 새 액세스 그룹을 만들어야 할 수 있습니다.

  액세스 그룹의 멤버십은 일반적으로 하나 이상의 그룹 소유자가 제어하며, 그룹 소유자는 사용자를 그룹에 초대하거나 사용자가 그룹에 가입하기 위한 요청을 승인합니다.

  액세스 그룹의 몇 가지 예로는 access.prod-firewall-admins, access.finance-datamart-viewers 및 access.billing-dashboard-users가 있습니다.

  액세스 그룹은 액세스 권한을 제공하는 데만 사용됩니다. 커뮤니케이션 목적으로는 사용되지 않습니다.

• 시정 조치 그룹

  시정 조치 그룹은 액세스 그룹과 유사하지만 액세스 권한을 제공하는 대신 액세스 제한 정책을 시행하는 데 사용됩니다.

  시정 조치 그룹의 구조는 일반적으로 규정 준수 요구사항과 조직 구조의 조합에 영향을 받습니다.

  시정 조치 그룹의 멤버십은 일반적으로 사용자의 승인 수준, 위치 또는 조직 내 역할 등을 고려하는 사전 정의된 규칙 집합에 따라 결정됩니다.

  시정 조치 그룹의 몇 가지 예로는 enforcement.users-in-restricted-locations, enforcement.fedramp-low 및 enforcement.sso-users가 있습니다.

  시정 조치 그룹은 액세스 제한 정책을 시행하는 데만 사용됩니다. 커뮤니케이션 목적으로는 사용되지 않습니다.

그룹 유형을 반영하도록 그룹 이름 지정

이 문서의 나머지 부분에서 권장사항을 따르려면 이름에서 그룹 유형을 확인할 수 있는 그룹 이름을 사용하세요. 이름 지정 규칙 또는 보조 도메인을 사용할 수 있습니다.

이름 지정 규칙

다음은 그룹 유형을 표시하는 이름 지정 규칙의 한 가지 예입니다.

• 조직 그룹: org.GROUP_NAME@example.com. 예를 들면 org.finance-all@example.com입니다.

• 공동작업 그룹: collab.TEAM_NAME@example.com. 예를 들면 collab.msmiths-team@example.com입니다.

• 액세스 그룹: access.JOB_FUNCTION@example.com. 예를 들면 access.billing-dashboard-users@example.com입니다.

• 시정 조치 그룹: enforcement.GROUP_DESCRIPTION@example.com 예를 들면 enforcement.sso-users@example.com입니다.

조직에 적합하고 그룹 관리 소프트웨어에서 지원하는 약관을 채택하세요. 프리픽스를 사용하면 기능별로 그룹을 알파벳순으로 정렬할 수 있지만 Groups for Business와 같은 일부 그룹 관리 시스템은 서픽스만 지원합니다. 프리픽스를 사용할 수 없는 경우 서픽스 또는 보조 도메인을 사용할 수 있습니다.

보조 도메인

이름 지정 규칙 대신 보조 도메인을 사용하여 그룹 유형을 이름에 삽입할 수 있습니다(예: access.example.com). 확인된 도메인의 하위 도메인인 보조 도메인은 확인이 필요하지 않으며 DNS에 존재할 필요가 없습니다. 또한 보조 도메인에 DNS 메일 교환(MX) 레코드를 생성하지 않으면 커뮤니케이션용이 아닌 그룹으로 인바운드 이메일이 전송되는 것을 차단할 수 있습니다.

중첩 규칙

그룹 유형에 따라 중첩(그룹을 구성원으로 허용)이 허용되는지 여부에 관한 규칙이 다릅니다.

조직 그룹의 중첩 규칙

조직도를 반영하도록 조직 그룹을 중첩하는 것이 좋습니다. 이 접근 방식은 모든 직원이 하나의 그룹에 포함되고 그러한 그룹들이 서로에게 포함된다는 것을 의미합니다. 예를 들어 org.finance-all 그룹에는 org.finance-us, org.finance-germany, org.finance-australia 그룹이 구성원으로 포함될 수 있습니다.

조직 그룹을 다른 그룹 유형에 구성원으로 추가할 수 있습니다. 이렇게 하면 조직 그룹의 모든 구성원을 다른 그룹에 추가하는 것보다 훨씬 쉽게 할 수 있습니다.

조직 그룹에 다른 그룹 유형을 구성원으로 추가하지 마세요. 조직 계층 구조의 일부로 액세스, 시정 조치 또는 공동작업 그룹을 사용하지 마세요.

공동작업 그룹의 중첩 규칙

모든 공동작업 그룹에는 구성원 추가 방법을 결정하는 잘 정의된 정책 집합이 있어야 합니다. 두 공동작업 그룹이 동일한 멤버십 정책을 따르는 경우 중첩할 수 있습니다. 그러나 멤버십 정책이 다른 공동작업 그룹을 중첩하면 해당 그룹의 멤버십 정책을 충족하지 않는 구성원이 그룹 구성원이 될 수 있습니다. 공동작업 그룹을 중첩하기 전에 멤버십 정책을 주의 깊게 검토하세요.

공동작업 그룹에는 조직 그룹이 구성원으로 포함될 수 있습니다.

액세스 그룹의 중첩 규칙

일반적으로 액세스 그룹을 중첩해서는 안 됩니다. 액세스 그룹을 중첩하면 누가 어떤 리소스에 액세스할 수 있는지 파악하기 어려울 수 있습니다. 또한 액세스 정책이 다른 액세스 그룹을 중첩하면 주 구성원이 엄격한 액세스 그룹 멤버십 정책을 우회하도록 할 수 있습니다.

액세스 그룹에는 조직 그룹이 구성원으로 포함될 수 있습니다.

시정 조치 그룹의 중첩 규칙

시정 조치 그룹을 중첩하지 마세요. 시정 조치 그룹을 중첩하면 주 구성원의 액세스가 거부되는 이유를 파악하기 어려울 수 있습니다. 또한 서로 멤버십 정책에 시정 조치 그룹을 중첩하면 일부 사용자에게 의도하지 않은 제한이 발생할 수 있습니다.

시정 조치 그룹에는 조직 그룹이 구성원으로 있을 수 있습니다.

조직 그룹 관리

다음 권장사항에 따라 조직 그룹을 관리하세요.

단일 정보 소스에서 프로비저닝

조직 그룹은 인사 데이터를 기반으로 하므로 이러한 그룹은 인사 관리 정보 시스템 또는 외부 정보 소스(예: 외부 ID 공급업체(IdP) 또는 Sailpoint, Okta, Entra ID와 같은 ID 거버넌스 시스템)에서만 제공하는 것이 가장 좋습니다.

그룹 수정 허용 안 함

조직 그룹에서 사용자를 수동으로 추가하거나 삭제하지 말고 사용자가 조직 그룹에서 자신을 삭제하도록 허용하지 마세요.

조직 그룹을 사용하여 리소스에 대한 액세스 권한을 제공하지 않음

조직 그룹의 모든 사용자에게 리소스에 대한 동일한 수준의 액세스 권한이 필요한 경우는 거의 없습니다. 따라서 조직 그룹에 액세스 권한을 부여하면 그룹의 일부 구성원이 실제로 필요한 것보다 더 많은 액세스 권한을 갖게 될 수 있습니다.

또한 외부 IdP에서 변경사항이 적용되는 시점과 Cloud ID에 변경사항이 적용되는 시점 사이에는 외부 IdP에서 Cloud ID로의 동기화 빈도에 따라 지연이 발생할 수 있습니다. 이 지연으로 인해 초과 권한이 확산될 수 있습니다. 예를 들어 기존 그룹에 리소스에 액세스할 필요가 없는 사람들이 포함되어 있어도 리소스 소유자가 새 그룹을 만드는 대신 기존 그룹에 액세스 권한을 부여하도록 유도할 수 있습니다.

조직 그룹을 사용하여 액세스 권한을 제공해야 하는 경우 액세스 권한을 직접 부여하는 대신 조직 그룹을 액세스 그룹에 구성원으로 추가하고 조직 뷰어와 같이 제한된 권한이 있는 역할만 부여합니다. 그렇지 않으면 액세스 그룹을 사용하여 리소스에 대한 액세스 권한을 제공합니다.

조직 그룹에 서비스 계정 및 외부 사용자를 허용하지 않음

서비스 계정은 사람을 나타내지 않으므로 조직 그룹에 포함하지 마세요.

외부 사용자(다른 Google Workspace 또는 Cloud ID 계정의 사용자)는 일반적으로 조직에 속하지 않으므로 조직 그룹의 구성원이 될 이유가 없습니다. 외부 인력을 자체 Google Workspace 또는 Cloud ID 계정에 온보딩하면 내부 사용자로 간주되며 조직 그룹에 포함될 수 있습니다.

Cloud ID 보안 그룹 및 그룹 제한사항을 사용하여 이러한 규칙을 적용합니다.

공동작업 그룹 관리

다음 권장사항에 따라 공동작업 그룹을 관리하세요.

Groups for Business를 사용하여 공동작업 그룹 관리하기

Google Workspace를 사용하는 경우 Groups for Business를 사용하여 공동작업 그룹을 관리할 수 있습니다. 이렇게 하면 사용자가 Google 그룹스를 사용하여 그룹을 만들고, 둘러보고, 참여할 수 있습니다. 사용자가 새 공동작업 그룹을 만들 수 있도록 하려면 Groups for Business를 구성해야 합니다.

사용하지 않는 경우 Groups for Business 사용 중지하기

Cloud ID는 사용하고 있지만 Google Workspace는 사용하지 않는 경우 Cloud ID에 공동작업 그룹을 만들 이유가 없으므로 사용자가 Cloud ID에서 그룹을 만들 수 없도록 Groups for Business를 사용 중지하는 것이 가장 좋습니다.

공동작업 그룹에 서픽스 강제 적용

Groups for Business를 사용하는 경우 서픽스를 적용하도록 구성합니다. 이는 모든 사용자가 새 Groups for Business 그룹을 만들도록 허용하는 경우에 특히 중요합니다.

서픽스를 적용하면 사용자가 외부 소스에서 프로비저닝하려는 액세스 그룹 또는 조직 그룹과 이름이 의도적으로 충돌하는 그룹을 만들 수 없습니다. 이 시나리오에서는 잘못된 이름의 공동작업 그룹의 크리에이터가 권한을 에스컬레이션할 수 있습니다.

액세스 제어에 공동작업 그룹을 사용하지 않음

공동작업 그룹은 느슨한 액세스 제어를 사용하도록 설계되었으며 일반적으로 잘 정의된 수명 주기를 따르지 않습니다. 따라서 공동작업에는 좋지만 액세스 제어에는 좋지 않습니다.

공동작업 그룹의 명명 규칙을 엄격하게 준수하는 경우 커스텀 조직 정책 제약 조건을 만들어 공동작업 그룹에 IAM 역할이 부여되지 않도록 할 수 있습니다.

마찬가지로 공동작업 그룹을 외부에서 프로비저닝하고 관리하는 경우 액세스 제어 목적으로 오용될 수 있는 Cloud ID에 프로비저닝하지 마세요.

액세스 그룹 관리

다음 권장사항에 따라 액세스 그룹을 관리하세요.

액세스 그룹을 관리할 적절한 도구 선택

액세스 그룹은 워크로드 소유자가 관리하므로 셀프서비스에 적합한 도구를 사용하세요. 도구를 사용하면 사용자가 기존 액세스 그룹을 찾고 다음 제어 기능을 적용하는 보안 가드레일을 시행할 수 있도록 해야 합니다.

• 액세스 그룹에 가입할 수 있는 사용자(조직 그룹의 구성원)

• 사용자가 그룹에 가입하려면 어떤 요구사항을 충족해야 하나요?

  예를 들어 사용자가 근거를 제공해야 하나요?

• 그룹 멤버십의 최대 전체 기간

• 멤버십 승인 여부 및 승인 담당자

• 감사 추적 지원

이러한 요구사항에 적합한 도구 중 하나는 JIT 그룹입니다.

액세스 그룹을 사용하여 직무 기능을 모델링하고 리소스에 대한 액세스 권한 부여

각 직무에 대한 액세스 그룹을 만들고 해당 직무의 사용자가 필요로 하는 모든 리소스에 대한 액세스 권한을 부여합니다. 그런 다음 해당 직무의 사용자를 그룹에 추가하여 각 개별 사용자에게 동일한 역할을 부여하는 대신 필요한 액세스 권한을 부여할 수 있습니다.

단일 액세스 그룹을 사용하여 여러 리소스 또는 여러 프로젝트에 대한 액세스 권한을 제공할 수 있습니다. 단, 각 그룹 구성원에게 그룹에 부여한 액세스 권한이 필요한지 확인해야 합니다. 일부 사용자에게 추가 액세스 권한이 필요하지 않은 경우 새 액세스 그룹을 만들고 해당 그룹에 추가 액세스 권한을 부여합니다.

특정 워크로드에 액세스 그룹 사용

여러 워크로드에 액세스 그룹을 재사용하면 과도한 권한 설정과 복잡한 관리가 발생합니다.

워크로드 소유자를 위한 액세스 그룹 생성하는 데 방해가 되는 장벽 제거

기존 액세스 그룹을 재사용하려는 유혹을 줄이려면 액세스 그룹을 간편하게 만들고 유지할 수 있도록 합니다. 워크로드 소유자는 적절한 이름 지정을 지원하는 셀프서비스 방식으로 액세스 그룹을 만들 수 있어야 합니다.

사용자가 액세스 그룹을 찾아 가입할 수 있도록 지원

사용자가 기존 액세스 그룹을 검색하여 필요한 그룹에 가입할 수 있으면 불필요한 권한이 누적될 가능성이 줄어듭니다. 필요한 경우 초대 또는 승인 절차를 사용하여 그룹에 가입할 수 있는 사용자를 관리할 수 있습니다.

기본적으로 멤버십이 자동으로 만료되도록 허용

일정 기간이 지나면 사용자가 액세스 그룹에 다시 가입하거나 멤버십을 연장하도록 요구합니다. 이는 액세스 그룹의 구성원을 유지하기 위한 마찰을 의도적으로 추가하고 불필요한 멤버십을 소멸시키는 인센티브를 만듭니다. 이 권장사항은 제로 스탠딩 권한(ZSP) 목표를 달성하는 데 매우 중요하며 외부 사용자에게 특히 중요합니다.

그러나 액세스 그룹에서 서비스 계정을 삭제하면 서비스가 중단될 수 있으므로 서비스 계정에는 이 규칙을 적용하지 마세요.

각 그룹에 지정된 소유자 지정

모든 액세스 그룹에는 한 명 이상의 지정된 소유자가 있어야 합니다. 이렇게 하면 그룹 멤버십에 대한 책임감이 생깁니다. 소유자는 그룹과 연결된 워크로드를 소유한 사람 또는 팀과 동일할 수 있습니다.

액세스 그룹의 공개 상태 제한하기

그룹스 디렉터리에 액세스 그룹을 표시하지 않습니다. 액세스 그룹 관리 도구에서 검색할 수 있어야 합니다. 또한 그룹 구성원만 다른 구성원이 누구인지 볼 수 있도록 허용합니다. 이러한 관행은 악의적인 행위자가 중요한 정보를 얻지 못하도록 합니다.

외부 구성원 제한

도메인 제한 공유(DRS) 정책 제약조건은 그룹에 적용되지만 그룹 구성원에게는 적용되지 않으므로 외부 구성원을 허용하는 액세스 그룹은 DRS를 무력화하는 허점을 만들 수 있습니다.

Cloud ID 보안 그룹 및 그룹 제한사항을 사용하여 액세스 그룹에 외부 구성원을 허용하거나 허용하지 않습니다. 또한 외부 구성원을 허용하는 액세스 그룹에는 external.access.GROUP_NAME@example.com과 같은 특수한 이름 지정 규칙을 사용하는 것이 좋습니다.

시정 조치 그룹 관리

다음 권장사항에 따라 시정 조치 그룹을 관리하세요.

시정 조치 그룹을 관리할 적절한 도구 선택

시정 조치 그룹의 멤버십은 조직 규칙에 따라 결정되며 보안 제한을 적용하는 데 사용되므로 구성원이 시정 조치 그룹에서 스스로를 선택 해제하거나 삭제할 수 있도록 허용하지 마세요.

동적 그룹을 사용하면 시정 조치 그룹 프로비저닝을 자동화할 수 있습니다. 외부 IdP를 사용하는 경우 IdP에서 제공하는 동적 그룹을 사용한 후 Cloud ID에 프로비저닝합니다. 외부 IdP를 사용하면 정책 업데이트가 지연될 수 있다는 점에 유의하세요.

동적 그룹을 사용할 수 없는 경우 Terraform 또는 기타 코드형 인프라(IaC) 도구를 사용하여 시정 조치 그룹을 프로비저닝하는 것이 좋습니다. IaC를 사용하여 시정 조치 그룹을 만드는 경우 파이프라인에 과도하게 광범위한 액세스 권한을 부여하지 마세요.

강제 액세스 제어 및 인증 제어를 위해 시정 조치 그룹 사용

액세스 그룹을 사용하여 필수 액세스 제어를 시행합니다.Google Cloud 는 다음을 비롯한 여러 서비스와 도구로 필수 액세스 제어를 지원합니다.

• IAM 거부 정책
• IAM 주 구성원 액세스 경계 정책
• Chrome Enterprise Premium 액세스 바인딩
• Google Workspace 서비스 사용 중지

시정 조치 그룹은 SAML 프로필 할당 또는 2단계 인증(2SV)과 같은 인증 제어를 적용하는 데도 사용됩니다.

이러한 제어 기능은 모두 기능을 제한하거나 액세스 권한을 삭제하므로 시정 조치 그룹이 적합합니다.

사용자가 시정 조치 그룹에서 탈퇴하도록 허용하지 않음

사용자가 시정 조치 그룹을 탈퇴하도록 허용하는 것은 강제 액세스 제어의 원칙에 위배됩니다. 사용자가 그룹에서 탈퇴하지 못하도록 하려면 그룹 설정 API를 사용하여 whoCanLeaveGroup 속성을 NONE_CAN_LEAVE로 설정하세요.

외부 IdP 권장사항

인증에 외부 IdP를 사용하는 경우 조직 그룹 및 시정 조치 그룹 프로비저닝에도 해당 IdP를 사용하는 것이 유용할 수 있습니다.

액세스 그룹에 외부 소스를 사용하지 않음

외부 IdP에서 액세스 그룹을 관리하고 Cloud ID에 프로비저닝할 수 있지만 이 접근 방식에는 몇 가지 단점이 있습니다.

• 프로비저닝 지연

  외부 IdP에서 변경한 내용이 액세스 그룹에 반영되기까지 최대 몇 시간이 걸릴 수 있습니다.

• 불일치 위험

  일부 IdP는 그룹을 공식적으로 제어하지 않습니다. 예를 들어 외부에서 그룹을 삭제한 후 Cloud ID에서 그룹을 삭제하지 않거나 Cloud ID에는 있지만 IdP에는 없는 그룹 구성원을 적극적으로 삭제할 수 있습니다.

  불일치로 인해 사용자가 필요하지 않은 액세스 권한을 유지하게 되고 액세스 권한이 있는 사용자에 관한 잘못된 정보를 제공받게 됩니다. 액세스 그룹을 만드는 데 불편을 더할 수도 있습니다.

이러한 문제를 방지하려면 외부 IdP를 사용하여 조직 및 시정 조치 그룹만 프로비저닝하고 JIT 그룹과 같은 도구를 사용하여 Cloud ID에서 액세스 그룹을 직접 관리하세요.

이름별로 그룹을 매핑하는 경우 보조 도메인 사용

Cloud ID는 이메일 주소로 그룹을 식별하지만 외부 IdP의 그룹에는 이메일 주소가 없을 수 있습니다.

많은 IdP에서는 my-group@example.com를 사용하는 등 그룹 이름에서 가명 이메일 주소를 도출하여 이 문제를 해결할 수 있습니다. 이렇게 하면 되지만 이 이메일 주소를 다른 그룹이나 사용자가 이미 사용하고 있는 경우 충돌이 발생할 수 있습니다. 최악의 경우 이러한 이름 충돌은 악의적인 행위자가 악용하여 검토가 덜 이루어진 다른 그룹 유형으로 가장하는 보안 그룹을 만드는 데 악용될 수 있습니다.

충돌 위험을 방지하려면 외부 소스(예: groups.example.com)에서 프로비저닝하는 그룹에 전용 보조 도메인을 사용하세요.

배포 파이프라인에 그룹 관리자 역할을 부여하지 않음

IaC를 사용하여 그룹(예: Terraform)을 관리하는 경우 배포 파이프라인에 해당 작업을 완료하는 데 필요한 권한이 있어야 합니다. 그룹 관리자 역할은 그룹 생성을 승인하지만 이 역할을 가진 모든 주 구성원이 Cloud ID 계정의 모든 그룹을 관리할 수도 있습니다.

하나의 권한(그룹 만들기 기능)으로 서비스 계정을 만든 다음 파이프라인을 생성한 그룹의 소유자로 지정하여 파이프라인에 부여된 액세스를 제한할 수 있습니다. 이를 통해 해당 파이프라인은 자신이 만들지 않은 그룹을 관리할 수 있는 권한 없이도 자신이 만든 모든 그룹을 관리하고 더 많은 그룹을 만들 수 있습니다.

다음 단계에서는 이 접근 방식을 간략히 설명합니다.

1. Admin API 그룹 생성 권한만 포함된 커스텀 관리자 역할을 만듭니다.

   이 역할에 설명이 포함된 이름(예: 그룹 생성자)을 지정합니다.

2. 서비스 계정을 만들고 그룹 생성자 역할을 할당합니다.

3. 파이프라인에 서비스 계정을 사용하고 그룹 생성 시 WITH_INITIAL_OWNER 플래그를 전달합니다.

Cloud Logging을 사용하여 그룹을 감사하고 모니터링합니다.

Logging을 사용하면 그룹 활동을 수집, 모니터링, 분석할 수 있습니다.

멤버십 변경사항 감사

조직 그룹, 액세스 그룹 또는 시정 조치 그룹의 구성원을 추가하거나 삭제하면 구성원이 액세스할 수 있는 리소스에 영향을 미칠 수 있으므로 이러한 변경사항을 추적하는 감사 추적을 유지하는 것이 중요합니다.

액세스 그룹 가입을 위한 근거 필요

모니터링 데이터를 더 유용하게 만들려면 사용자가 그룹에 가입하거나 그룹 가입을 요청할 때 근거를 제공하도록 요구하고 해당 근거를 기록하세요. 승인 절차가 있는 경우 요청을 승인한 사용자에 관한 세부정보를 기록합니다.

이 추가 메타데이터는 나중에 사용자가 그룹에 추가된 이유와 더 나아가 특정 리소스에 대한 액세스 권한이 부여된 이유를 분석하는 데 도움이 될 수 있습니다.

Cloud ID 감사 로그 공유 사용 설정

알림 설정 또는 외부 보안 정보 및 이벤트 관리(SIEM) 시스템 사용을 비롯해 이러한 감사 로그를 다른 Google Cloud 로그와 동일한 방식으로 처리할 수 있도록 로그를 Cloud Logging으로 라우팅하도록 Cloud ID를 구성합니다.