Best Practices für die Verwendung von Google-Gruppen

In diesem Dokument werden einige Best Practices für die Verwendung von Google-Gruppen zur Verwaltung des Zugriffs auf Google Cloud-Ressourcen mit Identity and Access Management (IAM) beschrieben.

Arten von Gruppen

Die hier aufgeführten Gruppentypen sind eine Möglichkeit, Google-Gruppen zu betrachten, zu verwenden und zu verwalten. Diese Gruppentypen werden nicht durch ein Google-Gruppenattribut festgelegt. Wenn Sie diese Gruppentypen jedoch in Ihrem allgemeinen Ansatz zur Verwaltung von Google-Gruppen verwenden, können Sie einige häufige Sicherheitsfallen vermeiden.

In diesem Dokument werden die folgenden Gruppentypen verwendet:

  • Organisationsgruppen

    Organisationsgruppen stellen Teilmengen der Struktur einer Organisation dar und stammen in der Regel aus Personaldaten. Sie können auf Abteilung, Berichtsstruktur, geografischem Standort oder anderen organisatorischen Gruppierungen basieren.

    Die Mitglieder einer Organisationsgruppe ändern sich, wenn ein Mitarbeiter der Organisation beitritt, in eine andere Abteilung wechselt oder die Organisation verlässt.

    Die Gesamtstruktur von Organisationsgruppen kann sich ändern, wenn das Unternehmen neu organisiert wird. Eine Umstrukturierung kann dazu führen, dass neue Gruppen erstellt oder vorhandene Gruppen eingestellt werden.

    Beispiele für organisatorische Gruppen sind org.marketing-fte, org.finance-all, org.msmith-reports, org.apac-all und org.summer-interns.

    Organisationsgruppen werden in der Regel für die E-Mail-Kommunikation verwendet.

  • Gruppen für die Zusammenarbeit

    Gruppen für die Gruppenarbeit repräsentieren Arbeitsgruppen, Projektmitglieder oder Nutzer, die an einem Projekt zusammenarbeiten oder ein bestimmtes Thema besprechen möchten.

    Die Struktur von Gruppen für die Gruppenarbeit ist nicht mit einer Organisationsstruktur verknüpft. Sie werden oft ad hoc und im Selfservice erstellt.

    Die Mitgliedschaft in Gruppen für die Gruppenarbeit kann uneingeschränkt sein, sodass jeder in der Organisation beitreten kann. Alternativ kann eine Gruppenarbeit selbst verwaltet werden, d. h. bestimmte Mitglieder können entscheiden, wer sonst noch in die Gruppe aufgenommen werden soll.

    Beispiele für Gruppen für die Gruppenarbeit sind collab.security-discuss und collab.website-relaunch.

    Gruppen für die Zusammenarbeit werden in der Regel für die E-Mail-Kommunikation verwendet.

  • Zugriffsgruppen

    Zugriffsgruppen dienen ausschließlich dem Zweck, Zugriff zu gewähren. Sie repräsentieren berufliche Funktionen und werden verwendet, um die Zuweisung von Rollen zu vereinfachen, die für die Ausführung dieser berufliche Funktionen erforderlich sind. Anstatt Rollen einzelnen Hauptkonten zuzuweisen, weisen Sie sie der Gruppe zu und verwalten dann die Gruppenmitgliedschaft.

    Die Struktur von Zugriffsgruppen wird von der Struktur der Ressourcen oder Arbeitslasten in Ihrer Organisation beeinflusst. Für die Bereitstellung einer neuen Ressource oder Arbeitslast müssen möglicherweise neue Zugriffsgruppen erstellt werden.

    Die Mitgliedschaft in Zugriffsgruppen wird in der Regel von einem oder mehreren Gruppeninhabern verwaltet, die Nutzer entweder in die Gruppe einladen oder deren Beitrittsanfragen genehmigen.

    Beispiele für Zugriffsgruppen sind access.prod-firewall-admins, access.finance-datamart-viewers und access.billing-dashboard-users.

    Zugriffsgruppen werden nur verwendet, um Zugriff zu gewähren. Sie werden nicht zu Kommunikationszwecken verwendet.

  • Durchsetzungsgruppen

    Erzwingungsgruppen ähneln Zugriffsgruppen, mit dem Unterschied, dass sie nicht zum Gewähren von Zugriff, sondern zum Erzwingen von Zugriffsbeschränkungsrichtlinien verwendet werden.

    Die Struktur von Enforcement-Gruppen wird in der Regel von einer Kombination aus Compliance-Anforderungen und Organisationsstruktur beeinflusst.

    Die Mitgliedschaft in einer Gruppe für die Durchsetzung wird in der Regel anhand einer Reihe von vordefinierten Regeln bestimmt, die die Sicherheitsstufe, den Standort oder die Rolle eines Nutzers in der Organisation berücksichtigen.

    Beispiele für Erzwingungsgruppen sind enforcement.users-in-restricted-locations, enforcement.fedramp-low und enforcement.sso-users.

    Erzwingungsgruppen werden nur verwendet, um Richtlinien für Zugriffsbeschränkungen durchzusetzen. Sie werden nicht zu Kommunikationszwecken verwendet.

Gruppen nach ihrem Typ benennen

Verwenden Sie Gruppennamen, anhand derer Sie den Typ einer Gruppe aus dem Namen ableiten können, damit Sie die Best Practices im Rest dieses Dokuments einhalten können. Sie können eine Namenskonvention oder sekundäre Domains verwenden.

Namenskonvention

Hier ist ein Beispiel für eine Namenskonvention, mit der der Gruppentyp sichtbar wird:

  • Organisationsgruppen: org.GROUP_NAME@example.com. Beispiel: org.finance-all@example.com.

  • Gruppen für die Gruppenarbeit: collab.TEAM_NAME@example.com. Beispiel: collab.msmiths-team@example.com.

  • Zugriffsgruppen: access.JOB_FUNCTION@example.com. Beispiel: access.billing-dashboard-users@example.com

  • Maßnahmengruppen: enforcement.GROUP_DESCRIPTION@example.com. Beispiel: enforcement.sso-users@example.com.

Verwenden Sie die Konvention, die für Ihre Organisation geeignet ist und von Ihrer Gruppenverwaltungssoftware unterstützt wird. Wenn Sie ein Präfix verwenden, werden Ihre Gruppen nach Funktion alphabetisch sortiert. Einige Gruppenverwaltungssysteme wie Google Groups for Business unterstützen jedoch nur Suffixe. Wenn Sie keine Präfixe verwenden können, können Sie Suffixe oder sekundäre Domains verwenden.

Sekundäre Domains

Alternativ zu Namenskonventionen können Sie sekundäre Domains verwenden, um den Gruppentyp in den Namen einzubetten, z. B. access.example.com. Sekundäre Domains, die eine Subdomain einer bestätigten Domain sind, müssen nicht bestätigt werden und müssen nicht im DNS vorhanden sein. Wenn Sie keine DNS-MX-Einträge (Mail Exchange) für die sekundären Domains erstellen, können Sie eingehende E-Mails an Gruppen blockieren, die nicht für die Kommunikation gedacht sind.

Regeln für verschachtelte Elemente

Für verschiedene Gruppentypen gelten unterschiedliche Regeln, ob das Verschachteln (das Akzeptieren einer Gruppe als Mitglied) zulässig ist.

Verschachtelungsregeln für Organisationsgruppen

Es ist eine Best Practice, Organisationsgruppen zu verschachteln, um Ihre Organisationsstruktur widerzuspiegeln. Bei diesem Ansatz ist jeder Mitarbeiter in einer Gruppe enthalten und die Gruppen sind dann gegenseitig enthalten. Die Gruppe org.finance-all kann beispielsweise die Gruppen org.finance-us, org.finance-germany und org.finance-australia als Mitglieder enthalten.

Sie können Organisationsgruppen als Mitglieder zu allen anderen Gruppentypen hinzufügen. Das kann viel einfacher sein, als jedes Mitglied einer Organisationsgruppe einer anderen Gruppe hinzuzufügen.

Fügen Sie einer Organisationsgruppe keinen anderen Gruppentyp als Mitglied hinzu. Verwenden Sie keine Zugriffs-, Erzwingungs- oder Gruppen für die Zusammenarbeit als Teil einer Organisationshierarchie.

Verschachtelungsregeln für Gruppen für die Zusammenarbeit

Für jede Gruppenarbeit sollte es klar definierte Richtlinien geben, die festlegen, wie Mitglieder hinzugefügt werden. Wenn zwei Gruppen für die Zusammenarbeit denselben Mitgliedschaftsrichtlinien unterliegen, können sie verschachtelt werden. Wenn Sie jedoch Gruppen für die Zusammenarbeit mit unterschiedlichen Mitgliedschaftsrichtlinien verschachteln, können Mitglieder, die die Mitgliedschaftsrichtlinien einer Gruppe nicht erfüllen, trotzdem Mitglied werden. Lesen Sie sich die Mitgliedschaftsrichtlinien sorgfältig durch, bevor Sie Gruppen für die Gruppenarbeit verschachteln.

Gruppen für die Zusammenarbeit können Organisationsgruppen als Mitglieder haben.

Verschachtelungsregeln für Zugriffsgruppen

Normalerweise sollten Sie keine Zugriffsgruppen verschachteln. Verschachtelte Zugriffsgruppen können es schwierig machen, zu ermitteln, wer auf welche Ressourcen zugreifen kann. Außerdem können Hauptkonten durch das Verschachteln von Zugriffsgruppen mit unterschiedlichen Zugriffsrichtlinien strenge Richtlinien für die Mitgliedschaft in Zugriffsgruppen umgehen.

Zugriffsgruppen können Organisationsgruppen als Mitglieder haben.

Verschachtelungsregeln für Erzwingungsgruppen

Verschachteln Sie keine Erzwingungsgruppen. Verschachtelte Erzwingungsgruppen können es schwierig machen, zu ermitteln, warum einem Hauptkonto der Zugriff verweigert wird. Außerdem kann es passieren, dass durch das Verschachteln von Gruppen mit unterschiedlichen Mitgliedschaftsrichtlinien einige Prinzipale von unbeabsichtigten Einschränkungen betroffen sind.

Durchsetzungsgruppen können Organisationsgruppen als Mitglieder haben.

Organisationsgruppen verwalten

Beachten Sie die folgenden Best Practices, um Ihre Organisationsgruppen zu verwalten.

Bereitstellung aus einer einzigen Source of Truth

Da Organisationsgruppen auf Personaldaten basieren, sollten Sie diese Gruppen ausschließlich über ein Human Resources Information System oder eine externe Datenquelle bereitstellen, z. B. einen externen Identitätsanbieter (IdP) oder ein Identitätsverwaltungssystem wie Sailpoint, Okta oder Entra ID.

Gruppenänderungen nicht zulassen

Fügen Sie Nutzer nicht manuell zu einer Organisationsgruppe hinzu und entfernen Sie sie nicht manuell daraus. Außerdem dürfen Nutzer sich nicht selbst aus einer Organisationsgruppe entfernen.

Vermeiden Sie die Verwendung von Organisationsgruppen, um Zugriff auf Ressourcen zu gewähren

Selten benötigen alle Nutzer in einer Organisationsgruppe dieselbe Zugriffsebene auf Ressourcen. Wenn Sie also einer Organisationsgruppe Zugriff gewähren, haben einige Mitglieder der Gruppe wahrscheinlich mehr Zugriff, als sie tatsächlich benötigen.

Außerdem kann es je nach Synchronisierungshäufigkeit zwischen dem externen IdP und Cloud Identity zu Verzögerungen bei der Übertragung von Änderungen kommen. Diese Verzögerung kann zu einer Ausweitung von überflüssigen Berechtigungen führen. So kann es beispielsweise dazu führen, dass Ressourceninhaber Zugriff auf vorhandene Gruppen gewähren, anstatt eine neue Gruppe zu erstellen, auch wenn diese vorhandenen Gruppen Personen enthalten, die keinen Zugriff auf die Ressource benötigen.

Wenn Sie den Zugriff über eine Organisationsgruppe gewähren müssen, fügen Sie die Organisationsgruppe einer Zugriffsgruppe als Mitglied hinzu, anstatt den Zugriff direkt zu gewähren. Weisen Sie außerdem nur Rollen mit eingeschränkten Berechtigungen zu, z. B. „Organisationsbetrachter“. Andernfalls können Sie Zugriffsgruppen verwenden, um Zugriff auf Ressourcen zu gewähren.

Dienstkonten und externe Nutzer in Organisationsgruppen nicht zulassen

Fügen Sie keine Dienstkonten zu Organisationsgruppen hinzu, da sie keine Personen repräsentieren.

Externe Nutzer (Nutzer eines anderen Google Workspace- oder Cloud Identity-Kontos) gehören in der Regel nicht zu Ihrer Organisation. Daher gibt es keinen Grund, sie Mitglied einer Organisationsgruppe zu machen. Wenn Sie Ihre externen Mitarbeiter in Ihrem eigenen Google Workspace- oder Cloud Identity-Konto anmelden, gelten sie als interne Nutzer und können in Ihre Organisationsgruppen aufgenommen werden.

Verwenden Sie Cloud Identity-Sicherheitsgruppen und Gruppenbeschränkungen, um diese Regeln durchzusetzen.

Gruppen für die Gruppenarbeit verwalten

Beachten Sie die folgenden Best Practices, um Ihre Gruppen für die Gruppenarbeit zu verwalten.

Gruppen für die Zusammenarbeit mit Google Groups for Business verwalten

Wenn Sie Google Workspace verwenden, können Sie Google Groups for Business verwenden, um Gruppen für die Zusammenarbeit zu verwalten. So können Nutzer mit Google Groups Gruppen erstellen, suchen und beitreten. Sie müssen Google Groups for Business so konfigurieren, dass Nutzer neue Gruppen für die Gruppenarbeit erstellen können.

Google Groups for Business deaktivieren, wenn Sie es nicht verwenden

Wenn Sie Cloud Identity, aber nicht Google Workspace verwenden, gibt es keinen Grund, Gruppen für die Zusammenarbeit in Cloud Identity zu haben. Daher sollten Sie Gruppen für Unternehmen deaktivieren, damit Ihre Nutzer keine Gruppen in Cloud Identity erstellen können.

Ein Suffix für Gruppen für die Zusammenarbeit erzwingen

Wenn Sie Google Groups for Business verwenden, konfigurieren Sie es so, dass ein Suffix erzwungen wird. Das ist besonders wichtig, wenn Sie allen erlauben, neue Groups for Business-Gruppen zu erstellen.

Wenn Sie ein Suffix erzwingen, können Nutzer keine Gruppe mit einem Namen erstellen, der absichtlich mit einer Zugriffsgruppe oder Organisationsgruppe übereinstimmt, die aus einer externen Quelle bereitgestellt werden soll. In diesem Szenario könnte der Ersteller der falsch benannten Gruppenarbeit seine Berechtigungen erhöhen.

Gruppen für die Zusammenarbeit nicht für die Zugriffssteuerung verwenden

Für Gruppen für die Zusammenarbeit ist eine lockere Zugriffssteuerung vorgesehen und sie folgen in der Regel keinem klar definierten Lebenszyklus. Das macht sie für die Zusammenarbeit gut, aber für die Zugriffssteuerung schlecht.

Wenn Sie für Ihre Gruppen für die Gruppenarbeit eine Namenskonvention strikt eingehalten haben, können Sie eine benutzerdefinierte Einschränkung für die Organisationsrichtlinie erstellen, um zu verhindern, dass Gruppen für die Gruppenarbeit IAM-Rollen zugewiesen werden.

Wenn Sie Ihre Gruppen für die Gruppenarbeit extern bereitstellen und verwalten, sollten Sie sie auch nicht in Cloud Identity bereitstellen, da sie sonst für die Zugriffssteuerung missbraucht werden könnten.

Zugriffsgruppen verwalten

Beachten Sie die folgenden Best Practices, um Ihre Zugriffsgruppen zu verwalten.

Das richtige Tool zum Verwalten von Zugriffsgruppen auswählen

Da Zugriffsgruppen von Arbeitslastinhabern verwaltet werden, sollten Sie ein Tool verwenden, das für den Selfservice geeignet ist. Mit Ihrem Tool sollten Nutzer vorhandene Zugriffsgruppen finden und Sicherheitsvorkehrungen erzwingen, die die folgenden Steuerelemente anwenden:

  • Wer (Mitglieder welcher Organisationsgruppe) kann einer Zugriffsgruppe beitreten?

  • Welche Voraussetzungen müssen erfüllt sein, damit ein Nutzer einer Gruppe beitreten kann

    Müssen Nutzer beispielsweise eine Begründung angeben?

  • Maximale Lebensdauer für die Gruppenmitgliedschaft

  • Ob die Mitgliedschaft genehmigt werden muss und von wem

  • Unterstützung für Audit-Trails

Ein Tool, das diesen Anforderungen entspricht, sind JIT-Gruppen.

Stellenfunktionen mithilfe von Zugriffsgruppen modellieren und Zugriff auf Ressourcen gewähren

Erstellen Sie für jede Position eine Zugriffsgruppe und gewähren Sie ihr Zugriff auf alle Ressourcen, die Nutzer in dieser Position benötigen. Anschließend können Sie der Gruppe Nutzer mit dieser Tätigkeit hinzufügen, um ihnen den erforderlichen Zugriff zu gewähren, anstatt jedem einzelnen Nutzer dieselbe Rolle zuzuweisen.

Mit einer einzigen Zugriffsgruppe können Sie Zugriff auf mehrere Ressourcen oder sogar auf mehrere Projekte gewähren. Achten Sie jedoch darauf, dass jedes Gruppenmitglied den Zugriff benötigt, den Sie der Gruppe gewähren. Wenn einige Nutzer keinen zusätzlichen Zugriff benötigen, erstellen Sie eine neue Zugriffsgruppe und gewähren Sie dieser Gruppe stattdessen den zusätzlichen Zugriff.

Zugriffsgruppen für eine bestimmte Arbeitslast verwenden

Die Wiederverwendung von Zugriffsgruppen für mehrere Arbeitslasten führt zu übermäßigen Berechtigungen und einer komplexen Verwaltung.

Barrieren beim Erstellen von Zugriffsgruppen für Arbeitslastinhaber beseitigen

Um die Versuchung zu verringern, eine vorhandene Zugriffsgruppe wiederzuverwenden, sollten Sie Zugriffsgruppen einfach erstellen und verwalten können. Workload-Inhaber sollten in der Lage sein, Zugriffsgruppen im Self-Service-Verfahren zu erstellen, wobei eine korrekte Benennung unterstützt werden sollte.

Nutzern die Möglichkeit geben, Zugriffsgruppen zu finden und ihnen beizutreten

Wenn Nutzer bestehende Zugriffsgruppen finden und denjenigen beitreten können, die sie benötigen, ist es weniger wahrscheinlich, dass sie unnötige Berechtigungen erhalten. Bei Bedarf können Sie mithilfe eines Einladungs- oder Genehmigungsverfahrens festlegen, wer der Gruppe beitreten kann.

Mitgliedschaften standardmäßig automatisch ablaufen lassen

Nutzer müssen nach einer bestimmten Zeit einer Zugriffsgruppe wieder beitreten oder ihre Mitgliedschaft verlängern. Diese Praxis erschwert es absichtlich, Mitglied einer Zugriffsgruppe zu bleiben, und schafft einen Anreiz, nicht benötigte Mitgliedschaften verfallen zu lassen. Diese Best Practice ist entscheidend für das Erreichen des Ziels „Null anhaltende Berechtigungen“ (Zero Standing Privileges, ZSP) und ist besonders für externe Nutzer wichtig.

Wenden Sie diese Regel jedoch nicht auf Dienstkonten an, da das Entfernen von Dienstkonten aus einer Zugriffsgruppe zu Dienstunterbrechungen führen kann.

Weisen Sie jeder Gruppe Inhaber zu.

Jede Zugriffsgruppe sollte einen oder mehrere benannte Inhaber haben. Dies fördert ein Gefühl der Verantwortung für die Gruppenmitgliedschaft. Die Inhaber können dieselbe Person oder dasselbe Team sein, dem die mit der Gruppe verknüpfte Arbeitslast zugewiesen ist.

Sichtbarkeit von Zugriffsgruppen einschränken

Zugriffsgruppen dürfen nicht im Gruppenverzeichnis sichtbar sein. Sie sollten in Ihrem Tool zur Verwaltung von Zugriffsgruppen zu finden sein. Außerdem können Sie festlegen, dass nur Gruppenmitglieder sehen können, wer sonst noch Mitglied ist. So wird verhindert, dass böswillige Akteure an wertvolle Informationen gelangen.

Externe Mitglieder beschränken

Da die Einschränkungen der DRS-Richtlinie (Domain Restricted Sharing) für Gruppen, aber nicht für Gruppenmitglieder gelten, können Zugriffsgruppen, die externe Mitglieder zulassen, eine Lücke schaffen, die DRS untergräbt.

Verwenden Sie Cloud Identity-Sicherheitsgruppen und Gruppenbeschränkungen, um externen Mitgliedern den Zugriff auf Zugriffsgruppen zu erlauben oder zu verweigern. Außerdem sollten Sie für Zugriffsgruppen, die externe Mitglieder zulassen, eine spezielle Benennungskonvention wie external.access.GROUP_NAME@example.com verwenden.

Maßnahmengruppen verwalten

Beachten Sie die folgenden Best Practices, um Ihre Gruppen für die Durchsetzung zu verwalten.

Das richtige Tool zum Verwalten von Gruppen für die Durchsetzung auswählen

Da die Mitgliedschaft in Gruppen für die Durchsetzung auf organisatorischen Regeln basiert und zur Anwendung von Sicherheitseinschränkungen verwendet wird, sollten Mitglieder nicht die Möglichkeit haben, sich von einer Gruppe für die Durchsetzung abzumelden oder selbst daraus zu entfernen.

Mit dynamischen Gruppen können Sie die Bereitstellung von Erzwingungsgruppen automatisieren. Wenn Sie einen externen IdP verwenden, verwenden Sie die vom IdP bereitgestellten dynamischen Gruppen und stellen Sie sie dann in Cloud Identity bereit. Beachten Sie, dass die Verwendung eines externen Identitätsanbieters zu Verzögerungen bei Richtlinienaktualisierungen führen kann.

Wenn Sie keine dynamischen Gruppen verwenden können, sollten Sie Terraform oder ein anderes IaC-Tool (Infrastruktur als Code) verwenden, um Ihre Erzwingungsgruppen bereitzustellen. Wenn Sie mit IaC-Konzepten Erzwingungsgruppen erstellen, sollten Sie der Pipeline keinen unnötig weit gefassten Zugriff gewähren.

Erzwingungsgruppen für die obligatorische Zugriffssteuerung und Authentifizierungssteuerung verwenden

Verwenden Sie Zugriffsgruppen, um die erforderliche Zugriffssteuerung durchzusetzen. Google Cloud unterstützt die obligatorische Zugriffssteuerung mit einer Reihe von Diensten und Tools, darunter:

Erzwingungsgruppen werden auch verwendet, um Authentifizierungssteuerungen wie die SAML-Profilzuweisung oder die Bestätigung in zwei Schritten anzuwenden.

Da diese Steuerelemente alle Funktionen einschränken oder den Zugriff entfernen, sind Erzwingungsgruppen die richtige Wahl.

Nutzern nicht erlauben, eine Gruppe für die Durchsetzung von Richtlinien zu verlassen

Wenn Nutzer eine Gruppe für die Erzwingung verlassen dürfen, verstößt das gegen die Prinzipien der obligatorischen Zugriffssteuerung. Wenn Nutzer die Gruppe nicht verlassen dürfen sollen, legen Sie mit der Groups Settings API das Attribut whoCanLeaveGroup auf NONE_CAN_LEAVE fest.

Best Practices für externe Identitätsanbieter

Wenn Sie für die Authentifizierung einen externen IdP verwenden, kann es sinnvoll sein, diesen IdP auch für die Bereitstellung von Organisationsgruppen und Durchsetzungsgruppen zu verwenden.

Externe Quellen für Zugriffsgruppen vermeiden

Es ist möglich, Zugriffsgruppen im externen IdP zu verwalten und für Cloud Identity bereitzustellen. Dieser Ansatz hat jedoch mehrere Nachteile:

  • Verzögerungen bei der Bereitstellung

    Es kann einige Stunden dauern, bis Änderungen, die am externen IdP vorgenommen wurden, in der Zugriffsgruppe übernommen werden.

  • Risiko der Abweichung

    Einige Identitätsanbieter übernehmen keine autoritative Kontrolle über Gruppen. So wird beispielsweise möglicherweise eine Gruppe in Cloud Identity nicht gelöscht, nachdem sie extern gelöscht wurde, oder Gruppenmitglieder werden aktiv gelöscht, die in Cloud Identity, aber nicht im IdP vorhanden sind.

    Abweichungen können dazu führen, dass Nutzer Zugriff behalten, den sie nicht benötigen, und ihnen falsche Informationen darüber geben, wer Zugriff hat. Außerdem kann es das Erstellen von Zugriffsgruppen erschweren.

Um diese Fallstricke zu vermeiden, sollten Sie mit externen Identitätsanbietern nur organisatorische und Erzwingungsgruppen bereitstellen und Zugriffsgruppen direkt in Cloud Identity mit einem Tool wie JIT-Gruppen verwalten.

Sekundäre Domain verwenden, wenn Sie Gruppen nach Namen zuordnen

In Cloud Identity werden Gruppen anhand ihrer E-Mail-Adresse identifiziert. Gruppen in Ihrem externen IdP haben jedoch möglicherweise keine E-Mail-Adresse.

Viele Identitätsanbieter bieten die Möglichkeit, eine Pseudo-E-Mail-Adresse aus dem Namen der Gruppe abzuleiten, z. B. mit my-group@example.com. Das funktioniert, kann aber zu Kollisionen führen, wenn diese E-Mail-Adresse bereits von einer anderen Gruppe oder einem anderen Nutzer verwendet wird. Im schlimmsten Fall kann diese Namenskollision von einem Angreifer ausgenutzt werden, um Sicherheitsgruppen zu erstellen, die sich als ein anderer, weniger geprüfter Gruppentyp ausgeben.

Verwenden Sie für Gruppen, die Sie über die externe Quelle bereitstellen, eine eigene sekundäre Domain, z. B. groups.example.com, um das Risiko von Kollisionen zu vermeiden.

Vermeiden Sie es, Bereitstellungspipelines die Rolle „Administrator von Gruppen“ zuzuweisen

Wenn Sie IaC zum Verwalten von Gruppen verwenden (z. B. Terraform), muss Ihre Bereitstellungspipeline die erforderlichen Berechtigungen haben, um ihre Aufgabe zu erfüllen. Die Rolle „Administrator für Gruppen“ autorisiert die Gruppenerstellung, ermöglicht aber auch allen Hauptkonten mit dieser Rolle, alle Gruppen im Cloud Identity-Konto zu verwalten.

Sie können den Zugriff auf eine Pipeline einschränken, indem Sie ein Dienstkonto mit nur einer Berechtigung (zum Erstellen einer Gruppe) erstellen und dann die Pipeline zum Inhaber aller von ihr erstellten Gruppen machen. So kann die Pipeline alle von ihr erstellten Gruppen verwalten und weitere Gruppen erstellen, ohne dass sie zum Verwalten von Gruppen berechtigt ist, die sie nicht erstellt hat.

Dieser Ansatz wird in den folgenden Schritten beschrieben:

  1. Erstellen Sie eine benutzerdefinierte Administratorrolle, die nur die Berechtigung „Admin API: Gruppen erstellen“ enthält.

    Geben Sie dieser Rolle einen aussagekräftigen Namen, z. B. „Gruppenbegründer“.

  2. Erstellen Sie ein Dienstkonto und weisen Sie ihm die Rolle „Gruppenersteller“ zu.

  3. Verwenden Sie das Dienstkonto für Ihre Pipeline und geben Sie beim Erstellen der Gruppe das Flag WITH_INITIAL_OWNER an.

Verwenden Sie Cloud Logging, um Ihre Gruppen zu prüfen und zu überwachen.

Mit Logging können Sie Gruppenaktivitäten erfassen, überwachen und analysieren.

Änderungen an Mitgliedschaften prüfen

Das Hinzufügen oder Entfernen eines Mitglieds einer Organisationsgruppe, Zugriffsgruppe oder Erzwingungsgruppe kann sich darauf auswirken, auf welche Ressourcen das Mitglied Zugriff hat. Daher ist es wichtig, einen Audit-Trail zu führen, in dem diese Änderungen erfasst werden.

Begründungen für den Beitritt zu Zugriffsgruppen erforderlich machen

Damit Ihre Monitoring-Daten nützlicher sind, sollten Sie Nutzer dazu verpflichten, eine Begründung anzugeben, wenn sie einer Gruppe beitreten oder den Beitritt beantragen, und diese Begründung protokollieren. Wenn es einen Genehmigungsprozess gibt, protokollieren Sie, wer die Anfrage genehmigt hat.

Anhand dieser zusätzlichen Metadaten können Sie später analysieren, warum eine Person einer Gruppe hinzugefügt wurde und damit auch, warum sie Zugriff auf bestimmte Ressourcen erhalten hat.

Freigabe von Cloud Identity-Audit-Logs aktivieren

Konfigurieren Sie Cloud Identity so, dass Logs an Cloud Logging weitergeleitet werden, damit Sie diese Audit-Logs wie andere Google Cloud-Logs verarbeiten können, z. B. Benachrichtigungen einrichten oder ein externes SIEM-System (Security Information and Event Management) verwenden.