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á.
# Segurança na criptografia AWS de pagamentos
A segurança na nuvem AWS é a maior prioridade. Como AWS cliente, você se beneficia de uma arquitetura de data center e rede criada para atender aos requisitos das organizações mais sensíveis à segurança.
A segurança é uma responsabilidade compartilhada entre você AWS e você. O [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) descreve isso como a segurança da nuvem e a segurança na nuvem:
+ **Segurança da nuvem** —AWS é responsável por proteger a infraestrutura que executa AWS os serviços na AWS nuvem. AWS também fornece serviços que você pode usar com segurança. Auditores terceirizados testam e verificam regularmente a eficácia de nossa segurança como parte dos Programas de Conformidade Programas de [AWS](https://aws.amazon.com/compliance/programs/) de . Para saber mais sobre os programas de conformidade que se aplicam à criptografia de AWS pagamento, consulte [Serviços da AWS no escopo do programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/) .
+ **Segurança na nuvem** — Sua responsabilidade é determinada pelo AWS serviço que você usa. Você também é responsável por outros fatores, incluindo a confidencialidade de seus dados, os requisitos da empresa e as leis e regulamentos aplicáveis.
Este tópico ajuda você a entender como aplicar o modelo de responsabilidade compartilhada ao usar a criptografia AWS de pagamento. Ele mostra como configurar a criptografia AWS de pagamento para atender aos seus objetivos de segurança e conformidade. Você também aprenderá a usar outros AWS serviços que ajudam a monitorar e proteger seus recursos AWS de criptografia de pagamento.
**Topics**
+ [Proteção de dados](data-protection.md)
+ [Resiliência](resilience.md)
+ [Segurança da infraestrutura](infrastructure-security.md)
+ [Use a Amazon VPC e a AWS PrivateLink](vpc-endpoint.md)
+ [TLS pós-quântico híbrido](pqtls.md)
+ [Práticas recomendadas de segurança](security-best-practices.md)
# Proteção de dados em criptografia AWS de pagamento
O [modelo de responsabilidade AWS compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) de se aplica à proteção de dados na criptografia AWS de pagamentos. Conforme descrito neste modelo, AWS é responsável por proteger a infraestrutura global que executa todos os Nuvem AWS. Você é responsável por manter o controle sobre o conteúdo hospedado nessa infraestrutura. Você também é responsável pelas tarefas de configuração e gerenciamento de segurança dos Serviços da AWS que usa. Para saber mais sobre a privacidade de dados, consulte as [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). Para saber mais sobre a proteção de dados na Europa, consulte a postagem do blog [AWS Shared Responsibility Model and RGPD](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS *.
Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure usuários individuais com Centro de Identidade do AWS IAM ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas:
+ Use uma autenticação multifator (MFA) com cada conta.
+ Use SSL/TLS para se comunicar com AWS os recursos. Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Configure a API e o registro de atividades do usuário com AWS CloudTrail. Para obter informações sobre o uso de CloudTrail trilhas para capturar AWS atividades, consulte Como [trabalhar com CloudTrail trilhas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) no *Guia AWS CloudTrail do usuário*.
+ Use soluções de AWS criptografia, juntamente com todos os controles de segurança padrão Serviços da AWS.
+ Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sensíveis armazenados no Amazon S3.
+ Se você precisar de módulos criptográficos validados pelo FIPS 140-3 ao acessar AWS por meio de uma interface de linha de comando ou de uma API, use um endpoint FIPS. Para saber mais sobre os endpoints FIPS disponíveis, consulte [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
É altamente recomendável que nunca sejam colocadas informações confidenciais ou sensíveis, como endereços de e-mail de clientes, em tags ou campos de formato livre, como um campo **Nome**. Isso inclui quando você trabalha com criptografia de AWS pagamento ou outra Serviços da AWS usando o console, a API ou AWS SDKs. AWS CLI Quaisquer dados inseridos em tags ou em campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, é fortemente recomendável que não sejam incluídas informações de credenciais no URL para validar a solicitação nesse servidor.
A AWS Payment Cryptography armazena e protege suas chaves de criptografia de pagamento para torná-las altamente disponíveis e, ao mesmo tempo, fornecer controle de acesso forte e flexível.
**Topics**
+ [Proteger material de chave](#key-protection)
+ [Criptografia de dados](#data-encryption)
+ [Criptografia em repouso](#encryption-rest)
+ [Criptografia em trânsito](#encryption-transit)
+ [Privacidade do tráfego entre redes](#internetwork)
## Proteger material de chave
Por padrão, a AWS Payment Cryptography protege o material de chave criptográfica das chaves de pagamento gerenciadas pelo serviço. Além disso, a AWS Payment Cryptography oferece opções para importar material de chave criado fora do serviço. Para obter detalhes técnicos sobre chaves de pagamento e material de chave, consulte Detalhes criptográficos da AWS Payment Cryptography.
## Criptografia de dados
Os dados na AWS Payment Cryptography consistem em chaves de AWS Payment Cryptography, o material de chave de criptografia que elas representam e seus atributos de uso. O material chave existe em texto simples somente nos módulos de segurança de hardware da AWS Payment Cryptography (HSMs) e somente quando está em uso. Caso contrário, o material e os atributos de chave serão criptografados e armazenados de maneira persistente durável.
O material chave que a criptografia de pagamento da AWS gera ou carrega para as chaves de pagamento nunca sai dos limites da criptografia de pagamento da AWS sem criptografia HSMs . Ele pode ser exportado criptografado pelas operações da API de AWS Payment Cryptography.
## Criptografia em repouso
A criptografia de pagamento da AWS gera material chave para chaves de pagamento listadas no PCI PTS HSM. HSMs Quando não estiver em uso, o material de chave é criptografado por uma chave do HSM e gravado em um armazenamento durável e persistente. O material principal das chaves de criptografia de pagamento e as chaves de criptografia que protegem o material da chave nunca saem do formato HSMs de texto simples.
A criptografia e o gerenciamento do material de chave para chaves de criptografia de pagamento são administrados inteiramente pelo serviço.
Para obter mais detalhes, consulte Detalhes criptográficos do serviço de gerenciamento de chaves da AWS.
## Criptografia em trânsito
O material chave que a criptografia AWS de pagamento gera ou carrega para as chaves de pagamento nunca é exportado ou transmitido nas operações da API de criptografia AWS de pagamento em texto não criptografado. AWS A criptografia de pagamento usa identificadores de chave para representar as chaves nas operações da API.
No entanto, algumas operações de API exportam chaves criptografadas por uma chave de troca de chaves previamente compartilhada ou assimétrica. Além disso, os clientes podem usar operações de API para importar material de chave criptografada para chaves de pagamento.
Todas as chamadas da API de criptografia de AWS pagamento devem ser assinadas e transmitidas usando o Transport Layer Security (TLS). AWS A criptografia de pagamento requer versões TLS e pacotes de criptografia definidos pelo PCI como “criptografia forte”. Todos os endpoints de serviço oferecem suporte ao TLS 1.2—1.3 e ao TLS híbrido pós-quântico.
Para obter mais detalhes, consulte Detalhes criptográficos do serviço de gerenciamento de chaves da AWS.
## Privacidade do tráfego entre redes
AWS A criptografia de pagamento oferece suporte a um AWS Management Console e a um conjunto de operações de API que permitem criar e gerenciar chaves de pagamento e usá-las em operações criptográficas.
AWS A criptografia de pagamento oferece suporte a duas opções de conectividade de rede, da sua rede privada à AWS.
+ Uma conexão IPSec VPN pela internet.
+ O AWS Direct Connect, que conecta sua rede interna a um local do AWS Direct Connect por meio de um cabo de fibra óptica Ethernet padrão.
Todas as chamadas da API de Payment Cryptography devem ser assinadas e transmitidas usando Transport Layer Security (TLS). As chamadas também exigem um conjunto de codificação moderno que seja compatível com o sigilo de encaminhamento perfeito. O tráfego para os módulos de segurança de hardware (HSMs) que armazenam material de chaves para chaves de pagamento é permitido somente de hosts conhecidos da API de criptografia de pagamento da AWS na rede interna da AWS.
Para se conectar diretamente à criptografia de pagamento da AWS a partir da sua nuvem privada virtual (VPC) sem enviar tráfego pela Internet pública, use endpoints de VPC, desenvolvidos pela AWS. PrivateLink Para obter mais informações, consulte a Conexão à AWS Payment Cryptography por meio de um endpoint da VPC.
O AWS Payment Cryptography também oferece suporte a uma opção híbrida de troca de chaves pós-quânticas para o protocolo de criptografia de rede Transport Layer Security (TLS). É possível usar essa opção com TLS ao se conectar aos endpoints da API de AWS Payment Cryptography.
# Resiliência na criptografia AWS de pagamentos
AWS a infraestrutura global é construída em torno de AWS regiões e zonas de disponibilidade. As regiões fornecem várias zonas de disponibilidade separadas e isoladas fisicamente, que são conectadas com baixa latência, alta throughput e redes altamente redundantes. Com as zonas de disponibilidade, é possível projetar e operar aplicações e bancos de dados que automaticamente executam o failover entre as zonas sem interrupção. As zonas de disponibilidade são altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais.
Para obter mais informações sobre AWS regiões e zonas de disponibilidade, consulte [Infraestrutura AWS global](https://aws.amazon.com/about-aws/global-infrastructure/).
## Isolamento regional
O AWS Payment Cryptography é um serviço regional que está disponível em várias regiões.
O design isolado regionalmente da AWS Payment Cryptography garante que um problema de disponibilidade em uma região da AWS não afete a operação de AWS Payment Cryptography em nenhuma outra região. A AWS Payment Cryptography foi projetada para garantir zero tempo de inatividade planejado, com todas as atualizações de software e operações de escalabilidade realizadas de forma perfeita e imperceptível.
O Acordo de Nível de Serviço (SLA) de Criptografia de Pagamentos da AWS inclui um compromisso de serviço de 99,99% para toda a criptografia de pagamento. APIs Para cumprir esse compromisso, a AWS Payment Cryptography garante que todos os dados e informações de autorização necessários para executar uma solicitação de API estejam disponíveis em todos os hosts regionais que recebem a solicitação.
A infraestrutura de criptografia de pagamentos da AWS é replicada em pelo menos três zonas de disponibilidade (AZs) em cada região. Para garantir que falhas em vários hosts não afetem o desempenho da criptografia de pagamento da AWS, a criptografia de pagamento da AWS foi projetada para atender ao tráfego de clientes de qualquer AZs região.
As alterações feitas nas propriedades ou permissões de uma chave de pagamento são replicadas para todos os hosts na região a fim de garantir que a solicitação subsequente possa ser processada corretamente por qualquer host na região. As solicitações de operações criptográficas usando sua chave de pagamento são encaminhadas para uma frota de módulos de segurança de hardware de criptografia de pagamento da AWS (HSMs), qualquer um dos quais pode realizar a operação com a chave de pagamento.
## Design de vários locatários
O design de vários locatários da AWS Payment Cryptography permite cumprir o SLA de disponibilidade e sustentar altas taxas de solicitação, ao mesmo tempo que protege a confidencialidade de suas chaves e dados.
Há vários mecanismos de imposição de integridade implantados para garantir que a chave de pagamento especificada para a operação criptográfica sempre seja a chave usada.
O material de chave em texto simples para suas chaves de Payment Cryptography é amplamente protegido. Assim que é criado, o material de chave é criptografado no HSM e o material de chave criptografado é imediatamente movido para armazenamento seguro. A chave criptografada é recuperada e descriptografada no HSM no momento do uso. A chave em texto não criptografado permanece na memória do HSM apenas pelo tempo necessário para a conclusão da operação criptográfica. O material chave em texto simples nunca sai do HSMs; nunca é gravado no armazenamento persistente.
Para obter mais informações sobre os mecanismos que a AWS Payment Cryptography usa para proteger suas chaves, consulte Detalhes criptográficos da AWS Payment Cryptography.
# Segurança da infraestrutura em AWS Payment Cryptography
Como serviço gerenciado, AWS Payment Cryptography é protegido pelos procedimentos AWS globais de segurança de rede descritos no whitepaper [Amazon Web Services: Visão geral dos processos de segurança](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf).
Você usa chamadas de API AWS publicadas para acessar AWS Payment Cryptography pela rede. Os clientes devem oferecer suporte a Transport Layer Security (TLS) 1.2 ou posterior. Os clientes também devem ter compatibilidade com conjuntos de criptografia com perfect forward secrecy (PFS) como Ephemeral Diffie-Hellman (DHE) ou Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). A maioria dos sistemas modernos como Java 7 e versões posteriores oferece suporte a esses modos.
Além disso, as solicitações devem ser assinadas usando um ID da chave de acesso e uma chave de acesso secreta associada a uma entidade principal do IAM. Ou é possível usar o [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) para gerar credenciais de segurança temporárias para assinar solicitações.
## Isolamento de hosts físicos
A segurança da infraestrutura física usada pela AWS Payment Cryptography está sujeita aos controles descritos na seção Segurança física e ambiental da Amazon Web Services: visão geral dos processos de segurança. É possível encontrar mais detalhes em relatórios de conformidade e em descobertas de auditoria de terceiros listados na seção anterior.
A criptografia de pagamento da AWS é suportada por módulos dedicados de segurança de hardware listados no commercial-off-the-shelf PCI PTS HSM (). HSMs O material chave das chaves de criptografia de pagamento da AWS é armazenado somente na memória volátil do HSMs, e somente enquanto a chave de criptografia de pagamento estiver em uso. HSMs estão em racks de acesso controlado nos data centers da Amazon que impõem controle duplo para qualquer acesso físico. Para obter informações detalhadas sobre a operação da criptografia de pagamento da AWS HSMs, consulte Detalhes criptográficos da criptografia de pagamentos da AWS.
# Conectando-se à criptografia AWS de pagamento por meio de um endpoint VPC
Você pode se conectar diretamente à criptografia AWS de pagamento por meio de um endpoint de interface privada em sua nuvem privada virtual (VPC). Quando você usa uma interface VPC endpoint, a comunicação entre sua VPC e a criptografia de AWS pagamento é conduzida inteiramente dentro da rede. AWS
AWS A criptografia de pagamento é compatível com endpoints da Amazon Virtual Private Cloud (Amazon VPC) alimentados por. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/) Cada VPC endpoint é representado por uma ou mais [interfaces de rede elástica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ENIs) com endereços IP privados em suas sub-redes VPC.
A interface VPC endpoint conecta sua VPC diretamente à criptografia de AWS pagamento sem um gateway de internet, dispositivo NAT, conexão VPN ou conexão. AWS Direct Connect As instâncias em sua VPC não precisam de endereços IP públicos para se comunicar com a criptografia de AWS pagamento.
**Regiões**
AWS [A criptografia de pagamento oferece suporte a endpoints de VPC e políticas de endpoints de VPC Regiões da AWS em todos os AWS quais a criptografia de pagamento é suportada.](https://docs.aws.amazon.com/general/latest/gr/payment-cryptography.html)
**Topics**
+ [Considerações sobre endpoints AWS VPC de criptografia de pagamento](#vpce-considerations)
+ [Criação de um VPC endpoint para criptografia de pagamento AWS](#vpce-create-endpoint)
+ [Conectando-se a um AWS endpoint VPC de criptografia de pagamento](#vpce-connect)
+ [Controlar o acesso a um endpoint da VPC](#vpce-policy)
+ [Usar um endpoint da VPC em uma declaração de política](#vpce-policy-condition)
+ [Registrar o endpoint da VPC em log](#vpce-logging)
## Considerações sobre endpoints AWS VPC de criptografia de pagamento
**nota**
Embora os VPC endpoints permitam que você se conecte ao serviço em apenas uma zona de disponibilidade (AZ), recomendamos conectar-se a três zonas de disponibilidade para fins de alta disponibilidade e redundância.
*Antes de configurar uma interface VPC endpoint para AWS Payment Cryptography, consulte o tópico [Propriedades e limitações do endpoint da interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-interface-limitations) no Guia.AWS PrivateLink *
AWS O suporte à criptografia de pagamento para um VPC endpoint inclui o seguinte.
+ Você pode usar seu VPC endpoint para chamar todas as operações do plano de [controle de criptografia AWS de pagamento e operações do plano](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/API_Operations.html) de [dados de criptografia AWS de pagamento](https://docs.aws.amazon.com/payment-cryptography/latest/DataAPIReference/API_Operations.html) de uma VPC.
+ Você pode criar uma interface VPC endpoint que se conecta a um endpoint da região de criptografia AWS de pagamento.
+ AWS A criptografia de pagamento consiste em um plano de controle e um plano de dados. Você pode optar por configurar um ou ambos os subserviços AWS PrivateLink , mas cada um é configurado separadamente.
+ Você pode usar AWS CloudTrail registros para auditar o uso das chaves de criptografia de AWS pagamento por meio do VPC endpoint. Para obter detalhes, consulte [Registrar o endpoint da VPC em log](#vpce-logging).
## Criação de um VPC endpoint para criptografia de pagamento AWS
Você pode criar um VPC endpoint para criptografia de AWS pagamento usando o console da Amazon VPC ou a API da Amazon VPC. Para obter mais informações, consulte [Criar um endpoint de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) no *Guia do usuário do AWS PrivateLink *.
+ Para criar um VPC endpoint para criptografia de AWS pagamento, use os seguintes nomes de serviço:
```
com.amazonaws.region.payment-cryptography.controlplane
```
```
com.amazonaws.region.payment-cryptography.dataplane
```
Por exemplo, na região Oeste dos EUA (Oregon) (`us-west-2`), os nomes dos serviços seriam:
```
com.amazonaws.us-west-2.payment-cryptography.controlplane
```
```
com.amazonaws.us-west-2.payment-cryptography.dataplane
```
Para facilitar o uso do endpoint da VPC, é possível habilitar um [nome de DNS privado](https://docs.aws.amazon.com/vpc/latest/privatelink/verify-domains.html) para seu endpoint da VPC. Se você selecionar a opção **Ativar nome DNS, o nome** de host DNS padrão da criptografia de AWS pagamento será resolvido no seu VPC endpoint. Por exemplo, `https://controlplane.payment-cryptography.us-west-2.amazonaws.com` resolveria para um endpoint da VPC conectado ao nome de serviço `com.amazonaws.us-west-2.payment-cryptography.controlplane`.
Essa opção facilita usar o endpoint da VPC. O AWS SDKs e AWS CLI usa o nome de host DNS padrão da criptografia de AWS pagamento por padrão, então você não precisa especificar a URL do VPC endpoint em aplicativos e comandos.
Para mais informações, consulte [Acessar um serviço por meio de um endpoint de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#access-service-though-endpoint) no *Guia do AWS PrivateLink *.
## Conectando-se a um AWS endpoint VPC de criptografia de pagamento
Você pode se conectar à criptografia AWS de pagamento por meio do VPC endpoint usando AWS um SDK, o ou. AWS CLI Ferramentas da AWS para PowerShell Para especificar o endpoint da VPC, use seu nome de DNS.
Por exemplo, este comando [list-keys](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/list-keys.html) usa o parâmetro `endpoint-url` para especificar o endpoint da VPC. Para usar um comando como este, substitua o exemplo de ID de endpoint da VPC na sua conta.
```
$ aws payment-cryptography list-keys --endpoint-url https://vpce-1234abcdf5678c90a-09p7654s-us-east-1a.ec2.us-east-1.vpce.amazonaws.com
```
Se os nomes de host privados tiverem sido ativados ao criar o endpoint da VPC, você não precisa especificar o URL do endpoint da VPC nos comandos de CLI ou na configuração da aplicação. O nome de host DNS padrão da criptografia de AWS pagamento é resolvido no seu VPC endpoint. O AWS CLI e SDKs usa esse nome de host por padrão, para que você possa começar a usar o VPC endpoint para se conectar a AWS um endpoint regional de criptografia de pagamento sem alterar nada em seus scripts e aplicativos.
Para usar nomes de host privados, os atributos`enableDnsHostnames` e `enableDnsSupport` da sua VPC devem ser definidos como `true`. Para definir esses atributos, use a [ModifyVpcAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpcAttribute.html)operação. Para mais detalhes, consulte [Exibir e atualizar atributos DNS para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) no *Guia do usuário do Amazon VPC*.
## Controlar o acesso a um endpoint da VPC
Para controlar o acesso ao seu VPC endpoint para criptografia de AWS pagamento, anexe uma política de VPC endpoint ao seu *VPC endpoint*. A política de endpoint determina se os diretores podem usar o endpoint VPC para chamar operações de criptografia de pagamento com recursos AWS específicos de criptografia de pagamento. AWS
É possível criar uma política de endpoint da VPC ao criar seu endpoint e alterar a política de endpoint da VPC a qualquer momento. Use o console de gerenciamento da VPC [CreateVpcEndpoint](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpcEndpoint.html)ou [ModifyVpcEndpoint](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpcEndpoint.html)as operações. Você também pode criar e alterar uma política de VPC endpoint [usando](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpcendpoint.html) um modelo. AWS CloudFormation Para obter ajuda sobre o uso do console de gerenciamento da VPC, consulte [Criar um endpoint de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) e [Modificar um endpoint de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#modify-interface-endpoint) no *Guia do AWS PrivateLink *.
Para ajuda sobre como escrever e formatar um documento de política JSON, consulte a[Referência a políticas JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html), no *Manual do usuário do IAM*.
**Topics**
+ [Sobre políticas de endpoint da VPC](#vpce-policy-about)
+ [Política de endpoint da VPC padrão](#vpce-default-policy)
+ [Criar uma política de endpoint da VPC](#vpce-policy-create)
+ [Visualizar uma política de endpoint da VPC](#vpce-policy-get)
### Sobre políticas de endpoint da VPC
Para que uma solicitação de criptografia de AWS pagamento que usa um VPC endpoint seja bem-sucedida, o principal exige permissões de duas fontes:
+ Uma [política baseada em identidade](security_iam_id-based-policy-examples.md) deve dar permissão ao principal para chamar a operação no recurso (chaves ou alias AWS de criptografia de pagamento).
+ Uma política de endpoint da VPC deve dar permissão à entidade principal para usar o endpoint para fazer a solicitação.
Por exemplo, uma política de chaves pode dar ao principal permissão para chamar o [Decrypt](https://docs.aws.amazon.com/payment-cryptography/latest/DataAPIReference/API_DecryptData.html) em uma determinada chave de criptografia de AWS pagamento. No entanto, a política do VPC endpoint pode não permitir que o principal solicite essas chaves `Decrypt` de criptografia AWS de pagamento usando o endpoint.
Ou uma política de VPC endpoint pode permitir que um principal use o endpoint para chamar determinadas AWS chaves de criptografia de [StopKeyUsage](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/API_StopKeyUsage.html)pagamento. Mas se o diretor não tiver essas permissões de uma política do IAM, a solicitação falhará.
### Política de endpoint da VPC padrão
Cada endpoint da VPC tem uma política de endpoint da VPC, mas não é necessário especificar a política. Se você não especificar uma política, a política de endpoint padrão permitirá todas as operações por todas as entidades principais em todos os recursos sobre o endpoint.
No entanto, para recursos AWS de criptografia de pagamento, o principal também deve ter permissão para chamar a operação a partir de uma [política do IAM](security_iam_id-based-policy-examples.md). Portanto, na prática, a política padrão diz que se uma entidade principal tem permissão para chamar uma operação em um recurso, ela também pode chamá-la usando o endpoint.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*"
}
]
}
```
Para permitir que entidades principais usem o endpoint da VPC apenas para um subconjunto de suas operações permitidas, [crie ou atualize a política de endpoint da VPC](#vpce-policy-create).
### Criar uma política de endpoint da VPC
Uma política de endpoint da VPC determina se uma entidade principal tem permissão para usar o endpoint da VPC para executar operações em um recurso. Para recursos AWS de criptografia de pagamento, o principal também deve ter permissão para realizar as operações a partir de uma [política do IAM](security_iam_id-based-policy-examples.md).
Cada declaração de política de endpoint da VPC requer os seguintes elementos:
+ A entidade principal que pode executar ações
+ As ações que podem ser executadas
+ Os recursos nos quais as ações podem ser executadas
A declaração de política não especifica o endpoint da VPC. Em vez disso, ele se aplica a qualquer endpoint da VPC ao qual a política está associada. Para obter mais informações, consulte [Controlar o acesso a serviços com endpoint da VPCs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) no *Guia do usuário da Amazon VPC*.
Veja a seguir um exemplo de uma política de VPC endpoint para AWS criptografia de pagamento. Quando anexada a um VPC endpoint, essa política permite usar o VPC endpoint `ExampleUser` para chamar as operações especificadas nas chaves de criptografia de pagamento especificadas. AWS Antes de usar uma política como essa, substitua o exemplo do [identificador principal e da chave](concepts.md#concepts.key-identifer) por valores válidos da sua conta.
```
{
"Statement":[
{
"Sid": "AllowDecryptAndView",
"Principal": {"AWS": "arn:aws:iam::111122223333:user/ExampleUser"},
"Effect":"Allow",
"Action": [
"payment-cryptography:Decrypt",
"payment-cryptography:GetKey",
"payment-cryptography:ListAliases",
"payment-cryptography:ListKeys",
"payment-cryptography:GetAlias"
],
"Resource": "arn:aws:payment-cryptography:us-east-2:111122223333:key/kwapwa6qaifllw2h"
}
]
}
```
AWS CloudTrail registra todas as operações que usam o VPC endpoint. No entanto, seus CloudTrail registros não incluem operações solicitadas por diretores em outras contas ou operações de chaves de criptografia AWS de pagamento em outras contas.
Dessa forma, talvez você queira criar uma política de VPC endpoint que impeça que diretores em contas externas usem o VPC endpoint para chamar qualquer operação de criptografia de AWS pagamento em qualquer chave na conta local.
O exemplo a seguir usa a chave de condição [aws: PrincipalAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalaccount) global para negar acesso a todos os diretores para todas as operações em todas as chaves de criptografia de AWS pagamento, a menos que o principal esteja na conta local. Antes de usar uma política como esta, substitua o ID de conta demonstrativo por um válido.
```
{
"Statement": [
{
"Sid": "AccessForASpecificAccount",
"Principal": {"AWS": "*"},
"Action": "payment-cryptography:*",
"Effect": "Deny",
"Resource": "arn:aws:payment-cryptography:*:111122223333:key/*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "111122223333"
}
}
}
]
}
```
### Visualizar uma política de endpoint da VPC
Para visualizar a política de VPC endpoint para um endpoint, use o console de gerenciamento da [VPC](https://console.aws.amazon.com/vpc/) ou a operação. [DescribeVpcEndpoints](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcEndpoints.html)
O AWS CLI comando a seguir obtém a política para o endpoint com o ID do endpoint VPC especificado.
Antes de executar esse comando, substitua o ID de endpoint demonstrativo por um válido da sua conta.
```
$ aws ec2 describe-vpc-endpoints \
--query 'VpcEndpoints[?VpcEndpointId==`vpce-1234abcdf5678c90a`].[PolicyDocument]'
--output text
```
## Usar um endpoint da VPC em uma declaração de política
Você pode controlar o acesso aos recursos e operações da AWS Payment Cryptography quando a solicitação vem da VPC ou usa um VPC endpoint. Para fazer isso, use uma [política do IAM](security_iam_id-based-policy-examples.md)
+ Use a chave de condição `aws:sourceVpce` para conceder ou restringir o acesso com base no endpoint da VPC.
+ Use a chave de condição `aws:sourceVpc` para conceder ou restringir o acesso a uma VPC que hospedar o endpoint privado.
**nota**
A chave de `aws:sourceIP` condição não é efetiva quando a solicitação vem de um endpoint da [Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html). Para restringir solicitações a um endpoint da VPC, use as chaves de condições `aws:sourceVpce` ou `aws:sourceVpc`. Para obter mais informações, consulte [Gerenciamento de identidade e acesso para VPC endpoints e serviços de VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-iam.html) no *Guia do AWS PrivateLink *.
Você pode usar essas chaves de condição globais para controlar o acesso a chaves de criptografia de AWS pagamento, aliases e operações como essas [CreateKey](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/API_CreateKey.html)que não dependem de nenhum recurso específico.
Por exemplo, o exemplo de política de chaves a seguir permite que um usuário execute operações criptográficas específicas com chaves de criptografia de AWS pagamento somente quando a solicitação usa o VPC endpoint especificado, bloqueando o acesso da Internet e das AWS PrivateLink conexões (se configurado). Quando um usuário faz uma solicitação à AWS Payment Cryptography, o ID do VPC endpoint na solicitação é comparado ao valor `aws:sourceVpce` da chave de condição na política. Se não coincidirem, a solicitação será negada.
Para usar uma política como essa, substitua o Conta da AWS ID do espaço reservado e o VPC IDs endpoint por valores válidos para sua conta.
------
#### [ JSON ]
****
```
{
"Id": "example-key-1",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnableIAMPolicies",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root"
]
},
"Action": [
"payment-cryptography:*"
],
"Resource": "*"
},
{
"Sid": "RestrictUsageToMyVPCEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": [
"payment-cryptography:EncryptData",
"payment-cryptography:DecryptData"
],
"Resource": "arn:aws:payment-cryptography:us-east-1:111122223333:key/*",
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1234abcdf5678c90a"
}
}
}
]
}
```
------
Você também pode usar a chave de `aws:sourceVpc` condição para restringir o acesso às suas chaves de criptografia de AWS pagamento com base na VPC na qual o VPC endpoint reside.
O exemplo de política de chaves a seguir permite comandos que gerenciam as chaves de criptografia de AWS pagamento somente quando elas vêm de`vpc-12345678`. Além disso, permite comandos que usam as chaves AWS de criptografia de pagamento para operações criptográficas somente quando elas vêm. `vpc-2b2b2b2b` Você pode usar uma política como essa se uma aplicação é executada em uma VPC, mas você usa uma segunda VPC isolada para funções de gerenciamento.
Para usar uma política como essa, substitua o Conta da AWS ID do espaço reservado e o VPC IDs endpoint por valores válidos para sua conta.
------
#### [ JSON ]
****
```
{
"Id": "example-key-2",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAdminActionsFromVPC12345678",
"Effect": "Allow",
"Principal": {
"AWS": "111122223333"
},
"Action": [
"payment-cryptography:Create*",
"payment-cryptography:Encrypt*",
"payment-cryptography:ImportKey*",
"payment-cryptography:GetParametersForImport*",
"payment-cryptography:TagResource",
"payment-cryptography:UntagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:sourceVpc": "vpc-12345678"
}
}
},
{
"Sid": "AllowKeyUsageFromVPC2b2b2b2b",
"Effect": "Allow",
"Principal": {
"AWS": "111122223333"
},
"Action": [
"payment-cryptography:Encrypt*",
"payment-cryptography:Decrypt*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:sourceVpc": "vpc-2b2b2b2b"
}
}
},
{
"Sid": "AllowListReadActionsFromEverywhere",
"Effect": "Allow",
"Principal": {
"AWS": "111122223333"
},
"Action": [
"payment-cryptography:List*",
"payment-cryptography:Get*"
],
"Resource": "*"
}
]
}
```
------
## Registrar o endpoint da VPC em log
AWS CloudTrail registra todas as operações que usam o VPC endpoint. Quando uma solicitação para AWS Payment Cryptography usa um VPC endpoint, o ID do VPC endpoint aparece na entrada de registro que [AWS CloudTrail registra a](monitoring-cloudtrail.md) solicitação. Você pode usar o ID do endpoint para auditar o uso do seu endpoint VPC de criptografia de AWS pagamento.
Para proteger sua VPC, as solicitações negadas por uma [política de endpoint de VPC](#vpce-policy), mas que de outra forma seriam permitidas, não são registradas. [AWS CloudTrail](monitoring-cloudtrail.md)
Por exemplo, este exemplo de entrada de log registra uma solicitação de [GenerateMac](https://docs.aws.amazon.com/payment-cryptography/latest/DataAPIReference/API_GenerateMac.html) que usou o VPC endpoint. O campo `vpcEndpointId` aparece no final da entrada de log.
```
{
"eventVersion": "1.08",
"userIdentity": {
"principalId": "TESTXECZ5U9M4LGF2N6Y5:i-98761b8890c09a34a",
"arn": "arn:aws:sts::111122223333:assumed-role/samplerole/i-98761b8890c09a34a",
"accountId": "111122223333",
"accessKeyId": "TESTXECZ5U2ZULLHHMJG",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "TESTXECZ5U9M4LGF2N6Y5",
"arn": "arn:aws:iam::111122223333:role/samplerole",
"accountId": "111122223333",
"userName": "samplerole"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2024-05-27T19:34:10Z",
"mfaAuthenticated": "false"
},
"ec2RoleDelivery": "2.0"
}
},
"eventTime": "2024-05-27T19:49:54Z",
"eventSource": "payment-cryptography.amazonaws.com",
"eventName": "CreateKey",
"awsRegion": "us-east-1",
"sourceIPAddress": "172.31.85.253",
"userAgent": "aws-cli/2.14.5 Python/3.9.16 Linux/6.1.79-99.167.amzn2023.x86_64 source/x86_64.amzn.2023 prompt/off command/payment-cryptography.create-key",
"requestParameters": {
"keyAttributes": {
"keyUsage": "TR31_M1_ISO_9797_1_MAC_KEY",
"keyClass": "SYMMETRIC_KEY",
"keyAlgorithm": "TDES_2KEY",
"keyModesOfUse": {
"encrypt": false,
"decrypt": false,
"wrap": false,
"unwrap": false,
"generate": true,
"sign": false,
"verify": true,
"deriveKey": false,
"noRestrictions": false
}
},
"exportable": true
},
"responseElements": {
"key": {
"keyArn": "arn:aws:payment-cryptography:us-east-2:111122223333:key/kwapwa6qaifllw2h",
"keyAttributes": {
"keyUsage": "TR31_M1_ISO_9797_1_MAC_KEY",
"keyClass": "SYMMETRIC_KEY",
"keyAlgorithm": "TDES_2KEY",
"keyModesOfUse": {
"encrypt": false,
"decrypt": false,
"wrap": false,
"unwrap": false,
"generate": true,
"sign": false,
"verify": true,
"deriveKey": false,
"noRestrictions": false
}
},
"keyCheckValue": "A486ED",
"keyCheckValueAlgorithm": "ANSI_X9_24",
"enabled": true,
"exportable": true,
"keyState": "CREATE_COMPLETE",
"keyOrigin": "AWS_PAYMENT_CRYPTOGRAPHY",
"createTimestamp": "May 27, 2024, 7:49:54 PM",
"usageStartTimestamp": "May 27, 2024, 7:49:54 PM"
}
},
"requestID": "f3020b3c-4e86-47f5-808f-14c7a4a99161",
"eventID": "b87c3d30-f3ab-4131-87e8-bc54cfef9d29",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"vpcEndpointId": "vpce-1234abcdf5678c90a",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "vpce-1234abcdf5678c90a-oo28vrvr.controlplane.payment-cryptography.us-east-1.vpce.amazonaws.com"
}
}
```
# Usar TLS pós-quântico híbrido
AWS A criptografia de pagamento e muitos outros serviços oferecem suporte a uma opção híbrida de troca de chaves pós-quânticas para o protocolo de criptografia de rede Transport Layer Security (TLS). Você pode usar essa opção de TLS ao se conectar a endpoints de API ou ao usar a AWS. SDKs Esses recursos opcionais de troca de chaves pós-quânticas híbridas são, no mínimo, tão seguros quanto a criptografia TLS que usamos atualmente e provavelmente fornecerão benefícios adicionais de segurança em longo prazo.
Os dados que você envia para serviços habilitados são protegidos em trânsito pela criptografia fornecida por uma conexão TLS (Transport Layer Security). Os pacotes de criptografia clássicos baseados em RSA e ECC que a criptografia de AWS pagamento suporta para sessões de TLS inviabilizam os ataques de força bruta aos mecanismos de troca de chaves com a tecnologia atual. No entanto, se computadores quânticos (CRQC) de grande escala ou criptograficamente relevantes se tornarem práticos no futuro, os mecanismos de troca de chaves TLS existentes estarão suscetíveis a esses ataques. É possível que os adversários comecem a coletar dados criptografados agora com a esperança de que possam decifrá-los no futuro (colha agora, decifre depois). Se você estiver desenvolvendo aplicativos que dependem da confidencialidade de longo prazo dos dados transmitidos por uma conexão TLS, considere um plano para migrar para a criptografia pós-quântica antes que computadores quânticos em grande escala estejam disponíveis para uso. AWS está trabalhando para se preparar para esse futuro, e queremos que você também esteja bem preparado.
![\[Um adversário que já gravou uma sessão TLS. Anos depois, quando o adversário tem um CRQC, o adversário pode primeiro recuperar a chave de sessão quebrando a troca de chaves clássica usando o CRQC. O adversário pode então decifrar os dados usando a chave de sessão descoberta. Os dados transmitidos anteriormente, se ainda valiosos, agora estão comprometidos.\]](http://docs.aws.amazon.com/pt_br/payment-cryptography/latest/userguide/images/pqtls-risk2.png)
*Para proteger os dados criptografados hoje contra possíveis ataques futuros, AWS está participando com a comunidade criptográfica no desenvolvimento de algoritmos quânticos resistentes ou pós-quânticos.* AWS implementou suítes de cifras *híbridas* pós-quânticas de troca de chaves que combinam elementos clássicos e pós-quânticos para garantir que sua conexão TLS seja pelo menos tão forte quanto seria com suítes de criptografia clássicas.
Esses pacotes de criptografia híbrida estão disponíveis para uso em suas cargas de trabalho de produção ao usar versões recentes da AWS. SDKs Para obter mais informações sobre como realizar enable/disable esse comportamento, consulte [Habilitando o TLS híbrido pós-quântico](pqtls-details.md)
![\[Uma sessão TLS que é protegida usando o acordo de chave clássico e o acordo de chave pós-quântica. Hoje, um adversário não pode quebrar a parte clássica do acordo-chave. Se o adversário registrar os dados e tentar decifrá-los no futuro com um CRQC, o acordo de chave pós-quântica mantém a chave de sessão segura. Assim, os dados transmitidos de hoje permanecem protegidos contra descobertas, mesmo no futuro. É por isso que o TLS híbrido pós-quântico é importante hoje em dia.\]](http://docs.aws.amazon.com/pt_br/payment-cryptography/latest/userguide/images/pqtls-mitigation.png)
## Sobre a troca de chaves pós-quântica híbrida no TLS
[Os algoritmos usados são um *híbrido* que AWS combina o [Elliptic Curve Diffie-Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) (ECDH), um algoritmo clássico de troca de chaves usado atualmente no TLS, com o [Mecanismo de Encapsulamento de Chaves Baseado em Módulos (), um algoritmo de criptografia de chave pública e estabelecimento de chaves que o Instituto Nacional de Padrões e Tecnologia (NISTML-KEM) designou como seu primeiro algoritmo padrão de acordo de chave pós-quântico](https://csrc.nist.gov/pubs/fips/203/final).](https://csrc.nist.gov/pubs/fips/203/final) Esse híbrido utiliza cada um dos algoritmos de maneira independente para gerar uma chave. Depois, ele combina as duas chaves criptograficamente.
## Saiba mais sobre o PQC
Para obter informações sobre o projeto de criptografia pós-quântica no Instituto Nacional de Padrões e Tecnologia (NIST — National Institute for Standards and Technology), consulte [Criptografia pós-quântica](https://csrc.nist.gov/Projects/Post-Quantum-Cryptography).
Para obter informações sobre a padronização de criptografia pós-quântica do NIST, consulte [Post-Quantum Cryptography Standardization](https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization) (Padronização de criptografia pós-quântica).
# Habilitando o TLS híbrido pós-quântico
A AWS SDKs e as ferramentas têm recursos criptográficos e configurações que diferem entre a linguagem e o tempo de execução. Atualmente, há três maneiras pelas quais um SDK ou ferramenta da AWS fornece suporte ao PQ TLS:
**Topics**
+ [SDKs com PQ TLS habilitado por padrão](#pq-tls-default)
+ [Suporte opcional para PQ TLS](#pq-tls-opt-in)
+ [SDKs que dependem do System OpenSSL](#pq-tls-open-ssl)
+ [AWS SDKs e ferramentas que não planejam oferecer suporte ao PQ TLS](#pq-tls-nosupport)
## SDKs com PQ TLS habilitado por padrão
**nota**
A partir de 6 de novembro de 2025, o AWS SDK e suas bibliotecas CRT subjacentes para macOS e Windows usam bibliotecas de sistema para TLS, portanto, os recursos do PQ TLS nessas plataformas geralmente são determinados pelo suporte em nível de sistema.
### AWS SDK for Go
O AWS SDK for Go usa a própria implementação de TLS da Golang fornecida por sua biblioteca padrão. O Golang oferece suporte e prefere o PQ TLS a partir da versão 1.24, então os usuários do AWS SDK for Go podem habilitar o PQ TLS simplesmente atualizando o Golang para a versão 1.24
### SDK da AWS para JavaScript (navegador)
O AWS SDK para JavaScript (navegador) usa a pilha TLS do navegador, então o SDK negociará o PQ TLS se o tempo de execução do navegador o suportar e preferir. O Firefox lançou o suporte para PQ TLS na v132.0. O Chrome anunciou suporte para PQ TLS na v131. O Edge oferece suporte ao PQ TLS opcional na versão 120 para desktop e 140 para Android.
### AWS SDK para Node.js
A partir do Node.js v22.20 (LTS) e v24.9.0, o Node.js vincula e agrupa estaticamente o OpenSSL 3.5. Isso significa que o PQ TLS está habilitado e preferido por padrão para essas e versões subsequentes.
### SDK da AWS para Kotlin
O Kotlin SDK suporta e prefere o PQ TLS no Linux a partir da versão 1.5.78. Como o cliente baseado em CRT do AWS SDK para Kotlin depende de bibliotecas do sistema para TLS no macOS e no Windows, o suporte ao PQ TLS dependerá dessas bibliotecas subjacentes do sistema.
### SDK da AWS para Rust
O AWS SDK para Rust distribui pacotes distintos (conhecidos como “caixas” no ecossistema Rust) para cada cliente de serviço. Tudo isso é gerenciado em um GitHub repositório consolidado, mas cada cliente de serviço segue sua própria versão e cadência de lançamento. O SDK consolidado lançou a preferência PQ TLS em 29/08/25, portanto, qualquer versão individual do cliente de serviço lançada após essa data oferecerá suporte e preferirá PQ TLS por padrão.
Você pode determinar a versão mínima compatível com PQ TLS para um cliente de serviço específico navegando até o URL da versão relevante do crates.io (por exemplo, a criptografia de AWS pagamento está [aqui](https://crates.io/crates/aws-sdk-paymentcryptography/versions)) e encontrando a primeira versão publicada após 29 a 25 de agosto. Qualquer versão do cliente de serviço publicada após 29 de agosto de 25 terá o PQ TLS habilitado e preferido por padrão.
## Suporte opcional para PQ TLS
### AWS SDK for C\$1\$1
Por padrão, o SDK para C\$1\$1 usa clientes nativos da plataforma, como libcurl e. WinHttp O Libcurl geralmente depende do OpenSSL do sistema para TLS, então o PQ TLS só é habilitado por padrão se o OpenSSL do sistema for ≥ v3.5. Você pode substituir esse padrão no SDK para C\$1\$1 v1.11.673 ou posterior e optar pelo AwsCrtHttpClient que suporta e ativa o PQ TLS por padrão.
[Notas sobre a criação do Opt-In PQ TLS Você pode buscar as dependências CRT do SDK com esse script.](https://github.com/aws/aws-sdk-cpp/blob/main/prefetch_crt_dependency.sh) A criação do SDK a partir do código-fonte é descrita [aqui](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/sdk-from-source.html) [e aqui](https://github.com/aws/aws-sdk-cpp/tree/main?tab=readme-ov-file#building-from-source), mas observe que talvez você precise de alguns CMake sinalizadores adicionais:
```
-DUSE_CRT_HTTP_CLIENT=ON \
-DUSE_TLS_V1_2=OFF \
-DUSE_TLS_V1_3=ON \
-DUSE_OPENSSL=OFF \
```
### AWS SDK para Java
A partir da v2, o AWS SDK for Java fornece um cliente HTTP do AWS Common Runtime (AWS CRT) que pode ser configurado para executar o PQ TLS. A partir da v2.35.11, ele AwsCrtHttpClient ativa e prefere o PQ TLS por padrão, onde quer que seja usado.
## SDKs que dependem do System OpenSSL
Várias ferramentas SDKs e AWS dependem da libcrypto/libssl biblioteca do sistema para TLS. A biblioteca do sistema mais usada é o OpenSSL. O OpenSSL habilitou o suporte ao PQ TLS na versão 3.5, então a maneira mais fácil de configurar SDKs essas ferramentas e essas ferramentas para o PQ TLS é usá-las em uma distribuição do sistema operacional que tenha pelo menos o OpenSSL 3.5 instalado.
Você também pode configurar um contêiner do Docker para usar o OpenSSL 3.5 para habilitar o PQ TLS em qualquer sistema que ofereça suporte ao Docker. Consulte TLS pós-quântico em Python para ver um exemplo de como configurar isso para Python.
### CLI da AWS
O suporte do PQ TLS com o [instalador da AWS CLI estará disponível](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) em breve. Para habilitar imediatamente, você pode usar instaladores alternativos para a AWS CLI, que varia de acordo com o sistema operacional, e pode habilitar o PQ TLS.
Para macOS, instale a AWS CLI via [Homebrew e garanta que seu OpenSSL vendido pelo Homebrew](https://brew.sh/) seja atualizado para a versão 3.5\$1. Você pode fazer isso com “brew install openssl @3 .6” e validar com “brew list \$1 grep openssl”.
Para Ubuntu ou Debian Linux: certifique-se de que a distribuição Linux que você está usando tenha o OpenSSL 3.5\$1 instalado como sistema OpenSSL. [Em seguida, instale a AWS CLI usando apt ou PyPI.](https://pypi.org/project/awscliv2/) Com esses pré-requisitos, a AWS CLI vendida pelo apt ou pelo PyPI será configurada para negociar o PQ-TLS. [Para step-by-step obter instruções sobre como validar a instalação, consulte o [repositório github](https://github.com/aws-samples/sample-post-quantum-tls-python/) e a postagem do blog que a acompanha.](https://aws.amazon.com/blogs/security/post-quantum-tls-in-python/)
### AWS SDK para PHP
O AWS SDK para PHP depende do sistema libssl/libcrypto. Para usar o PQ TLS, use esse SDK em uma distribuição de sistema operacional que tenha pelo menos o OpenSSL 3.5 instalado.
### AWS SDK para Python (Boto3)
O SDK da AWS para Python (Boto3) depende do sistema libssl/libcrypto. Para usar o PQ TLS, use esse SDK em uma distribuição de sistema operacional que tenha pelo menos o OpenSSL 3.5 instalado.
### AWS SDK para Ruby
O AWS SDK para Ruby depende do sistema libssl/libcrypto. Para usar o PQ TLS, use esse SDK em uma distribuição de sistema operacional que tenha pelo menos o OpenSSL 3.5 instalado.
### AWS SDK for .NET
No Linux, o AWS SDK para.NET depende do sistema libssl/libcrypto. Para usar o PQ TLS, use esse SDK em uma distribuição de sistema operacional que tenha pelo menos o OpenSSL 3.5 instalado. [No Windows e no macOS, o PQ TLS está disponível a partir [do.NET 10](https://devblogs.microsoft.com/dotnet/post-quantum-cryptography-in-dotnet/) e no Windows 11.](https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-apis-now-generally-available-on-microsoft-platforms/4469093) [No macOS, o suporte ao TLS 1.3 (um pré-requisito para o PQ TLS) pode ser ativado ao se inscrever no Network.framework da Apple, conforme descrito aqui.](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-10/libraries#tls-13-for-macos-client) Supondo uma versão mínima do.NET de 10, o PQ TLS deve então ser habilitado.
## AWS SDKs e ferramentas que não planejam oferecer suporte ao PQ TLS
No momento, não há planos para oferecer suporte aos seguintes idiomas SDKs e ferramentas:
+ SDK da AWS para SAP
+ SDK da AWS para Swift
+ Ferramentas da AWS para Windows PowerShell
# Melhores práticas de segurança para criptografia AWS de pagamentos
AWS A criptografia de pagamento oferece suporte a muitos recursos de segurança integrados ou que você pode implementar opcionalmente para aprimorar a proteção de suas chaves de criptografia e garantir que elas sejam usadas para a finalidade pretendida, incluindo [políticas de IAM](security_iam_service-with-iam.md), um amplo conjunto de chaves de condição de política para refinar suas principais políticas e políticas do IAM e a aplicação integrada das regras de PIN do PCI em relação aos blocos de chaves.
**Importante**
As diretrizes gerais fornecidas não representam uma solução de segurança completa. Como nem todas as melhores práticas são apropriadas para todas as situações, elas não se destinam a ser prescritivas.
+ **Uso da chave e modos de uso**: a criptografia de AWS pagamento segue e impõe as restrições de uso e modo de uso da chave, conforme descrito na Especificação de bloco de chaves interoperável de troca segura de chaves ANSI X9 TR 31-2018 e é consistente com o requisito de segurança de PIN PCI 18-3. Isso limita a capacidade de usar uma única chave para várias finalidades e vincula criptograficamente os metadados da chave (como operações permitidas) ao próprio material da chave. AWS A criptografia de pagamento impõe automaticamente essas restrições, como a de que uma chave de criptografia de chave (TR31\$1K0\$1KEY\$1ENCRYPTION\$1KEY) também não possa ser usada para decodificação de dados. Consulte [Compreendendo os principais atributos da chave AWS de criptografia de pagamento](keys-validattributes.md) para obter mais detalhes.
+ **Limite o compartilhamento de material de chave simétrica**: compartilhe material de chave simétrica (como chaves de criptografia PIN ou chaves de criptografia de chave) com, no máximo, uma outra entidade. Se houver necessidade de transmitir material confidencial para mais entidades ou parceiros, crie chaves adicionais. AWS A criptografia de pagamento nunca expõe material de chave simétrica ou material de chave privada assimétrica de forma clara.
+ **Use aliases ou tags para associar chaves a determinados casos de uso ou parceiros**: aliases podem ser usados para denotar facilmente o caso de uso associado a uma chave como alias/BIN\$112345\$1CVK para denotar uma chave de verificação de cartão associada ao BIN 12345. Para fornecer mais flexibilidade, considere criar tags como bin=12345, use\$1case=acquiring,country=us,partner=foo. Aliases e tags também podem ser usados para limitar o acesso, como impor controles de acesso entre a emissão e a aquisição de casos de uso.
+ **Pratique o acesso com privilégio mínimo**: o IAM pode ser usado para limitar o acesso de produção a sistemas em vez de indivíduos, como proibir usuários individuais de criar chaves ou executar operações criptográficas. O IAM também pode ser usado para limitar o acesso a comandos e chaves que podem não ser aplicáveis ao seu caso de uso, como limitar a capacidade de gerar ou validar PINs para um adquirente. Outra forma de usar o acesso com privilégio mínimo é restringir operações confidenciais (como importação de chaves) a contas de serviço específicas. Consulte [AWS Exemplos de políticas baseadas em identidade de criptografia de pagamento](security_iam_id-based-policy-examples.md) para ver exemplos.
**Consulte também**
+ [Gerenciamento de identidade e acesso para criptografia AWS de pagamento](security-iam.md)
+ [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html), no*Manual do usuário do IAM*