Diese Seite wurde von der Cloud Translation API übersetzt.

IAM-Rollen für netzwerkbezogene Jobfunktionen

In diesem Abschnitt erfahren Sie, wie Sie IAM-Berechtigungen (Identity and Access Management) für Netzwerkszenarien konfigurieren. Es wird gezeigt, welche IAM-Rollen den netzwerkbezogenen funktionalen Rollen in Ihrem Unternehmen für die Szenarien zugewiesen werden können. Zielgruppe sind hauptsächlich Netzwerkadministratoren und Mitarbeiter, die Netzwerkaufgaben für eine Organisation erledigen. Für die im Folgenden beschriebenen Szenarien ist die Konfiguration einer Google Cloud-Organisation erforderlich.

Netzwerkbezogene Rollen und Berechtigungen werden in diesem Dokument nicht näher erläutert. Eine detaillierte Beschreibung der Rollen und Berechtigungen für Computing- und Netzwerk-APIs finden Sie unter Vordefinierte Compute Engine-IAM-Rollen.

Zentrales Team zur Verwaltung von Sicherheits- und Netzwerkaufgaben in einer Organisation

In diesem Szenario verfügt eine große Organisation über ein zentrales Team, das alle Sicherheits- und Netzwerkaufgaben verwaltet. Entwickler sind nicht berechtigt, Änderungen an den Netzwerk- oder Sicherheitseinstellungen vorzunehmen, die vom Sicherheits- und Netzwerkteam vorgenommen wurden. Sie sind jedoch berechtigt, Ressourcen (z. B. virtuelle Maschinen) in freigegebenen Subnetzen zu erstellen.

Zu diesem Zweck nutzt die Organisation eine freigegebene VPC (Virtual Private Cloud). Eine freigegebene VPC ermöglicht die Erstellung eines VPC-Netzwerks mit RFC 1918-IP-Bereichen, die von zugehörigen Projekten (Dienstprojekten) verwendet werden können. Entwickler, die diese zugehörigen Projekte verwenden, können in den freigegebenen Bereichen des VPC-Netzwerks VM-Instanzen erstellen. Die Netzwerk- und Sicherheitsadministratoren der Organisation können Subnetze, VPNs und Firewallregeln erstellen, die von allen Projekten im VPC-Netzwerk verwendet werden.

In den folgenden Tabellen finden Sie eine Beschreibung der IAM-Rollen, die dem Sicherheits- und Administratorteam sowie dem Entwicklungsteam gewährt werden müssen. Außerdem wird die zugehörige Ressourcenebene angegeben.

Ressource:	Organisation
Rollen:	Administrator für freigegebene VPCs Netzwerkadministrator Sicherheitsadministrator
Hauptkonto:	Team aus Sicherheits- und Netzwerkadministratoren

Ressource:	Hostprojekt	Diese Rolle berechtigt zur Verwendung von Subnetzen, die von der freigegebenen VPC freigegeben wurden.
Rolle:	Netzwerknutzer
Hauptkonto:	Entwickler

Ressource:	Dienstprojekt	Beachten Sie, dass diese Rolle zur Verwendung externer IP-Adressen berechtigt. Beachten Sie den Hinweis unten, um zu erfahren, wie Sie diese Aktion vermeiden können.
Rolle:	compute.instanceAdmin
Hauptkonto:	Entwickler

Für dieses Szenario benötigen Sie drei separate „allow”-Richtlinien: eine für die Organisation, eine für das Hostprojekt und eine für die Dienstprojekte.

Die erste „allow”-Richtlinie, die auf Organisationsebene angehängt werden muss, gewährt dem Netzwerk- und Sicherheitsteam die Rollen, die zum Verwalten von freigegebenen VPC-Hostprojekten benötigt werden. Dazu gehört die Möglichkeit, Dienstprojekte mit dem Hostprojekt zu verknüpfen. Darüber hinaus erhält das Netzwerk- und Sicherheitsteam die Berechtigung, alle Netzwerk- und Sicherheitsressourcen in allen Projekten der Organisation zu verwalten.

{
  "bindings": [
    {
      "role": "roles/compute.xpnAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role":"roles/compute.networkAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    }
  ]
}

Die zweite „allow”-Richtlinie muss dem Hostprojekt zugeordnet werden. Sie berechtigt Entwickler in der Organisation zur Verwendung freigegebener Netzwerke im freigegebenen VPC-Hostprojekt.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
      ]
    }
  ]
}

Die dritte „allow”-Richtlinie muss den einzelnen Dienstprojekten zugeordnet werden. Sie berechtigt Entwickler, die das Projekt verwenden, zur Verwaltung von Instanzen im Dienstprojekt und zur Verwendung von freigegebenen Subnetzen im Hostprojekt.

Bei Bedarf haben Sie die Möglichkeit, alle Dienstprojekte in einem Ordner abzulegen und diese spezielle „allow”-Richtlinie auf dieser Hierarchieebene festzulegen. Hierdurch ermöglichen Sie, dass alle in diesem Ordner erstellten Projekte die Berechtigungen des Ordners übernehmen, in dem das Serviceprojekt erstellt wird.

Sie müssen den Entwicklern auch die Rolle des Netzwerknutzers im Dienstprojekt zuweisen.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:developers@example.com"
        ]
    }
  ]
}

Zur Verwaltung von Hauptkonten wird die Verwendung von Gruppen empfohlen. Im obigen Beispiel würden Sie die Nutzer-IDs der Nutzer, die die Sicherheits- und Netzwerkeinstellungen verwalten, der sec-net-Gruppe, und Entwickler der developers-Gruppe hinzufügen. Wenn Sie ändern möchten, wer zur Ausführung der Funktion in der Lage ist, müssen Sie lediglich die Gruppenmitgliedschaft anpassen, ohne die „allow”-Richtlinie zu aktualisieren.

Separate Netzwerk- und Sicherheitsteams

In diesem Szenario verfügt eine große Organisation über zwei zentrale Teams: ein Team zur Verwaltung der Sicherheits- und Netzwerkeinstellungen und ein weiteres Team, das alle anderen Netzwerkressourcen für die gesamte Organisation verwaltet. Entwickler sind nicht berechtigt, Netzwerk- oder Sicherheitseinstellungen zu ändern, die vom Sicherheits- und Netzwerkteam vorgenommen wurden. Sie sind jedoch berechtigt, Ressourcen (z. B. virtuelle Maschinen) in freigegebenen Subnetzen zu erstellen.

Wie auch im ersten Szenario wird eine freigegebene VPC verwendet und werden für die drei Gruppen "Netzwerk", "Sicherheit" und "Entwickler" die entsprechenden Berechtigungen konfiguriert.

Ressource:	Organisation
Rollen:	Administrator für freigegebene VPCs Netzwerkadministrator
Hauptkonto:	Netzwerkadministrator-Team

Ressource:	Organisation
Rollen:	Sicherheitsadministrator Organisationsadministrator
Hauptkonto:	Sicherheitsteam

Ressource:	Hostprojekt	Diese Rolle berechtigt zur Verwendung von Subnetzen, die von der freigegebenen VPC freigegeben wurden.
Rolle:	Netzwerknutzer
Hauptkonto:	Entwickler

Ressource:	Dienstprojekt	Beachten Sie, dass diese Rolle zur Verwendung externer IP-Adressen berechtigt. Beachten Sie den Hinweis unten, um zu erfahren, wie Sie diese Aktion vermeiden können.
Rolle:	compute.instanceAdmin
Hauptkonto:	Entwickler

Für dieses Szenario benötigen Sie drei separate „allow”-Richtlinien: eine für die Organisation, eine für das Hostprojekt und eine für die Dienstprojekte.

Die erste „allow”-Richtlinie, die der Organisationsebene zugeordnet werden muss, gewährt dem Netzwerkteam die Rollen, die für die Verwaltung freigegebener VPC-Hostprojekte und die Verwaltung aller Netzwerkressourcen erforderlich sind. Dazu gehört die Möglichkeit, Dienstprojekte mit dem Hostprojekt zu verknüpfen. Die Rolle des Netzwerkadministrators gibt dem Netzwerkteam auch die Möglichkeit, sich Firewallregeln anzusehen, nicht aber sie zu ändern. Sie berechtigt das Sicherheitsteam außerdem dazu, „allow”-Richtlinien festzulegen sowie Firewallregeln und SSL-Zertifikate in allen Projekten der Organisation zu verwalten.

{
  "bindings": [
  {
    "role": "roles/compute.xpnAdmin",
    "members": [
      "group:networks@example.com"
      ]
  },
  {
    "role": "roles/compute.networkAdmin",
    "members": [
      "group:networks@example.com"
      ]
  },
  {
    "role": "roles/compute.securityAdmin",
    "members": [
      "group:security@example.com"
      ]
    },
    {
      "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "group:security@example.com"
        ]
    }
  ]
}

Die zweite „allow”-Richtlinie muss mit dem Hostprojekt verknüpft werden. Diese „allow”-Richtlinie ermöglicht Entwicklern in der Organisation, die freigegebenen Netzwerke im freigegebenen VPC-Hostprojekt zu verwenden.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
    }
  ]
}

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
      },
      {
        "role": "roles/compute.instanceAdmin",
        "members": [
          "group:developers@example.com"
          ]
      }
    ]
}

Jedes Team kann sein eigenes Netzwerk verwalten

Ein Digital Native möchte seinen Entwicklungsteams die Möglichkeit bieten, in autonomer Weise zu arbeiten. Es gibt kein zentrales Team aus IT-Administratoren. Jedes Team trägt die Verantwortung für alle Aspekte in Verbindung mit einem Projekt.

Dennoch sollen auch einige flexible Kontrollmöglichkeiten für eine formellere Struktur implementiert werden können, wenn das Team wächst und das Produkt für den Endkunden freigegeben wird.

Für dieses Szenario wird jedem Entwicklerteam ein eigener Ordner zugewiesen. Durch diese Struktur ist gewährleistet, dass einzelne Projekte, die unter dem Ordner erstellt werden, die erforderlichen Berechtigungen erhalten, und dass gleichzeitig jedes Team unabhängig arbeiten kann. Jedes Team sollte beim Festlegen von „allow”-Richtlinien für seine eigenen Ressourcen weiterhin das Prinzip der geringsten Berechtigung beachten.

Auch wenn es erst einmal dieselben Teammitglieder sind, die die Netzwerkressourcen und die tatsächlichen Ressourcen in den Projekten verwalten, ist es Best Practice, separate Gruppen für die logischen Aufgaben zu erstellen.

Dieser Ansatz ermöglicht es, den Zugriff auf die Ressourcen zu beschränken, die von temporären oder neuen Mitarbeitern benötigt werden, die erst noch geschult werden müssen, bevor Sie Netzwerkressourcen ändern können. Er bietet auch die Möglichkeit, zu ändern, welche Nutzer Zugriff auf welche Ressourcen haben, ohne die „allow”-Richtlinie jedes Mal ändern zu müssen, wenn ein Personalwechsel eintritt.

Ressource:	Ordner	Ein Dienstkonto kann zum Erstellen und Betreuen von Projekten verwendet werden.
Rollen:	Projektersteller Ordneradministrator
Hauptkonto:	Entwicklungsteamleiter Dienstkonto

Ressource:	Ordner
Rollen:	Netzwerkadministrator Sicherheitsadministrator
Hauptkonto:	Netzwerk- und Sicherheitsteam

Ressource:	Ordner	Diese Rollen erlauben es den Entwicklern, alle Aspekte von BigQuery und Compute Engine zu verwalten.
Rollen:	Instanzadministrator BigQuery-Administrator
Hauptkonto:	Entwickler

Dies setzt voraus, dass alle zugeordneten Ordner der einzelnen Teams mit einer „allow”-Richtlinie verbunden sind.

{
  "bindings": [
    {
      "role": "roles/resourcemanager.foldersAdmin",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
        ]
    },
    {
      "role":"roles/resourcemanager.projectCreator",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
        ]
    },
    {
      "role": "roles/compute.networkAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:dev01@example.com"
        ]
    },
    {
      "role": "roles/bigquery.admin",
      "members": [
        "group:dev01@example.com"
        ]
    }
  ]
}