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

Este artigo descreve as considerações de rede para um cluster do AKS (Serviço de Kubernetes do Azure) 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. Ela facilita a criação de 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, fornecendo acesso conforme a necessidade. Além disso, você pode aplicar diversas abordagens de defesa em profundidade adicionando controles em cada salto e camada de rede.

Quando você está hospedando uma carga de trabalho em um Kubernetes, não é suficiente depender de construtos de rede tradicionais, como regras de firewall. Também há construtos nativos do Kubernetes que controlam o fluxo de tráfego no cluster, como o recurso NetworkPolicy. É 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 – instale e mantenha uma configuração de firewall para proteger os dados do titular do cartão.

Suporte ao recurso do AKS

O AKS dá suporte à implantação de um cluster em uma rede virtual privada como um cluster privado. A comunicação entre o cluster e o servidor da 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 CDE (ambiente de dados do titular do cartão). 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, confira Criar um cluster privado do Serviço de 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 marca FQDN do AKS. O processo recomendado é fornecido em Usar o Firewall do Azure para proteger as implantações do AKS (Serviço de Kubernetes do Azure).

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 ver mais informações, confira Controlar o tráfego de saída dos nós de cluster no AKS (Serviço de Kubernetes do Azure).

O AKS opcionalmente suporta 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, portanto, é recomendável usar um proxy HTTP além de um Firewall do Azure.

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

Suas responsabilidades

Requisito	Capacidade de resposta
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 as 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	Proíba 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 o software de firewall pessoal ou funcionalidade equivalente todos os dispositivos de computação portáteis (inclusive os de propriedade da empresa e/ou dos funcionários) que se conectam à Internet quando estão fora da rede (por exemplo, laptops usados pelos funcionários), e que também são usados para acessar o CDE.
Requisito 1.5	Garanta que políticas de segurança e procedimentos operacionais para o gerenciamento de firewalls estejam documentados, em uso e sejam do conhecimento de todas as partes afetadas.

Requisito 1.1

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

Requisito 1.1.1

Um processo formal para a aprovação e o teste de todas as conexões de rede e alterações nas configurações de firewall e de roteador.

Suas responsabilidades

Não implemente configurações manualmente, por exemplo, usando o portal do Azure ou a CLI do Azure diretamente. É recomendável usar a IaC (Infraestrutura como Código). Com a IaC, a infraestrutura é gerenciada por meio de um modelo descritivo que usa um sistema de controle de versão. 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. Caso você não tenha a opção de usar o IaC, tenha um processo bem documentado para rastrear, implementar e implantar as alterações nas regras de firewall com segurança. 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, NSGs (grupos de segurança de rede) e o recurso NetworkPolicy do Kubernetes.

Minimize o número de pessoas que podem acessar e modificar controles de rede. Defina funções e responsabilidades claras para as equipes. 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 uma 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

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 desse diagrama.

Figura 1.1.2 – Fluxo de rede

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

Para exibir a topologia de uma rede virtual do Azure é necessário ter o Observador de Rede do Azure. Você pode exibir todos os recursos em uma rede virtual, os recursos associados a recursos em uma rede virtual e os relacionamentos 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.

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. Garanta que o diagrama esteja sempre atualizado. Adicione uma etapa como parte do processo de gerenciamento de alterações para atualizar o diagrama de fluxo de dados.

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

Requisito 1.1.4

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

Suas responsabilidades

Tenha uma definição clara quanto ao 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, políticas de rede e outros controles. Para obter mais informações, confira DMZ em Nuvem.

Para uma infraestrutura PCI DSS, você é responsável por proteger o CDE usando controles de rede para bloquear acesso não autorizado de entrada e saída 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 colocados 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 ambos os sentidos, de e para o cluster que hospeda o CDE:

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

• O Firewall do Azure é usado para proteger todo o tráfego de saída (egresso) 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 do 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 por HTTP e devem ser consideradas como vetores de ataque. Esses vetores são alvos de um ataque man-in-the-middle que pode resultar na exfiltração de dados. Adicionar um firewall ao tráfego de saída reduz essa ameaça.

  Recomendamos que até mesmo a comunicação pod-para-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 ao tráfego seguro 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 qualquer tentativa de acesso SSH. Somente tráfego de dentro da rede virtual é permitido.

  À medida que você adiciona componentes à arquitetura, considere adicionar mais NSGs que permitam ou neguem tipos de tráfego em limites de 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 da carga de trabalho.

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

  Por padrão, não há restrições na comunicação pod-para-pod. Você precisa aplicar NetworkPolicy em comunicações no 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 namespaces a0005-i e a0005-o. Todos os namespaces (exceto kube-system, gatekeeper-system, e outros namespaces fornecidos pelo AKS) têm políticas de rede restritivas aplicadas. A definição de política depende dos pods em execução nesses namespaces. Lembre-se de abrir caminhos para a preparação, linhas dinâmicas e sondagens de inicialização. Além disso, abra caminho para oms-agent para que as métricas no nível do nó possam ser enviadas. Considere padronizar portas entre as cargas de trabalho para que você possa fornecer uma Azure Policy consistente NetworkPolicy para as portas de contêiner permitidas.

Requisito 1.1.5

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

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, cada um com uma finalidade. Certifique-se de que sua documentação tenha amplitude de cobertura, desde o planejamento da rede até todas as configurações aplicadas. Também deve incluir detalhes sobre a propriedade, 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 da redes entre o Azure e a Internet. Em uma empresa, a equipe de TI é responsável pela configuração e manutenção de regras de Firewall do Azure, WAF (Firewall do Aplicativo Web), NSGs, entre outros tráfegos entre redes. Eles também podem ser responsáveis pela rede virtual e alocação de 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 a Confiança Zero 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.

Sempre comece com uma estratégia de negação geral. Dê permissão apenas quando houver uma necessidade comercial ou uma justificativa de função.

Requisito 1.1.6

Documentação de justificativa de negócios e aprovação para uso de todos os serviços, protocolos e portas permitidos, incluindo a documentação dos recursos de segurança implementados para esses protocolos considerados inseguros.

Suas responsabilidades

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

Veja alguns exemplos em que você pode permitir o tráfego:

Regra	Protocolo:Porta	Origem	Destino	Justificativa
Permita a 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 destinos FQDN no plano de controle do AKS. Isso é especificado com a marca FQDN AzureKubernetesService.	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.
Permita a comunicação segura entre o Flux e o GitHub.	HTTPS:443	Pools de nós do 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 privado do GitHub.

Requisito 1.1.7

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

Suas responsabilidades

Tenha processos pelo menos a cada seis meses para revisar as configurações de rede e as regras de escopo. Isso fará com que as garantias de segurança se mantenham atualizadas e válidas. Verifique se você revisou estas configurações:

• Regras do Firewall do Azure.
• Regras NSG.
• Regras de Gateway de Aplicativo do Azure e WAF.
• Políticas de rede do Kubernetes.
• Controles de firewall nos recursos aplicáveis do Azure. Por exemplo, essa arquitetura usa uma regra no Registro de Contêiner do Azure que permite o tráfego apenas de um ponto de extremidade privado.
• Quaisquer outros controles de rede adicionados à 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 de NSG ainda são válidas.

Requisito 1.2

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

Suas responsabilidades

Nessa arquitetura, o cluster do AKS é um componente-chave do CDE (ambiente de dados do titular do cartão). É 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 da 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 esse design não é recomendado para clusters que contêm cargas de trabalho regulamentadas. O servidor de API será exposto à Internet. O registro DNS sempre será detectável. Portanto, você precisa ter controles para manter a API do cluster protegida do acesso público. Se o uso de um cluster público for necessário, a abordagem recomendada é ter controles rígidos por meio dos controles de acesso baseados em função (RBAC) do Kubernetes, emparelhados com o recurso de intervalos de IP autorizado 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 CHD (dados do titular do cartão ), o cluster precisará 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.

Redes não confiáveis estão fora desse perímetro. As redes não confiáveis incluem:

• Os outros hubs e spokes 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 em outra plataforma de nuvem.

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

Para obter informações sobre clusters privados, confira Criar um cluster privado do Serviço de 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 negue especificamente todos os outros tráfegos.

Suas responsabilidades

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

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

  Esse tráfego pode se originar de redes confiáveis ou não confiáveis. O Gateway de Aplicativo é 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 Gateway de Aplicativo roteia o tráfego para o backend configurado. Por exemplo, o Gateway de Aplicativo protege o CDE negando este 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.
  • As solicitações de investigação de integridade enviadas por entidades que não sejam o balanceador de carga interno no cluster.

• O Firewall do Azure é usado para proteger todo o tráfego de saída (egresso) 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 UDRs (rotas definidas pelo usuário) 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 criador de imagens. Depois que o tráfego atinge o Firewall do Azure, várias regras de escopo são aplicadas que permitem que o tráfego de fontes específicas vá para destinos específicos.

  Confira mais informações em Usar o Firewall do Azure para proteger as implantações do AKS (Serviço de Kubernetes do Azure).

• 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 precisar acessar 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 passam pelo 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. Verifique se essas interações são privadas e seguras usando o Link Privado do Azure.

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

• Os NSGs, em sub-redes que possuem pools de nós, negam qualquer acesso SSH aos seus nós. Tenha um processo em vigor para acesso de emergência just-in-time, mantendo o princípio de negação de tudo.
• O 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 do hub.
• Os NSGs, em sub-redes que têm os pontos de extremidade privados para Azure Key Vault e Registro de Contêiner do Azure, negam todo o tráfego, exceto do balanceador de carga interno e o tráfego pelo Link Privado do Azure.

Requisito 1.2.2

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

Suas responsabilidades

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

Os ativos de implantação, como arquivos Bicep, devem ser controlados pela origem 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 dos ativos implantados.

No cluster, os controles de rede, como as políticas de rede do Kubernetes, também devem seguir o fluxo controlado pela origem. Nesta implementação, o Flux é usado como o operador GitOps. Quando você está sincronizando uma configuração de cluster, como políticas de rede, seu histórico do Git combinado com os logs do Flux e da API pode ser uma fonte do 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 somente o tráfego autorizado entre o ambiente sem fio e o ambiente de dados do titular do cartão.

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 ao servidor da 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 spoke.

Requisito 1.3

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

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 aos nós do cluster e aplicando regras NSG nas sub-redes do cluster para garantir que o tráfego da Internet seja bloqueado. Para obter informações sobre acesso controlado, confira 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 do 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 do 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 realizar tarefas nativas do Kubernetes, como manter o estado do cluster e a 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, confira Criar um cluster privado do Serviço de Kubernetes do Azure.

As interações com outros pontos de extremidade também devem ser protegidas. Uma maneira é restringindo as comunicações em uma rede privada. Por exemplo, faça com que o cluster extraia imagens do Registro de Contêiner do Azure por meio de um link privado.

Requisito 1.3.1

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

Suas responsabilidades

Eis algumas práticas recomendadas:

• 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 por meio de balanceadores de carga internos.
• Só exponha 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, confira DMZ em Nuvem.

Requisito 1.3.2

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

Suas responsabilidades

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

Requisito 1.3.3

Implemente as medidas antifalsificação para detectar e impedir que endereços IP de origem forjados 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 a componentes de plataforma confiáveis.

Requisito 1.3.4

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

Suas responsabilidades

Veja aqui algumas maneiras pelas quais você pode 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 do sistema e do 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 de TLS. Esse exemplo é demonstrado nesta implementação. O Envoy é implantado como o proxy.
• Impeça 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 Serviço de Link Privado do Azure Monitor (AMPLS) para que os logs do Container insights 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, confira Controlar o tráfego de saída para nós de cluster no AKS (Serviço de Kubernetes do Azure).

Requisito 1.3.5

Permita apenas conexões "estabelecidas" 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 a 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 os dados do titular do cartão (como um banco de dados) em uma zona de rede interna, segregada da rede de borda e de outras redes não confiáveis.

Suas responsabilidades

Exponha seus sistemas de armazenamento apenas em uma rede privada, por exemplo, usando o Link Privado. Adicionalmente, restrinja o acesso das sub-redes 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 terceiros não autorizados.

Suas responsabilidades

Para atender a esse requisito, usar um cluster AKS público não é uma opção. Um cluster privado mantém os registros DNS fora da Internet pública usando uma zona DNS privada. No entanto, ainda é possível Criar um cluster AKS privado com um endereço DNS público. Portanto, é recomendável desabilitar explicitamente esse recurso definindo enablePrivateClusterPublicFQDN para false de modo a impedir a divulgação do endereço IP privado do seu plano de controle. Considere usar o Azure Policy 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 possui o Gateway de Aplicativo do Azure integrado ao WAF e a sub-rede que possui o balanceador de carga interno. Garanta que nenhuma resposta HTTP inclua informações de IP privado nos cabeçalhos ou no corpo. Garanta que os logs que possam conter registros de IP e DNS não sejam expostos fora das necessidades operacionais.

Um serviço do Azure conectado por link privado não tem um registro DNS público expondo seus endereços IP privados. Sua infraestrutura deve usar o Link Privado de maneira otimizada.

Requisito 1.4

Instale o software de firewall pessoal ou funcionalidade equivalente todos os dispositivos de computação portáteis que se conectam à Internet quando estãor fora da rede e que também são usados para acessar o CDE.

Suas responsabilidades

O cluster privado é gerenciado pelo plano de controle do 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 jumpbox de rede desconectada onde você pode executar os comandos. O tráfego de entrada e saída da jumpbox também deve ser restrito e seguro. Se a VPN for usada para acesso, garanta que a máquina cliente seja gerenciada pela política corporativa e que todas as políticas de acesso condicional estejam em vigor.

Nessa arquitetura, essa jumpbox está em uma sub-rede separada na rede spoke. O acesso de entrada à jumpbox é restrito usando um NSG que permite acesso apenas por meio do Azure Bastion sobre SSH.

Para executar determinados comandos na jumpbox, você precisará acessar os endpoints públicos. Por exemplo, pontos de extremidade gerenciados pelo plano de gerenciamento do Azure. Esse tráfego de saída deve ser seguro. De maneira 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

Garanta que políticas de segurança e procedimentos operacionais para o gerenciamento de firewalls estejam documentados, em uso e sejam do conhecimento de todas as partes afetadas.

Suas responsabilidades

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

Requisito 2 – não use padrões de fornecedores para senhas do sistema e outros parâmetros de segurança.

Suas responsabilidades

Requisito	Capacidade de resposta
Requisito 2.1	Sempre altere os padrões dos fornecedores e remova ou desabilite as contas padrão desnecessárias antes de instalar um sistema na rede.
Requisito 2.2	Desenvolva padrões de configuração para todos os componentes do sistema. Garanta que esses padrões tratem de todas as vulnerabilidades de segurança conhecidas e sejam consistentes com os padrões de proteção de sistema estabelecidos pelo setor.
Requisito 2.3	Criptografe todos os acessos administrativos fora do console usando criptografia forte.
Requisito 2.4	Mantenha um estoque de componentes do sistema que estejam no escopo do PCI DSS.
Requisito 2.5	Verifique se as políticas de segurança e os procedimentos operacionais para gerenciar padrões de fornecedor e outros parâmetros de segurança estão documentados, em uso e conhecidos para todas as partes afetadas.
Requisito 2.6	Os provedores de hospedagem compartilhada devem proteger os dados de ambiente hospedado e titular de cartão de cada entidade.

Não usar padrões de fornecedores para senhas do sistema e outros parâmetros de segurança

Requisito 2.1

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

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. Estas são algumas considerações:

• Desative o acesso de administrador no registro de contêiner.
• Garanta que as jump boxes e os agentes de compilação sigam os procedimentos de gerenciamento de usuários, removendo usuários do sistema que não são necessários.
• Não gere ou forneça acesso de chave SSH aos 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 nas novas senhas fornecidas pelos usuários. Se você alterar uma senha, será necessária a validação da senha mais antiga. Uma senha que foi redefinida por um administrador precisa ser alterada na próxima vez que o usuário entrar.

Requisito 2.1.1

Em ambientes sem fio conectados ao ambiente de dados do titular do cartão ou transmitindo dados do mesmo, altere TODOS os padrões do fornecedor sem fio na instalação, incluindo, mas não se limitando a, chaves de criptografia sem fio padrão, senhas e cadeias de caracteres da comunidade de SNMP.

Suas responsabilidades

Essa arquitetura e a implementação não foram projetadas para fazer transações de rede local ou corporativa para nuvem em conexões sem fio. Para ver outras considerações, confira as diretrizes no padrão oficial PCI-DSS 3.2.1.

Requisito 2.2

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

Suas responsabilidades

Implemente as recomendações do benchmark de segurança de 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 para Nuvem e o Azure Policy para ajudar a acompanhar os padrões. O parâmetro de comparação de segurança do Azure é a iniciativa padrão do Microsoft Defender para Nuvem. Considere criar verificações automatizadas adicionais no Azure Policy e na AzTS (Solução de Segurança do Locatário do Azure).

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

Para saber mais, confira Parâmetro de comparação de segurança da nuvem da Microsoft.

Responsabilidade do Azure

O Azure fornece padrões de configuração de segurança consistentes com os padrões de proteção aceitos pelo setor. Esses padrões são revistos pelo menos anualmente.

Requisito 2.2.1

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

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 custos maiores para a infraestrutura adicionada e a sobrecarga de manutenção. Outra abordagem é colocar todos os componentes em um cluster compartilhado. Use estratégias de segmentação para manter a separação. Por exemplo, tenha pools de nós separados em 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 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, os pods dentro e fora do escopo são implantados em pools de nós separados e nunca compartilham uma VM de nó.

Em 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. Ela não deve herdar nenhuma identidade no nível do cluster ou no nível do nó.

Use armazenamento externo em vez de armazenamento no nó (no cluster) sempre que possível. 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 diretriz 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 somente os serviços, protocolos, daemons etc., necessários para a função do sistema.

Suas responsabilidades

Revise os recursos e as implicações antes de ativá-los. As configurações padrão podem incluir recursos que você não precisa, e esses recursos podem precisar de visibilidade na 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, examine as imagens de jump boxes e agentes de build e remova todos os componentes que não são necessários.

Em componentes em que você só tem visibilidade, como nós AKS, documente o que o Azure instala nos nós. Considere usar o 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 são considerados inseguros.

Suas responsabilidades

O Gateway de Aplicativo possui 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 dá suporte apenas a TLS 1.2 e cifras aprovadas.

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

O Gateway de Aplicativo não deve responder a solicitações na porta 80. Não execute redirecionamentos no nível do aplicativo. Essa 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 Gateway de Aplicativo.

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), garanta que a exceção esteja documentada. Você deve monitorá-la 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.

Suas responsabilidades

Todos os serviços do Azure usados na arquitetura devem seguir as recomendações fornecidas pelo parâmetro de comparação de segurança em nuvem da Microsoft. Essas recomendações fornecem um ponto de partida para a seleção de definições de configuração de segurança específicas. Adicionalmente, compare sua configuração com a implementação de linha de base desse serviço. Para obter mais informações sobre as linhas de base de segurança, confira Linhas de base de segurança do Azure.

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

No nível da infraestrutura, você pode aplicar restrições ao tipo e à configuração dos recursos do Azure. Use o Azure Policy 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.

Garanta que todas as exceções sejam documentadas e revisadas regularmente.

Responsabilidades do Azure

O Azure garante que apenas o pessoal autorizado possa configurar os controles de segurança da plataforma Azure, usando controles de acesso multifator e uma necessidade comercial documentada.

Requisito 2.2.5

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

Suas responsabilidades

Não instale software em jumpboxes 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. Essa recomendação também se aplica às entidades de cluster, como DaemonSet e pods. Garanta que todas as instalações sejam detectadas e registradas.

Requisito 2.3

Criptografe todos os acessos administrativos fora do console usando criptografia forte.

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 aplicado ao acessar a infraestrutura do hipervisor. Ele garante que os clientes que usam o portal do Azure possam acessar seus serviços e consoles de host usando criptografia forte.

Requisito 2.4

Mantenha um estoque de componentes do sistema que estejam no escopo do PCI DSS.

Suas responsabilidades

Todos os recursos do Azure usados na arquitetura devem ser marcados corretamente. As marcas auxiliam na classificação dos dados e indicam se o serviço está dentro ou fora do escopo. Uma marcação meticulosa permitirá que você consulte recursos, mantenha um inventário, ajude a rastrear custos e defina alertas. Mantenha também 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 dentro do escopo, mesmo que interajam indiretamente ou sejam adjacentes aos dados do titular do cartão. Esses recursos estão sujeitos a auditoria e podem fazer parte de uma amostra representativa durante a auditoria. Considere fazer a marcação em um nível superior, no nível de assinatura e cluster.

Para obter informações sobre considerações de marcação, confira Guia de decisão de marcação e nomenclatura 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

Verifique se as políticas de segurança e os procedimentos operacionais para gerenciar padrões de fornecedor e outros parâmetros de segurança estão documentados, em uso e conhecidos para todas as partes afetadas.

Suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre os processos e as políticas. A equipe deve ser treinada nos recursos de segurança e nas definições de configuração de cada recurso do Azure. As pessoas que operam ambientes regulamentados devem ser treinadas, informadas e incentivadas a dar suporte às garantias de segurança. Essas etapas são particularmente importantes para qualquer pessoa que receba amplos privilégios administrativos.

Requisito 2.6

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

Suas responsabilidades

O Azure fornece garantias de segurança para quaisquer componentes do ambiente hospedado que sejam 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 único modelo de locatário 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 de Kubernetes do Azure (AKS). Essa 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 de custo significativas e requer um planejamento cuidadoso da capacidade. Não é típico para a maioria dos cenários.

Próximas etapas

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

Recursos relacionados

• Design de arquitetura do AKS (Serviço de Kubernetes do Azure)
• Introdução de um cluster regulamentado do AKS para PCI-DSS 3.2.1 (Parte 1 de 9)
• Arquitetura de um cluster regulamentado do AKS para PCI-DSS 3.2.1 (Parte 2 de 9)
• Arquitetura de linha de base de um cluster do AKS (Serviço de Kubernetes do Azure)
• Linha de base do AKS para clusters de várias regiões