[Azure Cloud Project Combat] Compliance authentication and access control: implement PCI DSS-compliant architecture design in Azure

1. The beginning is written in front

Dear blog readers and friends who are interested in cloud computing, the update of the basic part of Microsoft Azure cloud is coming to an end. From last weekend to this Wednesday, I have not updated the article. Recently, the main focus is how to update and blog In terms of content sorting, in the next short period of time, I will complete the subsequent scattered updates of the Azure foundation, which mainly includes the remaining two parts:

• Features and tools for managing and deploying Azure resources
• Monitoring tools in Azure

In the next few weeks, I will prepare the manuscripts for the remaining two articles above, and at the same time, I will update the real cases of the application of Azure cloud in the enterprise to explain from this week.

A few days ago, I talked with my friends, and I said that the time to update blog posts is very tight, but I still maintain the rhythm of updating at least one article a week. Later, I heard more than once that some bloggers directly copy other people’s materials or articles, such as from XX Copy it to XX, etc., or buy a book, and directly get the content of the book to the CSDN blog. To be honest, I am a little sad. What is sad is that the hard work of some bloggers who have always been original and worked very hard may be submerged in this big wave. On the other hand, the achievements of others are not respected, such as Most of the Azure series of articles I wrote, I can say that 99% of the pictures are drawn by myself a little bit, but some people outside the site may be crawled away by a crawler in less than 1 minute.

One million words are omitted here for your understanding.

2. Project background and introduction

This project is an Azure cloud project about the Payment Card Industry (PCI) Data Security Standard (DSS). The reason for taking this example is that on the one hand, the security standard of Microsoft Azure cloud has passed the audit of the standard, and on the other hand, it is based on The project that uses this standard as an example has also been mentioned officially by Microsoft.

Here is a brief mention of what is PCI DSS

PCI DSS is the abbreviation of Payment Card Industry Data Security Standard (Payment Card Industry Data Security Standard), usually abbreviated as PCI DSS.

PCI DSS is a set of security standards formulated by the Payment Card Industry Security Standards Council (PCI SSC), which aims to protect the security of holder information (Cardholder Data) and payment card data. The standard applies to all organizations that process, store or transmit bearer information, including merchants, payment processing service providers, banks and others involved in payment card transactions.

Presumably some students working on state-owned enterprises or banking projects should be familiar with this agreement.

This article is part of the #CloudComputingSolutions and Architecture column. Using the PCI DSS requirements as examples, we walk through each requirement and its implementation in Azure.

This article will introduce how to build a PCI DSS compliant architecture that meets the requirements of the Azure cloud platform in the PCI DSS project.

3. Azure PCI DSS project architecture and components

The configuration of the system is as follows. In fact the actual site we built had a more complex configuration, including an ExpressRoute connection to the corporate network, but the basic idea was the same.

First, the entire system is deployed in a virtual network. Viewed from front left, public endpoints are protected by Application Gateway + WAF and connected to Application Service Environment (ASE) via internal LB.

The application is deployed on ASE and stores data in a backend SQL database. Communication with the database is encrypted and secured through a virtual web service endpoint. It is connected to the corporate network via Express Route and allows communication with a specific system (system linkage partner) for system linkage. In addition, a bastion (springboard) server (Bastion) is installed for operation and management, and the access of specific terminals to the bastion server is restricted through Express Route. Logs and metrics are aggregated in Azure Monitor.

The system is deployed component by component within a subnet protected by a Network Security Group (NSG) within a virtual network. The architecture also includes Application Gateway, Azure DNS, and load balancers.

NSG only allows necessary communication between components. This separation policy is stricter than PCI DSS requirements, but we actively use it because it is easy to implement with Azure at low additional cost.

Using an Azure storage account in the solution, customers can configure the use of storage service encryption to maintain the confidentiality of data at rest. Azure stores data in three copies in the data center of the customer's choice to enhance resiliency. Geo-redundant storage ensures that data is replicated to a secondary data center hundreds of miles away, where it is stored again in triplicate to prevent data loss due to adverse events at the customer's primary data center.

Additionally, Application Insights provides real-time application performance management and analysis through Azure monitoring logs.

This architectural solution uses the following Azure services:

• App Service Environment v2
• application gateway
  • Web Application Firewall
  • Firewall Mode: Protect
  • Ruleset: OWASP 3.0
  • Listener port: 443
• Application Insights
• Azure Active Directory
• Azure Automation
• Azure DNS
• Azure Key Vault
• Azure Load Balancer
• Azure Monitor
• Azure Resource Manager
• Azure Security Center
• Azure SQL Database
• Azure Storage
• Azure virtual network
  • 16 network
  • 24 network
  • network security group
• Azure Web Apps

4. Authentication, access control

The most important difference between Azure and the traditional local security model is that the basic security is zero trust and identity-based security verification. For the zero trust model, you can refer to my previous article "Building a Security Architecture for Azure Cloud: Deep Understanding of Zero Trust Architecture ".

4.1 Three layers of defense control

In this system, Azure itself is Id Based Security, and the entire application architecture is protected by Id Based Security. Also, the basic idea is that nothing can be trusted (zero trust). The idea is not to even trust the internal network, but to authenticate and allow only predefined access.

The system adopts the same policy not only to the external direction but also to the enterprise network side, and all access to the system is protected through authentication and access control.

How are Azure resources protected? When the service is deployed on Azure, it will be configured as shown in the diagram below. The bottom layer is the Azure base layer , the middle layer is the Azure resource layer , and the top layer is the user-created application .

Commonly referred to as the infrastructure part is the bottom two layers, and the top layer is the application.

4.2 Three-tier deployment structure

In Azure, Azure AD authenticated operators perform operations on resources through Azure Resource Manager. These operations are controlled by permission judgment based on RBAC (Role-Based Access Control), and the operation history will be recorded in the Activity Log. RBAC allows you to define resource operation permissions to control access to resources. Additionally, you can perform these operations through the API and write scripts to automate the process.

What is important here is that infrastructure work such as network setup and server setup is performed based on authentication and access control. Operational history can be saved as an audit log and this can be done through automation (coding). These features help meet PCI DSS requirements .

5. Springboard machine

We have introduced a springboard server into the system to manage operational access to the corporate network. All operational operations must be authenticated and accessed through the springboard server to ensure safe access for operational administrators. It is possible to connect to the database through the bastion server if desired, but even in this case we restrict the permissions of the operators to prevent them from accessing tables and columns they should not be referencing. These permission restrictions are determined based on operational requirements. Additionally, we incorporate SQL database auditing to enable extensive auditing of operations. These measures help to meet the requirements of PCI DSS.

Here is a brief explanation of what a springboard machine is (students who already know this can skip this explanation):

A springboard machine is an intermediate server used to securely access and manage other computing devices. It is used in the network architecture as part of security measures to provide restricted access to enhance network security.

The springboard machine is usually located between the internal network and the external network, and can also be in a subnet of the internal network. It is a self-contained server that is highly secured and configured to allow access only to authorized users. Users need to connect to the springboard first, and then they can further connect to other protected servers or network devices after passing the authentication.

Springboard machine in Azure, English is: Bastion, you may also see words in other cloud vendors or documents Jump Box, which also means springboard machine.

6. Relationship with PCI DSS requirements

The equivalent of authentication and access control in PCI DSS are Requirements 7 and 8 . It requires the minimum necessary access rights, no shared accounts, personal accounts are always assigned, and ID passwords are properly managed.

The system uses Azure AD for business accounts. Meet the requirements by issuing individual accounts to everyone and using RBAC to restrict access to essentials.

Requirement 9 relates to physical access controls. No physical access is allowed in Azure, resource operations are done through the Azure REST API. APIs are subject to authentication and access control. This is an example of shared responsibility, where identity management is the responsibility of the customer and API access control is the responsibility of the cloud provider.

The requirements in Requirement 10 related to cardholder data audit log management are met by storing activity logs and operational history for the period required for auditing in the enterprise account in Log Analytics .

(The picture is PCI DSS data security standard)

7. Summary of this article ( important )

Note : The summary at the end of the article here is different from my other articles. Most of the previous articles are a summary or a review article. The summary here is based on the architecture and some best practices. Interested students should know the main points here.

In compliance with authentication, access control, etc., follow:

• Resource configuration and setup is done under AAD authentication
• Access Control (RBAC) combined with AAD authentication
• Resource operations can be done in code
• Actions are stored in Log Analytics

By adopting such a mechanism, the operational difficulty of the following items required by PCI DSS will be significantly reduced.

• Audit for unauthorized configuration changes
• Clarification of ingredient standards
• Actual execution of periodic configuration checks

Additionally, Azure resources do not have fixed default passwords and are not subject to PCI DSS Requirement 2 prohibiting the use of default passwords. This can be said to be a service design based on the latest security concept in the industry, and can easily build a PCI DSS-compliant environment.

(The picture is PCI DSS data security standard)

written at the end

This article is the first article of [Azure cloud project actual combat] PCI DSS project. It mainly explains its project architecture, especially for authentication and access control, and summarizes how to meet the requirements of PCI DSS. Imagine if you do For projects similar to PCI DSS, there must be relevant laws and regulations. When you design the cloud architecture or explain it to customers, how can you ensure that it meets the requirements? This article provides detailed answers and explanations. Readers are helpful.

[ 本文作者 ]   bluetata
[ 原文链接 ]   https://bluetata.blog.csdn.net/article/details/132068024
[ 最后更新 ]   08/02/2023 22:41
[ 版权声明 ]   如果您在非 CSDN 网站内看到这一行，
说明网络爬虫可能在本人还没有完整发布的时候就抓走了我的文章，
可能导致内容不完整，请去上述的原文链接查看原文。