As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Operações internas

Este tópico descreve os requisitos internos implementados pelo serviço para proteger as chaves do cliente e as operações criptográficas para um serviço de gerenciamento de chaves e criptografia de pagamento escalável e distribuído globalmente.

Especificações e ciclo de vida do HSM

AWS A criptografia de pagamento usa uma frota de HSM disponíveis comercialmente. Eles HSMs são validados pelo FIPS 140-2 Nível 3 e também usam versões de firmware e a política de segurança listadas na lista de dispositivos PCI PTS aprovados pelo PCI Security Standards Council como compatíveis com PCI HSM v3. O padrão PCI PTS HSM inclui requisitos adicionais para fabricação, envio, implantação, gerenciamento e destruição do hardware HSM, que são importantes para a segurança e conformidade dos pagamentos, mas não são abordados pelo FIPS 140.

Todos HSMs são operados no modo PCI e configurados com a política de segurança PCI PTS HSM. Somente as funções necessárias para oferecer suporte aos casos de uso da criptografia de AWS pagamento estão ativadas. AWS A criptografia de pagamento não permite a impressão, exibição ou devolução de texto PINs não criptografado.

Segurança física do dispositivo HSM

Somente HSMs aqueles com chaves de dispositivo assinadas por uma autoridade certificadora de criptografia de AWS pagamento (CA) pelo fabricante antes da entrega podem ser usados pelo serviço. A criptografia AWS de pagamento é uma subCA da CA do fabricante que é a raiz da confiança dos certificados de fabricantes e dispositivos do HSM. A CA do fabricante implementa o ANSI TR 34 e atestou a conformidade com o Anexo A de Segurança PCI PIN e o Anexo A. O fabricante verifica se todos os HSM com chaves de dispositivo assinadas pela Autoridade de Criptografia de AWS Pagamentos são enviados para o destinatário designado pela AWS.

Conforme exigido pela segurança PCI PIN, o fabricante fornece uma lista de números de série por meio de um canal de comunicação diferente do da remessa do HSM. Esses números de série são verificados em cada etapa do processo de instalação do HSM nos datacenters da AWS. Por fim, os operadores de criptografia de AWS pagamento validam a lista de HSM instalados em relação à lista do fabricante antes de adicionar o número de série à lista de HSM autorizados a receber AWS chaves de criptografia de pagamento.

HSMs estão sempre em armazenamento seguro ou sob controle duplo, o que inclui:

Um completo chain-of-custody, com responsabilidade individual, é mantido e monitorado para cada HSM.

Inicialização do Java

Um HSM só é inicializado como parte da frota de criptografia de AWS pagamento depois que sua identidade e integridade são validadas por números de série, chaves de dispositivo instaladas pelo fabricante e soma de verificação do firmware. Depois que a autenticidade e a integridade de um HSM são validadas, ele é configurado, incluindo a ativação do Modo PCI. Em seguida, as chaves principais da região de criptografia de AWS pagamento e as chaves principais do perfil são estabelecidas e o HSM fica disponível para o serviço.

Serviço e reparo do HSM

O HSM tem componentes que podem ser reparados e não exigem a violação do limite criptográfico do dispositivo. Esses componentes incluem ventiladores de resfriamento, fontes de alimentação e baterias. Se um HSM ou outro dispositivo dentro do rack do HSM precisar de manutenção, o controle duplo será mantido durante todo o período em que o rack estiver aberto.

Descomissionamento do HSM

O descomissionamento ocorre devido end-of-life ou falha de um HSM. Os HSM são logicamente zerados antes de serem removidos do rack e, se funcionarem, são destruídos nas salas de processamento seguras dos datacenters da AWS. Eles nunca são devolvidos ao fabricante para reparo, usados para outra finalidade ou removidos de uma sala de processamento segura antes da destruição.

Atualização de firmware do HSM

As atualizações de firmware do HSM são aplicadas quando necessário para manter o alinhamento com as versões listadas do PCI PTS HSM e do FIPS 140-2 (ou FIPS 140-3), se uma atualização estiver relacionada à segurança ou se for determinado que os clientes podem se beneficiar dos recursos de uma nova versão. AWS A criptografia de pagamento HSMs executa o off-the-shelf firmware, compatível com as versões listadas no PCI PTS HSM. As novas versões de firmware são validadas quanto à integridade com as versões de firmware com certificação PCI ou FIPS e, em seguida, testadas quanto à funcionalidade antes da implantação para todos. HSMs

Acesso do operador

Os operadores podem ter acesso sem console ao HSM para solução de problemas em casos raros em que as informações coletadas do HSM durante as operações normais são insuficientes para identificar um problema ou planejar uma mudança. As etapas a seguir são executadas:

Todos os registros de acesso que não sejam do console são revisados quanto à conformidade do processo e possíveis alterações no monitoramento do HSM, no processo non-console-access de gerenciamento ou no treinamento do operador.

Gerenciamento de chaves

Todos os HSMs em uma região são sincronizados com uma chave principal da região. Uma chave principal de região protege pelo menos uma chave principal de perfil. Uma chave principal de perfil protege as chaves do cliente.

Todas as chaves principais são geradas por um HSM e distribuídas por distribuição simétrica de chaves usando técnicas assimétricas, alinhadas com ANSI X9 TR 34 e Anexo A do PCI PIN.

Geração

Chaves principais AES de 256 bits são geradas em um dos HSM provisionados para a frota de HSM de serviço, usando o gerador de números aleatórios PCI PTS HSM.

Sincronização da chave principal da região

As chaves principais da região do HSM são sincronizadas pelo serviço em toda a frota regional com mecanismos definidos pela ANSI X9 TR-34, que incluem:

As chaves principais da região são estabelecidas para HSMs aquelas que foram autenticadas e provisionadas para uma região por:

Caso um único HSM precise ser sincronizado novamente com uma região:

Isso garante que:

Alternância de chaves principais da região

As chaves principais da região são alternadas ao fim do período criptográfico, no caso improvável de uma suspeita de comprometimento da chave ou após alterações no serviço que possam afetar a segurança da chave.

Uma nova chave principal de região é gerada e distribuída, como no provisionamento inicial. As chaves principais do perfil salvas devem ser traduzidas para a nova chave principal da região.

A alternância da chave principal da região não afeta o processamento do cliente.

Sincronização da chave principal do perfil

As chaves principais do perfil são protegidas pelas chaves principais da região. Isso restringe um perfil a uma região específica.

As chaves principais do perfil são provisionadas adequadamente:

Alternância de chaves principais do perfil

As chaves principais do perfil são alternadas ao fim do período criptográfico, após suspeita de comprometimento da chave ou após alterações no serviço que possam afetar a segurança da chave.

Etapas de alternância:

A alternância da chave principal do perfil não afeta o processamento do cliente.

Proteção

As chaves dependem somente da hierarquia de chaves para a proteção. A proteção das chaves principais é fundamental para evitar a perda ou o comprometimento de todas as chaves do cliente.

As chaves principais da região podem ser restauradas somente do backup para o HSM autenticado e provisionado para o serviço. Essas chaves podem ser armazenadas apenas como tokens de chave principal criptografados e mutuamente autenticáveis de um KDH específico para um HSM específico.

As chaves mestras do perfil são armazenadas com a configuração do perfil e as informações de contexto criptografadas por região.

As chaves do cliente são armazenadas em blocos de chaves, protegidas por uma chave mestra de perfil.

Todas as chaves existem exclusivamente em um HSM ou são armazenadas protegidas por outra chave de força criptográfica igual ou mais forte.

Durabilidade

As chaves do cliente para criptografia de transações e funções de negócios devem estar disponíveis mesmo em situações extremas que normalmente causariam interrupções. AWS A criptografia de pagamento utiliza um modelo de redundância de vários níveis em zonas e regiões de disponibilidade. AWS Os clientes que precisam de maior disponibilidade e durabilidade para operações criptográficas de pagamento do que as fornecidas pelo serviço devem implementar arquiteturas multirregionais.

A autenticação do HSM e os tokens da chave principal são salvos e podem ser usados para restaurar uma chave principal ou sincronizar com uma nova chave principal, caso um HSM precise ser redefinido. Os tokens são arquivados e usados somente sob controle duplo quando necessário.

Segurança de comunicação

Externo

AWS Os endpoints da API de criptografia de pagamento atendem aos padrões de AWS segurança, incluindo TLS na versão 1.2 ou superior e Signature versão 4 para autenticação e integridade das solicitações.

As conexões TLS de entrada são encerradas em balanceadores de carga de rede e encaminhadas para manipuladores de API por meio de conexões TLS internas.

Interno

As comunicações internas entre os componentes do serviço e entre os componentes do serviço e outros serviços da AWS são protegidas por TLS usando criptografia robusta.

Os HSM estão em uma rede privada, não virtual, que pode ser acessada apenas por componentes de serviço. Todas as conexões entre o HSM e os componentes do serviço são protegidas com TLS mútuo (mTLS), igual ou superior ao TLS 1.2. Os certificados internos para TLS e mTLS são gerenciados pelo Amazon Certificate Manager usando uma AWS Private Certificate Authority. A rede interna VPCs e a rede HSM são monitoradas em busca de atividades e alterações de configuração inesperadas.

Gerenciamento de chaves de clientes

Na AWS, a confiança do cliente é nossa maior prioridade. Você mantém o controle total das chaves que você carrega ou cria no serviço sob sua conta da AWS e é responsável pela configuração do acesso às chaves.

AWS A criptografia de pagamento tem total responsabilidade pela conformidade física do HSM e pelo gerenciamento de chaves das chaves gerenciadas pelo serviço. Isso exige a propriedade e o gerenciamento das chaves principais do HSM e o armazenamento das chaves protegidas do cliente no banco de dados de chaves AWS de criptografia de pagamento.

Separação de espaço entre chaves do cliente

AWS A criptografia de pagamento aplica as principais políticas para todos os usos de chaves, incluindo a limitação dos diretores à conta proprietária da chave, a menos que uma chave seja explicitamente compartilhada com outra conta.

Backup e recuperação

O backup das chaves e das principais informações de uma região é feito em arquivos criptografados pela AWS. Os arquivos exigem controle duplo AWS para serem restaurados.

Blocos de chaves

Todas as chaves são armazenadas em blocos de chaves no formato ANSI X9 TR-31.

As chaves podem ser importadas para o serviço a partir de criptogramas ou outros formatos de bloco de chaves suportados pelo ImportKey. Da mesma forma, as chaves podem ser exportadas, se forem exportáveis, para outros formatos de blocos de chaves ou criptogramas compatíveis com os perfis de exportação de chaves.

Uso de chaves

O uso da chave é restrito ao configurado KeyUsage pelo serviço. O serviço falhará em qualquer solicitação com uso inadequado de chaves, modo de uso ou algoritmo para a operação criptográfica solicitada.

Relações de troca de chaves

O PCI PIN Security e o PCI P2PE exigem que as organizações que compartilham chaves criptografadas PINs, incluindo a KEK usada para compartilhar essas chaves, não compartilhem essas chaves com nenhuma outra organização. É uma prática recomendada que chaves simétricas sejam compartilhadas apenas entre duas partes, inclusive dentro da mesma organização. Isso minimiza o impacto de suspeitas de comprometimento de chaves que forcem a substituição das chaves afetadas.

Mesmo os casos de negócios que exigem o compartilhamento de chaves entre mais de duas partes devem manter um número mínimo de partes.

AWS A criptografia de pagamento fornece etiquetas-chave que podem ser usadas para rastrear e impor o uso de chaves dentro desses requisitos.

Por exemplo, KEK e BDK para diferentes instalações de injeção de chaves podem ser identificados definindo um “KIF” = “POSStation” para todas as chaves compartilhadas com esse provedor de serviços. Outro exemplo seria marcar chaves compartilhadas com redes de pagamento com “Rede” = “PayCard”. As tags permitem que você crie controles de acesso e crie relatórios de auditoria para aplicar e demonstrar suas principais práticas de gerenciamento.

Exclusão de chaves

DeleteKey marca as chaves no banco de dados para exclusão após um período configurável pelo cliente. Após esse período, a chave é excluída irreversivelmente. Esse é um mecanismo de segurança para evitar a exclusão acidental ou maliciosa de uma chave. As teclas marcadas para exclusão não estão disponíveis para nenhuma ação, exceto RestoreKey.

As chaves excluídas permanecem nos backups do serviço por sete dias após a exclusão. Elas não são restauráveis durante esse período.

As chaves pertencentes a contas fechadas da AWS são marcadas para exclusão. Se a conta for reativada antes que o período de exclusão seja atingido, todas as chaves marcadas para exclusão serão restauradas, mas desativadas. Elas devem ser reativadas por você para serem usadas em operações criptográficas.

Registro em log e monitoramento

Os registros de serviços internos incluem:

Todas as fontes de log monitoram e filtram informações confidenciais, inclusive sobre chaves. Os logs são revisados sistematicamente para garantir que não contenham informações confidenciais do cliente.

O acesso aos logs é restrito às pessoas necessárias para concluir as funções de trabalho.

Todos os logs são retidos de acordo com as políticas de retenção de registros da AWS.