Richtlinien- und Zugriffsprobleme beheben

Dieses Dokument bietet eine Übersicht über die Durchsetzung von Google Cloud-Zugriffsrichtlinien und den Tools, die Ihnen bei der Behebung von Zugriffsproblemen zur Verfügung stehen. Dieses Dokument richtet sich an Supportteams, die Kunden in ihrer Organisation bei der Behebung von Problemen beim Zugriff auf ihre Google Cloud-Ressourcen unterstützen möchten.

Steuerelemente für die Durchsetzung von Google Cloud-Zugriffsrichtlinien

In diesem Abschnitt werden die Richtlinien beschrieben, die Sie oder der Administrator Ihrer Organisation implementieren können, der sich auf den Zugriff auf Ihre Google Cloud-Ressourcen auswirkt. Sie implementieren Zugriffsrichtlinien mithilfe der folgenden oder einiger der folgenden Produkte und Tools:

Labels, Tags und Netzwerktags

Google Cloud bietet verschiedene Möglichkeiten, Ressourcen mit Labels zu versehen und zu gruppieren. Sie können Labels, Tags und Netzwerktags verwenden, um Richtlinien zu erzwingen.

Labels sind Schlüssel/Wert-Paare, mit denen Sie Ihre Google Cloud-Ressourcen organisieren können. Viele Google Cloud-Dienste unterstützen Labels. Sie können Labels auch verwenden, um Ressourcen für andere Anwendungsfälle zu filtern und zu gruppieren, z. B. um alle Ressourcen zu identifizieren, die sich in einer Testumgebung befinden, im Gegensatz zu Ressourcen, die sich in der Produktion befinden. Im Rahmen der Durchsetzung von Richtlinien können Labels identifizieren, wo sich Ressourcen befinden sollten. Beispielsweise unterscheiden sich die Zugriffsrichtlinien, die Sie für Ressourcen testen, die als Test gekennzeichnet sind, von den Zugriffsrichtlinien, die Sie auf Ressourcen anwenden, die als Produktionsressourcen gekennzeichnet sind.

Tags sind Schlüssel/Wert-Paare, die einen Mechanismus zum Identifizieren von Ressourcen und zum Anwenden der Richtlinie bereitstellen. Sie können Tags an eine Organisation, einen Ordner oder ein Projekt anhängen. Ein Tag gilt für alle Ressourcen auf Hierarchieebene, auf die das Tag angewendet wird. Mit Tags können Sie Zugriffsrichtlinien abhängig davon zulassen oder ablehnen, ob eine Ressource ein bestimmtes Tag hat. Sie können auch Tags mit Firewallrichtlinien verwenden, um den Traffic in einem VPC-Netzwerk (Virtual Private Cloud) zu steuern. Für die Fehlerbehebung ist es wichtig zu verstehen, wie Tags übernommen und mit Zugriffs- und Firewallrichtlinien kombiniert werden.

Netzwerktags unterscheiden sich von den vorherigen Ressourcenmanager-Tags. Netzwerktags gelten für VM-Instanzen und bieten Ihnen eine weitere Möglichkeit, den Netzwerktraffic zu und von einer VM zu steuern. In Google Cloud-Netzwerken erkennen Netzwerks, welche VMs Firewallregeln und Netzwerkrouten unterliegen. Sie können Netzwerktags als Quell- und Zielwerte in Firewallregeln verwenden. Außerdem können Sie Netzwerktags verwenden, um zu ermitteln, für welche VMs eine bestimmte Route gilt. Mit Netzwerktags können Sie Zugriffsprobleme beheben, da Netzwerktags zur Definition von Netzwerk- und Routingregeln verwendet werden.

VPC-Firewallregeln

Sie können VPC-Firewallregeln konfigurieren, um Traffic zu und von Ihren VM-Instanzen und Produkten, die auf VMs basieren, zuzulassen oder abzulehnen. Jedes VPC-Netzwerk wirkt wie eine verteilte Firewall. Obwohl VPC-Firewallregeln auf Netzwerkebene definiert sind, werden Verbindungen pro Instanz zugelassen oder verweigert. Sie können VPC-Firewallregeln auf das VPC-Netzwerk, nach Tags gruppierte VMs und nach Dienstkonten gruppierte VMs anwenden.

VPC Service Controls

VPC Service Controls bietet eine Perimeter-Sicherheitslösung, mit der die Daten-Exfiltration aus Google Cloud-Diensten wie Cloud Storage und BigQuery minimiert werden kann. Sie erstellen einen Dienstperimeter, der eine Sicherheitsgrenze um Google Cloud-Ressourcen erstellt. Sie können festlegen, was innerhalb des Perimeters zulässig ist. Durch das Implementieren von Richtlinien, die auf Kontextattributen wie IP-Adresse und Identität basieren bietet VPC Service Controls auch kontextsensitive Zugriffskontrollen.

Resource Manager

Mit Resource Manager richten Sie eine Organisationsressource ein. Resource Manager bietet Tools, mit denen Sie Ihre Organisation und die Art und Weise, wie Sie Anwendungen entwickeln, einer Ressourcenhierarchie zuordnen können. Resource Manager bietet nicht nur eine logische Gruppierung von Ressourcen, sondern ermöglicht Ihnen auch das Zuweisen und Übernehmen von Zugriffssteuerungs- und Organisationsrichtlinien.

Identity and Access Management

Mit Identity and Access Management (IAM) können Sie definieren, wer (Identität) welchen Zugriff (Rolle) für welche Ressource hat. Eine IAM-Richtlinie ist eine Sammlung von Anweisungen, die festlegen, wer welche Art von Zugriff erhält, z. B. Lese- oder Schreibzugriff. Die IAM-Richtlinie ist mit einer Ressource verknüpft und die Richtlinie erzwingt die Zugriffssteuerung, wenn ein Nutzer versucht, auf die Ressource zuzugreifen.

Eine Funktion von IAM ist IAM Conditions. Wenn Sie IAM-Bedingungen als Teil Ihrer Richtliniendefinition implementieren, können Sie festlegen, dass Identitäten (Hauptkonten) nur dann Ressourcenzugriff gewährt wird, wenn die konfigurierten Bedingungen erfüllt sind. Sie können beispielsweise IAM-Bedingungen verwenden, um den Zugriff auf Ressourcen nur auf Mitarbeiter zu beschränken, die Anfragen von Ihrer Unternehmenszentrale aus stellen.

Organisationsrichtliniendienst

Mit dem Organisationsrichtliniendienst können Sie Einschränkungen für unterstützte Ressourcen in der Organisationshierarchie erzwingen. Für jede Ressource, die von der Organisationsrichtlinie unterstützt wird, gibt es eine Reihe von Einschränkungen, die festlegen, wie die Ressource eingeschränkt werden kann. Sie definieren eine Richtlinie, die bestimmte Regeln definiert, die die Ressourcenkonfiguration einschränken.

Mit dem Organisationsrichtliniendienst können Sie als autorisierter Administrator die standardmäßigen Organisationsrichtlinien auf Ordner- oder Projektebene nach Bedarf überschreiben. In Organisationsrichtlinien geht es hauptsächlich darum, wie Ressourcen konfiguriert werden, während sich IAM-Richtlinien darauf konzentrieren, welche Berechtigungen Ihre Identitäten für diese Ressourcen gewährt haben.

Kontingente

Google Cloud erzwingt Kontingente für Ressourcen, die festlegen, wie viel von einer bestimmten Google Cloud-Ressource Ihr Projekt nutzen darf. Die Anzahl Ihrer Projekte unterliegt ebenfalls einem Kontingent. Die folgenden Arten von Ressourcennutzungen sind durch Kontingente beschränkt:

  • Ratenkontingente, wie API-Anfragen pro Tag. Diese Art von Kontingent wird nach einer bestimmten Zeit zurückgesetzt, z. B. nach einer Minute oder einem Tag.
  • Zuteilungskontingente, wie die Anzahl der vom Projekt genutzten virtuellen Maschinen oder der Load-Balancer. Dieses Kontingent wird nicht zurückgesetzt. Ein Zuweisungskontingent muss explizit freigegeben werden, wenn Sie die Ressource nicht mehr verwenden möchten, z. B. durch Löschen eines GKE-Clusters (Google Kubernetes Engine).

Wenn Sie ein Limit beim Zuteilungskontingent erreichen, können Sie keine neuen Ressourcen starten. Wenn Sie ein Ratenkontingent erreichen, können Sie API-Anfragen nicht abschließen. Beide Probleme können wie ein Zugriffsproblem aussehen.

Chrome Enterprise Premium

Chrome Enterprise Premium verwendet verschiedene Google Cloud-Produkte, um eine detaillierte Zugriffskontrolle basierend auf der Identität und dem Kontext eines Nutzers der Anfrage zu erzwingen. Sie können Chrome Enterprise Premium so konfigurieren, dass der Zugriff auf die Google Cloud Console und auf Google Cloud APIs eingeschränkt wird.

Der Chrome Enterprise Premium-Zugriffsschutz funktioniert mit den folgenden Google Cloud-Diensten:

  • Identity-Aware Proxy (IAP): Ein Dienst, der die Nutzeridentität prüft und anhand des Kontexts bestimmt, ob einem Nutzer Zugriff auf eine Ressource gewährt werden soll.
  • IAM: Der Identitäts- und Autorisierungsdienst für Google Cloud.
  • Access Context Manager: Eine Regel-Engine, die eine detaillierte Zugriffssteuerung ermöglicht.
  • Endpunktprüfung: Eine Google Chrome-Erweiterung, die Gerätedetails von Nutzern erfasst.

IAM Recommender

IAM enthält Policy Intelligence-Tools, die Ihnen eine umfassende, proaktive Anleitung bieten, um bei der Verwendung von Google Cloud effizienter und sicherer zu sein. Empfohlene Aktionen werden Ihnen durch Benachrichtigungen in der Konsole bereitgestellt, die Sie direkt oder mithilfe eines an ein Pub/Sub-Thema gesendeten Ereignisses anwenden können.

IAM Recommender gehört zur Policy Intelligence-Suite und Sie können damit das Prinzip der geringsten Berechtigung anwenden. Recommender vergleicht Rollenzuweisungen auf Projektebene mit den Berechtigungen, die jedes Hauptkonto in den letzten 90 Tagen verwendet hat. Wenn Sie einem Hauptkonto eine Rolle auf Projektebene zuweisen und das Hauptkonto nicht alle Berechtigungen dieser Rolle verwendet, empfiehlt Recommender möglicherweise, dass Sie die Rolle widerrufen. Bei Bedarf empfiehlt Recommender auch striktere Rollen als Ersatz.

Wenn Sie eine Empfehlung automatisch anwenden, können Sie versehentlich verhindern, dass ein Nutzer oder Dienstkonto Zugriff auf eine Ressource erhält. Wenn Sie sich für die Automatisierung entscheiden, finden Sie unter Best Practices für IAM-Recommender eine Entscheidungshilfe für die Automatisierung.

Kubernetes-Namespaces und RBAC

Kubernetes wird als verwalteter Dienst in Google Cloud als Google Kubernetes Engine (GKE) ausgeführt. GKE kann Richtlinien erzwingen, die ungeachtet des Ausführungsortes Ihres GKE-Clusters konsistent sind. Die Richtlinien, die den Zugriff auf Ressourcen beeinflussen, sind eine Kombination aus integrierten Kubernetes-Steuerelementen und Google Cloud-spezifischen Steuerelementen.

Zusätzlich zu VPC-Firewalls und VPC-Dienststeuerungen verwendet GKE Namespaces, rollenbasierte Zugriffssteuerung (RBAC) und Arbeitslastidentitäten, um Richtlinien zu verwalten, die sich auf den Zugriff auf Ressourcen auswirken.

Namespaces

Namespaces sind virtuelle Cluster, die von demselben physischen Cluster unterstützt werden und einen Bereich für Namen bieten. Namen von Ressourcen müssen innerhalb eines Namespace eindeutig sein, Sie können jedoch denselben Namen in verschiedenen Namespaces verwenden. Mit Namespaces können Sie Ressourcenkontingente verwenden, um Clusterressourcen auf mehrere Nutzer zu verteilen.

RBAC

RBAC enthält folgende Features:

  • Detaillierte Kontrolle darüber, wie Nutzer auf die API-Ressourcen zugreifen, die in Ihrem Cluster ausgeführt werden
    • Ermöglicht das Erstellen detaillierter Richtlinien, die definieren, auf welche Vorgänge und Ressourcen Nutzer und Dienstkonten zugreifen dürfen.
    • Kann den Zugriff für Google-Konten, Google Cloud-Dienstkonten und Kubernetes-Dienstkonten steuern.
  • Ermöglicht das Erstellen von RBAC-Berechtigungen, die für den gesamten Cluster oder nur für bestimmte Namespaces innerhalb des Clusters gelten.
    • Clusterweite Berechtigungen dienen dazu, den Zugriff auf bestimmte API-Ressourcen für bestimmte Nutzer zu beschränken. Diese API-Ressourcen enthalten Sicherheitsrichtlinien und Secrets.
    • Namespace-spezifische Berechtigungen sind nützlich, wenn Sie mehrere Gruppen von Nutzern haben, die jeweils in eigenen Namespaces arbeiten. Mithilfe von RBAC können Sie dafür sorgen, dass Nutzer nur Zugriff auf Clusterressourcen innerhalb ihres eigenen Namespace haben.
  • Eine Rolle, die nur dazu verwendet werden kann, Zugriff auf Ressourcen innerhalb eines einzelnen Namespace zu gewähren.
  • Eine Rolle mit Regeln, die einen Satz von Berechtigungen darstellen. Berechtigungen sind rein additiv und es gibt keine Ablehnungsregeln.

IAM und Kubernetes RBAC sind so eingebunden, dass Nutzer berechtigt sind, Aktionen auszuführen, wenn sie ausreichende Berechtigungen für beide Tools haben.

Abbildung 1 zeigt, wie Sie IAM mit RBAC und Namespaces zum Implementieren von Richtlinien verwenden.

IAM und die rollenbasierte Zugriffssteuerung der Google Kubernetes Engine steuern gemeinsam den Zugriff auf einen GKE-Cluster (zum Vergrößern klicken).

Abbildung 1 zeigt die folgenden Richtlinienimplementierungen:

  1. Auf Projektebene definiert IAM Rollen für Clusteradministratoren, um Cluster zu verwalten und um Containerentwicklern den Zugriff auf APIs innerhalb von Clustern zu ermöglichen.
  2. Auf Clusterebene definiert RBAC Berechtigungen für einzelne Cluster.
  3. Auf Namespace-Ebene definiert RBAC Berechtigungen für Namespaces.

Workload Identity

Neben RBAC und IAM müssen Sie die Auswirkungen von Arbeitslastidentitäten verstehen. Mit Workload Identity können Sie ein Kubernetes-Dienstkonto so konfigurieren, dass es als Google-Dienstkonto fungiert. Jede Anwendung, die als Kubernetes-Dienstkonto ausgeführt wird, wird beim Zugriff auf Google Cloud APIs automatisch als Google-Dienstkonto authentifiziert. Mit dieser Authentifizierung können Sie eine detaillierte Identität und Autorisierung für Anwendungen in Ihrem Cluster zuweisen.

Workload Identity Federation for GKE beruht auf IAM-Berechtigungen, um zu steuern, auf welche Google Cloud APIs die GKE-Anwendung zugreifen kann. Wenn sich beispielsweise die IAM-Berechtigungen ändern, kann eine GKE-Anwendung möglicherweise nicht in Cloud Storage schreiben.

Tools zur Fehlerbehebung

In diesem Abschnitt werden die Tools beschrieben, die Ihnen zum Beheben von Richtlinienproblemen zur Verfügung stehen. Sie können verschiedene Produkte und Features verwenden, um eine Kombination von Richtlinien anzuwenden. Beispielsweise können Sie Firewalls und Subnetze verwenden, um die Kommunikation zwischen Ressourcen in Ihrer Umgebung und in von Ihnen definierten Sicherheitszonen zu verwalten. Sie können IAM auch verwenden, um einzuschränken, wer innerhalb der Sicherheitszone und in den von Ihnen definierten VPC Service Controls-Zonen darauf zugreifen kann.

Logs

Wenn ein Problem auftritt, sehen Sie sich als Erstes die Logs an. Die Google Cloud-Logs, die Aufschluss über Zugriffsprobleme geben, sind Cloud-Audit-Logs, Logging von Firewallregeln und VPC-Flusslogs.

Cloud-Audit-Logs

Cloud-Audit-Logs bestehen aus den folgenden Audit-Log-Streams für jedes Projekt, jeden Ordner und jede Organisation: Administratoraktivität, Datenzugriff und Systemereignis. Die Google Cloud-Dienste schreiben Audit-Logeinträge in diese Logs, um festzustellen, welcher Nutzer wo und wann eine Aktion in Ihren Google Cloud-Projekten ausgeführt hat.

  • Administratoraktivitätslogs enthalten Log-Einträge für API-Aufrufe oder andere Verwaltungsmaßnahmen, die die Konfiguration oder die Metadaten von Ressourcen ändern. Administratoraktivitäts-Logs sind immer aktiviert. Informationen zu Preisen und Kontingenten für Administratoraktivitätslogs finden Sie in der Übersicht zu Cloud-Audit-Logs.
  • In Datenzugriffslogs werden API-Aufrufe zum Erstellen, Ändern oder Lesen der von Nutzern bereitgestellten Daten erfasst. Audit-Logs zum Datenzugriff sind standardmäßig deaktiviert, mit Ausnahme von BigQuery. Die Datenzugriffslogs können sehr groß sein und zusätzliche Kosten verursachen. Informationen zu Nutzungslimits für Datenzugriffslogs finden Sie unter Kontingente und Limits. Informationen zu den möglichen Kosten finden Sie unter Preise.
  • Systemereignislogs enthalten Logeinträge über die Ausführung eines Systemereignisses durch Compute Engine. Zum Beispiel wird jede Live-Migration als Systemereignis protokolliert. Informationen zu Preisen und Kontingenten für Systemereignisse finden Sie in der Übersicht zu Cloud-Audit-Logs.

In Cloud Logging enthält das Feld protoPayload ein AuditLog-Objekt, mit dem die Audit-Logging-Daten gespeichert werden. Ein Beispiel für einen Audit-Logeintrag finden Sie im Beispiel für einen Audit-Logeintrag.

Um Audit-Logs zur Administratoraktivität aufzurufen, benötigen Sie entweder die Rolle "Logbetrachter" (roles/logging.viewer) oder die einfache Rolle "Betrachter" (roles/viewer). Wählen Sie, wenn möglich, die Rolle mit den geringsten Berechtigungen aus, die zum Ausführen der Aufgabe erforderlich sind.

Die einzelnen Audit-Logeinträge werden für einen bestimmten Zeitraum gespeichert. Für eine längere Aufbewahrung können Sie die Logeinträge in Cloud Storage, BigQuery oder Pub/Sub exportieren. Sie können aggregierte Exporte verwenden, um Logeinträge aus allen Projekten, Ordnern und Rechnungskonten Ihrer Organisation zu exportieren. Aggregierte Exporte bieten Ihnen eine zentrale Möglichkeit, Logs im gesamten Unternehmen zu prüfen.

So verwenden Sie Ihre Audit-Logs für die Fehlerbehebung:

  • Prüfen Sie, ob Sie die erforderlichen IAM-Rollen zum Anzeigen der Logs haben. Wenn Sie die Logs exportieren, benötigen Sie außerdem Berechtigungen zum Aufrufen der exportierten Logs in der Senke.
  • Befolgen Sie die Best Practices für die Verwendung von Audit-Logs, um Ihre Audit-Strategie zu erfüllen.
  • Wählen Sie eine Teamstrategie aus, um Logs aufzurufen. Es gibt mehrere Möglichkeiten, Logs aufzurufen.
  • Auf der Seite Aktivität der Google Cloud Console erhalten Sie einen groben Überblick über Ihre Aktivitätslogs.
  • Exportierte Logs aus der Senke anzeigen, in die sie exportiert wurden. Logs außerhalb der Aufbewahrungsdauer sind nur in der Senke sichtbar. Sie können die exportierten Logs auch verwenden, um eine Vergleichsanalyse durchzuführen, etwa zu einem Zeitpunkt, an dem alles wie erwartet funktioniert.

Logging von Firewallregeln

Durch das Logging der Firewallregeln können Sie deren Auswirkungen im Blick behalten, prüfen und analysieren. Sie können beispielsweise feststellen, ob eine Firewallregel, die Traffic abweisen soll, wie vorgesehen funktioniert.

Sie aktivieren das Logging von Firewallregeln für jede Firewallregel, deren Verbindungen Sie protokollieren möchten. Die Option des Loggings von Firewallregeln kann für jede Firewallregel unabhängig von der Aktion (zulassen oder ablehnen) oder der Richtung (eingehend oder ausgehend) genutzt werden. Logging von Firewallregeln kann viele Daten generieren. Logging von Firewallregeln ist mit Gebühren verbunden. Sie müssen also sorgfältig planen, welche Verbindungen Sie als Logs speichern möchten.

Legen Sie fest, wo Ihre Firewalllogs gespeichert werden sollen. Wenn Sie eine organisationsweite Ansicht Ihrer Logs benötigen, exportieren Sie die Firewalllogs in dieselbe Senke wie Ihre Audit-Logs. Verwenden Sie Filter, um nach bestimmten Firewallereignissen zu suchen.

Firewall Insights

Firewall Insights bietet Berichte mit Informationen zur Firewallnutzung und den Auswirkungen verschiedener Firewallregeln für Ihr VPC-Netzwerk. Mithilfe von Firewall Insights können Sie prüfen, ob die beabsichtigten Verbindungen durch Firewallregeln zugelassen oder blockiert werden.

Sie können mit Firewall Insights auch Firewallregeln erkennen, die von anderen Regeln blockiert sind. Eine verdeckte Regel ist eine Firewall-Regel, deren relevante Attribute wie IP-Adressbereiche und Ports von Attributen aus einer oder mehreren anderen Firewallregeln mit höherer oder gleicher Priorität überlappt werden. Verdeckte Regeln werden innerhalb von 24 Stunden nach Aktivierung des Loggings von Firewallregeln berechnet.

Wenn Sie das Logging von Firewallregeln aktivieren, analysiert Firewall Insights Logs, um Einblicke in alle Ablehnungsregeln vorzuschlagen, die für den von Ihnen festgelegten Beobachtungszeitraum verwendet werden (standardmäßig die letzten 24 Stunden). Die Informationen zu den Ablehnungsregeln liefern Ihnen Firewall-Pakete-Drop-Signale. Mithilfe der Paket-Drop-Signale können Sie prüfen, ob die Pakete aufgrund von Sicherheitsmaßnahmen erwartet verworfen wurden oder aufgrund von Problemen wie Netzwerkfehlkonfigurationen verloren gegangen sind.

VPC-Flusslogs

VPC-Flusslogs erfassen eine Stichprobe von Netzwerkflüssen, die von VM-Instanzen gesendet und empfangen werden. VPC-Flusslogs umfassen den Traffic, der sich auf eine VM auswirkt. Der gesamte ausgehende Traffic wird in Logs erfasst, auch wenn der ausgehende Traffic durch eine Firewallregel zum Blockieren des ausgehenden Traffics blockiert wird. Eingehender Traffic wird in Logs erfasst, wenn der Traffic durch eine Firewallregel für eingehenden Traffic zugelassen wird. Eingehender Traffic wird nicht in Logs erfasst, wenn eine Firewallregel für eingehenden Traffic den Traffic blockiert.

Flusslogs werden in bestimmten Intervallen für jede VM-Verbindung erfasst. Alle Stichprobenpakete, die für ein bestimmtes Intervall und eine bestimmte Verbindung (Aggregationsintervall) erfasst wurden, werden in einem einzigen Flusslogeintrag aggregiert. Der Logeintrag wird dann an Cloud Logging gesendet.

VPC-Flusslogs sind für jedes VPC-Subnetz aktiviert oder deaktiviert. Wenn Sie VPC-Flusslogs aktivieren, werden große Datenmengen generiert. Wir empfehlen, die Subnetze, mit denen Sie VPC-Flusslogs aktivieren, sorgfältig zu verwalten. Wir empfehlen beispielsweise, dass Sie Flusslogs für einen längeren Zeitraum für Subnetze aktivieren, die von Entwicklungsprojekten verwendet werden. Sie können VPC-Flusslogs direkt abfragen . Verwenden Sie dazu Cloud Logging oder die exportierte Senke. Wenn Sie wahrgenommene traffic-bedingte Probleme beheben, können Sie mithilfe von VPC-Flusslogs feststellen, ob der Traffic über den erwarteten Port eine VM verlässt oder betritt.

Benachrichtigungen

Durch Benachrichtigungen werden Sie rechtzeitig über Richtlinienverstöße informiert, die sich auf den Zugriff auf Ihre Google Cloud-Ressourcen auswirken können.

Benachrichtigungen in Echtzeit

Cloud Asset Inventory speichert einen fünfwöchigen Verlauf der Asset-Metadaten von Google Cloud. Ein Asset ist eine unterstützte Google Cloud-Ressource. Zu den unterstützten Ressourcen gehören IAM, Compute Engine mit zugehörigen Netzwerkfunktionen wie Firewallregeln und GKE-Namespaces sowie Rollen- und Clusterrollenbindungen. Alle vorherigen Ressourcen haben Zugriff auf Google Cloud-Ressourcen.

Wenn Sie Abweichungen von Ihren Ressourcenkonfigurationen überwachen möchten, z. B. Firewallregeln und Weiterleitungsregeln, können Sie Echtzeitbenachrichtigungen abonnieren. Wenn sich Ihre Ressourcenkonfigurationen ändern, wird durch Echtzeitbenachrichtigungen sofort eine Benachrichtigung über Pub/Sub gesendet. Durch Benachrichtigungen können Sie frühzeitig auf mögliche Probleme hingewiesen werden, bevor ein Supportanruf beendet wird.

Cloud-Audit-Logs und Cloud Run-Funktionen

Als Ergänzung zur Verwendung von Echtzeitbenachrichtigungen können Sie Cloud Logging überwachen und Benachrichtigungen über Aufrufe sensibler Ereignisse einrichten. Sie können beispielsweise eine Cloud Logging-Senke erstellen, die Aufrufe von SetIamPolicy auf Organisationsebene filtert. Die Senke sendet Logs an ein Pub/Sub-Thema, mit denen Sie die Cloud Run Functions-Funktion auslösen können.

Konnektivitätstests

Wenn Sie feststellen möchten, ob ein Zugriffsproblem Netzwerk- oder Berechtigungsbezogen ist, verwenden Sie das Network Intelligence Center-Tool Konnektivitätstests. Konnektivitätstests ist ein statisches Konfigurationsanalysator- und Diagnosetool, mit dem Sie die Konnektivität zwischen einem Quell- und einem Zielendpunkt prüfen können. Mit Konnektivitätstests können Sie die Ursache von netzwerkbezogenen Zugriffsproblemen ermitteln, die mit Ihrer Google Cloud-Netzwerkkonfiguration verknüpft sind.

Konnektivitätstests führen Tests mit Ihrem VPC-Netzwerk, VPC-Netzwerk-Peering und VPN-Tunneln zu Ihrem lokalen Netzwerk durch. Mit Konnektivitätstests kann zum Beispiel festgestellt werden, dass die Konnektivität durch eine Firewallregel blockiert wird. Weitere Informationen finden Sie unter Häufige Anwendungsfälle.

Richtlinien-Fehlerbehebung

Viele Aufgaben in Google Cloud erfordern eine IAM-Rolle und die zugehörigen Berechtigungen. Wir empfehlen, dass Sie prüfen, welche Berechtigungen in einer Rolle enthalten sind, und nach jeder Berechtigung suchen, die zum Ausführen einer Aufgabe erforderlich ist. Um beispielsweise Compute Engine-Images zum Erstellen einer Instanz zu verwenden, benötigt ein Nutzer die Rolle compute.imageUser, die neun Berechtigungen enthält. Daher muss der Nutzer eine Kombination aus Rollen und Berechtigungen mit allen neun Berechtigungen haben.

Die Richtlinien-Fehlerbehebung ist ein Google Cloud Console-Tool, mit dem Sie Fehler beheben können, wenn ein Nutzer oder Dienstkonto keine Berechtigung für den Zugriff auf eine Ressource hat. Zur Behebung von Zugriffsproblemen verwenden Sie den IAM-Teil des Tools zur Richtlinien-Fehlerbehebung.

Sie können beispielsweise prüfen, warum ein bestimmter Nutzer in einem Projekt Objekte in Buckets erstellen kann, während ein anderer Nutzer dies nicht kann. Mit der Richtlinien-Fehlerbehebung können Sie feststellen, über welche Berechtigungen der erste Nutzer verfügt, über die der zweite Nutzer nicht verfügt.

Die Richtlinien-Fehlerbehebung erfordert folgende Eingaben:

  • Hauptkonto (einzelner Nutzer, Dienstkonto oder Gruppen)
  • Berechtigung (beachten Sie, dass dies die zugrunde liegenden Berechtigungen sind, nicht die IAM-Rollen).
  • Ressource

IAM Recommender

Obwohl IAM Recommender ein Steuerelement zur Durchsetzung von Richtlinien ist, wie im vorherigen Abschnitt "Recommender" beschrieben, können Sie es auch als Tool zur Fehlerbehebung verwenden. Recommender führt einen täglichen Job aus, mit dem IAM-Zugriffslogdaten und die Berechtigungen der letzten 60 Tage analysiert werden. Mit Recommender können Sie prüfen, ob kürzlich eine Empfehlung genehmigt und angewendet wurde, die den Zugriff eines Nutzers auf eine zuvor zulässige Ressource beeinträchtigt haben könnte. In diesem Fall können Sie die entfernten Berechtigungen gewähren.

An den Kundenservice eskalieren

Bei der Behebung von Zugriffsproblemen ist es wichtig, einen guten internen Supportprozess und einen genau definierten Prozess für die Eskalation zur Cloud Customer Care zu haben. In diesem Abschnitt wird ein Beispiel für eine Supporteinrichtung beschrieben, über die Sie mit dem Kundenservice kommunizieren können, um Ihr Problem schnell zu beheben.

Wenn Sie ein Problem nicht mithilfe der in diesem Dokument beschriebenen Tools lösen können, hilft ein klar definierter Supportprozess dem Kunden bei der Fehlerbehebung. Wir empfehlen Ihnen einen systematischen Ansatz zur Fehlerbehebung, wie im Kapitel zur effektiven Fehlerbehebung im SRE-Buch (Site Reliability Engineering) von Google beschrieben.

Wir empfehlen, dass Ihr interner Supportprozess Folgendes ausführt:

  • Beschreiben Sie die zu befolgenden Schritte, falls ein Problem auftritt.
  • Erstellen Sie einen klar definierten Eskalationspfad.
  • Richten Sie einen Bereitschaftsprozess ein.
  • Erstellen Sie einen Reaktionsplan für Vorfälle.
  • Richten Sie ein Bug-Tracking- oder Helpdesk-System ein.
  • Ihr Support-Personal muss zur Kommunikation mit dem Kundendienst berechtigt sein und benannte Kontakte haben.
  • Kommunizieren Sie Support-Prozesse an interne Mitarbeiter, einschließlich der Kontaktaufnahme mit benannten Kontakten in Google Cloud.
  • Sie können regelmäßig Supportprobleme analysieren und anhand der gewonnenen Erkenntnisse immer wieder neue Optimierungen vornehmen.
  • Fügen Sie ein standardisiertes Aufarbeitungsformular bei.

Wenn Sie wegen der Behebung von Anmeldeproblemen an die Kundenbetreuung eskalieren müssen, halten Sie folgende Informationen bereit, um sie an die Kundenbetreuung weiterzuleiten:

  • Die Identität (E-Mail-Adresse des Nutzers oder Dienstkontos), die Zugriff anfordert.
    • Ob dieses Problem alle Identitäten oder nur einige betrifft.
    • Wenn nur einige Identitäten betroffen sind, geben Sie eine Beispielidentität an, bei der es funktioniert, und eine Beispielidentität, bei der der Fehler auftritt.
  • Ob die Identität vor Kurzem neu erstellt wurde.
  • Die Ressource, auf die der Nutzer zugreifen möchte (einschließlich Projekt-ID)
  • Die Anfrage oder Methode, die aufgerufen wird.
    • Geben Sie eine Kopie der Anfrage und der Antwort an.
  • Die Berechtigungen, die der Identität für diesen Zugriff gewährt wurden.
    • Geben Sie eine Kopie der IAM-Richtlinie an.
  • Die Quelle (Standort), von der die Identität versucht, auf Ressourcen zuzugreifen. Wenn sie beispielsweise versuchen, von einer Google Cloud-Ressource (z. B. einer Compute Engine-Instanz), der Google Cloud Console, der Google Cloud CLI, Cloud Shell oder einer externen Quelle wie lokal oder über das Internet aus auf sie zuzugreifen.
    • Wenn die Quelle aus einem anderen Projekt stammt, geben Sie die ID des Quellprojekts an.
  • Die Zeit (Zeitstempel) des Zeitpunkts, an dem der Fehler aufgetreten ist und ob das Problem immer noch besteht.
  • Der letzte Zeitpunkt, zu dem die Identität erfolgreich auf die Ressource zugegriffen hat (einschließlich Zeitstempel).
  • Alle Änderungen, die vor Beginn des Problems vorgenommen wurden (einschließlich Zeitstempel).
  • Alle Fehler, die in Cloud Logging aufgezeichnet werden Bevor Sie Daten für die Kundenbetreuung freigeben, müssen Sie sensible Daten wie Zugriffstoken, Anmeldedaten und Kreditkartennummern entfernen.

Nächste Schritte

Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.