Part 3 of the Zero Trust Packet Routing (ZPR) blog post is to explore potential use cases. As fortune would have it, ZPR came up during a spirited discussion with some security colleagues. We were discussing CIS compliance and management access to an application stack. To kick start the discussion, I used the CIS compliant Landing Zone Architecture provided by OCI. Skipping through the discussion covering segmentation, isolation, etc., our discussion finally got to the “how to” about controlling management access to an application stack. As you can see from the provided Oracle Help Center image below, there is a designated security compartment. In the example provided, Bastion instances (circled in red below) are deployed and managed within the security compartment. In this use case, we were discussing the use of remote desktop (RDP) compute instances.

The security team wanted to know if there was a way to restrict access to a remote desktop protocol (RDP) instance with identity domains and IAM policies. RDP would use Windows OS. There is no integration with Windows authentication and Identity Domains. Active Directory in combination with ZPR seemed like a great fit for the solution. ZPR was an ideal fit for RDP since ZPR does not currently support the Bastion Service.

Active Directory could be used for the OS authentication to the RDP instances. The security team could then leverage ZPR to write policy-based access of the RDP instances to the application.  

Active Directory (AD) restricts access to a Windows Server by assigning permissions to user accounts and groups. Known as Access Control Lists (ACLs). ACLs define who can access specific resources on the server. They also determine the level of access, such as read, write, or full control. The Active Directory would effectively control who can log in and what actions they can perform. The assigned group membership within the domain ensures that only authorized users can access sensitive data. It also allows them to perform administrative tasks on the server.

We will assume we have one RDP server for the application admins. There is another RDP instance for the DBA’s. The AD will ensure that the proper groups are restricted to the designated RDP server.  Now we need to look at ZPR policies that will restrict the RDP instances to their designated support tasks.

We will consider the application stack is an Oracle application for this exercise. We can venture guesses at what types of access each RDP instance might need.  For example, the application support RDP instance would need console access to Weblogic. It would also need ssh access to the web server and application server. Additionally, possibly 1521 access to the database instances is necessary as part of troubleshooting or application patching.  We will assume the database access granted to the application support team members is not elevated. It is restricted to the scope of the role (i.e. no issue granting port 1521 access to the app support RDP instance). The database support RDP instance would need ssh access to the database servers. It would also need port 1521 access for troubleshooting and database administration.

For example the policies may look like the following:

• in networks:Applications VCN allow compute:RDPApp1 endpoints to connect to compute:App1 endpoints with protocol=’tcp/7001′
• in networks:Application VCN allow compute:RDPApp1 endpoints to connect to compute:App1 endpoints with protocol=’tcp/22′
• in the networks:Applications VCN allow compute:RDPApp1 endpoints to connect to db:DB1 endpoints with protocol=’tcp/1521′
• in networks:Applications VCN allow compute:RDPDB1 endpoints to connect to db:DB1 endpoints with protocol=’tcp/22′
• in the networks:Applications VCN allow compute:RDPDB1 endpoints to connect to db:DB1 endpoints with protocol=’tcp/1521′

I did not discuss the other network controls necessary for this solution. I focused on the ZPR portion of the solution.  We would have to assume that the network team had already implemented the software defined network. The security resources would have been designated either a VCN and subnets or a singular subnet within a VCN. There is secure intranet access or VPN access to the security subnet (to get to the RDP instances securely). There is a security list allowing the traffic from the security subnet to the application subnets. The security team has the proper IAM policies to manage the resources deployed within the security compartment.   

In this use case, we have a solution that enables the security team to deploy, manage, and audit a secure application management solution for the application support personnel. They can do this without having to coordinate network changes with the network team. This applies to each new application being managed or any change to the number of RDP servers.

I assumed the RDP servers were within the same VCN for ease.  If the ZPR policies cross VCN then the policies need to reference IP addresses (i.e. in the networks:security VCN allow compute:RDPApp1 endpoints to connect to ‘10.0.1.0/24′ with protocol=’tcp/7001’). 

Below is a high-level diagram of the proposed solution:

Hopefully this blog series was helpful.  Drop a comment if you have any questions or would like to further the discussion on ZPR.