Oracle Secure Global Desktop einrichten
Oracle Secure Global Desktop (SGD) ist eine sichere Remote-Zugriffslösung für Cloud-gehostete Enterprise-Anwendungen und Desktops, die auf Microsoft Windows, Linux, Solaris und Mainframe-Servern ausgeführt werden.
Der Unterschied zwischen SGD und SSH oder VPN besteht darin, dass der Client niemals in das Netzwerk eintritt und der Administrator von SGD den gesamten Zugriff steuert, einschließlich Client-Features wie Kopieren und Einfügen, Drucken oder Gerätezugriff.
Sie interagieren mit dem Service über eine sichere Webbrowserverbindung und können Anwendungen starten, unterbrechen und wiederaufnehmen, die in einer kontrollierten Umgebung ausgeführt werden. Daten verlassen weder das Rechenzentrum noch die Cloud. Verlorene Clientgeräte enthalten keine sensiblen Informationen. SGD bietet einen einzigen Zugriffspunkt und ermöglicht es einem Administrator, eine Autorisierung eines Benutzers jederzeit zu deaktivieren und aktive Sessions zu beenden.
Architektur
Diese Architektur zeigt die Secure Global Desktop-Gateways und -Server im eigenen privaten Subnetz zwischen einem Load Balancer und den Anwendungsservern. Der einzige Port, der dem Internet zur Verfügung gestellt wird, ist 443 (HTTPS) über den Load Balancer.
Wenn Sie eine Anwendung starten, konvertiert Secure Global Desktop (SGD) das native Remotedesktopprotokoll (RDP) oder den X11-Traffic in ein eigenes proprietäres Protokoll namens Adaptive Internet Protocol (AIP) und sendet eine visuelle Präsentation an den Client zurück.
Das folgende Diagramm veranschaulicht diese Referenzarchitektur.
Beschreibung der Abbildung architektur-sicher-global-desktop.png
Die Architektur verfügt über folgende Komponenten:
- Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Rechenzentrum (Availability-Domains) enthält. Regionen sind unabhängig von anderen Regionen, und weite Entfernungen können sie trennen (über Länder oder sogar Kontinente).
- Verfügbarkeitsdomains
Availability-Domains sind eigenständige unabhängige Rechenzentren innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain werden von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Availability-Domains teilen keine Infrastruktur wie Strom oder Kühlung oder das interne Availability-Domainnetzwerk. Ein Fehler bei einer Availability-Domain wirkt sich daher unwahrscheinlich auf die anderen Availability-Domains in der Region aus.
- Fault-Domains
Eine Faultdomain ist eine Gruppierung von Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain verfügt über drei Faultdomains mit unabhängiger Power und Hardware. Wenn Sie Compute-Instanzen über mehrere Faultdomains hinweg platzieren, können Anwendungen physischen Serverfehler, Systemwartung und viele häufige Netzwerk- und Stromausfälle innerhalb der Availability-Domain tolerieren.
- Virtuelles Cloud-Netzwerk (VCN) und Subnetze
Ein VCN ist ein softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region eingerichtet haben. VCNs können in Subnetze segmentiert werden, die für eine Region oder eine Availability-Domain spezifisch sein können. Sowohl regionsspezifische als auch verfügbarkeitsdomainspezifische Subnetze können in demselben VCN nebeneinander bestehen. Ein Subnetz kann öffentlich oder privat sein.
- Sicherheitsliste
Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die die Quelle, das Ziel und den Traffictyp angeben, die im Subnetz und außerhalb des Subnetzes zulässig sein müssen.
- Routentabelle
Virtuelle Routentabellen enthalten Regeln zur Weiterleitung des Traffics von Subnetzen an Ziele außerhalb von VCN, typischerweise über Gateways.
- Clientgeräte
Eine breite Palette beliebter Clientgeräte wie Windows-PCs, Macs, Linux-PCs und Tablets wie Apple iPad und Android-basierte Geräte. Auch jedes System mit einem modernen Webbrowser kann den HTML5-Client verwenden.
- Load Balancer
Der Oracle Cloud Infrastructure Load Balancing-Service bietet eine automatisierte Trafficverteilung von einem Einstiegspunkt zu mehreren SGD-Gateways, die in Ihrem VCN erreichbar sind. Die Verbindung vom Load Balancer zu den SGD-Gateways muss TCP auf 443 und nicht HTTPS sein.
- Compute- und Anwendungsserver
Anwendungsserver sind die eigentlichen Zielressourcen, auf die SGD sicheren Zugriff bietet. Sie können alles sein, was RDP, SSH oder Telnet Zugriff auf die SGD-Server bietet. Nur die SGD-Server müssen mit den Anwendungsservern sprechen, die physische oder virtuelle Endpunkte sein können. SGD startet die Anwendungen oder Desktop-Umgebungen auf den Anwendungsservern.
- SGD-Server
Server verarbeiten Authentifizierung und Autorisierung, um Endbenutzern den HTML-Workspace bereitzustellen. Die Server übersetzen die RDP-, SSH- oder Telnet-Protokolle auch in das SGD-proprietäre Adaptive Internet Protocol (AIP) und senden Traffic über die SGD-Gateways an den Client. SGD-Server verarbeiten auch die Autorisierung, für welche Anwendungen ein Benutzer ausgeführt werden kann und auf welchem Anwendungsserver. Der SGD-Server speichert diese Autorisierung in einer internen Konfigurationsdatenbank.
Sie können mehrere SGD-Server in einem Array konfigurieren, eine einzelne Konfigurationsdatenbank gemeinsam verwenden, um die Kapazität zu erhöhen und Redundanz bereitzustellen. Sie können Server dynamisch hinzufügen oder entfernen, ohne den Clientzugriff zu unterbrechen.
- SGD-Gateways
Ein Gateway ist ein spezialisierter Reverse Proxy, der den Service der Außenwelt aussetzt. Es bietet auch Routing und Load Balancing. Das Gateway ist zustandslos und enthält keine Informationen zur Identitäts- oder Anwendungskonfiguration. Es ist die einzige Komponente, die mit den SGD-Servern sprechen muss. Sie können mehrere Gateways für Laden und Redundanz konfigurieren.
Empfehlungen
Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.
- VCN
Legen Sie beim Erstellen des VCN fest, wie viele IP-Adressen Ihre Cloud-Ressourcen in jedem Subnetz benötigen. Geben Sie mit der Notation Classless Inter-Domain Routing (CIDR) eine Subnetzmaske und einen Netzwerkadressbereich an, der groß genug für die erforderlichen IP-Adressen ist. Verwenden Sie einen Adressbereich, der sich im standardmäßigen privaten IP-Adressraum befindet.
Wählen Sie einen Adressbereich, der sich nicht mit Ihrem On-Premise-Netzwerk überschneidet, sodass Sie gegebenenfalls eine Verbindung zwischen VCN und Ihrem On-Premise-Netzwerk einrichten können.
Nachdem Sie ein VCN erstellt haben, können Sie den Adressbereich nicht ändern.
Wenn Sie die Subnetze entwerfen, berücksichtigen Sie Ihre Verkehrsfluss- und Sicherheitsanforderungen. Ordnen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz zu, das als Sicherheitsgrenze dienen kann.
- Sicherheitslisten
Verwenden Sie Sicherheitslisten, um Ingress- und Egressregeln zu definieren, die für jedes Subnetz gelten. Stellen Sie sicher, dass Traffic für die folgenden Ports zulässig ist:
Ports 443 und 5307 für den Datenverkehr zwischen SGD-Gateways und SGD-Servern.
Ports 443 und 5427 für den Datenverkehr zwischen SGD-Servern und anderen SGD-Servern.
Ports 22 und 3389 für den Datenverkehr zwischen SGD-Servern und den Compute- oder Anwendungsservern.
- SGD-Größe
In der Regel verwendet eine einzelne Windows- oder X11-Anwendung mit einer Bildschirmgröße von 1920x1200 und 32-Bit-Farbtiefe rund 1500 MB Arbeitsspeicher auf dem SGD-Server und rund 80 MB im SGD-Gateway. Je nach Anzahl der Benutzer und Anzahl gleichzeitiger Anwendungen werden diese Werte erhöht.
Überlegungen
- Performance
SGD-Server sollten sich so nahe wie möglich an den Anwendungsservern befinden, auf die sie zugreifen müssen, wie Verfügbarkeitsdomains oder -regionen.
- Networking
Jedes Gateway muss mit jedem SGD-Server sprechen können, und jeder SGD-Server muss in der Lage sein, mit jedem anderen SGD-Server im Array zu sprechen. Nur der SGD-Server in derselben Domain oder Region muss mit den Anwendungsservern in derselben Domain oder Region sprechen können. In diesem Betriebsmodus werden den SGD-Servern ein Speicherort in SGD zugewiesen, der mit dem Speicherort des Anwendungsservers übereinstimmt. Je nachdem, was Sie erreichen möchten, sollte ein einzelnes regionales Subnetz ausreichen, wenn die SGD-Infrastruktur im selben Compartment wie die Zielanwendungsserver bereitgestellt wird. Wenn Sie SGD verwenden möchten, um den Zugriff auf Ressourcen, die über Compartments und sogar Regionen verteilt sind, sicher und einfach zu steuern, müssen Sie mehrere Subnetze konfigurieren. Auf dieser Ebene verhält sich SGD wie jedes andere vernetzte Produkt. Die erforderlichen Ports müssen zwischen der SGD-Infrastruktur und den SGD-Servern und Zielanwendungsservern offen sein.
- Sicherheit
Ressourcen benötigen keine öffentlichen IP-Adressen und können nur über SGD aufgerufen werden.
- Verfügbarkeit
Mehrere SGD-Gateways und SGD-Server werden empfohlen, um die Verfügbarkeit zu erhöhen.
- Kostenfaktor
SGD hat einen benannten Benutzer plus Lizenz. Für jeden Endbenutzer ist eine Lizenz erforderlich, unabhängig davon, wie oft oder wo SGD bereitgestellt wird. Der gleiche lizenzierte Benutzer ist berechtigt, auf SGD zuzugreifen, die in Oracle Cloud Infrastructure und On Premise installiert ist.
Bereitstellen
Am einfachsten können Sie mit SGD beginnen, indem Sie das Oracle Cloud Marketplace-Image verwenden.
Für das Oracle Cloud Marketplace-Image sind SGD-Gateway und SGD-Server auf derselben Compute-Instanz wie ein Co-Location Setup konfiguriert. Mit der Gateway- und Serverkomponente auf derselben Instanz können Sie keine SGD-Arrays bilden. Sie können das Marketplace-Image jedoch neu konfigurieren, damit das Gateway oder die Serverkomponente installiert bleibt, und dann mit der Konfiguration eines Arrays fortfahren.
- Gehen Sie zu Oracle Cloud Marketplace.
- Klicken Sie auf App abrufen.
- Befolgen Sie die Prompts auf dem Bildschirm.