Netzwerksicherheitsgruppen

• Netzwerksicherheitsgruppen (NSGs) fungieren als virtuelle Firewall für Computing-Instanzen und andere Arten von Ressourcen. Eine NSG besteht aus einem Set von Ingress- und Egress-Sicherheitsregeln, die nur für eine Gruppe von VNICs in einem einzelnen VCN gelten (Beispiel: alle Compute -Instanzen, die als Webserver in der Web-Tier einer Multi-Tier -Anwendung in einem VCN fungieren).
• Im Vergleich zu Sicherheitslisten können Sie mithilfe von NSGs die Subnetzarchitektur eines VCN von den 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 weist das VCN keine Standard-NSG auf. 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. Die Services werden jedoch noch nicht von allen relevanten Oracle Cloud Infrastructure-Services unterstützt.

Die folgenden Typen von übergeordneten Ressourcen unterstützen den Einsatz 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 diese sich in einer oder mehreren NSGs befinden.
• Load Balancer: Wenn Sie einen Load Balancing erstellen, können Sie eine oder mehrere NSGs für den Load Balancing (nicht das Backend-Set) angeben. Sie können auch einen vorhandenen Load Balancing 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.
• 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: Beim Erstellen eines API-Gateways 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 mindestens eine NSG zu verwenden

Bei Ressourcentypen, die NSGs noch nicht unterstützen, verwenden Sie weiterhin Sicherheitslisten, um den Traffic in diesen 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 Computing-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 das Set der 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 einem und demselben VCN vorhanden sind, können Sie NSG-Sicherheitsregeln schreiben, um dem Traffic zwischen den Ressourcen mit einem bestimmten Wert anstatt einem anderen zu steuern. Beispiel: Im folgenden Diagramm werden in NSG1 VNICs in einer Tier einer Anwendung mit Multi-Tier-Architektur ausgeführt. 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 zur anderen NSG starten 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 starten muss.

Im nächsten Diagramm wird davon ausgegangen, dass Sie stattdessen nur Verbindungen zulassen möchten, die von NSG1 zu NSG2 gestartet 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 bis NSG1 gestartet werden.

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 eine der NSGs der VNIC den Traffic zulässt (oder wenn der Traffic Teil einer vorhandenen Verbindung ist, der verfolgt wird), es sei denn, die Listen enthalten sowohl zustandsbehaftete als auch zustandslose Sicherheitsregeln, die denselben Traffic abdecken. Weitere Informationen finden Sie unter Zustandsbehaftete Regeln im Vergleich zu zustandslosen Regeln.

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
• Zustandsbehaftet im Vergleich zu Regeln für zustandslosen Traffic

Informationen zur Verwendung der API und zu Signaturanforderungen 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 Signaturanforderungen finden Sie unter REST-API-Dokumentation und Sicherheitszugangsdaten. Informationen zu SDKs finden Sie unter SDKs und die CLI.

Die REST-API-Modell für NSGs enthält einige grundlegende Unterschiede im Vergleich zu Sicherheitslisten:

• Sicherheitslisten haben ein IngressSecurityRule-Objekt und ein separates EgressSecurityRule-Objekt. Netzwerksicherheitsgruppen haben nur ein SecurityRule-Objekt, und das direction-Attribut des Objekts zeigt an, ob die Regel für Ingress- oder Egress-Traffic gilt.
• 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 ist die Regel nicht Bestandteil des NetworkSecurityGroup-Objekts. Stattdessen verwenden Sie separate Vorgänge, um mit den Regeln für eine gewisse 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 bestimmten 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 gesamte Liste der Regeln übergeben, einschließlich Regeln, die im Aufruf nicht aktualisiert werden.
• Beim Aufrufen der Vorgänge, die hinzugefügt, entfernt oder aktualisiert werden sollen, sind Sicherheitsregeln auf 25 Regeln begrenzt.