Arquitetura de um cluster regulamentado do AKS para PCI-DSS 3.2.1 (Parte 2 de 9)

Este artigo descreve a arquitetura de referência para um cluster do AKS (Serviço de Kubernetes do Azure) 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 PCI-DSS 3.2.1.

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

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

GitHub: cluster de linha de base do AKS (Serviço de Kubernetes do Azure) para cargas de trabalho regulamentadas demonstra uma infraestrutura regulamentada. Essa implementação fornece um aplicativo de microsserviços. Ele está incluído para ajudar você a experimentar a infraestrutura e ilustrar os controles de rede e segurança. O aplicativo não representa nem implementa uma carga de trabalho PCI DSS real.

Baixe um Arquivo Visio dessa 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 da SRE (engenharia de confiabilidade de sites). Existem duas redes virtuais spoke. Um spoke contém o cluster do AKS que é um componente do CDE (ambiente do titular do cartão) e hospeda a carga de trabalho PCI DSS. O outro cria imagens de máquina virtual usadas para acesso do SRE controlado ao ambiente.

Componentes

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

Firewall do Azure

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 fornecia uma sub-rede para o Azure Bastion, mas não provisionava o recurso. Essa arquitetura adiciona o Azure Bastion na sub-rede e fornece acesso seguro a uma jumpbox.

Construtor de Imagens do Azure

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

Conjuntos de Dimensionamento de Máquinas Virtuais do Azure para instâncias de jump box

A rede spoke tem computação adicional para uma jump box. Esse conjunto de dimensionamento destina-se a ser o ponto de acesso controlado para executar ferramentas no cluster do AKS, como kubectl, conforme necessário.

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

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

AKS (Serviço de Kubernetes do Azure)

A infraestrutura de hospedagem, que é parte fundamental do CDE (ambiente de dados do titular do cartão). O cluster do AKS é implantado como um cluster privado. Portanto, 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 do ACR

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

Azure Key Vault

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

Configuração do cluster

Estas sã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 opção de computação para os pools de nós permanece a mesma da arquitetura de base. Diferentemente da arquitetura de base, cada pool de nós reside em uma sub-rede dedicada para fornecer um limite de isolamento de rede adicional entre 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 que são isoladas dos componentes no escopo.

A estratégia chave é fornecer o nível necessário de separação. A maneira preferencial é implantar componentes dentro e fora do escopo em clusters separados. A desvantagem de usar vários clusters são os custos mais altos para a infraestrutura adicionada e a sobrecarga de manutenção. Essa implementação coloca 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 dentro do cluster. Não importa como você opte por manter a separação, lembre-se de que, à medida que sua solução evoluir, alguns componentes fora do escopo poderão 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 no escopo 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 são distribuídos em dois pools de nós do usuário. Com o uso de taints 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 de IP da rede.

Controlador de entrada

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

Servidor de API do Kubernetes privado

A arquitetura de linha de base implantou o cluster do AKS no modo público. Isso significa que toda a comunicação com o servidor de API do Kubernetes gerenciado pelo AKS ocorre pela Internet pública. Isso não é aceitável nessa arquitetura porque o PCI-DSS 3.2.1 proíbe a exposição pública a qualquer componente 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 por meio de um ponto de extremidade privado na rede do cluster. A segurança é aprimorada ainda mais com o uso de grupos de segurança de rede e outros recursos internos. Eles são descritos na Configuração de rede.

Segurança do Pod

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

Evite referenciar imagens pelas respectivas marcas em seus manifestos de implantação. Em vez disso, use a ID da imagem real. Assim, você pode mapear de modo confiável os resultados da verificação de contêiner com o conteúdo real em execução no cluster. Você pode impor isso por meio do Azure Policy para que o nome da imagem inclua o padrão de ID de imagem na expressão regular permitida. Também siga estas diretrizes quando estiver usando a instrução Dockerfile FROM.

Configuração de rede

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

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

Segurança de sub-rede por meio de NSGs (grupos de segurança de rede)

Vários NSGs controlam o fluxo dentro e fora do cluster. Estes são alguns exemplos:

• Os pools de nós de cluster são colocados em sub-redes dedicadas. Para cada sub-rede, há NSGs que bloqueiam qualquer acesso SSH a VMs de 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 é interceptado pelo Gateway de Aplicativo do Azure. Por exemplo, as regras do NSG garantem que:

  • Somente tráfego HTTPS seja permitido.
  • O tráfego do painel de controle do Azure é permitido usando marcas de serviço. Para obter mais informações, confira 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 se comunicar.

• A sub-rede com a jump box destina-se a operações de gerenciamento. A regra NSG na sub-rede do jump box permite somente acesso SSH do Azure Bastion no hub e conexões de saída limitadas. As jump boxes não têm acesso universal à Internet e são controladas no NSG da sub-rede 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 de NSG para ajudar a definir o tipo de tráfego que deve ser permitido. O tráfego não deve percorrer esses limites de sub-rede. Como cada pool de nós reside na própria sub-rede, observe os padrões de tráfego e aplique regras mais específicas.

Segurança de pod a pod com políticas de rede

Essa arquitetura tenta implementar os princípios de "confiança zero" da Microsoft o máximo possível.

Exemplos de redes de confiança zero como conceito são demonstrados na implementação, dentro do a0005-i e a0005-o namespaces fornecidos pelo 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. Verifique se você está contabilizando a preparação, a dinâmica e as investigações de inicialização e também a tolerância para as métricas coletadas pelo agente do Log Analytics. Considere padronizar portas entre as cargas de trabalho para que você possa fornecer uma Azure Policy e NetworkPolicy consistentes para as portas de contêiner permitidas.

Em determinados 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 pode usar um).

Criptografia 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 a pod é liberada. Nesta arquitetura, o TLS se estende ao tráfego de pod a pod, com validação da Autoridade de Certificação (AC). 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 para 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 de certificado de sua escolha. Essa implementação usa a Malha Open Service.

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.

Restrições de rede do Azure Key Vault

Todos os segredos, chaves e certificados são armazenados no Azure Key Vault. O Key Vault lida com tarefas de gerenciamento de certificados, como rotação. A comunicação com o Key Vault ocorre no Link Privado do Azure. O registro DNS associado ao Key Vault está em uma zona DNS privada, de modo que não pode ser resolvido pela Internet. Embora isso aumente a segurança, há algumas restrições.

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

• Integração do Gateway de Aplicativo do Azure e do Key Vault
• Criar 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 contra DDoS do Azure. Nessa arquitetura de referência, a sub-rede que contém o Gateway de Aplicativo tem um endereço IP público anexado, portanto, está no escopo da proteção contra DDoS.

A Proteção de Rede contra 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 contra 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.

Gerenciamento de identidade e de acesso

Defina funções e 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 for prático. Evite funções que abrangem várias funções. Se várias funções forem desempenhadas por uma pessoa, atribua a essa pessoa todas as funções relevantes para as funções de trabalho equivalentes. Assim, mesmo que uma pessoa seja diretamente responsável pelo cluster e pela carga de trabalho, crie seu Kubernetes ClusterRole como se houvesse indivíduos separados. Em seguida, atribua a esse indivíduo todas as funções relevantes.

Minimize o acesso permanente, especialmente para contas de alto impacto, como interações de SRE/Ops com seu cluster. O painel de controle do AKS dá suporte ao Privileged Access Management (PAM) just-in-time (JIT) do Microsoft Entra ID e às 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, confira New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy e Remove-MgIdentityConditionalAccessPolicy.

Criptografia de disco

Quando estiver elaborando a criptografia para dados inativos, considere discos de armazenamento, VMs de nó do agente do AKS, outras VMs e 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 do 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 no meio de armazenamento. Além disso, certifique-se de que as chaves nunca sejam adjacentes à camada de armazenamento. Para obter mais informações, consulte BYOK (Bring Your Own Key) com o Serviço de Kubernetes do Azure.

Considere usar BYOK para qualquer outro disco que possa interagir com o cluster, como suas jump boxes com o Azure Bastion. Se você escolher BYOK, a opção de SKU para VMs e disponibilidade regional será limitada porque esse recurso não tem suporte 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 de VM. Leia mais sobre o suporte da VM para criptografia baseada em host.

Esse recurso é estendido para os dados armazenados no host da VM dos nós do agente do AKS por meio do recurso de Criptografia Baseada em Host. Semelhante ao BYOK, esse recurso pode limitar as opções de SKU e região de sua VM.

Você pode impor esses recursos por meio do Azure Policy.

Backups de cluster (estado e recursos)

Se a carga de trabalho exigir armazenamento no 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 PersistentVolumeClaim. Haverá vantagens se o sistema de backup der suporte a recursos nativos do Kubernetes. Você pode complementar o método primário que reconcilia o cluster com um estado conhecido, com o sistema de backup para técnicas críticas de recuperação do sistema. Por exemplo, isso pode ajudar na detecção de descompasso e na catalogação de alterações de estado do sistema ao longo do tempo no nível do recurso 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 os limites de conformidade para incluir o ciclo de vida e o destino do backup, que estará 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, vida útil e prevenção contra adulteração.

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

Considerações sobre o Azure Policy

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

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

Você pode impor a criptografia de dados definindo alguns alertas do Azure Policy. Por exemplo, você pode impor BYOK com um alerta que detecta clusters que não têm diskEncryptionSetID no recurso de cluster. Outra política pode detectar se a Criptografia Baseada em Host está habilitada em agentPoolProfiles. A implementação de referência não usa discos 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, e não block.

Gerenciamento de imagens

Use imagens 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 ocorrência de CVE.

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

Proteja imagens de contêiner e outros artefatos de OCI, pois 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 pelo serviço, mas chaves gerenciadas pelo cliente normalmente são necessárias para atender aos padrões de conformidade regulatória. Armazene a chave em um repositório de chaves gerenciadas, como o Azure Key Vault. Como cria e possui a chave, você é responsável por operações relacionadas ao ciclo de vida dela, incluindo rotação e gerenciamento. Para saber mais, confira Criptografar o registro usando uma chave gerenciada pelo cliente.

Acesso operacional do Servidor de API do Kubernetes

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

Agente de compilação

Os agentes de pipeline devem estar fora do escopo do cluster regulamentado, porque os processos de build 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 build elástico, não execute esse processo dentro do limite do runtime de carga de trabalho regulamentado. Os agentes de build não devem ter acesso direto ao cluster. Por exemplo, forneça acesso apenas à rede de agentes de build para o Registro de Contêiner do Azure para efetuar push de imagens de contêiner, gráficos de helm e assim por diante. Em seguida, implante por meio do GitOps. Como uma prática comum, fluxos de trabalho de build e lançamento não devem ter acesso direto à API de Cluster do Kubernetes (ou seus nós).

Monitoramento de operações

Atividades no cluster

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

Monitoramento de segurança

Use o Defender para Contêineres no Microsoft Defender para Nuvem para exibir e corrigir recomendações de segurança e exibir alertas de segurança em seus recursos de contêiner. Habilite os planos do Microsoft Defender, pois eles se aplicam a vários componentes do ambiente de dados do titular de cartão.

Integre logs para que você possa examinar, analisar e consultar dados com eficiência. 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 a soluções SIEM (gerenciamento de eventos e informações de segurança), como o Microsoft Sentinel.

Conforme exigido pela norma, todos os workspaces do Log Analytics são configurados com 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 veja se o acesso aos dados de log arquivados está sujeito aos mesmos níveis de controle de acesso que os dados de log recentes.

Para ter uma perspectiva completa, consulte o Guia de Integração Empresarial do Microsoft Defender para Nuvem. Este guia aborda o registro, as exportações de dados para suas soluções SIEM, a resposta a alertas e a criação de automação de fluxo de trabalho.

Serviços do Azure relacionados

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

• AKS (Serviço de Kubernetes do Azure)
• Firewall do Azure
• Azure Bastion
• Construtor de Imagens do Azure
• Conjuntos de dimensionamento de máquina virtual do Azure
• Gateway de Aplicativo do Azure com WAF (Firewall do Aplicativo Web) integrado
• Tarefas do Registro de Contêiner do Azure
• Azure Key Vault

Próximas etapas

Instalar e manter uma configuração de firewall para proteger os dados do titular do cartão. Não usar padrões de fornecedores para senhas do sistema e outros parâmetros de segurança.