Proteger dados em um cluster regulamentado do AKS para PCI-DSS 3.2.1 (Parte 4 de 9)

Este artigo descreve as considerações para um cluster do AKS (Serviço de Kubernetes do Azure) 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.

Esta arquitetura e a implementação estão focadas na infraestrutura e não na carga de trabalho. Este artigo fornece considerações gerais e melhores práticas para ajudar você a tomar decisões de design. Siga os requisitos no padrão PCI-DSS 3.2.1 oficial e use este artigo como informações adicionais, quando aplicável.

Proteger os dados do titular do cartão

Requisito 3 – Proteger dados armazenados do titular do cartão

Suas responsabilidades

Requisito 3.1

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

• Limitar a quantidade de armazenamento de dados e o tempo de retenção necessários para fins legais, regulatórios e comerciais
• Processos para exclusão segura de dados quando não forem mais necessários
• Especificar requisitos de retenção para os dados do titular do cartão
• Um processo trimestral para identificar e excluir com segurança os dados armazenados que ultrapassarem o tempo de retenção definido.

Suas responsabilidades

Não armazene o estado no cluster do AKS. Se você optar por armazenar o CHD, explore as 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 as diretrizes padrão sobre que tipo de CHD pode ser armazenado. Defina políticas de retenção de dados com base nos requisitos de negócios e no tipo de armazenamento usado. Algumas considerações principais são:

• Como e onde os dados são armazenados?
• Os dados armazenados são criptografados?
• O que é o período de retenção?
• Quais 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 expirar?

Tenha políticas de governança em torno de algumas dessas opções. 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.

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

Talvez seja necessário armazenar dados temporariamente em cache. Recomendamos que você proteja os dados armazenados em cache enquanto eles são movidos para uma solução de armazenamento. Considere habilitar o recurso de criptografia baseado em host no AKS. Isso criptografará os dados armazenados em VMs de nó. Para obter mais informações, confira Criptografia baseada em host no AKS (Azure Kubernetes Service). Além disso, habilite uma política interna do Azure que requer 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, Armazenamento de Blobs do Azure fornece políticas de retenção baseadas em tempo. Outra opção é implementar uma solução personalizada que exclui dados de acordo com as políticas de retenção. Um exemplo é o DLM (Gerenciamento de Ciclo de Vida de Dados), que gerencia atividades de ciclo de vida de 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, confira Gerenciar o ciclo de vida de dados usando o Azure Data Factory.

Requisito 3.2

Não armazenar dados confidenciais de autenticação após autorização (mesmo se criptografado). Se dados confidenciais de autenticação forem recebidos, considere todos os dados irrecuperáveis após a conclusão do processo de autorização.

Suas responsabilidades

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

Processar e proteger dados é uma preocupação de carga de trabalho e está além do escopo desta arquitetura. Aqui estão algumas considerações gerais.

De acordo com o padrão, os dados de autenticação confidenciais consistem em dados de acompanhamento completo, código ou valor de validação de cartão e dados PIN. Como parte do processamento do CHD, verifique se os dados de autenticação não estão expostos em fontes como:

• Logs emitidos dos pods.
• Rotinas de tratamento de exceções.
• Nomes de arquivo.
• Caches.

Como orientação geral, os comerciantes não devem armazenar essas informações. Se houver uma necessidade de documentar a justificativa comercial.

Requisito 3.3

Mascarar 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 necessidade comercial legítima possa ver o PAN completo.

Suas responsabilidades

O PAN (número da conta primária) é considerado como dados confidenciais e a exposição a esses dados deve ser evitada. Uma maneira é reduzir os dígitos exibidos por meio do mascaramento.

Não implemente o mascaramento de dados na carga de trabalho. Em vez disso, use constructos no nível do banco de dados. A linha de serviços do SQL do Azure, incluindo o Azure Synapse Analytics, dá suporte ao mascaramento de dados dinâmico, o que reduz a exposição na camada do aplicativo. É um recurso de segurança baseado em política que define quem pode exibir os dados não mascarados e quantos dados são expostos por meio do mascaramento. O método de mascaramento de cartão de crédito integrado 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, confira Mascaramento de dados dinâmico.

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

Requisito 3.4

Considerar o PAN ilegível em todos os lugares em que ele está armazenado (incluindo mídia digital portátil, mídia de backup e logs), usando uma das seguintes abordagens:

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

Suas responsabilidades

Para esse requisito, talvez seja necessário usar criptografia direta na carga de trabalho. As diretrizes de PCI DSS recomendam o uso de algoritmos testados pelo setor para defesa contra ataques do mundo real. Evite usar algoritmos de criptografia personalizados.

As técnicas apropriadas de mascaramento de dados também atendem a esse requisito. Você é responsável por mascarar todos os dados PAN (número da conta primária). A linha de serviços do SQL do Azure, incluindo o Azure Synapse Analytics, dá suporte ao mascaramento de dados dinâmico. Confira o Requisito 3.3.

Verifique se o PAN não está exposto como parte dos processos de fluxo de trabalho. Estas são algumas considerações:

• Mantenha o PAN fora de logs, logs de fluxo de trabalho e 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 não solicitados. Verifique se os processos de validação e detecção de conteúdo estão em vigor para todos os campos de texto de forma livre, eliminando todo o conteúdo que se assemelha a dados PAN.

Requisito 3.4.1

Se a criptografia de disco é usada (em vez de criptografia de banco de dados em nível de arquivo ou de coluna), o acesso lógico deve ser gerenciado separadamente e independentemente dos mecanismos de controle de acesso e autenticação do sistema operacional nativo (por exemplo, não usando bancos de dados de conta de usuário local ou credenciais de logon de rede geral). As chaves de descriptografia não devem estar associadas a contas de usuário.

Suas responsabilidades

Como regra geral, não armazene o estado no cluster do AKS. Use um armazenamento de dados externo que dê 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 no meio 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, confira Chaves gerenciadas pelo cliente para a criptografia do Armazenamento do Azure.

Recursos semelhantes estão disponíveis para bancos de dados. Para opções de SQL do Azure, confira Transparent Data Encryption do SQL do Azure com chave gerenciada pelo cliente.

Certifique-se de armazenar suas chaves em um repositório 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 em nós de VM sejam criptografados.

Requisito 3.5

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

Suas responsabilidades

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

• Mantenha 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 projetados para dar suporte aos requisitos de registro em log de auditoria e autorização. Para obter detalhes, confira Autenticação de solicitação para Key Vault do Azure.
• Proteja todas as chaves de criptografia de dados com uma chave de criptografia armazenada em um dispositivo criptográfico.
• Se você usar chaves autogerenciadas (em vez de chaves gerenciadas pela Microsoft), tenha um processo e uma documentação para manter tarefas relacionadas ao gerenciamento de chaves.

Requisito 3.5.1

Requisitos adicionais somente para provedores de serviço: manter uma descrição documentada da arquitetura de criptografia que inclui:

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

Suas responsabilidades

Uma maneira de armazenar informações confidenciais (chaves, cadeias de conexão e outras) é usar o recurso Secretdo Kubernetes nativo. Você deve habilitar explicitamente a criptografia em repouso. Como alternativa, armazene em um repositório gerenciado, como o Azure Key Vault. Das duas abordagens, recomendamos usar um serviço de repositório gerenciado. 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 dão suporte a chaves autogerenciadas para criptografia. Se você usar chaves autogerenciadas para criptografia em repouso, verifique se você contabiliza 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 detalhes de expiração, localização e plano de manutenção.

Requisito 3.5.2

Restringir o acesso a chaves de criptografia ao menor número de responsáveis possível.

Suas responsabilidades

Minimize o número de pessoas com acesso às chaves. Se você estiver usando atribuições de função baseadas em grupo, configure um processo de auditoria recorrente para avaliar 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. Somente as pessoas certas devem ter acesso. Use as revisões de acesso do Microsoft Entra ID para examinar regularmente as associações de grupo.

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

Requisito 3.5.3

Armazenar chaves privadas e segredos usados para sempre criptografar/descriptografar os dados do titular do cartão em um (ou mais) dos seguintes formulários:

• Criptografado com uma chave de criptografia de chave que seja pelo menos tão forte quanto a chave de criptografia de dados, e que esteja armazenado separadamente da chave de criptografia de dados
• Dentro de um dispositivo de criptografia seguro (por exemplo, um HSM (módulo de segurança de hardware) (host) ou o dispositivo de ponto de interação aprovado por PTS)
• Como pelo menos dois componentes principais completos ou compartilhamentos de chave, de acordo com um método aceito pelo setor

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 DEK (chave de criptografia de dados) é usada para criptografar e descriptografar o CHD, mas você é responsável por uma KEK (chave de criptografia de chave) adicional 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, confira O que é o HSM Dedicado do Azure?.

Requisito 3.6

Documentar totalmente e implementar todos os processos de gerenciamento de chaves e procedimentos para as chaves de criptografia usadas para criptografia de dados do titular do cartão, incluindo o seguinte:

Suas responsabilidades

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

Se você estiver usando o Azure Key Vault para armazenar segredos, como chaves, certificados e cadeias de conexão, proteja-o contra acesso não autorizado. O Microsoft Defender para Key Vault detecta tentativas suspeitas de acesso e gera alertas. É possível exibir esses alertas no Microsoft Defender para Nuvem. Para obter mais informações, confira Microsoft Defender para Key Vault.

Siga as diretrizes do NIST sobre o gerenciamento de chaves. Para obter detalhes, confira:

• Gerenciamento criptográfico de chaves.
• SP 800-133 Rev. 2, Recomendação para geração de chave criptográfica
• SP 800-57 Parte 1 Rev. 5, Recomendação para gerenciamento de chaves

Confira também Microsoft Defender para o Key Vault.

Requisito 3.6.7

Prevenção de substituição não autorizada das chaves de criptografia.

Suas responsabilidades

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

Requisito 3.6.8

Requisito para que os responsáveis pelas chaves de criptografia confirmem formalmente que compreendem e aceitam suas responsabilidades de custódia de chave.

Suas responsabilidades

Mantenha a documentação que descreve as responsabilidades das partes responsáveis nas operações de gerenciamento de chaves.

Requisito 3.7

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

Suas responsabilidades

Crie a documentação como uma instrução geral, além de uma série de guias de função atualizados para todas as personas. Execute treinamento de novas contratações e treinamento contínuo.

É fundamental que você mantenha uma documentação completa sobre os processos e as políticas. Várias equipes participam para garantir que os dados estejam protegidos em repouso e em trânsito. Em sua documentação, forneça diretrizes 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 diretrizes NIST e estratégias de dados em repouso para manter o conjunto de habilidades atualizado. Os requisitos de treinamento 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

Suas responsabilidades

Requisito 4.1

Use uma criptografia forte e protocolos de segurança (por exemplo, TLS, IPSEC, SSH, entre outros) para proteger dados confidenciais de titulares de cartão durante a transmissão por redes abertas e públicas, incluindo o seguinte:

Suas responsabilidades

Os CHD (dados do titular do cartão) que transitam pela Internet pública devem ser criptografados. Os dados devem ser criptografados com o TLS 1.2 (ou posterior), com suporte de criptografia reduzido para todas as transmissões. Não dê suporte a redirecionamentos não TLS para TLS em nenhum serviço de transmissão de dados.

Seu design deve ter uma cadeia estratégica de pontos de terminação TLS. Conforme os dados viajam pelos 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 Azure Policy 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 quaisquer balanceadores de carga públicos em seu cluster, para garantir que o tráfego da Web esteja sendo encaminhado por meio do gateway.

Para obter mais informações, consulte Visão geral da criptografia do Azure.

Requisito 4.1.1

Verifique que as redes sem fios transmitem dados do titular do cartão, ou que estão conectados ao ambiente de dados do titular do cartão, use as práticas recomendadas do setor (por exemplo, IEEE 802.11 i) para implantar uma criptografia forte para autenticação e para transmissão.

Suas responsabilidades

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

Requisito 4.2

Nunca enviar PANs desprotegidas por meio de tecnologias de mensagens com base no usuário final (por exemplo: email, mensagens instantâneas, SMS, bate-papo, etc.).

Suas responsabilidades

Se a sua carga de trabalho exigir o envio de emails, considere a criação de um portão de quarentena de email. Esta validação 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. O ideal é que você também considere essa abordagem para mensagens de suporte ao cliente.

A validação deve ser feita no nível da carga de trabalho e no processo de controle de alteração. Os portões de aprovação devem entender o requisito.

Para ver outras considerações, confira as diretrizes no padrão oficial PCI-DSS 3.2.1.

Requisito 4.3

Garantir que políticas de segurança e procedimentos operacionais para criptografar as transmissões de dados de titular do cartão armazenados 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 é especialmente verdade quando você está gerenciando políticas sobre TLS (Transport Layer Security). Estas são algumas áreas:

• Pontos de entrada da Internet pública. Um exemplo é o suporte do Gateway de Aplicativo do Azure para criptografias TLS.
• Saltos de rede entre a rede de perímetro e os pods de carga de trabalho.
• Criptografia pod a 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 de PaaS do Azure que usam TLS, um gateway de pagamento ou um sistema de detecção de fraude.

As pessoas que operam ambientes regulamentados devem ser instruídas, informadas e incentivadas para 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.

Próximas etapas

Proteger todos os sistemas contra malware e atualizar regularmente softwares ou programas antivírus. Desenvolver e manter os aplicativos e sistemas protegidos.