Managing Administrative Access to an Azure-based Cardholder Data Environment

Managing Administrative Access to an Azure-based Cardholder Data Environment

In our last post in the Azure Secure Cloud Migration series, we reviewed how to manage internet traffic flows in your cloud environment by making use of proxies. For an overview of the blog series and a list of the topics being covered, see the introductory post, Preparing to Migrate to a Secure Cloud. We’ll resume with part 8 of the Azure Secure Cloud Migration blog series, covering considerations for securing remote access in Azure.

One of the challenges many face when designing a Payment Card Industry Data Security Standard (PCI DSS) compliant cardholder data environment (CDE) is creating secure administrative access workflows that do not increase the number of systems in scope for compliance. To learn more about ways to keep PCI scope to a minimum, see this post from the “Common Misconceptions around the Payment Card Industry Data Security Standard (PCI DSS)” blog series.

In the cloud migration this blog series focuses on, the way that we limited scope was by deploying administrative workstations residing between the internal and production (CDE) virtual networks (VNETs). Several different configurations of Windows Server 2012 R2 were deployed as administrative workstations to accommodate the administrative needs of different client work groups (e.g., developers, system administrators, QA analysts, etc.). From administrative workstations, users could remote into other production servers or complete other administrative tasks that required connectivity to production servers. By applying controls at the user, network, and logical levels, we ensured security at multiple layers.

User Controls

Multi-factor authentication (MFA) for all administrative access is a requirement of the PCI DSS. To address this, we implemented highly available Azure Multi-factor Authentication Servers in order to provide a “something you have” factor of authentication (e.g., a soft token in the form smart phone notification) when logging in. The first factor is a user’s credentials – “something you know.” The MFA servers are made highly available by placing them in the same MFA provider group upon installation, and specifying master and slave server settings within the MFA Server application.

Due to the Azure MFA server’s incompatibility with Terminal Services in Windows Server 2012 R2 (see the known issues in the Release Notes), we incorporated Remote Authentication Dial-In User Service (RADIUS) with highly available Remote Desktop Gateways (RDGs) to provide remote desktop access to administrative workstations. The RDGs are made highly available by including them in an Azure availability set, as well as placing them in a back-end pool of an Azure load-balanced set. The load-balanced set has a single Virtual IP (VIP) address that redirects requests to the back-end pool (both RDGs).

During the authentication process users submit privileged credentials to an RDG. These credentials are tied to a separate Windows domain dedicated to the CDE. After configuring Network Policy Servers (NPS), we created a “RADIUS loop” to force a second factor of authentication during the sign-on process. This trick allows for incorporation of MFA with any RADIUS-based device, as well as a straightforward approach to authentication log analysis. The steps in the above authentication process are described in the following figure:


Network Controls

By implementing the RDGs as session brokers, we created a single source — from a Network Security Group (NSG) rule perspective — that should be allowed to connect to administrative workstations. This meant that only NSG rules permitting RDGs to initiate traffic flows to administrative workstations needed to be created, rather than needing rules for each administrative user’s everyday, non-CDE workstation. This reduces NSG management overhead, as well as makes creating alerts based on log entries for RDP sessions from unauthorized IPs simple. Additionally, we used whitelist-based NSG rules to permit each role-based administrative workstation access to production member servers only when a business justification existed. The following figure outlines connections that are made:


Logical Controls

Access to administrative workstations was controlled by using certificates to publish connection files with specific gateway parameters to a permissioned file server in the internal environment. Role-Based Access Controls (RBAC) were used to restrict access to the connection files and administrative workstations. Active Directory functional security groups were created for each role-based administrative workstation. Based on a business justification, users were added to these functional groups. These functional groups were then placed in Active Directory resource groups. These resource groups were used in two places – to grant read only permission to connection files on the file server, and to scope the Connection Access Policy (CAP) in NPS. If a user was not present in a given functional security group, they would not be able to access connection file on the file server, or be able to pass the CAP during the MFA process.

In review, we implemented secure administrative access to the CDE in Azure by:

  • Deploying role-based administrative workstations that require separate administrative credentials, acting as a stepping stone to manage any resource in the CDE
  • Using RDGs, RADIUS, NPS, and Azure Multi-factor Authentication Servers to force MFA when initiating a session to an administrative workstation
  • Limiting the source addresses that are allowed to initiate a remote session with administrative workstation to those of the RDGs
  • Restricting which administrative workstations can RDP into specific member servers by using whitelist-based NSG rules
  • Using certificates to publish connection files and authenticate remote sessions
  • Using RBAC to silo access to session hosts and publishing read-only connection files
  • Sending RADIUS and Windows Event logs to a central location for review

By leveraging available Azure functionality, we were able to satisfy PCI DSS requirements and avoid the additional complexity of granting network level access for individual users or workstations. Let us know how you manage controlling administrative access to the CDE in your environment by submitting a comment.

Phone: 312-602-4000
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons