# Protección de los datos en tránsito
Los *datos en tránsito* son todos aquellos que se transmiten de un sistema a otro. Incluye la comunicación entre recursos de la carga de trabajo, así como entre otros servicios y los usuarios finales. Con el nivel de protección adecuado para los datos en tránsito, protege la confidencialidad y la integridad de los datos de la carga de trabajo.
**Protección de los datos entre ubicaciones de VPC o en las instalaciones:** puede utilizar [AWS PrivateLink](https://aws.amazon.com/privatelink/)para crear una conexión de red segura y privada entre Amazon Virtual Private Cloud (Amazon VPC) o la conectividad en las instalaciones con los servicios alojados en AWS. Puede acceder a servicios de AWS, servicios de terceros y servicios de otras Cuentas de AWS como si estuvieran en su red privada. Con AWS PrivateLink, puede acceder a los servicios de todas las cuentas con CIDR de IP superpuestas sin necesidad de puertas de enlace de Internet o NAT. Tampoco es necesario configurar las reglas de firewall, las definiciones de rutas ni las tablas de enrutamiento. El tráfico permanece en la red troncal de Amazon y no atraviesa Internet, por lo que sus datos están protegidos. Puede mantener el cumplimiento de las normas de cumplimiento específicas del sector, como la HIPAA y el Privacy Shield de la UE/EE. UU. AWS PrivateLink funciona sin problemas con soluciones de terceros para crear una red global simplificada, lo que le permite acelerar su migración a la nube y aprovechar los servicios de AWS disponibles.
**Topics**
+ [SEC09-BP01 Implementación de la administración segura de claves y certificados](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 Aplicación del cifrado en tránsito](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 Autenticación de las comunicaciones de red](sec_protect_data_transit_authentication.md)
# SEC09-BP01 Implementación de la administración segura de claves y certificados
Los certificados de seguridad de la capa de transporte (TLS) se utilizan para proteger las comunicaciones de red y establecer la identidad de los sitios web, los recursos y las cargas de trabajo a través de Internet, así como de las redes privadas.
**Resultado deseado:** un sistema de administración de certificados seguro que puede aprovisionar, implementar, almacenar y renovar certificados en una infraestructura de clave pública (PKI). Un mecanismo seguro de administración de claves y certificados evita que se divulgue el material de claves privadas del certificado y renueva automáticamente el certificado de forma periódica. También se integra con otros servicios para proporcionar comunicaciones de red e identidad seguras para los recursos de la máquina dentro de su carga de trabajo. Las identidades humanas nunca deben tener acceso al material de claves.
**Patrones comunes de uso no recomendados:**
+ Seguir pasos manuales durante los procesos de implementación o renovación del certificado.
+ No prestar suficiente atención a la jerarquía de la autoridad de certificación (CA) al diseñar una CA privada.
+ Usar certificados autofirmados para recursos públicos.
**Beneficios de establecer esta práctica recomendada: **
+ Simplificar la administración de certificados mediante la implementación y la renovación automatizadas
+ Fomentar el cifrado de los datos en tránsito mediante certificados TLS
+ Aumentar la seguridad y auditabilidad de las medidas de certificación adoptadas por la autoridad de certificación
+ Organizar las tareas de administración en los diferentes capas de la jerarquía de CA
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Las cargas de trabajo modernas hacen un uso extensivo de las comunicaciones de red cifradas mediante protocolos PKI como TLS. La administración de certificados de PKI puede ser compleja, pero el aprovisionamiento, la implementación y la renovación automatizados de los certificados pueden reducir la fricción asociada con la administración de certificados.
AWS proporciona dos servicios para administrar los certificados de PKI de uso general: [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) y [AWS Private Certificate Authority (AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). ACM es el servicio principal que los clientes utilizan para aprovisionar, administrar e implementar certificados para su uso tanto en cargas de trabajo de AWS tanto públicas como privadas. ACM emite certificados privados mediante AWS Private CA y se [integra](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) con muchos otros servicios administrados de AWS para proporcionar certificados TLS seguros para las cargas de trabajo. ACM también puede emitir certificados de confianza pública de los [servicios de confianza de Amazon](https://www.amazontrust.com/repository/). Los certificados públicos de ACM se pueden usar en cargas de trabajo públicas, ya que los navegadores y sistemas operativos modernos confían en estos certificados de forma predeterminada.
AWS Private CA le permite establecer su propia autoridad de certificación raíz o subordinada y emitir certificados TLS a través de una API. Puede usar este tipo de certificados en situaciones en las que controla y administra la cadena de confianza en el lado del cliente de la conexión TLS. Además de los casos de uso de TLS, AWS Private CA se puede utilizar para emitir certificados para pods de Kubernetes, atestaciones de productos de dispositivos Matter, firma de código y otros casos de uso con una [plantilla personalizada](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html). También puede utilizar [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) para proporcionar credenciales temporales de IAM a las cargas de trabajo en las instalaciones a las que se les hayan emitido certificados X.509 firmados por su CA privada.
Además de ACM y AWS Private CA, [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html) proporciona soporte especializado para el aprovisionamiento, la administración y la implementación de certificados de PKI en dispositivos de IoT. AWS IoT Core proporciona mecanismos especializados para [incorporar dispositivos de IoT](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html) en su infraestructura de clave pública a escala.
Algunos servicios de AWS, como [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) y [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html), ofrecen sus propias capacidades de uso de certificados para proteger las conexiones de las aplicaciones. Por ejemplo, tanto API Gateway como Application Load Balancer (ALB) admiten el TLS mutuo (mTLS) mediante certificados de cliente que se crean y exportan mediante la Consola de administración de AWS, CLI o las API.
**Consideraciones para establecer una jerarquía de CA privada **
Si tiene que establecer una CA privada, es importante prestar especial atención para diseñar correctamente la jerarquía de CA desde el principio. Se recomienda implementar cada nivel de jerarquía de CA en Cuentas de AWS independientes al crear una jerarquía de CA privada. Este paso deliberado reduce el área de superficie de cada nivel de la jerarquía de CA, lo que facilita la detección de anomalías en los datos de registro de CloudTrail y reduce el alcance del acceso o el impacto si se produce un acceso no autorizado a una de las cuentas. La CA raíz debe residir en su propia cuenta independiente y solo debe usarse para emitir uno o más certificados de CA intermedios.
A continuación, cree una o más CA intermedias en cuentas independientes de la cuenta de la CA raíz para emitir certificados para los usuarios finales, los dispositivos u otras cargas de trabajo. Por último, emita certificados desde su CA raíz a las CA intermedias, que a su vez emitirán certificados para sus usuarios finales o dispositivos. Para obtener más información sobre la planificación de la implementación de la CA y el diseño de la jerarquía de las CA, incluida la planificación de la resiliencia, la replicación entre regiones, el uso compartido de las CA en toda la organización y mucho más, consulte [Planificación de la implementación de AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html).
### Pasos para la implementación
1. Determine los servicios de AWS pertinentes que necesita para su caso de uso:
+ Muchos casos de uso pueden utilizar la infraestructura de clave pública existente de AWS mediante [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html). ACM se puede usar para implementar certificados TLS para servidores web, equilibradores de carga u otros usos para certificados de confianza pública.
+ Considere [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) cuando necesite establecer su propia jerarquía de autoridades de certificación privadas o necesite acceder a certificados exportables. ACM se puede utilizar entonces para emitir [muchos tipos de certificados de entidad final](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html) mediante la AWS Private CA.
+ Para los casos de uso en los que los certificados se deben aprovisionar a escala para dispositivos de Internet de las cosas (IoT) integrados, considere [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html).
+ Puede utilizar la funcionalidad mTLS nativa en servicios como [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) o [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html).
1. Implemente la renovación automática de certificados siempre que sea posible:
+ Utilice la [renovación administrada de ACM](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) para los certificados emitidos por ACM junto con los servicios administrados de AWS integrados.
1. Establezca registros y registros de auditoría:
+ Habilite los [registros de CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html) para hacer un seguimiento del acceso a las cuentas que tienen autoridades de certificación. Considere configurar la validación de integridad del archivo de registro en CloudTrail para verificar la autenticidad de los datos de registro.
+ Genere y revise periódicamente [informes de auditoría](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html) que enumeren los certificados que su CA privada ha emitido o revocado. Estos informes se pueden exportar a un bucket de S3.
+ Al implementar una CA privada, también tendrá que establecer un bucket de S3 para almacenar la lista de revocación de certificados (CRL). Para obtener instrucciones sobre cómo configurar este bucket de S3 en función de los requisitos de su carga de trabajo, consulte [Planificación de una lista de revocación de certificados (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).
## Recursos
**Prácticas recomendadas relacionadas:**
+ [SEC02-BP02 Uso de credenciales temporales](sec_identities_unique.md)
+ [SEC08-BP01 Implementación de una administración de claves segura](sec_protect_data_rest_key_mgmt.md)
+ [SEC09-BP03 Autenticación de las comunicaciones de red](sec_protect_data_transit_authentication.md)
**Documentos relacionados:**
+ [How to host and manage an entire private certificate infrastructure in AWS](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/)
+ [How to secure an enterprise scale ACM Private CA hierarchy for automotive and manufacturing](https://aws.amazon.com/blogs/security/how-to-secure-an-enterprise-scale-acm-private-ca-hierarchy-for-automotive-and-manufacturing/)
+ [Private CA best practices](https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html)
+ [How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/)
**Videos relacionados:**
+ [Activating AWS Certificate Manager Private CA (workshop)](https://www.youtube.com/watch?v=XrrdyplT3PE)
**Ejemplos relacionados:**
+ [Private CA workshop](https://catalog.workshops.aws/certificatemanager/en-US/introduction)
+ [IOT Device Management Workshop](https://iot-device-management.workshop.aws/en/) (incluido el aprovisionamiento de dispositivos)
**Herramientas relacionadas:**
+ [Plugin to Kubernetes cert-manager to use AWS Private CA](https://github.com/cert-manager/aws-privateca-issuer)
# SEC09-BP02 Aplicación del cifrado en tránsito
Aplique los requisitos de cifrado definidos en función de las políticas, las obligaciones reglamentarias y las normas de su organización para ayudarle a cumplir los requisitos organizativos, legales y de cumplimiento. Utilice únicamente protocolos con cifrado cuando transmita datos confidenciales fuera de su nube privada virtual (VPC). El cifrado ayuda a mantener la confidencialidad de los datos incluso cuando transitan por redes que no son de confianza.
**Resultado deseado**: el tráfico de red entre sus recursos e Internet debe cifrarse para mitigar el acceso no autorizado a los datos. Cifra el tráfico de red en su entorno de AWS interno de acuerdo con sus requisitos de seguridad. Cifra todos los datos en tránsito mediante protocolos TLS seguros y conjuntos de cifrado.
**Patrones comunes de uso no recomendados:**
+ Utilizar versiones de SSL, TLS y componentes del conjunto de cifrado obsoletos (por ejemplo, SSL v3.0, claves RSA de 1024 bits y cifrado RC4).
+ Permitir tráfico no cifrado (HTTP) hacia o desde recursos destinados al público.
+ No supervisar y sustituir los certificados X.509 antes de que caduquen.
+ Utilizar certificados X.509 autofirmados para TLS.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Los servicios de AWS facilitan puntos de conexión HTTPS con TLS para la comunicación, lo que proporciona cifrado en tránsito al comunicarse con las API de AWS. Los protocolos no seguros, como HTTP, se pueden auditar y bloquear en una nube privada virtual (VPC) mediante el uso de grupos de seguridad. Las solicitudes HTTP también se pueden [redirigir automáticamente a HTTPS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) en Amazon CloudFront o en un [Equilibrador de carga de aplicación](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions). Puede utilizar una política de buckets de [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/blogs/storage/enforcing-encryption-in-transit-with-tls1-2-or-higher-with-amazon-s3/) para restringir la capacidad de cargar objetos a través de HTTP, lo que impone el uso de HTTPS para cargar objetos en sus buckets. Dispone de un control total sobre los recursos de computación para implementar el cifrado en tránsito en los servicios. También puede usar la conectividad de VPN en la VPC desde una red externa o [AWS Direct Connect](https://aws.amazon.com/directconnect/) para facilitar el cifrado de tráfico. Compruebe que sus clientes hagan llamadas a las API de AWS mediante al menos TLS 1.2, ya que [AWS va a dejar de utilizar versiones anteriores de TLS en febrero de 2024](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). Se recomienda utilizar TLS 1.3. Si tiene requisitos especiales para el cifrado en tránsito, puede encontrar soluciones de terceros disponibles en AWS Marketplace.
### Pasos para la implementación
+ **Aplicación del cifrado en tránsito:** los requisitos de cifrado definidos deben basarse en los últimos estándares y prácticas recomendadas, y solo permitir protocolos seguros. Por ejemplo, configure un grupo de seguridad para permitir solamente el protocolo HTTPS a una instancia del equilibrador de carga de aplicaciones o una instancia de Amazon EC2.
+ **Configuración de protocolos seguros en los servicios de periferia:** [configure HTTPS con Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html) y utilice un [perfil de seguridad apropiado para su posición de seguridad y su caso de uso](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers).
+ **Uso de una [VPN para la conectividad externa](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html):** considere la posibilidad de utilizar una VPN IPsec para proteger las conexiones de punto a punto o de red a red para ofrecer tanto privacidad como integridad de los datos.
+ **Configuración de protocolos seguros en los equilibradores de carga:** seleccione una política de seguridad que proporcione los conjuntos de cifrado más seguros que admitan los clientes que se conectarán al oyente. [Cree un oyente HTTPS para su equilibrador de carga de aplicación](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html).
+ **Configuración de protocolos seguros en Amazon Redshift:** configure su clúster para que requiera una [conexión de capa de sockets seguros (SSL) o de seguridad de la capa de transporte (TLS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html).
+ **Configuración de protocolos seguros:** revise la documentación del servicio de AWS para determinar las capacidades de cifrado en tránsito.
+ **Configuración del acceso seguro al cargar en los buckets de Amazon S3:** utilice los controles de políticas de buckets de Amazon S3 para [aplicar el acceso seguro](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) a los datos.
+ **Consideración de uso de [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/):** ACM le permite aprovisionar, administrar e implementar certificados TLS públicos para utilizarlos con los servicios de AWS.
+ **Consideración de uso de [AWS Private Certificate Authority](https://aws.amazon.com/private-ca/) para las necesidades de PKI privadas:** AWS Private CA le permite crear jerarquías de autoridades de certificación (CA) privadas para emitir certificados X.509 de entidad final que pueden utilizarse para crear canales TLS cifrados.
## Recursos
**Documentos relacionados:**
+ [ Uso de HTTPS con CloudFront ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)
+ [ Conectar la VPC a redes remotas mediante AWS Virtual Private Network](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ [ Create an HTTPS listener for your Application Load Balancer ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ [ Tutorial: Configure SSL/TLS on Amazon Linux 2 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html)
+ [ Uso de SSL/TLS para cifrar una conexión a una instancia o clúster de base de datos ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)
+ [ Configuración de las opciones de seguridad para las conexiones ](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)
# SEC09-BP03 Autenticación de las comunicaciones de red
Verifique la identidad de las comunicaciones mediante el uso de protocolos que admiten la autenticación, como la seguridad de la capa de transporte (TLS) o IPsec.
Diseñe su carga de trabajo para utilizar protocolos de red seguros y autenticados siempre que haya una comunicación entre servicios, aplicaciones o usuarios. El uso de protocolos de red que admiten autenticación y autorización proporciona un mayor control sobre los flujos de red y reduce la repercusión del acceso no autorizado.
**Resultado deseado:** una carga de trabajo con flujos de tráfico entre servicios bien definidos en el plano de datos y en el plano de control. Los flujos de tráfico utilizan protocolos de red autenticados y cifrados cuando es técnicamente posible.
**Patrones comunes de uso no recomendados:**
+ Tener tráfico no cifrado o no autenticado en la carga de trabajo.
+ Reutilizar credenciales de autenticación para varios usuarios o entidades.
+ Confiar únicamente en los controles de red como mecanismo de control de acceso.
+ Crear un mecanismo de autenticación personalizado en lugar de confiar en los mecanismos de autenticación estándar del sector.
+ Tener un tráfico excesivamente permisivo entre los componentes del servicio u otros recursos de la VPC.
**Beneficios de establecer esta práctica recomendada:**
+ Limita el alcance de la repercusión del acceso no autorizado a una parte de la carga de trabajo.
+ Proporciona un nivel de garantía mayor de que las acciones solo las llevan a cabo entidades autenticadas.
+ Mejora el desacoplamiento de los servicios al definir claramente las interfaces de transferencia de datos previstas y obligar a usarlas.
+ Mejora la supervisión, el registro y la respuesta a los incidentes mediante la atribución de solicitudes y unas interfaces de comunicación bien definidas.
+ Proporciona una defensa en profundidad para las cargas de trabajo al combinar los controles de red con los controles de autenticación y autorización.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** bajo
## Guía para la implementación
Los patrones de tráfico de red de la carga de trabajo se pueden clasificar en dos categorías:
+ El *tráfico este-oeste* representa los flujos de tráfico entre los servicios que constituyen una carga de trabajo.
+ El *tráfico norte-sur* representa los flujos de tráfico entre su carga de trabajo y los consumidores.
Aunque es una práctica común cifrar el tráfico norte-sur, es menos común proteger el tráfico este-oeste mediante protocolos autenticados. Las prácticas de seguridad modernas recomiendan que el diseño de red por sí solo no garantice una relación de confianza entre dos entidades. Cuando dos servicios pueden residir dentro de un límite de red común, sigue siendo una buena práctica recomendada cifrar, autenticar y autorizar las comunicaciones entre esos servicios.
Por ejemplo, las API del servicio de AWS utilizan el protocolo de firma [AWS Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) para autenticar a la persona que llama, independientemente de la red en la que se origine la solicitud. Esta autenticación garantiza que las API de AWS puedan verificar la identidad que solicitó la acción y, a continuación, esa identidad se pueda combinar con políticas para tomar una decisión de autorización que determine si la acción debe permitirse o no.
Servicios como [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) y [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) le permiten usar el mismo protocolo de firma SigV4 para incorporar autenticación y autorización al tráfico este-oeste en sus propias cargas de trabajo. Si los recursos fuera de su entorno de AWS necesitan comunicarse con servicios que requieren autenticación y autorización basadas en Sigv4, puede usar [AWS Identity and Access Management (IAM) Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) en el recurso que no es de AWS para adquirir credenciales de AWS temporales. Estas credenciales se pueden usar para firmar solicitudes de los servicios que utilizan SigV4 para autorizar el acceso.
Otro mecanismo común para autenticar el tráfico este-oeste es la autenticación mutua de TLS (mTLS). Muchas aplicaciones de internet de las cosas (IoT), aplicaciones de empresa a empresa y microservicios utilizan mTLS para validar la identidad de ambos lados de una comunicación TLS mediante el uso de certificados X.509 del lado del cliente y del lado del servidor. Estos certificados puede emitirlos AWS Private Certificate Authority (AWS Private CA). Puede utilizar servicios como [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) para proporcionar autenticación mTLS para la comunicación entre cargas de trabajo o dentro de ellas. El [Equilibrador de carga de aplicación también admite mTLS](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html) para cargas de trabajo internas o externas. Aunque mTLS proporciona información de autenticación para ambos lados de una comunicación TLS, no tiene un mecanismo de autorización.
Por último, OAuth 2.0 y OpenID Connect (OIDC) son dos protocolos que se suelen utilizar para controlar el acceso de los usuarios a los servicios, pero ahora también se están popularizando para el tráfico de servicio a servicio. API Gateway proporciona un [autorizador de token web JSON (JWT)](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html) que permite a las cargas de trabajo restringir el acceso a las rutas de la API mediante JWT emitidas por proveedores de identidad OIDC u OAuth 2.0. Los ámbitos OAuth2 pueden utilizarse como fuente para tomar las decisiones de autorización básicas, pero las comprobaciones de autorizaciones siguen teniendo que implementarse en la capa de aplicación, y los ámbitos OAuth2 por sí solos no pueden satisfacer necesidades de autorización más complejas.
### Pasos para la implementación
+ **Definición y documentación de los flujos de red de su carga de trabajo:** el primer paso para implementar una estrategia de defensa en profundidad es definir los flujos de tráfico de la carga de trabajo.
+ Cree un diagrama de flujo de datos en el que se defina claramente cómo se transmiten los datos entre los diferentes servicios que componen su carga de trabajo. Este diagrama es el primer paso para imponer esos flujos a través de canales de red autentificados.
+ Instrumente su carga de trabajo en las fases de desarrollo y prueba para validar que el diagrama de flujo de datos refleje con precisión el comportamiento de la carga de trabajo en tiempo de ejecución.
+ Un diagrama de flujo de datos también puede ser útil cuando se lleva a cabo un ejercicio de modelado de amenazas, como se describe en [SEC01-BP07 Identificación de amenazas y priorización de mitigaciones con un modelo de amenazas](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html).
+ **Establecimiento de controles de red:** considere la posibilidad de usar las capacidades de AWS para establecer controles de red que se ajusten a sus flujos de datos. Aunque los límites de la red no deberían ser el único control de seguridad, estos proporcionan una capa en la estrategia de defensa en profundidad para proteger su carga de trabajo.
+ Use [grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html) para establecer, definir y restringir los flujos de datos entre los recursos.
+ Considere la posibilidad de usar [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) para comunicarse con servicios de AWS y de terceros compatibles con AWS PrivateLink. Los datos que se envían a través de un punto de conexión de la interfaz de AWS PrivateLink permanecen en la estructura de red de AWS y no atraviesan la Internet pública.
+ **Implementación de autenticación y autorización en todos los servicios de su carga de trabajo:** elija el conjunto de servicios de AWS más adecuado para proporcionar flujos de tráfico autenticados y cifrados en su carga de trabajo.
+ Considere la posibilidad de usar [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) para proteger la comunicación de servicio a servicio. VPC Lattice puede usar la [autenticación SigV4 combinada con políticas de autenticación](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html) para controlar el acceso de un servicio a otro.
+ Para la comunicación de servicio a servicio mediante mTLS, puede usar [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) o [Equilibrador de carga de aplicación](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html). [AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) se puede usar para establecer una jerarquía de CA privada capaz de emitir certificados para su uso con los mTLS.
+ Al hacer la integración con servicios que utilizan OAuth 2.0 u OIDC, considere la posibilidad de usar [API Gateway con el autorizador JWT](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html).
+ Para la comunicación entre la carga de trabajo y los dispositivos de IoT, considere la posibilidad de usar [AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html), que ofrece varias opciones para el cifrado y la autenticación del tráfico de red.
+ **Supervisión del acceso no autorizado:** supervise continuamente los canales de comunicación no deseados, las entidades principales no autorizadas que intentan acceder a los recursos protegidos y otros patrones de acceso inadecuados.
+ Si utiliza VPC Lattice para administrar el acceso a sus servicios, piense en la posibilidad de habilitar y supervisar [registros de acceso de VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html). Estos registros de acceso incluyen información sobre la entidad solicitante, información de red, incluida la VPC de origen y destino, y los metadatos de la solicitud.
+ Considere la posibilidad de habilitar [registros de flujo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) para capturar los metadatos de los flujos de red y revisarlos periódicamente para detectar anomalías.
+ Consulte la [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) y la sección [Respuesta ante incidentes](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html) del pilar de seguridad del Marco de AWS Well-Architected para obtener más información sobre la planificación, la simulación y la respuesta a los incidentes de seguridad.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [ SEC03-BP07 Análisis del acceso público y entre cuentas ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [ SEC02-BP02 Uso de credenciales temporales ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [ SEC01-BP07 Identificación de amenazas y priorización de mitigaciones con un modelo de amenazas ](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)
**Documentos relacionados:**
+ [ Evaluating access control methods to secure Amazon API Gateway APIs ](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [ Configuring mutual TLS authentication for a REST API ](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [ How to secure API Gateway HTTP endpoints with JWT authorizer ](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [ Authorizing direct calls to AWS services using AWS IoT Core credential provider ](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [AWS Security Incident Response Guide ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**Videos relacionados:**
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)
**Ejemplos relacionados:**
+ [ Amazon VPC Lattice Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ Taller “Zero-Trust Episode 1 – The Phantom Service Perimeter” ](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)