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

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

Essa arquitetura e a implementação não foram projetadas para fornecer controles sobre o acesso físico a recursos locais ou datacenters. Um benefício de hospedar seu CDE no Azure, em oposição à sua plataforma na borda ou em seu datacenter, é que a restrição de acesso físico já é principalmente tratada por meio da segurança do datacenter do Azure. Não há quaisquer responsabilidades para a organização na gestão de hardware físico.

Implementar fortes medidas de controlo de acesso

Requisito 7 — Restringir o acesso aos dados do titular do cartão por necessidade de conhecimento da empresa

Suporte ao recurso AKS

O AKS está totalmente integrado com o Microsoft Entra ID como provedor de identidade.

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

Por padrão, o RBAC do Azure é definido para negar todo o acesso, portanto, um recurso não pode ser acessado sem que as permissões sejam concedidas. O AKS limita o acesso SSH aos nós de trabalho do AKS e usa a política de rede 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 a Política do Azure.

As suas responsabilidades

Necessidade	Responsabilidade
Requisito 7.1	Limitar o acesso aos componentes do sistema e aos dados do titular do cartão apenas aos indivíduos cujo trabalho exija esse acesso.
Requisito 7.2	Estabeleça um sistema de controle de acesso para componentes de sistemas que restrinja o acesso com base na necessidade de conhecimento do usuário e seja definido para "negar tudo", a menos que especificamente permitido.
Requisito 7.3	Garantir que as políticas de segurança e os procedimentos operacionais para restringir o acesso aos dados do titular do cartão estejam documentados, em uso e conhecidos por todas as partes afetadas.

Requisito 7.1

Limitar o acesso aos componentes do sistema e aos dados do titular do cartão apenas aos indivíduos cujo trabalho exija esse acesso.

As suas responsabilidades

Aqui estão algumas considerações:

• Certifique-se de que sua implementação esteja alinhada com os requisitos da organização e com os requisitos de conformidade sobre gerenciamento de identidade.
• Minimize as permissões permanentes, especialmente para contas de impacto crítico.
• Siga o princípio do acesso com privilégios mínimos. Forneça apenas acesso suficiente para concluir a tarefa.

Requisito 7.1.1

Defina as necessidades de acesso para cada função, incluindo:

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

As suas responsabilidades

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

• Âmbito por grupos de gestão, subscrições ou grupos de recursos do Azure
• Política do Azure para a carga de trabalho ou subscrição
• Operações de contentores
• Gestão de segredos
• Pipelines de compilação e implantação

Embora a definição de funções e responsabilidades em torno dessas áreas possa estar associada à estrutura da 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. Seguem-se alguns exemplos:

• Decida configurações para segurança de aplicativos, Kubernetes RBAC, 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 aplicativos Web (WAF), os NSGs (grupos de segurança de rede) e o DNS.
• Monitore e corrija a segurança do servidor, a aplicação de patches, a configuração e a segurança do ponto final.
• Defina a direção para o uso do RBAC, do Microsoft Defender for Cloud, da estratégia de proteção do administrador e da Política do Azure para governar os recursos do Azure.
• Identificar a equipe de monitoramento e resposta a incidentes. Investigue e corrija incidentes de segurança usando um sistema de gerenciamento de eventos e informações de segurança (SIEM), como o Microsoft Sentinel ou o Microsoft Defender for Cloud.

Em seguida, formalize 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.

Role	Responsabilidades	Níveis de acesso
Proprietários de aplicativos	Defina e priorize 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 dos dados do cliente com os objetivos de negócios.	Acesso de leitura a logs e métricas emitidos pelo aplicativo. Eles não precisam de permissões para acessar a carga de trabalho ou o cluster.
Programadores de aplicações	Desenvolva a aplicação. Todo o código do aplicativo está sujeito a treinamentos e portas de qualidade que garantem a conformidade, o atestado e os processos de gerenciamento de liberação. Pode gerenciar os pipelines de compilação, mas geralmente não os pipelines de implantação.	Acesso de leitura a namespaces do Kubernetes e recursos do Azure que estão no escopo da carga de trabalho. Nenhum acesso de gravação para implantar ou modificar qualquer estado do sistema.
Operadores de aplicação (ou SRE)	Ter uma compreensão profunda da base de código, observabilidade e operações. Faça a triagem ao vivo e a solução de problemas. Junto com os desenvolvedores de aplicativos, melhore a disponibilidade, a escalabilidade e o desempenho do aplicativo. Gerencie o pipeline de implantação de "última milha" e ajude a gerenciar os pipelines de compilação.	Altamente privilegiado dentro do escopo do aplicativo que inclui namespaces Kubernetes relacionados e recursos do Azure. Provavelmente têm acesso permanente a partes do cluster Kubernetes.
Proprietários de infraestruturas	Projete uma arquitetura econômica, incluindo sua conectividade e a funcionalidade dos componentes. O escopo pode incluir serviços na nuvem e no local. Decida recursos, retenção de dados, recursos de continuidade de negócios e outros.	Acesso a logs da 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 serviços dependentes. Crie, implante e inicialize o pipeline para o cluster no qual a carga de trabalho é implantada. Defina pools de nós de destino e os requisitos esperados de dimensionamento e dimensionamento. Monitore a integridade da infraestrutura de hospedagem de contêiner e dos serviços dependentes.	Acesso de leitura a namespaces de carga de trabalho. Acesso altamente privilegiado para o cluster.
Política, proprietários de segurança	Ter experiência em segurança ou conformidade com regulamentos. 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. Trabalha 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. Também acesso a dados de log e auditoria.
Operadores de rede	Alocação de redes virtuais e sub-redes em toda a empresa. Configuração e manutenção do Firewall do Azure, WAF, NSGs e configuração de DNS.	Altamente privilegiado na camada de rede. Nenhuma permissão de gravação dentro do cluster.

Requisito 7.1.2

Restrinja o acesso a IDs de usuário privilegiados aos privilégios mínimos necessários para executar responsabilidades de trabalho.

As suas responsabilidades

Com base nas funções do trabalho, esforce-se para minimizar o acesso sem causar interrupções. Aqui estão algumas melhores práticas:

• Reduza o acesso que cada identidade exige. Uma identidade deve ter acesso suficiente para concluir sua tarefa.
• Minimize as permissões permanentes, especialmente em identidades de impacto crítico que têm acesso a componentes no escopo.
• Adicione restrições adicionais sempre que possível. Uma forma é fornecer acesso condicional com base em critérios de acesso.
• Realize uma revisão e auditoria regulares de usuários e grupos que têm acesso em suas assinaturas, mesmo para acesso de leitura. Evite convidar identidades externas.

Requisito 7.1.3

Atribua acesso com base na classificação de trabalho e função de cada pessoal.

As suas responsabilidades

Determine as permissões com base nas tarefas de trabalho claramente atribuídas pelo indivíduo. Evite parâmetros como o sistema ou a permanência do funcionário. Conceda direitos de acesso a um único utilizador ou a um grupo.

Seguem-se alguns exemplos.

Classificação das funções	Role
Um proprietário de produto define o escopo da carga de trabalho e prioriza os recursos. Equilibra a proteção e a propriedade dos dados dos clientes com os objetivos de negócios. Precisa de acesso a relatórios, ao centro de custo ou aos painéis do Azure. Nenhum acesso é necessário para permissões no cluster ou no nível do cluster.	Proprietários de aplicativos
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 Application Insights) e os namespaces de carga de trabalho. Esses escopos e permissões podem ser diferentes entre ambientes de pré-produção e produção.	Desenvolvedor de aplicativos
Um engenheiro de confiabilidade do local faz a triagem do local ao vivo, gerencia pipelines e configura a infraestrutura de aplicativos. Grupo A com controle total dentro de seus namespaces alocados. Não são necessárias permissões permanentes. Grupo B para operações diárias sobre a carga de trabalho. Ele pode ter permissões permanentes dentro de seus namespaces alocados, mas não são altamente privilegiados.	Operadores de aplicação
Um operador de cluster projeta e implanta um cluster AKS confiável e seguro na plataforma. Responsável por manter o tempo de funcionamento do cluster. Grupo A com controle total dentro de seus namespaces alocados. Não são necessárias permissões permanentes. Grupo B para operações diárias sobre a carga de trabalho. Ele pode ter permissões permanentes dentro de seus namespaces alocados, mas não são altamente privilegiados.	Operadores de infraestruturas
Um engenheiro de rede aloca rede virtual e sub-redes em toda a empresa, conectividade local para nuvem e segurança de rede.	Operadores de infraestruturas

Requisito 7.1.4

Requer aprovação documentada por partes autorizadas especificando os privilégios necessários.

As suas responsabilidades

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

Requisito 7.2

Estabeleça um sistema de controle de acesso para componentes de sistemas que restrinja o acesso com base na necessidade de conhecimento do usuário e seja definido para "negar tudo", a menos que especificamente permitido.

As suas responsabilidades

Depois de 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 da arquitetura que estão no escopo devem ter acesso restrito. Isso inclui os nós AKS que executam a carga de trabalho, o armazenamento de dados, o acesso à rede e todos os outros serviços que participam do processamento dos dados do titular do cartão (CHD).

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

• O RBAC do Kubernetes é um modelo de autorização nativo do Kubernetes que controla o acesso ao plano de controle do Kubernetes, exposto através 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 listar pods.
• O Azure RBAC é um modelo de autorização baseado em ID do Microsoft Entra que controla o acesso ao plano de controle do Azure. Esta é uma associação do seu 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 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 às quais são atribuídas as responsabilidades de operador de infraestrutura pertencem a um grupo do Microsoft Entra. Conforme estabelecido na versão 7.1.1, essa função requer o privilégio mais alto no cluster. O Kubernetes tem funções RBAC integradas, como cluster-admin, que atende a esses requisitos. Você precisará vincular o grupo Microsoft Entra para operador de infraestrutura criando cluster-admin associações de função. Existem 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 suas associações.

A implementação de referência demonstra o exemplo anterior usando o RBAC nativo do Kubernetes. A mesma associação pode ser realizada com o Azure RBAC. 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 Kubernetes do Azure.

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

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

Além das pessoas e suas funções, os recursos do Azure e até mesmo os pods dentro do cluster gerenciaram identidades. Essas identidades precisam de um conjunto de permissões por meio do RBAC do Azure e devem ter um escopo rigoroso com base nas tarefas esperadas. Por exemplo, o Gateway de Aplicativo do Azure deve ter permissões para obter segredos (certificados TLS) do Cofre de Chaves do Azure. Ele não deve ter permissões para modificar segredos.

Aqui estão algumas melhores práticas:

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

• Monitore as funções em busca de alterações, como em alterações de atribuição ou definições de função. Crie alertas sobre alterações, mesmo que sejam esperadas, para obter visibilidade das intenções por trás das alterações.

Requisito 7.2.1

Cobertura de todos os componentes do sistema

As suas responsabilidades

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

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

• Configure políticas de acesso condicional no Microsoft Entra ID para o cluster. Isso coloca ainda mais restrições no acesso ao plano de controle do Kubernetes. Com as políticas de acesso condicional, pode exigir autenticação multifator, restringir a autenticação a dispositivos geridos pelo inquilino do Microsoft Entra ou bloquear tentativas de início de sessão atípicas. Aplique essas políticas a grupos do Microsoft Entra mapeados para funções do Kubernetes com alto privilégio.

  Nota

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

• Idealmente, desative o acesso SSH aos nós do cluster. Esta implementação de referência não gera detalhes de conexão SSH para essa finalidade.

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

Requisito 7.2.2

Atribuição de privilégios a indivíduos com base na classificação do cargo e função.

As suas responsabilidades

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

Por exemplo, considere a função de operador de cluster. Devem ter um manual claramente definido para as atividades de triagem de agrupamentos. Qual é a diferença entre esse acesso e a equipe de carga de trabalho? Dependendo da sua organização, eles podem ser os mesmos. Aqui estão alguns pontos a considerar:

• Como eles devem acessar o cluster?
• Que fontes são permitidas para acesso?
• Que permissões eles devem ter no cluster?
• Quando essas permissões são atribuídas?

Certifique-se de que as definições estejam documentadas na documentação de governança, na política e nos materiais de treinamento em torno do operador de carga de trabalho e do operador de cluster.

Requisito 7.2.3

Configuração padrão "negar tudo".

As 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 invertem a configuração negar tudo.

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

• Todos os serviços do Azure, incluindo o Azure Key Vault e o Azure Container Registry, 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 negar tudo.

Requisito 7.3

Garantir que as políticas de segurança e os procedimentos operacionais para restringir o acesso aos dados do titular do cartão 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. Isso inclui políticas RBAC do Azure e do Kubernetes e políticas de governança organizacional. As pessoas que operam ambientes regulamentados devem ser educadas, informadas e incentivadas a apoiar as garantias de segurança. Isto é particularmente importante para as pessoas que fazem parte do processo de aprovação do ponto de vista político.

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

Suporte ao recurso AKS

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

As suas responsabilidades

Necessidade	Responsabilidade
Requisito 8.1	Defina e implemente políticas e procedimentos para garantir o gerenciamento adequado da identificação de 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, garanta o gerenciamento adequado de autenticação de usuário para usuários não consumidores e administradores em todos os componentes do sistema, empregando pelo menos um dos seguintes métodos para autenticar todos os usuários:
Requisito 8.3	Proteja todo o acesso administrativo individual não console e todo o acesso remoto ao CDE usando autenticação multifator.
Requisito 8.4	Documentar e comunicar procedimentos e políticas e procedimentos de autenticação a todos os utilizadores, incluindo:
Requisito 8.5	Não use IDs de grupo, compartilhadas ou genéricas, senhas ou outros métodos de autenticação da seguinte maneira:
Requisito 8.6	Quando forem utilizados outros mecanismos de autenticação (por exemplo, fichas de segurança físicas ou lógicas, cartões inteligentes, certificados, etc.), a utilização desses mecanismos deve ser atribuída do seguinte modo:
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 forma:
Requisito 8.8	Certifique-se de que as políticas de segurança e os procedimentos operacionais para identificação e autenticação estejam documentados, em uso e conhecidos por todas as partes afetadas.

Requisito 8.1

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

• 8.1.1 Atribua a todos os utilizadores um ID único antes de lhes permitir aceder aos componentes do sistema ou aos dados do titular do cartão.
• 8.1.2 Controle a adição, exclusão e modificação de IDs de usuário, credenciais e outros objetos identificadores.
• 8.1.3 Revogar imediatamente o acesso de quaisquer utilizadores terminados.
• 8.1.4 Remover/desativar contas de utilizador inativas no prazo de 90 dias.
• 8.1.5 Gerir IDs utilizados por terceiros para aceder, suportar ou manter componentes do sistema através de acesso remoto da seguinte forma:
  • Ativado apenas durante o período de tempo necessário e desativado quando não está em uso.
  • Monitorizado quando em uso.
• 8.1.6 Limite as tentativas repetidas de acesso bloqueando o ID do usuário após não mais de seis tentativas.
• 8.1.7 Defina a duração do bloqueio para um mínimo de 30 minutos ou até que um administrador ative o ID do 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.

As suas responsabilidades

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

APLICA-SE A: 8.1.1, 8.1.2, 8.1.3

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

Estenda essa entidade de identidade para atribuições de identidade gerenciadas no Azure. Não partilhe identidades geridas pelo utilizador entre recursos do Azure. Atribua a cada recurso do Azure sua própria identidade gerenciada. Da mesma forma, quando você estiver usando o ID de carga de trabalho do Microsoft Entra no cluster AKS, certifique-se de que cada componente em sua carga de trabalho receba sua própria identidade em vez de usar uma identidade de amplo escopo. Nunca partilhe a mesma identidade gerida entre ambientes de produção e não produção.

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

APLICA-SE A: 8.1.2, 8.1.3, 8.1.4

Use o Microsoft Entra ID como o armazenamento de identidade. Como o cluster e todos os recursos do Azure usam a ID do Microsoft Entra, desabilitar ou revogar o acesso de uma entidade de segurança se aplica a todos os recursos automaticamente. Se houver algum componente que não é apoiado diretamente pelo Microsoft Entra ID, certifique-se de ter um processo para remover o acesso. Por exemplo, as credenciais SSH para acessar uma caixa de salto podem precisar ser explicitamente removidas se o usuário não for mais válido.

APLICA-SE A: 8.1.5

Aproveite a ID Externa do Microsoft Entra projetada 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 os dados corporativos. Essas contas devem ter permissões permanentes mínimas e datas de expiração 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 fornecedor e acesso semelhante.

APLICA-SE EM: 8.1.6, 8.1.7, 8.1.8

As suas responsabilidades

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

Implemente o bloqueio para componentes que suportam recursos semelhantes, mas não são apoiados com o Microsoft Entra ID (por exemplo, máquinas habilitadas para SSH, como uma caixa de salto). Isso garante que os bloqueios estejam habilitados para evitar ou retardar o abuso de tentativas de acesso.

Os nós AKS não são projetados para serem acessados rotineiramente. Bloqueie o acesso direto a SSH ou Área de Trabalho Remota aos nós do cluster. O acesso SSH só deve ser considerado como parte dos esforços avançados de solução de problemas. O acesso deve ser acompanhado de perto e prontamente revertido após a conclusão do evento específico. Se você fizer isso, esteja ciente de que quaisquer alterações no nível do nó podem fazer com que seu cluster fique sem suporte.

Requisito 8.2

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

• 8.2.1 Usando criptografia forte, torne 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, executar redefinições de senha, provisionar novos tokens ou gerar novas chaves.
• 8.2.3 As senhas/frases devem atender aos seguintes requisitos:
  • Requer um comprimento mínimo de pelo menos sete caracteres.
  • Contêm caracteres numéricos e alfabéticos.
• 8.2.4 Alterar senhas/frases secretas do usuário pelo menos uma vez a cada 90 dias.
• 8.2.5 Não permita que um indivíduo envie uma nova senha/frase que seja igual a qualquer uma das últimas quatro senhas/frases que ele ou ela usou.
• 8.2.6 Defina senhas/frases para uso pela primeira vez e após a redefinição para um valor exclusivo para cada usuário, e altere imediatamente após o primeiro uso.

As suas responsabilidades

Configure as Políticas de Acesso Condicional na ID do Microsoft Entra para o cluster. Isso coloca ainda mais restrições no acesso ao plano de controle do Kubernetes.

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

• Segurança da palavra-passe

  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. Esta proteção não é suficiente. Para criar uma lista de banimento específica da organização, considere adicionar o recurso Proteção por Senha do Microsoft Entra. Uma política de senha é aplicada por padrão. Algumas políticas não podem ser modificadas e abrangem alguns dos requisitos anteriores. Estes incluem a expiração da palavra-passe e os caracteres permitidos. Para obter a lista completa, consulte 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 detetam 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.

  Nota

  Recomendamos vivamente que considere opções sem palavra-passe. Para obter mais informações, consulte 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 entrada para detetar se a solicitação de autenticação foi emitida pela identidade solicitante. O pedido é validado contra fontes de informações sobre ameaças. Estes incluem spray de senha e anomalias de endereço IP. Para obter mais informações, consulte Acesso condicional: acesso condicional baseado em risco de entrada.

Você pode ter componentes que não usam o Microsoft Entra ID, como acesso a caixas de salto com SSH. Para esses casos, use criptografia de chave pública com pelo menos o tamanho de chave RSA 2048. Especifique sempre uma frase secreta. Tenha um processo de validação que rastreie chaves públicas aprovadas conhecidas. Os sistemas que utilizam o acesso à chave pública não devem ser expostos à Internet. Em vez disso, todo o acesso SSH só deve ser permitido através de um intermediário, como o Azure Bastion, para reduzir o impacto de uma fuga de chave privada. Desative o acesso direto à senha e use uma solução alternativa sem senha.

Requisito 8.3

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

As 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 alto privilégio.

Esta política pode ser reforçada com políticas adicionais. Seguem-se alguns exemplos:

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

Para obter mais informações, consulte:

• Acesso condicional: Exigir MFA para administradores
• Acesso condicional: Requer dispositivos compatíveis
• Acesso condicional: autenticação multifator baseada em risco de entrada

Requisito 8.4

Documentar e comunicar procedimentos e políticas e procedimentos de autenticação a todos os utilizadores, incluindo:

• Orientação sobre como selecionar credenciais de autenticação forte
• Orientações sobre como os usuários devem proteger suas credenciais de autenticação
• Instruções para não reutilizar palavras-passe utilizadas anteriormente
• Instruções para alterar senhas se houver alguma suspeita de que a senha pode ser comprometida.

As suas responsabilidades

Manter a documentação sobre as políticas aplicadas. Como parte de seu treinamento de integração de identidade, forneça orientação para procedimentos de redefinição de senha e práticas recomendadas organizacionais sobre proteção de ativos.

Requisito 8.5

Não use IDs de grupo, compartilhadas ou genéricas, senhas ou outros métodos de autenticação da seguinte maneira:

• Os IDs de utilizador genéricos são desativados ou removidos.
• Os IDs de utilizador partilhados não existem para a administração do sistema e outras funções críticas.
• IDs de usuário compartilhados e genéricos não são usados para administrar nenhum componente do sistema.

As suas responsabilidades

Não compartilhe ou reutilize identidades para partes funcionalmente diferentes do cluster ou pods. Por exemplo, não use uma conta de equipe para acessar dados ou recursos de cluster. Verifique se a documentação de identidade é clara sobre não usar contas compartilhadas.

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

Requisito 8.6

Quando forem utilizados outros mecanismos de autenticação (por exemplo, fichas de segurança físicas ou lógicas, cartões inteligentes, certificados, etc.), a utilização desses mecanismos deve ser atribuída do seguinte modo:

• Os mecanismos de autenticação devem ser atribuídos a uma conta individual e não compartilhados entre várias contas.
• Devem existir controlos físicos e/ou lógicos para garantir que apenas a conta pretendida pode utilizar esse mecanismo para obter acesso.

As suas responsabilidades

Certifique-se de que todo o acesso ao CDE seja fornecido em identidades por usuário, e isso seja estendido a quaisquer tokens físicos ou virtuais. Isso inclui qualquer acesso VPN à rede CDE, garantindo que o acesso corporativo ponto a site (se houver) use certificados por usuário como parte desse 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 forma:

• Todos os acessos, consultas de usuários e ações de usuários em bancos de dados são feitos por meio de métodos programáticos.
• Somente os administradores de banco de dados têm a capacidade de acessar ou consultar bancos de dados diretamente.
• 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 aplicativos).

As suas responsabilidades

Forneça acesso com base em funções e responsabilidades. As pessoas podem usar a sua identidade, mas o acesso deve ser restringido com base na necessidade de conhecimento, com permissões permanentes mínimas. As pessoas nunca devem usar identidades de aplicativos e as 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 repositório gerenciado projetado para dados seguros, como o Azure Key Vault. Com as identidades gerenciadas habilitadas em um cluster AKS, ele precisa se autenticar no Cofre da Chave para obter acesso.

Requisito 8.8

Certifique-se de que as políticas de segurança e os procedimentos operacionais para identificação e autenticação 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. Manter a documentação sobre as políticas aplicadas. Como parte de seu treinamento de integração de identidade, forneça orientação para procedimentos de redefinição de senha e práticas recomendadas organizacionais sobre proteção de ativos. As pessoas que operam ambientes regulamentados devem ser educadas, informadas e incentivadas a apoiar as garantias de segurança. Isto é particularmente importante para as pessoas que fazem parte do processo de aprovação do ponto de vista político.

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

Suporte ao recurso AKS

Não existem quaisquer funcionalidades AKS aplicáveis a este requisito.

As suas responsabilidades

Essa arquitetura e a implementação não foram projetadas para fornecer controles sobre o acesso físico a recursos locais ou datacenters. Para obter considerações, consulte as orientações no padrão oficial PCI-DSS 3.2.1.

Aqui estão algumas sugestões para a aplicação de controles técnicos:

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

• Ajuste as políticas de acesso condicional para minimizar o TTL nos tokens de acesso do Azure a partir 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 CDE hospedado na nuvem, não há responsabilidades pelo gerenciamento de acesso físico e hardware. Confie nos controles físicos e lógicos da rede corporativa.

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

• Minimize os backups no local. Se isso for necessário, esteja ciente de que o destino local estará no escopo da auditoria.

Próximos passos

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