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 Cloud de Confiance by S3NS -Ressourcen mit Identity and Access Management (IAM) beschrieben.

Arten von Gruppen

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

In diesem Dokument werden die folgenden Arten von Gruppen verwendet:

  • Organisationsgruppen

    Organisationsgruppen stellen Teilmengen der Organisationsstruktur dar und basieren in der Regel auf Personaldaten. Sie können auf Abteilungen, der Berichtsstruktur, dem geografischen Standort oder anderen Organisationsgruppen 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 reorganisiert wird. Bei einer Reorganisation können neue Gruppen erstellt oder vorhandene Gruppen eingestellt werden.

    Beispiele für Organisationsgruppen 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

    Zusammenarbeitsgruppen repräsentieren Arbeitsgruppen, Projektmitglieder oder Nutzer, die an einem Projekt zusammenarbeiten oder ein bestimmtes Thema diskutieren möchten.

    Die Struktur von Gruppen für die Zusammenarbeit ist nicht an eine Organisationsstruktur gebunden. Sie werden oft ad hoc im Selfservice-Verfahren erstellt.

    Die Mitgliedschaft in Kollaborationsgruppen kann uneingeschränkt sein, sodass jeder in der Organisation beitreten kann. Alternativ kann eine Gruppe für die Zusammenarbeit selbstverwaltet sein. Das bedeutet, dass bestimmte Mitglieder entscheiden können, wer sonst noch in die Gruppe aufgenommen wird.

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

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

  • Zugriffsgruppen

    Zugriffsgruppen werden ausschließlich für die Bereitstellung des Zugriffs verwendet. Sie stellen Jobfunktionen dar und werden verwendet, um die Zuweisung von Rollen zu vereinfachen, die für die Ausführung dieser Jobfunktionen erforderlich sind. Anstatt Rollen einzelnen Hauptkonten zuzuweisen, weisen Sie Rollen der Gruppe zu und verwalten dann die Gruppenmitgliedschaft.

    Die Struktur von Zugriffsgruppen wird durch die Struktur der Ressourcen oder Arbeitslasten in Ihrer Organisation beeinflusst. Für die Bereitstellung einer neuen Ressource oder eines neuen Arbeitslasttyps 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 die Anfragen von Nutzern zum Beitritt zur Gruppe genehmigen.

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

    Zugriffsgruppen werden nur für den Zugriff verwendet. Sie werden nicht für Kommunikationszwecke verwendet.

  • Durchsetzungsgruppen

    Erzwingungsgruppen ähneln Zugriffsgruppen, werden aber verwendet, um Richtlinien zur Zugriffsbeschränkung zu erzwingen, anstatt Zugriff zu gewähren.

    Die Struktur von Erzwingungsgruppen wird in der Regel durch eine Kombination aus Compliance-Anforderungen und Organisationsstruktur beeinflusst.

    Die Mitgliedschaft in einer Erzwingungsgruppe wird in der Regel durch eine Reihe vordefinierter Regeln bestimmt, die sich auf die Sicherheitsfreigabe, den Standort oder die Rolle eines Nutzers in der Organisation beziehen.

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

    Erzwingungsgruppen werden nur zum Erzwingen von Richtlinien zur Zugriffsbeschränkung verwendet. Sie werden nicht für die Kommunikation verwendet.

Benennen Sie Ihre Gruppen entsprechend ihrem Typ.

Damit Sie die Best Practices im Rest dieses Dokuments leichter umsetzen können, sollten Sie Gruppennamen verwenden, anhand derer Sie den Typ einer Gruppe bestimmen 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 gemacht wird:

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

  • Zusammenarbeitsgruppen: collab.TEAM_NAME@example.com. Beispiel: collab.msmiths-team@example.com.

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

  • Erzwingungsgruppen: enforcement.GROUP_DESCRIPTION@example.com. Beispiel: enforcement.sso-users@example.com.

Wählen Sie die Konvention aus, die für Ihre Organisation am besten geeignet ist und von Ihrer Software zur Gruppenverwaltung unterstützt wird. Durch die Verwendung eines Präfixes 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. Für sekundäre Domains, die eine Subdomain einer bestätigten Domain sind, ist keine Bestätigung erforderlich und sie 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 außerdem verhindern, dass eingehende E‑Mails an Gruppen gesendet werden, die nicht für die Kommunikation vorgesehen sind.

Regeln für das Verschachteln

Für verschiedene Arten von Gruppen gelten unterschiedliche Regeln dafür, ob das Einbetten (Akzeptieren einer Gruppe als Mitglied) zulässig ist.

Regeln für das Verschachteln von Organisationsgruppen

Es empfiehlt sich, Organisationsgruppen so zu verschachteln, dass sie Ihr Organigramm widerspiegeln. Bei diesem Ansatz wird jeder Mitarbeiter in eine Gruppe aufgenommen und die Gruppen umfassen sich dann gegenseitig. 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 ist viel einfacher, als jedes Mitglied einer Organisationsgruppe einer anderen Gruppe hinzuzufügen.

Fügen Sie einer Organisationsgruppe keine anderen Gruppentypen als Mitglieder hinzu. Verwenden Sie keine Zugriffs-, Durchsetzungs- oder Zusammenarbeitsgruppen als Teil einer Organisationshierarchie.

Regeln für das Verschachteln von Gruppen für die Zusammenarbeit

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

Zusammenarbeitsgruppen können Organisationsgruppen als Mitglieder haben.

Regeln für das Verschachteln von Zugriffsgruppen

Normalerweise sollten Sie Zugriffsgruppen nicht verschachteln. Durch das Verschachteln von Zugriffsgruppen kann es schwierig sein, festzustellen, wer Zugriff auf welche Ressourcen hat. Außerdem kann es durch das Verschachteln von Zugriffsgruppen mit unterschiedlichen Zugriffsrichtlinien möglich sein, strenge Richtlinien für die Gruppenmitgliedschaft in Zugriffsgruppen zu umgehen.

Zugriffsgruppen können Organisationsgruppen als Mitglieder haben.

Regeln für das Verschachteln von Erzwingungsgruppen

Vermeiden Sie das Verschachteln von Erzwingungsgruppen. Durch das Verschachteln von Erzwingungsgruppen kann es schwierig sein, festzustellen, warum einem Hauptkonto der Zugriff verweigert wird. Außerdem kann das Verschachteln von Erzwingungsgruppen mit unterschiedlichen Mitgliedschaftsrichtlinien dazu führen, dass einige Principals von unbeabsichtigten Einschränkungen betroffen sind.

Durchsetzungsgruppen können Organisationsgruppen als Mitglieder haben.

Organisationsgruppen verwalten

Mit den folgenden Best Practices können Sie Ihre Organisationsgruppen verwalten.

Bereitstellung aus einer einzigen Quelle

Da Organisationsgruppen auf Personaldaten basieren, sollten sie am besten ausschließlich über ein Personalinformationssystem oder eine externe Quelle der Wahrheit bereitgestellt werden, 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 einer Organisationsgruppe hinzu und entfernen Sie sie nicht manuell daraus. Lassen Sie auch nicht zu, dass Nutzer sich selbst aus einer Organisationsgruppe entfernen.

Verwenden Sie keine Organisationsgruppen, um Zugriff auf Ressourcen zu gewähren.

Alle Nutzer in einer Organisationsgruppe benötigen selten denselben Zugriff auf Ressourcen. Aus diesem Grund führt das Gewähren des Zugriffs auf eine Organisationsgruppe wahrscheinlich dazu, dass einige Mitglieder der Gruppe mehr Zugriff haben, als sie tatsächlich benötigen.

Außerdem kann es je nach Synchronisierungshäufigkeit zwischen dem externen IdP und Cloud Identity zu einer Verzögerung kommen, bis Änderungen in einem externen IdP in Cloud Identity übernommen werden. Diese Verzögerung kann dazu führen, dass nicht erforderliche Berechtigungen immer weiter verbreitet werden. Das kann 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 nur Rollen mit eingeschränkten Berechtigungen zu, z. B. „Organisationsbetrachter“. Verwenden Sie andernfalls Zugriffsgruppen, um Zugriff auf Ressourcen zu gewähren.

Dienstkonten und externe Nutzer in Organisationsgruppen nicht zulassen

Dienstkonten sollten nicht in Organisationsgruppen enthalten sein, da sie keine Personen darstellen.

Externe Nutzer – Nutzer mit einem anderen Google Workspace- oder Cloud Identity-Konto – gehören in der Regel nicht zu Ihrer Organisation. Daher gibt es keinen Grund, warum sie Mitglied einer Organisationsgruppe sein sollten. Wenn Sie Ihre externen Mitarbeiter in Ihr eigenes Google Workspace- oder Cloud Identity-Konto aufnehmen, 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.

Zusammenarbeitsgruppen verwalten

Mit den folgenden Best Practices können Sie Ihre Kollaborationsgruppen verwalten.

Google Groups for Business zum Verwalten von Gruppen für die Zusammenarbeit verwenden

Wenn Sie Google Workspace verwenden, können Sie Google Groups for Business nutzen, um Gruppen für die Zusammenarbeit zu verwalten. So können Nutzer Google Groups verwenden, um Gruppen zu erstellen, zu durchsuchen und ihnen beizutreten. Sie müssen Google Groups for Business konfigurieren, damit Nutzer neue Gruppen für die Zusammenarbeit erstellen können.

Google Groups for Business deaktivieren, wenn Sie den Dienst nicht verwenden

Wenn Sie Cloud Identity, aber nicht Google Workspace verwenden, gibt es keinen Grund, in Cloud Identity Kollaborationsgruppen zu haben. Es ist daher am besten, Groups for Business zu deaktivieren, um zu verhindern, dass Ihre Nutzer Gruppen in Cloud Identity erstellen.

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 Nutzern erlauben, neue Google Groups for Business-Gruppen zu erstellen.

Durch das Erzwingen eines Suffixes wird verhindert, dass Nutzer eine Gruppe mit einem Namen erstellen, der absichtlich mit einer Zugriffs- oder Organisationsgruppe kollidiert, die aus einer externen Quelle bereitgestellt werden soll. In diesem Szenario könnte der Creator der fälschlicherweise benannten Gruppe für die Zusammenarbeit seine Berechtigungen eskalieren.

Zusammenarbeitsgruppen nicht für die Zugriffssteuerung verwenden

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

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

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

Zugriffsgruppen verwalten

Mit den folgenden Best Practices können Sie Ihre Zugriffsgruppen verwalten.

Das richtige Tool zum Verwalten Ihrer Zugriffsgruppen auswählen

Da Zugriffsgruppen von Arbeitslastinhabern verwaltet werden, sollten Sie ein Tool verwenden, das für den Self-Service geeignet ist. Mit Ihrem Tool sollten Nutzer vorhandene Zugriffsgruppen finden und Sicherheitsvorkehrungen durchsetzen können, die die folgenden Kontrollen 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 von Audit-Trails

Ein Tool, das diese Anforderungen erfüllt, sind JIT-Gruppen.

Zugriffsgruppen verwenden, um Jobfunktionen zu modellieren und Zugriff auf Ressourcen zu gewähren

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

Sie können eine einzelne Zugriffsgruppe verwenden, um Zugriff auf mehrere Ressourcen oder sogar mehrere Projekte zu gewähren. Achten Sie jedoch darauf, dass jedes Gruppenmitglied den Zugriff benötigt, den Sie der Gruppe gewähren. Wenn einige Nutzer den zusätzlichen Zugriff nicht 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

Wenn Sie Zugriffsgruppen für mehrere Arbeitslasten wiederverwenden, führt dies zu einer übermäßigen Berechtigung und einer komplexen Verwaltung.

Barrieren für das Erstellen von Zugriffsgruppen für Arbeitslastinhaber beseitigen

Um die Versuchung zu verringern, eine vorhandene Zugriffsgruppe wiederzuverwenden, sollten Sie dafür sorgen, dass sich Zugriffsgruppen einfach erstellen und verwalten lassen. Workload-Inhaber sollten in der Lage sein, selbstständig Zugriffsgruppen zu erstellen und dabei die richtige Namensgebung zu unterstützen.

Nutzern ermöglichen, Zugriffsgruppen zu finden und ihnen beizutreten

Wenn Nutzer vorhandene Zugriffsgruppen finden und den benötigten Gruppen beitreten können, ist es weniger wahrscheinlich, dass sie unnötige Berechtigungen erhalten. Bei Bedarf können Sie ein Einladungs- oder Genehmigungsverfahren verwenden, um zu steuern, wer der Gruppe beitreten kann.

Mitgliedschaften standardmäßig automatisch ablaufen lassen

Nutzer müssen einer Zugriffsgruppe nach einer bestimmten Zeit wieder beitreten oder ihre Mitgliedschaft verlängern. Durch diese Vorgehensweise wird die Mitgliedschaft in einer Zugriffsgruppe bewusst erschwert und ein Anreiz geschaffen, nicht benötigte Mitgliedschaften auslaufen zu lassen. Diese Best Practice ist entscheidend, um das Ziel von Zero Standing Privileges (ZSP) zu erreichen, und ist besonders wichtig für externe Nutzer.

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

Jeder Gruppe bestimmte Inhaber zuweisen

Jede Zugriffsgruppe sollte mindestens einen zugewiesenen Inhaber haben. Das fördert das Verantwortungsbewusstsein für die Gruppenmitgliedschaft. Die Inhaber können dieselbe Person oder dasselbe Team sein, die bzw. das die mit der Gruppe verknüpfte Arbeitslast besitzt.

Sichtbarkeit von Zugriffsgruppen einschränken

Zugriffsgruppen nicht im Gruppenverzeichnis anzeigen 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. Diese Praktiken verhindern, dass böswillige Akteure wertvolle Informationen erhalten.

Externe Mitglieder einschränken

Da Einschränkungen für die Richtlinie zur Freigabe mit eingeschränkter Domain für Gruppen, aber nicht für Gruppenmitglieder gelten, können Zugriffsgruppen, die externe Mitglieder zulassen, eine Lücke schaffen, die die Freigabe mit eingeschränkter Domain untergräbt.

Verwenden Sie Cloud Identity-Sicherheitsgruppen und Gruppeneinschränkungen, um externe Mitglieder für Zugriffsgruppen zuzulassen oder zu verbieten. Außerdem sollten Sie eine spezielle Namenskonvention wie external.access.GROUP_NAME@example.com für Zugriffsgruppen verwenden, die externe Mitglieder zulassen.

Maßnahmengruppen verwalten

Mit den folgenden Best Practices können Sie Ihre Durchsetzungsgruppen verwalten.

Das richtige Tool zum Verwalten von Durchsetzungsgruppen auswählen

Da die Mitgliedschaft in Erzwingungsgruppen auf Organisationsregeln basiert und zur Anwendung von Sicherheitsbeschränkungen verwendet wird, sollten Mitglieder nicht die Möglichkeit haben, sich abzumelden oder selbst aus einer Erzwingungsgruppe zu entfernen.

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

Wenn Sie keine dynamischen Gruppen verwenden können, sollten Sie Terraform oder ein anderes IaC-Tool (Infrastructure as Code) verwenden, um Ihre Erzwingungsgruppen bereitzustellen. Wenn Sie IaC zum Erstellen von Erzwingungsgruppen verwenden, achten Sie darauf, dass Sie der Pipeline keinen unnötig weitreichenden Zugriff gewähren.

Durchsetzungsgruppen für die obligatorische Zugriffssteuerung und Authentifizierungssteuerung verwenden

Mit Erzwingungsgruppen können Sie die obligatorische Zugriffssteuerung erzwingen. Cloud de Confiance unterstützt die obligatorische Zugriffssteuerung mit einer Reihe von Diensten und Tools, darunter:

Mit Erzwingungsgruppen lassen sich auch Authentifizierungsmaßnahmen wie die Zuweisung von SAML-Profilen oder die 2-Faktor-Authentifizierung (2FA) anwenden.

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

Nutzern nicht erlauben, eine Erzwingungsgruppe zu verlassen

Wenn Nutzer eine Erzwingungsgruppe verlassen dürfen, widerspricht das den Grundsätzen der obligatorischen Zugriffssteuerung. Wenn Sie verhindern möchten, dass Nutzer die Gruppe verlassen, verwenden Sie die Groups Settings API, um die Eigenschaft whoCanLeaveGroup auf NONE_CAN_LEAVE festzulegen.

Best Practices für externe Identitätsanbieter

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

Keine externe Quelle für Zugriffsgruppen verwenden

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

  • Verzögerungen bei der Bereitstellung

    Es kann mehrere Stunden dauern, bis Änderungen, die im externen IdP vorgenommen wurden, in der Zugriffsgruppe berücksichtigt werden.

  • Risiko von Abweichungen

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

    Durch Abweichungen können Nutzer Zugriff auf Daten behalten, die sie nicht benötigen, und erhalten falsche Informationen darüber, wer Zugriff hat. Außerdem kann es schwieriger sein, Zugriffsgruppen zu erstellen.

Um diese Fallstricke zu vermeiden, sollten Sie externe IdPs nur zum Bereitstellen von Organisations- und Erzwingungsgruppen verwenden und ein Tool wie JIT-Gruppen verwenden, um Zugriffsgruppen direkt in Cloud Identity zu verwalten.

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

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

Bei vielen IdPs lässt sich dieses Problem umgehen, indem Sie eine Pseudo-E-Mail-Adresse aus dem Namen der Gruppe ableiten, z. B. mit my-group@example.com. Das funktioniert, kann aber zu Konflikten führen, wenn diese E-Mail-Adresse bereits von einer anderen Gruppe oder einem anderen Nutzer verwendet wird. Im schlimmsten Fall könnte diese Namenskollision von einem böswilligen Akteur ausgenutzt werden, um Sicherheitsgruppen zu erstellen, die sich als ein anderer, weniger genau untersuchter Gruppentyp ausgeben.

Um das Risiko von Konflikten zu vermeiden, verwenden Sie eine eigene sekundäre Domain für Gruppen, die Sie aus der externen Quelle wie groups.example.com bereitstellen.

Bereitstellungspipelines nicht die Rolle „Gruppenadministrator“ zuweisen

Wenn Sie IaC zum Verwalten von Gruppen verwenden (z. B. Terraform), muss Ihre Bereitstellungspipeline die erforderlichen Berechtigungen haben, um ihre Aufgabe zu erfüllen. Mit der Rolle „Groups Admin“ wird die Gruppenerstellung autorisiert. Außerdem können alle Hauptkonten mit dieser Rolle alle Gruppen im Cloud Identity-Konto verwalten.

Sie können den Zugriff auf eine Pipeline einschränken, indem Sie ein Dienstkonto mit nur einer Berechtigung (der Möglichkeit, eine Gruppe zu erstellen) erstellen und die Pipeline dann 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 berechtigt wird, Gruppen zu verwalten, die sie nicht erstellt hat.

Im Folgenden wird dieser Ansatz beschrieben:

  1. Erstellen Sie eine benutzerdefinierte Administratorrolle, die nur die Berechtigung zum Erstellen von Gruppen für die Admin API enthält.

    Geben Sie dieser Rolle einen beschreibenden Namen, z. B. „Gruppenersteller“.

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

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

Cloud Logging zum Prüfen und Überwachen Ihrer Gruppen verwenden

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

Änderungen an Mitgliedschaften prüfen

Wenn Sie ein Mitglied einer Organisationsgruppe, Zugriffsgruppe oder Erzwingungsgruppe hinzufügen oder entfernen, kann sich das auf die Ressourcen auswirken, auf die das Mitglied Zugriff hat. Daher ist es wichtig, einen Prüfpfad zu führen, in dem diese Änderungen nachverfolgt werden.

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

Damit Ihre Monitoring-Daten aussagekräftiger sind, können Sie Nutzer dazu auffordern, eine Begründung anzugeben, wenn sie einer Gruppe beitreten oder den Beitritt zu einer Gruppe beantragen, und die Begründung protokollieren. Wenn es einen Genehmigungsprozess gibt, protokollieren Sie Details dazu, wer die Anfrage genehmigt hat.

Diese zusätzlichen Metadaten können Ihnen später helfen, zu analysieren, warum jemand einer Gruppe hinzugefügt wurde und warum er 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. So können Sie diese Audit-Logs genauso wie andere Cloud de Confiance Logs verarbeiten, z. B. Benachrichtigungen einrichten oder ein externes SIEM-System (Security Information and Event Management) verwenden.