Gerenciamento de acesso de um cluster de linha de base do AKS para um PCI-DSS 3.2.1 (Parte 6 de 9)

Este artigo descreve as considerações 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 Kubernetes conta com RBAC (controle de acesso baseado em função) nativo que gerencia permissões para a API do Kubernetes. Diversas funções internas têm permissões ou ações específicas em recursos do Kubernetes. O AKS (Serviço de Kubernetes do Azure) dá suporte a essas funções internas e funções personalizadas para proporcionar controle granular. Essas ações podem ser autorizadas (ou recusadas) para um usuário por meio do RBAC do Kubernetes.

Essa arquitetura e a implementação não têm a finalidade de fornecer controles de acesso físico a datacenters ou recursos locais. Um benefício de hospedar seu CDE no Azure, e não em sua plataforma na borda ou no datacenter, é que a restrição do acesso físico já é feita em grande parte por meio da segurança do datacenter do Azure. Não há responsabilidades para a organização quanto ao gerenciamento de hardware físico.

Implementar medidas avançadas de controle de acesso

Requisito 7 — Restringir o acesso aos dados do titular do cartão segundo a necessidade de conhecimento

Suporte ao recurso do AKS

O AKS é totalmente integrado ao Microsoft Entra ID como o provedor de identidade.

Você não precisa gerenciar credenciais e identidades de usuário separadas para o Kubernetes. Você pode adicionar usuários do Microsoft Entra para o RBAC do Kubernetes. Essa integração possibilita atribuir funções aos usuários do Microsoft Entra. Com o uso de identidades do Microsoft Entra, você pode usar uma variedade de funções internas, como visualizador, gravador, administrador de serviços e administrador de cluster. Além disso, você pode criar funções personalizadas para ter um controle mais granular.

Por padrão, o RBAC do Azure é configurado para negar todo o acesso, de modo que um recurso não pode ser acessado sem que permissões sejam concedidas. O AKS limita o acesso SSH aos próprios nós de trabalho e usa a política de rede do AKS para controlar o acesso a cargas de trabalho nos pods.

Para obter mais informações, consulte Usar o RBAC do Azure para Autorização do Kubernetes e Proteger seu cluster com o Azure Policy.

Suas responsabilidades

Requisito	Capacidade de resposta
Requisito 7.1	Limitar o acesso aos componentes do sistema e a dados do titular do cartão apenas às pessoas cujo trabalho exija tal acesso.
Requisito 7.2	Estabelecer um sistema de controle de acesso aos componentes de sistemas que restringe o acesso com base na necessidade de conhecimento de um usuário, que é definido como "negar tudo", a menos que haja uma permissão específica.
Requisito 7.3	Garantir que políticas de segurança e procedimentos operacionais para restringir o acesso a dados do titular do cartão estejam documentados, em uso e sejam do conhecimento de todas as partes afetadas.

Requisito 7.1

Limitar o acesso aos componentes do sistema e a dados do titular do cartão apenas às pessoas cujo trabalho exija tal acesso.

Suas responsabilidades

Estas são algumas considerações:

• Verifique se sua implementação está alinhada aos requisitos da organização e aos requisitos de conformidade sobre o gerenciamento de identidade.
• Minimize permissões permanentes, especialmente para contas de impacto crítico.
• Siga o princípio do acesso com privilégios mínimos. Forneça apenas o acesso suficiente para a conclusão da tarefa.

Requisito 7.1.1

Definir as necessidades de acesso de cada função, inclusive:

• Componentes de sistema e recursos de dados que cada função precisa acessar para executar seu trabalho
• Nível de privilégio necessário (por exemplo, usuário, administrador etc.) para acessar recursos.

Suas responsabilidades

Definir as funções com base nas tarefas e responsabilidades necessárias para os componentes no escopo e a interação deles com os recursos do Azure. Você pode começar com categorias amplas, como:

• Escopo por grupos de gerenciamento, assinaturas ou grupos de recursos do Azure
• Azure Policy para a carga de trabalho ou assinatura
• Operações de contêiner
• Gerenciamento de segredos
• Pipelines de build e implantação

Embora a definição de funções e responsabilidades em torno dessas áreas possa estar associada à estrutura de sua equipe, concentre-se no requisito da carga de trabalho. Por exemplo, determine quem é responsável por manter a segurança, o isolamento, a implantação e a observabilidade. Veja alguns exemplos:

• Decida as configurações de segurança do aplicativo, RBAC do Kubernetes, políticas de rede, políticas do Azure e comunicação com outros serviços.
• Configure e mantenha o Firewall do Azure, o firewall de aplicativo Web (WAF), os grupos de segurança de rede (NSGs) e o DNS.
• Monitorar e corrigir a segurança do servidor, a aplicação de patch, a configuração e a segurança do ponto de extremidade.
• Definir instruções de uso para RBAC, Microsoft Defender para Nuvem, estratégia de proteção do administrador e Azure Policy para controlar os recursos do Azure.
• Identifique a equipe de monitoramento e resposta a incidentes. Investigue e corrija incidentes de segurança usando um sistema SIEM (geranciamento de eventos e informações de segurança), como o Microsoft Sentinel ou o Microsoft Defender para Nuvem.

Em seguida, formalizar a definição determinando qual nível de acesso é necessário para a função em relação à carga de trabalho e à infraestrutura. Aqui está uma definição simples para fins ilustrativos.

Função	Responsibilities	Níveis de acesso
Proprietários de aplicativo	Definir e priorizar recursos alinhados com os resultados de negócios. Eles entendem como os recursos afetam o escopo de conformidade da carga de trabalho e equilibram a proteção e a propriedade de dados do cliente com os objetivos de negócios.	Acesso de leitura para logs e métricas emitidos pelo aplicativo. Eles não precisam de permissões para acessar a carga de trabalho nem o cluster.
Desenvolvedores de aplicativos	Desenvolver o aplicativo. Todo o código do aplicativo está sujeito a portões de treinamento e qualidade para manutenção de processos de conformidade, atestado e gerenciamento de versão. Pode gerenciar pipelines de build, mas geralmente não gerencia pipelines de implantação.	Acesso de leitura a namespaces do Kubernetes e recursos do Azure no escopo da carga de trabalho. Não há acesso de gravação para implantar ou modificar nenhum estado do sistema.
Operadores de aplicativo (ou SRE)	Ter uma compreensão profunda da base de código, da observabilidade e das operações. Fazer triagem e solucionar problemas de sites ativos. Com os desenvolvedores de aplicativos, aprimorar a disponibilidade, a escalabilidade e o desempenho do aplicativo. Gerenciar o pipeline de implantação de "última milha" e ajudar a gerenciar pipelines de build.	Altamente privilegiado dentro do escopo do aplicativo, que inclui namespaces do Kubernetes e recursos do Azure relacionados. Provavelmente tem acesso permanente a partes do cluster do Kubernetes.
Proprietários de infraestrutura	Criar uma arquitetura econômica, incluindo a conectividade e a funcionalidade dos componentes. O escopo pode incluir serviços locais e de nuvem. Decidir recursos de retenção de dados, de continuidade de negócios, entre outros.	Acesso a logs de plataforma e dados do centro de custo. Nenhum acesso é necessário dentro do cluster.
Operadores de infraestrutura (ou SRE)	Operações relacionadas ao cluster e aos serviços dependentes. Criar, implantar e inicializar o pipeline para o cluster no qual a carga de trabalho é implantada. Defina pools de nós de destino e requisitos de dimensionamento e escala esperados. Monitorar a integridade da infraestrutura de hospedagem de contêineres e dos serviços dependentes.	Acesso de leitura a namespaces de carga de trabalho. Acesso altamente privilegiado para o cluster.
Proprietários de segurança, policy	Ter experiência com conformidade de segurança ou regulamentação. Definir políticas que protejam a segurança e a conformidade regulatória dos funcionários da empresa, seus ativos e os dos clientes da empresa. Trabalhar com todas as outras funções para garantir que a política seja aplicada e auditável em todas as fases.	Acesso de leitura à carga de trabalho e ao cluster. Além disso, acesso aos dados de log e auditoria.
Operadores de rede	Alocação da rede virtual e de sub-redes em toda a empresa. Configuração e manutenção do Firewall do Azure, do WAF, de NSGs e de DNS.	Altamente privilegiado na camada de rede. Nenhuma permissão de gravação dentro do cluster.

Requisito 7.1.2

Restringir o acesso a IDs de usuário com privilégios aos privilégios mínimos necessários para cumprir as responsabilidades do trabalho.

Suas responsabilidades

Com base nas funções de trabalho, buscar minimizar o acesso sem causar interrupções. Eis algumas práticas recomendadas:

• Reduza o acesso que cada identidade exige. Uma identidade deve ter acesso suficiente para concluir sua tarefa.
• Minimizar permissões permanentes, especialmente em identidades de impacto crítico que têm acesso a componentes no escopo.
• Adicionar restrições extras sempre que possível. Uma maneira é fornecer acesso condicional com base nos critérios de acesso.
• Conduzir revisões e auditorias regulares de usuários e grupos que têm acesso em suas assinaturas, mesmo para acesso de leitura. Evitar convidar identidades externas.

Requisito 7.1.3

Atribuir acesso com base na classificação de trabalho e na atuação individual dos funcionários.

Suas responsabilidades

Determinar permissões com base nas funções de trabalho claramente atribuídas do indivíduo. Evitar parâmetros como o sistema ou o tempo de contratação do funcionário. Conceder direitos de acesso a um usuário ou a um grupo.

Aqui estão alguns exemplos.

Classificação de trabalho	Função
Um proprietário de produto define o escopo da carga de trabalho e prioriza os recursos. Equilibra a proteção e a propriedade de dados do cliente com objetivos comerciais. Precisa ter acesso a relatórios, ao centro de custos ou a dashboards do Azure. Não é necessário nenhum acesso para permissões dentro do cluster ou no nível do cluster.	Proprietários de aplicativo
Um engenheiro de software projeta, desenvolve e conteineriza o código do aplicativo. Um grupo com permissões de leitura permanentes dentro de escopos definidos no Azure (como o Application Insights) e nos namespaces de carga de trabalho. Esses escopos e permissões podem ser diferentes entre ambientes de pré-produção e produção.	Desenvolvedor de aplicativo
Um engenheiro de confiabilidade de site faz a triagem de site ativo, gerencia pipelines e configura a infraestrutura do aplicativo. Grupo A com controle total dentro de seus namespaces alocados. Não são necessárias autorizações permanentes. Grupo B para operações diárias na carga de trabalho. Ele pode ter permissões permanentes dentro de seus namespaces alocados, mas não é altamente privilegiado.	Operadores de aplicativo
Um operador de cluster projeta e implanta um cluster do AKS confiável e seguro na plataforma. Responsável por manter o tempo de atividade do cluster. Grupo A com controle total dentro de seus namespaces alocados. Não são necessárias autorizações permanentes. Grupo B para operações diárias na carga de trabalho. Ele pode ter permissões permanentes dentro de seus namespaces alocados, mas não é altamente privilegiado.	Operadores de infraestrutura
Um engenheiro de rede aloca redes virtuais e sub-redes em toda a empresa, a conectividade entre o local e a nuvem e a segurança de rede.	Operadores de infraestrutura

Requisito 7.1.4

Exigir aprovação documentada por partes autorizadas, com especificação dos privilégios necessários.

Suas responsabilidades

Ter um processo com portões para aprovar alterações em funções e permissões, incluindo a atribuição inicial de privilégios. Garantir que essas aprovações estejam documentadas e disponíveis para inspeção.

Requisito 7.2

Estabelecer um sistema de controle de acesso aos componentes de sistemas que restringe o acesso com base na necessidade de conhecimento de um usuário, que é definido como "negar tudo", a menos que haja uma permissão específica.

Suas responsabilidades

Após seguir o Requisito 7.1, você deve ter avaliado as funções e responsabilidades aplicáveis à sua organização e à carga de trabalho. Todos os componentes na arquitetura que estão no escopo devem ter acesso restrito. Isso inclui os nós do AKS que executam a carga de trabalho, o armazenamento de dados, o acesso à rede e todos os outros serviços que participam do processamento de CHD (dados do titular do cartão).

Com base em funções e responsabilidades, atribua funções ao RBAC (controle de acesso baseado em função) da infraestrutura. Esse mecanismo pode ser:

• O RBAC do Kubernetes é um modelo de autorização nativo do Kubernetes que controla o acesso ao painel de controle do Kubernetes, exposto por meio do servidor de API do Kubernetes. Esse conjunto de permissões define o que você pode fazer com o servidor de API. Por exemplo, você pode negar a um usuário as permissões para criar ou até mesmo para listar pods.
• O RBAC do Azure é um modelo de autorização baseado no Microsoft Entra ID que controla o acesso ao painel de controle do Azure. Trata-se de uma associação do locatário do Microsoft Entra com sua assinatura do Azure. Com o RBAC do Azure, você pode conceder permissões para criar recursos do Azure, como redes, um cluster do AKS e identidades gerenciadas.

Suponha que você precise conceder permissões aos operadores de cluster (mapeados para a função de operador de infraestrutura). Todas as pessoas a que foram atribuídas responsabilidades de operador de infraestrutura pertencem a um grupo do Microsoft Entra. Conforme estabelecido em 7.1.1, essa função requer o privilégio mais elevado no cluster. O Kubernetes tem funções de RBAC internas, como cluster-admin, que atendem a esses requisitos. Você precisará associar o grupo do Microsoft Entra para operadores de infraestrutura a cluster-admin criando associações de função. Há duas abordagens. Você pode escolher as funções internas. Ou, se as funções internas não atenderem aos seus requisitos (por exemplo, elas podem ser excessivamente permissivas), crie funções personalizadas para as associações.

A implementação de referência demonstra o exemplo anterior usando o RBAC do Kubernetes nativo. A mesma associação pode ser realizada com o RBAC do Azure. Para obter mais informações, consulte Controlar o acesso a recursos de cluster usando o controle de acesso baseado em função do Kubernetes e identidades do Microsoft Entra no serviço de Kubernetes do Azure.

Você pode escolher o escopo da permissão no nível do cluster ou do namespace. Para funções que têm responsabilidades com escopo, como operadores de aplicativo, as permissões são atribuídas no nível do namespace para a carga de trabalho.

Além disso, as funções também precisam de permissões de RBAC do Azure para que possam realizar suas tarefas. Por exemplo, o operador de cluster precisa acessar o Azure Monitor por meio do portal. Portanto, a função de operador de infraestrutura precisa ter a atribuição do RBAC apropriada.

Além das pessoas e suas funções, os recursos do Azure, e até pods dentro do cluster, têm identidades gerenciadas. Essas identidades precisam de um conjunto de permissões por meio do RBAC do Azure e precisam ter um escopo rígido com base nas tarefas esperadas. Por exemplo, o Gateway de Aplicativo do Azure precisa ter permissões para obter segredos (certificados TLS) do Azure Key Vault. Ele não pode ter permissões para modificar segredos.

Eis algumas práticas recomendadas:

• Mantenha uma documentação meticulosa sobre cada função e as permissões atribuídas, bem como as justificativas. Manter distinções claras sobre quais permissões são JIT e quais são permanentes.

• Monitorar as funções quando a alterações, como alterações de atribuição ou definições de função. Criar alertas sobre alterações, mesmo que seja esperado que tenham visibilidade quanto às intenções por trás das alterações.

Requisito 7.2.1

Cobertura de todos os componentes do sistema

Suas responsabilidades

Aqui estão algumas melhores práticas para manter medidas de controle de acesso:

• Não ter acesso permanente. Considere usar a associação de grupo do AD Just-In-Time. Esse recurso requer Privileged Identity Management do Microsoft Entra.

• Configure políticas de acesso condicional no Microsoft Entra ID para seu cluster. Isso acrescenta restrições ao acesso ao painel de controle do Kubernetes. Com políticas de acesso condicional, você pode exigir autenticação multifator, restringir a autenticação a dispositivos gerenciados pelo locatário do Microsoft Entra ou bloquear tentativas de entrada atípicas. Aplique essas políticas a grupos do Microsoft Entra mapeados para funções do Kubernetes com privilégio elevado.

  Observação

  As opções de tecnologia de acesso condicional e JIT exigem as licenças P1 ou P2 do Microsoft Entra ID.

• O ideal é desabilitar o acesso SSH aos nós de cluster. Essa implementação de referência não gera detalhes da conexão SSH para essa finalidade.

• Qualquer computação adicional, como caixas de salto, deve ser acessada por usuários autorizados. Não criar logons genéricos disponíveis para toda a equipe.

Requisito 7.2.2

Atribuição de privilégios às pessoas com base na classificação e na função do trabalho.

Suas responsabilidades

Com base em 7.1.3, haverá muitas funções envolvidas nas operações de cluster. Além das funções de recurso do Azure padrão, você precisará definir a extensão e o processo de acesso.

Por exemplo, considere a função de operador de cluster. Eles precisam ter um guia estratégico claramente definido para atividades de triagem de cluster. Qual é a diferença entre esse acesso e o da equipe de carga de trabalho? Dependendo da organização, eles poderão ser os mesmos. Veja alguns pontos a serem considerados:

• Como eles devem acessar o cluster?
• Quais fontes têm permissão de acesso?
• Quais permissões eles devem ter no cluster?
• Quando essas permissões são atribuídas?

Verifique se as definições estão documentadas na documentação de governança, na política e nos materiais de treinamento voltados ao operador de carga de trabalho e ao operador de cluster.

Requisito 7.2.3

O padrão configuração é "negar tudo".

Suas responsabilidades

Ao iniciar a configuração, comece com políticas de confiança zero. Faça exceções conforme necessário e documente-as em detalhes.

• O RBAC do Kubernetes implementa negar tudo por padrão. Não substitua adicionando associações de função de cluster altamente permissivas que revertem a configuração de negar tudo.

• O RBAC do Azure também implementa negar tudo por padrão. Não substitua adicionando atribuições de RBAC que revertem a configuração de negar tudo.

• Todos os serviços do Azure, incluindo o Azure Key Vault e o Registro de Contêiner do Azure, negam todas as permissões por padrão.

• Qualquer ponto de acesso administrativo, como uma caixa de salto, deve negar todo o acesso na configuração inicial. Todas as permissões elevadas devem ser definidas explicitamente para substituir a regra de negar tudo.

Requisito 7.3

Garantir que políticas de segurança e procedimentos operacionais para restringir o acesso a dados do titular do cartão estejam documentados, em uso e sejam do conhecimento de todas as partes afetadas.

Suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre os processos e as políticas. Isso inclui políticas de RBAC do Azure e do Kubernetes e políticas de governança organizacional. As pessoas que operam ambientes regulamentados devem ser treinadas, informadas e incentivadas a dar suporte às garantias de segurança. Isso é particularmente importante para as pessoas que fazem parte do processo de aprovação do ponto de vista da política.

Requisito 8 — Identificar e autenticar o acesso aos componentes do sistema

Suporte ao recurso do AKS

Devido à integração do AKS com o Microsoft Entra, você pode utilizar os recursos de autorização e gerenciamento de identidade, incluindo gerenciamento de acesso, gerenciamento de objetos de identificador e outros. Para obter mais informações, consulte Integração do Microsoft Entra gerenciada pelo AKS.

Suas responsabilidades

Requisito	Capacidade de resposta
Requisito 8.1	Definir e implementar políticas e procedimentos para garantir o gerenciamento de identificação de usuário apropriado para usuários e administradores não consumidores em todos os componentes do sistema, da seguinte maneira:
Requisito 8.2	Além de atribuir uma ID exclusiva, garantir o gerenciamento de autenticação de usuário apropriado para usuários e administradores não consumidores em todos os componentes do sistema empregando pelo menos um dos métodos a seguir para autenticar todos os usuários:
Requisito 8.3	Proteger todo o acesso administrativo individual que não seja do console e todo o acesso remoto ao CDE usando autenticação multifator.
Requisito 8.4	Documentar e comunicar as políticas e os procedimentos de autenticação a todos os usuários, incluindo:
Requisito 8.5	Não usar IDs e senhas genéricas, compartilhadas ou de grupo, nem outros métodos de autenticação, conforme o seguinte:
Requisito 8.6	Quando outros mecanismos de autenticação forem usados (por exemplo, tokens de segurança físicos ou lógicos, cartões inteligentes, certificados, etc.), o uso desses mecanismos deve ser atribuído da seguinte maneira:
Requisito 8.7	Todo o acesso a qualquer banco de dados que contenha dados do titular do cartão (incluindo o acesso por aplicativos, administradores e todos os outros usuários) é restrito da seguinte maneira:
Requisito 8.8	Garantir que as políticas de segurança e os procedimentos operacionais para identificação e autenticação estejam documentados, em uso e sejam do conhecimento de todas as partes afetadas.

Requisito 8.1

Definir e implementar políticas e procedimentos para garantir o gerenciamento de identificação de usuário apropriado para usuários e administradores não consumidores em todos os componentes do sistema, da seguinte maneira:

• 8.1.1 Atribua a todos os usuários uma ID exclusiva antes de permitir que eles acessem componentes do sistema ou dados de titular do cartão.
• 8.1.2 Controle a adição, a exclusão e a modificação de IDs de usuário, credenciais e outros objetos identificadores.
• 8.1.3 Revogue imediatamente o acesso para qualquer usuário encerrado.
• 8.1.4 Remover/desabilitar contas de usuário inativas dentro de 90 dias.
• 8.1.5 Gerencie as IDs usadas por terceiros para acessar, dar suporte ou manter os componentes do sistema por meio do acesso remoto, da seguinte maneira:
  • Habilitado somente durante o período de tempo necessário e desabilitado quando não estiver em uso.
  • Monitorado quando em uso.
• 8.1.6 Limite as repetidas tentativas de acesso bloqueando a ID de usuário depois de não mais de seis tentativas.
• 8.1.7 Defina a duração do bloqueio como um mínimo de 30 minutos ou até que um administrador habilite a ID de usuário.
• 8.1.8 Se uma sessão estiver ociosa por mais de 15 minutos, exija que o usuário se autentique novamente para reativar o terminal ou a sessão.

Suas responsabilidades

Aqui estão as considerações gerais sobre este requisito:

APLICA-SE A: 8.1.1, 8.1.2, 8.1.3

Não compartilhe nem reutilize identidades para partes funcionalmente diferentes do CDE. Por exemplo, não use uma conta de equipe para acessar dados ou recursos de cluster. Certifique-se de que a documentação de identidade seja clara quanto a não usar contas compartilhadas.

Estenda essa entidade de segurança de identidade para atribuições de identidade gerenciadas no Azure. Não compartilhe identidades gerenciadas pelo usuário em recursos do Azure. Atribua a cada recurso do Azure a própria identidade gerenciada. Da mesma forma, quando estiver usando a ID de carga de trabalho do Microsoft Entra no cluster do AKS, verifique se cada componente na carga de trabalho recebe a própria identidade em vez de usar uma identidade de escopo amplo. Nunca compartilhe a mesma identidade gerenciada entre ambientes de produção e não produção.

Saiba mais sobre Opções de acesso e identidade do Serviço de Kubernetes do Azure (AKS).

APLICA-SE A: 8.1.2, 8.1.3, 8.1.4

Use a Microsoft Entra ID como o repositório de identidades. Como o cluster e todos os recursos do Azure usam o Microsoft Entra ID, desabilitar ou revogar o acesso de uma entidade se aplica a todos os recursos automaticamente. Se houver componentes sem suporte direto do Microsoft Entra ID, verifique se você tem um processo para remover o acesso. Por exemplo, as credenciais SSH para acessar um jump box podem precisar ser explicitamente removidas se o usuário não for mais válido.

APLICA-SE A: 8.1.5

Aproveite o Microsoft Entra External ID, projetado para hospedar contas B2B (business-to-business) de terceiros, como fornecedores e parceiros, como usuários convidados. Conceda o nível apropriado de acesso usando políticas condicionais para proteger dados corporativos. Essas contas devem ter permissões permanentes mínimas e datas de validade obrigatórias. Para obter mais informações, consulte Colaboração B2B com convidados externos para sua força de trabalho.

Sua organização deve ter um padrão claro e documentado de acesso de fornecedores e semelhantes.

APLICA-SE A: 8.1.6, 8.1.7, 8.1.8

Suas responsabilidades

O Microsoft Entra ID fornece um recurso de bloqueio inteligente para bloquear usuários após tentativas de entrada com falha. A maneira recomendada de implementar bloqueios é com políticas de acesso condicional do Microsoft Entra.

Implemente o bloqueio para componentes que têm suporte para recursos semelhantes, mas não têm suporte do Microsoft Entra ID (por exemplo, computadores habilitados para SSH, como uma caixa de salto). Isso garante que bloqueios estejam habilitados para evitar ou retardar o abuso de tentativas de acesso.

Os nós do AKS não foram projetados para serem acessados rotineiramente. Bloqueie o acesso direto via SSH ou Remote Desktop aos nós do cluster. O acesso SSH só deve ser considerado como parte de esforços avançados de solução de problemas. O acesso deve ser monitorado atentamente e prontamente revertido após a conclusão do evento específico. Se fizer isso, lembre-se de que qualquer alteração no nível do nó pode fazer com que o cluster fique sem suporte.

Requisito 8.2

Além de atribuir uma ID exclusiva, verifique o gerenciamento de autenticação de usuário adequado para administradores e usuários não consumidores em todos os componentes do sistema empregando pelo menos um dos seguintes métodos para autenticar todos os usuários: algo que você sabe, por exemplo, uma senha ou frase secreta; algo que você tem, como um dispositivo de token ou cartão inteligente; algo que você é, por exemplo, biometria.

• 8.2.1 Usando a criptografia forte, processe todas as credenciais de autenticação (como senhas/frases) ilegíveis durante a transmissão e o armazenamento em todos os componentes do sistema.
• 8.2.2 Verifique a identidade do usuário antes de modificar qualquer credencial de autenticação — por exemplo, executando redefinições de senha, provisionando novos tokens ou gerando novas chaves.
• 8.2.3 Senhas/frases secretas devem atender aos seguintes requisitos:
  • Precisam de um comprimento mínimo de sete caracteres.
  • Conter caracteres numéricos e alfabéticos.
• 8.2.4 Altere as senhas de usuário/frases secretas pelo menos uma vez a cada 90 dias.
• 8.2.5 Não permita que um indivíduo envie uma nova senha/frase secreta que seja igual a qualquer uma das últimas quatro senhas/frases secretas que ele tenha usado.
• 8.2.6 Defina senhas/frases secretas para uso pela primeira vez e após a redefinição como um valor exclusivo para cada usuário e altere imediatamente após o primeiro uso.

Suas responsabilidades

Configure políticas de acesso condicional no Microsoft Entra ID para o cluster. Isso acrescenta restrições ao acesso ao painel de controle do Kubernetes.

Vários dos requisitos anteriores são tratados automaticamente pelo Microsoft Entra ID. Veja alguns exemplos:

• Segurança de senha

  O Microsoft Entra ID fornece recursos que impõem o uso de senhas fortes. Por exemplo, senhas fracas que pertencem à lista global de senhas proibidas são bloqueadas. Essa proteção não é suficiente. Para criar uma lista de proibições específica da organização, considere adicionar o recurso Microsoft Entra Password Protection. Uma política de senha é aplicada por padrão. Determinadas políticas não podem ser modificadas e tratam de alguns dos requisitos anteriores. Elas incluem expiração de senha e caracteres permitidos. Para ver a lista completa, confira Políticas de senha do Microsoft Entra. Considere a aplicação avançada usando políticas de acesso condicional, como aquelas baseadas no risco do usuário, que detectam pares de nome de usuário e senha vazados. Para obter mais informações, consulte Acesso Condicional: Acesso Condicional baseado em risco do usuário.

  Observação

  É altamente recomendável que você considere opções sem senha. Para mais informações, veja Planejar uma implantação de autenticação sem senha no Microsoft Entra ID.

• Verificação de identidade do usuário

  Você pode aplicar a política de acesso condicional de risco de credenciais para detectar se a solicitação de autenticação foi emitida pela identidade solicitante. A solicitação é validada com relação a fontes de inteligência contra ameaças. Elas incluem anomalias de endereço IP e pulverização de senha. Para obter mais informações, consulte Acesso Condicional: Acesso Condicional baseado em risco de credenciais.

Você pode ter componentes que não usam o Microsoft Entra ID, como o acesso a caixas de salto com SSH. Para esses casos, use a criptografia de chave pública com pelo menos o tamanho da chave RSA 2048. Sempre especifique uma frase secreta. Tenha um processo de validação que rastreie chaves públicas aprovadas conhecidas. Sistemas que usam acesso à chave pública não devem ser expostos à Internet. Em vez disso, todo o acesso SSH apenas deve ser permitido por meio de um intermediário, como o Azure Bastion, para reduzir o impacto de um vazamento de chave privada. Desabilite o acesso direto à senha e use uma solução alternativa sem senha.

Requisito 8.3

Proteger todo o acesso administrativo individual que não seja do console e todo o acesso remoto ao CDE usando autenticação multifator. Observação: a autenticação multifator requer que pelo menos dois dos três métodos de autenticação (veja no Requisito 8.2 as descrições dos métodos de autenticação) sejam usados para a autenticação. Usar um fator duas vezes (por exemplo, usando duas senhas separadas) não é considerado a autenticação multifator.

Suas responsabilidades

Use políticas de acesso condicional para impor a autenticação multifator, especificamente em contas administrativas. Essas políticas são recomendadas em várias funções internas. Aplique essas políticas a grupos do Microsoft Entra mapeados para funções do Kubernetes com privilégio elevado.

Essa política pode ser ainda mais protegida com políticas adicionais. Veja alguns exemplos:

• Você pode restringir a autenticação a dispositivos gerenciados pelo locatário do Microsoft Entra.
• Se o acesso for proveniente de uma rede fora da rede de cluster, você poderá impor a autenticação multifator.

Para saber mais, veja:

• Acesso condicional: exigir MFA para todos os administradores
• Acesso condicional: exigir dispositivos em conformidade
• Acesso condicional: autenticação multifator baseada em risco de entrada

Requisito 8.4

Documentar e comunicar as políticas e os procedimentos de autenticação a todos os usuários, incluindo:

• Orientação sobre como selecionar credenciais de autenticação fortes
• Diretrizes sobre como os usuários devem proteger as credenciais de autenticação
• Instruções para a não reutilização das senhas usadas anteriormente
• Instruções para a alteração da senha caso haja qualquer suspeita de comprometimento da senha.

Suas responsabilidades

Mantenha a documentação sobre as políticas impostas. Como parte do treinamento de integração de identidade, forneça diretrizes para procedimentos de redefinição de senha e melhores práticas organizacionais sobre a proteção de ativos.

Requisito 8.5

Não usar IDs e senhas genéricas, compartilhadas ou de grupo, nem outros métodos de autenticação, conforme o seguinte:

• As IDs de usuário genéricas são desabilitadas ou removidas.
• As IDs de usuário compartilhadas não existem para a administração do sistema e outras funções críticas.
• As IDs de usuário compartilhadas e genéricas não são usadas para se administrar qualquer componente do sistema.

Suas responsabilidades

Não compartilhe nem reutilize identidades para partes funcionalmente diferentes do cluster ou dos pods. Por exemplo, não use uma conta de equipe para acessar dados ou recursos de cluster. Certifique-se de que a documentação de identidade seja clara quanto a não usar contas compartilhadas.

Desabilite usuários raiz no CDE. Desabilite o uso de contas locais do Kubernetes para que os usuários não possam usar o acesso interno --admin aos clusters dentro do CDE.

Requisito 8.6

Quando outros mecanismos de autenticação forem usados (por exemplo, tokens de segurança físicos ou lógicos, cartões inteligentes, certificados, etc.), o uso desses mecanismos deve ser atribuído da seguinte maneira:

• Os mecanismos de autenticação devem ser atribuídos a uma conta individual e não compartilhados entre várias contas.
• Os controles físicos e/ou lógicos devem estar em vigor para garantir que apenas a conta pretendida possa usar esse mecanismo para obter acesso.

Suas responsabilidades

Verifique se todo o acesso ao CDE é fornecido em identidades por usuário, e isso é estendido para tokens físicos ou virtuais. Isso inclui qualquer acesso VPN à rede CDE, garantindo que o acesso ponto a site da empresa (se houver) use certificados por usuário como parte do fluxo de autenticação.

Requisito 8.7

Todo o acesso a qualquer banco de dados que contenha dados do titular do cartão (incluindo o acesso por aplicativos, administradores e todos os outros usuários) é restrito da seguinte maneira:

• Todo o acesso do usuário, consultas de usuário e ações do usuário nos bancos de dados são feitos por meio de métodos de programação.
• Somente os administradores de banco de dados têm a capacidade de acessar diretamente ou consultar bancos de dados.
• As IDs de aplicativo para aplicativos de banco de dados só podem ser usadas pelos aplicativos (e não por usuários individuais ou outros processos que não sejam por aplicativo).

Suas responsabilidades

Forneça acesso com base em funções e responsabilidades. As pessoas podem usar sua identidade, mas o acesso deve ser restrito de acordo com a necessidade de saber, com permissões permanentes mínimas. As pessoas nunca devem usar identidades de aplicativo, e identidades de acesso ao banco de dados nunca devem ser compartilhadas.

Se possível, acesse bancos de dados de aplicativos por meio de uma identidade gerenciada. Caso contrário, limite a exposição a cadeias de conexão e credenciais. Use segredos do Kubernetes para armazenar informações confidenciais em vez de mantê-las em locais onde elas são facilmente descobertas, como uma definição de pod. Outra maneira é armazenar e carregar segredos de e para um armazenamento gerenciado projetado para dados seguros, como o Azure Key Vault. Com identidades gerenciadas habilitadas em um cluster do AKS, ele precisa se autenticar no Key Vault para obter acesso.

Requisito 8.8

Garantir que as políticas de segurança e os procedimentos operacionais para identificação e autenticação estejam documentados, em uso e sejam do conhecimento de todas as partes afetadas.

Suas responsabilidades

É fundamental que você mantenha uma documentação completa sobre os processos e as políticas. Mantenha a documentação sobre as políticas impostas. Como parte do treinamento de integração de identidade, forneça diretrizes para procedimentos de redefinição de senha e melhores práticas organizacionais sobre a proteção de ativos. As pessoas que operam ambientes regulamentados devem ser treinadas, informadas e incentivadas a dar suporte às garantias de segurança. Isso é particularmente importante para as pessoas que fazem parte do processo de aprovação do ponto de vista da política.

Requisito 9 — Restringir o acesso físico aos dados do titular do cartão

Suporte ao recurso do AKS

Não há nenhum recurso do AKS pertinente para esse requisito.

Suas responsabilidades

Essa arquitetura e a implementação não têm a finalidade de fornecer controles de acesso físico a datacenters ou recursos locais. Para ver outras considerações, confira as diretrizes no padrão oficial PCI-DSS 3.2.1.

Aqui estão algumas sugestões para aplicar controles técnicos:

• Ajuste os tempos limite da sessão em qualquer acesso administrativo ao console, como caixas de salto no CDE, para minimizar o acesso.

• Ajuste as políticas de acesso condicional para minimizar a TTL em tokens de acesso do Azure de pontos de acesso, como o portal do Azure. Para obter informações, consulte estes artigos:

  • Configurar políticas de tempo de vida de sessão adaptável
  • Tempos de vida de token configuráveis na plataforma de identidade da Microsoft

• Para o CDE hospedado na nuvem, não há nenhuma responsabilidade por gerenciar o acesso físico e o hardware. Conte com controles físicos e lógicos de rede corporativa.

• Minimize a exportação de backups de CHD para destinos locais. Use soluções hospedadas no Azure para limitar o acesso físico a backups.

• Minimize backups para o local. Se isso for necessário, lembre-se de que o destino local estará no escopo da auditoria.

Próximas etapas

Controlar e monitorar todo o acesso aos recursos da rede e aos dados do titular do cartão. Testar regularmente os sistemas e processos de segurança.