Platform Architecture and Topology

The architectural diagrams provided in this article show a high-level view of the underlying infrastructure and technology stack that supports the Delinea Platform. Additionally, you can leverage this material if you are interested in allowing access to the Delinea Platform and its related services in your firewall.

We are continuously improving and optimizing our architecture to ensure that our service is scalable, secure, and efficient.

The suggested list of ports in this document shows all of the default port numbers. These default ports may differ based on your environment and your own unique requirements. In all cases, the ports and addresses listed below should be excluded from packet inspection to allow for normal service operation.

Delinea Platform: High-Level Overview

The diagram below highlights the overall architecture of the Delinea Platform.

• Shared services are foundational services that provide infrastructure and other common resources that are designed to be consumed by various applications such as authentication, notification, and audit.

• Application services are built on top of the platform shared services, and are designed to provide functionality that is unique to the application such as vaulting and remote access.

  The Delinea Platform is evolving with every new release. The overview diagram below may be forward-looking from that perspective.

The Delinea Platform leverages Imperva Cloud Web Application Firewall to help secure its edge services. If you want to apply outbound filtering, lock down access to the ingress Imperva IPs as described in Imperva Documentation.

The IP ranges from Imperva may change periodically. It is important to check frequently and stay up to date. IP ranges can also be retrieved using the Imperva API. For example:

  curl -s --data "resp_format=json" https://my.imperva.com/api/integration/v1/ips | json_pp
  { 
   "debug_info" : { 
      "id-info" : "999999" 
   }, 
   "ipRanges" : [ 
      "199.83.128.0/21", 
      "198.143.32.0/19", 
      "149.126.72.0/21", 
      "103.28.248.0/22", 
      "185.11.124.0/22", 
      "192.230.64.0/18", 
      "45.64.64.0/22", 
      "107.154.0.0/16", 
      "45.60.0.0/16", 
      "45.223.0.0/16", 
      "131.125.128.0/17" 
   ], 
   "ipv6Ranges" : [ 
      "2a02:e980::/29" 
   ], 
   "res" : 0, 
   "res_message" : "OK" 
} 

If desired, you can implement inbound filtering by restricting access to traffic originating from the Delinea Platform to the specified egress IP address ranges below:

• 4.180.243.168/29

• 13.68.202.64/29

• 20.11.207.32/29

• 20.90.1.200/29

• 23.100.88.32/29

• 23.101.212.8/29

• 40.85.216.32/29

• 40.85.241.48/29

• 40.86.243.40/29

• 51.140.10.160/29

• 51.145.8.56/29

• 65.52.165.168/29

• 74.235.247.24/29

• 104.210.77.120/29

• 104.215.150.80/29

• 108.143.39.32/29

• 137.116.238.240/29

• 172.203.27.16/29

For detailed information about the ingress and egress IP ranges used by Secret Server Cloud, see Secret Server Hybrid Multi-Tenant Cloud Architecture.

Delinea Platform Engine Management

The Delinea Platform manages and protects endpoints using small software packages called engines. Engines run as services on endpoints, facilitating downloading, installing, and running other Delinea products (called workloads).

Engines exchange data with the Delinea Platform to keep endpoints up to date and provide the latest engine and workload status.

Engine Management Architecture

The Engine Management feature provides administrators with a single interface for managing engines, which are automatically updated and maintained after installation — removing the need for the separate installers and management processes that are traditionally necessary on individual machines.

Ports and Network Communication

Port 443 (outbound only) must be open for the engine to send encrypted information to the platform through the CloudAMQP messaging service.

Outbound Message Queue - Fully Qualified Domain Names (CloudAMQP)

The following Fully Qualified Domain Names are deployed by CloudAMQP using public IP ranges of Amazon, Azure, DigitalOcean, and Google Cloud, and are used by the engine to facilitate communication with the platform through encrypted messages over the CloudAMQP messaging service.

Outbound firewall rules should include the following Fully Qualified Domain Names (selected by databoundary), rather than static IP ranges of these URLs, as these IP ranges can change.

Upstream and Downstream Communication

The Engine Management Service can manage engines on millions of endpoints per tenant. To achieve high availability and to avoid high load on a web server, the request from the engine to the server is sent only once, during engine registration. After the engine is registered, communication is carried over message queues.

Upstream communication goes from the engine to the server. Downstream communication goes from the server to the engines. Downstream communication does not have a gRPC option.

Following are some of the communications that are typically sent upstream and downstream:

• The engine can get a new configuration from the server passively. Engines that aren't active (no current workloads) can get the up-to-date configuration from the server. This reduces the load on the system.

• Engines always send their heartbeats upstream to the server.

• If the server determines an engine is out of sync, it sends a single message to the groups the engine belongs to. The engine that forced the message and all others that have the wrong group stamp will update. This strategy reduces the load on the bus, and engines eventually coalesce. If an engine stamp itself is outdated, the server sends a message on the engine topic for the engine to update.

Engine Security

Engines retrieve workloads from the Delinea Platform, which supplies securely signed packages for the engine to download.

The engine only runs workload deployment binaries that are both signed and trusted.

During deployment execution, engines maintain file integrity check for both the working and binary directories. Any unauthorized modifications to these directories render the deployment invalid and trigger its recycling. This may require downloading the deployment packages again.

Engines send heartbeats to the platform to fetch configuration updates using a stamp. This stamp verifies whether the engine configuration matches the machine's configuration. Currently, these heartbeats are dispatched every five minutes, ensuring prompt detection of any new updates.

Privileged Remote Access

Delinea Privileged Remote Access (PRA) provides seamless access to remote machines through RDP and SSH, without the need for a VPN. PRA leverages a PRA engine that runs on customer premises.

• No internet-facing ingress ports are required for the PRA Engine.

• Only TLS 1.2+ is supported.

• Outbound access on port 443 TCP from PRA Engine to the Delinea Platform through Imperva ingress.

• Internal access on port 53 TCP/UDP from PRA Engine to DNS server for name resolution of target machines.

• Internal access on port 3389 TCP from PRA Engine to Windows-based target machines for RDP access.

• Internal access on port 22 TCP from PRA Engine to Linux-based target machines for SSH access.

• Internal access on port 443 TCP from PRA Engine to Secret Server (on-premise) to enable integration with the Delinea Platform and leverage secret access. Only required if Secret Server (on-premise) is in use.

• Outbound access on port 443 TCP from the Secret Server (on-premise) to the Delinea Platform through Imperva ingress to support the integration.

• Internal access on port 445 TCP from PRA Engine to Windows-based target machines for SMB file transfers

Delinea Privileged Remote Access

Delinea Connector

The Delinea Connector enables secure communication between the Delinea Platform and AD directories. Typically, the Delinea Connector is installed on-premises and requires access to an Active Directory Domain Controller.

• No internet-facing ingress ports are required for the Connector.

• Outbound access on port 443 TCP from the Connector to the Delinea Platform through Imperva WAF.

Requests from the Delinea Platform to the Delinea Connector are made through the TCP Relay hosts. For example, such requests include querying for AD user details. All data is encrypted.

• Internal access on port 3268 TCP from Delinea Connector to AD Domain Controller for Global Catalog access

• Internal access on port 123 UDP from Delinea Connector to AD Domain Controller for time synchronization

• Internal access on port 389 TCP/UDP from Delinea Connector to AD Domain Controller for handling normal authentication queries

• Internal access on port 88 TCP from Delinea Connector to AD Domain Controller used for Kerberos authentication

• Internal access on port 135 TCP from Delinea Connector to AD Domain Controller for remote procedure call (RPC) endpoint mapping

• Internal access on port 53 TCP/UDP from Delinea Connector to DNS server for name resolution (this might be the DC itself depending on your environment)

Delinea Connector

Notification Services

The platform leverages select third-party messaging providers. This enables Delinea to deliver notifications promptly and reliably to users across various channels, including email, SMS, and phone.