In diesem Dokument werden empfohlene Best Practices für die Verwendung des kontextsensitiven Zugriffs beschrieben, um Ihre Google Cloud Ressourcen effektiv zu schützen. Der kontextsensitive Zugriff ist ein Sicherheitsansatz, bei dem Sie den Zugriff von Nutzern basierend auf ihrer Authentifizierungsstärke, dem Gerätestatus, dem Netzwerkstandort, dem geografischen Standort oder anderen Attributen steuern. Dieser Ansatz geht über die Verwendung grundlegender Nutzeridentitäten für den Sicherheitszugriff hinaus und kann Ihnen helfen, ein Zero-Trust Sicherheitsmodell zu implementieren, um Ihren allgemeinen Sicherheitsstatus zu verbessern. Weitere Informationen zum Implementieren des kontextsensitiven Zugriffs für verschiedene Arten von Apps und Ressourcen finden Sie unter Apps und Ressourcen mit kontextsensitivem Zugriff schützen.
Um Ihre Apps und Google Cloud Ressourcen zu schützen, können Sie eine detaillierte Zugriffssteuerung definieren, die auf einer Vielzahl und Kombination von Kontextfaktoren basiert. Mit Access Context Manager können Sie Zugriffsrichtlinien definieren, die Zugriffsebenen und Dienstparameter enthalten.
Dieses Dokument richtet sich an alle Sicherheitsexperten, die für Identity and Access Management (IAM) und die Sicherheit von Google Cloud Ressourcen und Apps verantwortlich sind. In diesem Dokument wird davon ausgegangen, dass Sie bereits mit Access Context Manager, Google Cloud, und der IAM-Verwaltung vertraut sind.
Ansätze für den kontextsensitiven Zugriff
Wenn Sie den kontextsensitiven Zugriff in Ihrer Organisation einrichten, müssen Sie entscheiden, ob Sie die kontextsensitiven Zugriffssteuerungen auf Apps, Ressourcen oder beides anwenden möchten. Um diese Entscheidung zu treffen, ist es hilfreich, zwischen den folgenden verschiedenen Arten von Apps und Diensten zu unterscheiden:
- Administrative Apps: Mit diesen Apps können Nutzer Ressourcen wie VM-Instanzen, BigQuery Datasets oder Cloud Storage-Buckets verwalten oder mit ihnen interagieren.Google Cloud Beispiele für administrative Apps sind die Google Cloud Console, die Google Cloud CLI, Terraform und IAP Desktop.
- Branchenspezifische Apps: Dazu gehören Webanwendungen, die auf Google Cloud ausgeführt werden und SAML oder Identity-Aware Proxy (IAP) für die Authentifizierung und Autorisierung verwenden. Diese Apps werden manchmal auch als interne Apps bezeichnet. Beispiele für branchenspezifische Apps sind CRM-Systeme, Dashboards und andere benutzerdefinierte Apps.
- Google Workspace und andere Google-Dienste: Diese Dienste werden von Google bereitgestellt, sind aber nicht mit Google Cloud verknüpft Google Cloud.
Sie können branchenspezifische Apps weiter danach unterscheiden, wie sie die Authentifizierung und Autorisierung handhaben:
- SAML: Apps, die Google Workspace SAML für die Authentifizierung verwenden. SaaS-Apps fallen oft in diese Kategorie.
- IAP: Benutzerdefinierte Webanwendungen, die Sie hinter IAP bereitgestellt haben.
- OAuth: Benutzerdefinierte Web- oder Desktop-Apps, die OAuth 2.0 und einen oder mehrere Google Cloud OAuth-Bereiche verwenden.
Das folgende Flussdiagramm zeigt den am besten geeigneten Ansatz für den kontextsensitiven Zugriff für jede Art von App:
Das Diagramm zeigt die folgenden Arten von Apps:
Administrative Apps: Im Allgemeinen ist es wichtiger, die Google Cloud Ressourcen zu schützen, auf die die administrative App den Zugriff ermöglicht, als die App selbst. Sehen Sie sich die folgenden Szenarien an:
- Ein Nutzer kann auf keine der Ressourcen zugreifen. In diesem Szenario ist der Zugriff auf eine administrative App für den Nutzer wahrscheinlich nicht so wertvoll.
- Ein Nutzer hat Zugriff auf eine Ressource, kann aber nicht auf eine administrative App zugreifen. In diesem Szenario kann er möglicherweise eine andere administrative App finden, die nicht blockiert ist und ihm den Zugriff auf die Ressource ermöglicht.
Verwenden Sie daher für administrative Apps einen ressourcenorientierten Ansatz. Die effektivste Möglichkeit, die richtigen kontextsensitiven Zugriffssteuerungen auf Ressourcen anzuwenden, sind VPC-Dienstperimeter (Virtual Private Cloud) mit den entsprechenden Regeln für eingehenden Traffic. Sie können die VPC-Dienstperimeter mit Zugriffsbindungen ergänzen.
Branchenspezifische Apps, die OAuth verwenden: Bei diesen Apps ist es wichtig, den Zugriff auf die Apps selbst sowie auf die Ressourcen zu schützen, die von den Apps verwendet werden. Verwenden Sie Zugriffsbindungen, um die Apps mit kontextsensitivem Zugriff zu schützen.
Branchenspezifische Apps, die IAP verwenden: Obwohl IAP OAuth verwendet, können Sie keine Zugriffsbindungen verwenden, um Apps zu schützen, die IAP zur Authentifizierung von Nutzern verwenden. Schützen Sie diese Apps stattdessen mit IAM-Bedingungen.
Branchenspezifische Apps, die SAML verwenden: Ähnlich wie bei branchenspezifischen Apps, die OAuth verwenden, ist es wichtig, den Zugriff auf die Apps selbst sowie auf die Ressourcen zu schützen, die von den Apps verwendet werden. Verwenden Sie den kontextsensitiven Zugriff von Google Workspace, um diese Apps zu schützen.
Google Workspace und andere Google-Dienste: Bei diesen Apps ist es wichtig, den Zugriff auf die Apps selbst sowie auf die Ressourcen zu schützen, die von den Apps verwendet werden. Verwenden Sie den kontextsensitiven Zugriff von Google Workspace, um diese Apps zu schützen.
Zugriffsebenen verwalten
In den folgenden Abschnitten werden die empfohlenen Best Practices für die Verwaltung von Zugriffsebenen beschrieben.
Wiederverwendbare Zugriffsebenen erstellen
Zugriffsebenen sind eine globale Ressource und sollen für alle Ressourcen in Ihrer Google Cloud Organisation verwendet werden. Daher ist es am besten, die Gesamtzahl der Zugriffsebenen zu begrenzen und sie aussagekräftig und für mehrere Ressourcen anwendbar zu machen. Beachten Sie Folgendes:
- Vermeiden Sie es, die Namen bestimmter Ressourcen oder Apps in den Namen einer Zugriffsebene einzubetten.
- Vermeiden Sie es, ressourcen- oder app-spezifische Anforderungen in einer Zugriffsebene zu codieren.
- Verwenden Sie Namen, die einen bestimmten Nutzer- oder Gerätestatus angeben, z. B.
Fully Trusted Device.
Zusammengesetzte Zugriffsebenen verwenden
Um den Wartungsaufwand zu reduzieren und die Konsistenz zu gewährleisten, wenn sich die Subnetzwerke oder Regionen ändern, wiederholen Sie die gleichen Anforderungen nicht in mehreren Zugriffsebenen. Lassen Sie stattdessen die Zugriffsebenen voneinander abhängen.
Listen Sie beispielsweise nicht dieselben vertrauenswürdigen
Regionen
oder IP-Subnetzwerke in mehreren Zugriffsebenen auf, sondern erstellen Sie stattdessen eine zusätzliche
Zugriffsebene mit dem Namen Trusted location. Diese Ebene Trusted location kann als Abhängigkeit für die anderen Zugriffsebenen dienen.
Nutzer mit Notfallzugriff in Zugriffsebenen ausnehmen
Um eine versehentliche Sperrung zu vermeiden, sollten Sie mindestens einen Nutzer mit Notfallzugriff von allen Zugriffsebenen ausschließen. Damit die Ausnahme für alle Apps und Ressourcen gilt, auf die Sie die Zugriffsebene anwenden, konfigurieren Sie die Ausnahme in der Zugriffsebene selbst:
- Fügen Sie eine Bedingung hinzu, die Ihre regulären Anforderungen definiert.
- Fügen Sie eine weitere Bedingung mit einer
membersAnforderung hinzu, in der ein oder mehrere Nutzer mit Notfallzugriff aufgeführt sind. - Legen Sie die Kombinationsfunktion auf eine
OR-Bedingung fest, damit Nutzer nur eine der beiden Bedingungen erfüllen müssen.
Die folgende Zugriffsebene beschränkt beispielsweise den Zugriff auf drei Regionen, aber der Nutzer emergencyaccess@example.net ist von dieser Anforderung ausgenommen:
{
"name": "accessPolicies/…",
"title": "Example access level",
"basic": {
"conditions": [
{
"members": [
"user:emergencyaccess@example.net"
]
},
{
"regions": [
"DE",
"AU",
"SG"
]
}
],
"combiningFunction": "OR"
}
}
Abhilfemeldung konfigurieren
Nutzer in Ihrer Organisation wissen möglicherweise nicht, dass ihr Standort, ihr Gerät und andere Faktoren sich darauf auswirken können, ob sie auf bestimmte Apps zugreifen dürfen oder nicht. Konfigurieren Sie eine benutzerdefinierte Abhilfemeldung die Nutzern die Schritte zum Wiederherstellen des Zugriffs zeigt, um sie auf dem Laufenden zu halten und Supportanfragen zu reduzieren.
Zugriffsbindungen verwalten
Mit Zugriffsbindungen können Sie den kontextsensitiven Zugriff für OAuth-Apps konfigurieren, die einen oder mehrere Google Cloud Bereiche verwenden. Zugriffsbindungen sind auch eine effektive Möglichkeit, den kontextsensitiven Zugriff für branchenspezifische Apps zu erzwingen.
In den folgenden Abschnitten werden empfohlene Best Practices für die Verwendung von Zugriffsbindungen beschrieben.
Eine einzelne Zugriffsbindung mit bereichsspezifischen Einstellungen verwenden
Bei der Verwendung von Zugriffsbindungen müssen Sie die folgenden Einschränkungen beachten:
- Jede Cloud Identity-Gruppe kann maximal eine Zugriffsbindung haben.
- Wenn mehr als eine Zugriffsbindung auf einen Nutzer angewendet wird, hat die weniger restriktive Zugriffsbindung Vorrang.
Um diese beiden Einschränkungen zu berücksichtigen, verwenden Sie eine einzelne Zugriffsbindung, die für alle Nutzer gilt:
- Erstellen Sie eine Gruppe, die automatisch alle Nutzer enthält Ihres Cloud Identity- oder Google Workspace-Kontos.
- Erstellen oder verwenden Sie eine Zugriffsbindung, die der Gruppe eine Standardzugriffsebene zuweist. Die Standardzugriffsebene sollte für die meisten Nutzer, Geräte und Apps geeignet sein.
- Verwenden Sie bei Bedarf
bereichsspezifische Zugriffseinstellungen (
scopedAccessSettings) um ausgewählten Apps niedrigere Zugriffsebenen zuzuweisen.
Strenge Standardzugriffsebene verwenden
Wenn in einer Zugriffsbindung sowohl eine bereichsspezifische Zugriffseinstellung als auch eine Standardzugriffsebene angegeben sind, werden die beiden Zugriffsebenen mit der Semantik OR kombiniert.
Dieses Verhalten hat folgende Auswirkungen:
- Ein Nutzer muss nur eine der Zugriffsebenen erfüllen, um auf die OAuth-App zugreifen zu können.
- Wenn Sie eine bereichsspezifische Zugriffseinstellung für eine OAuth-App hinzufügen, können Sie die effektiven Zugriffsanforderungen senken.
- Eine bereichsspezifische Zugriffseinstellung hat keine Auswirkungen, wenn sie eine Zugriffsebene verwendet, die strenger ist als die Standardzugriffsebene der Zugriffsbindung.
Wenn Sie eine Standardzugriffsebene für eine Zugriffsbindung auswählen, empfehlen wir Folgendes:
- Verwenden Sie eine strenge Zugriffsebene als Standardzugriffsebene.
- Wenden Sie mit bereichsspezifischen Zugriffseinstellungen niedrigere Zugriffsebenen auf einzelne OAuth-Apps an.
Sie können der Standardzugriffsebene einige oder alle der folgenden Einschränkungen hinzufügen:
- Browser- und Geräteeinschränkungen: Legen Sie fest, dass Nutzer über einen verwalteten Chrome-Browser und ein vom Administrator genehmigtes Gerät auf Apps zugreifen müssen.
- Geografische Einschränkungen: Wenn Ihre Organisation ausschließlich in bestimmten Regionen tätig ist, verwenden Sie regionale Einschränkungen um nur diese Regionen in die Zulassungsliste aufzunehmen. Andernfalls können Sie regionale Einschränkungen verwenden, um den Zugriff auf Regionen zu beschränken, gegen die Sanktionen verhängt wurden oder die aus anderen Gründen nicht relevant sind.
- Einschränkungen für IP-Netzwerke: Wenn Nutzer in Ihrer Organisation ausschließlich über bestimmte Netzwerke zugreifen oder wenn Ihre Organisation einen gemeinsamen Ausgangsproxy verwendet, können Sie Einschränkungen für IP-Netzwerke einbeziehen.Google Cloud
Verwenden Sie keine Zugriffsebenen, die eine zertifikatbasierte Authentifizierung erfordern, als Standardzugriffsebene. Die zertifikatbasierte Authentifizierung eignet sich am besten für Regeln für eingehenden Traffic für VPC-Dienstperimeter.
Ausnahmen nach App verwalten
Wenn Sie Ausnahmen von der Standardzugriffsebene verwalten möchten, fügen Sie Ausnahmen für einzelne Apps anstelle von Ausnahmen für Nutzer oder Gruppen hinzu.
Eine strenge Standardzugriffsebene ist möglicherweise für die meisten Apps geeignet, aber nicht für alle:
- Einige Apps sind möglicherweise weniger vertraulich und Sie müssen sie für Nutzer zugänglich machen, die die Standardzugriffsebene nicht erfüllen. Beispiele hierfür sind Apps, die für Partner, Gäste oder Alumni zugänglich sein müssen.
- Einige Apps sind möglicherweise technisch nicht mit einer der Einschränkungen kompatibel, die von der Standardzugriffsebene erzwungen werden.
Verwenden Sie bereichsspezifische Zugriffseinstellungen, um einzelne Apps von der Standardzugriffsebene auszunehmen. Fügen Sie für jede betroffene App eine bereichsspezifische Einstellung hinzu und weisen Sie eine Zugriffsebene zu, die für die einzelne App besser geeignet ist.
Erstellen Sie keine zusätzlichen Zugriffsbindungen, um Ausnahmen nach Nutzer oder Gruppe zu verwalten. Zusätzliche Zugriffsbindungen können die folgenden Probleme verursachen:
- Sie erstellen möglicherweise versehentlich überlappende Zugriffsbindungen.
- Es kann schwierig sein, zu bestimmen, welche Anforderungen für den kontextsensitiven Zugriff für einzelne Apps effektiv erzwungen werden.
Überlappende Zugriffsbindungen vermeiden
Zugriffsbindungen sind mit Gruppen verknüpft. Wenn ein Nutzer Mitglied mehrerer Gruppen ist, können mehrere Zugriffsbindungen auf ihn angewendet werden. In diesem Fall werden die Anforderungen für den kontextsensitiven Zugriff dieser Zugriffsbindungen mit der Semantik OR kombiniert.
Dieses Verhalten kann unbeabsichtigte Auswirkungen haben. Wenn Nutzer beispielsweise zusätzlichen Gruppen beitreten dürfen, kann der Schutz bestimmter Apps untergraben werden.
Um solche Situationen zu vermeiden, empfehlen wir, überlappende Zugriffsbindungen zu vermeiden:
- Minimieren Sie die Anzahl der Zugriffsbindungen, idealerweise auf eine.
- Wenn Sie mehrere Zugriffsbindungen benötigen, weisen Sie sie Gruppen zu, die sich gegenseitig ausschließen.
Gruppen vor unbefugten Änderungen schützen
Standardmäßig können Cloud Identity-Gruppenmitglieder eine Gruppe verlassen. Dieses Verhalten ist für Zugriffsgruppen, aber problematisch für Gruppen mit zugehörigen Zugriffsbindungen. Wenn ein Nutzer eine Gruppe mit einer zugehörigen Zugriffsbindung verlässt, unterliegt er nicht mehr den Anforderungen für den kontextsensitiven Zugriff, die durch die Zugriffsbindungen auferlegt werden. Nutzer können also Anforderungen für den kontextsensitiven Zugriff umgehen, indem sie eine Gruppe verlassen.
Verwenden Sie immer Erzwingungsgruppen und lassen Sie nicht zu, dass Nutzer eine Erzwingungsgruppe verlassen, wenn Sie Zugriffs bindungen konfigurieren. Alternativ können Sie eine Gruppe erstellen, die automatisch alle Nutzer Ihres Cloud Identity- oder Google Workspace-Kontos enthält.
Keinen Zugriff für externe Nutzer zulassen, wenn Sie Zugriffsbindungen verwenden
Zugriffsbindungen wirken sich nur auf Nutzer des Cloud Identity- oder Google Workspace-Kontos aus, zu dem Ihre Google Cloud Organisation gehört. Diese Nutzer unterliegen weiterhin den Zugriffsbindungen in Ihrer Google Cloud Organisation, wenn sie versuchen, auf Ressourcen in anderen Google Cloud Organisationen zuzugreifen. Diese Anwendung von Zugriffsbindungen auf Nutzer unterscheidet sich vom Verhalten in anderen Kontexten mit Cloud Identity.
Wenn Sie Nutzern aus externen Cloud Identity- oder Google Workspace-Konten den Zugriff auf Ressourcen in Ihren Google Cloud Organisationen erlauben, haben Ihre Zugriffsbindungen keine Auswirkungen auf diese Nutzer.
Damit Ihre Zugriffsbindungen effektiv sind, gewähren Sie externen Nutzern keinen Zugriff auf Apps oder Ressourcen in Ihrer Google Cloud Organisation. Fügen Sie außerdem keine externen Nutzer zu Gruppen in Ihrem Cloud Identity- oder Google Workspace-Konto hinzu.
Separate Zugriffsbindungen für die Steuerung der Sitzungslänge verwenden
Neben der kontextsensitiven Zugriffssteuerung können Sie auch Zugriffsbindungen verwenden, um die Länge von Browsersitzungen und OAuth-Tokens zu verwalten.
Wenn Sie Zugriffsbindungen verwenden, um den kontextsensitiven Zugriff zu steuern, sollten Sie überlappende Zugriffsbindungen vermeiden.
Wenn Sie Zugriffsbindungen verwenden, um die Sitzungslänge zu steuern, erstellen Sie keine überlappenden Zugriffsbindungen. Wenn mehr als eine solche Zugriffsbindung auf einen Nutzer angewendet wird, wird nur die zuletzt aktualisierte Zugriffsbindung wirksam, was zu unbeabsichtigten Ergebnissen führen kann.
Um solche unbeabsichtigten Ergebnisse zu vermeiden, verwenden Sie eine separate Zugriffsbindung, um die Sitzungslänge zu steuern.
Nutzern nicht erlauben, als Dienstkonto zu fungieren
Zugriffsbindungen gelten für Cloud Identity- und Google Workspace-Nutzer, haben aber keine Auswirkungen auf Dienstkonten. Wenn Sie Nutzern erlauben, sich zu authentifizieren und als Dienstkonto zu fungieren, können sie möglicherweise Ihre kontextsensitiven Zugriffssteuerungen untergraben.
Es gibt weitere Risiken, wenn Nutzer als Dienstkonto fungieren können. Wenn Sie Nutzern erlauben möchten, ihre Berechtigungen vorübergehend zu erhöhen, empfehlen wir die Verwendung von Privileged Access Manager. Verwenden Sie die Identitätsübernahme von Dienstkonten nur für Entwicklungszwecke.
Weitere Informationen zum Sichern von Dienstkonten und Dienstkontoschlüsseln finden Sie unter Best Practices für die Verwendung von Dienstkonten und Best Practices für die Verwaltung von Dienstkontoschlüsseln.
Regeln für eingehenden Traffic für VPC-Dienstperimeter
Mit Regeln für eingehenden Traffic können Sie den kontextsensitiven Zugriff von außerhalb des Dienstperimeters auf Ressourcen innerhalb des Perimeters gewähren. VPC-Dienstperimeter und Regeln für eingehenden Traffic schützen Google Cloud Ressourcen, nicht einzelne Apps. Ein Dienstperimeter mit Regeln für eingehenden Traffic ist daher ideal, um den kontextsensitiven Zugriff für administrative Tools wie die Console und die gcloud CLI zu erzwingen. Google Cloud
Weitere Informationen und Best Practices zu VPC-Dienstperimetern finden Sie unter Best Practices zum Aktivieren von VPC Service Controls.
In den folgenden Abschnitten werden empfohlene Best Practices für die Verwendung von Regeln für eingehenden Traffic beschrieben, um den kontextsensitiven Zugriff zu erzwingen.
IAP-TCP-Weiterleitung als eingeschränkten Dienst einbeziehen
Es kann riskant sein, Nutzern zu erlauben, sich über SSH oder RDP mit VM-Instanzen in Ihrem Dienstperimeter zu verbinden. Die Gründe dafür sind:
- Ihre Regeln für eingehenden Traffic gelten nicht für die Verbindungen, da die Verwendung von SSH und RDP keinen Zugriff auf Google APIs beinhaltet.
- Nachdem Nutzer eine SSH- oder RDP-Sitzung eingerichtet haben, wird jeder API-Zugriff, der innerhalb dieser Sitzung initiiert wird, als Zugriff innerhalb des Dienstperimeters betrachtet. Daher gelten Ihre Regeln für eingehenden Traffic nicht für API-Zugriffe, die innerhalb dieser Sitzung initiiert werden.
Um diese Risiken zu minimieren, erlauben Sie den SSH- und RDP-Zugriff auf VMs nur über die IAP-TCP-Weiterleitung:
- Nehmen Sie den
iaptunnel.googleapis.comDienst als eingeschränkten Dienst auf. - Konfigurieren Sie Firewallregeln die den Zugriff auf SSH- und RDP-Ports über die IAP-TCP Weiterleitung einschränken.
Verwenden Sie die IAP-TCP-Weiterleitung, um sicherzustellen, dass die Konfiguration der Regeln für eingehenden Traffic Ihres VPC-Dienstperimeters auf jeden SSH- und RDP-Zugriffsversuch angewendet wird.
Zertifikatbasierten Zugriff für vertrauliche Dienstperimeter verwenden
Standardmäßig sind Google-Zugriffstokens und Aktualisierungstokens nicht an ein Gerät gebunden und können anfällig für Diebstahl oder Replay-Angriffe sein. Um diese Risiken zu minimieren, können Sie den zertifikatbasierten Zugriff (Certificate-Based Access, CBA), der den Zugriff auf Geräte beschränkt, die ein vertrauenswürdiges X.509-Zertifikat besitzen.
CBA trägt zur Erhöhung der Sicherheit bei, dieser Ansatz erfordert jedoch auch zusätzliche Infrastruktur:
- Das Gerät eines Nutzers muss ein X.509-Zertifikat haben, das von einer internen Zertifizierungsstelle ausgestellt wurde.
- Der mit dem Zertifikat verknüpfte Schlüssel muss so gespeichert werden, dass ein unbefugter Export verhindert wird.
- Client-Apps müssen die gegenseitige TLS-Authentifizierung (Mutual TLS, mTLS) verwenden, um eine Verbindung zu Google Cloud APIs herzustellen.
Verwenden Sie CBA, um den Zugriff auf Ihre vertraulichsten VPC-Dienstperimeter zu schützen. Mit diesem Ansatz können Sie die Sicherheitsstärke mit minimalen Infrastrukturanforderungen und Gesamtauswirkungen in Einklang bringen.
Beitragende
Autor: Johannes Passing | Cloud Solutions Architect
Weiterer Beitragender: Ido Flatow | Cloud Solutions Architect