Set up Oracle Secure Global Desktop
Oracle Secure Global Desktop (SGD) is a secure remote access solution for cloud-hosted enterprise applications and desktops that run on Microsoft Windows, Linux, Solaris, and mainframe servers.
The difference between SGD and SSH or VPN is that the client never enters the network and the administrator of SGD controls all access, including client features such as copy and paste, printing or device access.
You interact with the service through a secure web browser connection and can launch, suspend, and resume applications running in a controlled environment. Data doesn’t leave the data center or the cloud. Lost client devices don’t contain any sensitive information. SGD provides a single point of access and allows an administrator to deauthorize a user at any time and terminate active sessions.
Architecture
This architecture shows the Secure Global Desktop gateways and servers in their own private subnet between a load balancer and the application servers. The only port exposed to the internet is 443 (HTTPS), through the load balancer.
When you launch an application, Secure Global Desktop (SGD) converts the native remote desktop protocol (RDP) or X11 traffic into its own proprietary protocol called Adaptive Internet Protocol (AIP) and sends a visual presentation back to the client.
The following diagram illustrates this reference architecture.
Description of the illustration architecture-secure-global-desktop.png
The architecture has the following components:
- Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you place Compute instances across multiple fault domains, applications can tolerate physical server failure, system maintenance, and many common networking and power failures inside the availability domain.
- Virtual cloud network (VCN) and subnets
A VCN is a software-defined network that you set up in an Oracle Cloud Infrastructure region. VCNs can be segmented into subnets, which can be specific to a region or to an availability domain. Both region-specific and availability domain-specific subnets can coexist in the same VCN. A subnet can be public or private.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- Route table
Virtual route tables contain rules to route traffic from subnets to destinations outside the VCN, typically through gateways.
- Client devices
A wide range of popular client devices such as Windows PCs, Macs, Linux PCs, and tablets such as Apple iPad and Android-based devices. Also any system with a modern web browser can use the HTML5 client.
- Load balancer
The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from one entry point to multiple SGD gateways reachable in your VCN. The connection from the load balancer to the SGD gateways must be TCP on 443 and not HTTPS.
- Compute and application servers
Application servers are the actual target resources that SGD provides secure access to. They can be anything that provides RDP, SSH, or Telnet access to the SGD servers. Only the SGD servers need to talk to the application servers, which can be physical or virtual end points. SGD launches the applications or desktop environments on the application servers.
- SGD servers
Servers handle authentication and authorization to provide the HTML workspace to end users. The servers also translate the RDP, SSH, or Telnet protocols into the SGD proprietary Adaptive Internet Protocol (AIP) and send traffic to the client through the SGD gateways. SGD servers also handle the authorization for which applications a user is entitled to run and on which application server. The SGD server stores this authorization in an internal configuration database.
You can configure multiple SGD servers into an array, sharing a single configuration database, to increase capacity and provide redundancy. You can add or remove servers dynamically without interrupting client access.
- SGD gateways
A gateway is a specialized reverse proxy that exposes the service to the outside world. It also provides routing and load balancing. The gateway is stateless and has no information about identity or application configuration. It’s the only component that needs to talk to the SGD servers. You can configure multiple gateways for load and redundancy.
Recommendations
Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.
- VCN
When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses. Use an address range that's within the standard private IP address space.
Select an address range that doesn’t overlap with your on-premises network, so that you can set up a connection between the VCN and your on-premises network, if necessary.
After you create a VCN, you can't change its address range.
When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.
- Security Lists
Use security lists to define ingress and egress rules that apply to each subnet. Ensure that traffic is allowed to the following ports:
Ports 443 and 5307 for traffic between SGD gateways and SGD servers.
Ports 443 and 5427 for traffic between SGD servers and other SGD servers.
Ports 22 and 3389 for traffic between SGD servers and the compute or application servers.
- SGD Sizing
As a general rule, a single Windows or X11 application with a screen size of 1920x1200 and 32-bit color depth uses around 1500 MB of memory on the SGD server and around 80 MB on the SGD gateway. These values will increase depending on the number of users and the number of concurrent applications.
Considerations
- Performance
SGD servers should be located as close as possible to the application servers they need to access, such as availability domains or regions.
- Networking
Every gateway needs to be able to talk to every SGD server, and every SGD server needs to be able to talk to every other SGD server in the array. Only the SGD server in the same domain or region needs to be able to talk to the application servers in the same domain or region. In this mode of operation, the SGD servers are assigned a location in SGD that matches the location of the application server. Depending on what you want to accomplish, a single regional subnet should suffice, if the SGD infrastructure is deployed in the same compartment as the target application servers. If you want to use SGD to securely and easily control access to resources distributed across compartments and even regions, you need to configure multiple subnets. At this level, SGD behaves as any other networked product. The necessary ports must be open between the SGD infrastructure and the SGD servers and target application servers.
- Security
Resources don’t need public IP addresses and can only be accessed through SGD.
- Availability
Multiple SGD gateways and SGD servers are recommended to increase availability.
- Cost
SGD has a named user plus license. A license is required for every end user, regardless how many times or where SGD is deployed. The same licensed user is entitled to access SGD installed in Oracle Cloud Infrastructure and on-premises.
Deploy
The easiest way to start with SGD is to use the Oracle Cloud Marketplace image.
The Oracle Cloud Marketplace image has the SGD gateway and SGD server configured on the same Compute instance as a co-located setup. With the gateway and server component on the same instance, you can’t form SGD arrays. However, you can reconfigure the Marketplace image to keep the gateway or server component installed, and then proceed with the configuration of an array.
- Go to Oracle Cloud Marketplace.
- Click Get App.
- Follow the on-screen prompts.