Ablehnungsrichtlinien

Mit IAM-Ablehnungsrichtlinien (Identity and Access Management) können Sie Leitlinien für den Zugriff auf Google Cloud-Ressourcen festlegen. Mit Ablehnungsrichtlinien können Sie Ablehnungsregeln definieren, die verhindern, dass bestimmte Hauptkonten bestimmte Berechtigungen verwenden, unabhängig von den ihnen zugewiesenen Rollen.

Auf dieser Seite erhalten Sie eine Übersicht über Ablehnungsrichtlinien und Ablehnungsregeln. Informationen zum Erstellen und Aktualisieren von Ablehnungsrichtlinien finden Sie unter Zugriff auf Ressourcen verweigern.

Funktionsweise von Ablehnungsrichtlinien

Ablehnungsrichtlinien bestehen aus Ablehnungsregeln. Jede Ablehnungsregel gibt Folgendes an:

• Eine Reihe von Hauptkonten, für die Berechtigungen abgelehnt werden
• Die Berechtigungen, die für die Hauptkonten abgelehnt werden oder nicht verwendet werden können
• Optional: Die Bedingung, die erfüllt sein muss, damit die Berechtigung abgelehnt wird

Wenn die Berechtigung für ein Hauptkonto abgelehnt wird, kann es nichts tun, das diese Berechtigung erfordert, unabhängig von den IAM-Rollen, die ihm zugewiesen wurde. Das liegt daran, dass IAM immer relevante Ablehnungsrichtlinien überprüft, bevor die relevanten Zulassungsrichtlinien geprüft werden. Weitere Informationen finden Sie unter Richtlinienbewertung.

Um anzugeben, wo eine Ablehnungsrichtlinie gelten soll, hängen Sie sie an ein Projekt, einen Ordner oder eine Organisation an. Wenn eine Ablehnungsrichtlinie an eine dieser Ressourcen angehängt wird, können die Hauptkonten in der Richtlinie nicht die angegebenen Berechtigungen für den Zugriff auf die Ressource oder auf eines der Nachfolgerelemente der Ressource verwenden. Weitere Informationen dazu, wo Sie eine Ablehnungsrichtlinie anhängen können, finden Sie auf dieser Seite unter Anknüpfungspunkt.

Sie können einer einzelnen Ressource mehrere Richtlinien für die Zugriffsverweigerung zuweisen. Auf diese Weise können Sie separate Ablehnungsrichtlinien für verschiedene Arten von Ablehnungsregeln erstellen. Sie können beispielsweise compliance-bezogene Ablehnungsregeln in eine Richtlinie einfügen und dann eine andere Richtlinie für andere Ablehnungsregeln verwenden. Jede Ablehnungsrichtlinie wird unabhängig von allen anderen Ablehnungsrichtlinien ausgewertet.

Für jede Ressource können bis zu 500 Ablehnungsrichtlinien festgelegt werden. Zusammen können diese Ablehnungsrichtlinien insgesamt 500 Ablehnungsregeln enthalten.

Verknüpfungspunkt

Jede Ablehnungsrichtlinie ist mit einer Organisation, einem Ordner oder einem Projekt verknüpft. Wenn Sie eine Ablehnungsrichtlinie an eine dieser Ressourcen anhängen, wird sie von allen untergeordneten Ressourcen in diesem Projekt, Ordner oder dieser Organisation übernommen. Um mit Ablehnungsrichtlinien zu arbeiten, benötigen Sie eine Kennzeichnung für die Ressource, mit der die Ablehnungsrichtlinie verknüpft ist. Diese wird als Anhangspunkt bezeichnet. Diese Kennzeichnung verwendet eines der Formate in der folgenden Tabelle:

Übernahme von Ablehnungsrichtlinien

Ablehnungsrichtlinien, wie Zulassungsrichtlinien, werden über die Ressourcenhierarchie übernommen. Wenn Sie eine Ablehnungsrichtlinie an ein Projekt, einen Ordner oder eine Organisation anhängen, gilt die Richtlinie auch für alle Ressourcen in diesem Projekt, diesem Ordner oder dieser Organisation.

Wenn eine Ablehnungsrichtlinie für eine Organisation beispielsweise besagt, dass ein Hauptkonto keine bestimmte Berechtigung verwenden kann, kann das Hauptkonto diese Berechtigung nicht für eine Ressource innerhalb der Organisation verwenden. Diese Regel gilt auch dann, wenn die Ordner und Projekte innerhalb dieser Organisation striktere Ablehnungsrichtlinien haben.

Wenn eine Ablehnungsrichtlinie für ein Projekt besagt, dass ein Hauptkonto keine bestimmte Berechtigung verwenden kann, kann das Hauptkonto diese Berechtigung nicht für jede Ressource innerhalb des Projekts verwenden. Diese Regel gilt auch dann, wenn die übergeordnete Organisation und die Ordner striktere Richtlinien für den Ausschluss haben.

Ablehnungsbedingungen

Ablehnungsbedingungen geben die Bedingungen an, die erfüllt sein müssen, damit eine Ablehnungsregel angewendet wird. Wenn die Bedingung true ergibt oder nicht ausgewertet werden kann, gilt die Ablehnungsregel und die Hauptkonten können die angegebenen Berechtigungen nicht verwenden. Wenn die Bedingung false ergibt, gilt die Ablehnungsregel nicht und die Hauptkonten können die angegebenen Berechtigungen verwenden, wenn sie sie haben.

Ablehnungsbedingungen haben dieselbe Struktur wie IAM-Bedingungen. Ablehnungsbedingungen erkennen jedoch nur Ressourcen-Tag-Funktionen.

Informationen zum Schreiben von Bedingungen finden Sie in der Übersicht über IAM-Bedingungen.

Berechtigungsgruppen

Bei einigen Diensten können Sie Berechtigungsgruppen ablehnen. Berechtigungsgruppen sind Sätze von Berechtigungen, die einem bestimmten Muster entsprechen. Mit einer Berechtigungsgruppe können Sie mehrere zugehörige Berechtigungen ablehnen, z. B. alle Berechtigungen für einen einzelnen Dienst oder eine einzelne Ressource.

Unterstützte Berechtigungsgruppen sind unter In Ablehnungsrichtlinien unterstützte Berechtigungen aufgeführt. Bei den IDs für die unterstützten Berechtigungsgruppen wird ein oder mehrere Abschnitte eines Berechtigungsnamens durch einen Platzhalter (*) ersetzt. Die Berechtigungen, die jede Gruppe enthält, hängen von der Position des Platzhalters ab:

• SERVICE_FQDN/RESOURCE.*: Alle Berechtigungen für die angegebene Ressource werden abgelehnt.
• SERVICE_FQDN/*.*: Alle Berechtigungen für den angegebenen Dienst werden abgelehnt.
• SERVICE_FQDN/*.VERB: Alle Berechtigungen für einen Dienst werden abgelehnt, die auf das angegebene Verb enden.

Berechtigungsgruppen umfassen alle aktuellen und zukünftigen Berechtigungen, die dem angegebenen Muster entsprechen. Angenommen, Sie verwenden die Berechtigungsgruppe example.googleapis.com/exampleResource.*, um einem Nutzer alle Berechtigungen für den Ressourcentyp exampleResource zu verweigern. Wenn example.googleapis.com eine neue Berechtigung für den Ressourcentyp exampleResource hinzufügt, z. B. example.googleapis.com/exampleResource.newPermission, wird dem Nutzer die neue Berechtigung automatisch verweigert.

Sie können Platzhalter nur in unterstützten Berechtigungsgruppen verwenden. Die Verwendung von Platzhaltern in anderen Berechtigungsnamen wird nicht unterstützt.

Struktur einer Ablehnungsrichtlinie

Eine Ablehnungsrichtlinie ist eine Sammlung von Metadaten und Ablehnungsregeln. Eine Ablehnungsregel verknüpft eine Reihe von Hauptkonten mit einer Reihe von Berechtigungen, die für die Hauptkonten abgelehnt werden oder von ihnen nicht verwendet werden können. Jede Regel kann auch eine Bedingung angeben, die bestimmt, wann die Berechtigung abgelehnt wird.

Die folgende Ablehnungsrichtlinie verhindert beispielsweise, dass Hauptkonten Projekte löschen, es sei denn, das Hauptkonto ist Mitglied der Gruppe project-admins oder das zu löschende Projekt hat ein Tag mit dem Wert test.

{
  "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion",
  "uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816",
  "kind": "DenyPolicy",
  "displayName": "Only project admins can delete projects.",
  "etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=",
  "createTime": "2021-09-07T23:15:35.258319Z",
  "updateTime": "2021-09-07T23:15:35.258319Z",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete",
          "cloudresourcemanager.googleapis.com/folders.*"
        ],
        "exceptionPermissions": [
          "cloudresourcemanager.googleapis.com/folders.list",
          "cloudresourcemanager.googelapis.com/folders.get"
        ],
        "denialCondition": {
          "title":  "Only for non-test projects",
          "expression": "!resource.matchTag('12345678/env', 'test')"
        }
      }
    }
  ]
}

In den folgenden Abschnitten werden die Felder in den Metadaten und Ablehnungsregeln der Ablehnungsrichtlinie beschrieben.

Metadaten

Ablehnungsrichtlinien enthalten die folgenden Metadaten:

• name: Der Name der Ablehnungsrichtlinie. Dieser Name hat das Format policies/ATTACHMENT_POINT/denypolicies/POLICY_ID, wobei ATTACHMENT_POINT das Projekt, der Ordner oder die Organisation ist, mit der die Ablehnungsrichtlinie verknüpft ist, und POLICY_ID die alphanumerische ID der Ablehnungsrichtlinie.
• uid: Eine eindeutige ID, die der Ablehnungsrichtlinie von Google zugewiesen wurde.
• kind: Die Art der Richtlinie. kind ist für eine Ablehnungsrichtlinie immer DenyPolicy.
• displayName: Optional. Ein für Menschen lesbarer Name für die Ablehnungsrichtlinie.
• etag: Eine Kennung für eine Version der Richtlinie. Damit widersprüchliche Aktualisierungen verhindert werden, muss der Wert etag mit dem in IAM gespeicherten Wert übereinstimmen. Wenn die etag-Werte nicht übereinstimmen, schlägt die Anfrage fehl.
• createTime: Der Zeitpunkt, zu dem die Ablehnungsrichtlinie erstellt wurde.
• updateTime: Der Zeitpunkt der letzten Aktualisierung der Ablehnungsrichtlinie.

Ablehnungsregeln

Jede Ablehnungsregel kann die folgenden Felder enthalten:

• deniedPrincipals: Die Hauptkonten, für die diese Berechtigungen abgelehnt werden. Sie können einzelne Hauptkonten und Gruppen von Hauptkonten auflisten. Zu den einzelnen Hauptkontotypen gehören Nutzerkonten, Dienstkonten und einzelne Identitäten in einem Workforce- oder Workload Identity-Pool. Zu den Hauptkontogruppen gehören Google-Gruppen, Cloud Identity-Domains, Mitarbeiter- oder Arbeitslastidentitäten und alle Nutzer im Internet.

  Eine Liste der gültigen Hauptkontotypen und ‑Kennungen finden Sie unter Hauptkonto-IDs der IAM v2 API.

• exceptionPrincipals: Optional. Die Hauptkonten, die von der Ablehnungsregel ausgeschlossen sind. Für diese Hauptkonten werden die angegebenen Berechtigungen nicht abgelehnt, auch wenn sie in deniedPrincipals aufgeführt sind oder Teil einer in deniedPrincipals aufgeführten Gruppe sind.

  Sie können einzelne Hauptkonten und Gruppen von Hauptkonten auflisten. Zu den einzelnen Hauptkontotypen gehören Nutzerkonten, Dienstkonten und einzelne Identitäten in einem Workforce- oder Workload Identity-Pool. Zu den Hauptkontogruppen gehören Google-Gruppen, Cloud Identity-Domains, Mitarbeiter- oder Arbeitslastidentitäten und alle Nutzer im Internet.

  Eine Liste der gültigen Hauptkontotypen und ‑Kennungen finden Sie unter Hauptkonto-IDs der IAM v2 API.

• deniedPermissions: Die Berechtigungen, die die angegebenen Hauptkonten nicht verwenden können oder die für sie abgelehnt wurden. Diese Berechtigungen verwenden das IAM-v2-Berechtigungsformat, das voll qualifizierte Domainnamen (FQDNs) zur Identifizierung des Dienstes verwendet. Das Format ist SERVICE_FQDN/RESOURCE.ACTION. Google APIs verwenden die Domain *.googleapis.com. Beispiel: iam.googleapis.com/roles.delete.

  Nur bestimmte Berechtigungen können abgelehnt werden. Eine vollständige Liste der Berechtigungen, die abgelehnt werden können, finden Sie unter In Ablehnungsrichtlinien unterstützte Berechtigungen.

  In einigen Fällen können Sie mit Berechtigungsgruppen Berechtigungssätze ablehnen. Weitere Informationen finden Sie unter Berechtigungsgruppen.

• exceptionPermissions: Optional. Eine Liste der Berechtigungen, die die angegebenen Hauptkonten verwenden können, auch wenn diese Berechtigungen in deniedPermissions enthalten sind. Beispielsweise können Sie mit diesem Feld Ausnahmen für bestimmte Berechtigungen in einer Berechtigungsgruppe festlegen.

• denialConditions: Optional. Ein logischer Ausdruck, der sich auf die Gültigkeit einer Ablehnungsregel auswirkt. Wenn die Bedingung true ergibt oder nicht ausgewertet werden kann, wird die Berechtigung abgelehnt. Wenn die Bedingung false ergibt, wird die Berechtigung nicht abgelehnt. Weitere Informationen finden Sie unter Ablehnungsbedingungen auf dieser Seite.

Gängige Anwendungsfälle

Im Folgenden finden Sie häufig vorkommende Situationen, in denen Sie Ablehnungsrichtlinien verwenden können, und Beispiele für die Ablehnungsregeln, die Sie in den einzelnen Situationen erstellen könnten. Informationen zum Erstellen und Aktualisieren von Ablehnungsrichtlinien finden Sie unter Zugriff auf Ressourcen verweigern.

Administratorberechtigungen zentralisieren

Sie können Ablehnungsrichtlinien verwenden, um bestimmte Arten von administrativen Aktivitäten auf eine bestimmte Gruppe von Hauptkonten zu beschränken.

Angenommen, Sie möchten die Verwaltung benutzerdefinierter Rollen für Ihre Organisation auf ein zentrales Team beschränken. Dazu erstellen Sie eine Ablehnungsregel, die die Berechtigungen zur Verwaltung benutzerdefinierter Rollen für alle Nutzer ablehnt, außer für Nutzer in der administrativen Gruppe (custom-role-admins):

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/custom-role-admins@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/roles.create",
    "iam.googleapis.com/roles.delete",
    "iam.googleapis.com/roles.update",
  ]
}

Anschließend hängen Sie die Ablehnungsrichtlinie an Ihre Organisation an.

Jetzt können nur Mitglieder der Gruppe custom-role-admins benutzerdefinierte Rollen verwalten, auch wenn andere Nutzer die erforderlichen Berechtigungen haben.

Angenommen, sowohl Yuri als auch Tal haben die Rolle „Administrator für Organisationsrollen“ (roles/iam.organizationRoleAdmin). Yuri ist jedoch Mitglied von custom-role-admins und Tal ist es nicht. Bei dieser Ablehnungsrichtlinie kann nur Yuri Rollen erstellen, löschen und aktualisieren.

Ausnahmen für Zugriffsgewährungen erstellen

Sie können übernommene Berechtigungen mithilfe von Ablehnungsrichtlinien ablehnen. Diese Funktion bietet Ihnen die Möglichkeit, eine Rolle auf hoher Ebene in der Ressourcenhierarchie zuzuweisen und anschließend wenn nötig die Berechtigungen der Rolle für einzelne untergeordnete Ressourcen abzulehnen.

Angenommen, Sie haben den Ordner Engineering, der mehrere Projekte enthält. Sie möchten der Gruppe eng die Berechtigungen der Rolle "Dienstkontoschlüssel-Administrator" (roles/iam.serviceAccountKeyAdmin) für fast alle Projekte im Ordner erteilen. Die Gruppe soll jedoch nicht die Möglichkeit haben, Dienstkontoschlüssel in einem bestimmten Projekt im Ordner example-prod zu erstellen und zu löschen.

Anstatt in jedem einzelnen Projekt die Rolle „Zentraler Dienstkontoadministrator“ zu gewähren, erstellen Sie die folgende Ablehnungsregel, die das Erstellen und Löschen von Berechtigungen in der Rolle „Zentraler Dienstkontoadministrator“ für die Hauptkonten in der Gruppe eng abgelehnt:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Anschließend fügen Sie diese Ablehnungsregel einer Ablehnungsrichtlinie hinzu und hängen die Richtlinie an das Projekt example-prod an.

Nachdem Sie die Ablehnungsrichtlinie an das Projekt angehängt haben, können Sie der Gruppe eng im Ordner Engineering die Rolle „Zentraler Dienstkontoadministrator“ zuweisen, ohne dass die Gruppe Dienstkontoschlüssel in example-prod erstellen oder löschen kann.

Mitglieder der Gruppe eng können dann Dienstkontoschlüssel in allen Projekten außer example-prod erstellen und löschen. Wenn Izumi beispielsweise Mitglied der Gruppe eng ist, kann sie Schlüssel für Dienstkonten in example-dev und example-test erstellen und löschen, aber nicht in example-prod.

Angenommen, Sie möchten, dass eine Teilmenge der Gruppe eng Dienstkontoschlüssel in example-prod erstellen und löschen kann. Diese Teilmenge wird durch die Gruppe eng-prod repräsentiert. Damit die Mitglieder der Gruppe eng-prod Dienstkontoschlüssel in example-prod erstellen und löschen können, können Sie die Gruppe von der Ablehnungsregel ausnehmen:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/eng-prod@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Bei dieser überarbeiteten Ablehnungsrichtlinie können Mitglieder der Gruppe eng-prod Dienstkontoschlüssel in allen Projekten erstellen und löschen, einschließlich example-prod. Wenn Karl beispielsweise Mitglied der Gruppe eng-prod ist, kann er Schlüssel in example-dev, example-test und example-prod erstellen und löschen, auch wenn er Mitglied der Gruppe eng ist.

Zugriff anhand von Tags blockieren

Ein Tag ist ein Schlüssel/Wert-Paar, das an eine Organisation, einen Ordner oder ein Projekt angehängt werden kann. Sie können Ablehnungsrichtlinien verwenden, um Berechtigungen basierend auf Tags abzulehnen, ohne jeder Rollenzuweisung eine IAM-Bedingung hinzuzufügen.

Angenommen, Sie taggen alle Ihre Projekte als dev, test oder prod. Sie möchten, dass nur Mitglieder der Gruppe project-admins Projekte mit dem Tag prod löschen können.

Erstellen Sie zum Beheben dieses Problems eine Ablehnungsregel, die allen Nutzern mit Ausnahme der Gruppe project-admins die Berechtigung cloudresourcemanager.googleapis.com/projects.delete für Ressourcen mit dem Tag prod verweigert:

{
  "displayName": "Only project admins can delete production projects.",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "denialCondition": {
          "title":  "Only for prod projects",
          "expression": "resource.matchTag('12345678/env', 'prod')"
        }
      }
    }
  ]
}

Anschließend fügen Sie diese Ablehnungsregel einer Ablehnungsrichtlinie hinzu und hängen die Richtlinie an Ihre Organisation an.

Aufgrund dieser Ablehnungsregel können Sie den Zugriff von Hauptkonten einschränken, ohne eine Bedingung zu ihren Rollenzuweisungen hinzuzufügen. Stattdessen können Sie Hauptkonten Rollen mit der Berechtigung cloudresourcemanager.googleapis.com/projects.delete zuweisen und sich auf die Ablehnungsregel verlassen, um zu verhindern, dass Hauptkonten außerhalb der Gruppe project-admins Projekte mit dem Tag prod löschen können.

Angenommen, Sie haben zwei Nutzer, Bola und Kiran. Beide Nutzer haben die Rolle „Projektlöscher“ (roles/resourcemanager.projectDeleter). Darüber hinaus ist Kiran Mitglied der Gruppe project-admins. Bei dieser Ablehnungsrichtlinie kann Bola nur Projekte löschen, die das Tag dev oder test haben. Kiran kann alle Projekte unabhängig von ihren Tags löschen.

Nächste Schritte

• Informationen zum Erstellen, Aktualisieren und Löschen von Ablehnungsrichtlinien
• Zugriffsprobleme durch Ablehnungsrichtlinien beheben
• Berechtigungen ansehen, die verweigert werden können
• Weitere Informationen zu den Arten von Hauptkonten, die Sie in Ablehnungsrichtlinien angeben können