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.

Sie können mehrere Ablehnungsrichtlinien an eine einzelne Ressource anhängen. 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.

Jede Ressource kann bis zu 500 Ablehnungsrichtlinien haben. Zusammen können diese Ablehnungsrichtlinien insgesamt 500 Ablehnungsregeln enthalten.

Hinweis: Änderungen am Zugriff eines Hauptkontos entsprechen der Eventual Consistency. Das bedeutet, dass es einige Zeit dauert, bis Zugriffsänderungen im System wirksam werden. Informationen darüber, wie lange es durchschnittlich dauert, bis Zugriffsänderungen weitergegeben werden, finden Sie unter Zugriffsänderungsverteilung.

Richtlinienbewertung

Wenn ein Hauptkonto versucht, auf eine Ressource zuzugreifen, wertet IAM alle relevanten Zulassungs- und Ablehnungsrichtlinien aus, um festzustellen, ob das Hauptkonto auf die Ressource zugreifen darf. Die Richtlinien werden in dieser Reihenfolge bewertet:

1. IAM prüft alle relevanten Ablehnungsrichtlinien, um festzustellen, ob die Berechtigung für das Hauptkonto abgelehnt wurde. Relevante Ablehnungsrichtlinien sind die Ablehnungsrichtlinien, die mit der Ressource verknüpft sind, sowie alle übernommenen Ablehnungsrichtlinien.

   Wenn irgendeine dieser Ablehnungsrichtlinien das Hauptkonto daran hindert, eine erforderliche Berechtigung zu verwenden, verhindert IAM, dass es auf die Ressource zugreift.

   Wenn keine Ablehnungsrichtlinien verhindern, dass das Hauptkonto eine erforderliche Berechtigung verwendet, fährt IAM mit dem nächsten Schritt fort.

2. IAM prüft alle relevanten Zulassungsrichtlinien, um zu ermitteln, ob das Hauptkonto die erforderlichen Berechtigungen hat. Relevante Zulassungsrichtlinien sind die Zulassungsrichtlinien, die der Ressource zugeordnet sind, sowie alle übernommenen Zulassungsrichtlinien.

   Wenn das Hauptkonto die erforderlichen Berechtigungen hat, ermöglicht IAM ihm den Zugriff auf die Ressource.

   Wenn der Hauptkonto nicht die erforderlichen Berechtigungen hat, verhindert IAM, dass es auf die Ressource zugreift.

Das folgende Diagramm zeigt diesen Richtlinienbewertungsablauf:

Ü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 Gruppen verwandter Berechtigungen ablehnen. Sie können beispielsweise alle Berechtigungen für einen einzelnen Dienst oder eine einzelne Ressource ablehnen.

Unterstützte Berechtigungsgruppen sind unter In Ablehnungsrichtlinien unterstützte Berechtigungen aufgeführt. In anderen Berechtigungsnamen können Sie keine Platzhalter verwenden.

Die Kennung für eine Berechtigungsgruppe ersetzt einen oder mehrere Abschnitte eines Berechtigungsnamens durch ein Platzhalterzeichen (*). Die Berechtigungsgruppe enthält alle Berechtigungen, die diesem Muster entsprechen.

Platzhalter können an folgenden Stellen angezeigt werden:

• SERVICE_FQDN/RESOURCE.*: Alle Berechtigungen für die angegebene Ressource werden abgelehnt.
• SERVICE_FQDN/.: Verweigert alle Berechtigungen für den angegebenen Dienst.
• SERVICE_FQDN/*.VERB: Verweigert alle Berechtigungen für einen Dienst, der im angegebenen Verb endet.

Berechtigungsgruppen enthalten alle aktuellen und zukünftigen Berechtigungen, die mit dem angegebenen Muster übereinstimmen. 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 automatisch die neue Berechtigung verweigert.

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 von [e-mail] 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/[e-mail]"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "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 Groups-Gruppen, Cloud Identity-Domains, Gruppen von Workforce- und Workload Identitys sowie alle Nutzer im Internet.

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

• 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 Groups-Gruppen, Cloud Identity-Domains, Gruppen von Workforce- und Workload Identitys und alle Nutzer im Internet.

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

• 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 dafür 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 auch Berechtigungssätze ablehnen. Weitere Informationen finden Sie unter Berechtigungsgruppen.

• 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 ([e-mail]):

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "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 [e-mail] benutzerdefinierte Rollen verwalten, auch wenn andere Nutzer die erforderlichen Berechtigungen haben.

Stellen Sie sich beispielsweise vor, [e-mail] und [e-mail] haben die Rolle "Administrator für Organisationsrollen" (roles/iam.organizationRoleAdmin). Allerdings ist [e-mail] Mitglied von [e-mail] und [e-mail] ist dies nicht. Bei dieser Ablehnungsrichtlinie kann nur [e-mail] 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 [e-mail] 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 "Dienstkontoschlüssel-Administrator" zu gewähren, erstellen Sie die folgende Ablehnungsregel, die das Erstellen und Löschen von Berechtigungen in der Rolle "Dienstkontoschlüsse-Administrator" für die Hauptkonten in [e-mail] abgelehnt:

{
  "deniedPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "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 die Rolle "Dienstkontoschlüssel-Administrator" zu [e-mail] im Ordner Engineering zuweisen, ohne dass die Gruppe Dienstkontoschlüssel in example-prod erstellen oder löschen kann.

Mitglieder von [e-mail] können dann Dienstkontoschlüssel in allen Projekten außer example-prod erstellen und löschen. Wenn [e-mail] beispielsweise Mitglied von [e-mail] ist, kann dieses Hauptkonto Schlüssel für Dienstkonten in example-dev und example-test erstellen und löschen, aber nicht in example-prod.

Beispiel: Sie möchten, dass eine Teilmenge von [e-mail] Dienstkontoschlüssel in example-prod erstellen und löschen kann. Diese Teilmenge wird durch die Gruppe [e-mail] repräsentiert. Damit die Mitglieder von [e-mail] Dienstkontoschlüssel in example-prod erstellen und löschen können, können Sie die Gruppe von der Ablehnungsregel ausschließen:

{
  "deniedPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Bei dieser überarbeiteten Ablehnungsrichtlinie können Mitglieder von [e-mail] Dienstkontoschlüssel in allen Projekten erstellen und löschen, einschließlich example-prod. Wenn [e-mail] beispielsweise Mitglied von [e-mail] ist, kann dieses Hauptkonto Schlüssel in example-dev, example-test und example-prod erstellen und löschen. Dies gilt auch, wenn es außerdem Mitglied von [e-mail] sind.

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 von [e-mail] Projekte mit dem Tag prod löschen können.

Erstellen Sie zum Beheben dieses Problems eine Ablehnungsregel, die allen Nutzern mit Ausnahme von [e-mail] 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/[e-mail]"
        ],
        "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 von [e-mail] Projekte mit dem Tag prod löschen können.

Angenommen, Sie haben zwei Nutzer, [e-mail] und [e-mail]. Beide Nutzer haben die Rolle „Projektlöscher“ (roles/resourcemanager.projectDeleter). Darüber hinaus ist [e-mail] Mitglied von [e-mail]. Bei dieser Ablehnungsrichtlinie kann [e-mail] nur Projekte löschen, die das Tag dev oder test haben. [e-mail] 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
• Siehe die Hauptkontotypen, die Sie in Ablehnungsrichtlinien aufnehmen können.