Configurar a rede de um cluster regulado pelo AKS para PCI-DSS 3.2.1 (Parte 3 de 9)

Este artigo descreve as considerações de rede para um cluster do Serviço Kubernetes do Azure (AKS) configurado de acordo com o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI-DSS 3.2.1).

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

O tema principal do padrão PCI-DSS 3.2.1 é a segurança. A topologia hub-spoke é uma escolha natural para configurar um ambiente de rede regulamentado. É mais fácil criar uma infraestrutura que permita comunicações seguras. Os controles de rede são colocados em ambas as redes hub-spoke e seguem o modelo de confiança zero da Microsoft. Os controles podem ser ajustados com privilégios mínimos para proteger o tráfego, dando acesso com base na necessidade de conhecimento. Além disso, você pode aplicar várias abordagens de defesa profunda adicionando controles em cada salto e camada de rede.

Quando você hospeda uma carga de trabalho em um Kubernetes, não é suficiente confiar em construções de rede tradicionais, como regras de firewall. Há também construções nativas do Kubernetes que controlam o fluxo de tráfego dentro do cluster, como o NetworkPolicy recurso. É altamente recomendável que você consulte a documentação do Kubernetes para entender os principais conceitos sobre pods isolados e políticas de entrada e saída.

Construir e manter uma rede e sistemas seguros

Requisito 1 — Instalar e manter uma configuração de firewall para proteger os dados do titular do cartão

Suporte ao recurso AKS

O AKS suporta a implantação de um cluster em uma rede virtual privada como um cluster privado. A comunicação entre o cluster e o servidor de API Kubernetes gerenciado pelo AKS é feita por uma rede confiável. Com um cluster privado, você pode usar a Rede Virtual do Azure, o NSG (Grupo de Segurança de Rede) e outros controles de rede internos para proteger todo o ambiente de dados do titular do cartão (CDE). Esta configuração proíbe qualquer acesso público não autorizado entre a Internet e o ambiente. Para obter detalhes sobre como provisionar esse cluster, consulte Criar um cluster privado do Serviço Kubernetes do Azure.

O Firewall do Azure pode ser integrado ao AKS e pode limitar o tráfego de saída do cluster, que é um componente chave do CDE. A configuração é facilitada com uma AKS FQDN Tag. O processo recomendado é fornecido em Usar o Firewall do Azure para proteger implantações do Serviço Kubernetes do Azure (AKS).

Os clusters AKS requerem algum acesso público à Internet. Limite o tráfego de saída para a Internet usando o Firewall do Azure e NSGs na sub-rede do cluster. Para obter informações, consulte Controlar o tráfego de saída para nós de cluster no Serviço Kubernetes do Azure (AKS).

O AKS suporta opcionalmente a capacidade de definir um proxy HTTP, que pode ser utilizado para controle e monitoramento de tráfego de saída adicionais para o cluster. Os nós de cluster usam a configuração de proxy HTTP especificada para rotear o tráfego de saída. Além disso, um MutatingWebhook é registrado para injetar as informações de proxy nos pods no momento da criação, portanto, é recomendável que as cargas de trabalho possam herdar as mesmas informações de proxy. Os pods podem substituir informações de proxy, por isso é recomendável usar um proxy HTTP além de um Firewall do Azure.

Os clusters AKS devem ser criados com o plug-in NetworkPolicy. No AKS, você tem várias opções para seu plug-in de Política de Rede, incluindo Calico, Gerenciamento de Políticas de Rede do Azure e Cilium. Com a política de rede Calico, você pode usar Kubenet ou Azure CNI. Para o Gerenciamento de Política de Rede do Azure, você só pode usar o Azure CNI (não o Kubenet). Os plug-ins do Azure e do Calico Network Policy são de código aberto. Para obter mais informações sobre o Project Calico, consulte o whitepaper abrangente da solução PCI, que aborda muitos dos requisitos de firewall abaixo.

As suas responsabilidades

Necessidade	Responsabilidade
Requisito 1.1	Estabeleça e implemente padrões de configuração de firewall e roteador.
Requisito 1.2	Crie configurações de firewall e roteador que restrinjam conexões entre redes não confiáveis e quaisquer componentes do sistema no ambiente de dados do titular do cartão.
Requisito 1.3	Proibir o acesso público direto entre a Internet e qualquer componente do sistema no ambiente de dados do titular do cartão.
Requisito 1.4	Instale software de firewall pessoal ou funcionalidade equivalente em quaisquer dispositivos de computação portáteis (incluindo propriedade da empresa e/ou dos funcionários) que se conectam à Internet quando estão fora da rede (por exemplo, laptops usados por funcionários) e que também são usados para acessar o CDE.
Requisito 1.5	Certifique-se de que as políticas de segurança e os procedimentos operacionais para gerenciar firewalls estejam documentados, em uso e conhecidos por todas as partes afetadas.

Requisito 1.1

Estabeleça e implemente padrões de configuração de firewall e roteador que incluam o seguinte:

Requisito 1.1.1

Um processo formal para aprovar e testar todas as conexões de rede e alterações nas configurações de firewall e roteador.

As suas responsabilidades

Não implemente configurações manualmente, como usando o portal do Azure ou a CLI do Azure diretamente. Recomendamos o uso de Infraestrutura como Código (IaC). Com o IaC, a infraestrutura é gerenciada por meio de um modelo descritivo que usa um sistema de versionamento. O modelo IaC gera o mesmo ambiente sempre que é aplicado. Exemplos comuns de IaC são Bicep, modelos do Azure Resource Manager (modelos ARM) ou Terraform. Se o IaC não for uma opção, tenha um processo bem documentado para rastrear, implementar e implantar com segurança as alterações nas regras de firewall. Mais detalhes são fornecidos como parte do Requisito 11.2.

Você precisará usar uma combinação de vários controles de rede, incluindo o Firewall do Azure, grupos de segurança de rede (NSGs) e o recurso Kubernetes NetworkPolicy .

Minimize o número de pessoas que podem acessar e modificar controles de rede. Definir papéis e responsabilidades claras para as equipas. Por exemplo, a equipe de rede de uma organização validará as alterações de acordo com as políticas de governança definidas pelas equipes de TI. Tenha um processo de aprovação fechado que envolva pessoas e processos para aprovar alterações em qualquer configuração de rede. O processo deve incluir uma etapa para testar todos os controles de rede. Tenha documentação detalhada que descreva o processo.

Requisito 1.1.2

Diagrama de rede atual que identifica todas as conexões entre o ambiente de dados do titular do cartão e outras redes, incluindo quaisquer redes sem fio

As suas responsabilidades

Como parte da documentação, mantenha um diagrama de fluxo de rede que mostre o tráfego de entrada e saída com controles de segurança. Isso inclui o fluxo de tráfego de outras redes, incluindo qualquer rede sem fio para o CDE. O diagrama também deve mostrar fluxos dentro do cluster. Existem alguns requisitos específicos para diagramas, incluindo que eles devem mostrar sensores de intrusão e quaisquer controles aplicados.

Esta imagem mostra o diagrama de rede da implementação de referência.

Baixe um arquivo do Visio deste diagrama.

Figura 1.1.2 - Fluxo de rede

A descrição desse fluxo está nas seções a seguir.

Você pode exibir a topologia de uma rede virtual do Azure se tiver o Azure Network Watcher. Você pode exibir todos os recursos em uma rede virtual, os recursos associados a recursos em uma rede virtual e as relações entre os recursos.

Requisito 1.1.3

Diagrama atual que mostra todos os fluxos de dados do titular do cartão entre sistemas e redes.

As suas responsabilidades

Como parte da documentação, inclua um diagrama de fluxo de dados que mostre como os dados são protegidos em repouso e em trânsito.

O diagrama deve mostrar como os dados fluem de e para a carga de trabalho e quais informações são passadas de um recurso para outro. Certifique-se de que o diagrama é mantido atualizado. Adicione uma etapa como parte do processo de gerenciamento de alterações para atualizar o diagrama de fluxo de dados.

Como essa arquitetura é focada na infraestrutura e não na carga de trabalho, omitimos ilustrações aqui.

Requisito 1.1.4

Requisitos para um firewall em cada conexão com a Internet e entre qualquer zona desmilitarizada (DMZ) e a zona de rede interna.

As suas responsabilidades

Tenha uma definição clara do que define o limite de uma DMZ. Por exemplo, o ambiente de dados do titular do cartão (CDE) pode estar dentro de uma DMZ protegida por um firewall, diretivas de rede e outros controles. Para obter mais informações, consulte Cloud DMZ.

Para uma infraestrutura PCI DSS, você é responsável por proteger o CDE usando controles de rede para bloquear o acesso não autorizado dentro e fora da rede que contém o CDE. Os controles de rede devem ser configurados corretamente para uma postura de segurança forte e devem ser aplicados a:

• Comunicação entre os componentes colocalizados dentro do cluster.
• Comunicação entre a carga de trabalho e outros componentes em redes confiáveis.
• Comunicação entre a carga de trabalho e a Internet pública.

Essa arquitetura usa diferentes tecnologias de firewall para inspecionar o tráfego que flui em ambas as direções, de e para o cluster que hospeda o CDE:

• O Gateway de Aplicativo do Azure é usado como o roteador de tráfego e seu firewall de aplicativo Web integrado (WAF) é usado para proteger o tráfego de entrada (entrada) para o cluster.

• O Firewall do Azure é usado para proteger todo o tráfego de saída (saída) de qualquer rede e suas sub-redes.

  Como parte do processamento de uma transação ou operações de gerenciamento, o cluster precisará se comunicar com pontos de extremidade externos. Por exemplo, o cluster pode exigir comunicação com o plano de controle AKS, comunicação com o sistema operacional e sistemas de atualização de pacotes, e muitas cargas de trabalho interagem com APIs externas. Algumas dessas interações podem ser via HTTP e devem ser consideradas como vetores de ataque. Esses vetores são alvos de um ataque man-in-the-middle que pode resultar em exfiltração de dados. Adicionar um firewall ao tráfego de saída atenua essa ameaça.

  Recomendamos que até mesmo a comunicação pod-to-pod seja criptografada por TLS. Essa prática é mostrada na implementação de referência com o uso de autenticação TLS mútua (mTLS).

• Os NSGs são adicionados para proteger o tráfego entre o cluster e outros componentes dentro da infraestrutura. Por exemplo, na implementação de referência, há NSGs na sub-rede com pools de nós que bloqueiam quaisquer tentativas de acesso SSH. Apenas o tráfego de dentro da rede virtual é permitido.

  Ao adicionar componentes à arquitetura, considere adicionar mais NSGs que permitam ou neguem tipos de tráfego nos limites da sub-rede. Como cada pool de nós está em uma sub-rede dedicada, aplique regras mais específicas com base nos padrões de tráfego esperados de sua carga de trabalho.

• Os objetos Kubernetes NetworkPolicy são usados para controlar comunicações em cluster.

  Por padrão, não há restrições na comunicação pod-to-pod. Você precisa aplicar NetworkPolicy em comunicações em cluster, começando com uma rede de confiança zero e abrindo caminhos conforme necessário. A implementação de referência demonstra redes de confiança zero nos a0005-i namespaces e a0005-o . Todos os namespaces (exceto kube-system, gatekeeper-systeme outros namespaces fornecidos pelo AKS) têm políticas de rede restritivas aplicadas. A definição da política depende dos pods em execução nesses namespaces. Certifique-se de abrir caminhos para prontidão, vivacidade e sondas de inicialização. Além disso, abra o caminho para para que as métricas no oms-agent nível do nó possam ser enviadas. Considere padronizar portas entre as cargas de trabalho para que você possa fornecer uma Política do Azure consistente NetworkPolicy para as portas de contêiner permitidas.

Requisito 1.1.5

Descrição de grupos, funções e responsabilidades para o gerenciamento de componentes de rede.

As suas responsabilidades

Você precisará fornecer controles sobre os fluxos de rede e os componentes envolvidos. A infraestrutura resultante terá vários segmentos de rede, cada um com muitos controles, e cada controle com uma finalidade. Certifique-se de que sua documentação tenha ampla cobertura, desde o planejamento de rede até todas as configurações aplicadas. Deve também incluir pormenores sobre a apropriação, com linhas claras de responsabilidade e as funções que são responsáveis por elas.

Por exemplo, saiba quem é responsável pela governança da proteção de redes entre o Azure e a Internet. Em uma empresa, a equipe de TI geralmente é responsável pela configuração e manutenção de regras do Firewall do Azure, regras de firewall de aplicativo Web (WAF), NSGs e outro tráfego entre redes. Eles também podem ser responsáveis pela alocação de rede virtual e sub-rede em toda a empresa e pelo planejamento de endereços IP.

No nível da carga de trabalho, um operador de cluster é responsável por manter o Zero-Trust por meio de políticas de rede. Além disso, as responsabilidades podem incluir comunicação com o plano de controle do Azure, APIs do Kubernetes e tecnologias de monitoramento.

Comece sempre com uma estratégia de negar tudo. Dê permissão somente quando houver uma necessidade comercial ou uma justificativa de função.

Requisito 1.1.6

Documentação de justificação comercial e aprovação para utilização de todos os serviços, protocolos e portas permitidos, incluindo documentação dos elementos de segurança implementados para os protocolos considerados inseguros.

As suas responsabilidades

Tenha documentação detalhada que descreva os serviços, protocolos e portas usados nos controles de rede. Negar tudo, exceto as portas explicitamente permitidas. Documente a justificação comercial e os recursos de segurança documentados se o uso de protocolos inseguros não puder ser evitado. Aqui estão alguns exemplos da implementação de referência para o Firewall do Azure. As regras de firewall devem ter como escopo exclusivo os recursos relacionados. Ou seja, apenas o tráfego de fontes específicas pode ir para destinos FQDN específicos.

Aqui estão alguns exemplos em que você pode permitir o tráfego:

Regra	Protocolo:Porta	Origem	Destino	Justificação
Permita uma comunicação segura entre os nós e o plano de controle.	HTTPS:443	Intervalos de endereços IP autorizados atribuídos aos pools de nós do cluster	Lista de alvos FQDN no plano de controle AKS. Isso é especificado com a AzureKubernetesService marca FQDN.	Os nós precisam de acesso ao plano de controle para ferramentas de gerenciamento, informações de estado e configuração e informações sobre quais nós podem ser dimensionados.
Permite uma comunicação segura entre o Flux e o GitHub.	HTTPS:443	Pools de nós AKS	github.com, api.github.com	O Flux é uma integração de terceiros que é executada nos nós. Ele sincroniza a configuração do cluster com um repositório GitHub privado.

Requisito 1.1.7

Requisito para revisar os conjuntos de regras de firewall e roteador pelo menos a cada seis meses.

As suas responsabilidades

Tenha processos pelo menos a cada seis meses para revisar as configurações de rede e as regras de escopo. Isso garantirá que as garantias de segurança estejam atualizadas e válidas. Certifique-se de revisar estas configurações:

• Regras do Firewall do Azure.
• Regras do NSG.
• Regras do Azure Application Gateway e WAF.
• Políticas de rede Kubernetes nativas.
• Controles de firewall nos recursos do Azure aplicáveis. Por exemplo, essa arquitetura usa uma regra no Registro de Contêiner do Azure que só permite o tráfego de um ponto de extremidade privado.
• Quaisquer outros controles de rede que você adicionou à arquitetura.

Se você desativou qualquer carga de trabalho ou alterou a configuração do cluster desde a revisão anterior, é importante verificar se todas as suposições feitas sobre exceções de firewall necessárias ou regras NSG ainda são válidas.

Requisito 1.2

Crie configurações de firewall e roteador que restrinjam conexões entre redes não confiáveis e quaisquer componentes do sistema no ambiente de dados do titular do cartão.

As suas responsabilidades

Nesta arquitetura, o cluster AKS é um componente chave do ambiente de dados do titular do cartão (CDE). É altamente recomendável que o cluster seja implantado como um cluster privado para maior segurança. Em um cluster privado, o tráfego de rede entre o servidor de API Kubernetes gerenciado pelo AKS e seus pools de nós é privado. O servidor de API é exposto por meio de um ponto de extremidade privado na rede do cluster.

Você também pode escolher um cluster público, mas, no entanto, esse design não é recomendado para clusters que contêm cargas de trabalho regulamentadas. O servidor API será exposto à internet. O registo DNS será sempre detetável. Portanto, você precisa ter controles para manter a API do cluster protegida contra acesso público. Se o uso de um cluster público for necessário, a abordagem recomendada é ter controles rígidos por meio de controles de acesso baseados em função (RBAC) do Kubernetes, emparelhados com o recurso de intervalos de IP autorizados AKS para restringir quem pode acessar o AKS API Server. No entanto, essa solução não é recomendada para clusters que contêm cargas de trabalho regulamentadas.

Ao processar dados do titular do cartão (CHD), o cluster precisa interagir com redes consideradas confiáveis e não confiáveis. Nessa arquitetura, ambas as redes hub-spoke dentro do perímetro da carga de trabalho PCI-DSS 3.2.1 são consideradas redes confiáveis.

As redes não fidedignas são redes fora desse perímetro. As redes não fidedignas incluem:

• Os outros hubs e porta-vozes que podem estar na mesma infraestrutura, mas estão fora do perímetro da carga de trabalho.
• A internet pública.
• A rede corporativa.
• Outras redes virtuais no Azure ou noutra plataforma na nuvem.

Nessa arquitetura, a rede virtual que hospeda o construtor de imagens não é confiável porque não tem nenhum papel a desempenhar no tratamento de CHD. A interação do CDE com essas redes deve ser assegurada de acordo com os requisitos. Com esse cluster privado, você pode usar redes virtuais, NSGs e outros recursos internos para proteger todo o ambiente.

Para obter informações sobre clusters privados, consulte Criar um cluster privado do Serviço Kubernetes do Azure.

Requisito 1.2.1

Restrinja o tráfego de entrada e saída ao que é necessário para o ambiente de dados do titular do cartão e, especificamente, negue todo o outro tráfego.

As suas responsabilidades

Por predefinição, as redes virtuais do Azure não podem ser acedidas diretamente a partir da Internet pública. Todo o tráfego de entrada (ou entrada) deve passar por um roteador de tráfego intermediário. No entanto, por padrão, todos os componentes da rede podem alcançar pontos de extremidade públicos. Você pode desabilitar esse comportamento configurando uma sub-rede privada ou usando um UDR para enviar todo o tráfego de saída através de um firewall. Esse tráfego de saída (ou saída) deve ser explicitamente protegido para permitir apenas cifras seguras e TLS 1.2 ou posterior.

• O WAF integrado do Gateway de Aplicativo do Azure interceta todo o tráfego de entrada HTTP(S) e roteia o tráfego inspecionado para o cluster.

  Este tráfego pode ter origem em redes fidedignas ou não fidedignas. O Application Gateway é provisionado em uma sub-rede da rede spoke e protegido por um NSG. À medida que o tráfego flui, as regras do WAF permitem ou negam e o Application Gateway roteia o tráfego para o back-end configurado. Por exemplo, o Application Gateway protege o CDE negando esse tipo de tráfego:

  • Todo o tráfego que não é criptografado por TLS.
  • Tráfego fora do intervalo de portas para comunicação do plano de controle da infraestrutura do Azure.
  • Solicitações de teste de integridade enviadas por entidades diferentes do balanceador de carga interno no cluster.

• O Firewall do Azure é usado para proteger todo o tráfego de saída (saída) de redes confiáveis e não confiáveis.

  O Firewall do Azure é provisionado em uma sub-rede da rede de hub. Para impor o Firewall do Azure como o único ponto de saída, as rotas definidas pelo usuário (UDRs) são usadas em sub-redes capazes de gerar tráfego de saída. Isso inclui sub-redes em redes não confiáveis, como a rede virtual do construtor de imagens. Depois que o tráfego atinge o Firewall do Azure, várias regras de escopo são aplicadas para permitir que o tráfego de fontes específicas vá para destinos específicos.

  Para obter mais informações, consulte Usar o Firewall do Azure para proteger implantações do Serviço Kubernetes do Azure (AKS).

• Opcionalmente, é possível usar um proxy HTTP para monitorar e proteger o tráfego de saída (saída), do cluster para recursos externos.

  Além de um firewall, algumas organizações podem querer usar um proxy HTTP para ter controles adicionais na saída. Recomendamos que você ainda tenha as rotas definidas pelo usuário indo para o firewall e para limitar o tráfego de saída para apenas ir para o proxy HTTP. Com essa configuração, se um pod tentar substituir o proxy, o firewall ainda poderá bloquear o tráfego de saída.

  Para obter mais informações, consulte Suporte a proxy HTTP no Serviço Kubernetes do Azure.

O cluster pode exigir acesso a outros serviços pela Internet pública. Por exemplo, se você usar um software antimalware de terceiros, ele precisará obter as definições de vírus de um servidor pela Internet pública.

As interações com pontos de extremidade de outros serviços do Azure estão no backbone do Azure. Por exemplo, como parte das operações regulares, o cluster precisará obter certificados do armazenamento de chaves gerenciadas, extrair imagens de um registro de contêiner e assim por diante. Certifique-se de que essas interações sejam privadas e seguras usando o Azure Private Link.

Além das regras de firewall e redes privadas, os fluxos de tráfego também são protegidos por meio de regras NSG. Aqui estão alguns exemplos desta arquitetura onde o CDE é protegido pela negação de tráfego:

• NSGs em sub-redes que têm pools de nós negam qualquer acesso SSH aos nós. Certifique-se de ter um processo em vigor para acesso de emergência just-in-time, mantendo o princípio de negar tudo.
• Um NSG na sub-rede que tem a caixa de salto para executar ferramentas de gerenciamento nega todo o tráfego, exceto do Azure Bastion na rede de hub.
• NSGs em sub-redes que têm os pontos de extremidade privados para o Cofre de Chaves do Azure e o Registro de Contêiner do Azure negam todo o tráfego, exceto do balanceador de carga interno e do tráfego pelo Azure Private Link.

Requisito 1.2.2

Proteja e sincronize os arquivos de configuração do roteador.

As suas responsabilidades

Tenha um mecanismo para detetar o delta entre o estado real implantado e o estado desejado. Infraestrutura como Código (IaC) é uma ótima opção para esse fim. Por exemplo, arquivos Bicep ou modelos do Azure Resource Manager (modelos ARM) mantêm um registro do estado desejado.

Os ativos de implantação, como arquivos Bicep, devem ser controlados pelo código-fonte para que você tenha o histórico de todas as alterações. Colete informações de logs de atividades do Azure, logs de pipeline de implantação e logs de implantação do Azure. Essas fontes ajudarão você a manter um rastro de ativos implantados.

No cluster, os controles de rede, como as diretivas de rede do Kubernetes, também devem seguir o fluxo controlado pelo código-fonte. Nesta implementação, o Flux é usado como o operador GitOps. Quando você sincroniza uma configuração de cluster, como políticas de rede, seu histórico do Git combinado com o Flux e os logs de API podem ser uma fonte de histórico de configuração.

Requisito 1.2.3

Instale firewalls de perímetro entre todas as redes sem fio e o ambiente de dados do titular do cartão e configure esses firewalls para negar ou, se o tráfego for necessário para fins comerciais, permitir apenas o tráfego autorizado entre o ambiente sem fio e o ambiente de dados do titular do cartão.

As suas responsabilidades

Os nós AKS e os pools de nós não devem ser acessíveis a partir de redes sem fio. Além disso, as solicitações para o servidor de API do Kubernetes devem ser negadas. O acesso a esses componentes é restrito a sub-redes autorizadas e seguras.

Em geral, limite o acesso do tráfego local à rede falada.

Requisito 1.3

Proibir o acesso público direto entre a Internet e qualquer componente do sistema no ambiente de dados do titular do cartão.

As suas responsabilidades

Os pools de nós de cluster AKS operam dentro da rede virtual e isolados de redes públicas, como a Internet. Mantenha o isolamento impedindo a associação de IPs públicos a nós de cluster e aplicando regras NSG nas sub-redes de cluster para garantir que o tráfego da Internet seja bloqueado. Para obter informações sobre acesso controlado, consulte a seção DMZ.

O cluster AKS tem pools de nós do sistema que hospedam pods críticos do sistema. Mesmo nos pools de nós de usuário, há pods que executam outros serviços que participam de operações de cluster. Por exemplo, os pods podem executar o Flux para sincronizar a configuração do cluster com um repositório GitHub ou o controlador de entrada para rotear o tráfego para os pods de carga de trabalho. Independentemente do tipo de pool de nós, todos os nós devem ser protegidos.

Outro componente crítico do sistema é o servidor de API que é usado para executar tarefas nativas do Kubernetes, como manter o estado do cluster e da configuração. Uma vantagem de usar um cluster privado é que o ponto de extremidade do servidor de API não é exposto por padrão. Para obter informações sobre clusters privados, consulte Criar um cluster privado do Serviço Kubernetes do Azure.

As interações com outros pontos finais também devem ser protegidas. Uma das formas é restringir as comunicações através de uma rede privada. Por exemplo, faça com que o cluster extraia imagens do Registro de Contêiner do Azure em um link privado.

Requisito 1.3.1

Implemente uma DMZ para limitar o tráfego de entrada apenas aos componentes do sistema que fornecem serviços, protocolos e portas autorizados acessíveis ao público.

As suas responsabilidades

Aqui estão algumas melhores práticas:

• Não configure endereços IP públicos nos nós do pool de nós.
• Use a Política do Azure para garantir que o Kubernetes não exponha um balanceador de carga público. O tráfego dentro do cluster deve ser roteado através de balanceadores de carga internos.
• Exponha apenas os balanceadores de carga internos ao Gateway de Aplicativo do Azure integrado ao WAF.
• Todos os controles de rede devem especificar restrições de origem, destino, porta e protocolo, quando aplicável.
• Não exponha o servidor de API à Internet. Quando você executa o cluster no modo privado, o ponto de extremidade não é exposto e a comunicação entre os pools de nós e o servidor de API é feita por uma rede privada.

Os usuários podem implementar uma rede de perímetro para proteger clusters AKS. Para obter informações, consulte Cloud DMZ.

Requisito 1.3.2

Limite o tráfego de entrada da Internet para endereços IP dentro da DMZ.

As suas responsabilidades

Na rede de cluster, tenha um NSG na sub-rede com o balanceador de carga interno. Configure regras para aceitar apenas tráfego da sub-rede que tenha o Gateway de Aplicativo do Azure integrado ao WAF. Dentro do cluster AKS, use o Kubernetes NetworkPolicies para restringir o tráfego de entrada para os pods.

Requisito 1.3.3

Implemente medidas antifalsificação para detetar e impedir que endereços IP de origem falsificados entrem na rede.

Responsabilidades do Azure

O Azure implementa a filtragem de rede para evitar tráfego falsificado e restringir o tráfego de entrada e saída para componentes de plataforma confiáveis.

Requisito 1.3.4

Não permita tráfego de saída não autorizado do ambiente de dados do titular do cartão para a Internet.

As suas responsabilidades

Eis algumas formas de bloquear o tráfego de saída não autorizado:

• Imponha todo o tráfego de saída (saída) do cluster AKS para passar pelo Firewall do Azure usando rotas definidas pelo usuário (UDRs) em todas as sub-redes do cluster. Isso inclui sub-redes com pools de nós de sistema e usuário.
• Limite o tráfego de saída adicionando NSGs em sub-redes com pools de nós.
• Use o Kubernetes NetworkPolicies para restringir o tráfego de saída dos pods.
• Use uma malha de serviço para lidar com políticas adicionais. Por exemplo, se você permitir apenas tráfego criptografado por TLS entre pods, o proxy de malha de serviço poderá lidar com a verificação TLS. Esse exemplo é demonstrado nesta implementação. O Envoy é implantado como proxy.
• Impedir a adição de endereços IP públicos às redes dentro do CDE, a menos que por sub-redes explicitamente autorizadas, como as sub-redes do Firewall.
• Use um proxy HTTP, além do Firewall do Azure, para limitar o tráfego de saída (saída) do cluster AKS para a Internet.
• Use o Azure Monitor Private Link Service (AMPLS) para que os logs das informações do Container sejam enviados por meio de uma conexão segura e privada com o Azure Monitor. Entenda o impacto da habilitação do AMPLS.

Para obter detalhes, consulte Controlar o tráfego de saída para nós de cluster no Serviço Kubernetes do Azure (AKS).

Requisito 1.3.5

Permitir apenas ligações "estabelecidas" à rede.

Responsabilidades do Azure

O Azure implementa a filtragem de rede para evitar tráfego falsificado e restringir o tráfego de entrada e saída para componentes de plataforma confiáveis. A rede do Azure é segregada para separar o tráfego do cliente do tráfego de gerenciamento.

Requisito 1.3.6

Coloque os componentes do sistema que armazenam dados do titular do cartão (como um banco de dados) em uma zona de rede interna, segregada da DMZ e de outras redes não confiáveis.

As suas responsabilidades

Exponha seus sistemas de armazenamento somente em uma rede privada, por exemplo, usando o Private Link. Além disso, restrinja o acesso da(s) sub-rede(s) do pool de nós que o exigem. Mantenha o estado fora do cluster e em sua própria zona de segurança dedicada.

Requisito 1.3.7

Não divulgue endereços IP privados e informações de roteamento para partes não autorizadas.

As suas responsabilidades

Para atender a esse requisito, um cluster AKS público não é uma opção. Um cluster privado mantém os registos DNS fora da Internet pública utilizando uma zona DNS privada. No entanto, ainda é possível criar um cluster AKS privado com um endereço DNS público. Portanto, é recomendável desativar explicitamente esse recurso definindo enablePrivateClusterPublicFQDN para false evitar a divulgação do endereço IP privado do seu plano de controle. Considere usar a Política do Azure para impor o uso de clusters privados sem registros DNS públicos.

Além disso, use uma zona DNS privada para roteamento entre a sub-rede que tem o Gateway de Aplicativo do Azure integrado ao WAF e a sub-rede que tem o balanceador de carga interno. Certifique-se de que nenhuma resposta HTTP inclua qualquer informação IP privada nos cabeçalhos ou no corpo. Certifique-se de que os logs que podem conter registros IP e DNS não sejam expostos fora das necessidades operacionais.

Um serviço do Azure conectado por meio do Private Link não tem um registro DNS público expondo seus endereços IP privados. Sua infraestrutura deve fazer o melhor uso do Private Link.

Requisito 1.4

Instale software de firewall pessoal ou funcionalidade equivalente em qualquer dispositivo de computação portátil que se conecte à Internet quando estiver fora da rede e que também seja usado para acessar o CDE.

As suas responsabilidades

O cluster privado é gerenciado pelo plano de controle AKS. Você não tem acesso aos nós diretamente. Para realizar tarefas administrativas, você precisará usar ferramentas de gerenciamento, como kubectl, de um recurso de computação separado. Uma opção é usar uma caixa de salto air-gapped onde você pode executar os comandos. Além disso, o tráfego de entrada e saída da caixa de salto deve ser restrito e seguro. Se a VPN for usada para acesso, verifique se a máquina cliente é gerenciada pela política corporativa e se todas as políticas de acesso condicional estão em vigor.

Nessa arquitetura, essa caixa de salto está em uma sub-rede separada na rede falada. O acesso de entrada à caixa de salto é restrito usando um NSG que só permite o acesso por meio do Azure Bastion sobre SSH.

Para executar determinados comandos na caixa de salto, você precisará alcançar pontos de extremidade públicos. Por exemplo, pontos de extremidade gerenciados pelo plano de gerenciamento do Azure. Esse tráfego de saída deve ser seguro. Semelhante a outros componentes na rede spoke, o tráfego de saída da caixa de salto é restrito usando um UDR que força o tráfego HTTPS a passar pelo Firewall do Azure.

Requisito 1.5

Certifique-se de que as políticas de segurança e os procedimentos operacionais para gerenciar firewalls estejam documentados, em uso e conhecidos por todas as partes afetadas.

As suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre o processo e as políticas. Isso é especialmente verdadeiro quando você gerencia regras do Firewall do Azure que segmentam o cluster AKS. As pessoas que operam ambientes regulamentados devem ser educadas, informadas e incentivadas a apoiar as garantias de segurança. Isso é particularmente importante para pessoas com contas que recebem amplos privilégios administrativos.

Requisito 2 — não use padrões fornecidos pelo fornecedor para senhas do sistema e outros parâmetros de segurança

As suas responsabilidades

Necessidade	Responsabilidade
Requisito 2.1	Sempre altere os padrões fornecidos pelo fornecedor e remova ou desabilite contas padrão desnecessárias antes de instalar um sistema na rede.
Requisito 2.2	Desenvolver padrões de configuração para todos os componentes do sistema. Assegure-se de que esses padrões abordam todas as vulnerabilidades de segurança conhecidas e são consistentes com os padrões de proteção do sistema aceitos pelo setor.
Requisito 2.3	Criptografe todo o acesso administrativo que não seja do console usando criptografia forte.
Requisito 2.4	Mantenha um inventário dos componentes do sistema que estão no escopo do PCI DSS.
Requisito 2.5	Certifique-se de que as políticas de segurança e os procedimentos operacionais para gerenciar os padrões do fornecedor e outros parâmetros de segurança estejam documentados, em uso e conhecidos por todas as partes afetadas.
Requisito 2.6	Os provedores de hospedagem compartilhada devem proteger o ambiente hospedado de cada entidade e 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

Requisito 2.1

Sempre altere os padrões fornecidos pelo fornecedor e remova ou desabilite contas padrão desnecessárias antes de instalar um sistema na rede.

As suas responsabilidades

As configurações padrão fornecidas pelos fornecedores devem ser alteradas. As configurações padrão são vetores de ataque comuns e tornam o sistema propenso a ataques. Aqui estão algumas considerações:

• Desative o acesso de administrador no registro do contêiner.
• Certifique-se de que as caixas de salto e os agentes de compilação sigam os procedimentos de gerenciamento de usuários, removendo os usuários do sistema que não são necessários.
• Não gere ou forneça acesso de chave SSH a nós para usuários administradores. Se o acesso de emergência for necessário, use o processo de recuperação do Azure para obter acesso just-in-time.

Responsabilidades do Azure

O Microsoft Entra ID tem políticas de senha que são aplicadas às novas senhas fornecidas pelos usuários. Se alterar uma palavra-passe, é necessária a validação da palavra-passe mais antiga. Uma senha que foi redefinida por um administrador precisa ser alterada quando o usuário entrar em seguida.

Requisito 2.1.1

Para ambientes sem fio conectados ao ambiente de dados do titular do cartão ou transmissão de dados do titular do cartão, altere TODOS os padrões do fornecedor sem fio na instalação, incluindo, entre outros, chaves de criptografia sem fio padrão, senhas e cadeias de caracteres da comunidade SNMP.

As suas responsabilidades

Essa arquitetura e a implementação não foram projetadas para fazer transações locais ou de rede corporativa para a nuvem por meio de conexões sem fio. Para obter considerações, consulte as orientações no padrão oficial PCI-DSS 3.2.1.

Requisito 2.2

Desenvolver padrões de configuração para todos os componentes do sistema.

As suas responsabilidades

Implemente as recomendações no benchmark de segurança na nuvem da Microsoft. Ele fornece uma visão única e consolidada das recomendações de segurança do Azure, abrangendo estruturas do setor, como CIS, NIST, PCI-DSS 3.2.1 e outras. Use os recursos do Microsoft Defender for Cloud e a Política do Azure para ajudar a rastrear os padrões. O benchmark de segurança do Azure é a iniciativa padrão do Microsoft Defender for Cloud. Considere a criação de verificações automatizadas adicionais na Política do Azure e na Solução de Segurança do Locatário do Azure (AzTS).

Documente o estado de configuração desejado de todos os componentes no CDE, especialmente para nós AKS, jump box, agentes de compilação e outros componentes que interagem com o cluster.

Para obter mais informações, consulte Benchmark de segurança na nuvem da Microsoft.

Responsabilidade do Azure

O Azure fornece padrões de configuração de segurança que são consistentes com os padrões de proteção aceitos pelo setor. As normas são revistas pelo menos uma vez por ano.

Requisito 2.2.1

Implemente apenas uma função primária por servidor para impedir que funções que exigem diferentes níveis de segurança coexistam no mesmo servidor. (Por exemplo, servidores Web, servidores de banco de dados e DNS devem ser implementados em servidores separados.)

As suas responsabilidades

A estratégia-chave é fornecer o nível necessário de segmentação. Uma maneira é implantar componentes dentro e fora do escopo em clusters separados. Entenda que isso resulta em aumento de custos para a infraestrutura adicional e as despesas gerais de manutenção. Outra abordagem é colocalizar todos os componentes em um cluster compartilhado. Use estratégias de segmentação para manter a separação. Por exemplo, ter pools de nós separados dentro de um cluster.

Na implementação de referência, a segunda abordagem é demonstrada com um aplicativo de microsserviços implantado em um único cluster. O aplicativo tem dois conjuntos de serviços: um conjunto tem pods no escopo e o outro está fora do escopo. Ambos os conjuntos estão distribuídos em dois pools de nós de usuário. Com o uso de manchas do Kubernetes, pods dentro e fora do escopo são implantados em pools de nós separados e nunca compartilham uma VM de nó.

Para tecnologias de contêiner, essa segmentação é fornecida por padrão porque apenas uma instância de um contêiner é responsável por uma função no sistema.

Cada pod de carga de trabalho deve usar sua própria identidade. Ele não deve herdar nenhuma identidade de nível de cluster ou de nó.

Sempre que possível, use armazenamento externo em vez de armazenamento no nó (em cluster). Mantenha os pods de cluster reservados exclusivamente para o trabalho que deve ser realizado como parte da operação de processamento de dados do titular do cartão. Mova as operações fora do escopo para fora do cluster. Esta orientação se aplica a agentes de compilação, cargas de trabalho não relacionadas ou atividades como ter uma caixa de salto dentro do cluster.

Requisito 2.2.2

Habilite apenas os serviços necessários, protocolos, daemons, etc., conforme necessário para o funcionamento do sistema.

As suas responsabilidades

Analise os recursos e as implicações antes de habilitá-los. As configurações padrão podem incluir recursos que você não precisa e esses recursos podem precisar de visibilidade da carga de trabalho. Um exemplo disso são as cifras na política SSL padrão para o Gateway de Aplicativo do Azure. Verifique se a política é excessivamente permissiva. A recomendação é criar uma política personalizada selecionando apenas as cifras necessárias.

Para componentes em que você tem controle total, remova todos os serviços desnecessários do sistema das imagens. Por exemplo, revise as imagens em busca de caixas de salto e agentes de compilação e remova todos os componentes que não são necessários.

Para componentes em que você só tem visibilidade, como nós AKS, documente o que o Azure instala nos nós. Considere usar DaemonSets para fornecer qualquer auditoria adicional necessária para esses componentes controlados pela nuvem.

Requisito 2.2.3

Implemente recursos de segurança adicionais para quaisquer serviços, protocolos ou daemons necessários que sejam considerados inseguros.

As suas responsabilidades

O Application Gateway tem um WAF integrado e negocia o handshake TLS para a solicitação enviada ao seu ponto de extremidade público, permitindo apenas cifras seguras. A implementação de referência suporta apenas TLS 1.2 e cifras aprovadas.

Suponha que você tenha um dispositivo herdado que precisa interagir com o CDE por meio do Gateway de Aplicativo do Azure. Para atender a esse requisito, o Application Gateway deve habilitar um protocolo inseguro. Documente essa exceção e monitore se esse protocolo é usado além desse dispositivo herdado. Desative esse protocolo imediatamente após a interação herdada ser descontinuada.

O Application Gateway não deve responder a solicitações na porta 80. Não execute redirecionamentos no nível do aplicativo. Esta implementação de referência tem uma regra NSG que bloqueia o tráfego da porta 80. A regra está na sub-rede com o Application Gateway.

Se uma carga de trabalho em seu cluster não puder aderir à política organizacional em torno de perfis de conformidade de segurança ou outros controles (por exemplo, limites e cotas), verifique se a exceção está documentada. Você deve monitorar para garantir que apenas a funcionalidade esperada seja executada.

Requisito 2.2.4

Configure os parâmetros de segurança do sistema para evitar o uso indevido.

As suas responsabilidades

Todos os serviços do Azure usados na arquitetura devem seguir as recomendações fornecidas pelo benchmark de segurança na nuvem da Microsoft. Essas recomendações fornecem um ponto de partida para selecionar definições de configuração de segurança específicas. Além disso, compare sua configuração com a implementação de linha de base para esse serviço. Para obter mais informações sobre as linhas de base de segurança, consulte Linhas de base de segurança para o Azure.

O controlador de admissão do Open Policy Agent funciona em conjunto com a Política do Azure para detetar e evitar configurações incorretas no cluster. Suponha que haja uma política organizacional que não permita alocações públicas de IP nos nós. Quando essa alocação é detetada, ela é marcada para auditoria ou negada com base na ação especificada na definição de política.

No nível de infraestrutura, você pode aplicar restrições sobre o tipo e a configuração dos recursos do Azure. Use a Política do Azure para evitar configurações incorretas. Nesta implementação de referência, há uma política que nega a criação de clusters AKS que não são privados.

Certifique-se de que todas as exceções sejam documentadas e revistas regularmente.

Responsabilidades do Azure

O Azure garante que apenas pessoal autorizado possa configurar os controlos de segurança da plataforma Azure, utilizando controlos de acesso multifator e uma necessidade empresarial documentada.

Requisito 2.2.5

Remova todas as funcionalidades desnecessárias, como scripts, drivers, recursos, subsistemas, sistemas de arquivos e servidores Web desnecessários.

As suas responsabilidades

Não instale software em jump boxes ou crie agentes que não participem do processamento de uma transação ou forneçam observabilidade para requisitos de conformidade, como agentes de segurança. Esta recomendação também se aplica às entidades de cluster, como DaemonSet e pods. Certifique-se de que todas as instalações são detetadas e registradas.

Requisito 2.3

Criptografe todo o acesso administrativo que não seja do console usando criptografia forte.

As suas responsabilidades

Todo o acesso administrativo ao cluster deve ser feito usando o console. Não exponha o plano de controle do cluster.

Responsabilidades do Azure

O Azure garante que o uso de criptografia forte seja imposto ao acessar a infraestrutura do hipervisor. Ele garante que os clientes que usam o portal do Azure possam acessar seus consoles de serviço e host usando criptografia forte.

Requisito 2.4

Mantenha um inventário dos componentes do sistema que estão no escopo do PCI DSS.

As suas responsabilidades

Todos os recursos do Azure usados na arquitetura devem ser marcados corretamente. As tags ajudam na classificação de dados e indicam se o serviço está dentro ou fora do escopo. A marcação meticulosa permitirá que você consulte recursos, mantenha um inventário, ajude a controlar custos e defina alertas. Além disso, mantenha um instantâneo dessa documentação periodicamente.

Evite marcar recursos dentro ou fora do escopo em um nível granular. À medida que a solução evolui, os recursos fora do escopo podem se tornar inescoados, mesmo que interajam indiretamente ou sejam adjacentes aos dados do titular do cartão. Estes recursos estão sujeitos a auditoria e podem fazer parte de uma amostra representativa durante a auditoria. Considere a marcação em um nível mais alto, no nível de assinatura e cluster.

Para obter informações sobre considerações sobre marcação, consulte Guia de decisão de nomenclatura e marcação de recursos.

Marque objetos no cluster aplicando rótulos do Kubernetes. Dessa forma, você pode organizar objetos, selecionar uma coleção de objetos e relatar o inventário.

Requisito 2.5

Certifique-se de que as políticas de segurança e os procedimentos operacionais para gerenciar os padrões do fornecedor e outros parâmetros de segurança estejam documentados, em uso e conhecidos por todas as partes afetadas.

As suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre os processos e políticas. O pessoal deve ser treinado nos recursos de segurança e definições de configuração de cada recurso do Azure. As pessoas que operam ambientes regulamentados devem ser educadas, informadas e incentivadas a apoiar as garantias de segurança. Essas etapas são particularmente importantes para qualquer pessoa a quem sejam concedidos amplos privilégios administrativos.

Requisito 2.6

Os provedores de hospedagem compartilhada devem proteger o ambiente hospedado de cada entidade e os dados do titular do cartão.

As suas responsabilidades

O Azure fornece garantias de segurança para todos os componentes do ambiente hospedado que são compartilhados. É altamente recomendável que você trate seus nós AKS como um host dedicado para essa carga de trabalho. Ou seja, toda a computação deve estar em um modelo de locatário único e não compartilhada com outras cargas de trabalho que você possa operar.

Se o isolamento de computação completo for desejado no nível de infraestrutura do Azure, você poderá Adicionar Host Dedicado do Azure a um cluster do Serviço Kubernetes do Azure (AKS). Esta oferta fornece servidores físicos dedicados à sua carga de trabalho, permitindo que você coloque nós AKS diretamente nesses hosts provisionados. Essa escolha arquitetônica tem implicações significativas em termos de custos e requer um planejamento cuidadoso da capacidade. Não é típico para a maioria dos cenários.

Próximos passos

Proteja os dados armazenados do titular do cartão. Criptografe a transmissão de dados do titular do cartão em redes abertas e públicas.

Recursos relacionados

• Design de arquitetura do Serviço Kubernetes do Azure (AKS)
• Introdução de um cluster regulado por AKS para PCI-DSS 3.2.1 (Parte 1 de 9)
• Arquitetura de um cluster regulado pelo AKS para PCI-DSS 3.2.1 (Parte 2 de 9)
• Arquitetura de linha de base para um cluster do Serviço Kubernetes do Azure (AKS)
• Linha de base AKS para clusters multirregionais