Mit Bastion-Service auf Ressourcen in einem privaten Subnetz zugreifen
Oracle Cloud Infrastructure Bastion bietet privaten, zeitgebundenen SSH-Zugriff auf Ressourcen, die keine öffentlichen Endpunkte haben.
Bastionen sind Gateways oder Proxys. Sie sind logische Entitys, die sicheren Zugriff auf Ressourcen in der Cloud ermöglichen, die andernfalls nicht über das Internet zugänglich ist. Bastionen befinden sich in einem öffentlichen Subnetz und stellen die Netzwerkinfrastruktur dar, mit der ein Benutzer mit einer Ressource in einem privaten Subnetz verbunden werden kann. OCI Bastion ist ein Infrastrukturservice, der einen Bastion-Server ersetzen kann, den Sie selbst in Oracle Cloud Infrastructure (OCI) erstellen.
Durch die Integration mit Oracle Cloud Infrastructure Identity and Access Management (IAM) können Sie steuern, wer eine Bastion oder eine Session in einem Bastion-Service verwalten kann. Durch die Integration mit Oracle Cloud Infrastructure Audit können Sie administrative Aktionen im Zusammenhang mit dem Bastion-Service und Bastion-Sessions überwachen.
Architektur
Diese Architektur zeigt zwei Möglichkeiten für die Verbindung mit privaten Subnetzen: Eine Möglichkeit besteht darin, eine Verbindung über ein Zwischenzielsubnetz herzustellen, und die andere Möglichkeit besteht darin, eine direkte Verbindung mit dem Subnetz herzustellen, das die geschützten Ressourcen enthält.
Wenn Sie OCI-Bastion verwenden, können Sie eine Ausnahmeliste für ein Classless-Inter-Domain-Routing (CIDR)-Block und eine maximale Session-Time-to-Live (TTL) angeben. OCI Bastion erstellt über eine Reverse-Verbindung einen Netzwerkpfad zwischen dem Bastion-VCN und dem Kunden-VCN. Sessions werden in der Regel von Benutzern oder Operatoren erstellt.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.
Beschreibung der Abbildung architecture-use-bastion-service.png
Architektur-use-bastion-service-oracle.zip
Die Architektur umfasst folgende Komponenten:
- OCI-region
Eine OCI-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Centre enthält, das Availability-Domains hostet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.
- Availability-Domain
Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Ein Fehler in einer Availability-Domain sollte sich also nicht auf die anderen Availability-Domains in der Region auswirken.
- Faultdomain
Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain verfügt über drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen über mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverausfälle, Systemwartungen und Stromausfälle innerhalb einer Faultdomain tolerieren.
- Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein virtuelles Cloud-Netzwerk (VCN) ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer OCI-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie über VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.
- OCI Bastion
Oracle Cloud Infrastructure Bastion bietet eingeschränkten und zeitlich begrenzten sicheren Zugriff auf Ressourcen, die keine öffentlichen Endpunkte haben und strenge Ressourcenzugriffskontrollen erfordern, wie Bare-Metal- und virtuelle Maschinen, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Cloud Infrastructure Kubernetes Engine (OKE) und alle anderen Ressourcen, die den Secure Shell-Protokoll-(SSH-)Zugriff ermöglichen. Mit dem OCI Bastion-Service können Sie den Zugriff auf private Hosts aktivieren, ohne einen Jump-Host bereitzustellen und zu verwalten. Darüber hinaus erhalten Sie einen verbesserten Sicherheitsstatus mit identitätsbasierten Berechtigungen und einer zentralisierten, auditierten und zeitgebundenen SSH-Session. Mit OCI Bastion ist keine öffentliche IP für den Bastionzugriff erforderlich, sodass der Aufwand und die potenzielle Angriffsfläche bei der Bereitstellung von Remotezugriff entfallen.
- Bastionservice-Backend
Das Oracle Cloud Infrastructure Bastion-Backend speichert die Sessionkonfiguration und die SSH-Public Keys, mit denen Zugriff auf die Zielsysteme erteilt wird. Die Zielsysteme verwenden bei Bedarf das Servicegateway, um auf das OCI-Bastion-Backend zuzugreifen.
- Privater Endpunkt
Ein privater Endpunkt verbindet die OCI-Bastion mit den Zielsubnetzen. Das Zielsubnetz kann ein separates Subnetz für eine genauere Kontrolle oder in demselben Subnetz der Instanzen sein, auf die Sie zugreifen möchten.
Empfehlungen
Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.
- VCN
Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich innerhalb des standardmäßigen privaten IP-Adressraums befinden.
Wählen Sie CIDR-Blöcke aus, die sich mit keinem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, zu dem Sie private Verbindungen einrichten möchten.
Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.
Berücksichtigen Sie beim Entwerfen der Subnetze den Verkehrsfluss und die Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Tier oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.
Verwenden Sie regionale Subnetze.
Beachten Sie, dass jede bereitgestellte Bastion zwei IP-Adressen aus dem Zielsubnetz übernimmt. Wählen Sie den CIDR-Block basierend auf der Anzahl der Bastionen, die Sie für ein bestimmtes Subnetz bereitstellen möchten. Beispiel: Wenn Sie ein Subnetz mit /30-CIDR haben, bedeutet dies, dass Sie über zwei verwendbare Adressen verfügen, und wenn innerhalb dieses CIDR eine Zielressource vorhanden ist, verfügen Sie nicht über genügend Adressen, um eine Bastion bereitzustellen. In diesem Fall verläuft das Provisioning der Bastion nicht erfolgreich. Wir empfehlen, dass das Zielsubnetz breiter als /29 ist.
- Cloud Guard
Klonen und passen Sie die von Oracle bereitgestellten Standardrezepte an, um benutzerdefinierte Detektor- und Responder-Rezepte zu erstellen. Mit diesen Rezepten können Sie angeben, welche Art von Sicherheitsverletzungen eine Warnung generieren und welche Aktionen für sie ausgeführt werden dürfen. Beispiel: Sie möchten OCI Object Storage-Buckets ermitteln, deren Sichtbarkeit auf "Öffentlich" gesetzt ist.
Wenden Sie Oracle Cloud Guard auf Mandantenebene an, um den größten Umfang abzudecken und den Verwaltungsaufwand für die Verwaltung mehrerer Konfigurationen zu reduzieren.
Sie können auch das Feature "Verwaltete Liste" verwenden, um bestimmte Konfigurationen auf Detektoren anzuwenden.
- Sicherheitszonen
Für Ressourcen, die maximale Sicherheit erfordern, empfiehlt Oracle die Verwendung von Sicherheitszonen. Eine Sicherheitszone ist ein Compartment, das mit einem von Oracle definierten Rezept für Sicherheits-Policys verknüpft ist, die auf Best Practices basieren. Beispiel: Ressourcen in einer Sicherheitszone dürfen nicht über das öffentliche Internet zugänglich sein und müssen über vom Kunden verwaltete Schlüssel verschlüsselt werden. Wenn Sie Ressourcen in einer Sicherheitszone erstellen und aktualisieren, validiert OCI die Vorgänge anhand der Policys im Rezept und verhindert Vorgänge, die gegen eine der Policys verstoßen.
- OCI Bastion
Wenn Sie die Gültigkeitsdauer (Time-to-Live, TTL) auf Bastion-Ebene angeben, wird sichergestellt, dass keine der im Kontext dieser Bastion erstellten Sessions eine längere TTL als die Bastion selbst aufweist. Setzen Sie die TTL auf das Mindestlimit für Ihren Anwendungsfall. Der Mindestwert beträgt 30 Minuten und der Höchstwert 3 Stunden. Die TTL kann auch auf Session-Ebene konfiguriert werden.
Der CIDR-Block, der für eine Ausnahmeliste verwendet wird, sollte für Ihr Szenario so eng wie möglich sein. Dadurch können Sie die IP-Adressbereiche für SSH-Verbindungen einschränken, die auf die privaten Zielressourcen zugreifen können.
Berücksichtigen Sie die Größe des Zielsubnetzes, das mit OCI-Bastion verknüpft ist, und die Anzahl der gewünschten Bastioninstanzen. Jede OCI Bastion-Instanz benötigt 2 IP-Adressen. Es ist also besser, den /29-Bereich (mindestens) zu haben, damit er 6 verwendbare IP-Adressen hat. /30 hätte 2 IP-Adressen, aber wenn Sie in Zukunft möchten, dass die zweite Instanz der Bastion auf dasselbe Subnetz verweist, können Sie sie nicht erstellen. Das Zielsubnetz kann entweder das Subnetz sein, in dem sich Ihre Zielressource befindet, oder andere Subnetze im Ziel-VCN.
Empfehlungen für Sicherheits-Policys:
- Die Ingress-Regeln im Subnetz, das die Zielressourcen enthält, sollten den eingehenden TCP-Traffic von nur einer IP-Adresse zulassen, der privaten Endpunkt-IP der Bastion.
- Geben Sie den genauen Port auf einem Ziel an, z.B. 22 für Linux, 3389 für Fenster, 33060 für MySql usw. Verwenden Sie ALLE nicht für Ports.
Verwenden Sie bestimmte IAM-Policys für Admin- und Operatorszenarios.
Hinweise
- Region
Oracle Cloud Infrastructure Bastion ist ein regionaler Service. Beispiel: Sie müssen eine Bastion in der PHX-Region erstellen, um auf Ressourcen in der PHX-Region zuzugreifen. Eine Bastion innerhalb einer Region kann nicht für den Zugriff auf Ressourcen in einer anderen Region verwendet werden.
- Performance
Die Erstellung der OCI-Bastion muss innerhalb des SLO (2 Minuten nach der Anforderungserstellung) liegen. Sessionerstellung/-beendigung muss innerhalb des SLO liegen. Portweiterleitung ist 1 Minute (Bruchglas-Szenario) und verwaltete SSH-Session ist 3 Minuten (normale Nutzung).
- Sicherheit
Traffic von OCI-Bastion stammt vom privaten Endpunkt im Subnetz. Um Traffic von Bastionen zuzulassen, lassen Sie Ingress- und Egress-Traffic von diesem privaten Endpunkt zu den IPs zu, auf die mit Bastionen zugegriffen werden muss. Fein granulierte Policys, die den Zugriff auf eine Teilmenge von Instanzen einschränken, tragen dazu bei, die richtige Zugriffsebene sicherzustellen.
- Verfügbarkeit
Der Service sollte High Availability bereitstellen, um Bastionen und Sessions zu erstellen/beenden (basierend auf der API-Fehlerrate). Geplante Verfügbarkeit beträgt 99,9%.
- Kostenfaktor
Für die Verwendung von OCI Bastion fallen keine Kosten an. Sie können bis zu fünf Bastionen pro Region und Mandant erstellen. Jede Bastion bedient die Zielressourcen innerhalb eines VCN.
- Verwendungsszenarios
Wenn Sie auf private Zielhosts zugreifen möchten, auf denen native OCI-Images ausgeführt werden oder die Linux-basiert sind und den OCA v2-Agent ausführen (wobei das Bastion-Plug-in aktiviert ist), können Sie verwaltete SSH-Sessions verwenden. Wenn Sie auf private Zielressourcen zugreifen möchten, die entweder nicht den Agent ausführen, Windows-basiert sind oder Zugriff auf Datenbanken (ATP oder MySQL) benötigen, können Sie SSH-Sessions zur Portweiterleitung verwenden.