Platform Constructs
The following topics relate to deploying components of the solution used for multiple remote access use cases.
Table of contents
Identity Design
A User Identity is an element that contains details that identify an individual based on certain attributes, such as an email account or a phone number. The identity is authenticated by Identity Providers (IdPs), and HPE Aruba Networking SSE authorizes access to applications based on the authentication.
Use one of the following methods to integrate HPE Aruba Networking SSE and an IdP:
- Security Assertion Markup Language (SAML)
- System for Cross-domain Identity Management (SCIM).
To add a user or a group to a policy rule, add the user to the system as an identity object in the identity management screen of the Management Console.
Select the identity provider and ensure that integration is supported. Also determine and groups to pull from the identity provider for policy enforcement. HPE Aruba Networking SSE includes easy-to-use integration that support the following common identity providers:
Microsoft Entra ID
Okta
PingFederate
Google Workspace
JumpCloud.
Other SAML providers are supported.
Connector Design
Connectors provide a secure and authenticated interface between a customer’s network and the HPE Aruba Networking SSE cloud. Connectors are deployed on network segments that can access secured applications and the Atmos Cloud simultaneously.
Connectors should be located in a network that has connectivity to the applications. HPE Aruba recommends deploying the connectors inside the trusted network rather than at a DMZ. Since no inbound connection is applied to the connector, it can be considered a trusted resource.
Applications are associated with Connector Zones. It is important to associate at least one connector for each connector zone in production. This is important to ensure high availability: if a server or VM with a running connector fails, the application remains secured and accessible by at least one more running connector.
For production deployment, a minimum of two connectors per connector zone is recommended for high availability and load balancing.
HPE Aruba Networking SSE can be deployed into the cloud environment, for which an Amazon Marketplace Image (AMI) is provided, deployed with the OVA, or deployed on a customer provided Linux box.
Defining Applications
An application is a resource specified by a domain name, a local domain name, or an IP address, defined on a standard set of ports, and managed and accessed through the HPE Aruba Networking SSE Security Portal.
In essence, an application is a service that is accessed in the internal network through the HPE Aruba Networking SSE Platform.
After installing one or more Connectors that can access the address where the applications or resources reside, you can add specific applications. Each Connector can support multiple applications.
The following applications are supported by the HPE Aruba Networking SSE Platform. Certain applications also support clientless, as noted.
- Active Directory Application
- Database Server - Clientless
- Git Server - Clientless
- Network Range
- Office 365 with Conditional Access
- SSH Server - Clientless
- SSH Range
- Remote Desktop Server - Clientless
- Remote Desktop Pool - Clientless
- Salesforce
- Web Application - Clientless
Consider the applications requiring access and ensure they are supported using the desired method (agent or agentless). HPE Aruba recommends defining each application individually, by DNS name, whenever possible. When that is not feasible, use the network range method using DNS wildcards.
Defining Policies
A Policy is a collection of rules that provide specific, granular access to apps based on a range of assigned parameters. For example, access can be defined based on the requester’s destination application groups.
Atmos enforces policies continuously. When a user’s session no longer adheres to a policy rule, it is terminated immediately. Consult Continuous Policy Enforcement for more details.
Consider defining and obtaining security buy-in for policies, in business terms, before beginning a deployment
Policies define the following:
- Who can access a application
- Which applications users can access
- When users can access a application
- From where users can access an application (geo location, IP address range)
- If users are allowed to access an application based on the device posture; i.e., it is patched or it has an enabled firewall.
- The level of access that a user can have during the connection; i.e. are users allowed to perform certain actions and how often reauthentication is required.
- Whether users are explicitly blocked from accessing one or more applications.
- How users can access an application (agent or agentless).