Configurar Oracle Secure Global Desktop
Oracle Secure Global Desktop (SGD) es una solución de acceso remoto seguro para aplicaciones empresariales y escritorios alojados en la nube que se ejecutan en servidores Microsoft Windows, Linux, Solaris y mainframe.
La diferencia entre SGD y SSH o VPN es que el cliente nunca entra en la red y el administrador de SGD controla todo el acceso, incluidas las características del cliente, como copiar y pegar, imprimir o acceder a dispositivos.
Interactúa con el servicio a través de una conexión segura al navegador web y puede iniciar, suspender y reanudar aplicaciones que se ejecutan en un entorno controlado. Los datos no dejan el centro de datos ni la nube. Los dispositivos de cliente perdidos no contienen información confidencial. SGD proporciona un único punto de acceso y permite a un administrador autorizar a un usuario en cualquier momento y terminar las sesiones activas.
Arquitectura
Esta arquitectura muestra los gateways y servidores de Secure Global Desktop en su propia subred privada entre un equilibrador de carga y los servidores de aplicaciones. El único puerto expuesto a Internet es 443 (HTTPS), a través del equilibrador de carga.
Al iniciar una aplicación, Secure Global Desktop (SGD) convierte el tráfico nativo de escritorio remoto (RDP) o X11 en su propio protocolo propietario denominado protocolo de Internet adaptativo (AIP) y envía una presentación visual al cliente.
El siguiente diagrama ilustra esta arquitectura de referencia.
Descripción de la ilustración arquitectura- secure-global-desktop.png
La arquitectura tiene los siguientes componentes:
- Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y grandes distancias pueden separarlas (entre países o incluso continentes).
- Dominios de Disponibilidad
Los dominios de disponibilidad son centros de datos independientes e independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los otros dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como energía o refrigeración, o la red de dominio de disponibilidad interna. Por lo tanto, es poco probable que un fallo en un dominio de disponibilidad afecte a los otros dominios de disponibilidad de la región.
- Dominios de Fallos
Un dominio de fallo es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad tiene tres dominios de fallos con energía y hardware independientes. Cuando coloca instancias de Compute en varios dominios de fallos, las aplicaciones pueden tolerar fallos físicos del servidor, mantenimiento del sistema y muchos fallos comunes de red y energía dentro del dominio de disponibilidad.
- Red virtual en la nube (VCN) y subredes
VCN es una red definida por software que se configura en una región de Oracle Cloud Infrastructure. Las VCN se pueden segmentar en subredes, que pueden ser específicas de una región o de un dominio de disponibilidad. Las subredes específicas de cada región y de cada dominio de disponibilidad pueden coexistir en la misma VCN. Una subred puede ser pública o privada.
- Lista de seguridad
Para cada subred, puede crear reglas de seguridad que especifiquen el origen, destino y tipo de tráfico que se debe permitir dentro y fuera de la subred.
- Tabla de rutas
Las tablas de rutas virtuales contienen reglas para enrutar el tráfico de subredes a destinos fuera de VCN, normalmente a través de gateways.
- Dispositivos cliente
Una amplia gama de dispositivos cliente populares, como PC de Windows, Mac, PC de Linux y tabletas, como Apple iPad y dispositivos basados en Android. También cualquier sistema con un explorador web moderno puede utilizar el cliente HTML5.
- Equilibrador de carga
El servicio Oracle Cloud Infrastructure Load Balancing proporciona distribución automática del tráfico de un punto de entrada a varios gateways SGD a los que se puede acceder en VCN. La conexión del equilibrador de carga a los gateways SGD debe ser TCP en 443 y no HTTPS.
- Servidores de computación y aplicaciones
Los servidores de aplicaciones son los recursos de destino reales a los que SGD proporciona acceso seguro. Pueden ser cualquier cosa que proporcione acceso RDP, SSH o Telnet a los servidores SGD. Solo los servidores SGD necesitan hablar con los servidores de aplicaciones, que pueden ser puntos finales físicos o virtuales. SGD inicia las aplicaciones o entornos de escritorio en los servidores de aplicaciones.
- Servidores SGD
Los servidores gestionan la autenticación y la autorización para proporcionar el espacio de trabajo HTML a los usuarios finales. Los servidores también traducen los protocolos RDP, SSH o Telnet al protocolo de Internet adaptativo propietario de SGD (AIP) y envían tráfico al cliente a través de los gateways de SGD. Los servidores SGD también gestionan la autorización para las aplicaciones en las que un usuario tiene derecho a ejecutarse y en las que el servidor de aplicaciones. El servidor SGD almacena esta autorización en una base de datos de configuración interna.
Puede configurar varios servidores SGD en una matriz, compartiendo una sola base de datos de configuración, para aumentar la capacidad y proporcionar redundancia. Puede agregar o eliminar servidores de forma dinámica sin interrumpir el acceso del cliente.
- Gateways de SGD
Un gateway es un proxy inverso especializado que expone el servicio al mundo exterior. También proporciona enrutamiento y equilibrio de carga. El gateway es apátrida y no tiene información sobre la identidad ni la configuración de la aplicación. Es el único componente que necesita hablar con los servidores SGD. Puede configurar varios gateways para carga y redundancia.
Recomendaciones
Sus requisitos pueden diferir de la arquitectura descrita aquí. Utilice las siguientes recomendaciones como punto de partida.
- VCN
Al crear VCN, determine el número de direcciones IP que necesitan los recursos de la nube en cada subred. Mediante la notación de enrutamiento entre dominios sin clase (CIDR), especifique una máscara de subred y un rango de direcciones de red lo suficientemente grande como para las direcciones IP necesarias. Utilice un rango de direcciones que esté dentro del espacio de direcciones IP privadas estándar.
Seleccione un rango de direcciones que no se superponga con la red local, de modo que pueda configurar una conexión entre VCN y la red local, si es necesario.
Después de crear un VCN, no puede cambiar su rango de direcciones.
Cuando diseñe las subredes, tenga en cuenta sus requisitos de flujo de tráfico y seguridad. Conecte todos los recursos dentro de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
- Listas de seguridad
Utilice las listas de seguridad para definir las reglas de entrada y salida que se aplican a cada subred. Asegúrese de que se permite el tráfico a los siguientes puertos:
Puertos 443 y 5307 para el tráfico entre gateways SGD y servidores SGD.
Puertos 443 y 5427 para el tráfico entre servidores SGD y otros servidores SGD.
Puertos 22 y 3389 para el tráfico entre los servidores SGD y los servidores de cálculo o aplicación.
- Tamaño de SGD
Como regla general, una única aplicación de Windows o X11 con un tamaño de pantalla de 1920x1200 y profundidad de color de 32 bits utiliza alrededor de 1500 MB de memoria en el servidor SGD y alrededor de 80 MB en el gateway SGD. Estos valores aumentarán dependiendo del número de usuarios y del número de aplicaciones simultáneas.
Consideraciones
- Rendimiento
Los servidores SGD deben estar lo más cerca posible de los servidores de aplicaciones a los que necesitan acceder, como dominios de disponibilidad o regiones.
- Redes
Cada gateway necesita ser capaz de hablar con cada servidor SGD, y cada servidor SGD debe ser capaz de hablar con cada otro servidor SGD en la matriz. Solo el servidor SGD en el mismo dominio o región debe poder hablar con los servidores de aplicaciones en el mismo dominio o región. En este modo de operación, se asigna a los servidores SGD una ubicación en SGD que coincida con la ubicación del servidor de aplicaciones. Dependiendo de lo que desee lograr, debe bastar con una sola subred regional, si la infraestructura SGD se despliega en el mismo compartimento que los servidores de aplicaciones de destino. Si desea utilizar SGD para controlar de forma segura y sencilla el acceso a los recursos distribuidos entre compartimentos e incluso regiones, debe configurar varias subredes. En este nivel, SGD se comporta como cualquier otro producto en red. Los puertos necesarios deben estar abiertos entre la infraestructura SGD y los servidores SGD y los servidores de aplicaciones de destino.
- Seguridad
Los recursos no necesitan direcciones IP públicas y solo se puede acceder a ellos mediante SGD.
- Disponibilidad
Se recomiendan varios gateways SGD y servidores SGD para aumentar la disponibilidad.
- Costo
SGD tiene un usuario con nombre más licencia. Se requiere una licencia para cada usuario final, independientemente de cuántas veces o dónde se despliega SGD. El mismo usuario con licencia tiene derecho a acceder a SGD instalado en Oracle Cloud Infrastructure y en las instalaciones.
Desplegar
La forma más fácil de empezar con SGD es utilizar la imagen de Oracle Cloud Marketplace.
La imagen de Oracle Cloud Marketplace tiene el gateway SGD y el servidor SGD configurados en la misma instancia de Compute que una configuración compartida. Con el componente de gateway y servidor en la misma instancia, no puede formar matrices SGD. Sin embargo, puede volver a configurar la imagen de Marketplace para mantener instalado el componente de gateway o servidor y, a continuación, continuar con la configuración de una matriz.
- Vaya a Oracle Cloud Marketplace.
- Haga clic en Obtener aplicación.
- Siga las peticiones de datos en pantalla.