Editor Top
|
|
Hoy anunciamos controles de cifrado de nube privada virtual (VPC), una nueva capacidad de Amazon Virtual Private Cloud (Amazon VPC) que le ayuda a auditar y aplicar el cifrado en tránsito para todo el tráfico dentro y entre las VPC en una región.
Las organizaciones de servicios financieros, atención médica, gobierno y comercio minorista enfrentan una complejidad operativa significativa para mantener el cumplimiento del cifrado en toda su infraestructura de nube. Los enfoques tradicionales requieren reunir múltiples soluciones y administrar una infraestructura de clave pública (PKI) compleja, mientras se realiza un seguimiento manual del cifrado en diferentes rutas de red utilizando hojas de cálculo, un proceso propenso a errores humanos que se vuelve cada vez más desafiante a medida que la infraestructura escala.
Aunque las instancias basadas en AWS Nitro cifran automáticamente el tráfico en la capa de hardware sin afectar el rendimiento, las organizaciones necesitan mecanismos simples para extender estas capacidades a toda su infraestructura de VPC. Esto es particularmente importante para demostrar el cumplimiento de marcos regulatorios como la Portabilidad y Responsabilidad del Seguro Médico (HIPAA), el Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) y el Programa Federal de Gestión de Autorizaciones y Riesgos (FedRAMP), que requieren prueba de cifrado de extremo a extremo en todos los entornos. Las organizaciones necesitan visibilidad y control centralizados sobre su estado de cifrado, sin tener que gestionar compensaciones de rendimiento ni complejos sistemas de gestión de claves.
Los controles de cifrado de VPC abordan estos desafíos proporcionando dos modos operativos: monitorear y hacer cumplir. En modo monitor, puede auditar el estado de cifrado de sus flujos de tráfico e identificar recursos que permiten el tráfico de texto sin formato. La función agrega un nuevo campo de estado de cifrado a los registros de flujo de VPC, lo que le brinda visibilidad sobre si el tráfico está cifrado mediante cifrado de hardware Nitro, cifrado de capa de aplicación (TLS) o ambos.
Una vez que haya identificado los recursos que necesitan modificación, puede tomar medidas para implementar el cifrado. Los servicios de AWS, como Network Load Balancer, Application Load Balancer y tareas de AWS Fargate, migrarán de forma automática y transparente su infraestructura subyacente al hardware Nitro sin necesidad de ninguna acción por su parte y sin interrupción del servicio. Para otros recursos, como la generación anterior de instancias de Amazon Elastic Compute Cloud (Amazon EC2), deberá cambiar a tipos de instancias modernos basados en Nitro o configurar el cifrado TLS a nivel de aplicación.
Puede cambiar al modo obligatorio después de que todos los recursos se hayan migrado a una infraestructura compatible con el cifrado. Esta migración a protocolos de comunicación y hardware compatibles con el cifrado es un requisito previo para habilitar el modo de aplicación. Puede configurar exclusiones específicas para recursos como puertas de enlace de Internet o puertas de enlace NAT, que no admiten cifrado (porque el tráfico fluye fuera de su VPC o de la red de AWS).
Otros recursos deben ser compatibles con el cifrado y no pueden excluirse. Después de la activación, el modo de aplicación permite que todos los recursos futuros solo se creen en instancias de Nitro compatibles y que el tráfico no cifrado se elimine cuando se detectan protocolos o puertos incorrectos.
Déjame mostrarte cómo empezar
Para esta demostración, inicié tres instancias EC2. Utilizo uno como servidor web con Nginx instalado en el puerto 80, que sirve una página HTML de texto sin formato. Los otros dos realizan continuamente solicitudes HTTP GET al servidor. Esto genera tráfico de texto claro en mi VPC. yo uso el m7g.medium tipo de instancia para el servidor web y uno de los dos clientes. Este tipo de instancia utiliza el hardware subyacente del Sistema Nitro para cifrar automáticamente el tráfico en tránsito entre instancias. yo uso un t4g.medium instancia para el otro cliente web. El tráfico de red de esa instancia no está cifrado a nivel de hardware.
Para comenzar, habilito los controles de cifrado en modo monitor. En la Consola de administración de AWS, selecciono Sus VPC en el panel de navegación izquierdo, luego cambio al Controles de cifrado de VPC pestaña. yo elijo Crear control de cifrado y seleccione la VPC para la que quiero crear el control.
Cada VPC puede tener solo un control de cifrado de VPC asociado, lo que crea una relación uno a uno entre el ID de VPC y el ID de control de cifrado de VPC. Al crear controles de cifrado de VPC, puede agregar etiquetas para ayudar con la organización y administración de recursos. También puede activar el control de cifrado de VPC cuando crea una nueva VPC.
entro en un Nombre para este control. selecciono el VPC Quiero controlar. Para las VPC existentes, tengo que comenzar en modo de monitorización, y puedo encender Modo de aplicación cuando estoy seguro de que no hay tráfico no cifrado. Para las VPC nuevas, puedo aplicar el cifrado en el momento de la creación.
Opcionalmente, puedo definir etiquetas al crear controles de cifrado para una VPC existente. Sin embargo, al habilitar los controles de cifrado durante la creación de la VPC, no se pueden crear etiquetas independientes para los controles de cifrado de la VPC, porque heredan automáticamente las mismas etiquetas que la VPC. Cuando estoy listo, elijo Crear control de cifrado.
Alternativamente, puedo utilizar la interfaz de línea de comandos de AWS (AWS CLI):
aws ec2 create-vpc-encryption-control --vpc-id vpc-123456789A continuación, audito el estado de cifrado de mi VPC mediante la consola, la línea de comandos o los registros de flujo:
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-123456789 \
--traffic-type ALL \
--log-destination-type s3 \
--log-destination arn:aws:s3:::vpc-flow-logs-012345678901/vpc-flow-logs/ \
--log-format '${flow-direction} ${traffic-path} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${encryption-status}'
{
"ClientToken": "F7xmLqTHgt9krTcFMBHrwHmAZHByyDXmA1J94PsxWiU=",
"FlowLogIds": [
"fl-0667848f2d19786ca"
],
"Unsuccessful": []
}Después de unos minutos, veo este tráfico en mis registros:
flow-direction traffic-path srcaddr dstaddr srcport dstport encryption-status
ingress - 10.0.133.8 10.0.128.55 43236 80 1 # <-- HTTP between web client and server. Encrypted at hardware-level
egress 1 10.0.128.55 10.0.133.8 80 43236 1
ingress - 10.0.133.8 10.0.128.55 36902 80 1
egress 1 10.0.128.55 10.0.133.8 80 36902 1
ingress - 10.0.130.104 10.0.128.55 55016 80 0 # <-- HTTP between web client and server. Not encrypted at hardware-level
egress 1 10.0.128.55 10.0.130.104 80 55016 0
ingress - 10.0.130.104 10.0.128.55 60276 80 0
egress 1 10.0.128.55 10.0.130.104 80 60276 010.0.128.55es el servidor web con tráfico cifrado por hardware, que sirve tráfico de texto claro a nivel de aplicación.10.0.133.8es el cliente web con tráfico cifrado por hardware.10.0.130.104es el cliente web sin cifrado a nivel de hardware.
El encryption-status El campo me indica el estado del cifrado del tráfico entre la dirección de origen y de destino:
- 0 significa que el tráfico está en texto claro
- 1 significa que el tráfico está cifrado en la capa de red (Nivel 3) por el sistema Nitro
- 2 significa que el tráfico está cifrado en la capa de aplicación (Nivel 7, Puerto TCP 443 y TLS/SSL)
- 3 significa que el tráfico está cifrado tanto en la capa de aplicación (TLS) como en la capa de red (Nitro)
- “-” significa que los controles de cifrado de VPC no están habilitados o que los registros de flujo de AWS no tienen la información de estado.
El tráfico que se origina desde el cliente web en la instancia que no está basada en Nitro (10.0.130.104), está marcado como 0. El tráfico iniciado desde el cliente web en la instancia Nitro-ased (10.0.133.8) está marcado como 1.
También uso la consola para identificar recursos que necesitan modificación. Informa dos recursos no cifrados: la puerta de enlace de Internet y la interfaz de red elástica (ENI) de la instancia que no está basada en Nitro.
También puedo comprobar si hay recursos no cifrados utilizando la CLI:
aws ec2 get-vpc-resources-blocking-encryption-enforcement --vpc-id vpc-123456789Después de actualizar mis recursos para admitir el cifrado, puedo usar la consola o la CLI para cambiar al modo obligatorio.
En la consola, selecciono el control de cifrado VPC. Luego selecciono Comportamiento y Modo de cambio.
O la CLI equivalente:
aws ec2 modify-vpc-encryption-control --vpc-id vpc-123456789 --mode enforce¿Cómo modificar los recursos que están identificados como no cifrados?
Todos sus recursos de VPC deben admitir el cifrado de tráfico, ya sea en la capa de hardware o en la capa de aplicación. Para la mayoría de los recursos, no es necesario realizar ninguna acción.
Los servicios de AWS a los que se accede a través de AWS PrivateLink y los puntos finales de puerta de enlace aplican automáticamente el cifrado en la capa de aplicación. Estos servicios sólo aceptan tráfico cifrado con TLS. AWS descartará automáticamente cualquier tráfico que no esté cifrado en la capa de aplicación.
Cuando habilita el modo de monitor, migramos automática y gradualmente sus balanceadores de carga de red, balanceadores de carga de aplicaciones, clústeres de AWS Fargate y clústeres de Amazon Elastic Kubernetes Service (Amazon EKS) a hardware que admite inherentemente el cifrado. Esta migración se produce de forma transparente y no requiere ninguna acción por su parte.
Algunos recursos de VPC requieren que seleccione las instancias subyacentes que admiten el cifrado de capa de hardware Nitro moderno. Estos incluyen instancias EC2, grupos de Auto Scaling, bases de datos de Amazon Relational Database Service (Amazon RDS) (incluido Amazon DocumentDB), clústeres basados en nodos de Amazon ElastiCache, clústeres aprovisionados de Amazon Redshift, clústeres de EKS, ECS con capacidad EC2, MSK Provisioned, Amazon OpenSearch Service y Amazon EMR. Para migrar sus clústeres de Redshift, debe crear un nuevo clúster o espacio de nombres a partir de una instantánea.
Si utiliza instancias de nueva generación, probablemente ya tenga una infraestructura compatible con el cifrado porque todos los tipos de instancias recientes admiten el cifrado. Para las instancias de generaciones anteriores que no admiten el cifrado en tránsito, deberá actualizar a tipos de instancias compatibles.
Algo que debe saber al utilizar AWS Transit Gateway
Al crear una Transit Gateway a través de AWS CloudFormation con el cifrado de VPC habilitado, necesita dos permisos adicionales de AWS Identity and Access Management (IAM): ec2:ModifyTransitGateway y ec2:ModifyTransitGatewayOptions. Estos permisos son necesarios porque CloudFormation utiliza un proceso de dos pasos para crear una puerta de enlace de tránsito. Primero crea Transit Gateway con la configuración básica, luego llama ModifyTransitGateway para habilitar el soporte de cifrado. Sin estos permisos, su pila de CloudFormation fallará durante la creación al intentar aplicar la configuración de cifrado, incluso si solo está realizando lo que parece ser una operación de creación.
Precios y disponibilidad
Puede comenzar a utilizar controles de cifrado de VPC hoy en estas regiones de AWS: EE. UU. Este (Ohio, Norte de Virginia), EE. UU. Oeste (Norte de California, Oregón), África (Ciudad del Cabo), Asia Pacífico (Hong Kong, Hyderabad, Yakarta, Melbourne, Mumbai, Osaka, Singapur, Sídney, Tokio), Canadá (Central), Canadá Oeste (Calgary), Europa (Frankfurt, Irlanda, Londres, Milán, París, Estocolmo, Zúrich), Medio Oriente (Bahréin, Emiratos Árabes Unidos) y América del Sur (São Paulo).
Los controles de cifrado de VPC son gratuitos hasta el 1 de marzo de 2026. La página de precios de VPC se actualizará con detalles a medida que nos acerquemos a esa fecha.
Para obtener más información, visite la documentación de controles de cifrado de VPC o pruébelo en su cuenta de AWS. Espero saber cómo utiliza esta función para fortalecer su postura de seguridad y ayudarlo a cumplir con los estándares de cumplimiento.
