Arquitetura de um cluster regulado pelo AKS para PCI-DSS 3.2.1 (Parte 2 de 9)

Este artigo descreve uma arquitetura de referência para um cluster do Serviço Kubernetes do Azure (AKS) que executa uma carga de trabalho em conformidade com o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI-DSS 3.2.1). Essa arquitetura é focada na infraestrutura e não na carga de trabalho do PCI-DSS 3.2.1.

Este artigo faz parte de uma série. Leia a introdução.

As recomendações e exemplos são extraídos desta implementação de referência que acompanha o processo:

GitHub: O Cluster de Linha de Base do Serviço Kubernetes do Azure (AKS) para Cargas de Trabalho Regulamentadas demonstra a infraestrutura regulada. Esta implementação fornece um aplicativo de microsserviços. Ele está incluído para ajudá-lo a experimentar a infraestrutura e ilustrar os controles de rede e segurança. O aplicativo não representa ou implementa uma carga de trabalho PCI DSS real.

Transfira um ficheiro do Visio desta arquitetura.

Essa arquitetura de rede é baseada em uma topologia hub-spoke. A rede virtual do hub contém o firewall para controlar o tráfego de saída, o tráfego de gateway de redes locais e uma terceira rede para acesso ao cluster SRE (engenheiro de confiabilidade do site). Existem duas redes virtuais faladas. One spoke contém o cluster AKS que é um componente do ambiente de titular de cartão (CDE) e hospeda a carga de trabalho do PCI DSS. O outro spoke cria imagens de máquina virtual usadas para acesso SRE controlado ao ambiente.

Componentes

Aqui estão os principais componentes usados nesta arquitetura. Se você não estiver familiarizado com esses serviços, consulte os serviços relacionados do Azure para obter links para a documentação do produto.

Azure Firewall

A instância de firewall protege o tráfego de rede de saída. Sem essa camada de segurança, o fluxo pode se comunicar com um serviço de terceiros mal-intencionado que pode exfiltrar dados confidenciais da empresa.

Azure Bastion

A arquitetura de linha de base forneceu uma sub-rede para o Azure Bastion, mas não provisionou o recurso. Essa arquitetura adiciona o Azure Bastion na sub-rede e fornece acesso seguro a uma caixa de salto.

Azure Image Builder

Provisionado em uma rede virtual separada, ele cria imagens de VM com segurança e configuração básicas. Nessa arquitetura, ele é personalizado para criar imagens de nó seguras com ferramentas de gerenciamento, kubectlcomo a CLI do Azure e a CLI do Flux pré-instaladas.

Conjuntos de Dimensionamento de Máquina Virtual do Azure para instâncias de caixa de salto

A rede spoke tem computação adicional para uma caixa de salto. Este conjunto de escalas destina-se a ser o ponto de acesso controlado para executar ferramentas no cluster AKS, como kubectl, conforme necessário.

Gateway de Aplicativo do Azure com Firewall de Aplicativo Web (WAF) integrado

Balanceamentos de carga do Gateway de Aplicativo do Azure na Camada 7. O WAF protege o tráfego de entrada de ataques comuns de tráfego da Web. A instância tem uma configuração IP de front-end pública que recebe solicitações do usuário.

Azure Kubernetes Service (AKS)

A infraestrutura de hospedagem, que é uma parte fundamental do ambiente de dados do titular do cartão (CDE). O cluster AKS é implantado como um cluster privado. Assim, o servidor de API do Kubernetes não é exposto à Internet pública e o tráfego para o servidor de API é limitado à sua rede privada.

Tarefas ACR

Fornece uma maneira automatizada de criar e manter imagens de contêiner.

Azure Key Vault

Armazena e gerencia segredos necessários para operações de cluster, como certificados e chaves de criptografia.

Configuração do cluster

Aqui estão algumas alterações significativas da arquitetura de linha de base:

Segmentação do pool de nós

Nessa arquitetura, o cluster tem dois pools de nós de usuário e um pool de nós do sistema. A escolha de computação para os pools de nós permanece a mesma que na arquitetura de linha de base. Ao contrário da arquitetura de linha de base, cada pool de nós reside em uma sub-rede dedicada para fornecer um limite de isolamento de rede adicional entre as camadas de computação.

O PCI-DSS 3.2.1 requer o isolamento da carga de trabalho PCI de outras cargas de trabalho em termos de operações e conectividade.

• No escopo: a carga de trabalho PCI, o ambiente em que reside e as operações.

• Fora do escopo: outras cargas de trabalho que podem compartilhar serviços, mas são isoladas dos componentes no escopo.

A estratégia-chave é fornecer o nível necessário de separação. A maneira preferida é implantar componentes dentro e fora do escopo em clusters separados. A desvantagem de usar vários clusters é o custo mais alto para a infraestrutura adicional e as despesas gerais de manutenção. Essa implementação colocaliza todos os componentes em um cluster compartilhado para simplificar. Se você optar por seguir o modelo de cluster único, use uma estratégia rigorosa de segmentação em cluster. Não importa como você opte por manter a separação, esteja ciente de que, à medida que sua solução evolui, alguns componentes fora do escopo podem se tornar dentro do escopo.

Na implementação de referência, demonstramos a abordagem de cluster compartilhado implantando um aplicativo de microsserviços em um único cluster. As cargas de trabalho dentro e fora do escopo são segmentadas em dois pools de nós de usuário separados. O aplicativo tem dois conjuntos de serviços; um conjunto tem pods dentro do escopo e o outro está fora do escopo. Ambos os conjuntos estão distribuídos em dois pools de nós de usuário. Usando manchas do Kubernetes, pods dentro e fora do escopo são implantados em nós separados e nunca compartilham uma VM de nó ou o espaço IP da rede.

Controlador de entradas

A arquitetura de linha de base usou Traefik para controle de ingresso. Nesta arquitetura de referência, em vez disso, usamos o Nginx. Essa alteração ilustra que esse componente pode ser alterado com base nos requisitos de suas cargas de trabalho.

Servidor de API Kubernetes privado

A arquitetura de linha de base implantou o cluster AKS no modo público. Isso significa que toda a comunicação com o servidor de API Kubernetes gerenciado pelo AKS é feita pela Internet pública. Isto não é aceitável nesta arquitetura porque o PCI-DSS 3.2.1 proíbe a exposição pública a quaisquer componentes do sistema. Nessa arquitetura regulamentada, o cluster é implantado como um cluster privado. O tráfego de rede para o servidor de API do Kubernetes é limitado à sua rede privada. O servidor de API é exposto através de um ponto de extremidade privado na rede do cluster. A segurança é reforçada com o uso de grupos de segurança de rede e outros recursos integrados. Estes são descritos em Configuração de rede.

Segurança do pod

Ao descrever as necessidades de segurança da carga de trabalho, use configurações relevantes securityContext para seus contêineres. Isso inclui configurações básicas, como fsGroup,runAsGrouprunAsUser / e configuração allowPrivilegeEscalation como false (a menos que necessário). Seja claro sobre como definir e remover recursos do Linux e definir suas opções SELinux no seLinuxOptions.

Evite fazer referência a imagens por suas tags em seus manifestos de implantação. Em vez disso, use o ID da imagem real. Dessa forma, você pode mapear de forma confiável os resultados da verificação de contêiner com o conteúdo real em execução no cluster. Você pode impô-lo por meio da Política do Azure para que o nome da imagem inclua o padrão de ID da imagem na expressão regular permitida. Siga também estas orientações quando estiver usando a instrução Dockerfile FROM .

Configuração da rede

Os hub-spokes são todos implantados em redes virtuais separadas, cada uma em seu espaço de endereçamento privado. Por padrão, nenhum tráfego é permitido entre duas redes virtuais. Dentro da rede, a segmentação é aplicada através da criação de sub-redes.

Uma combinação de vários serviços e recursos do Azure e construções nativas do Kubernetes fornecem o nível necessário de controle. Aqui estão algumas opções usadas nesta arquitetura.

Segurança de sub-rede através de grupos de segurança de rede (NSGs)

Existem vários NSGs que controlam o fluxo de entrada e saída do cluster. Seguem-se alguns exemplos:

• Os pools de nós do cluster são colocados em sub-redes dedicadas. Para cada sub-rede, existem NSGs que bloqueiam qualquer acesso SSH às VMs do nó e permitem o tráfego da rede virtual. O tráfego dos pools de nós é restrito à rede virtual.

• Todo o tráfego de entrada da Internet é intercetado pelo Gateway de Aplicativo do Azure. Por exemplo, as regras NSG garantem que:

  • Apenas o tráfego HTTPS é permitido.
  • O tráfego do plano de controle do Azure é permitido usando marcas de serviço. Para obter mais informações, consulte Permitir acesso a alguns IPs de origem.

• Nas sub-redes que têm agentes do Registro de Contêiner do Azure, os NSGs permitem apenas o tráfego de saída necessário. Por exemplo, o tráfego é permitido para o Azure Key Vault, Microsoft Entra ID, Azure Monitor e outros serviços com os quais o registro de contêiner precisa conversar.

• A sub-rede com a caixa de salto destina-se a operações de gerenciamento. A regra NSG na sub-rede da caixa de salto só permite acesso SSH do Azure Bastion no hub e conexões de saída limitadas. As caixas de salto não têm acesso universal à Internet e são controladas na sub-rede NSG e no Firewall do Azure.

À medida que suas cargas de trabalho, agentes de segurança do sistema e outros componentes são implantados, adicione mais regras NSG que ajudam a definir o tipo de tráfego que deve ser permitido. O tráfego não deve atravessar esses limites de sub-rede. Como cada pool de nós vive em sua própria sub-rede, observe os padrões de tráfego e aplique regras mais específicas.

Segurança Pod-to-pod com políticas de rede

Esta arquitetura tenta implementar os princípios de "confiança zero" da Microsoft tanto quanto possível.

Exemplos de redes de confiança zero como um conceito são demonstrados na implementação, dentro dos namespaces fornecidos a0005-o pelo a0005-i usuário. Cada namespace de carga de trabalho deve ter uma NetworkPolicy restritiva aplicada. As definições de política dependerão dos pods em execução nesses namespaces. Certifique-se de que está a contabilizar a prontidão, vivacidade e sondas de arranque e permita métricas recolhidas pelo agente do Log Analytics. Considere a padronização de portas em suas cargas de trabalho para que você possa fornecer uma Política de Rede e uma Política do Azure consistentes para portas de contêiner permitidas.

Em certos casos, isso não é prático para a comunicação dentro do cluster. Nem todos os namespaces fornecidos pelo usuário podem usar uma rede de confiança zero (por exemplo, cluster-baseline-settings não podem usar uma).

Encriptação TLS

A arquitetura de linha de base fornece tráfego criptografado por TLS até o controlador de entrada no cluster, mas a comunicação pod-to-pod está clara. Nessa arquitetura, o TLS se estende ao tráfego de pods para pods, com validação de autoridade de certificação (CA). Esse TLS é fornecido por uma malha de serviço, que impõe conexões mTLS e verificação antes de permitir a comunicação.

A implementação usa mTLS. O suporte a mTLS pode ser implementado com ou sem uma malha de serviço. Se você usar uma malha, verifique se ela é compatível com o emissor do certificado de sua escolha. Esta implementação usa Open Service Mesh.

O controlador de entrada nesta implementação usa um certificado curinga para lidar com o tráfego padrão quando um recurso de entrada não contém um certificado específico. Isso pode ser aceitável, mas se sua política organizacional não permitir o uso de certificados curinga, talvez seja necessário ajustar o controlador de entrada para não usar um certificado curinga.

Restrições de rede do Azure Key Vault

Todos os segredos, chaves e certificados são armazenados no Cofre de Chaves do Azure. O Key Vault lida com tarefas de gerenciamento de certificados, como rotação. A comunicação com o Cofre da Chave é feita através do Azure Private Link. O registo DNS associado ao Cofre da Chave encontra-se numa zona DNS privada para que não possa ser resolvido a partir da Internet. Embora isso aumente a segurança, existem algumas restrições.

O Gateway de Aplicativo do Azure não oferece suporte ao fornecimento de certificados TLS para o ouvinte HTTP de instâncias do Cofre da Chave expostas com o Private Link. Assim, a implementação implanta o Key Vault em um modelo híbrido. Ele ainda usa o Private Link para conexões que o suportam, mas também permite acesso público para integração com o Application Gateway. Se essa abordagem híbrida não for adequada para sua implantação, mova o processo de gerenciamento de certificados para o Application Gateway. Isso adicionará sobrecarga de gerenciamento, mas a instância do Cofre da Chave será completamente isolada. Para obter informações, consulte:

• Integração do Azure Application Gateway e do Key Vault
• Crie um gateway de aplicativo com terminação TLS usando a CLI do Azure.

Proteção contra DDoS

Se você tiver redes virtuais com endereços IP públicos, habilite a Proteção de Rede DDoS do Azure. Nessa arquitetura de referência, a sub-rede que contém o Application Gateway tem um endereço IP público anexado, portanto, está no escopo da proteção contra DDoS.

A Proteção de Rede DDoS do Azure protege a infraestrutura e a carga de trabalho contra solicitações fraudulentas em massa. Essas solicitações podem causar interrupção do serviço ou mascarar outro ataque simultâneo. A Proteção de Rede DDoS do Azure tem um custo significativo e normalmente é amortizada em muitas cargas de trabalho que abrangem muitos endereços IP. Trabalhe com sua equipe de rede para coordenar a cobertura de suas cargas de trabalho.

Gestão de identidades e acessos

Defina funções e defina o controle de acesso de acordo com os requisitos da função. Mapeie funções para ações do Kubernetes com escopo tão restrito quanto prático. Evite funções que abrangem várias funções. Se várias funções forem preenchidas por uma pessoa, atribua a essa pessoa todas as funções que são relevantes para as funções de trabalho equivalentes. Portanto, mesmo que uma pessoa seja diretamente responsável pelo cluster e pela carga de trabalho, crie seus Kubernetes ClusterRolecomo se houvesse indivíduos separados. Em seguida, atribua a esse único indivíduo todas as funções relevantes.

Minimize o acesso permanente, especialmente para contas de alto impacto, como interações SRE/Ops com seu cluster. O plano de controle AKS suporta o Microsoft Entra ID Privileged Access Management (PAM) just-in-time (JIT) e as Políticas de Acesso Condicional, que fornecem camadas adicionais de validação de autenticação necessária para acesso privilegiado, com base nas regras que você cria.

Para obter mais detalhes sobre como usar o PowerShell para configurar o acesso condicional, consulte New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy e Remove-MgIdentityConditionalAccessPolicy.

Encriptação de disco

Ao projetar a criptografia para dados em repouso, considere discos de armazenamento, VMs de nó do agente AKS, outras VMs e quaisquer discos temporários e do sistema operacional.

Discos de armazenamento

Por padrão, os discos de Armazenamento do Azure são criptografados em repouso com chaves gerenciadas pela Microsoft. Se você usar discos de sistema operacional não efêmeros ou adicionar discos de dados, recomendamos que use chaves gerenciadas pelo cliente para controlar as chaves de criptografia. Criptografe fora da camada de armazenamento e grave apenas dados criptografados na mídia de armazenamento. Além disso, certifique-se de que as chaves nunca estão adjacentes à camada de armazenamento. Para obter mais informações, consulte Traga suas próprias chaves (BYOK) com discos do Azure.

Considere usar o BYOK para quaisquer outros discos que possam interagir com o cluster, como suas caixas de salto frontais do Azure Bastion. Se você escolher BYOK, a opção de SKU para VMs e disponibilidade regional será limitada porque esse recurso não é suportado em todas as SKUs ou regiões.

Hosts de VM

Recomendamos que você habilite o recurso de criptografia no host. Isso criptografará o host da VM e qualquer sistema operacional temporário ou discos de dados armazenados em cache em um host da VM. Leia mais sobre o suporte de VM para criptografia baseada em host.

Esse recurso é estendido aos dados armazenados no host da VM dos nós do agente AKS por meio do recurso de criptografia baseada em host. Semelhante ao BYOK, esse recurso pode limitar suas opções de VM SKU e região.

Você pode impor esses recursos por meio da Política do Azure.

Backups de cluster (estado e recursos)

Se sua carga de trabalho exigir armazenamento em cluster, tenha um processo robusto e seguro para backup e recuperação. Considere serviços como o Backup do Azure (para Discos do Azure e Arquivos do Azure), para backup e recuperação de qualquer PersistentVolumeClaimarquivo . Há vantagens se o sistema de backup suportar recursos nativos do Kubernetes. Você pode complementar seu método principal que reconcilia o cluster a um estado conhecido, com o sistema de backup para técnicas críticas de recuperação do sistema. Por exemplo, ele pode ajudar na deteção de desvio e catalogação de alterações de estado do sistema ao longo do tempo no nível de recursos do Kubernetes.

Os processos de backup precisam classificar os dados no backup, sejam eles provenientes do cluster ou externos ao cluster. Se os dados estiverem no escopo do PCI DSS 3.2.1, estenda seus limites de conformidade para incluir o ciclo de vida e o destino do backup, que estarão fora do cluster. Os backups podem ser um vetor de ataque. Ao projetar seu backup, considere restrições geográficas, criptografia em repouso, controles de acesso, funções e responsabilidades, auditoria, tempo de vida útil e prevenção de violação.

Espera-se que os sistemas de backup em cluster sejam executados com altos privilégios durante suas operações. Avalie o risco e o benefício de trazer um agente de backup para o cluster. A capacidade do agente se sobrepõe a outra solução de gerenciamento no cluster? Qual é o conjunto mínimo de ferramentas que você precisa para realizar essa tarefa sem expandir a superfície de ataque?

Considerações sobre a Política do Azure

Normalmente, as políticas do Azure aplicadas não têm configurações ajustadas à carga de trabalho. Na implementação, estamos aplicando os padrões restritos de segurança do pod de cluster do Kubernetes para a iniciativa de cargas de trabalho baseadas em Linux, que é uma das iniciativas de políticas integradas. Esta iniciativa não permite ajustar as configurações. Considere exportar essa iniciativa e personalizar seus valores para sua carga de trabalho específica. Você pode incluir todas as políticas do Gatekeeper deny Azure em uma iniciativa personalizada e todas as audit políticas do Azure em outra iniciativa. Isso categoriza as ações de bloqueio de políticas somente de informações.

Considere incluir os kube-system namespaces e gatekeeper-system nas políticas em suas políticas de auditoria para aumentar a visibilidade. Incluir esses namespaces em políticas de negação pode causar falha de cluster devido a uma configuração sem suporte.

Você pode impor a criptografia de dados definindo alguns alertas da Política do Azure. Por exemplo, você pode impor o BYOK com um alerta que deteta clusters que não têm diskEncryptionSetID no recurso de cluster. Outra política pode detetar se a Criptografia Baseada em Host está habilitada no agentPoolProfiles. A implementação de referência não usa nenhum disco no cluster e o disco do sistema operacional é efêmero. Ambas as políticas de exemplo estão em vigor como um lembrete do recurso de segurança. As políticas são definidas como audit, não block.

Gestão de imagens

Use imagens de base sem distribuição para suas cargas de trabalho. Com essas imagens, a área da superfície de segurança é minimizada porque imagens suplementares, como shells e gerenciadores de pacotes, são removidas. Um benefício é a redução das taxas de acerto CVE.

O Registro de Contêiner do Azure dá suporte a imagens que atendem à Especificação de Formato de Imagem da Open Container Initiative (OCI). Isso, juntamente com um controlador de admissão que suporta a validação de assinaturas, pode garantir que você esteja executando apenas imagens que assinou com suas chaves privadas. Existem soluções open-source como SSE Connaisseur ou IBM Portieris que integram esses processos.

Proteja imagens de contêiner e outros artefatos OCI porque eles contêm a propriedade intelectual da organização. Use chaves gerenciadas pelo cliente e criptografe o conteúdo de seus registros. Por padrão, os dados são criptografados em repouso com chaves gerenciadas por serviço, mas as chaves gerenciadas pelo cliente às vezes são necessárias para atender aos padrões de conformidade regulamentar. Armazene a chave em um repositório de chaves gerenciado, como o Azure Key Vault. Como você cria e possui a chave, é responsável pelas operações relacionadas ao ciclo de vida da chave, incluindo rotação e gerenciamento. Para obter mais informações, consulte Criptografar o registro usando uma chave gerenciada pelo cliente.

Acesso operacional ao Kubernetes API Server

Você pode limitar comandos executados no cluster, sem necessariamente criar um processo operacional baseado em caixas de salto. Se você tiver uma plataforma de automação de TI fechada pelo IAM, use as ações predefinidas para controlar e auditar o tipo de ações.

Agentes de construção

Os agentes de pipeline devem estar fora do escopo do cluster regulamentado porque os processos de compilação podem ser vetores de ameaça. Por exemplo, os processos de compilação geralmente funcionam com componentes não testados e não confiáveis.

Embora seja comum usar o Kubernetes como uma infraestrutura de agente de compilação elástica, não execute esse processo dentro do limite do tempo de execução da carga de trabalho regulamentada. Seus agentes de compilação não devem ter acesso direto ao cluster. Por exemplo, dê apenas aos agentes de compilação acesso de rede ao Registro de Contêiner do Azure para enviar imagens de contêiner, gráficos de leme e assim por diante. Em seguida, implante por meio do GitOps. Como prática comum, os fluxos de trabalho de compilação e liberação não devem ter acesso direto à API de cluster do Kubernetes (ou seus nós).

Operações de monitorização

Atividades em cluster

Os pods no cluster omsagent em execução são kube-system o agente de coleta do Log Analytics. Eles coletam telemetria, raspam recipientes stdout e stderr troncos e coletam métricas Prometheus. Você pode ajustar suas configurações de coleção atualizando o container-azm-ms-agentconfig.yaml arquivo ConfigMap. Nesta implementação de referência, o registro em log é habilitado em todas kube-system as suas cargas de trabalho. Por padrão, kube-system é excluído do registro. Certifique-se de que você está ajustando o processo de coleta de logs para alcançar objetivos de custo equilibrados, eficiência de SRE ao revisar logs e necessidades de conformidade.

Controlo de segurança

Use o Defender for Containers no Microsoft Defender for Cloud para exibir e corrigir recomendações de segurança e alertas de segurança em seus recursos de contêiner. Habilite os planos do Microsoft Defender à medida que se aplicam a vários componentes do ambiente de dados do titular do cartão.

Integre logs para que você possa revisar, analisar e consultar dados de forma eficiente. O Azure fornece várias opções. Você pode ativar os logs de diagnóstico do AKS e enviá-los para um espaço de trabalho do Log Analytics que faz parte do Azure Monitor. Outra opção é integrar dados em soluções de gerenciamento de eventos e informações de segurança (SIEM), como o Microsoft Sentinel.

Conforme exigido pelo padrão, todos os espaços de trabalho do Log Analytics são definidos para um período de retenção de 90 dias. Considere configurar a exportação contínua para armazenamento de longo prazo. Não armazene informações confidenciais em dados de log e certifique-se de que o acesso aos dados de log arquivados esteja sujeito aos mesmos níveis de controles de acesso que os dados de log recentes.

Para obter uma perspetiva completa, consulte o Guia de integração do Microsoft Defender for Cloud Enterprise. Este guia aborda o registro, as exportações de dados para suas soluções SIEM, a resposta a alertas e a automação do fluxo de trabalho da criação.

Serviços relacionados do Azure

Aqui estão links para a documentação de recursos de alguns componentes-chave dessa arquitetura.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Conjuntos de Dimensionamento de Máquinas Virtuais do Azure
• Gateway de Aplicativo do Azure com Firewall de Aplicativo Web (WAF) integrado
• Tarefas do Registro de Contêiner do Azure
• Azure Key Vault

Próximos passos

Instale e mantenha uma configuração de firewall para proteger os dados do titular do cartão. Não use padrões fornecidos pelo fornecedor para senhas do sistema e outros parâmetros de segurança.