IAM-Rollen für auditbezogene Jobfunktionen

In diesem Abschnitt wird beschrieben, wie Sie Berechtigungen für das Identity and Access Management für verschiedene Beispiel-Auditszenarien konfigurieren. Sie finden Anleitungen dazu, welche IAM-Rollen den auditbezogenen funktionalen Rollen in Ihrem Unternehmen für das jeweilige Szenario gewährt werden. Die Beispiele in diesem Thema richten sich hauptsächlich an Sicherheitsadministratoren, Prüfer und Mitarbeiter, die Auditaufgaben für eine Organisation verwalten.

Weitere Informationen zu Audit-Logs für Google Cloud finden Sie unter Cloud-Audit-Logs. Informationen zu den von IAM generierten Audit-Logs finden Sie unter IAM-Audit-Logging für Dienstkonten.

Szenario: Betriebsmonitoring

In diesem Szenario hat eine Organisation ein zentrales Sicherheitsteam, das Logs, die möglicherweise vertrauliche Informationen enthalten, sowohl in Cloud Logging als auch im Langzeitspeicher prüfen kann.

Der Verlauf der Auditdaten wird in Cloud Storage gespeichert. Die Organisation verwendet eine Anwendung, um Zugriff auf den Verlauf der Auditdaten zu gewähren. Die Anwendung verwendet ein Dienstkonto, um auf die Log-Daten zuzugreifen. Aufgrund der Vertraulichkeit einiger protokollierter Auditdaten werden diese mithilfe der Funktion Sensitive Data Protection entfernt, bevor sie aufrufbar gemacht werden.

In der folgenden Tabelle wird erläutert, welche IAM-Rollen dem CTO, dem Sicherheitsteam und dem Dienstkonto gewährt werden müssen und auf welcher Ressourcenebene dies erfolgen muss.

Rolle	Ressource	Hauptkonto	Beschreibung
resourcemanager.organizationAdmin	Organisation	CTO	Durch die Rolle resourcemanager.organizationAdmin wird dem CTO ermöglicht, dem Sicherheitsteam und dem Dienstkonto Berechtigungen zuzuweisen.
logging.viewer	Organisation	Sicherheitsteam	Mit der Rolle logging.viewer kann sich das Sicherheitsverwaltungsteam die Logs zu Administratoraktivitäten ansehen.
logging.privateLogViewer	Organisation	Sicherheitsteam	Die Rolle logging.privateLogViewer bietet die Möglichkeit, die Datenzugriffslogs einzusehen.

Nachdem die Logeinträge exportiert wurden, wird der Zugriff auf die exportierten Kopien vollständig über IAM-Berechtigungen und -Rollen an den folgenden Zielorten gesteuert: Cloud Storage, BigQuery oder Pub/Sub. In diesem Szenario ist Cloud Storage das Ziel für die Langzeitspeicherung von Audit-Logs.

Rolle	Ressource	Hauptkonto	Beschreibung
logging.viewer	Organisation	Dienstkonto	Durch die Rolle logging.viewer kann das Dienstkonto die Logs zu Administratoraktivitäten in Cloud Logging lesen.

Daten in den Datenzugriffslogs werden als personenbezogene Daten für diese Organisation betrachtet. Durch die Integration der Anwendung mit Sensitive Data Protection können vertrauliche personenbezogene Daten beim Aufrufen von Datenzugriffslogs entfernt werden, unabhängig davon, ob sie sich in den Datenzugriffslogs oder im Verlaufsarchiv in Cloud Storage befinden.

Rolle	Ressource	Hauptkonto	Beschreibung
storage.objectViewer	Bucket	Dienstkonto	Die Rolle storage.objectViewer ermöglicht dem Dienstkonto das Lesen der exportierten Logs zu Administratoraktivitäten.

Die Zulassungsrichtlinie, die an die Organisationsressource für dieses Szenario gebunden ist, sieht etwa so aus:

{
  "bindings": [{
    "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "user:[e-mail]"
      ]
    },
    {
      "role": "roles/logging.viewer",
      "members": [
        "group:[e-mail]",
        "serviceAccount:[e-mail]"
      ]
    },
    {
      "role": "roles/logging.privateLogViewer",
      "members": [
        "group:[e-mail]"
      ]
    }
  ]
}

Die Zulassungsrichtlinie, die an den Bucket gebunden ist, der als Zielsenke für dieses Szenario konfiguriert ist, sieht etwa so aus:

{
  "bindings": [{
    "role": "roles/storage.objectViewer",
    "members": [
      "serviceAccount:[e-mail]"
    ]
  }]
}

Szenario: Entwicklungsteams, die ihre Audit-Logs überwachen

In diesem Szenario müssen sich die Entwickler der Organisation die Audit-Logs ansehen, die beim Entwickeln ihrer Anwendungen generiert wurden. Sie dürfen Produktionslogs nur prüfen, wenn sie mit Sensitive Data Protection entfernt wurden. Über eine Dashboardanwendung haben die Entwickler schreibgeschützten Zugriff auf die exportierten Produktionsdaten. Das Sicherheitsteam der Organisation hat Zugriff auf alle Logs, sowohl in der Produktion als auch in der Entwicklungsumgebung.

In der folgenden Tabelle wird erläutert, welche IAM-Rollen dem Sicherheitsteam, den Entwicklern und dem Dienstkonto gewährt werden müssen und auf welcher Ressourcenebene dies erfolgen muss.

Rolle	Ressource	Hauptkonto	Beschreibung
logging.viewer	Organisation	Sicherheitsteam	Mit der Rolle logging.viewer kann sich das Sicherheitsverwaltungsteam die Logs zu Administratoraktivitäten ansehen.
logging.privateLogViewer	Organisation	Sicherheitsteam	Die Rolle logging.privateLogViewer bietet die Möglichkeit, die Datenzugriffslogs einzusehen.
logging.viewer	Ordner	Entwicklerteam	Mit der Rolle logging.viewer kann sich das Entwicklerteam die Logs zu Administratoraktivitäten ansehen, die von den Entwicklerprojekten in einem Ordner erstellt wurden, in dem sich alle Entwicklerprojekte befinden.
logging.privateLogViewer	Ordner	Entwicklerteam	Die Rolle logging.privateLogViewer bietet die Möglichkeit, die Datenzugriffslogs einzusehen.

Der Zugriff auf die exportierten Kopien wird vollständig über IAM-Berechtigungen und -Rollen an den folgenden Zielorten gesteuert: Cloud Storage, BigQuery oder Pub/Sub. In diesem Szenario ist BigQuery das Ziel für die Speicherung von Audit-Logs.

Rolle	Ressource	Hauptkonto	Beschreibung
bigquery.dataViewer	BigQuery-Dataset	Dashboarddienstkonto	Die Rolle bigquery.dataViewer ermöglicht dem Dienstkonto, das von der Dashboardanwendung verwendet wird, das Lesen der exportierten Logs zu Administratoraktivitäten.

Die Zulassungsrichtlinie, die an die Ordnerressource des Entwicklungsteams für dieses Szenario gebunden ist, sieht etwa so aus:

{
  "bindings": [{
    "role": "roles/logging.viewer",
    "members": [
      "group:[e-mail]"
    ]
  },
  {
    "role": "roles/logging.privateLogViewer",
    "members": [
      "group:[e-mail]"
    ]
  }]
}

Die Zulassungsrichtlinie, die an die Organisationsressource für dieses Szenario gebunden ist, sieht etwa so aus:

{
  "bindings": [{
    "role": "roles/logging.viewer",
    "members": [
      "group:[e-mail]"
    ]
  },
  {
    "role": "roles/logging.privateLogViewer",
    "members": [
      "group:[e-mail]"
    ]
  }]
}

Die Zulassungsrichtlinie, die an das BigQuery-Dataset gebunden ist, das als Zielsenke für dieses Szenario konfiguriert ist, sieht etwa so aus:

{
  "bindings": [{
    "role": "roles/bigquery.dataViewer",
    "members": [
      "serviceAccount:[e-mail]"
    ]
  }]
}

Szenario: Externe Prüfer

In diesem Szenario werden Audit-Logs für eine Organisation zusammengefasst und an einen zentralen Senkenspeicherort exportiert. Ein externer Prüfer erhält mehrmals pro Jahr Zugriff auf die Audit-Logs der Organisation, um sie zu überprüfen. Der Prüfer ist nicht berechtigt, personenbezogene Daten in den Logs zu Administratoraktivitäten einzusehen. Es wird über ein Dashboard Zugriff auf die in BigQuery gespeicherten Verlaufslogs und auf Anfrage auf die Cloud Logging-Logs zu Administratoraktivitäten gewährt, um diese Anforderung zu erfüllen.

Die Organisation erstellt eine Google-Gruppe für diese externen Prüfer und fügt der Gruppe den aktuellen Prüfer hinzu. Diese Gruppe wird überwacht und in der Regel wird ihm Zugriff auf die Dashboardanwendung gewährt.

Beim normalen Zugriff wird der Google-Gruppe des Prüfers nur gestattet, auf die in BigQuery gespeicherten Verlaufslogs zuzugreifen. Wenn Anomalien festgestellt werden, erhält die Gruppe die Berechtigung, sich über den Dashboardmodus für erweiterten Zugriff die eigentlichen Cloud Logging-Logs zu Administratoraktivitäten anzusehen. Am Ende jedes Auditzeitraums wird der Zugriff für die Gruppe widerrufen.

Daten werden mit Sensitive Data Protection entfernt, bevor sie über die Dashboardanwendung eingesehen werden können.

In der folgenden Tabelle wird erläutert, welche IAM-Logging-Rollen ein Organisationsadministrator dem Dienstkonto zuweisen kann, das vom Dashboard verwendet wird, und auf welcher Ressourcenebene dies erfolgen muss.

Rolle	Ressource	Hauptkonto	Beschreibung
logging.viewer	Organisation	Dashboarddienstkonto	Durch die Rolle logging.viewer kann das Dienstkonto die Logs zu Administratoraktivitäten in Cloud Logging lesen.
bigquery.dataViewer	BigQuery-Dataset	Dashboarddienstkonto	Die Rolle bigquery.dataViewer ermöglicht dem Dienstkonto, das von der Dashboardanwendung verwendet wird, das Lesen der exportierten Logs zu Administratoraktivitäten.

Die Zulassungsrichtlinie, die an die Organisationsressource für dieses Szenario gebunden ist, sieht etwa so aus:

{
  "bindings": [{
    "role": "roles/logging.viewer",
    "members": [
      "serviceAccount:[e-mail]"
    ]
  }]
}

Die Zulassungsrichtlinie, die an das BigQuery-Dataset gebunden ist, das als Zielsenke für dieses Szenario konfiguriert ist, sieht etwa so aus:

{
  "bindings": [{
    "role": "roles/bigquery.dataViewer",
    "members": [
      "serviceAccount:[e-mail]"
    ]
  }]
}