Proteja os dados em um cluster regulado pelo AKS para PCI-DSS 3.2.1 (Parte 4 de 9)

Este artigo descreve as considerações 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 3.2.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 do padrão oficial PCI-DSS 3.2.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 4 — Criptografar a transmissão de dados do titular do cartão em redes abertas e públicas.

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 conservação dos 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

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.

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. Algumas das principais considerações são:

• 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.

Analise esta 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.

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

Requisito 3.2

Não armazene dados confidenciais de autenticação após a autorização (mesmo se 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

(APLICA-SE A: REQUISITO 3.2.1, Requisito 3.2.2, Requisito 3.2.3)

O processamento e a proteção de dados 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 que são emitidos a partir dos pods.
• Rotinas de tratamento de exceções.
• Nomes de ficheiros.
• Cache.

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.

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 onde 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 (o hash tem de ser de todo o PAN)
• Truncagem (o hashing não pode ser utilizado para substituir o segmento truncado do PAN)
• Tokens de índice e almofadas (as almofadas devem ser armazenadas de forma segura)
• 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. A orientação do PCI DSS recomenda o uso de algoritmos testados pelo setor para que eles enfrentem ataques do mundo real. Evite usar algoritmos de encriptação personalizados.

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.

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.

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 (Azure Key Vault, Azure Key Vault Managed Hardware Security Module (HSM) e outros).

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

Estes pontos são descritos nas subsecções:

• 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 provedores de serviços: Manter 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 para todos os dados criptografados, por cliente. 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. 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.

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 3.2.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.

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 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

(APLICA-SE A: REQUISITO 3.6.1, Requisito 3.6.2, Requisito 3.6.3, Requisito 3.2.4)

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.

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

• 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 todas as entidades de serviço de gerenciamento. 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 responsáveis nas operações de gestão de chaves.

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 o conjunto de habilidades atualizado. Os requisitos de formação são abordados no Requisito 6.5 e no Requisito 12.6.

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 posterior), com suporte de cifra reduzido para todas as transmissões. Não suporta redirecionamentos não-TLS para TLS em nenhum serviço de transmissão de dados.

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.

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 no padrão oficial PCI-DSS 3.2.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 no padrão oficial PCI-DSS 3.2.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). Eis algumas áreas:

• 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

Proteja todos os sistemas contra malware e atualize regularmente o software ou programas antivírus. Desenvolver e manter sistemas e aplicações seguras.