[Azure Cloud Project Combat] Autenticação de conformidade e controle de acesso: implemente o design de arquitetura compatível com PCI DSS no Azure

1. O começo está escrito na frente

Caros leitores do blog e amigos interessados ​​em computação em nuvem, a atualização da parte básica da nuvem do Microsoft Azure está chegando ao fim. Do último final de semana até esta quarta-feira, não atualizei o artigo. Recentemente, o foco principal é como atualização e blog Em termos de classificação de conteúdo, no próximo curto período de tempo, concluirei as atualizações dispersas subsequentes da fundação Azure, que incluem principalmente as duas partes restantes:

• Recursos e ferramentas para gerenciar e implantar recursos do Azure
• Ferramentas de monitoramento no Azure

Nas próximas semanas, prepararei os manuscritos dos dois artigos restantes acima e, ao mesmo tempo, atualizarei os casos reais da aplicação da nuvem Azure na empresa para explicar a partir desta semana.

Há alguns dias, conversei com meus amigos e disse que o tempo para atualizar os posts do blog é muito apertado, mas ainda mantenho o ritmo de atualizar pelo menos um artigo por semana. Mais tarde, ouvi mais de uma vez que alguns blogueiros copie diretamente materiais ou artigos de outras pessoas, como de XX Copie para XX, etc., ou compre um livro e obtenha diretamente o conteúdo do livro no blog da CSDN. Para ser sincero, estou um pouco triste. O que é triste é que o trabalho árduo de alguns blogueiros que sempre foram originais e trabalharam muito pode estar submerso nessa grande onda. Por outro lado, as conquistas de outros não são respeitadas , como A maioria dos artigos da série Azure que escrevi, posso dizer que 99% das imagens são desenhadas por mim, mas algumas pessoas fora do site podem rastejar com um rastreador em menos de 1 minuto.

Um milhão de palavras foram omitidas aqui para sua compreensão.

2. Antecedentes e introdução do projeto

Este projeto é um projeto de nuvem do Azure sobre o padrão de segurança de dados (DSS) da indústria de cartões de pagamento (PCI). O motivo para usar este exemplo é que, por um lado, o padrão de segurança da nuvem do Microsoft Azure passou na auditoria do padrão, e por outro lado, é baseado em O projeto que usa esse padrão como exemplo também foi mencionado oficialmente pela Microsoft.

Aqui está uma breve menção do que é PCI DSS

PCI DSS é a abreviatura de Payment Card Industry Data Security Standard (Padrão de Segurança de Dados da Indústria de Cartões de Pagamento), geralmente abreviado como PCI DSS.

O PCI DSS é um conjunto de padrões de segurança formulados pelo Payment Card Industry Security Standards Council (PCI SSC), que visa proteger a segurança das informações do titular (dados do titular do cartão) e dos dados do cartão de pagamento. O padrão se aplica a todas as organizações que processam, armazenam ou transmitem informações do portador, incluindo comerciantes, provedores de serviços de processamento de pagamentos, bancos e outros envolvidos em transações com cartões de pagamento.

Presumivelmente, alguns alunos que trabalham em empresas estatais ou projetos bancários devem estar familiarizados com este acordo.

Este artigo faz parte da coluna #CloudComputingSolutions and Architecture . Usando os requisitos do PCI DSS como exemplos, percorremos cada requisito e sua implementação no Azure.

Este artigo apresentará como criar uma arquitetura compatível com PCI DSS que atenda aos requisitos da plataforma de nuvem do Azure no projeto PCI DSS.

3. Arquitetura e componentes do projeto Azure PCI DSS

A configuração do sistema é a seguinte. Na verdade, o site real que construímos tinha uma configuração mais complexa, incluindo uma conexão ExpressRoute à rede corporativa, mas a ideia básica era a mesma.

Primeiro, todo o sistema é implantado em uma rede virtual. Vistos da frente à esquerda, os endpoints públicos são protegidos pelo Application Gateway + WAF e conectados ao Application Service Environment (ASE) via LB interno.

O aplicativo é implantado no ASE e armazena dados em um banco de dados SQL de back-end. A comunicação com o banco de dados é criptografada e protegida por meio de um terminal virtual de serviço da web. Está conectado à rede corporativa via Rota Expressa e permite a comunicação com um sistema específico (parceiro de vinculação de sistemas) para vinculação de sistemas. Além disso, um servidor bastion (trampolim) (Bastion) é instalado para operação e gerenciamento, e o acesso de terminais específicos ao servidor bastion é restrito através do Express Route. Logs e métricas são agregados no Azure Monitor.

O sistema é implantado componente por componente dentro de uma sub-rede protegida por um Grupo de Segurança de Rede (NSG) dentro de uma rede virtual. A arquitetura também inclui Gateway de Aplicativo, DNS do Azure e balanceadores de carga.

O NSG permite apenas a comunicação necessária entre os componentes. Essa política de separação é mais rígida do que os requisitos do PCI DSS, mas a usamos ativamente porque é fácil de implementar com o Azure com baixo custo adicional.

Usando uma conta de armazenamento do Azure na solução, os clientes podem configurar o uso da criptografia do serviço de armazenamento para manter a confidencialidade dos dados em repouso. O Azure armazena dados em três cópias no datacenter de escolha do cliente para aumentar a resiliência. O armazenamento com redundância geográfica garante que os dados sejam replicados para um data center secundário a centenas de quilômetros de distância, onde são armazenados novamente em triplicado para evitar a perda de dados devido a eventos adversos no data center principal do cliente.

Além disso, o Application Insights fornece gerenciamento e análise de desempenho de aplicativos em tempo real por meio de logs de monitoramento do Azure.

Esta solução arquitetônica usa os seguintes serviços do Azure:

• Ambiente de Serviço de Aplicativo v2
• gateway de aplicação
  • Firewall de aplicativos da Web
  • Modo de firewall: Proteger
  • Conjunto de regras: OWASP 3.0
  • Porta do ouvinte: 443
• Insights de aplicativos
• Azure Active Directory
• Automação do Azure
• DNS do Azure
• Azure Key Vault
• Balanceador de carga do Azure
• Monitor Azure
• Gerenciador de recursos do Azure
• Central de Segurança do Azure
• Banco de Dados SQL do Azure
• Armazenamento do Azure
• Rede virtual do Azure
  • 16 rede
  • 24 rede
  • grupo de segurança de rede
• Aplicativos Web do Azure

4. Autenticação, controle de acesso

A diferença mais importante entre o Azure e o modelo de segurança local tradicional é que a segurança básica é confiança zero e verificação de segurança baseada em identidade. Para o modelo de confiança zero, você pode consultar meu artigo anterior "Building a Security Architecture for Azure Cloud: Deep Compreensão da Arquitetura de Confiança Zero ”.

4.1 Três camadas de controle de defesa

Neste sistema, o próprio Azure é Id Based Security e toda a arquitetura do aplicativo é protegida por Id Based Security. Além disso, a ideia básica é que nada pode ser confiável (confiança zero). A ideia não é nem confiar na rede interna, mas autenticar e permitir apenas acessos pré-definidos.

O sistema adota a mesma política não apenas para a direção externa, mas também para o lado da rede corporativa, e todo acesso ao sistema é protegido por meio de autenticação e controle de acesso.

Como os recursos do Azure são protegidos? Quando o serviço for implantado no Azure, ele será configurado conforme mostrado no diagrama abaixo. A camada inferior é a camada base do Azure , a camada intermediária é a camada de recursos do Azure e a camada superior é o aplicativo criado pelo usuário .

Comumente chamada de parte da infraestrutura, são as duas camadas inferiores e a camada superior é o aplicativo.

4.2 Estrutura de implantação de três camadas

No Azure, os operadores autenticados do Azure AD executam operações em recursos por meio do Azure Resource Manager. Essas operações são controladas por julgamento de permissão baseado em RBAC (Role-Based Access Control), e o histórico da operação será registrado no Log de Atividades. O RBAC permite definir permissões de operação de recursos para controlar o acesso aos recursos. Além disso, você pode executar essas operações por meio da API e escrever scripts para automatizar o processo.

O que é importante aqui é que o trabalho de infraestrutura, como configuração de rede e configuração de servidor, seja executado com base na autenticação e no controle de acesso. O histórico operacional pode ser salvo como um log de auditoria e isso pode ser feito por meio de automação (codificação). Esses recursos ajudam a atender aos requisitos do PCI DSS .

5. Máquina de trampolim

Introduzimos um servidor trampolim no sistema para gerenciar o acesso operacional à rede corporativa. Todas as operações operacionais devem ser autenticadas e acessadas por meio do servidor springboard para garantir acesso seguro aos administradores operacionais. É possível conectar-se ao banco de dados através do servidor bastion, se desejado, mas mesmo neste caso, restringimos as permissões dos operadores para evitar que eles acessem tabelas e colunas às quais não deveriam estar fazendo referência. Essas restrições de permissão são determinadas com base nos requisitos operacionais. Além disso, incorporamos a auditoria de banco de dados SQL para permitir uma ampla auditoria das operações. Essas medidas ajudam a atender aos requisitos do PCI DSS.

Aqui está uma breve explicação do que é uma máquina de trampolim (alunos que já sabem disso podem pular esta explicação):

Uma máquina trampolim é um servidor intermediário usado para acessar e gerenciar com segurança outros dispositivos de computação. Ele é usado na arquitetura de rede como parte das medidas de segurança para fornecer acesso restrito para aumentar a segurança da rede.

A máquina trampolim geralmente está localizada entre a rede interna e a rede externa e também pode estar em uma sub-rede da rede interna. É um servidor independente altamente seguro e configurado para permitir o acesso apenas a usuários autorizados. Os usuários precisam se conectar primeiro ao trampolim e, em seguida, podem se conectar a outros servidores protegidos ou dispositivos de rede depois de passar pela autenticação.

Máquina de trampolim no Azure, o inglês é: Bastion, você também pode ver palavras em outros fornecedores de nuvem ou documentos Jump Box, o que também significa máquina de trampolim.

6. Relação com os requisitos do PCI DSS

O equivalente à autenticação e controle de acesso no PCI DSS são os Requisitos 7 e 8 . Requer os direitos de acesso mínimos necessários, sem contas compartilhadas, contas pessoais são sempre atribuídas e senhas de identificação são gerenciadas adequadamente.

O sistema usa o Azure AD para contas comerciais. Atenda aos requisitos emitindo contas individuais para todos e usando o RBAC para restringir o acesso ao essencial.

O requisito 9 refere-se aos controles de acesso físico. Nenhum acesso físico é permitido no Azure, as operações de recursos são feitas por meio da API REST do Azure. As APIs estão sujeitas a controles de autenticação e acesso. Este é um exemplo de responsabilidade compartilhada, onde o gerenciamento de identidade é responsabilidade do cliente e o controle de acesso à API é responsabilidade do provedor de nuvem.

Os requisitos do Requisito 10 relacionados ao gerenciamento de log de auditoria de dados do titular do cartão são atendidos armazenando logs de atividades e histórico operacional pelo período necessário para auditoria na conta corporativa em Log Analytics .

(A imagem é padrão de segurança de dados PCI DSS)

7. Resumo deste artigo ( importante )

Observação : o resumo no final do artigo aqui é diferente dos meus outros artigos. A maioria dos artigos anteriores é um resumo ou um artigo de revisão. O resumo aqui é baseado na arquitetura e em algumas práticas recomendadas. Os alunos interessados ​​devem conhecer os principais pontos aqui.

Em conformidade com autenticação, controle de acesso, etc., siga:

• A configuração e configuração de recursos são feitas sob autenticação AAD
• Controle de acesso (RBAC) combinado com autenticação AAD
• Operações de recursos podem ser feitas em código
• As ações são armazenadas no Log Analytics

Ao adotar tal mecanismo, a dificuldade operacional dos seguintes itens exigidos pelo PCI DSS será significativamente reduzida.

• Auditoria para alterações de configuração não autorizadas
• Esclarecimento dos padrões de ingredientes
• Execução real de verificações de configuração periódicas

Além disso, os recursos do Azure não têm senhas padrão fixas e não estão sujeitos ao Requisito 2 do PCI DSS que proíbe o uso de senhas padrão. Isso pode ser considerado um design de serviço baseado no mais recente conceito de segurança do setor e pode facilmente criar um ambiente compatível com PCI DSS.

(A imagem é padrão de segurança de dados PCI DSS)

escrito no final

Este artigo é o primeiro artigo do [Azure cloud project actual combat] projeto PCI DSS. Ele explica principalmente sua arquitetura de projeto, especialmente para autenticação e controle de acesso, e resume como atender aos requisitos do PCI DSS. Imagine se você fizer Para projetos semelhantes para o PCI DSS, deve haver leis e regulamentos relevantes. Ao projetar a arquitetura de nuvem ou explicá-la aos clientes, como você pode garantir que ela atenda aos requisitos? Este artigo fornece respostas e explicações detalhadas. Os leitores são úteis.

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