Impostazione di Oracle Secure Global Desktop
Oracle Secure Global Desktop (SGD) è una soluzione di accesso remoto sicuro per applicazioni enterprise e desktop gestiti dal cloud che vengono eseguiti su server Microsoft Windows, Linux, Solaris e mainframe.
La differenza tra SGD e SSH o VPN è che il client non entra mai nella rete e l'amministratore di SGD controlla tutti gli accessi, incluse funzioni client come copia e incolla, stampa o accesso al dispositivo.
È possibile interagire con il servizio tramite una connessione sicura al browser Web e avviare, sospendere e riprendere le applicazioni in esecuzione in un ambiente controllato. I dati non lasciano il data center o il cloud. I dispositivi client persi non contengono informazioni riservate. SGD fornisce un singolo punto di accesso e consente a un amministratore di disattivare un utente in qualsiasi momento e di terminare le sessioni attive.
Architettura
Questa architettura mostra i gateway e i server Secure Global Desktop nella propria subnet privata tra un load balancer e gli Application Server. L'unica porta esposta a Internet è 443 (HTTPS), tramite il load balancer.
Quando si avvia un'applicazione, Secure Global Desktop (SGD) converte il protocollo Desktop remoto nativo (RDP) o il traffico X11 nel proprio protocollo proprietario denominato Adaptive Internet Protocol (AIP) e invia una presentazione visiva al client.
Il diagramma seguente illustra questa architettura di riferimento.
Descrizione dell'immagine architecture-secure-global-desktop.png
L'architettura ha i seguenti componenti:
- Area
Un'area Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni, e vaste distanze possono separarle (tra paesi o addirittura continenti).
- Domini di disponibilità
I domini di disponibilità sono data center indipendenti e autonomi all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità vengono isolate dalle risorse negli altri domini di disponibilità, il che fornisce la tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio l'alimentazione o il raffreddamento, o la rete di dominio di disponibilità interna. È quindi improbabile che un errore a un dominio di disponibilità influenzi gli altri domini di disponibilità nell'area.
- Domini di errore
Un dominio di errore è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità ha tre domini di guasto con alimentazione e hardware indipendenti. Quando si inseriscono istanze di calcolo in più domini di errore, le applicazioni possono tollerare errori fisici del server, la manutenzione del sistema e molti errori di rete e di alimentazione comuni all'interno del dominio di disponibilità.
- Rete cloud virtuale (VCN) e subnet
Un VCN è una rete definita dal software impostata in un'area Oracle Cloud Infrastructure. I VCN possono essere segmentati in subnet, che possono essere specifiche di un'area o di un dominio di disponibilità. Sia le subnet specifiche dell'area che quelle specifiche del dominio di disponibilità possono coesistere nello stesso VCN. Una subnet può essere pubblica o privata.
- Lista di sicurezza
Per ogni subnet è possibile creare regole di sicurezza che specifichino l'origine, la destinazione e il tipo di traffico che devono essere consentiti all'interno e all'esterno della subnet.
- Tabella instradamento
Le tabelle di instradamento virtuale contengono regole per instradare il traffico dalle subnet alle destinazioni al di fuori di VCN, in genere tramite gateway.
- Dispositivi client
Una vasta gamma di dispositivi client popolari come PC Windows, Mac, PC Linux e tablet come Apple iPad e dispositivi basati su Android. Anche qualsiasi sistema con un browser Web moderno può utilizzare il client HTML5.
- Load balancer
Il servizio Oracle Cloud Infrastructure Load Balancing fornisce la distribuzione automatica del traffico da un punto di accesso a più gateway SGD raggiungibili in VCN. La connessione dal load balancer ai gateway SGD deve essere TCP su 443 e non HTTPS.
- Server di calcolo e applicazioni
I server applicazioni sono le risorse di destinazione effettive a cui SGD fornisce l'accesso sicuro. Possono essere qualsiasi cosa che fornisca accesso RDP, SSH o Telnet ai server SGD. Solo i server SGD devono parlare con gli Application Server, che possono essere endpoint fisici o virtuali. SGD avvia le applicazioni o gli ambienti desktop sui server applicazioni.
- Server SGD
I server gestiscono l'autenticazione e l'autorizzazione per fornire l'area di lavoro HTML agli utenti finali. I server traducono anche i protocolli RDP, SSH o Telnet nel protocollo Internet adattabile proprietario SGD (AIP) e inviano traffico al client attraverso i gateway SGD. I server SGD gestiscono anche l'autorizzazione per cui un utente ha il diritto di eseguire le applicazioni e su quale server applicazioni. Il server SGD memorizza questa autorizzazione in un database di configurazione interno.
È possibile configurare più server SGD in un array, condividendo un singolo database di configurazione, per aumentare la capacità e fornire ridondanza. È possibile aggiungere o rimuovere i server in modo dinamico senza interrompere l'accesso client.
- Gateway SGD
Un gateway è un proxy inverso specializzato che espone il servizio al mondo esterno. Fornisce anche instradamento e bilanciamento del carico. Il gateway è senza conservazione dello stato e non contiene informazioni sull'identità o sulla configurazione dell'applicazione. È l'unico componente che ha bisogno di parlare con i server SGD. È possibile configurare più gateway per carico e ridondanza.
Suggerimenti
Le vostre esigenze potrebbero differire dall'architettura descritta qui. Utilizzare i suggerimenti riportati di seguito come punto di partenza.
- VCN
Quando si crea VCN, determinare il numero di indirizzi IP necessari per le risorse cloud in ogni subnet. Utilizzando la notazione CIDR (Classless Inter-Domain Routing), specificare una maschera di sottorete e un intervallo di indirizzi di rete sufficientemente grande per gli indirizzi IP richiesti. Utilizzare un intervallo di indirizzi all'interno dello spazio degli indirizzi IP privati standard.
Selezionare un intervallo di indirizzi che non si sovrapponga alla rete in locale, in modo da poter impostare una connessione tra VCN e la rete in locale, se necessario.
Dopo aver creato un VCN, non è possibile modificarne l'intervallo di indirizzi.
Quando si progettano le subnet, prendere in considerazione il flusso di traffico e i requisiti di sicurezza. Allegare tutte le risorse all'interno di uno specifico livello o ruolo alla stessa subnet, che può fungere da limite di sicurezza.
- Elenchi sicurezza
Utilizzare gli elenchi di sicurezza per definire le regole di ingresso e uscita applicabili a ciascuna subnet. Assicurarsi che il traffico sia consentito nelle seguenti porte:
Porte 443 e 5307 per il traffico tra i gateway SGD e i server SGD.
Porte 443 e 5427 per il traffico tra server SGD e altri server SGD.
Porte 22 e 3389 per il traffico tra i server SGD e i server di calcolo o applicazioni.
- Dimensione SGD
Come regola generale, un'unica applicazione Windows o X11 con una dimensione dello schermo di 1920x1200 e una profondità di colore di 32 bit utilizza circa 1500 MB di memoria sul server SGD e circa 80 MB sul gateway SGD. Questi valori aumenteranno a seconda del numero di utenti e del numero di applicazioni concorrenti.
Considerazioni
- Prestazioni
I server SGD devono essere situati il più vicino possibile ai server applicazioni a cui devono accedere, ad esempio domini di disponibilità o aree.
- Networking
Ogni gateway deve essere in grado di parlare con ogni server SGD e ogni server SGD deve essere in grado di parlare con ogni altro server SGD nell'array. Solo il server SGD dello stesso dominio o area deve essere in grado di parlare con gli Application Server dello stesso dominio o area. In questa modalità di funzionamento, ai server SGD viene assegnata una posizione in SGD corrispondente alla posizione dell'Application Server. A seconda di ciò che si desidera eseguire, una singola subnet regionale deve essere sufficiente se l'infrastruttura SGD viene distribuita nello stesso compartimento degli Application Server di destinazione. Se si desidera utilizzare SGD per controllare in modo sicuro e semplice l'accesso alle risorse distribuite tra compartimenti e persino aree, è necessario configurare più subnet. A questo livello, SGD si comporta come qualsiasi altro prodotto in rete. Le porte necessarie devono essere aperte tra l'infrastruttura SGD e i server SGD e gli Application Server di destinazione.
- Sicurezza
Le risorse non hanno bisogno di indirizzi IP pubblici e possono essere accessibili solo tramite SGD.
- Disponibilità
Si consiglia di aumentare la disponibilità di più gateway SGD e server SGD.
- Costo
SGD ha un utente denominato più licenza. È richiesta una licenza per ogni utente finale, indipendentemente da quante volte o dove SGD viene distribuito. Lo stesso utente autorizzato ha il diritto di accedere a SGD installato in Oracle Cloud Infrastructure e on-premise.
Distribuisci
Il modo più semplice per iniziare con SGD è utilizzare l'immagine di Oracle Cloud Marketplace.
Nell'immagine di Oracle Cloud Marketplace sono configurati il gateway SGD e il server SGD sulla stessa istanza di calcolo di un'impostazione in co-localizzazione. Con il gateway e il componente server sulla stessa istanza, non è possibile formare array SGD. È tuttavia possibile riconfigurare l'immagine Marketplace per mantenere installato il gateway o il componente server, quindi procedere con la configurazione di un array.
- Andare a Oracle Cloud Marketplace.
- Fare clic su Recupera applicazione.
- Seguire i prompt sullo schermo.