Zero Trust Network Access on Digibee Integration Platform
Understand how ZTNA works and how it is used on the Digibee Integration Platform
Zero Trust Network Access (ZTNA) is a security model based on the principle of zero trust. It provides significantly higher security and micro-segmentation by treating each user and device like their own perimeter. ZTNA also constantly checks and verifies identity and health to gain access to enterprise applications and data.
According to Gartner's “Emerging Technologies: Adoption Growth Insights for Zero Trust Network Access” report, by 2025, at least 70% of new remote access deployments will be primarily via ZTNA instead of VPN services — up from less than 10% at the end of 2021.
ZTNA integrates device compliance and health into access policies, giving you the option to exclude non-compliant, infected, or compromised systems from accessing enterprise applications and data. It also eliminates a key threat vector and reduces the risk of data theft or leakage.
ZNTA presents many benefits such as:
- Fast network configuration in minutes with remote and automated deployment;
- Flexibility to emulate Layer 2 Ethernet with multipath, multicast, and bridging capabilities;
- Security zero trust network solution that provides scalable security with 256-bit end-to-end encryption;
- Internal DNS to resolve distributed multi-network private Fully Qualified Domain Names (FQDN);
- Secure identity and authentication, based on bi-directional certificate verification;
- Least Privileged Access: replaces wide open VPNs to provide the segmentation and isolation you need;
- No more IP Address management: everything works based on the customer’s DNS, so FQDN can be used to target internal systems.
| ZTNA | VPN |
Functionality | ZTNA secures access between resources and also grants access to systems, services, and apps based on defined policies. | VPNs secure access between networks. |
Performance | Traffic goes directly to the application, which generally reduces latency; per-application basis usually means better performance. | Some performance degradation and latency is possible since all traffic is directed to the VPN concentrator instead of communicating directly, which can add latency. |
Implementation and Management | Can be implemented in phases, so the initial phase of the implementation is quick with limited (to none) disruption and further built from there. | High complexity and very dependent on infra teams. |
Adaptability to Modern Environments | ZTNA is better suited for modern environments where applications and resources are spread across multiple cloud services, as it can enforce granular access controls regardless of the resource location. | VPNs may struggle to keep up with the dynamic nature of modern IT environments, especially with the rise of cloud-based applications and services. |
Flexibility | ZTNA offers more flexibility than a traditional VPN. ZTNA solutions are cloud-based, which means they can be implemented almost anywhere with little impact on user experience. | Traditional VPNs require more manual configuration and offer less flexibility. However, cloud VPNs provide an equal level of flexibility as ZTNA, albeit with a limited featureset. |
- All communications between Edge Routers as well as communications from Edge Routers to the Network Controller are done over TLS.
- Proxies and Web Applications Firewalls should be bypassed (or an exception made) for Edge Routers to work properly.
- Deep packet inspection will also cause reachability issues with Edge Routers.
- All Edge Routers make outbound connections only, no inbound initiated traffic is required.
Inbound Requirements
Do not need any inbound ports.
Outbound Requirements
Required Ports:
- 80/TCP ⇒ toward the network controller are for the establishment of the fabric/data layer.
- 443/TCP ⇒ toward the network controller are for sessions & initial authentication.
- 6262/TCP ⇒ towards the network controller are a fabric/data layer for software maintenance.
The diagram below shows the necessary requirements to establish the connection between the Edge Router and the network controller:
.png?alt=media&token=a1dec9d6-4b6e-48ae-8289-1b8e33a65fbb)
Installation of the Edge Router is the responsibility of the customer and must be performed in the steps that meet the specifications for each particular cloud environment:
For either case, Digibee must provide the registration key for each of the Edge Routers that will be created.
Since the Edge Router will be the bridge between the Digibee side and the customer side, it is mandatory that this component can access all the resources that will be exposed. That is, if the customer needs to expose a database with FQDN prod-db.customerdomain.me, this DNS must be resolved from the Edge Router.
Sizing your Edge Router Virtual Machines (VM) correctly is essential for getting the required throughput from this component. Administrators should utilize these recommendations for allocation of CPU, RAM, and Disk Storage to allocate to VM instances running the Edge Router on the VM stack of your choice.
Check the documentation to know the specific configurations for operating Edge Routers VM according to customer environments.
Task | Digibee Responsibility | Customer Responsibility |
|---|---|---|
Edge Router Registration (2 ER’s, customer and Digibee) | ✔ | |
Edge Router Installation (Digibee Side) | ✔ | |
Edge Router Installation (Customer Side) | | ✔ |
Grant access to the Edge Router (Customer Side) to each services, endpoints, servers, etc. that will be accessed by the DGB Platform through the ZTNA tunnel | | ✔ |
Using the Chat feature in the realm, create a ticket that provides the endpoint that is to be accessed (the resource must be accessible from the customer-side Edge Router). The ticket should include a table with the actual endpoint (FQDN, and the Port). | | ✔ |
Patching security vulnerabilities manually using the “apt” command or using a tool/solution like Automox, Ivanti, or Ansible can be done during any routine customer patching window. Digibee will patch their side monthly or if a zero day is identified sooner. | ✔ | ✔ |
Black Carbon and other security tools can be used on the image, but exceptions must be made for the 3 binaries: ziti, ziti-router, and ziti-edge-tunnel | | ✔ |
Create the SERVICES related to each entry in the relationship table sent by the customer | ✔ | |
Define APPWANs to ensure that the DGB-side Edge Router can route traffic to customer SERVICES. | ✔ | |
Look at the relationship table example below supposing we need to expose two resources from customer side:
1 Database Server: my_super_critical_database.thebestcustomer.me (FQDN), PORT 3306
1 SFTP Server: my_best_sftp_server.thebestcustomer.me (FQDN). PORT 22
Real Endpoint (DNS that can be resolved client-side) | Real Port | Result after route creation (used in pipelines) | Port |
my_super_critical_database.thebestcustomer.me | 3306 | my_super_critical_database.thebestcustomer.digibee.ztn | 3306 |
my_best_sftp_server.thebestcustomer.me | 22 | my_best_sftp_server.thebestcustomer.digibee.ztn | 22 |
The columns on the tight are result of the implementation of ZTN, those routes will be accessed from the realm pipelines, and a particularity is that the used domain is digibee.ztn
- 1.
- 2.Check Firewall requirements
- 3.Check Connectivity requirements (example, by using telnet)
- 4.Configure Edge Router
- 5.Create a ticket that specifies the endpoint to be accessed.
Last modified 2d ago