Zugriffskontrolle

Dieses Thema enthält grundlegende Informationen über die Verwendung von Compartments und IAM-Policys zur Kontrolle des Zugriffs auf ein Cloud-Netzwerk.

Compartments und ein Cloud-Netzwerk

Wenn Sie eine Cloud-Ressource wie ein virtuelles Cloud-Network (VCN) oder eine Computing-Instanz erstellen, müssen Sie angeben, in welchem IAM-Compartment die Ressource enthalten ist. Ein Compartment ist eine Sammlung aus zusammengehörigen Ressourcen, auf die nur bestimmte Gruppen Zugriff haben, denen von einem Administrator die Berechtigung erteilt wurde. Der Administrator erstellt Compartments und entsprechende IAM-Policys, um zu steuern, welche Benutzer auf welche Compartments zugreifen können. Ziel ist es, sicherzustellen, dass jede Person nur auf die benötigten Ressourcen zugreifen kann.

Wenn ein Unternehmen Oracle Cloud Infrastructure ausprobiert, müssen nur einige Personen das VCN und seine Komponenten erstellen und verwalten, Instanzen im VCN erstellen und Blockspeicher-Volumes an diese Instanzen anhängen. Diese wenigen Personen benötigen Zugriff auf alle diese Ressourcen, damit sich diese Ressourcen in demselben Compartment befinden können.

In einer Unternehmensproduktionsumgebung mit einem VCN kann ein Unternehmen viele Compartments verwenden, um den Zugriff auf bestimmte Ressourcentypen einfacher zu steuern. Beispiel: Ein Administrator kann Compartment_A für ein VCN und andere Netzwerkkomponenten erstellen. Der Administrator könnte dann Compartment_B für alle Compute-Instanzen und Blockspeicher-Volumes erstellen, die von der HR-Organisation verwendet wird, und Compartment_C für alle Instanzen und Blockspeicher-Volumes, die die Marketingorganisation verwendet. Der Administrator würde dann IAM-Policys erstellen, mit denen Benutzern nur die erforderliche Zugriffsebene in jedem Compartment erteilt wird. Beispiel: Der HR-Instanzadministrator ist nicht berechtigt, das vorhandene Cloud-Netzwerk zu ändern. Sie haben also die vollen Berechtigungen für Compartment_B, aber begrenzten Zugriff auf Compartment_A (nur was zum Erstellen von Instanzen im Netzwerk erforderlich ist). Wenn sie versuchen, andere Ressourcen in Compartment_A zu verändern, wird die Anforderung abgelehnt.

Netzwerkressourcen wie VCNs, Subnetze, Routentabellen, Sicherheitslisten, Servicegateways, NAT-Gateways, VPN-Verbindungen und FastConnect-Verbindungen können von einem Compartment in ein anderes verschoben werden. Wenn eine Ressource in ein neues Compartment verschoben wird, werden inhärente Policys sofort angewendet.

Weitere Informationen zu Compartments und zur Kontrolle der Zugriffsrechte auf Cloud-Ressourcen erhalten Sie unter Best Practices zum Einrichten Ihres Mandanten und Überblick über Identity and Access Management.

IAM-Policys für Networking

Die einfachste Methode zum Erteilen des Zugriffs auf Networking ist die Policy, die unter Verwalten eines Cloud-Netzwerks durch Netzwerkadministratoren zulassen aufgeführt wird. Sie deckt das Cloud-Netzwerk und alle anderen Netzwerkkomponenten (Subnetze, Sicherheitslisten, Routing-Tabellen, Gateways usw.) ab. Weitere Informationen finden Sie unter Starten von Compute-Instanzen durch Benutzer zulassen.

Wenn Sie mit Policys neu sind, finden Sie weitere Informationen unter Identitätsdomains verwalten und Allgemeine Policys.

Referenzmaterial für das Schreiben detaillierter Policys für Networking finden Sie unter Details zu den Coreservices.

Einzelne Ressourcentypen

Sie können Policys schreiben, die sich auf einzelne Ressourcentypen konzentrieren (z.B. nur Sicherheitslisten) und nicht auf den umfassenderen Ressourcentyp virtual-network-family. Der Ressourcentyp instance-family enthält auch mehrere Berechtigungen für VNICs, die sich in einem Subnetz befinden, aber an eine Instanz angehängt sind. Weitere Informationen finden Sie unter Details für Kombinationen aus Verb + Ressourcentyp und Virtuelle Netzwerkkarten (VNICs).

Der Ressourcentyp local-peering-gateways ist in virtual-network-family enthalten und enthält zwei weitere zum lokalen VCN-Peering (innerhalb der Region) zugehörige Ressourcentypen:

local-peering-from
local-peering-to

Der Ressourcentyp local-peering-gateways deckt alle zu lokalen Peering-Gateways (LPGs) zugehörigen Berechtigungen ab. Die Ressourcentypen local-peering-from und local-peering-to dienen dazu, die Berechtigung zum Verbinden von zwei LPGs zu erteilen und eine Peering-Beziehung innerhalb einer einzelnen Region zu definieren. Weitere Informationen finden Sie unter Lokales Peering mit einem LPG (VCNs im selben Mandanten) oder Lokales Peering mit einem LPG (VCNs in verschiedenen Mandanten).

Außerdem ist ein Ressourcentyp mit dem Namen remote-peering-connections in virtual-network-family enthalten und enthält zwei andere zu Remote-VCN-Peering (regionsübergreifend) zugehörigen Ressourcentypen:

remote-peering-from
remote-peering-to

Der Ressourcentyp remote-peering-connections deckt alle zu Remote-Peering-Verbindungen (RPCs) zugehörigen Berechtigungen ab. Die Ressourcentypen remote-peering-from und remote-peering-to dienen dazu, die Berechtigung zum Verbinden von zwei RPCs zu erteilen und eine regionsübergreifende Peering-Beziehung zu definieren. Weitere Informationen finden Sie unter Remote-Peering mit einem Legacy-DRG und Remote-Peering mit einem upgegradeten DRG.

Nuancen verschiedener Verben

Sie können Policys schreiben, die den Zugriff einschränken, indem Sie ein anderes Policy-Verb (manage anstelle von use usw.) verwenden. In diesem Fall finden Sie nachfolgend einige Nuancen zu den Policy-Verben für Networking.

Beachten Sie, dass das Verb inspect nicht nur allgemeine Informationen zu den Komponenten des Cloud-Netzwerks zurückgibt (Beispiel: Name und OCID einer Sicherheitsliste oder einer Routentabelle). Es enthält außerdem den Inhalt der Komponente (Beispiel: die eigentlichen Regeln in der Sicherheitsliste, die Routen in der Routentabelle usw.).

Außerdem sind die folgenden Arten von Fähigkeiten nur mit dem Verb manage und nicht mit dem Verb use verfügbar:

internet-gateways aktualisieren (aktivieren/deaktivieren)
security-lists aktualisieren
route-tables aktualisieren
dhcp-options aktualisieren
Ein dynamisches Routinggateway (DRG) an ein virtuelles Cloud-Netzwerk (VCN) anhängen
Eine IPSec-Verbindung zwischen einem DRG und Customer Premises Equipment (CPE) erstellen
Peer-VCNs

Wichtig

Jedes VCN verfügt über verschiedene Komponenten, die sich direkt auf das Verhalten des Netzwerks auswirken (Routentabellen, Sicherheitslisten, DHCP-Optionen, Internetgateway usw.). Wenn Sie eine dieser Komponenten erstellen, legen Sie eine Beziehung zwischen dieser Komponente und dem VCN fest. Dies bedeutet, dass eine Policy Sie berechtigen muss, sowohl die Komponente zu erstellen als auch das VCN selbst zu verwalten. Die Möglichkeit, diese Komponente zu aktualisieren (um die Routingregeln, Sicherheitslistenregeln usw. zu ändern) erfordert jedoch nicht die Berechtigung zur Verwaltung des VCN selbst, obwohl sich die Änderung dieser Komponente direkt auf das Verhalten des Netzwerks auswirkt. Diese Abweichung bietet Ihnen Flexibilität, Benutzern die wenigsten Berechtigungen zu erteilen, und Sie müssen dem VCN keinen übermäßigen Zugriff gewähren, damit der Benutzer andere Komponenten des Netzwerks verwalten kann. Beachten Sie, dass wenn Sie jemandem die Möglichkeit geben, einen bestimmten Komponententyp zu aktualisieren, Sie dieser Person implizit vertrauen, das Verhalten des Netzwerks zu steuern.

Weitere Informationen zu Policy-Verben finden Sie unter Policy-Grundlagen.

Peering-Policys

Policys, die zum Verbinden eines DRG mit VCNs und DRGs in anderen Regionen und Mandanten verwendet werden, finden Sie unter IAM-Policys für Routing zwischen VCNs.