Proteção de dados para um cluster regulado AKS para PCI DSS 4.0.1

Este artigo descreve considerações de proteção de dados para um cluster do Serviço Kubernetes do Azure (AKS) que executa uma carga de trabalho em conformidade com o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI-DSS 4.0.1).

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

Essa arquitetura e a implementação são focadas na infraestrutura e não na carga de trabalho. Este artigo fornece considerações gerais e práticas recomendadas para ajudá-lo a tomar decisões de design. Siga os requisitos da norma oficial PCI-DSS 4.0.1 e use este artigo como informação adicional, quando aplicável.

Proteja os dados do titular do cartão

Requisito 3: Proteger os dados armazenados do titular do cartão

As suas responsabilidades

Requisito 3.1

Mantenha o armazenamento de dados do titular do cartão ao mínimo, implementando políticas, procedimentos e processos de retenção e eliminação de dados que incluam pelo menos o seguinte para todo o armazenamento de dados do titular do cartão (CHD):

• Limitar a quantidade de armazenamento de dados e o tempo de retenção ao que é necessário para requisitos legais, regulamentares e de negócios.
• Processos para exclusão segura de dados quando não são mais necessários.
• Requisitos específicos de retenção para os dados do titular do cartão.
• Um processo trimestral para identificar e excluir com segurança os dados armazenados do titular do cartão que excedem a retenção definida.

As suas responsabilidades (PCI DSS 4.0.1)

Não armazene o estado no cluster AKS. Se você optar por armazenar CHD, explore opções de armazenamento seguro. As opções incluem o Armazenamento do Azure para armazenamento de arquivos ou bancos de dados como o Banco de Dados SQL do Azure ou o Azure Cosmos DB. O PCI DSS 4.0.1 permite uma abordagem personalizada para atender aos objetivos de segurança, mas você deve documentar e justificar quaisquer controles alternativos.

Siga estritamente a orientação padrão sobre que tipo de CHD pode ser armazenado. Defina políticas de retenção de dados com base em seus requisitos de negócios e no tipo de armazenamento usado. As principais considerações incluem:

• Como e onde são armazenados os dados?
• Os dados armazenados são encriptados?
• Qual é o período de retenção?
• Que ações são permitidas durante o período de retenção?
• Como você está excluindo os dados armazenados após o período de retenção ter expirado?

Tenha políticas de governança em torno de algumas dessas escolhas. As políticas internas do Azure impõem essas opções. Por exemplo, você pode restringir os tipos de volume nos pods de cluster ou negar operações de gravação no sistema de arquivos raiz.

Revise a lista de definições de política e aplique-as ao cluster, quando aplicável.

Talvez seja necessário armazenar dados em cache temporariamente. Recomendamos que você proteja os dados armazenados em cache enquanto eles são movidos para uma solução de armazenamento. Considere ativar o recurso de criptografia baseada em host no AKS. Isso criptografará os dados armazenados nas VMs do nó. Para obter mais informações, consulte Criptografia baseada em host no Serviço Kubernetes do Azure (AKS). Além disso, habilite uma política interna do Azure que exija criptografia de discos temporários e cache para pools de nós.

Ao escolher uma tecnologia de armazenamento, explore os recursos de retenção. Por exemplo, o Armazenamento de Blobs do Azure fornece políticas de retenção baseadas no tempo. Outra opção é implementar uma solução personalizada que exclua dados de acordo com as políticas de retenção. Um exemplo é o Data Lifecycle Management (DLM), que gerencia as atividades do ciclo de vida dos dados. A solução foi projetada com serviços como Azure Data Factory, Microsoft Entra ID e Azure Key Vault. O PCI DSS 4.0.1 enfatiza o monitoramento contínuo e avaliações de risco regulares para todos os processos de armazenamento e retenção de dados.

Para obter mais informações, consulte Gerenciando o ciclo de vida dos dados usando o Azure Data Factory.

Requisito 3.2

Não armazene dados confidenciais de autenticação após a autorização (mesmo que criptografados). Se dados de autenticação confidenciais forem recebidos, torne todos os dados irrecuperáveis após a conclusão do processo de autorização.

As suas responsabilidades

O processamento e a proteção de dados são uma preocupação de carga de trabalho e estão além do escopo dessa arquitetura. Aqui estão algumas considerações gerais:

De acordo com o padrão, os dados de autenticação confidenciais consistem em dados de rastreamento completos, código ou valor de validação do cartão e dados PIN. Como parte do processamento CHD, certifique-se de que os dados de autenticação não sejam expostos em fontes como logs, rotinas de tratamento de exceções, nomes de arquivos ou caches. O PCI DSS 4.0.1 requer monitoramento e registro expandidos para detetar e responder ao acesso não autorizado ou armazenamento de dados confidenciais de autenticação, incluindo:

• Logs que são emitidos a partir dos pods.
• Rotinas de tratamento de exceções.
• Nomes de ficheiros.
• Caches.

Como orientação geral, os comerciantes não devem armazenar essas informações. Se houver necessidade, documente a justificativa do negócio.

Requisito 3.3

Mascare o PAN quando exibido (os primeiros seis e os últimos quatro dígitos são o número máximo de dígitos a serem exibidos), de modo que apenas o pessoal com uma necessidade comercial legítima possa ver o PAN completo.

As suas responsabilidades

O número de conta principal (PAN) é considerado um dado sensível e a exposição a esses dados deve ser evitada. Uma maneira é reduzir os dígitos exibidos através do mascaramento. O PCI DSS 4.0.1 esclarece os requisitos de mascaramento e permite uma abordagem personalizada, se justificada e documentada.

Não implemente o mascaramento de dados na carga de trabalho. Em vez disso, use construções no nível do banco de dados. A linha de serviços SQL do Azure, incluindo o Azure Synapse Analytics, oferece suporte ao mascaramento dinâmico de dados, o que reduz a exposição na camada de aplicativo. É um recurso de segurança baseado em políticas que define quem pode visualizar os dados não mascarados e quantos dados são expostos por meio do mascaramento. O método interno de mascaramento de cartão de crédito expõe os últimos quatro dígitos dos campos designados e adiciona uma cadeia de caracteres constante como um prefixo na forma de um cartão de crédito.

Para obter mais informações, consulte Mascaramento dinâmico de dados.

Se você precisar trazer dados não mascarados para o cluster, mascare o mais rápido possível.

Requisito 3.4

Torne o PAN ilegível em qualquer lugar em que esteja armazenado (inclusive em mídia digital portátil, mídia de backup e em logs) usando qualquer uma das seguintes abordagens:

• Hashes unidirecionais baseados em criptografia forte (hash deve ser de todo o PAN).
• Truncamento (hashing não pode ser usado para substituir o segmento truncado do PAN).
• Tokens de índice e pads (os pads devem ser armazenados com segurança).
• Criptografia forte com processos e procedimentos de gerenciamento de chaves associados.

As suas responsabilidades

Para esse requisito, talvez seja necessário usar criptografia direta na carga de trabalho. O PCI DSS 4.0.1 atualiza os requisitos criptográficos para se alinhar com os padrões da indústria em evolução. Use apenas algoritmos testados e aprovados pelo setor (como AES, RSA, etc.) e evite algoritmos de criptografia personalizados. Certifique-se de que os controles criptográficos sejam monitorados e testados continuamente.

Técnicas apropriadas de mascaramento de dados também atendem a esse requisito. Você é responsável por mascarar todos os dados do número de conta principal (PAN). A linha de serviços SQL do Azure, incluindo o Azure Synapse Analytics, dá suporte ao mascaramento dinâmico de dados. Consulte o Requisito 3.3. O PCI DSS 4.0.1 requer que o mascaramento e os controles criptográficos sejam documentados e sujeitos a revisão contínua.

Certifique-se de que o PAN não está exposto como parte dos seus processos de fluxo de trabalho. Aqui estão algumas considerações:

• Mantenha a PAN fora dos logs, dos logs de fluxo de trabalho e dos logs de tratamento de exceções (esperados ou inesperados). Além disso, os fluxos de dados de diagnóstico, como cabeçalhos HTTP, não devem expor esses dados.
• Não use PAN como uma chave de pesquisa de cache ou como parte de qualquer nome de arquivo gerado por esse processo.
• Seus clientes podem fornecer PAN em campos de texto de forma livre sem solicitação. Certifique-se de que os processos de validação e deteção de conteúdo estejam em vigor para quaisquer campos de texto de forma livre, limpando todo o conteúdo que se assemelhe a dados PAN.

Requisito 3.4.1

Se a criptografia de disco for usada (em vez da criptografia de banco de dados em nível de arquivo ou coluna), o acesso lógico deverá ser gerenciado separadamente e independentemente dos mecanismos nativos de autenticação e controle de acesso do sistema operacional (por exemplo, não usando bancos de dados de conta de usuário local ou credenciais gerais de login de rede). As chaves de desencriptação não devem ser associadas a contas de utilizador. O PCI DSS 4.0.1 esclarece ainda mais os requisitos de gerenciamento de chaves e separação de acesso.

As suas responsabilidades

Como regra geral, não armazene o estado no cluster AKS. Use um armazenamento de dados externo que ofereça suporte à criptografia no nível do mecanismo de armazenamento.

Todos os dados armazenados no Armazenamento do Azure são criptografados e descriptografados usando criptografia forte. A Microsoft gerencia as chaves associadas. As chaves de criptografia autogerenciadas são preferidas. Sempre criptografe fora da camada de armazenamento e escreva apenas dados criptografados na mídia de armazenamento, garantindo que as chaves nunca sejam adjacentes à camada de armazenamento.

Com o Armazenamento do Azure, você também pode usar chaves autogerenciadas. Para obter detalhes, consulte Chaves gerenciadas pelo cliente para criptografia de armazenamento do Azure.

Recursos semelhantes estão disponíveis para bancos de dados. Para opções SQL do Azure, consulte Criptografia de dados transparente do SQL do Azure com chave gerenciada pelo cliente.

Certifique-se de armazenar suas chaves em um armazenamento de chaves gerenciado, como o Azure Key Vault, o Azure Managed HSM ou uma solução de gerenciamento de chaves de terceiros.

Se você precisar armazenar dados temporariamente, habilite o recurso de criptografia de host do AKS para garantir que os dados armazenados nos nós da VM sejam criptografados.

Requisito 3.5

Documentar e implementar procedimentos para proteger as chaves usadas para proteger os dados armazenados do titular do cartão contra divulgação e uso indevido.

As suas responsabilidades

Aplicam-se as seguintes responsabilidades:

• Manter a prática de acesso de privilégios mínimos para as chaves criptográficas.
• O Azure Key Vault e o Microsoft Entra ID foram concebidos para suportar os requisitos de autorização e registo de auditoria. Para obter detalhes, consulte Solicitar autenticação para o Cofre da Chave do Azure.
• Proteja todas as chaves de criptografia de dados com uma chave de criptografia de chave armazenada em um dispositivo criptográfico.
• Se você usar chaves autogerenciadas (em vez de chaves gerenciadas pela Microsoft), tenha um processo e documentação para manter tarefas relacionadas ao gerenciamento de chaves.

Requisito 3.5.1

Requisito adicional apenas para os prestadores de serviços: Mantenha uma descrição documentada da arquitetura criptográfica que inclua:

• Detalhes de todos os algoritmos, protocolos e chaves usados para a proteção dos dados do titular do cartão, incluindo a força da chave e a data de validade.
• Descrição do uso da chave para cada chave.
• Inventário de quaisquer HSMs e outros SCDs usados para gerenciamento de chaves.

As suas responsabilidades

Uma maneira de armazenar informações confidenciais (chaves, cadeias de conexão e outras) é usar o recurso nativo do Kubernetes Secret . Você deve habilitar explicitamente a criptografia em repouso. Como alternativa, armazene-os em um repositório gerenciado, como o Azure Key Vault. Das duas abordagens, recomendamos o uso de um serviço de loja gerenciada. Uma vantagem é a redução da sobrecarga em tarefas relacionadas ao gerenciamento de chaves, como a rotação de chaves.

Por padrão, o Azure usa chaves gerenciadas pela Microsoft por cliente para todos os dados criptografados. No entanto, alguns serviços também suportam chaves autogeridas para encriptação. Se você usar chaves autogerenciadas para criptografia em repouso, certifique-se de levar em conta um processo e uma estratégia que lida com tarefas de gerenciamento de chaves.

Como parte de sua documentação, inclua informações relacionadas ao gerenciamento de chaves, como expiração, localização e detalhes do plano de manutenção.

Requisito 3.5.2

Restrinja o acesso às chaves criptográficas ao menor número de custodiantes necessário.

As suas responsabilidades

Minimize o número de pessoas que têm acesso às chaves. Se você estiver usando atribuições de função baseadas em grupo, configure um processo de auditoria recorrente para revisar as funções que têm acesso. Quando os membros da equipe do projeto são alterados, as contas que não são mais relevantes devem ser removidas das permissões. Só as pessoas certas devem ter acesso. Use as revisões de acesso do Microsoft Entra ID para revisar regularmente as associações de grupo.

Considere remover as permissões permanentes em favor de atribuições de função just-in-time (JIT), ativação de função baseada em tempo e ativação de função baseada em aprovação. Por exemplo, considere o uso do Privileged Identity Management.

Requisito 3.5.3

Armazene chaves secretas e privadas usadas para criptografar/descriptografar dados do titular do cartão em um (ou mais) dos seguintes formulários em todos os momentos:

• Criptografado com uma chave de criptografia de chave que é pelo menos tão forte quanto a chave de criptografia de dados e que é armazenada separadamente da chave de criptografia de dados.
• Dentro de um dispositivo criptográfico seguro (como um módulo de segurança (HSM) de hardware (host) ou um dispositivo de ponto de interação aprovado pelo PTS).
• Como pelo menos dois componentes-chave completos ou acções-chave, de acordo com um método aceite pela indústria.

As suas responsabilidades

Uma carga de trabalho PCI-DSS 4.0.1 precisará usar mais de uma chave de criptografia como parte da estratégia de proteção de dados em repouso. Uma chave de criptografia de dados (DEK) é usada para criptografar e descriptografar o CHD, mas você é responsável por uma chave de criptografia de chave adicional (KEK) para proteger esse DEK. Você também é responsável por garantir que o KEK seja armazenado em um dispositivo criptográfico. O PCI DSS 4.0.1 requer monitoramento contínuo e documentação de todas as principais atividades de gerenciamento.

Você pode usar o Azure Key Vault para armazenar o DEK e usar o HSM Dedicado do Azure para armazenar o KEK. Para obter informações sobre o gerenciamento de chaves do HSM, consulte O que é o HSM Dedicado do Azure?

Requisito 3.6

Documentar e implementar integralmente todos os processos e procedimentos de gestão de chaves criptográficas utilizadas para encriptação de dados do titular do cartão, incluindo o seguinte:

As suas responsabilidades

Se estiver a utilizar o Azure Key Vault para armazenar segredos como chaves, certificados e cadeias de ligação, proteja-o contra acesso não autorizado. O Microsoft Defender for Key Vault deteta tentativas de acesso suspeitas e gera alertas. Você pode exibir esses alertas no Microsoft Defender for Cloud. Para obter mais informações, consulte Microsoft Defender for Key Vault. O PCI DSS 4.0.1 requer monitoramento e alertas expandidos para todos os sistemas de gerenciamento de chaves.

Siga as orientações do NIST sobre a gestão de chaves. Para obter mais detalhes, consulte:

• Gestão de Chaves Criptográficas
• SP 800-133 Rev. 2, Recomendação para geração de chaves criptográficas
• SP 800-57 Parte 1 Rev. 5, Recomendação para Gestão de Chaves

Consulte também Microsoft Defender for Key Vault.

Requisito 3.6.7

Prevenção da substituição não autorizada de chaves criptográficas.

As suas responsabilidades

• Habilite o diagnóstico em todos os principais armazenamentos . Use Azure Monitor for Key Vault. Ele coleta logs e métricas e os envia para o Azure Monitor. Para obter mais informações, consulte Monitorando seu serviço de cofre de chaves com o Azure Monitor for Key Vault.
• Conceda permissões somente leitura a todos os consumidores.
• Não tem permissões permanentes para usuários de gerenciamento ou entidades de segurança. Em vez disso, use atribuições de função just-in-time (JIT), ativação de função baseada em tempo e ativação de função baseada em aprovação.
• Crie uma exibição centralizada integrando logs e alertas em soluções de gerenciamento de eventos e informações de segurança (SIEM), como o Microsoft Sentinel.
• Tome medidas em alertas e notificações, especialmente em alterações inesperadas.

Requisito 3.6.8

Exigência de que os depositários de chaves criptográficas reconheçam formalmente que compreendem e aceitam as suas responsabilidades de custódia de chaves.

As suas responsabilidades

Manter documentação que descreva as responsabilidades das partes envolvidas nas principais operações de gerenciamento.

Requisito 3.7

Certifique-se de que as políticas de segurança e os procedimentos operacionais para proteger os dados armazenados do titular do cartão estão documentados, em uso e conhecidos por todas as partes afetadas.

As suas responsabilidades

Crie documentação como uma declaração geral, além de uma série de guias de função atualizados para todas as personas. Realizar treinamentos de recém-contratados e treinamentos contínuos.

É fundamental que você mantenha uma documentação completa sobre os processos e políticas. Várias equipas participam para garantir que os dados estão protegidos em repouso e em trânsito. Em sua documentação, forneça orientação de função para todas as personas. As funções devem incluir SRE, suporte ao cliente, vendas, operações de rede, operações de segurança, engenheiros de software, administradores de banco de dados e outros. O pessoal deve ser treinado em orientação NIST e estratégias de dados em repouso para manter suas habilidades atualizadas. Os requisitos de formação são abordados no Requisito 6.5 e no Requisito 12.6.

Requisito 4: Criptografar a transmissão de dados do titular do cartão em redes abertas e públicas

As suas responsabilidades

Requisito 4.1

Use criptografia forte e protocolos de segurança (por exemplo, TLS, IPSEC, SSH e assim por diante.) para proteger dados confidenciais do titular do cartão durante a transmissão em redes públicas abertas, incluindo o seguinte:

As suas responsabilidades

Os dados do titular do cartão (CHD) que transitam pela Internet pública devem ser encriptados. Os dados devem ser criptografados com TLS 1.2 ou superior, com forte suporte de codificação para todas as transmissões. Não suporte redirecionamentos não-TLS para TLS em nenhum serviço de transmissão de dados. O PCI DSS 4.0.1 requer monitoramento contínuo dos protocolos de criptografia e avaliações de risco regulares para garantir que os controles criptográficos permaneçam eficazes.

Seu projeto deve ter uma cadeia estratégica de pontos de terminação TLS. À medida que os dados percorrem os saltos de rede, mantenha o TLS em saltos que exigem inspeção de pacotes. No mínimo, tenha o ponto de terminação TLS final no recurso de entrada do cluster. Considere levá-lo mais longe dentro dos recursos do cluster.

Use a Política do Azure para controlar a criação de recursos:

• Negar a criação de qualquer recurso de entrada não-HTTPS.
• Negar a criação de qualquer IP público ou qualquer balanceador de carga público em seu cluster, para garantir que o tráfego da Web esteja sendo encapsulado através do gateway.

Para obter mais informações, consulte Visão geral da criptografia do Azure. O PCI DSS 4.0.1 permite uma abordagem personalizada aos controles de criptografia, se justificado e documentado.

Requisito 4.1.1

Certifique-se de que as redes sem fio que transmitem dados do titular do cartão ou conectadas ao ambiente de dados do titular do cartão usem as práticas recomendadas do setor (por exemplo, IEEE 802.11i) para implementar criptografia forte para autenticação e transmissão.

As suas responsabilidades

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

Requisito 4.2

Nunca envie PANs desprotegidos por tecnologias de mensagens do usuário final (por exemplo, e-mail, mensagens instantâneas, SMS, bate-papo, etc.).

As suas responsabilidades

Se sua carga de trabalho exigir o envio de e-mails, considere criar um portão de quarentena de e-mail. Essa validação lhe dará a capacidade de verificar todas as mensagens de saída em busca de conformidade e verificar se os dados confidenciais não estão incluídos. Idealmente, você também deve considerar essa abordagem para mensagens de suporte ao cliente.

A validação deve ser feita ao nível da carga de trabalho e do processo de controlo de alterações. As portas de aprovação devem compreender o requisito.

Para obter considerações, consulte as orientações da norma oficial PCI-DSS 4.0.1.

Requisito 4.3

Garantir que as políticas de segurança e os procedimentos operacionais para criptografar as transmissões de dados do titular do cartão sejam 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 é especialmente verdadeiro quando você está gerenciando políticas sobre TLS (Transport Layer Security). A documentação deve incluir informações sobre aspetos como:

• Pontos públicos de acesso à Internet. Um exemplo é o suporte do Gateway de Aplicativo do Azure para cifras TLS.
• Saltos de rede entre a rede de perímetro e os pods de carga de trabalho.
• Encriptação Pod-to-pod (se implementada). Isso pode incluir detalhes sobre a configuração de uma malha de serviço.
• Pod para armazenamento (se parte da arquitetura).
• Pod para serviços externos, serviços PaaS do Azure que usam TLS, um gateway de pagamento ou um sistema de deteção de fraude.

As pessoas que operam em 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.

Próximos passos

Implemente criptografia abrangente e controles de gerenciamento de chaves para proteger os dados do titular do cartão em repouso e em trânsito.