Sicherheitsregeln

Informationen zu VNICs und übergeordneten Ressourcen

Eine VNIC ist eine Networking-Servicekomponente, die für eine vernetzte Ressource, z.B. eine Compute -Instanz, erforderlich ist, um eine Verbindung zu einem virtuellen Cloud-Netz (VCN) herzustellen. Die VNIC beeinflusst, wie die Instanz Verbindungen mit Endpunkten innerhalb und außerhalb des VCN herstellt. Jede VNIC befindet sich in einem Subnetz in einem VCN.

Wenn Sie eine Computing-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 eine Compute-Instanz weitere (sekundäre) VNICs hinzufügen. Deshalb werden die VNICs einer Instanz deutlich deutlich sichtbar als Bestandteil der zugehörigen Ressourcen der Compute-Instanz in der Konsole angezeigt.

Andere Typen von übergeordneten Ressourcen führen auch dazu, dass automatisch eine VNIC erstellt wird. Beispiel: Wenn Sie einen Load-Balancer erstellen, erstellt er automatisch VNICs, um 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. Aus diesem Grund sind diese VNICs in der Konsole nicht sofort sichtbar, wie sie bei VNICs für Computing-Instanzen der Fall sind.

Um eine NSG zu verwenden, fügen Sie aktiv VNICs in die Gruppe ein. Eine VNIC ist nie Teil einer NSG, weil sie sich in einem bestimmten Subnetz befindet. 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 Computing-Instanz erstellen, können Sie optional eine NSG für die Instanz angeben. Obwohl Sie die Instanz der Gruppe konzeptionell hinzufügen, fügen Sie die primäre VNIC der Instanz in die Netzwerksicherheitsgruppe ein. 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 einer NSG in demselben VCN enthalten sein müssen, zu dem die NSG gehört.

Wenn Sie einen Load Balancing in einer Netzwerksicherheitsgruppe einfügen, fügen Sie den Load Balancing im Prinzip in die Gruppe ein. Technisch fügen Sie der Netzwerksicherheitsgruppe vom Load Balancer-Service verwaltete VNICs hinzu.

Sie verwalten die VNIC-Mitgliedschaft einer NSG in der übergeordneten Ressource und nicht in der NSG selbst. Beispiel: 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 wird). Sie führen die Aktion nicht in der NSG aus (indem Sie angeben, welche VNICs oder übergeordneten Ressourcen der NSG hinzugefügt werden sollen). Um eine VNIC aus einer NSG zu entfernen, führen Sie diese Aktion nicht die NSG, sondern die übergeordnete Ressource aus. Beispiel: Um eine vorhandene Compute-Instanz zu einer NSG hinzuzufügen, aktualisieren Sie die Eigenschaften dieser VNIC und geben die NSG an. Beispiel: Mit der REST-API rufen Sie UpdateVnic auf. Zeigen Sie in der Konsole die Instanz und anschließend die relevante VNIC an, und bearbeiten Sie dann 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

Ein wichtiger Unterschied beim Schreiben von Sicherheitsregeln für NSGs im Vergleich zu Sicherheitslisten: Wenn Sie Regeln für eine NSG schreiben, können Sie ein NSG als Quelle des Traffics (für Ingress-Regeln) oder als Ziel des Traffics ( für Egress-Regeln) festlegen. 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.

Um den Traffic zwischen VNICs in einer bestimmten NSG zu steuern, können Sie Regeln schreiben, in denen die eigene NSG der Regel als Quelle (für Ingress-Regeln) oder Ziel (für Egress-Regeln) angegeben wird.

Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen - Überblick.

REST-API-Unterschiede

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

Standardregeln

Ein VCN enthält automatisch eine Standardsicherheitsliste, die verschiedene Standardsicherheitsregeln enthält, um Ihnen den Einstieg in den Networking-Service zu vereinfachen. Wenn Sie ein Subnetz erstellen, wird die Standardsicherheitslisten mit dem Subnetz verknüpft, es sei denn, Sie geben eine benutzerdefinierte Sicherheitsliste an. Die Liste wurde bereits im VCN erstellt.

Im Vergleich dazu hat das VCN keine standardmäßige Netzwerksicherheitsgruppe.

Limits

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

Verwenden Sie Netzwerksicherheitsgruppen

Es wird empfohlen, NSGs für Komponenten zu verwenden, die alle denselben Sicherheitsstatus aufweisen. In einer Multitier-Architektur würden Sie beispielsweise für jede Tier separate NSG haben. Alle VNICs der Tier gehören zur NSG dieser Tier. Innerhalb einer spezifischen Tier kann eine bestimmte Untergruppe der VNICs der Tier vorhanden sind, die besondere Sicherheitsanforderungen haben. Daher würden Sie für diese weiteren Regeln eine weitere NSG erstellen und die Untergruppe von VNICs sowohl in die NSG der Ebene als auch in die zusätzliche NSG platzieren.

Oracle empfiehlt außerdem, NSGs zu verwenden, weil Oracle NSGs beim Implementieren von zukünftigen Verbesserungen gegenüber Sicherheitslisten priorisiert.

Machen Sie sich mit den Standardsicherheitslistenregeln vertraut

Ein VCN enthält automatisch eine Standardsicherheitsliste, die verschiedene Standardsicherheitsregeln enthält, um Ihnen den Einstieg in den Networking-Service zu vereinfachen. Es gibt diese Regeln, weil sie die grundlegende Konnektivität ermöglichen. Selbst wenn Sie weder Sicherheitslisten noch Standardsicherheitsliste verwenden, machen sie sich mit den Regeln vertraut, damit Sie besser verstehen, welche Traffictypen vernetzte Cloud-Ressourcen benötigen. Sie können diese Regeln in 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

Ein VCN verfügt möglicherweise über Subnetze, die standardmäßig die Standardsicherheitsliste verwenden. Löschen Sie keine Standardsicherheitsregeln der Liste, es sei denn, Sie haben zuvor bestätigt, dass Ressourcen im VCN sie nicht benötigen. Andernfalls können Sie die Konnektivität des VCN unterbrechen.

Übereinstimmung der BS-Firewallregeln mit Sicherheitsregeln bestätigen

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 angeben, ob die VNICs den richtigen 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 Response-Traffic zu ermöglichen, da 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 starten und die Antwort abrufen muss, ist ein anderes Set von Regeln zum 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, damit Antworten für Traffic zuzulassen sind, der mit Regeln für zustandsbehafteten Traffic übereinstimmt (siehe Regeln für zustandsbehafteten Traffic im Vergleich zu zustandslosen Regeln). 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 entscheiden, führt Oracle Verbindungstracking für die folgende Elemente des Pakets aus:

• 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 lange genug im Leerlauf ist, wird sie wegen Timeout abgebrochen und entfernt. Nachdem die Verbindung entfernt wurde, werden die Antworten für eine zustandsbehaftete Sicherheitsregel gelöscht. In der folgenden Tabelle sind die standardmäßigen Inaktivitätstimeouts aufgeführt:

Pfad-MTU-Discovery-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 Compute-Instanzen Path MTU Discovery-Fragmentierungsmeldungen erhalten. Diese Regel ist für das Aufbau einer Verbindung zu Instanzen wichtig. Ohne sie können Konnektivitätsprobleme auftreten. Weitere Informationen finden Sie unter Hängende Verbindung.