Configurar o Oracle Secure Global Desktop
O Oracle Secure Global Desktop (SGD) é uma solução de acesso remoto seguro para aplicativos e desktops empresariais hospedados na nuvem que são executados em servidores Microsoft Windows, Linux, Solaris e mainframe.
A diferença entre SGD e SSH ou VPN é que o cliente nunca entra na rede e o administrador do SGD controla todo o acesso, incluindo recursos do cliente, como copiar e colar, imprimir ou acesso a dispositivos.
Você interage com o serviço por meio de uma conexão segura do web browser e pode iniciar, suspender e retomar aplicativos em execução em um ambiente controlado. Os dados não saem do data center ou da nuvem. Os dispositivos cliente perdidos não contêm informações confidenciais. O SGD fornece um único ponto de acesso e permite que um administrador desautorize um usuário a qualquer momento e encerre sessões ativas.
Arquitetura
Essa arquitetura mostra os gateways e servidores do Secure Global Desktop em sua própria sub-rede privada entre um balanceador de carga e os servidores de aplicativos. A única porta exposta à Internet é 443 (HTTPS), por meio do balanceador de carga.
Quando você inicia uma aplicação, o Secure Global Desktop (SGD) converte o RDP (Remote Desktop Protocol) nativo ou o tráfego X11 em seu próprio protocolo proprietário chamado AIP (Adaptive Internet Protocol) e envia uma apresentação visual de volta ao cliente.
O diagrama a seguir ilustra essa arquitetura de referência.
Descrição da ilustração architecture-secure-global-desktop.png
A arquitetura tem os seguintes componentes:
- Região
Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, chamados domínios de disponibilidade. As regiões são independentes de outras regiões e vastas distâncias podem separá-las (entre países ou mesmo continentes).
- Domínios de disponibilidade
Os domínios de disponibilidade são data centers independentes e independentes em uma região. Os recursos físicos em cada domínio de disponibilidade são isolados dos recursos nos outros domínios de disponibilidade, o que fornece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura, como energia ou resfriamento, ou a rede de domínio de disponibilidade interna. Portanto, é improvável que uma falha em um domínio de disponibilidade afete os outros domínios de disponibilidade na região.
- Domínios com falha
Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você coloca instâncias do serviço Compute em vários domínios de falha, os aplicativos podem tolerar falhas físicas do servidor, manutenção do sistema e muitas falhas comuns de rede e energia dentro do domínio de disponibilidade.
- Rede virtual na nuvem (VCN) e sub-redes
VCN é uma rede definida por software que você configura em uma região do Oracle Cloud Infrastructure. As VCNs podem ser segmentadas em sub-redes, que podem ser específicas de uma região ou de um domínio de disponibilidade. As sub-redes específicas da região e do domínio de disponibilidade podem coexistir na mesma VCN. Uma sub-rede pode ser pública ou privada.
- Lista de segurança
Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que devem ser permitidos dentro e fora da sub-rede.
- Tabela de roteamento
As tabelas de roteamento virtuais contêm regras para rotear o tráfego de sub-redes para destinos fora da VCN, geralmente por meio de gateways.
- Dispositivos clientes
Uma ampla gama de dispositivos clientes populares, como PCs Windows, Macs, PCs Linux e tablets, como Apple iPad e dispositivos baseados em Android. Além disso, qualquer sistema com um web browser moderno pode usar o cliente HTML5.
- Balanceador de carga
O serviço Oracle Cloud Infrastructure Load Balancing fornece distribuição de tráfego automatizada de um ponto de entrada para vários gateways SGD acessíveis em sua VCN. A conexão do balanceador de carga com os gateways SGD deve ser TCP em 443 e não HTTPS.
- Servidores de computação e aplicativos
Os servidores de aplicativos são os recursos de destino reais aos quais o SGD fornece acesso seguro. Eles podem ser qualquer coisa que forneça acesso RDP, SSH ou Telnet aos servidores SGD. Somente os servidores SGD precisam falar com os servidores de aplicativos, que podem ser pontos finais físicos ou virtuais. O SGD inicia os aplicativos ou ambientes de desktop nos servidores de aplicativos.
- Servidores SGD
Os servidores lidam com autenticação e autorização para fornecer o espaço de trabalho HTML aos usuários finais. Os servidores também convertem os protocolos RDP, SSH ou Telnet no AIP (Adaptive Internet Protocol) proprietário do SGD e enviam tráfego para o cliente por meio dos gateways do SGD. Os servidores SGD também tratam da autorização para quais aplicativos um usuário tem o direito de executar e em qual servidor de aplicativos. O servidor SGD armazena esta autorização em um banco de dados de configuração interno.
Você pode configurar vários servidores SGD em um array, compartilhando um único banco de dados de configuração, para aumentar a capacidade e fornecer redundância. Você pode adicionar ou remover servidores dinamicamente sem interromper o acesso do cliente.
- Gateways SGD
Um gateway é um proxy reverso especializado que expõe o serviço ao mundo externo. Ele também fornece roteamento e balanceamento de carga. O gateway é stateless e não tem informações sobre identidade ou configuração do aplicativo. É o único componente que precisa falar com os servidores SGD. Você pode configurar vários gateways para carga e redundância.
Recomendações
Seus requisitos podem ser diferentes da arquitetura descrita aqui. Use as recomendações a seguir como ponto de partida.
- VCN
Quando você criar a VCN, determine quantos endereços IP seus recursos de nuvem em cada sub-rede exigem. Usando a notação CIDR (Classless Inter-Domain Routing), especifique uma máscara de sub-rede e uma faixa de endereços de rede que seja grande o suficiente para os endereços IP necessários. Use um intervalo de endereços que esteja dentro do espaço de endereços IP privado padrão.
Selecione um intervalo de endereços que não se sobreponha à sua rede local, para que você possa configurar uma conexão entre o VCN e a sua rede local, se necessário.
Depois de criar um VCN, você não poderá alterar seu intervalo de endereços.
Ao projetar as sub-redes, considere o fluxo de tráfego e os requisitos de segurança. Anexe todos os recursos em uma camada ou atribuição específica à mesma sub-rede, que pode servir como um limite de segurança.
- Listas de Segurança
Use listas de segurança para definir regras de entrada e saída que se aplicam a cada sub-rede. Certifique-se de que o tráfego é permitido para as seguintes portas:
Portas 443 e 5307 para tráfego entre gateways SGD e servidores SGD.
Portas 443 e 5427 para tráfego entre servidores SGD e outros servidores SGD.
Portas 22 e 3389 para tráfego entre servidores SGD e servidores de computação ou aplicativos.
- Dimensionamento SGD
Como regra geral, uma única aplicação Windows ou X11 com um tamanho de tela 1920x1200 e 32-bit de profundidade de cor usa cerca de 1500 MB de memória no servidor SGD e cerca de 80 MB no gateway SGD. Esses valores aumentarão dependendo do número de usuários e do número de aplicativos concorrentes.
Considerações
- Desempenho
Os servidores SGD devem estar localizados o mais próximo possível dos servidores de aplicativos que precisam acessar, como domínios de disponibilidade ou regiões.
- Rede
Cada gateway precisa ser capaz de conversar com cada servidor SGD, e cada servidor SGD precisa ser capaz de conversar com todos os outros servidores SGD no array. Somente o servidor SGD no mesmo domínio ou região precisa conversar com os servidores de aplicativos no mesmo domínio ou região. Neste modo de operação, os servidores SGD recebem uma localização no SGD que corresponde à localização do servidor de aplicativos. Dependendo do que você deseja realizar, uma única sub-rede regional deverá ser suficiente se a infraestrutura SGD estiver implantada no mesmo compartimento que os servidores de aplicativos de destino. Se você quiser usar o SGD para controlar com segurança e facilidade o acesso a recursos distribuídos entre compartimentos e até regiões, será necessário configurar várias sub-redes. Nesse nível, a SGD se comporta como qualquer outro produto em rede. As portas necessárias devem estar abertas entre a infraestrutura SGD e os servidores SGD e os servidores de aplicativos de destino.
- Segurança
Os recursos não precisam de endereços IP públicos e só podem ser acessados por meio do SGD.
- Disponibilidade
Vários gateways SGD e servidores SGD são recomendados para aumentar a disponibilidade.
- Custo
SGD tem uma licença de usuário mais nomeada. É necessária uma licença para cada usuário final, independentemente de quantas vezes ou onde o SGD está implantado. O mesmo usuário licenciado tem o direito de acessar o SGD instalado no Oracle Cloud Infrastructure e no local.
Implantar
A maneira mais fácil de começar com SGD é usar a imagem do Oracle Cloud Marketplace.
A imagem do Oracle Cloud Marketplace tem o gateway SGD e o servidor SGD configurados na mesma instância do serviço Compute que uma configuração co-localizada. Com o componente de gateway e servidor na mesma instância, você não pode formar arrays SGD. No entanto, você pode reconfigurar a imagem do Marketplace para manter o gateway ou o componente do servidor instalado e, em seguida, prosseguir com a configuração de um array.
- Vá para o Oracle Cloud Marketplace.
- Clique em Obter Aplicativo.
- Siga os prompts na tela.