Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Seguridad en la criptografía AWS de pagos
La seguridad en la nube AWS es la máxima prioridad. Como AWS cliente, usted se beneficia de una arquitectura de centro de datos y red diseñada para cumplir con los requisitos de las organizaciones más sensibles a la seguridad.
La seguridad es una responsabilidad compartida entre usted AWS y usted. El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) la describe como seguridad de la nube y seguridad en la nube:
+ **Seguridad de la nube**:AWS es responsable de proteger la infraestructura que ejecuta AWS los servicios en la AWS nube. AWS también le proporciona servicios que puede utilizar de forma segura. Los auditores externos prueban y verifican periódicamente la eficacia de nuestra seguridad como parte de los [AWS programas](https://aws.amazon.com/compliance/programs/) de de . Para obtener más información sobre los programas de conformidad que se aplican a la criptografía de AWS pagos, consulte [Servicios de AWS en el ámbito de aplicación por programa de conformidad](https://aws.amazon.com/compliance/services-in-scope/) .
+ **Seguridad en la nube**: su responsabilidad viene determinada por el AWS servicio que utilice. También es responsable de otros factores, incluida la confidencialidad de los datos, los requisitos de la empresa y la legislación y la normativa aplicables.
Este tema le ayuda a entender cómo aplicar el modelo de responsabilidad compartida al utilizar la criptografía AWS de pagos. Le muestra cómo configurar la criptografía AWS de pagos para cumplir sus objetivos de seguridad y conformidad. También aprenderá a utilizar otros AWS servicios que le ayudan a supervisar y proteger sus recursos de criptografía AWS de pagos.
**Topics**
+ [Protección de datos](data-protection.md)
+ [Resiliencia](resilience.md)
+ [Seguridad de la infraestructura](infrastructure-security.md)
+ [Utilice Amazon VPC y AWS PrivateLink](vpc-endpoint.md)
+ [TLS híbrido postcuántico](pqtls.md)
+ [Prácticas recomendadas de seguridad](security-best-practices.md)
# La protección de datos en la criptografía AWS de pagos
El [modelo de ](https://aws.amazon.com/compliance/shared-responsibility-model/) se aplica a protección de datos en la criptografía de AWS pagos. Como se describe en este modelo, AWS es responsable de proteger la infraestructura global que ejecuta todos los Nube de AWS. Eres responsable de mantener el control sobre el contenido alojado en esta infraestructura. También eres responsable de las tareas de administración y configuración de seguridad para los Servicios de AWS que utiliza. Para obtener más información sobre la privacidad de los datos, consulte las [Preguntas frecuentes sobre la privacidad de datos](https://aws.amazon.com/compliance/data-privacy-faq/). Para obtener información sobre la protección de datos en Europa, consulte la publicación de blog sobre el [Modelo de responsabilidad compartida de AWS y GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) en el * Blog de seguridad de AWS *.
Con fines de protección de datos, le recomendamos que proteja Cuenta de AWS las credenciales y configure los usuarios individuales con AWS IAM Identity Center o AWS Identity and Access Management (IAM). De esta manera, solo se otorgan a cada usuario los permisos necesarios para cumplir sus obligaciones laborales. También recomendamos proteger sus datos de la siguiente manera:
+ Utiliza la autenticación multifactor (MFA) en cada cuenta.
+ Se utiliza SSL/TLS para comunicarse con AWS los recursos. Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Configure la API y el registro de actividad de los usuarios con AWS CloudTrail. Para obtener información sobre el uso de CloudTrail senderos para capturar AWS actividades, consulte [Cómo trabajar con CloudTrail senderos](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) en la *Guía del AWS CloudTrail usuario*.
+ Utilice soluciones de AWS cifrado, junto con todos los controles de seguridad predeterminados Servicios de AWS.
+ Utiliza servicios de seguridad administrados avanzados, como Amazon Macie, que lo ayuden a detectar y proteger la información confidencial almacenada en Amazon S3.
+ Si necesita módulos criptográficos validados por FIPS 140-3 para acceder a AWS través de una interfaz de línea de comandos o una API, utilice un punto final FIPS. Para obtener más información sobre los puntos de conexión de FIPS disponibles, consulte [Estándar de procesamiento de la información federal (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Se recomienda encarecidamente no introducir nunca información confidencial o sensible, como por ejemplo, direcciones de correo electrónico de clientes, en etiquetas o campos de formato libre, tales como el campo **Nombre**. Esto incluye cuando trabaja con criptografía de AWS pagos u otra forma Servicios de AWS mediante la consola, la API o. AWS CLI AWS SDKs Cualquier dato que introduzca en etiquetas o campos de formato libre utilizados para los nombres se pueden emplear para los registros de facturación o diagnóstico. Si proporciona una URL a un servidor externo, recomendamos encarecidamente que no incluya información de credenciales en la URL a fin de validar la solicitud para ese servidor.
AWS Payment Cryptography almacena y protege sus claves de cifrado de pagos para que estén altamente disponibles al mismo tiempo que le proporciona un control de acceso sólido y flexible.
**Topics**
+ [Rotación del material de claves](#key-protection)
+ [Cifrado de datos](#data-encryption)
+ [Cifrado en reposo](#encryption-rest)
+ [Cifrado en tránsito](#encryption-transit)
+ [Privacidad del tráfico entre redes](#internetwork)
## Rotación del material de claves
Por defecto, AWS Payment Cryptography protege el material criptográfico de las claves de pago gestionadas por el servicio. Además, AWS Payment Cryptography ofrece opciones para importar material de claves creado fuera del servicio. Para obtener más detalles sobre las claves de pago y el material de claves, consulte los detalles de criptografía de AWS Payment Cryptography.
## Cifrado de datos
Los datos de AWS Payment Cryptography consisten en claves de AWS Payment Cryptography, el material de claves criptográficas que representan y sus atributos de uso. El material clave solo existe en texto plano en los módulos de seguridad de hardware de criptografía de pagos de AWS (HSMs) y solo cuando está en uso. De lo contrario, el material de la clave y los atributos se cifran y se almacenan en almacenamiento persistente duradero.
El material clave que la criptografía de pagos de AWS genera o carga para las claves de pago nunca sale de los límites de la criptografía HSMs de pagos de AWS sin cifrar. Puede ser exportado cifrado por las operaciones API de AWS Payment Cryptography.
## Cifrado en reposo
La criptografía de pagos de AWS genera material clave para las claves de pago en las listas PCI PTS HSM. HSMs Cuando no se utiliza, el material de claves se cifra mediante una clave de HSM y se escribe en un almacenamiento duradero y persistente. El material clave para las claves de criptografía de pagos y las claves de cifrado que protegen el material clave nunca están en formato de texto plano. HSMs
El cifrado y la administración del material de claves para las claves de Payment Cryptography está completamente a cargo del servicio.
Para obtener más información, consulte el documento técnico Detalles criptográficos de AWS Key Management Service.
## Cifrado en tránsito
El material clave que la criptografía de AWS pagos genera o carga para las claves de pago nunca se exporta ni transmite en las operaciones de la API de criptografía de AWS pagos en texto claro. AWS La criptografía de pagos utiliza identificadores clave para representar las claves en las operaciones de la API.
Sin embargo, algunas operaciones de API exportan claves cifradas mediante una clave de intercambio de claves previamente compartida o asimétrica. Además, los clientes pueden usar las operaciones de la API para importar material de claves encriptadas para las claves de pago.
Todas las llamadas a la API de criptografía de AWS pagos deben firmarse y transmitirse mediante Transport Layer Security (TLS). AWS La criptografía de pagos requiere versiones TLS y conjuntos de cifrado definidos por PCI como «criptografía sólida». Todos los terminales de servicio admiten el TLS 1.2—1.3 y el TLS poscuántico híbrido.
Para obtener más información, consulte el documento técnico Detalles criptográficos de AWS Key Management Service.
## Privacidad del tráfico entre redes
AWS La criptografía de pagos admite una consola de administración de AWS y un conjunto de operaciones de API que le permiten crear y administrar claves de pago y utilizarlas en operaciones criptográficas.
AWS La criptografía de pagos admite dos opciones de conectividad de red desde su red privada a AWS.
+ Una conexión IPSec VPN a través de Internet.
+ AWS Direct Connect vincula su red interna con una ubicación de AWS Direct Connect a través de cable estándar Ethernet de fibra óptica.
Todas las llamadas de la API de Payment Cryptography deben firmarse y transmitirse mediante seguridad de la capa de transporte (TLS). Las llamadas también requieren un paquete de cifrado moderno que admita el secreto perfecto en el futuro. El tráfico a los módulos de seguridad de hardware (HSMs) que almacenan el material clave para las claves de pago solo está permitido desde hosts conocidos de la API de criptografía de pagos de AWS a través de la red interna de AWS.
Para conectarse directamente a la criptografía de pagos de AWS desde su nube privada virtual (VPC) sin enviar tráfico a través de la Internet pública, utilice los puntos de enlace de VPC, con tecnología de AWS. PrivateLink Para obtener más información, consulte Conexión a AWS Payment Cryptography a través de un punto de conexión de VPC.
AWS Payment Cryptography admite también una opción de intercambio híbrido postcuántico de claves para el protocolo de cifrado de red de seguridad de la capa de transporte (TLS). Puede utilizar esta opción de TLS cuando se conecte a los puntos de conexión de la API de AWS Payment Cryptography.
# Resiliencia en la criptografía de pagos AWS
AWS La infraestructura global se basa en AWS regiones y zonas de disponibilidad. Las regiones proporcionan varias zonas de disponibilidad físicamente independientes y aisladas que se encuentran conectadas mediante redes con un alto nivel de rendimiento y redundancia, además de baja demora. Con las zonas de disponibilidad, puede diseñar y utilizar aplicaciones y bases de datos que realizan una conmutación por error automática entre las zonas sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de uno o varios centros de datos.
Para obtener más información sobre AWS las regiones y las zonas de disponibilidad, consulte [Infraestructura AWS global](https://aws.amazon.com/about-aws/global-infrastructure/).
## Aislamiento regional
La criptografía de pagos de AWS es un servicio regional que está disponible en varias regiones.
El diseño regionalmente aislado de AWS Payment Cryptography garantiza que un problema de disponibilidad en una región de AWS no puede afectar al funcionamiento de AWS Payment Cryptography en ninguna otra región. AWS Payment Cryptography está diseñado para garantizar un tiempo de inactividad planificado cero, con todas las actualizaciones de software y operaciones de escalado realizadas de manera imperceptible y sin problemas.
El acuerdo de nivel de servicio (SLA) de criptografía de pagos de AWS incluye un compromiso de servicio del 99,99% para toda la criptografía de pagos. APIs Para cumplir este compromiso, AWS Payment Cryptography garantiza que todos los datos y la información de autorización necesarios para ejecutar una solicitud de la API estén disponibles en todos los hosts regionales que reciben la solicitud.
La infraestructura de criptografía de pagos de AWS se replica en al menos tres zonas de disponibilidad (AZs) de cada región. Para garantizar que los errores de varios hosts no afecten al rendimiento de la criptografía de pagos de AWS, la criptografía de pagos de AWS está diseñada para atender el tráfico de clientes desde cualquier lugar de una AZs región.
Los cambios realizados en las propiedades o permisos de una clave de pagos se replican en todos los hosts de la región para garantizar que cualquier host de la región pueda procesar de manera correcta la solicitud posterior. Las solicitudes de operaciones criptográficas que utilizan su clave de pago se reenvían a una flota de módulos de seguridad de hardware de criptografía de pagos de AWS (HSMs), cualquiera de los cuales puede realizar la operación con la clave de pago.
## Diseño de varios inquilinos
El diseño de varios inquilinos de AWS Payment Cryptography permite cumplir el SLA de disponibilidad y mantener altas tasas de solicitudes, al tiempo que protege la confidencialidad de las claves y los datos.
Se implementan varios mecanismos de cumplimiento de la integridad para garantizar que la clave de pagos especificada para la operación criptográfica sea siempre la que se utiliza.
El material de clave de texto sin formato para las claves de Payment Cryptography está ampliamente protegido. El material de clave se cifra en el HSM tan pronto como se crea y el material de clave cifrado se mueve de inmediato al almacenamiento seguro. La clave cifrada se recupera y se descifra dentro del HSM justo a tiempo para su uso. La clave de texto sin formato permanece en la memoria HSM solo durante el tiempo necesario para completar la operación criptográfica. El material clave en texto simple nunca sale del archivo HSMs; nunca se escribe en un almacenamiento persistente.
Para obtener más información acerca de los mecanismos que AWS Payment Cryptography utiliza para proteger sus claves, consulte Detalles criptográficos de AWS Payment Cryptography.
# Seguridad de la infraestructura en AWS Payment Cryptography
Como servicio gestionado, AWS Payment Cryptography está protegido por los procedimientos de seguridad de red AWS global que se describen en el documento técnico [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf).
Utiliza las llamadas a la API AWS publicadas para acceder a AWS Payment Cryptography través de la red. Los clientes deben ser compatibles con Transport Layer Security (TLS) 1.2 o una versión posterior. Los clientes también deben ser compatibles con conjuntos de cifrado con confidencialidad directa total (PFS) tales como Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles con estos modos.
Además, las solicitudes deben estar firmadas mediante un ID de clave de acceso y una clave de acceso secreta que esté asociada a una entidad principal de IAM. También puede utilizar [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) para generar credenciales de seguridad temporales para firmar solicitudes.
## Aislamiento de hosts físicos
La seguridad de la infraestructura física que AWS Payment Cryptography utiliza está sujeto a los controles que se describen en la sección Seguridad Física y Ambiental de Amazon Web Services: Información general de los procesos de seguridad. Puede encontrar más detalles en los informes de conformidad y los resultados de auditoría de terceros enumerados en la sección anterior.
La criptografía de pagos de AWS es compatible con módulos de seguridad de hardware dedicados que figuran en commercial-off-the-shelf PCI PTS HSM (). HSMs El material clave de las claves de criptografía de pagos de AWS se almacena solo en una memoria volátil y solo mientras se utilice la clave de criptografía de pagos. HSMs HSMs se encuentran en racks de acceso controlado dentro de los centros de datos de Amazon que imponen un doble control para cualquier acceso físico. Para obtener información detallada sobre el funcionamiento de la criptografía de pagos de AWS HSMs, consulte Detalles criptográficos de criptografía de pagos de AWS.
# Conexión a la criptografía AWS de pagos a través de un punto final de VPC
Puede conectarse directamente a la criptografía de AWS pagos a través de un punto final de interfaz privada en su nube privada virtual (VPC). Cuando utiliza un punto final de VPC de interfaz, la comunicación entre su VPC y la criptografía de AWS pagos se lleva a cabo íntegramente dentro de la red. AWS
AWS La criptografía de pagos es compatible con los puntos de conexión de Amazon Virtual Private Cloud (Amazon VPC) con la tecnología de. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/) Cada punto final de la VPC está representado por una o más [interfaces de red elásticas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) (ENIs) con direcciones IP privadas en las subredes de la VPC.
El punto final de la interfaz VPC conecta su VPC directamente a la criptografía de AWS pagos sin necesidad de una pasarela de Internet, un dispositivo NAT, una conexión VPN o una conexión. AWS Direct Connect Las instancias de su VPC no necesitan direcciones IP públicas para comunicarse con AWS Payment Cryptography.
**Regions**
AWS La criptografía de pagos es compatible con los puntos de enlace de VPC y las políticas de puntos de enlace de VPC Regiones de AWS [AWS en](https://docs.aws.amazon.com/general/latest/gr/payment-cryptography.html) todos los que se admite la criptografía de pagos.
**Topics**
+ [Consideraciones sobre los puntos AWS finales de VPC de criptografía de pagos](#vpce-considerations)
+ [Creación de un punto final de VPC para AWS criptografía de pagos](#vpce-create-endpoint)
+ [Conexión a un punto final de AWS VPC de criptografía de pagos](#vpce-connect)
+ [Control del acceso a un punto de conexión de VPC](#vpce-policy)
+ [Utilizar un punto de conexión de VPC en una declaración de política](#vpce-policy-condition)
+ [Registro de su punto de conexión de VPC](#vpce-logging)
## Consideraciones sobre los puntos AWS finales de VPC de criptografía de pagos
**nota**
Si bien los puntos de enlace de la VPC le permiten conectarse al servicio en tan solo una zona de disponibilidad (AZ), le recomendamos que se conecte a tres zonas de disponibilidad por motivos de alta disponibilidad y redundancia.
*Antes de configurar un punto final de la VPC de la interfaz para la criptografía de AWS pagos, consulte el tema de [propiedades y limitaciones del punto final de la interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-interface-limitations) en la Guía.AWS PrivateLink *
AWS El soporte de criptografía de pagos para un punto final de VPC incluye lo siguiente.
+ Puede usar su punto final de VPC para llamar a todas las operaciones del plano de [control de criptografía de AWS pagos y las operaciones del plano](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/API_Operations.html) de [datos de criptografía de AWS pagos desde](https://docs.aws.amazon.com/payment-cryptography/latest/DataAPIReference/API_Operations.html) una VPC.
+ Puede crear un punto final de VPC de interfaz que se conecte a un punto final de la región de criptografía AWS de pagos.
+ AWS La criptografía de pagos consta de un plano de control y un plano de datos. Puede elegir configurar uno o ambos subservicios, AWS PrivateLink pero cada uno se configura por separado.
+ Puedes usar AWS CloudTrail los registros para auditar tu uso de las claves de criptografía de AWS pago a través del punto final de la VPC. Para obtener más información, consulte [Registro de su punto de conexión de VPC](#vpce-logging).
## Creación de un punto final de VPC para AWS criptografía de pagos
Puede crear un punto de conexión de VPC para la criptografía de AWS pagos mediante la consola de Amazon VPC o la API de Amazon VPC. Para obtener más información, consulte [Creación de un punto de conexión de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) en la *Guía de AWS PrivateLink *.
+ Para crear un punto final de VPC para la criptografía AWS de pagos, utilice los siguientes nombres de servicio:
```
com.amazonaws.region.payment-cryptography.controlplane
```
```
com.amazonaws.region.payment-cryptography.dataplane
```
Por ejemplo, en la región EE.UU. Oeste (Oregón) (`us-west-2`), los nombres de los servicios serían:
```
com.amazonaws.us-west-2.payment-cryptography.controlplane
```
```
com.amazonaws.us-west-2.payment-cryptography.dataplane
```
Para facilitar el uso del punto de conexión de VPC, puede habilitar un [nombre de DNS privado](https://docs.aws.amazon.com/vpc/latest/privatelink/verify-domains.html) para el punto de conexión de VPC. Si selecciona la opción **Habilitar nombre DNS, el nombre** de host DNS de criptografía de AWS pagos estándar se transfiere a su punto final de VPC. Por ejemplo, `https://controlplane.payment-cryptography.us-west-2.amazonaws.com` se resolvería en un punto de conexión de VPC conectado al nombre del servicio `com.amazonaws.us-west-2.payment-cryptography.controlplane`.
Esta opción facilita el uso del punto de conexión de VPC. De forma predeterminada, AWS CLI utilizan el nombre de host DNS de criptografía de AWS pagos estándar, por lo que no es necesario especificar la URL del punto de conexión de la VPC en las aplicaciones y los comandos. AWS SDKs
Para obtener más información, consulte [Acceso a un servicio a través de un punto de conexión de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#access-service-though-endpoint) en la *Guía de AWS PrivateLink *.
## Conexión a un punto final de AWS VPC de criptografía de pagos
Puede conectarse a la criptografía AWS de pagos a través del punto final de la VPC mediante AWS un SDK, AWS CLI el o. Herramientas de AWS para PowerShell Para especificar el punto de conexión de VPC, utilice su nombre de DNS.
Por ejemplo, este comando [list-keys](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/list-keys.html) utiliza el parámetro `endpoint-url` para especificar el punto de conexión de VPC. Para utilizar un comando de este tipo, sustituya el ID del punto de conexión de VPC del ejemplo por uno de su cuenta.
```
$ aws payment-cryptography list-keys --endpoint-url https://vpce-1234abcdf5678c90a-09p7654s-us-east-1a.ec2.us-east-1.vpce.amazonaws.com
```
Si ha habilitado los nombres de host privados al crear el punto de conexión de VPC, no es necesario que especifique la URL de este en los comandos de la CLI ni en la configuración de la aplicación. El nombre de host DNS AWS de criptografía de pagos estándar se resuelve en el punto final de la VPC. AWS CLI Y SDKs usa este nombre de host de forma predeterminada para que puedas empezar a usar el punto final de la VPC para conectarte a AWS un punto final regional de criptografía de pagos sin cambiar nada en tus scripts y aplicaciones.
Para utilizar nombres de host privados, se deben establecer los atributos `enableDnsHostnames` y `enableDnsSupport` de la VPC en `true`. Para configurar estos atributos, utilice la operación. [ModifyVpcAttribute](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpcAttribute.html) Para obtener más información, consulte [Ver y actualizar los atributos de DNS de su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) en la *Guía del usuario de Amazon VPC*.
## Control del acceso a un punto de conexión de VPC
Para controlar el acceso a su punto final de VPC para la criptografía de AWS pagos, adjunte una *política de punto final de VPC a su punto de enlace de VPC*. La política de puntos finales determina si los principales pueden usar el punto final de la VPC para AWS llamar a las operaciones de criptografía de pagos con recursos de criptografía de pagos AWS específicos.
Puede crear una política de punto de conexión de VPC cuando cree el punto de conexión y puede cambiar la política de punto de conexión de VPC en cualquier momento. Utilice la consola de administración de VPC o las operaciones [CreateVpcEndpoint](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpcEndpoint.html)o [ModifyVpcEndpoint](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpcEndpoint.html). También puede crear y cambiar una política de puntos finales de VPC [mediante una AWS CloudFormation plantilla](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpcendpoint.html). Para obtener ayuda sobre el uso de la consola de administración de la VPC, consulte [Creación de un punto de conexión de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#create-interface-endpoint) y [Modificación de un punto de conexión de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#modify-interface-endpoint) en la *Guía de AWS PrivateLink *.
Para obtener ayuda sobre cómo escribir y dar formato a un documento de política JSON, consulte la [Referencia de políticas JSON de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) en la *Guía del usuario de IAM*.
**Topics**
+ [Uso de políticas de punto de conexión de VPC](#vpce-policy-about)
+ [Política de puntos de conexión de VPC predeterminada](#vpce-default-policy)
+ [Creación de una política de punto de conexión de VPC](#vpce-policy-create)
+ [Visualización de una política de punto de conexión de VPC](#vpce-policy-get)
### Uso de políticas de punto de conexión de VPC
Para que una solicitud de criptografía de AWS pagos que utilice un punto final de VPC se realice correctamente, el director necesita permisos de dos fuentes:
+ Una [política basada en la identidad](security_iam_id-based-policy-examples.md) debe conceder al principal permiso para realizar la operación en el recurso (claves o alias de criptografía AWS de pagos).
+ Una política de extremo de VPC debe conceder a la entidad principal permiso para utilizar el punto de conexión para realizar la solicitud.
Por ejemplo, una política clave puede conceder a un director permiso para llamar a [Decrypt](https://docs.aws.amazon.com/payment-cryptography/latest/DataAPIReference/API_DecryptData.html) en una determinada AWS clave de criptografía de pago. Sin embargo, es posible que la política de puntos finales de la VPC no permita que el principal invoque `Decrypt` esas claves de criptografía de AWS pagos mediante el punto final.
O bien, una política de puntos finales de VPC podría permitir que un principal utilice el punto final para solicitar determinadas claves [StopKeyUsage](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/API_StopKeyUsage.html)de criptografía AWS de pagos. Sin embargo, si el principal no tiene esos permisos de una política de IAM, la solicitud no se realizará correctamente.
### Política de puntos de conexión de VPC predeterminada
Cada punto de conexión de VPC tiene una política de punto de conexión de VPC, pero no es necesario que especifique la política. Si no especifica una política, la política de punto de conexión predeterminada permite todas las operaciones de todas las entidades principales en todos los recursos del punto de conexión.
Sin embargo, en el caso de los recursos de criptografía de AWS pagos, el director también debe tener permiso para llamar a la operación desde una política de [IAM](security_iam_id-based-policy-examples.md). Por lo tanto, en la práctica, la política predeterminada dice que si una entidad principal tiene permiso para llamar a una operación en un recurso, también puede llamarla mediante el punto de conexión.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*"
}
]
}
```
Para permitir que las entidades principales utilicen el punto de conexión de VPC solo para un subconjunto de sus operaciones permitidas, [cree o modifique la política de puntos de conexión de VPC](#vpce-policy-create).
### Creación de una política de punto de conexión de VPC
Una política de punto de conexión de VPC determina si una entidad principal tiene permiso para utilizar el punto de conexión de VPC para realizar operaciones en un recurso. [En el AWS caso de los recursos de criptografía de pagos, el principal también debe tener permiso para realizar las operaciones en virtud de una política de IAM.](security_iam_id-based-policy-examples.md)
Cada declaración de política de puntos de conexión de VPC requiere los siguientes elementos:
+ La entidad principal que puede realizar acciones
+ Las acciones que se pueden realizar
+ Los recursos en los que se pueden llevar a cabo las acciones
La declaración de política no especifica el punto de conexión de VPC. En cambio, se aplica a cualquier punto de conexión de VPC al que esté asociada dicha política. Para obtener más información, consulte [Control del acceso a los servicios con puntos de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) en la *guía del usuario de Amazon VPC*.
El siguiente es un ejemplo de una política de punto final de VPC para criptografía de AWS pagos. Cuando se conecta a un punto final de la VPC, esta política permite usar el punto final de la VPC `ExampleUser` para llamar a las operaciones especificadas en las claves de criptografía de pago especificadas AWS . Antes de usar una política como esta, sustituya el [identificador principal y clave](concepts.md#concepts.key-identifer) del ejemplo por valores válidos de su cuenta.
```
{
"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 las operaciones que utilizan el punto final de la VPC. Sin embargo, tus CloudTrail registros no incluyen las operaciones solicitadas por los responsables de otras cuentas ni las operaciones relacionadas con las claves de criptografía de AWS pagos de otras cuentas.
Por lo tanto, es posible que desee crear una política de punto final de la VPC que impida que los directores de las cuentas externas utilicen el punto de enlace de la VPC para realizar cualquier operación de criptografía de AWS pagos en cualquier clave de la cuenta local.
En el siguiente ejemplo, se utiliza la clave de condición [aws: PrincipalAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalaccount) global para denegar el acceso a todos los principales para todas las operaciones con todas las claves de criptografía de AWS pagos, a menos que el principal esté en la cuenta local. Antes de utilizar una política como esta, sustituya el ID de la cuenta de ejemplo por uno válido.
```
{
"Statement": [
{
"Sid": "AccessForASpecificAccount",
"Principal": {"AWS": "*"},
"Action": "payment-cryptography:*",
"Effect": "Deny",
"Resource": "arn:aws:payment-cryptography:*:111122223333:key/*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "111122223333"
}
}
}
]
}
```
### Visualización de una política de punto de conexión de VPC
Para ver la política de puntos finales de la VPC de un punto final, utilice la [consola de administración de VPC](https://console.aws.amazon.com/vpc/) o la operación. [DescribeVpcEndpoints](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcEndpoints.html)
El siguiente AWS CLI comando obtiene la política del punto final con el ID de punto final de VPC especificado.
Antes de ejecutar este comando, reemplace el ID de punto de conexión de ejemplo por uno válido de su cuenta.
```
$ aws ec2 describe-vpc-endpoints \
--query 'VpcEndpoints[?VpcEndpointId==`vpce-1234abcdf5678c90a`].[PolicyDocument]'
--output text
```
## Utilizar un punto de conexión de VPC en una declaración de política
Puede controlar el acceso a los recursos y las operaciones de criptografía de AWS pagos cuando la solicitud proviene de la VPC o utiliza un punto final de la VPC. [Para ello, utilice una política de IAM](security_iam_id-based-policy-examples.md)
+ Utilice la clave de condición `aws:sourceVpce` para conceder o restringir el acceso en función del punto de conexión de VPC.
+ Utilice la clave de condición `aws:sourceVpc` para conceder o restringir el acceso en función de la VPC que aloja el punto de conexión privado.
**nota**
La clave de `aws:sourceIP` condición no entra en vigor cuando la solicitud proviene de un punto de conexión de [Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html). Para restringir las solicitudes a un punto de conexión de VPC, utilice las claves de condición `aws:sourceVpce` o `aws:sourceVpc`. Para obtener más información, consulte [Administración de identidades y accesos para puntos de conexión de VPC y servicios de puntos de conexión de VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-iam.html) en la *Guía de AWS PrivateLink *.
Puede utilizar estas claves de condición globales para controlar el acceso a las claves de criptografía de AWS pagos, a los alias y a operaciones de [CreateKey](https://docs.aws.amazon.com/payment-cryptography/latest/APIReference/API_CreateKey.html)este tipo que no dependen de ningún recurso en particular.
Por ejemplo, el siguiente ejemplo de política de claves permite a un usuario realizar determinadas operaciones criptográficas con claves de criptografía de AWS pago solo cuando la solicitud utiliza el punto final de VPC especificado, lo que bloquea el acceso tanto desde Internet como desde las AWS PrivateLink conexiones (si está configurado). Cuando un usuario realiza una solicitud a AWS Payment Cryptography, el ID del punto final de la VPC de la solicitud se compara con el valor de `aws:sourceVpce` la clave de condición de la política. Si no coinciden, la solicitud se deniega.
Para usar una política como esta, reemplaza el Cuenta de AWS ID del marcador de posición y el IDs punto de enlace de VPC por valores válidos para tu cuenta.
------
#### [ 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"
}
}
}
]
}
```
------
También puede usar la clave de `aws:sourceVpc` condición para restringir el acceso a sus claves de criptografía de AWS pagos en función de la VPC en la que reside el punto final de la VPC.
El siguiente ejemplo de política de claves permite que los comandos gestionen las claves de criptografía de AWS pagos solo cuando proceden de ellas. `vpc-12345678` Además, permite ejecutar comandos que utilicen las claves de criptografía de AWS pagos para operaciones criptográficas únicamente cuando procedan de. `vpc-2b2b2b2b` Podría utilizar una política como esta en caso de que una aplicación se ejecute en una VPC, pero utiliza una segunda VPC aislada para funciones de administración.
Para usar una política como esta, reemplaza el Cuenta de AWS ID del marcador de posición y el IDs punto de enlace de VPC por valores válidos para tu cuenta.
------
#### [ 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": "*"
}
]
}
```
------
## Registro de su punto de conexión de VPC
AWS CloudTrail registra todas las operaciones que utilizan el punto final de la VPC. Cuando una solicitud a AWS Payment Cryptography utiliza un punto de enlace de VPC, el ID del punto de enlace de VPC aparece en [AWS CloudTrail la entrada de registro que registra la](monitoring-cloudtrail.md) solicitud. Puede usar el ID del punto final para auditar el uso de su punto final de VPC de criptografía de AWS pagos.
Para proteger su VPC, no se registran las solicitudes denegadas por una [política de puntos finales de la VPC](#vpce-policy), pero que de otro modo se habrían permitido. [AWS CloudTrail](monitoring-cloudtrail.md)
Por ejemplo, esta entrada de log de ejemplo registra una solicitud [GenerateMac](https://docs.aws.amazon.com/payment-cryptography/latest/DataAPIReference/API_GenerateMac.html) que ha utilizado el punto de enlace de la VPC. El campo `vpcEndpointId` aparece al final de la 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 el cifrado TLS híbrido postcuántico
AWS La criptografía de pagos y muchos otros servicios admiten una opción híbrida de intercambio de claves poscuántico para el protocolo de cifrado de red Transport Layer Security (TLS). Puede usar esta opción de TLS cuando se conecte a los puntos de enlace de la API o cuando utilice AWS. SDKs Estas características opcionales de intercambio híbrido postcuántico de claves son al menos tan seguras como el cifrado TLS que utilizamos hoy en día y es muy probable que aporten beneficios de seguridad adicionales.
Los datos que envíe a los servicios habilitados están protegidos en tránsito mediante el cifrado que proporciona una conexión de Transport Layer Security (TLS). Los conjuntos de cifrado clásicos basados en RSA y ECC que AWS Payment Cryptography admite para las sesiones de TLS hacen que los ataques de fuerza bruta a los mecanismos de intercambio de claves no sean factibles con la tecnología actual. Sin embargo, si las computadoras cuánticas a gran escala o criptográficamente relevantes (CRQC) se vuelven prácticas en el futuro, los mecanismos de intercambio de claves TLS existentes serán susceptibles a estos ataques. Es posible que los adversarios comiencen a recolectar datos cifrados ahora con la esperanza de poder descifrarlos en el futuro (recolectarlos ahora, desencriptarlos más tarde). Si está desarrollando aplicaciones que se basan en la confidencialidad a largo plazo de los datos transmitidos a través de una conexión TLS, debería plantearse un plan para migrar a la criptografía poscuántica antes de que se puedan utilizar ordenadores cuánticos a gran escala. AWS está trabajando para prepararse para este futuro y queremos que usted también esté bien preparado.
![\[Un adversario que ha grabado previamente una sesión de TLS. Años más tarde, cuando el adversario tiene un CRQC, el adversario puede recuperar primero la clave de sesión interrumpiendo el intercambio de claves clásico mediante el CRQC. A continuación, el adversario puede descifrar los datos utilizando la clave de sesión descubierta. Los datos transmitidos anteriormente, si aún son valiosos, ahora están comprometidos.\]](http://docs.aws.amazon.com/es_es/payment-cryptography/latest/userguide/images/pqtls-risk2.png)
*Para proteger los datos cifrados hoy contra posibles ataques futuros, AWS participa con la comunidad criptográfica en el desarrollo de algoritmos cuánticos resistentes o poscuánticos.* AWS ha implementado conjuntos de cifrado *híbridos* de intercambio de claves poscuántico que combinan elementos clásicos y poscuánticos para garantizar que su conexión TLS sea al menos tan sólida como lo sería con los conjuntos de cifrado clásicos.
Estos conjuntos de cifrado híbridos están disponibles para su uso en sus cargas de trabajo de producción cuando utilice versiones recientes de AWS. SDKs Para obtener más información sobre cómo se produce enable/disable este comportamiento, consulte [Habilitar el TLS poscuántico híbrido](pqtls-details.md)
![\[Una sesión de TLS que se asegura mediante un acuerdo de clave clásico y un acuerdo de clave poscuántico. Hoy en día, un adversario no puede romper la parte clásica del acuerdo clave. Si el adversario graba los datos e intenta descifrarlos en el futuro con un CRQC, el acuerdo de clave poscuántica mantiene segura la clave de sesión. Por lo tanto, los datos transmitidos en la actualidad permanecen a salvo de ser descubiertos incluso en el futuro. Esta es la razón por la que el TLS poscuántico híbrido es importante en la actualidad.\]](http://docs.aws.amazon.com/es_es/payment-cryptography/latest/userguide/images/pqtls-mitigation.png)
## Acerca del intercambio de claves postcuántico híbrido en TLS
[Los algoritmos que AWS utiliza son *híbridos* y combinan la [curva elíptica Diffie-Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) (ECDH), un algoritmo clásico de intercambio de claves que se utiliza actualmente en el TLS, con el [mecanismo de encapsulación de claves basado en módulos (), un algoritmo de cifrado y establecimiento de claves públicas que el Instituto Nacional de Estándares y Tecnología (NISTML-KEM) ha designado como su primer algoritmo estándar de acuerdo de claves poscuántico](https://csrc.nist.gov/pubs/fips/203/final).](https://csrc.nist.gov/pubs/fips/203/final) Este híbrido utiliza cada uno de los algoritmos de forma independiente para generar una clave. Luego combina las dos claves criptográficamente.
## Obtenga más información sobre el PQC
Para obtener información sobre el proyecto de criptografía postcuántica del Instituto Nacional de Estándares y Tecnología (NIST), consulte [Post-Quantum Cryptography](https://csrc.nist.gov/Projects/Post-Quantum-Cryptography).
Para obtener información sobre la estandarización de la criptografía poscuántica del NIST, consulte [Estandarización de la criptografía poscuántica](https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization).
# Habilitar el TLS poscuántico híbrido
AWS SDKs y las herramientas tienen capacidades y configuraciones criptográficas que difieren según el idioma y el tiempo de ejecución. Actualmente, un SDK o una herramienta de AWS proporcionan compatibilidad con PQ TLS de tres maneras:
**Topics**
+ [SDKs con PQ TLS activado de forma predeterminada](#pq-tls-default)
+ [Compatibilidad opcional con PQ TLS](#pq-tls-opt-in)
+ [SDKs que se basan en el sistema OpenSSL](#pq-tls-open-ssl)
+ [AWS SDKs y las herramientas no tienen previsto admitir PQ TLS](#pq-tls-nosupport)
## SDKs con PQ TLS activado de forma predeterminada
**nota**
A partir del 6 de noviembre de 2025, el SDK de AWS y sus bibliotecas CRT subyacentes para macOS y Windows utilizan bibliotecas del sistema para TLS, por lo que las capacidades de PQ TLS en esas plataformas suelen estar determinadas por el soporte a nivel de sistema.
### AWS SDK para Go
El AWS SDK for Go utiliza la propia implementación de TLS de Golang proporcionada por su biblioteca estándar. Golang admite y prefiere PQ TLS a partir de la versión 1.24, por lo que los usuarios de AWS SDK for Go pueden habilitar PQ TLS simplemente actualizando Golang a la versión 1.24
### AWS SDK para JavaScript (navegador)
El SDK de AWS para JavaScript (navegador) usa la pila de TLS del navegador, por lo que el SDK negociará el TLS de PQ si el motor de ejecución del navegador lo admite y lo prefiere. Firefox lanzó la compatibilidad con PQ TLS en la versión 132.0. Chrome anunció la compatibilidad con PQ TLS en la versión 1.3.1. Edge admite el protocolo PQ TLS opcional en la versión 120 para ordenadores de sobremesa y en la versión 140 para Android.
### AWS SDK para Node.js
A partir de las versiones 22.20 (LTS) y 24.9.0 de Node.js, Node.js enlaza y agrupa OpenSSL 3.5 de forma estática. Esto significa que PQ TLS está activado y es el preferido de forma predeterminada para esas versiones y las posteriores.
### SDK de AWS para Kotlin
El SDK de Kotlin admite y prefiere PQ TLS en Linux a partir de la versión 1.5.78. Dado que el SDK de AWS para el cliente basado en CRT de Kotlin se basa en las bibliotecas del sistema para TLS en macOS y Windows, la compatibilidad con PQ TLS dependerá de las bibliotecas del sistema subyacentes.
### SDK de AWS para Rust
El SDK de AWS para Rust distribuye paquetes distintos (conocidos como «cajas» en el ecosistema de Rust) para cada cliente de servicio. Todos ellos se administran en un GitHub repositorio consolidado, pero cada cliente de servicio sigue su propia cadencia de versiones y lanzamientos. El SDK consolidado publicó la PQ TLS preferencial el 29 de agosto de 2025, por lo que cualquier versión de un cliente de servicio individual que se publique después de esa fecha admitirá y preferirá PQ TLS de forma predeterminada.
[Para determinar la versión mínima compatible con PQ TLS para un cliente de servicio concreto, dirígete a la URL de la versión de crates.io correspondiente (por ejemplo, aquí encontrarás la de AWS Payment Cryptography) y buscando la primera versión publicada después del 29 de agosto.](https://crates.io/crates/aws-sdk-paymentcryptography/versions) Cualquier versión de cliente de servicio publicada después del 29 de agosto tendrá el protocolo PQ TLS activado y será el preferido de forma predeterminada.
## Compatibilidad opcional con PQ TLS
### AWS SDK for C\$1\$1
De forma predeterminada, el SDK de C\$1\$1 usa clientes nativos de la plataforma, como libcurl y. WinHttp Libcurl generalmente se basa en el OpenSSL del sistema para TLS, por lo que el PQ TLS solo está habilitado de forma predeterminada si el OpenSSL del sistema es ≥ v3.5. Puedes anular esta configuración predeterminada en la versión 1.11.673 o posterior del SDK de C\$1\$1 y optar por la versión que admite y habilita el PQ TLS de forma predeterminada. AwsCrtHttpClient
[Notas sobre la creación de un protocolo PQ TLS opcional Con este script, puede recuperar las dependencias CRT del SDK.](https://github.com/aws/aws-sdk-cpp/blob/main/prefetch_crt_dependency.sh) La creación del SDK a partir del código fuente se describe [aquí y [aquí](https://github.com/aws/aws-sdk-cpp/tree/main?tab=readme-ov-file#building-from-source)](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/sdk-from-source.html), pero ten en cuenta que es posible que necesites algunos indicadores adicionales: CMake
```
-DUSE_CRT_HTTP_CLIENT=ON \
-DUSE_TLS_V1_2=OFF \
-DUSE_TLS_V1_3=ON \
-DUSE_OPENSSL=OFF \
```
### AWS SDK para Java
A partir de la versión 2, el AWS SDK for Java proporciona un cliente HTTP AWS Common Runtime (AWS CRT) que se puede configurar para ejecutar PQ TLS. A partir de la versión 2.35.11, AwsCrtHttpClient habilita y prefiere el PQ TLS de forma predeterminada dondequiera que se utilice.
## SDKs que se basan en el sistema OpenSSL
Varias herramientas SDKs y AWS dependen de la libcrypto/libssl biblioteca del sistema para TLS. La biblioteca del sistema más utilizada es OpenSSL. OpenSSL habilitó la compatibilidad con PQ TLS en la versión 3.5, por lo que la forma más sencilla de SDKs configurarlas y las herramientas para PQ TLS es usarla en una distribución de sistema operativo que tenga instalado al menos OpenSSL 3.5.
También puede configurar un contenedor Docker para que utilice OpenSSL 3.5 y habilite PQ TLS en cualquier sistema compatible con Docker. Consulte TLS poscuántico en Python para ver un ejemplo de cómo configurarlo para Python.
### CLI de AWS
La compatibilidad con PQ TLS con el [instalador de AWS CLI estará disponible](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) próximamente. Para habilitarlo inmediatamente, puede usar instaladores alternativos para la AWS CLI, que varía según el sistema operativo, y puede habilitar PQ TLS.
Para macOS, instale la AWS CLI a través de [Homebrew](https://brew.sh/) y asegúrese de que su OpenSSL vendido en Homebrew esté actualizado a la versión 3.5 o superior. Puede hacerlo con «brew install openssl @3 .6» y validarlo con «brew list \$1 grep openssl».
Para Ubuntu o Debian Linux: asegúrese de que la distribución de Linux que está utilizando tenga instalado OpenSSL 3.5\$1 como sistema OpenSSL. A continuación, instale la AWS CLI mediante apt o [PyPI](https://pypi.org/project/awscliv2/). Con estos requisitos previos, la AWS CLI vendida por apt o PyPI se configurará para negociar el PQ-TLS. [https://github.com/aws-samples/sample-post-quantum-tls-python/](https://github.com/aws-samples/sample-post-quantum-tls-python/)
### AWS SDK para PHP
El AWS SDK for PHP se basa en el sistema libssl/libcrypto. Para usar PQ TLS, use este SDK en una distribución de sistema operativo que tenga instalado al menos OpenSSL 3.5.
### AWS SDK para Python (Boto3)
El AWS SDK para Python (Boto3) se basa en el sistema libssl/libcrypto. Para usar PQ TLS, use este SDK en una distribución de sistema operativo que tenga instalado al menos OpenSSL 3.5.
### AWS SDK para Ruby
El AWS SDK for Ruby se basa en el sistema libssl/libcrypto. Para usar PQ TLS, use este SDK en una distribución de sistema operativo que tenga instalado al menos OpenSSL 3.5.
### AWS SDK para .NET
En Linux, AWS SDK for .NET se basa en el sistema libssl/libcrypto. Para usar PQ TLS, use este SDK en una distribución de sistema operativo que tenga instalado al menos OpenSSL 3.5. En Windows y macOS, PQ TLS está disponible a partir de [.NET 10](https://devblogs.microsoft.com/dotnet/post-quantum-cryptography-in-dotnet/) y [Windows](https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-apis-now-generally-available-on-microsoft-platforms/4469093) 11. [En macOS, la compatibilidad con TLS 1.3 (un requisito previo para PQ TLS) se puede habilitar al optar por Network.framework de Apple, como se describe aquí.](https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-10/libraries#tls-13-for-macos-client) Suponiendo que la versión de .NET sea 10 como mínimo, PQ TLS debería estar habilitado.
## AWS SDKs y las herramientas no tienen previsto admitir PQ TLS
Actualmente, no hay planes de admitir los siguientes lenguajes SDKs y herramientas:
+ SDK de AWS para SAP
+ SDK de AWS para Swift
+ Herramientas de AWS para Windows PowerShell
# Prácticas recomendadas de seguridad para la criptografía AWS de pagos
AWS La criptografía de pagos admite muchas funciones de seguridad integradas o que puede implementar de forma opcional para mejorar la protección de sus claves de cifrado y garantizar que se utilicen para los fines previstos, incluidas las políticas de [IAM, un amplio conjunto de claves condicionales de políticas](security_iam_service-with-iam.md) para refinar sus políticas de claves y políticas de IAM y la aplicación integrada de las normas PCI PIN en relación con los bloques de claves.
**importante**
Las directrices generales proporcionadas no representan una solución de seguridad completa. Dado que no todas las mejores prácticas son adecuadas para todas las situaciones, no se pretende que sean prescriptivas.
+ **Uso de claves y modos de uso**: La criptografía de AWS pagos sigue y aplica las restricciones de uso y uso de claves tal como se describe en la especificación de bloque de claves de intercambio seguro de claves interoperable ANSI X9 TR 31-2018 y de conformidad con el requisito de seguridad 18-3 del PIN PCI. Esto limita la capacidad de utilizar una sola clave para varios fines y vincula criptográficamente los metadatos de la clave (como las operaciones permitidas) al propio material de la clave. AWS La criptografía de pagos impone automáticamente estas restricciones, por ejemplo, no se puede utilizar una clave de cifrado clave (TR31\$1K0\$1KEY\$1ENCRYPTION\$1KEY) para descifrar datos. Consulte [Comprender los atributos clave de la clave AWS de criptografía de pagos](keys-validattributes.md) para obtener más detalles.
+ **Limitar el uso compartido de material de clave simétrica**: sólo comparta material de claves simétricas (como claves de cifrado de pines o claves de cifrado de claves) con un máximo de otra entidad. Si es necesario transferir material confidencial a más entidades o socios, cree claves adicionales. AWS La criptografía de pagos nunca expone el material de clave simétrica ni el material de clave privada asimétrica de forma transparente.
+ **Utilizar alias o etiquetas para asociar claves a determinados casos de uso o socios**: los alias pueden utilizarse para denotar fácilmente el caso de uso asociado a una clave, como alias/BIN\$112345\$1CVK para denotar una clave de verificación de tarjeta asociada a BIN 12345. Para ofrecer más flexibilidad, considere la posibilidad de crear etiquetas como bin=12345, use\$1case=acquiring,country=us,partner=foo. Los alias y las etiquetas también se pueden utilizar para limitar el acceso como, por ejemplo, para aplicar controles de acceso entre los casos de uso emisor y adquirente.
+ **Practicar el acceso con privilegio mínimo**: IAM puede utilizarse para limitar el acceso de producción a los sistemas en lugar de a los individuos, como prohibir a los usuarios individuales la creación de claves o la ejecución de operaciones criptográficas. IAM también puede utilizarse para limitar el acceso tanto a comandos como a claves que pueden no ser aplicables para su caso de uso, como limitar la capacidad de generar o validar pines para un adquirente. Otra forma de utilizar el acceso con privilegio mínimo es restringir las operaciones sensibles (como la importación de claves) a cuentas de servicio específicas. Para ver ejemplos, consulte [AWS Ejemplos de políticas de criptografía de pagos basadas en la identidad](security_iam_id-based-policy-examples.md).
**Véase también**
+ [Gestión de identidad y acceso para criptografía AWS de pagos](security-iam.md)
+ Consulte [Prácticas recomendadas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*.