Sicherheitsregeln

Informationen zu VNICs und übergeordneten Ressourcen

Eine VNIC ist eine Komponente des Networking-Service, mit der eine vernetzte Ressource wie eine Compute-Instanz eine Verbindung zu einem virtuellen Cloud-Netzwerk (VCN) herstellen kann. Die VNIC bestimmt, wie die Instanz mit Endpunkten innerhalb und außerhalb des VCN verbunden wird. Jede VNIC befindet sich in einem Subnetz in einem VCN.

Wenn Sie eine Compute-Instanz erstellen, wird automatisch eine VNIC für die Instanz im Subnetz der Instanz erstellt. Die Instanz wird als übergeordnete Ressource für die VNIC betrachtet. Sie können einer Compute-Instanz weitere (sekundäre) VNICs hinzufügen. Deshalb werden die VNICs einer Instanz deutlich sichtbar als Bestandteil der zugehörigen Ressourcen einer Compute-Instanz in der Konsole angezeigt.

Es gibt auch andere Arten von übergeordneten Ressourcen, die Sie erstellen können, und die auch zur automatischen Erstellung einer VNIC führen. Beispiel: Wenn Sie einen Load Balancer erstellen, erstellt der Load Balancer-Service automatisch VNICs, um den Traffic über das Backend-Set auszugleichen. Wenn Sie ein DB-System erstellen, erstellt der Datenbank-Service ebenfalls automatisch VNICs als DB-Systemknoten. Diese VNICs werden für Sie von den Services erstellt und verwaltet. Deshalb sind diese VNICs in der Konsole nicht sofort sichtbar, wie dies bei VNICs für Compute-Instanzen der Fall ist.

Um eine NSG zu verwenden, platzieren Sie die gewünschten VNICs in die Gruppe. Sie arbeiten in der Regel jedoch mit der übergeordneten Ressource anstatt der VNIC selbst, wenn Sie der Gruppe eine VNIC hinzufügen. Beispiel: Wenn Sie eine Compute-Instanz erstellen, können Sie optional eine NSG für die Instanz angeben. Obwohl Sie prinzipiell die Instanz der Gruppe hinzufügen, fügen Sie tatsächlich die primäre VNIC der Instanz der Netzwerksicherheitsgruppe hinzu. Die Sicherheitsregeln der Gruppe gelten für diese VNIC, nicht für die Instanz. Wenn Sie außerdem der Instanz eine sekundäre VNIC hinzufügen, können Sie optional eine NSG für diese VNIC angeben. Die Regeln gelten dann für diese VNIC und nicht für die Instanz. Beachten Sie, dass alle VNICs in einem bestimmten NSG in dem VCN enthalten sein müssen, zu dem die NSG gehört.

Wenn Sie einen Load Balancer zu einer Netzwerksicherheitsgruppe hinzufügen, fügen Sie im Prinzip den Load Balancer der Gruppe hinzu. Tatsächlich fügen Sie der Netzwerksicherheitsgruppe jedoch vom Load Balancer-Service verwaltete VNICs hinzu.

Sie verwalten die VNIC-Mitgliedschaft einer NSG in der übergeordneten Ressource und nicht in der NSG selbst. Anders ausgedrückt, um eine übergeordnete Ressource zu einer NSG hinzuzufügen, führen Sie die Aktion mit der übergeordneten Ressource aus (indem Sie angeben, welchen NSGs die übergeordnete Ressource hinzugefügt werden soll). Sie führen die Aktion nicht in der NSG aus (indem Sie angeben, welche VNICs oder übergeordneten Ressourcen zur NSG hinzugefügt werden sollen). Um eine VNIC aus einer NSG zu entfernen, führen Sie diese Aktion aus, indem Sie die übergeordnete Ressource aktualisieren und nicht die NSG. Beispiel: Um die VNIC einer vorhandenen Compute-Instanz zu einer NSG hinzuzufügen, aktualisieren Sie die Eigenschaften dieser VNIC, und geben Sie die NSG an. Beispiel: Mit der REST-API rufen Sie UpdateVnic auf. Zeigen Sie in der Konsole die Instanz und anschließend die gewünschte VNIC an. Dann bearbeiten Sie die Eigenschaften der VNIC.

Eine Liste der übergeordneten Ressourcen, die die Verwendung von NSGs unterstützen, finden Sie unter Unterstützung für Netzwerksicherheitsgruppen.

Netzwerksicherheitsgruppe als Quelle oder Ziel einer Regel

Es gibt einen wichtigen Unterschied, wie Sie Sicherheitsregeln für NSGs gegenüber Sicherheitslisten schreiben können.

Beim Schreiben von Regeln für eine NSG können Sie eine NSG als Quelle des Traffics (für Ingress-Regeln) oder als Ziel des Traffics (für Egress-Regeln) angeben. Im Vergleich dazu geben Sie bei Sicherheitslistenregeln ein CIDR als Quelle oder Ziel an.

Dadurch, dass eine NSG angegeben werden kann, können ganz einfach Regeln geschrieben werden, mit denen Traffic zwischen zwei verschiedenen NSGs gesteuert werden kann. Die NSGs müssen sich im selben VCN befinden.

Wenn Sie außerdem Traffic zwischen VNICs in einer bestimmten NSG steuern möchten, können Sie Regeln schreiben, die die eigene NSG der Regel als Quelle (für Ingress-Regeln) oder Ziel (für Egress-Regeln) angeben.

Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen - Überblick.

REST-API-Unterschiede

Das REST-API-Modell enthält einige grundlegende Unterschiede für NSGs im Vergleich zu Sicherheitslisten. Weitere Informationen finden Sie unter API verwenden.

Standardregeln

Das VCN verfügt automatisch über eine Standardsicherheitsliste, die mehrere Standardsicherheitsregeln enthält, um Ihnen die ersten Schritte mit dem Networking-Service zu erleichtern. Wenn Sie ein Subnetz erstellen, wird die Standardsicherheitsliste mit dem Subnetz verknüpft, es sei denn, Sie geben eine benutzerdefinierte Sicherheitsliste an, die Sie bereits im VCN erstellt haben.

Im Vergleich dazu verfügt das VCN über keine standardmäßige Netzwerksicherheitsgruppe.

Limits

Die beiden Features weisen unterschiedliche Limits auf. Unter Servicelimits finden Sie eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung anfordern.

Verwenden Sie Netzwerksicherheitsgruppen

Oracle empfiehlt die Verwendung von NSGs für Komponenten, die alle denselben Sicherheitsstatus aufweisen. In einer Multi-Tier-Architektur würden Sie beispielsweise für jede Tier separate NSG haben. Alle VNICs einer Tier gehören zu der NSG dieser Tier. Innerhalb einer bestimmten Tier kann eine bestimmte Untergruppe der VNICs der Tier vorhanden sein, die zusätzliche besondere Sicherheitsanforderungen haben. Daher würden Sie für diese zusätzlichen Regeln eine weitere NSG erstellen und diese Untergruppe von VNICs sowohl in der NSG der Tier als auch in der zusätzlichen NSG platzieren.

Oracle empfiehlt außerdem die Verwendung von NSGs, weil Oracle bei der Implementierung von zukünftigen Verbesserungen NSGs gegenüber Sicherheitslisten Priorität einräumen wird.

Machen Sie sich mit den Standardsicherheitslistenregeln vertraut

Das VCN verfügt automatisch über eine Standardsicherheitsliste, die mehrere Standardsicherheitsregeln enthält, um Ihnen die ersten Schritte mit dem Networking-Service zu erleichtern. Es gibt diese Regeln, weil sie die grundlegende Konnektivität ermöglichen. Selbst wenn Sie keine Sicherheitslisten oder Standardsicherheitsliste verwenden, machen Sie sich mit den Regeln vertraut, damit Sie die Traffictypen besser verstehen, die Ihre vernetzten Cloud-Ressourcen benötigen. Möglicherweise möchten Sie diese Regeln in Ihren NSGs oder benutzerdefinierten Sicherheitslisten verwenden, die Sie einrichten.

Die Standardsicherheitsliste enthält keine Regeln zum Aktivieren von Ping. Wenn Sie Ping verwenden müssen, lesen Sie den Abschnitt Regeln zum Aktivieren von Ping.

Löschen Sie Standardsicherheitsregeln nicht wahllos

Das VCN verfügt möglicherweise über Subnetze, die standardmäßig die Standardsicherheitsliste verwenden. Löschen Sie keine Standardsicherheitsregeln aus der Liste, es sei denn, Sie haben bereits bestätigt, dass die Ressourcen in Ihrem VCN diese nicht benötigen. Andernfalls kann die Konnektivität des VCN unterbrochen werden.

Stellen Sie sicher, dass die Firewallregeln Ihres Betriebssystems mit Ihren Sicherheitsregeln ausgerichtet sind

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

Verwenden Sie VNIC-Metriken zur Fehlerbehebung bei Paketen, die aufgrund von Sicherheitsregeln verworfen wurden

Der Networking-Service bietet Metriken für VNICs, die das VNIC-Trafficaufkommen (Pakete und Byte) zeigen. Zwei der Metriken sind für Ingress- und Egress-Pakete bestimmt, die Sicherheitsregeln verletzen und daher gelöscht werden. Mit diesen Metriken können Sie Probleme im Zusammenhang mit Sicherheitsregeln beheben und können angeben, ob Ihre VNICs den gewünschten Traffic erhalten.

Regeln für zustandsbehafteten Traffic

Wenn Sie mit der Markierung festlegen, dass eine Sicherheitsregel für zustandsbehafteten Traffic bestimmt ist, bedeutet dies, dass Sie das Verbindungstracking für jeden Traffic verwenden möchten, der dieser Regel entspricht. Wenn eine Instanz Traffic empfängt, der der Regel für zustandsbehafteten Ingress entspricht, wird die Antwort verfolgt und die Rücksendung an den ursprünglichen Host automatisch zugelassen, unabhängig von Egress-Regeln, die für die Instanz gelten. Wenn eine Instanz Traffic sendet, der einer Regel für zustandsbehafteten Egress entspricht, wird die eingehende Antwort automatisch zugelassen, unabhängig von den Ingress-Regeln.

Beispiel: Möglicherweise haben Sie eine Sicherheitsregel für zustandsbehafteten Ingress für eine Instanz (Instanz A), die HTTP-Traffic von Host B empfangen und beantworten muss. Host B kann ein beliebiger Host sein, unabhängig davon, ob es sich um eine Instanz handelt. Instanz A und Host B kommunizieren, weil die Regel für zustandsbehafteten Ingress Traffic von allen Quell-IP-Adressen (0.0.0.0/0) nur an den Zielport 80 (TCP-Protokoll) zulässt. Es ist keine Egress-Regel erforderlich, um den Antworttraffic zu ermöglichen, weil Antworten automatisch verfolgt und zugelassen werden.

Regeln für zustandslosen Traffic

In der nächsten Abbildung werden Instanz A und Host B wie zuvor dargestellt, allerdings jetzt mit Sicherheitsegeln für zustandslosen Traffic. Wie bei der Regel für zustandsbehafteten Traffic im vorherigen Abschnitt, lässt die Regel für zustandslosen Ingress Traffic von allen IP-Adressen und Ports nur auf dem Zielport 80 (mit dem TCP-Protokoll) zu. Um den Antworttraffic zuzulassen, muss eine entsprechende Regel für zustandslosen Egress vorhanden sein, die den Traffic zu einer beliebigen Ziel-IP-Adresse (0.0.0.0/0) und allen Ports nur vom Quellport 80 (mit dem TCP-Protokoll) zulässt.

Wenn Instanz A stattdessen HTTP-Traffic initiieren und die Antwort abrufen muss, ist ein anderes Set von Regeln für zustandslosen Traffic erforderlich. Wie in der nächsten Abbildung dargestellt, würde in der Egress-Regel als Quellport "Alle" und als Zielport "80 (HTTP)" angegeben sein. In der Ingress-Regel würde dann als Quellport "80" und als Zielport "Alle" angegeben sein.

Wenn Sie für Instanz A das Port-Binding verwenden, um genau anzugeben, von welchem Port der HTTP-Traffic stammt, können Sie dies als Quellport in der Egress-Regel und als Zielport in der Ingress-Regel angeben.

Verbindungstrackingdetails für Regeln für zustandsbehafteten Traffic

Oracle verwendet Verbindungstracking, um Antworten für Traffic zuzulassen, der mit Regeln für zustandsbehafteten Traffic übereinstimmt (siehe Regeln für zustandsbehafteten und zustandslosen Traffic im Vergleich). Jede Instanz hat eine maximale Anzahl gleichzeitiger Verbindungen, die basierend auf der Ausprägung der Instanz überwacht werden können.

Um den Antwortverkehr für TCP, UDP und ICMP zu bestimmen, führt Oracle Verbindungstracking für die folgenden Elemente des Pakets durch:

• Protokoll
• Quell- und Ziel-IP-Adressen
• Quell- und Zielports (nur für TCP und UDP)

Verfolgte Verbindungen werden aufrechterhalten, solange der Traffic für die Verbindung empfangen wird. Wenn eine Verbindung längere Zeit ungenutzt bleibt, wird sie wegen Timeout abgebrochen und entfernt. Nach dem Entfernen werden die Antworten für eine zustandsbehaftete Sicherheitsregel verworfen. In der folgenden Tabelle sind die standardmäßigen Inaktivitätstimeouts aufgeführt:

PMTUD-Nachrichten für Regeln für zustandslosen Traffic aktivieren

Wenn Sie Sicherheitsregeln für zustandslosen Traffic verwenden, um Traffic an/von Endpunkten außerhalb des VCN zuzulassen, muss unbedingt eine Sicherheitsregel hinzugefügt werden, die Ingress-ICMP-Traffic vom Typ 3 Code 4 von 0.0.0.0/0 und allen Quellports zulässt. Mit dieser Regel können Ihre Instanzen Path MTU Discovery-Fragmentierungsmeldungen erhalten. Diese Regel ist für den Aufbau einer Verbindung zu Ihren Instanzen von entscheidender Bedeutung. Ohne sie können Konnektivitätsprobleme auftreten. Weitere Informationen finden Sie unter Hängende Verbindung.