In diesem Dokument werden empfohlene Best Practices für die Verwendung des kontextbezogenen Zugriffs beschrieben, mit denen Sie Ihre Google Cloud -Ressourcen effektiv schützen können. Der kontextsensitiven Zugriff ist ein Sicherheitsansatz, bei dem Sie den Zugriff von Nutzern basierend auf der Stärke der Authentifizierung, dem Sicherheitsstatus des Geräts, 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 kontextsensitiven Zugriff schützen.
Um Ihre Apps und Google Cloud Ressourcen zu schützen, können Sie eine detaillierte Zugriffssteuerung definieren, die auf einer Vielzahl von Kontextfaktoren und Kombinationen 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 Cloudund 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 Steuerelemente für den kontextsensitiven Zugriff 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:
- Administrator-Apps: Mit diesen Apps können NutzerGoogle Cloud -Ressourcen wie VM-Instanzen, BigQuery-Datasets oder Cloud Storage-Buckets verwalten oder mit ihnen interagieren. Beispiele für administrative Apps sind die Google Cloud Console, die Google Cloud CLI, Terraform und IAP Desktop.
- Geschäftsanwendungen: Dazu gehören Web-Apps, die aufGoogle 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, stehen aber nicht im Zusammenhang mit Google Cloud.
Sie können Line-of-Business-Apps weiter danach unterscheiden, wie sie die Authentifizierung und Autorisierung handhaben:
- SAML: Apps, die Google Workspace-SAML zur Authentifizierung verwenden. SaaS-Apps fallen oft in diese Kategorie.
- IAP: Benutzerdefinierte Web-Apps, die Sie hinter IAP bereitgestellt haben.
- OAuth: Benutzerdefinierte Web- oder Desktop-Apps, die OAuth 2.0 verwenden und einen oder mehrere Google Cloud OAuth-Bereiche nutzen.
Das folgende Flussdiagramm zeigt den jeweils am besten geeigneten kontextbezogenen Zugriff für die einzelnen App-Typen:
Das Diagramm zeigt die folgenden Arten von Apps:
Administrative Apps: Im Allgemeinen ist es wichtiger, dieGoogle 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 Fall ist der Zugriff auf eine administrative App für den Nutzer wahrscheinlich nicht so wichtig.
- Ein Nutzer hat Zugriff auf eine Ressource, kann aber nicht auf eine Verwaltungs-App zugreifen. In diesem Fall kann er möglicherweise eine andere Verwaltungs-App finden, die nicht blockiert ist und mit der er auf die Ressource zugreifen kann.
Verwenden Sie daher für administrative Apps einen ressourcenorientierten Ansatz. Um die richtigen kontextbezogenen Zugriffssteuerungen auf Ressourcen anzuwenden, verwenden Sie VPC-Dienstperimeter (Virtual Private Cloud) mit den entsprechenden Ingress-Regeln. Sie können die VPC-Dienstperimeter mit Zugriffsberechtigungen ergänzen.
Geschäftsanwendungen, 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. Um die Apps mit kontextsensitivem Zugriff zu schützen, verwenden Sie Zugriffsberechtigungen.
Geschäftsanwendungen, die IAP verwenden: Obwohl IAP OAuth verwendet, können Sie Zugriffsbindungen nicht verwenden, um Anwendungen zu schützen, die IAP zur Authentifizierung von Nutzern verwenden. Schützen Sie diese Apps stattdessen mit IAM-Bedingungen.
Geschäftsanwendungen, die SAML verwenden: Ähnlich wie bei Geschäftsanwendungen, 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. Um diese Apps zu schützen, verwenden Sie den kontextsensitiven Zugriff von Google Workspace.
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. Um diese Apps zu schützen, verwenden Sie den kontextsensitiven Zugriff für Google Workspace.
Zugriffsebenen verwalten
In den folgenden Abschnitten werden die empfohlenen Vorgehensweisen für die Verwaltung von Zugriffsebenen beschrieben.
Wiederverwendbare Zugriffsebenen erstellen
Zugriffsebenen sind eine globale Ressource und sollen für Ressourcen in Ihrer Google Cloud Organisation verwendet werden. Daher ist es am besten, die Gesamtzahl der Zugriffsebenen zu begrenzen und sie aussagekräftig und auf mehrere Ressourcen anwendbar zu machen. Berücksichtige 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 eine bestimmte Nutzer- oder Gerätekonfiguration bestätigen, z. B.
Fully Trusted Device.
Zusammengesetzte Zugriffsebenen verwenden
Um den Wartungsaufwand zu verringern und die Konsistenz bei Änderungen an den Subnetzen oder Regionen zu gewährleisten, sollten Sie dieselben Anforderungen nicht in mehreren Zugriffsebenen wiederholen. Lassen Sie stattdessen 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 Trusted location-Ebene kann als Abhängigkeit für die anderen Zugriffsebenen dienen.
Notfallzugriffsnutzer in Zugriffsebenen ausnehmen
Um ein versehentliches Aussperren zu verhindern, 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
members-Anforderung hinzu, in der mindestens einer Ihrer Nutzer mit Notfallzugriff aufgeführt ist. - 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 sind sich möglicherweise nicht bewusst, dass ihr Standort, ihr Gerät und andere Faktoren sich darauf auswirken können, ob sie auf bestimmte Apps zugreifen dürfen oder nicht. Damit Nutzer informiert sind und weniger Supportanfragen eingehen, sollten Sie eine benutzerdefinierte Abhilfemeldung konfigurieren, in der die Schritte beschrieben werden, die Nutzer ausführen müssen, um wieder Zugriff zu erhalten.
Zugriffsbindungen verwalten
Mit Zugriffsberechtigungen können Sie den kontextsensitiven Zugriff für OAuth-Apps konfigurieren, die einen oder mehrere Google Cloud Bereiche verwenden. Zugriffsbindungen sind auch eine effektive Methode, um den kontextsensitiven Zugriff für Line-of-Business-Apps zu erzwingen.
In den folgenden Abschnitten werden empfohlene Vorgehensweisen für die Verwendung von Zugriffsbindungen beschrieben.
Einzelne Zugriffsbindung mit eingeschränkten Einstellungen verwenden
Wenn Sie Zugriffsbindungen verwenden, müssen Sie die folgenden Einschränkungen beachten:
- Jede Cloud Identity-Gruppe kann maximal eine Zugriffsbindung haben.
- Wenn für einen Nutzer mehrere Zugriffsbindungen gelten, hat die weniger restriktive Zugriffsbindung Vorrang.
Um diesen beiden Einschränkungen gerecht zu werden, verwenden Sie eine einzelne Zugriffsbindung, die für alle Ihre Nutzer gilt:
- Erstellen Sie eine Gruppe, die automatisch alle Nutzer Ihres Cloud Identity- oder Google Workspace-Kontos enthält.
- Erstellen Sie eine Zugriffsbindung, die eine Standardzugriffsebene mit der Gruppe verknüpft, oder verwenden Sie eine solche. Die Standardzugriffsebene sollte für die meisten Nutzer, Geräte und Apps geeignet sein.
- Verwenden Sie bei Bedarf Einstellungen für eingeschränkten Zugriff (
scopedAccessSettings), um ausgewählten Apps niedrigere Zugriffsebenen zuzuweisen.
Strenge Standardzugriffsebene verwenden
Wenn in einer Zugriffsbindung sowohl eine Einstellung für den eingeschränkten Zugriff als auch eine Standardzugriffsebene angegeben sind, werden die beiden Zugriffsebenen mit der Semantik von 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 Einstellung für den eingeschränkten Zugriff für eine OAuth-App hinzufügen, können Sie die effektiven Zugriffsanforderungen herabstufen.
- Eine Einstellung für eingeschränkten Zugriff 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.
- Mit Einstellungen für eingeschränkten Zugriff können Sie einzelnen OAuth-Apps niedrigere Zugriffsebenen zuweisen.
Sie können dem Standardzugriff einige oder alle der folgenden Einschränkungen hinzufügen:
- Browser- und Gerätebeschränkungen: Sie können festlegen, dass Ihre Nutzer auf Apps nur über einen verwalteten Chrome-Browser und ein vom Administrator genehmigtes Gerät zugreifen dürfen.
- Geografische Einschränkungen: Wenn Ihre Organisation ausschließlich in bestimmten Regionen tätig ist, verwenden Sie Regionseinschränkungen, um nur diese Regionen in die Zulassungsliste aufzunehmen. Andernfalls können Sie den Zugriff mithilfe von Regionsbeschränkungen auf geografische Einheiten 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 aufGoogle Cloud zugreifen oder Ihre Organisation einen gemeinsamen Egress-Proxy verwendet, können Sie Einschränkungen für IP-Netzwerke einbeziehen.
Verwenden Sie keine Zugriffsebenen, für die eine zertifikatbasierte Authentifizierung erforderlich ist, 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, aber nicht für alle Ihre Apps geeignet:
- Einige Apps sind möglicherweise weniger sensibel und Sie müssen sie Nutzern zugänglich machen, die die Standardzugriffsebene nicht erfüllen. Beispiele hierfür sind Apps, auf die Partner, Gäste oder Alumni zugreifen müssen.
- Einige Apps sind möglicherweise technisch nicht mit einer der Einschränkungen kompatibel, die durch die Standardzugriffsebene erzwungen werden.
Wenn Sie einzelne Apps von der Standardzugriffsebene ausnehmen möchten, verwenden Sie Einstellungen für den eingeschränkten Zugriff. Fügen Sie für jede betroffene App eine Einstellung mit eingeschränktem Umfang hinzu und weisen Sie ihr eine Zugriffsebene zu, die für die jeweilige 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:
- Möglicherweise erstellen Sie versehentlich sich überschneidende Zugriffsbindungen.
- Es kann schwierig werden, festzustellen, welche Anforderungen für den kontextsensitiven Zugriff für einzelne Apps effektiv durchgesetzt werden.
Überlappende Zugriffsberechtigungen 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 kontextbezogenen Zugriff dieser Zugriffsberechtigungen mithilfe der OR-Semantik kombiniert.
Dieses Verhalten kann zu unbeabsichtigten Auswirkungen führen. Wenn Nutzer beispielsweise weiteren Gruppen beitreten dürfen, kann der Schutz bestimmter Apps untergraben werden.
Um solche Situationen zu vermeiden, empfehlen wir, sich nicht überschneidende Zugriffsberechtigungen zu verwenden:
- Minimieren Sie die Anzahl der Zugriffsbindungen, idealerweise auf eine.
- Wenn Sie mehrere Zugriffsbindungen benötigen, weisen Sie sie sich gegenseitig ausschließenden Gruppen zu.
Gruppen vor unbefugten Änderungen schützen
Standardmäßig können Gruppenmitglieder in Cloud Identity eine Gruppe verlassen. Dieses Verhalten ist für Zugriffsgruppen angemessen, aber problematisch für Gruppen mit zugehörigen Zugriffsbinding. 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. Daher können Nutzer die Anforderungen für den kontextsensitiven Zugriff umgehen, indem sie eine Gruppe verlassen.
Verwenden Sie immer Erzwingungsgruppen und erlauben Sie Nutzern nicht, eine Erzwingungsgruppe zu verlassen, wenn Sie Zugriffsberechtigungen konfigurieren. Alternativ können Sie eine Gruppe erstellen, die automatisch alle Nutzer Ihres Cloud Identity- oder Google Workspace-Kontos enthält.
Externen Nutzerzugriff nicht zulassen, wenn Sie Zugriffsberechtigungen 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 Zugriffsberechtigungen in Ihrer Google Cloud Organisation, wenn sie versuchen, auf Ressourcen in anderen Google Cloud Organisationen zuzugreifen. Diese Anwendung von Zugriffsberechtigungen auf Nutzer unterscheidet sich vom Verhalten in anderen Kontexten mit Cloud Identity.
Wenn Sie Nutzern mit 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 wirksam sind, sollten Sie externen Nutzern keinen Zugriff auf Apps oder Ressourcen in Ihrer Google Cloud -Organisation gewähren. Fügen Sie außerdem keine externen Nutzer Gruppen in Ihrem Cloud Identity- oder Google Workspace-Konto hinzu.
Separate Zugriffsbindungen für die Steuerung der Sitzungslänge verwenden
Zusätzlich zur 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 überschneidende Zugriffsbindungen vermeiden.
Wenn Sie Zugriffsbindungen verwenden, um die Sitzungslänge zu steuern, sollten Sie keine sich überschneidenden Zugriffsbindungen erstellen. Wenn für einen Nutzer mehrere solcher Zugriffsbindungen gelten, 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
Zugriffsberechtigungen gelten für Cloud Identity- und Google Workspace-Nutzer, haben aber keine Auswirkungen auf Dienstkonten. Wenn Sie Nutzern erlauben, sich als Dienstkonto zu authentifizieren und als Dienstkonto zu agieren, können sie möglicherweise Ihre kontextbezogenen Zugriffssteuerungen umgehen.
Es gibt auch andere Risiken, wenn Nutzer als Dienstkonto agieren können. Wenn Sie Nutzern die Möglichkeit geben möchten, ihre Berechtigungen vorübergehend zu erweitern, empfehlen wir die Verwendung von Privileged Access Manager. Verwenden Sie die Identitätsübernahme des Dienstkontos 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 Ingress-Regeln ist daher ideal, um kontextbezogenen Zugriff für Verwaltungstools wie die Google Cloud Console und die gcloud CLI zu erzwingen.
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 Vorgehensweisen für die Verwendung von Ingress-Regeln zur Erzwingung des kontextbezogenen Zugriffs beschrieben.
IAP-TCP-Weiterleitung als eingeschränkten Dienst einschließen
Es kann riskant sein, Nutzern die Verbindung zu VM-Instanzen in Ihrem Dienstperimeter über SSH oder RDP zu erlauben. Das hat folgende Gründe:
- Ihre Eingangsregeln gelten nicht für die Verbindungen, da für die Verwendung von SSH und RDP kein Zugriff auf Google-APIs erforderlich ist.
- 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, sollten Sie den SSH- und RDP-Zugriff auf VMs nur über die IAP-TCP-Weiterleitung zulassen:
- Fügen Sie den Dienst
iaptunnel.googleapis.comals eingeschränkten Dienst hinzu. - 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 sensible 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 verwenden. Dadurch wird der Zugriff auf Geräte beschränkt, die ein vertrauenswürdiges X.509-Zertifikat haben.
Mit der CBA können Sie die Sicherheit erhöhen. Dieser Ansatz erfordert jedoch 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 (mTLS) verwenden, um eine Verbindung zuGoogle Cloud -APIs herzustellen.
Verwenden Sie die clientzertifikatbasierte Authentifizierung, 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