Netzwerksicherheitsgruppen

• Netzwerksicherheitsgruppen (NSGs) fungieren als virtuelle Firewall für Ihre Compute-Instanzen und andere Arten von Ressourcen. Eine NSG besteht aus einem Set von Ingress- und Egress-Sicherheitsregeln, die nur für ein Set von VNICs Ihrer Wahl in einem einzelnen VCN gelten (Beispiel: alle Compute-Instanzen, die als Webserver in der Web Tier einer Multi-Tier-Anwendung in Ihrem VCN fungieren).
• Im Vergleich zu Sicherheitslisten können Sie mit NSGs die Subnetzarchitektur Ihres VCN von Ihren Anforderungen an die Anwendungssicherheit trennen. Siehe Vergleich von Sicherheitslisten und Netzwerksicherheitsgruppen.
• Sie können NSGs mit bestimmten Ressourcentypen verwenden. Weitere Informationen finden Sie unter Unterstützung für Netzwerksicherheitsgruppen.
• NSG-Sicherheitsregeln entsprechen den Sicherheitslistenregeln. Bei der Quelle einer NSG-Sicherheitsregel (für Ingress-Regeln) oder dem Ziel (für Egress-Regeln) können Sie jedoch eine NSG anstelle eines CIDR angeben. So können Sie ganz einfach Sicherheitsregeln schreiben, um den Traffic zwischen zwei NSGs in ein und demselben VCN oder innerhalb einer einzelnen NSG zu steuern. Siehe Elemente einer Sicherheitsregel.
• Im Gegensatz zu Sicherheitslisten verfügt das VCN nicht über eine Standard-NSG. Außerdem ist jede von Ihnen erstellte NSG anfänglich leer. Sie enthält keine Standardsicherheitsregeln.
• Netzwerksicherheitsgruppen haben separate und unterschiedliche Limits im Vergleich zu Sicherheitslisten. Siehe Grenzwerte für Sicherheitslisten.

NSGs sind zum Erstellen und Verwenden verfügbar. Sie werden jedoch noch nicht von allen relevanten Oracle Cloud Infrastructure-Services unterstützt.

Derzeit unterstützen die folgenden Typen von übergeordneten Ressourcen die Verwendung von NSGs:

• Autonomous Recovery Service (Subnetze für Recovery Service): Wenn Sie ein Recovery-Servicesubnetz registrieren, können Sie mindestens eine NSG (maximal fünf) mit den Ingress-Regeln für Recovery Service verknüpfen.
• Compute-Instanzen: Wenn Sie eine Instanz erstellen, können Sie eine oder mehrere NSGs für die primäre VNIC der Instanz angeben. Wenn Sie eine sekundäre VNIC zu einer Instanz hinzufügen, können Sie eine oder mehrere NSGs für diese VNIC angeben. Sie können auch bestehende VNICs auf einer Instanz aktualisieren, sodass sie sich in einer oder mehreren NSGs befinden.
• Load Balancer: Wenn Sie einen Load Balancer erstellen, können Sie eine oder mehrere NSGs für den Load Balancer angeben (nicht das Backend-Set). Sie können auch einen vorhandenen Load Balancer aktualisieren, um eine oder mehrere NSGs zu verwenden.
• DB-Systeme: Wenn Sie ein DB-System erstellen, können Sie eine oder mehrere NSGs angeben. Sie können auch ein vorhandenes DB-System aktualisieren, um eine oder mehrere NSGs zu verwenden.
• Autonome Datenbanken: Wenn Sie eine Autonomous Database auf einer dedizierten Exadata-Infrastruktur erstellen, können Sie eine oder mehrere NSGs für die Infrastrukturressource angeben. Sie können auch eine vorhandene dedizierte Exadata-Infrastrukturinstanz aktualisieren, um NSGs zu verwenden.
• Mountziele: Wenn Sie ein Mountziel für ein Dateisystem erstellen, können Sie eine oder mehrere NSGs angeben. Sie können auch ein vorhandenes Mountziel aktualisieren, um eine oder mehrere NSGs zu verwenden.
• DNS-Resolver-Endpunkt: Wenn Sie einen Endpunkt für einen privaten DNS-Resolver erstellen, können Sie mindestens eine NSG angeben. Sie können auch einen vorhandenen Endpunkt aktualisieren, um mindestens eine NSG zu verwenden.
• Kubernetes-Cluster: Wenn Sie ein Kubernetes-Cluster mit der Kubernetes-Engine erstellen, können Sie mindestens eine NSG angeben, um den Zugriff auf den Kubernetes-API-Endpunkt und auf Worker-Knoten zu steuern. Sie können auch NSGs angeben, wenn Sie einen Load Balancer für ein Cluster definieren.
• API-Gateways: Wenn Sie ein API-Gateway erstellen, können Sie mindestens eine NSG angeben, um den Zugriff auf das API-Gateway zu steuern.
• Funktionen: Wenn Sie in OCI Functions eine Anwendung einrichten, können Sie mindestens eine NSG angeben, um Ingress- und Egress-Regeln zu definieren, die für alle Funktionen in dieser bestimmten Anwendung gelten.
• GoldenGate-Deployments: Wenn Sie ein GoldenGate-Deployment erstellen, können Sie mindestens eine NSG angeben, um den Zugriff auf das Deployment zu steuern.
• Redis-Cluster: Wenn Sie ein Redis-Cluster erstellen, können Sie eine oder mehrere NSGs angeben, um den Zugriff auf das Redis-Cluster zu kontrollieren. Sie können auch ein vorhandenes Cluster aktualisieren, um eine oder mehrere NSGs zu verwenden

Bei Ressourcentypen, die noch keine NSGs unterstützen, verwenden Sie weiterhin Sicherheitslisten, um den Traffic in diese und aus diesen übergeordneten Ressourcen zu steuern.

Eine Netzwerksicherheitsgruppe (NSG) stellt eine virtuelle Firewall für Cloud-Ressourcen bereit, die alle denselben Sicherheitsstatus aufweisen. Beispiel: Eine Gruppe von Compute-Instanzen, die alle dieselben Aufgaben ausführen und damit alle dieselben Ports verwenden müssen.

Eine NSG besteht aus zwei Elementtypen:

• VNICs: Eine oder mehrere VNICs (zum Beispiel die VNICs, die an die Compute-Instanzen angehängt sind, die alle denselben Sicherheitsstatus haben). Alle VNICs müssen sich in demselben VCN wie die NSG befinden. Siehe auch Sicherheitslisten und Netzwerksicherheitsgruppen im Vergleich.
• Sicherheitsregeln: Die Sicherheitsregeln der NSG definieren, welche Typen von Traffic in die und aus den VNICs in der Gruppe zulässig sind. Beispiel: Ingress-Traffic über TCP-Port 22 (SSH) aus einer bestimmten Quelle.

Wenn Ressourcen mit unterschiedlichem Sicherheitsstatus in ein und demselben VCN vorhanden sind, können Sie NSG-Sicherheitsregeln schreiben, um den Traffic zwischen den Ressourcen mit einem bestimmten Niveau anstatt einem anderen zu steuern. Beispiel: Im folgenden Diagramm führt NSG1 VNICs in einer Tier einer Anwendung mit Multi-Tier-Architektur aus. Bei NSG2 werden VNICs in einer zweiten Tier ausgeführt. Beide NSGs müssen zu demselben VCN gehören. Es wird davon ausgegangen, dass beide NSGs Verbindungen mit der anderen NSG initiieren müssen.

Bei NSG1 richten Sie Egress-Sicherheitsregeln ein, mit denen NSG2 als Ziel angegeben wird, und Ingress-Sicherheitsregeln, die NSG2 als Quelle angeben. Gleichermaßen richten Sie für NSG2 Egress-Sicherheitsregeln ein, die NSG1 als Ziel angeben, und Ingress-Sicherheitsregeln, die NSG1 als Quelle angeben. In diesem Beispiel wird davon ausgegangen, dass die Regeln für zustandsbehafteten Traffic vorgesehen sind.

Im vorherigen Diagramm wird davon ausgegangen, dass jede NSG Verbindungen für die andere NSG initiieren muss.

Im nächsten Diagramm wird davon ausgegangen, dass Sie stattdessen nur Verbindungen zulassen möchten, die von NSG1 zu NSG2 initiiert wurden. Dazu entfernen Sie die Ingress-Regel aus NSG1 und die Egress-Regel aus NSG2. Die verbleibenden Regeln lassen keine Verbindungen zu, die von NSG2 zu NSG1 initiiert wurden.

Im nächsten Diagramm wird davon ausgegangen, dass Sie den Traffic zwischen VNICs in derselben NSG steuern möchten. Legen Sie dazu die Quelle (für Ingress) oder das Ziel (für Egress) der Regel als eigene NSG fest.

Eine VNIC kann maximal in fünf NSGs vorhanden sein. Ein Paket ist zulässig, wenn eine beliebige Regel in einer der NSGs der VNIC den Traffic zulässt (oder wenn der Traffic Teil einer vorhandenen Verbindung ist, die verfolgt wird). Es gibt eine Bedingung, wenn die Listen Sicherheitsregeln sowohl für zustandsbehafteten als auch zustandslosen Traffic enthalten, die denselben Traffic abdecken. Weitere Informationen finden Sie unter Regeln für zustandsbehafteten und zustandslosen Traffic im Vergleich.

Netzwerksicherheitsgruppen sind regionale Entitys. Grenzwerte für Netzwerksicherheitsgruppen finden Sie unter Sicherheitslisten und Netzwerksicherheitsgruppen im Vergleich.

Informationen zu Limits finden Sie unter Limits für Netzwerksicherheitsgruppen und Erhöhung des Servicelimits anfordern.

Wenn Sie noch nicht mit den Grundlagen der NSG-Sicherheitsregeln vertraut sind, lesen Sie die folgenden Abschnitte im Thema zu Sicherheitsregeln:

• Elemente einer Sicherheitsregel
• Regeln für zustandsbehafteten und zustandslosen Traffic im Vergleich

Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-API-Dokumentation und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter SDKs und die CLI.

Informationen zur Verwendung der API und zu Signieranforderungen finden Sie unter REST-API-Dokumentation und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter SDKs und die CLI.

Es gibt einige Unterschiede im REST-API-Modell für NSGs im Vergleich zu Sicherheitslisten:

• Bei Sicherheitslisten gibt es ein IngressSecurityRule-Objekt und ein separates EgressSecurityRule-Objekt. Bei Netzwerksicherheitsgruppen gibt es nur ein SecurityRule-Objekt, und das direction-Attribut des Objekts bestimmt, ob die Regel für den Ingress- oder Egress-Traffic bestimmt ist.
• Bei Sicherheitslisten sind die Regeln Teil des SecurityList-Objekts, und Sie arbeiten mit den Regeln, indem Sie die Sicherheitslistenvorgänge aufrufen (wie UpdateSecurityList). Bei NSGs sind die Regeln nicht Bestandteil des NetworkSecurityGroup-Objekts. Stattdessen verwenden Sie separate Vorgänge, um mit den Regeln für eine bestimmte NSG zu arbeiten (Beispiel: UpdateNetworkSecurityGroupSecurityRules).
• Das Modell zum Aktualisieren vorhandener Sicherheitsregeln ist bei Sicherheitslisten anders als bei NSGs. Bei NSGs hat jede Regel in einer angegebenen Gruppe eine eindeutige von Oracle zugewiesene ID (Beispiel: 04ABEC). Wenn Sie UpdateNetworkSecurityGroupSecurityRules aufrufen, geben Sie die IDs der bestimmten Regeln an, die Sie aktualisieren möchten. Im Vergleich dazu haben die Regeln bei Sicherheitslisten keine eindeutige ID. Wenn Sie UpdateSecurityList aufrufen, müssen Sie die vollständige Liste der Regeln einschließlich der Regeln, die nicht im Aufruf aktualisiert werden, übergeben.
• Beim Aufrufen der Vorgänge zum Hinzufügen, Entfernen oder Aktualisieren von Sicherheitsregeln sind maximal 25 Regeln zulässig.

Allgemeiner Prozess für die Arbeit mit NSGs

1. Erstellen Sie eine NSG.
2. Fügen Sie der NSG Sicherheitsregeln hinzu.
3. Fügen Sie übergeordnete Ressourcen (genauer ausgedrückt: VNICs) zur NSG hinzu. Dies ist möglich, wenn Sie die übergeordnete Ressource erstellen, oder Sie können die übergeordnete Ressource aktualisieren und sie zu einer oder mehreren NSGs hinzufügen. Wenn Sie eine Compute-Instanz erstellen und zu einer NSG hinzufügen, wird die primäre VNIC der Instanz zur NSG hinzugefügt. Abgesehen davon können Sie auch sekundäre VNICs erstellen und diese optional zu NSGs hinzufügen.

NSGs löschen

Zum Löschen einer NSG darf sie keine VNICs oder übergeordneten Ressourcen enthalten. Wenn eine übergeordnete Ressource (oder eine VNIC der Compute-Instanz) gelöscht wird, wird sie automatisch aus den NSGs entfernt, in denen sie enthalten war. Sie haben möglicherweise keine Berechtigung, eine bestimmte übergeordnete Ressource zu löschen. Wenden Sie sich an Ihren Administrator, um festzustellen, wer Eigentümer einer bestimmten Ressource ist.

Erforderliche IAM Policy

Um Oracle Cloud Infrastructure zu verwenden, muss Ihnen ein Administrator in einer Policy  Sicherheitszugriff erteilen. Dieser Zugriff ist erforderlich, unabhängig davon, ob Sie die Konsole oder die REST-API mit einem SDK, einer CLI oder einem anderen Tool verwenden. Wenn Sie eine Nachricht erhalten, dass Sie keine Berechtigung haben oder nicht autorisiert sind, fragen Sie den Administrator, welcher Zugriffstyp Ihnen erteilt wurde und in welchem Compartment  Sie arbeiten sollen.

Für Administratoren: Die Policy unter Verwalten eines Cloud-Netzwerks durch Netzwerkadministratoren zulassen umfasst die Verwaltung aller Netzwerkkomponenten, einschließlich NSGs.

Wenn Sie über Sicherheitsadministratoren verfügen, die NSGs, aber keine anderen Komponenten im Networking-Service verwalten müssen, können Sie eine restriktivere Policy schreiben:

Allow group NSGAdmins to manage network-security-groups in tenancy
			
Allow group NSGAdmins to manage vcns in tenancy 
      where ANY {request.operation = 'CreateNetworkSecurityGroup',
                 request.operation = 'DeleteNetworkSecurityGroup'}

Allow group NSGAdmins to read vcns in tenancy

Allow group NSGAdmins to use VNICs in tenancy

Mit der ersten Anweisung kann die NSGAdmins-Gruppe NSGs und die zugehörigen Sicherheitsregeln erstellen und verwalten.

Die zweite Anweisung ist erforderlich, da sich das Erstellen oder Löschen einer NSG auf das VCN auswirkt, in dem sich die NSG befindet. Die Anweisung beschränkt die VCN-bezogenen Berechtigungen auf die Berechtigungen, die zum Erstellen oder Löschen einer NSG erforderlich sind. Die Anweisung lässt nicht zu, dass die NSGAdmins-Gruppe VCNs erstellt oder löscht oder mit Ressourcen in einem VCN arbeitet (NSGs ausgenommen).

Die dritte Anweisung ist für das Auflisten der VCNs erforderlich. Das ist eine Voraussetzung für das Erstellen oder Löschen einer NSG in einem VCN. Informationen dazu, warum sowohl die zweite als auch die dritte Anweisung erforderlich ist, finden Sie unter Bedingungen.

Die vierte Anweisung ist erforderlich, wenn die NSGAdmins-Gruppe VNICs in eine NSG aufnehmen muss. Wer die übergeordnete Ressource der VNIC erstellt (z.B. eine Compute-Instanz), muss bereits über diese Berechtigungsebene verfügen, um die übergeordnete Ressource zu erstellen.

Weitere Informationen zu Networking-Service-Policys finden Sie unter IAM-Policys für Networking.