Oracle Cloud Infrastructure - Dokumentation

Networking sichern: VCN, Load Balancer und DNS

Sicherheitsempfehlungen

Der Networking-Service verfügt über umfangreiche Features, mit denen die Netzwerkzugriffskontrolle durchgesetzt und VCN-Traffic geschützt werden kann. Diese Features werden in der folgenden Tabelle aufgeführt.

VCN-Feature Sicherheitsbeschreibung
Öffentliche und private Subnetze Ihr VCN kann in Subnetze partitioniert werden. Subnetze waren ursprünglich einer Availability-Domain zugeordnet, können aber inzwischen regional genutzt werden (wobei sie alle Availability-Domains in der Region abdecken). Instanzen innerhalb von privaten Subnetzen können keine öffentlichen IP-Adressen haben. Instanzen innerhalb von öffentlichen Subnetzen können optional (in Ihrem Ermessen) öffentliche IP-Adressen haben.
Sicherheitsregeln Sicherheitsregeln bieten zustandsbehaftete und zustandslose Firewallfunktionen, um den Netzwerkzugriff auf Ihre Instanzen zu kontrollieren. Um Sicherheitsregeln in Ihrem VCN zu implementieren, können Sie Netzwerksicherheitsgruppen (NSGs) oder Sicherheitslisten verwenden. Weitere Informationen finden Sie unter Vergleich von Sicherheitslisten und Netzwerksicherheitsgruppen.
Gateways

Mit Gateways können Ressourcen in einem VCN mit Zielen außerhalb des VCN kommunizieren. Die Gateways umfassen:

  • Internetgateway: für Internetkonnektivität (für Ressourcen mit öffentlichen IP-Adressen in öffentlichen Subnetzen)
  • NAT-Gateway: für Internetkonnektivität, ohne die Ressourcen für eingehende Internetverbindungen (für Ressourcen in privaten Subnetzen) zugänglich zu machen
  • Dynamisches Routinggateway (Dynamic Routing Gateway, DRG): für Konnektivität mit Netzwerken außerhalb der Region des VCN (z.B. Ihr On-Premise-Netzwerk über ein Site-to-Site-VPN oder FastConnect oder ein Peer-VCN in einer anderen Region)
  • Servicegateway: für private Konnektivität zu Oracle-Services wie Object Storage
  • Lokales Peering-Gateway (LPG): für Konnektivität zu einem Peer-VCN in derselben Region
Routentabellenregeln Routentabellen kontrollieren, wie Traffic von den Subnetzen Ihres VCN zu Zielen außerhalb des VCN geleitet wird. Routingziele können VCN-Gateways oder private IP-Adressen im VCN sein.
IAM-Policys für virtual-network-family IAM-Policys geben den Zugriff und die Aktionen an, die von IAM-Gruppen an Ressourcen in einem VCN zulässig sind. Beispiel: IAM-Policys können administrative Berechtigungen für Netzwerkadministratoren erteilen, die die VCNs verwalten, und die Berechtigungen für normale Benutzer eingrenzen.

Oracle empfiehlt, die Oracle Cloud Infrastructure Audit-Logs in regelmäßigen Abständen zu prüfen, um Änderungen an VCN-Netzwerksicherheitsgruppen, Sicherheitslisten, Routentabellenregeln und VCN-Gateways zu ermitteln.

Netzwerksegmentierung: VCN-Subnetze

  • Formulieren Sie eine Strategie mit mehreren Subnetz-Tiers für das VCN, um den Netzwerkzugriff zu kontrollieren. Ein gängiges Entwurfsmuster besteht darin, die folgenden Subnetz-Tiers zu verwenden:

    1. DMZ-Subnetz für Load Balancer
    2. Öffentliches Subnetz für extern zugängliche Hosts wie NAT-Instanzen, Instanzen zur Angriffserkennung (IDS) und Webanwendungsserver
    3. Privates Subnetz für interne Hosts wie Datenbanken

    Es ist kein spezielles Routing erforderlich, damit die Instanzen in den verschiedenen Subnetzen kommunizieren können. Sie können jedoch die Arten von Traffic zwischen den verschiedenen Tiers mit den Netzwerksicherheitsgruppen oder Sicherheitslisten des VCN steuern.

  • Instanzen im privaten Subnetz haben nur private IP-Adressen und können nur von anderen Instanzen im VCN erreicht werden. Oracle empfiehlt, sicherheitsrelevante Hosts (z.B. DB-Systeme) in einem privaten Subnetz unterzubringen und Sicherheitsregeln zu verwenden, um die Art der Konnektivität zu Hosts in einem öffentlichen Subnetz zu kontrollieren. Zusätzlich zu VCN-Sicherheitsregeln sollten Sie hostbasierte Firewalls wie iptables oder firewalld zur Netzwerkzugriffskontrolle als Abwehrmechanismus konfigurieren.
  • Sie können ein Servicegateway zu Ihrem VCN hinzufügen, damit DB-Systeme im privaten Subnetz direkt in Object Storage gesichert werden können, ohne dass der Traffic das Internet durchläuft. Sie müssen die Routing- und Sicherheitsregeln einrichten, um diesen Traffic zu ermöglichen. Weitere Informationen zu Bare-Metal- oder VM-DB-Systemen finden Sie unter Netzwerk konfigurieren. Weitere Informationen zu Exadata-DB-Systemen finden Sie unter Network Setup für Exadata Cloud Service-Instanzen.

Netzwerkzugriffskontrolle: VCN-Sicherheitsregeln

  • Mit den Sicherheitsregeln Ihres VCN können Sie den Netzwerkzugriff auf Instanzen beschränken. Eine Sicherheitsregel ist standardmäßig zustandsbehaftet, kann jedoch auch als zustandslos konfiguriert werden. Im Allgemeinen werden zustandslose Regeln für Anwendungen mit hoher Performance verwendet. In Fällen, in denen Netzwerktraffic sowohl mit der zustandsbehafteten als auch der zustandslosen Sicherheitsliste übereinstimmt, hat die zustandslose Regel Vorrang. Weitere Informationen zum Konfigurieren von VCN-Sicherheitsregeln finden Sie unter Sicherheitsregeln.
  • Um unbefugten Zugriff oder Angriffe auf Compute-Instanzen zu verhindern, empfiehlt Oracle, eine VCN-Sicherheitsregel zu verwenden, die SSH- oder RDP-Zugriff nur über autorisierte CIDR-Blöcke anstatt von offenen Internetquellen (0.0.0.0/0) zulässt. Für zusätzliche Sicherheit können Sie den SSH-Zugriff (Port 22) oder RDP-Zugriff (Port 3389) bei Bedarf über die VCN-API UpdateNetworkSecurityGroupSecurityRules (wenn Sie Netzwerksicherheitsgruppen verwenden) oder UpdateSecurityList (wenn Sie Sicherheitslisten verwenden) vorübergehend aktivieren. Weitere Informationen zum Aktivieren des RDP-Zugriffs finden Sie unter So aktivieren Sie den RDP-Zugriff in Instanzen erstellen. Zur Ausführung von Health Checks für Instanzen empfiehlt Oracle, VCN-Sicherheitsregeln so zu konfigurieren, dass sie ICMP-Pings zulassen. Weitere Informationen finden Sie unter Regeln zum Aktivieren von Ping.
  • Bastions sind logische Entitys, die einen gesicherten öffentlichen Zugriff auf Zielressourcen in der Cloud bereitstellen, den Sie sonst nicht über das Internet erreichen können. Bastions befinden sich in einem öffentlichen Subnetz und richten die Netzwerkinfrastruktur ein, die zum Verbinden eines Benutzers mit einer Zielressource in einem privaten Subnetz erforderlich ist.
  • VCN-Netzwerksicherheitsgruppen (NSGs) und -Sicherheitslisten ermöglichen die sicherheitsrelevante Netzwerkzugriffskontrolle auf Compute-Instanzen. Außerdem müssen alle unbeabsichtigten oder nicht autorisierten Änderungen an NSGs und Sicherheitslisten vermieden werden. Um nicht autorisierte Änderungen zu verhindern, empfiehlt Oracle, IAM-Policys zu verwenden, damit nur Netzwerkadministratoren Änderungen an NSGs und Sicherheitslisten vornehmen können.

Sichere Konnektivität: VCN-Gateways und FastConnect-Peering

  • VCN-Gateways stellen externe Konnektivität (Internet, On Premise oder Peer-VCN) für VCN-Hosts bereit. Eine Liste der Gatewaytypen finden Sie in der Tabelle weiter oben in diesem Thema. Oracle empfiehlt, eine IAM Policy zu verwenden, damit nur Netzwerkadministratoren VCN-Gateways erstellen oder ändern können.

  • Überlegen Sie gründlich, ob Sie Internetzugriff auf Instanzen zulassen möchten. So soll z.B. versehentlicher Internetzugriff auf vertrauliche Datenbankinstanzen verhindert werden. Damit eine Instanz in einem VCN öffentlich über das Internet zugänglich ist, müssen Sie die folgenden VCN-Optionen konfigurieren:

    • Die Instanz muss sich in einem öffentlichen VCN-Subnetz befinden.
    • Für das VCN, das die Instanz enthält, muss ein Internetgateway aktiviert und als Routingziel für ausgehenden Traffic konfiguriert sein.
    • Der Instanz muss eine öffentliche IP-Adresse zugewiesen sein.
    • Die VCN-Sicherheitsliste für das Subnetz der Instanz muss so konfiguriert sein, dass eingehender Traffic von 0.0.0.0/0 zugelassen wird. Wenn Sie Netzwerksicherheitsgruppen (NSG) verwenden, muss sich die Instanz in einer NSG befinden, die diesen Traffic zulässt.
  • VPN-IPsec bietet Konnektivität zwischen dem On-Premise-Netzwerk eines Kunden und dem VCN. Sie können zwei IPsec-Tunnel für High Availability erstellen. Weitere Informationen zum Erstellen von VPN-Tunneln zum Verbinden von VCN-DRG mit Kunden-CPEs finden Sie unter Site-to-Site-VPN.
  • Mit FastConnect-Peering können Sie Ihr On-Premise-Netzwerk mit einem privaten Circuit mit Ihrem VCN verbinden, sodass der Traffic nicht das öffentliche Internet durchläuft. Sie können Private Peering (für die Verbindung mit privaten IP-Adressen) oder Public Peering (für die Verbindung mit öffentlichen Oracle Cloud Infrastructure-Endpunkten wie Object Storage) einrichten. Weitere Informationen zu FastConnect-Peering-Optionen finden Sie unter FastConnect.

Virtuelle Sicherheits-Appliances in einem VCN

  • Mit dem Service Networking können Sie Netzwerksicherheitsfunktionen wie Angriffserkennung, Firewalls auf Anwendungsebene und NAT implementieren (Sie können jedoch stattdessen auch ein NAT-Gateway mit Ihrem VCN verwenden). Dazu können Sie den gesamten Subnetztraffic an einen Netzwerksicherheitshost weiterleiten und dabei Routentabellenregeln verwenden, die eine lokale private VCN-IP-Adresse als Ziel nutzen. Weitere Informationen finden Sie unter Private IP als Routingziel verwenden. Für High Availability können Sie dem Gatewaysicherheitshost eine sekundäre private IP-Adresse zuweisen, die Sie bei einem Ausfall des primären Hosts zu einer VNIC auf einem Standbyhost verschieben können. Die vollständige Netzwerkpaketerfassung oder Netzwerkflowlogs können auf den NAT-Instanzen mit tcpdump aufgezeichnet werden. Die Logs können regelmäßig in einen Object Storage-Bucket hochgeladen werden.

  • Virtuelle Sicherheits-Appliances können auf einer Bare-Metal-Instanz als virtuelle Maschinen (VMs) nach dem Bring Your Own Hypervisor-(BYOH-)Prinzip ausgeführt werden. Virtuelle Sicherheits-Appliance-VMs, die auf der BYOH-Bare-Metal-Instanz ausgeführt werden, verfügen jeweils über ihre eigene sekundäre VNIC und liefern direkte Konnektivität zu anderen Instanzen und Services im VCN der VNIC. Informationen zum Aktivieren von BYOH auf einer Bare-Metal-Instanz mit einem Open-Source-KVM-Hypervisor finden Sie unter Eigenes Hypervisor-Gastbetriebssystem bereitstellen.
  • Virtuelle Sicherheits-Apps können auch auf Compute-VMs installiert werden, auf denen VMDK- oder QCOW2-Images von Sicherheits-Apps mit dem BYOI-Feature importiert werden können. Aufgrund von Infrastrukturabhängigkeiten funktioniert das BYOI-Feature möglicherweise bei einigen Appliances nicht. In diesem Fall wäre das BYOH-Modell eine weitere Option. Weitere Informationen zum Importieren von Appliance-Images in Oracle Cloud Infrastructure finden Sie unter Bring Your Own Image (BYOI).

Load Balancer

  • Oracle Cloud Infrastructure Load Balancer ermöglichen End-to-End-TLS-Verbindungen zwischen den Anwendungen eines Clients und dem VCN eines Kunden. Die TLS-Verbindung kann auf einem HTTP-Load-Balancer oder auf einem Backend-Server mit einem TCP-Load-Balancer beendet werden. Die Load Balancer verwenden standardmäßig TLS 1.2. Informationen zum Konfigurieren eines HTTPS-Listeners finden Sie unter Listener für Load Balancer. Sie können auch Ihre eigenen TLS-Zertifikate hochladen. Weitere Informationen finden Sie unter SSL-Zertifikate für Load Balancer.
  • Sie können den Netzwerkzugriff auf Load Balancer mit VCN-Netzwerksicherheitsgruppen oder -Sicherheitslisten konfigurieren. Diese Methode bietet ähnliche Funktionen wie herkömmliche Load-Balancer-Firewalls. Für öffentliche Load Balancer empfiehlt Oracle, ein regionales öffentliches Subnetz (z.B. DMZ-Subnetz) zum Instanziieren der Load Balancer in einer hochverfügbaren Konfiguration in zwei verschiedenen Availability-Domains zu verwenden. Sie können die Load-Balancer-Firewallregeln konfigurieren, indem Sie die Netzwerksicherheitsgruppen des Load Balancers oder die Sicherheitslisten des Subnetzes einrichten. Weitere Informationen zum Erstellen von Load-Balancer-Sicherheitslisten finden Sie unter Load-Balancer-Sicherheitslisten aktualisieren und Internettraffic an den Listener zulassen. Gleichermaßen müssen Sie die Netzwerksicherheitsgruppen oder Sicherheitslisten des VCN für die Backend-Server konfigurieren, um nur Traffic von den öffentlichen Load Balancern zu begrenzen. Weitere Informationen zur Konfiguration von Backend-Serversicherheitslisten finden Sie unter Regeln aktualisieren, um Traffic zu Backend-Servern zu begrenzen.

DNS-Zonen und -Datensätze

DNS-Zonen und -Datensätze sind entscheidend für die Verfügbarkeit von Webeigenschaften. Falsche Updates oder unbefugte Löschvorgänge können zu einem Ausfall von Services führen, auf die über die DNS-Namen zugegriffen wird. Oracle empfiehlt, IAM-Benutzer einzugrenzen, die DNS-Zonen und -Datensätze ändern können.

DNS Traffic Management Steering Policies

Falsche Aktualisierungen oder nicht autorisierte Löschungen an den Steuerungs-Policys für das DNS-Trafficmanagement können zu einem Ausfall von Services führen, weil Traffic falsch oder Failover ausfällt. Oracle empfiehlt, IAM-Benutzer einzugrenzen, die DNS-Trafficmanagementsteuerungs-Policys ändern können.

Beispiele für Sicherheits-Policys

Benutzern erlauben, Sicherheitslisten nur anzuzeigen

Ihre Netzwerkadministratoren sind die Mitarbeiter, die Netzwerksicherheitsgruppen und Sicherheitslisten erstellen und verwalten dürfen.

Möglicherweise haben Sie jedoch Netzwerkbenutzer, die wissen müssen, welche Sicherheitsregeln in einer bestimmten Netzwerksicherheitsgruppe (NSG) oder Sicherheitsliste vorliegen.

Die erste Zeile der folgenden Beispiel-Policy erlaubt der Gruppe NetworkUsers, Sicherheitslisten und deren Inhalte anzuzeigen. Diese Policy ermöglicht der Gruppe jedoch nicht das Erstellen, Anhängen, Löschen oder Ändern von Sicherheitslisten.

Die zweite Zeile erlaubt der Gruppe NetworkUsers, die Sicherheitsregeln in NSGs und außerdem die VNICs und übergeordneten Ressourcen in NSGs anzuzeigen. Die zweite Zeile erlaubt der Gruppe NetworkUsers nicht, die Sicherheitsregeln in NSGs zu ändern.

Allow group NetworkUsers to inspect security-lists in tenancy
Allow group NetworkUsers to use network-security-groups in tenancy

Benutzer daran hindern, eine externe Verbindung zum Internet herzustellen

In einigen Fällen müssen Sie möglicherweise verhindern, dass Benutzer eine externe Internetverbindung mit ihrem VCN erstellen. In der folgenden Beispiel-Policy kann die Gruppe NetworkUsers kein Internetgateway erstellen.

Allow group NetworkUsers to manage internet-gateways in tenancy
 where request.permission!='INTERNET_GATEWAY_CREATE'

Benutzer daran hindern, DNS-Datensätze und -Zonen zu aktualisieren

In der folgenden Beispiel-Policy kann die Gruppe NetworkUsers keine DNS-Zonen und -Datensätze löschen und aktualisieren

Allow group NetworkUsers to manage dns-records in tenancy
 where all {request.permission!='DNS_RECORD_DELETE', 
            request.permission!='DNS_RECORD_UPDATE'} 
Allow group NetworkUsers to manage dns-zones in tenancy
 where all {request.permission!='DNS_ZONE_DELETE', 
            request.permission!='DNS_ZONE_UPDATE'}

Nützliche CLI-Befehle

In allen folgenden Beispielen sind die Umgebungsvariablen $T, $C und $VCN auf die Mandanten-OCID, Compartment-OCID bzw. VCN-OCID gesetzt.

Offene Sicherheitslisten in einem VCN auflisten

# list open (0.0.0.0/0) security lists in VCN $VCN in compartment $C 
oci network security-list list -c $C --vcn-id $VCN | grep "source" | grep "\"0.0.0.0/0\""

Gateways in einem VCN auflisten

# list all internet gateways in VCN $VCN in compartment $C 
oci network internet-gateway list -c $C --vcn-id $VCN 
# list all DRGs in compartment $C 
oci network drg list -c $C 
# list all local peering gateways in vcn $VCN in compartment $C 
oci network local-peering-gateway list -c $C --vcn-id $VCN

Routentabellenregeln in einem VCN auflisten

# list route table rules in VCN $VCN in compartment $C 
oci network route-table list -c $C --vcn-id $VCN