

# Protección de la infraestructura
<a name="infrastructure-protection"></a>

La protección de la infraestructura abarca las metodologías de control, como la defensa en profundidad, necesarias para ajustarse a las prácticas recomendadas y las obligaciones organizativas o normativas. Usar estas metodologías es fundamental para operaciones continuas correctas en la nube. 

La protección de la infraestructura representa una parte clave de un programa de seguridad de la información. Garantiza que los sistemas y servicios de la carga de trabajo estén protegidos frente a accesos no intencionados ni autorizados y posibles vulnerabilidades. Por ejemplo, definirá los límites de confianza (como límites de red y cuenta), el mantenimiento y la configuración de seguridad del sistema (como la minimización, la protección y la implementación de revisiones), autorizaciones y autenticación del sistema operativo (como los usuarios, claves y niveles de acceso) y otros puntos adecuados del cumplimiento de la política (como los firewalls de aplicaciones web o puertas de enlace de API). 

 **Regiones, zonas de disponibilidad, zonas locales de AWS y AWS Outposts**

Asegúrese de estar familiarizado con las regiones, las zonas de disponibilidad, las [zonas locales de AWS](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) y [AWS Outposts](https://aws.amazon.com/outposts/), que son componentes de la infraestructura global segura de AWS.

AWS tiene el concepto de región, que es una ubicación física en todo el mundo donde agrupamos los centros de datos. Cada grupo de centros de datos lógicos se denomina zona de disponibilidad (AZ). Cada región de AWS se compone de múltiples zonas de disponibilidad aisladas y separadas físicamente dentro de un área geográfica. Si tiene requisitos de residencia de datos, puede elegir la región de AWS que esté cerca de la ubicación que desee. Usted retiene el control y la propiedad absolutos de la región donde se encuentran físicamente sus datos, lo que puede ser útil para el cumplimiento de los requisitos regionales de conformidad y residencia de datos. Cada zona de disponibilidad tiene alimentación, refrigeración y seguridad física independientes. Si una aplicación se particiona entre zonas de disponibilidad, tendrá un mejor aislamiento y protección frente a incidencias relacionadas con cortes de energía, rayos, tornados, terremotos, etc. Las zonas de disponibilidad están físicamente separadas por una distancia considerable, a muchos kilómetros de cualquier otra zona de disponibilidad, aunque todas se encuentran a unos 100 km (60 millas) la una de la otra. Todas las AZ de una región de AWS están interconectadas con ancho de banda alto y redes de baja latencia y utilizan fibra metropolitana dedicada y totalmente redundante, lo que ofrece una conexión de red de baja latencia y alto rendimiento entre las zonas de disponibilidad. Todo el tráfico entre las zonas de disponibilidad está cifrado. Los clientes de AWS que se centran en la alta disponibilidad pueden diseñar sus aplicaciones para que se ejecuten en varias zonas de disponibilidad a fin de lograr una tolerancia a los errores aún mayor. Las regiones de AWS cumplen con los niveles más altos de seguridad, cumplimiento y protección de datos.

 

Las Zonas locales de AWS acercan los servicios de computación, almacenamiento, base de datos y otros servicios de AWS exclusivos a los usuarios finales. Con las Zonas locales de AWS, puede ejecutar fácilmente aplicaciones muy exigentes que requieren latencias de milisegundos de un solo dígito para sus usuarios finales, como la creación de contenido multimedia y de entretenimiento, juegos en tiempo real, simulaciones de depósitos, automatización del diseño electrónico y machine learning. Cada ubicación de zona local de AWS es una extensión de una región de AWS en la que puede ejecutar sus aplicaciones sensibles a la latencia mediante servicios de AWS, como Amazon EC2, Amazon VPC, Amazon EBS, Amazon File Storage y Elastic Load Balancing, en proximidad geográfica con los usuarios finales. Las Zonas locales de AWS proporcionan una conexión segura y de gran ancho de banda entre las cargas de trabajo locales y las que se ejecutan en la región de AWS, lo que le permite conectarse sin interrupciones a la gama completa de servicios de la región a través de las mismas API y los mismos conjuntos de herramientas.

 

 AWS Outposts brinda servicios de AWS nativos, infraestructura y modelos operativos a prácticamente cualquier centro de datos, espacio de coubicación o instalación en las instalaciones. Puede usar las mismas API de AWS, herramientas e infraestructura en las instalaciones y en la nube de AWS para ofrecer una experiencia híbrida verdaderamente coherente. AWS Outposts está diseñado para entornos conectados y se puede usar para admitir cargas de trabajo que deben permanecer en las instalaciones debido a la baja latencia o a las necesidades de procesamiento de datos locales.

En AWS, existen varios enfoques para la protección de la infraestructura. En las siguientes secciones se describe cómo se usan estos enfoques. 

**Topics**
+ [Protección de redes](protecting-networks.md)
+ [Protección de la computación](protecting-compute.md)

# Protección de redes
<a name="protecting-networks"></a>

Los usuarios, tanto de sus empleados como de sus clientes, pueden estar ubicados en cualquier lugar. Debe dejar atrás los modelos tradicionales que confían en cualquier persona y en cualquier cosa que tenga acceso a la red. Cuando sigue el principio de aplicar la seguridad en todos los niveles, emplea un enfoque de [Confianza cero](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/). La seguridad de Confianza cero es un modelo en el que los componentes de la aplicación o los microservicios se consideran independientes entre sí y ningún componente o microservicio confía en ningún otro.

La planificación y administración minuciosas del diseño y la topología de red forma la base del modo de aislar y limitar los recursos en su carga de trabajo. Dado que muchos recursos de su carga de trabajo funcionan en una VPC y heredan las propiedades de seguridad, es fundamental que el diseño esté respaldado por mecanismos de inspección y protección respaldados por la automatización. Del mismo modo, para las cargas de trabajo que funcionan fuera de una VPC, que utilizan únicamente servicios periféricos o sin servidor, las prácticas recomendadas se aplican con un enfoque más simplificado. Consulte el documento [AWS Well-Architected Serverless Applications Lens](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html) para obtener orientación específica sobre la seguridad sin servidor. 

**Topics**
+ [SEC05-BP01 Creación de capas de red](sec_network_protection_create_layers.md)
+ [SEC05-BP02 Control del flujo de tráfico dentro de las capas de red](sec_network_protection_layered.md)
+ [SEC05-BP03 Implementación de una protección basada en la inspección](sec_network_protection_inspection.md)
+ [SEC05-BP04 Automatización de la protección de la red](sec_network_auto_protect.md)

# SEC05-BP01 Creación de capas de red
<a name="sec_network_protection_create_layers"></a>

 Segmente la topología de red en diferentes capas en función de las agrupaciones lógicas de los componentes de la carga de trabajo según sus requisitos de acceso y la confidencialidad de los datos. Distinga entre los componentes que requieren acceso entrante desde Internet, como los puntos de conexión web públicos, y aquellos que solo necesitan acceso interno, como las bases de datos. 

 **Resultado deseado:** incorporar las capas de su red en un enfoque de seguridad integral de defensa en profundidad que complemente la estrategia de autenticación y autorización de identidad de sus cargas de trabajo. Dispone de las capas de acuerdo con los requisitos de acceso y confidencialidad de los datos, con los mecanismos de control y flujo de tráfico adecuados. 

 **Patrones comunes de uso no recomendados:** 
+  Crea todos los recursos en una única VPC o subred. 
+  Desarrolla las capas de red sin tener en cuenta los requisitos de confidencialidad de los datos, el comportamiento de los componentes o la funcionalidad. 
+  Utiliza las VPC y las subredes de forma predeterminada para todas las consideraciones sobre las capas de red y no tener en cuenta la forma en que los servicios administrados de AWS influyen en la topología. 

 **Beneficios de establecer esta práctica recomendada:** establecer las capas de red es el primer paso para restringir las rutas innecesarias a través de la red, sobre todo las que conducen a sistemas y datos críticos. Esto dificulta que los actores no autorizados accedan a su red y a los recursos adicionales que contiene. Las capas de red diferenciadas reducen de forma ventajosa el alcance del análisis de los sistemas de inspección, como la detección de intrusos o la prevención del malware. Esto reduce la posibilidad de que se produzcan falsos positivos y disminuye la sobrecarga de procesamiento innecesaria. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Al diseñar una arquitectura de carga de trabajo, es habitual separar los componentes en diferentes capas en función de su responsabilidad. Por ejemplo, una aplicación web puede tener una capa de presentación, una capa de aplicación y una capa de datos. Es posible adoptar un enfoque similar al diseñar su topología de la red. Los controles de red subyacentes pueden ayudarle a hacer cumplir los requisitos de acceso a los datos de su carga de trabajo. Por ejemplo, en una arquitectura de aplicaciones web de tres niveles, puede almacenar los archivos de la capa de presentación estática en [Amazon S3](https://aws.amazon.com/s3/) y distribuirlos desde una red de entrega de contenido (CDN), como [Amazon CloudFront](https://aws.amazon.com/cloudfront/). La capa de aplicaciones puede tener puntos de conexión públicos a los que presta servicio un [equilibrador de carga de aplicación (ALB)](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) en una subred pública de [Amazon VPC](https://aws.amazon.com/vpc/) (similar a una zona desmilitarizada o DMZ), con servicios de backend implementados en subredes privadas. La capa de datos, en la que se alojan recursos como bases de datos y sistemas de archivos compartidos, puede encontrarse en subredes privadas diferentes de aquellas en las que están los recursos de la capa de aplicación. Puede implementar controles dentro de cada uno de estos límites de capa (CDN, subred pública, subred privada) para que solo los atraviese el tráfico autorizado. 

 Debe tener también en cuenta el nivel de confidencialidad de los datos que se vayan a procesar, de forma similar a cuando se modelan las capas de red en función del propósito funcional de los componentes de la carga de trabajo. Según el ejemplo de la aplicación web, si bien todos los servicios de carga de trabajo podrían encontrarse en la capa de aplicación, los distintos servicios podrían procesar datos con niveles de confidencialidad diferentes. En este caso, puede ser conveniente dividir la capa de aplicación con varias subredes privadas, distintas VPC en la misma Cuenta de AWS o incluso distintas VPC en Cuentas de AWS diferentes para cada nivel de confidencialidad de los datos, en función de los requisitos de control. 

 Otra cuestión que debe plantearse para las capas de red es la coherencia del comportamiento de los componentes de la carga de trabajo. En ese mismo ejemplo, es posible que en la capa de aplicación haya servicios que acepten entradas de usuarios finales o integraciones de sistemas externos que planteen intrínsecamente más riesgos que las entradas procedentes de otros servicios. Entre algunos ejemplos de esta situación podemos citar la carga de archivos, la ejecución de scripts de código, el análisis de correo electrónico, etc. Al ubicar estos servicios en su propia capa de red se contribuye a crear un límite de aislamiento más sólido en torno a ellos, y esto permite evitar que su comportamiento peculiar genere alertas por falsos positivos en los sistemas de inspección. 

 Como parte del diseño, tenga en cuenta cómo el uso de AWS Managed Services influye en la topología de la red. Descubra de qué manera servicios como [Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) pueden ayudar a facilitar la interoperabilidad de los componentes de la carga de trabajo entre las capas de la red. Al usar [AWS Lambda](https://aws.amazon.com/lambda/), implemente en sus subredes de VPC, a menos que existan motivos específicos para no hacerlo. Determine en qué casos pueden los puntos de conexión de VPC y [AWS PrivateLink](https://aws.amazon.com/privatelink/) simplificar el cumplimiento de las políticas de seguridad que limitan el acceso a las puertas de enlace de Internet. 

### Pasos para la implementación
<a name="implementation-steps"></a>

1.  Revise la arquitectura de su carga de trabajo. Agrupe de forma lógica los componentes y servicios según las funciones que cumplen, la confidencialidad de los datos que procesan y su comportamiento. 

1.  Para aquellos componentes que respondan a solicitudes de Internet, plantéese la posibilidad de usar equilibradores de carga u otros proxies para proporcionar puntos de conexión públicos. Valore la posibilidad de cambiar los controles de seguridad mediante el uso de servicios administrados, como CloudFront, [Amazon API Gateway](https://aws.amazon.com/api-gateway/), Elastic Load Balancing y [AWS Amplify](https://aws.amazon.com/amplify/) para alojar puntos de conexión públicos. 

1.  Para los componentes que se ejecutan en entornos de computación, como instancias de Amazon EC2, contenedores de [AWS Fargate](https://aws.amazon.com/fargate/) o funciones de Lambda, lleve a cabo la implementación en subredes privadas en función de sus grupos del primer paso. 

1.  Para los servicios de AWS totalmente administrados, como [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Kinesis](https://aws.amazon.com/kinesis/) o [Amazon SQS](https://aws.amazon.com/sqs/), considere la posibilidad de utilizar puntos de conexión de VPC como valores predeterminados para el acceso a través de direcciones IP privadas. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [REL02 Planificación de la topología de la red](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html) 
+  [PERF04-BP01 Comprensión del efecto de las redes en el rendimiento](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_networking_understand_how_networking_impacts_performance.html) 

 **Videos relacionados:** 
+  [AWS re:Invent 2023 - AWS networking foundations](https://www.youtube.com/watch?v=8nNurTFy-h4) 

 **Ejemplos relacionados:** 
+  [Ejemplos de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-examples-intro.html) 
+  [Acceder a las aplicaciones en contenedores de forma privada en Amazon ECS mediante AWS Fargate, un AWS PrivateLink y un equilibrador de carga de red](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html) 
+  [Serve static content in an Amazon S3 bucket through a VPC by using Amazon CloudFront](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html) 

# SEC05-BP02 Control del flujo de tráfico dentro de las capas de red
<a name="sec_network_protection_layered"></a>

 Dentro de las capas de su red, utilice una mayor segmentación para restringir el tráfico únicamente a los flujos necesarios para cada carga de trabajo. En primer lugar, céntrese en controlar el tráfico entre Internet u otros sistemas externos a una carga de trabajo y su entorno (tráfico *norte-sur*). A continuación, observe los flujos entre los diferentes componentes y sistemas (tráfico de *este a oeste*). 

 **Resultado deseado:** permite que solo los flujos de red necesarios para que los componentes de sus cargas de trabajo se comuniquen entre sí, con sus clientes y con cualquier otro servicio del que dependan. Tiene en cuenta en su diseño cuestiones como la entrada y salida públicas en comparación con las privadas, la clasificación de datos, las normativas regionales y los requisitos de protocolo. Siempre que sea posible, prefiere los flujos punto a punto en lugar de la interconexión de redes como parte del diseño con el *principio de privilegios mínimos*. 

 **Patrones comunes de uso no recomendados:** 
+  Adoptar un enfoque de seguridad de red basado en el perímetro y controlar solamente el flujo de tráfico dentro de los límites de las capas de red. 
+  Dar por sentado que todo el tráfico dentro de una capa de red está autenticado y autorizado. 
+  Aplicar controles para el tráfico de entrada o de salida, pero no para ambos. 
+  Confiar solo en los componentes de la carga de trabajo y los controles de red para autenticar y autorizar el tráfico. 

 **Beneficios de establecer esta práctica recomendada:** esta práctica ayuda a reducir el riesgo de movimientos no autorizados dentro de la red y agrega un nivel adicional de autorización a sus cargas de trabajo. Al controlar el flujo de tráfico, puede restringir el alcance del impacto de un incidente de seguridad y acelerar la detección y la respuesta. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Si bien las capas de red ayudan a establecer límites en torno a los componentes de la carga de trabajo similares en cuanto a función, nivel de confidencialidad de los datos y comportamiento, puede crear un nivel de control del tráfico mucho más detallado mediante el uso de técnicas para segmentar aún más los componentes de estas capas según el principio de privilegio mínimo. En AWS, las capas de red se definen principalmente mediante subredes según los rangos de direcciones IP dentro de una Amazon VPC. Las capas también se pueden definir mediante diferentes VPC, por ejemplo, para agrupar entornos de microservicios por dominio empresarial. Cuando use varias VPC, intervenga en el enrutamiento mediante una [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/). Si bien esto permite controlar el tráfico en el nivel de capa 4 (direcciones IP e intervalos de puertos) mediante grupos de seguridad y tablas de enrutamiento, puede obtener un mayor control mediante servicios adicionales como [AWS PrivateLink](https://aws.amazon.com/privatelink/), [Amazon Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html), [AWS Network Firewall](https://aws.amazon.com/network-firewall/) y [AWS WAF](https://aws.amazon.com/waf/). 

 Determine y haga un inventario de los requisitos de flujo de datos y comunicación de sus cargas de trabajo que incluya las entidades que inician la conexión, los puertos, los protocolos y las capas de red. Evalúe los protocolos disponibles para establecer conexiones y transmitir datos con el objetivo de seleccionar los que cumplan sus requisitos de protección (por ejemplo, HTTPS en lugar de HTTP). Capture estos requisitos tanto en los límites de sus redes como dentro de cada capa. Una vez identificados estos requisitos, explore las opciones para permitir solamente el tráfico requerido en cada punto de conexión. Un buen punto de partida es utilizar *grupos de seguridad* dentro de la VPC, ya que se pueden asociar a recursos que utilizan una interfaz de red elástica (ENI), como las instancias de Amazon EC2, las tareas de Amazon ECS, los pods de Amazon EKS o las bases de datos de Amazon RDS. A diferencia de un firewall de capa 4, un grupo de seguridad puede tener una regla que permita el tráfico de otro grupo de seguridad mediante su identificador, lo que reduce al mínimo las actualizaciones a medida que los recursos del grupo cambian con el tiempo. También puede filtrar el tráfico con reglas entrantes y salientes mediante grupos de seguridad. 

 Cuando el tráfico fluye entre las VPC, es habitual utilizar el emparejamiento de VPC para el enrutamiento sencillo o AWS Transit Gateway para el enrutamiento complejo. Con estos enfoques, se facilitan los flujos de tráfico entre el rango de direcciones IP de las redes de origen y destino. Sin embargo, si su carga de trabajo solo requiere flujos de tráfico entre componentes específicos de diferentes VPC, considere la posibilidad de utilizar una conexión punto a punto mediante [AWS PrivateLink](https://aws.amazon.com/privatelink/). Para ello, identifique qué servicio debe actuar como productor y cuál debe actuar como consumidor. Implemente un equilibrador de carga compatible para el productor, active PrivateLink en consecuencia y, a continuación, acepte una solicitud de conexión del consumidor. A continuación, se asignará al servicio del productor una dirección IP privada de la VPC del consumidor que el consumidor podrá usar para efectuar solicitudes posteriores. Este enfoque reduce la necesidad de emparejar las redes. Incluya los costos del procesamiento de datos y el equilibrio de carga como parte de la evaluación de PrivateLink. 

 Si bien los grupos de seguridad y PrivateLink ayudan a controlar el flujo entre los componentes de sus cargas de trabajo, otro aspecto importante que debe tener en cuenta es cómo controlar los dominios de DNS a los que pueden acceder sus recursos (si los hay). En función de la configuración de DHCP de sus VPC, puede optar por dos servicios de AWS para este fin. La mayoría de los clientes utilizan el servicio de DNS predeterminado de Route 53 Resolver (también denominado servidor DNS de Amazon o AmazonProvideDDNS) disponible para las VPC en la dirección \$12 de su rango de CIDR. Con este enfoque, puede crear reglas de firewall de DNS y asociarlas a su VPC para determinar qué acciones tomar para las listas de dominios que proporcione. 

 Si no usa el servicio Route 53 Resolver o si desea complementarlo con capacidades de inspección y control de flujo más profundas que vayan más allá del filtrado de dominios, considere la posibilidad de implementar un AWS Network Firewall. Este servicio inspecciona los paquetes individuales mediante reglas sin estado o con estado para determinar si se debe denegar o permitir el tráfico. Puede adoptar un enfoque similar para filtrar el tráfico web entrante a sus puntos de enlace públicos con AWS WAF. Para obtener más información sobre estos servicios, consulte [SEC05-BP03 Implementación de una protección basada en la inspección](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html). 

### Pasos para la implementación
<a name="implementation-steps"></a>

1.  Identifique los flujos de datos necesarios entre los componentes de sus cargas de trabajo. 

1.  Aplique múltiples controles con un enfoque de defensa en profundidad tanto para el tráfico entrante como para el saliente, incluido el uso de grupos de seguridad y tablas de enrutamiento.  

1.  Utilice firewalls para definir un control detallado del tráfico de red entrante, saliente y que pase por sus VPC, como el Firewall DNS de Route 53 Resolver, AWS Network Firewall y AWS WAF. Considere la posibilidad de usar [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) para configurar y administrar de forma centralizada las reglas de firewall en toda la organización. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [REL03-BP01 Elección de cómo segmentar su carga de trabajo](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_monolith_soa_microservice.html) 
+  [SEC09-BP02 Aplicación del cifrado en tránsito](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_data_transit_encrypt.html) 

 **Documentos relacionados:** 
+  [Prácticas recomendadas de seguridad de la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html) 
+  [AWS Network Optimization Tips](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/) 
+  [Guidance for Network Security on AWS](https://aws.amazon.com/solutions/guidance/network-security-on-aws/) 
+  [Secure your VPC's outbound network traffic in the Nube de AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-outbound-network-traffic/welcome.html) 

 **Herramientas relacionadas:** 
+  [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) 

 **Videos relacionados:** 
+  [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc) 
+  [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield](https://youtu.be/0xlwLEccRe0) 
+  [AWS re:Inforce 2023: Firewalls and where to put them](https://www.youtube.com/watch?v=lTJxWAiQrHM) 

# SEC05-BP03 Implementación de una protección basada en la inspección
<a name="sec_network_protection_inspection"></a>

 Configure puntos de inspección del tráfico entre las capas de la red para asegurarse de que los datos en tránsito coincidan con las categorías y los patrones esperados.  Analice los flujos de tráfico, los metadatos y los patrones para ayudar a identificar y detectar los eventos y responder a ellos de manera más eficaz. 

 **Resultado deseado:** se inspecciona y se autoriza el tráfico que atraviesa las capas de la red.  Basa las decisiones de permiso o denegación en reglas explícitas, información sobre amenazas y desviaciones de los comportamientos de referencia.  Las protecciones son más estrictas a medida que el tráfico se acerca a los datos confidenciales. 

 **Patrones comunes de uso no recomendados:** 
+  Confiar únicamente en las reglas de firewall basadas en puertos y protocolos. No aprovechar los sistemas inteligentes. 
+  Crear reglas de firewall sobre la base de patrones de amenazas actuales específicos sujetos a cambios. 
+  Inspeccionar únicamente el tráfico cuando fluye de subredes privadas a públicas, o de subredes públicas a Internet. 
+  No tener una visión básica del tráfico de la red para comparar las anomalías de comportamiento. 

 **Beneficios de establecer esta práctica recomendada:** los sistemas de inspección permiten crear reglas inteligentes, como permitir o denegar el tráfico únicamente cuando existan ciertas condiciones en los datos del tráfico. Beneficiarse de los conjuntos de reglas administradas de AWS y nuestros socios, sobre la base de la inteligencia de amenazas más reciente, a medida que el panorama de amenazas cambia con el tiempo.  Esto reduce los gastos administrativos que supone mantener las reglas e investigar los indicadores de situaciones de riesgo, lo que reduce la posibilidad de que se produzcan falsos positivos. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Controle minuciosamente el tráfico de red con y sin estado mediante AWS Network Firewall, otros [firewalls](https://aws.amazon.com/marketplace/search/results?searchTerms=firewalls) y otros [sistemas de prevención de intrusiones](https://aws.amazon.com/marketplace/search/results?searchTerms=Intrusion+Prevention+Systems) (IPS) en AWS Marketplace, que puede implementar detrás de un[ equilibrador de carga de puerta de enlace (GWLB)](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/). AWS Network Firewall es compatible con las especificaciones de IPS de código abierto [compatibles con Suricata](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html) para proteger su carga de trabajo. 

 Tanto AWS Network Firewall como las soluciones de otros proveedores que utilizan un GWLB admiten diferentes modelos de implementación de inspecciones en línea.  Por ejemplo, puede llevar a cabo la inspección en cada VPC, centralizarla en una VPC de inspección o implementarla en un modelo híbrido en el que el tráfico este-oeste fluya a través de una VPC de inspección y las entradas a Internet se inspeccionen en cada VPC.  Otra consideración es si la solución admite desempaquetar la seguridad de la capa de transporte (TLS), lo que permite una inspección profunda de los paquetes en busca de flujos de tráfico iniciados en cualquier dirección. Para obtener más información y detalles en profundidad sobre estas configuraciones, consulte la [guía AWS Network Firewall Best Practice](https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/). 

 Si utiliza soluciones que inspeccionan fuera de banda, como el análisis pcap de datos de paquetes de las interfaces de red que funcionan en modo promiscuo, puede configurar el [reflejo del tráfico de la VPC](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html). El tráfico reflejado se incluye en el ancho de banda disponible de sus interfaces y está sujeto a los mismos cargos por transferencia de datos que el tráfico no reflejado. Puede comprobar si hay versiones virtuales de estos dispositivos disponibles en [AWS Marketplace](https://aws.amazon.com/marketplace/solutions/infrastructure-software/cloud-networking), que podrían admitir la implementación en línea detrás de un GWLB. 

 En el caso de los componentes que llevan a cabo transacciones con protocolos basados en HTTP, proteja su aplicación ante las amenazas comunes con un firewall de aplicaciones web (WAF). [AWS WAF](https://aws.amazon.com/waf) es un firewall de aplicaciones web que le permite supervisar y bloquear las solicitudes HTTP(S) que coincidan con sus reglas configurables antes de enviarlas a Amazon API Gateway, Amazon CloudFront, AWS AppSync o un equilibrador de carga de aplicación. Piense en la posibilidad de llevar a cabo una inspección de paquetes en profundidad cuando evalúe la implementación del firewall de su aplicación web, ya que algunos requieren que finalice la seguridad de la capa de transporte (TLS) antes de la inspección del tráfico. Para empezar con AWS WAF, puede usar [Reglas administradas de AWS](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group) junto con sus propias [integraciones de socios](https://aws.amazon.com/waf/partners/) o utilizar las existentes. 

 Puede administrar de forma centralizada AWS WAF, AWS Shield Advanced, AWS Network Firewall y los grupos de seguridad de Amazon VPC en toda su organización de AWS con [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/).  

## Pasos para la implementación
<a name="implementation-steps"></a>

1.  Determine si puede aplicar las reglas de inspección de manera amplia (por ejemplo, mediante una VPC de inspección) o si necesita un enfoque más detallado por cada VPC. 

1.  Para soluciones de inspección en línea: 

   1.  Si utiliza AWS Network Firewall, cree reglas, políticas de firewall y el propio firewall. Una vez configurado esto, puede [redirigir el tráfico al punto de conexión del firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/) para facilitar la inspección.  

   1.  Si utiliza un dispositivo de terceros con un equilibrador de carga de puerta de enlace (GWLB), implemente y configure su dispositivo en una o más zonas de disponibilidad. A continuación, cree su GWLB, el servicio de punto de conexión y el punto de conexión, y configure el enrutamiento para su tráfico. 

1.  Para soluciones de inspección fuera de banda: 

   1.  Active el reflejo del tráfico de VPC en las interfaces en las que se deba reflejar el tráfico entrante y saliente. Puede usar reglas de Amazon EventBridge para invocar una función de AWS Lambda con el fin de activar el reflejo del tráfico en las interfaces cuando se creen nuevos recursos. Dirija las sesiones de reflejo del tráfico al equilibrador de carga de red situado frente al dispositivo que procese el tráfico. 

1.  Para soluciones de tráfico web entrante: 

   1.  Para configurar AWS WAF, comience por configurar una lista de control de acceso web (ACL web). La ACL web es una colección de reglas con una acción predeterminada procesada en serie (PERMITIR o DENEGAR) que define la forma en que gestiona el tráfico el WAF. Puede crear sus propias reglas y grupos o usar grupos de reglas administradas de AWS en su ACL web. 

   1.  Una vez configurada la ACL web, asocie la ACL web a un recurso de AWS (como un equilibrador de carga de aplicación, API Gateway, una API de REST o una distribución de CloudFront) para comenzar a proteger el tráfico web. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [What is Traffic Mirroring?](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) 
+  [Implementing inline traffic inspection using third-party security appliances](https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/welcome.html) 
+  [AWS Network Firewall example architectures with routing](https://docs.aws.amazon.com/network-firewall/latest/developerguide/architectures.html) 
+  [Centralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/) 

 **Ejemplos relacionados:** 
+  [Prácticas recomendadas para implementar el Equilibrador de carga de puerta de enlace](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) 
+  [TLS inspection configuration for encrypted egress traffic and AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-egress-traffic-and-aws-network-firewall/) 

 **Herramientas relacionadas:** 
+  [AWS Marketplace IDS/IPS](https://aws.amazon.com/marketplace/search/results?prevFilters=%257B%2522id%2522%3A%25220ed48363-5064-4d47-b41b-a53f7c937314%2522%257D&searchTerms=ids%2Fips) 

# SEC05-BP04 Automatización de la protección de la red
<a name="sec_network_auto_protect"></a>

 Automatice la implementación de las protecciones de su red mediante prácticas de DevOps, como la *infraestructura como código* (IaC) y las canalizaciones de CI/CD.  Estas prácticas pueden ayudarle a hacer un seguimiento de los cambios en las protecciones de la red a través de un sistema de control de versiones, a reducir el tiempo necesario para implementar los cambios y a detectar si las protecciones de la red se desvían de la configuración deseada.   

 **Resultado deseado:** defina las protecciones de red con plantillas y confirmarlas en un sistema de control de versiones.  Las canalizaciones automatizadas se inician cuando se hacen nuevos cambios que sirvan para organizar sus pruebas e implementación.  Dispone de comprobaciones de políticas y otras pruebas estáticas para validar los cambios antes de la implementación.  Implementa los cambios en un entorno provisional para validar que los controles funcionen según lo esperado.  También implementa en sus entornos de producción automáticamente una vez que se aprueben los controles. 

 **Patrones comunes de uso no recomendados:** 
+  Confiar en que los equipos de cada carga de trabajo definan individualmente toda su pila de red, sus protecciones y sus automatizaciones.  No publicar los aspectos estándares de la pila de red y las protecciones de forma centralizada para que los consuman los equipos de carga de trabajo. 
+  Confiar en un equipo de red central para definir todos los aspectos de la red, las protecciones y las automatizaciones.  No delegar los aspectos específicos de la carga de trabajo de la pila de red y las protecciones al equipo de esa carga de trabajo. 
+  Lograr el equilibrio adecuado entre la centralización y la delegación entre un equipo de red y los equipos de las cargas de trabajo, pero no aplicar estándares de prueba e implementación uniformes en todas las plantillas de IaC y las canalizaciones de CI/CD.  No recoger las configuraciones requeridas en herramientas que comprueben si las plantillas se ajustan a dichas configuraciones. 

 **Beneficios de establecer esta práctica recomendada:** el uso de plantillas para definir las protecciones de la red le permite hacer un seguimiento y comparar los cambios a lo largo del tiempo con un sistema de control de versiones.  El uso de la automatización para probar e implementar los cambios crea estandarización y previsibilidad, lo que aumenta las posibilidades de que la implementación tenga éxito y reduce las configuraciones manuales repetitivas. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio  

## Guía para la implementación
<a name="implementation-guidance"></a>

 Varios controles de protección de la red que se describen en [SEC05-BP02 Control del flujo de tráfico dentro de las capas de red](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_layered.html) y [SEC05-BP03 Implementación de una protección basada en la inspección](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html) incluyen sistemas de reglas administradas que pueden actualizarse automáticamente en función de la información sobre amenazas más reciente.  Entre los ejemplos de protección de los puntos de enlace web se incluyen las [reglas administradas de AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html) y la [mitigación de DDoS automática en la capa de aplicaciones de AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html). Utilice los [grupos de reglas administradas de AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/nwfw-managed-rule-groups.html) para mantenerse al día de las listas de dominios de baja reputación y las firmas de amenazas. 

 Más allá de las reglas administradas, le recomendamos que utilice prácticas de DevOps para automatizar la implementación de los recursos de red, las protecciones y las reglas que especifique.  Puede plasmar estas definiciones en [AWS CloudFormation](https://aws.amazon.com/cloudformation/) u otra herramienta de *infraestructura como código* (IaC) de su elección, confirmarlas en un sistema de control de versiones e implementarlas mediante canalizaciones de CI/CD.  Utilice este enfoque para obtener los beneficios tradicionales de DevOps para administrar los controles de red, como versiones más predecibles, pruebas automatizadas con herramientas como [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) y detección de desviaciones entre el entorno implementado y la configuración deseada. 

 En función de las decisiones que haya tomado como parte del proceso descrito en [SEC05-BP01 Creación de capas de red](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_create_layers.html), es posible que tenga un enfoque de administración centralizado para la creación de VPC dedicadas a los flujos de entrada, salida e inspección.  Tal y como se describe en [AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture), puede definir estas VPC en una [cuenta de infraestructura de red](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html) dedicada.  Puede utilizar técnicas similares para definir de forma centralizada las VPC que utilizan sus cargas de trabajo en otras cuentas, sus grupos de seguridad, las implementaciones de AWS Network Firewall, las reglas de Route 53 Resolver y las configuraciones de firewall DNS, además de otros recursos de red.  Puede compartir estos recursos con sus demás cuentas mediante [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html).  Con este enfoque, puede simplificar las pruebas automatizadas y la implementación de los controles de red en la cuenta de red, y solo tendrá un destino que administrar.  Puede hacerlo en un modelo híbrido, en el que implementa y comparte ciertos controles de forma centralizada y delega otros controles a los equipos de carga de trabajo individuales y a sus respectivas cuentas. 

## Pasos para la implementación
<a name="implementation-steps"></a>

1.  Determine qué aspectos de la red y qué protecciones se definen de forma centralizada y cuáles pueden mantener sus equipos de carga de trabajo. 

1.  Cree entornos para probar e implementar cambios en su red y sus protecciones.  Por ejemplo, utilice una cuenta de pruebas de red y una cuenta de producción de red. 

1.  Determine cómo va a almacenar y mantener las plantillas en un sistema de control de versiones.  Almacene las plantillas centrales en un repositorio distinto de los repositorios de carga de trabajo; las plantillas de carga de trabajo se pueden almacenar en repositorios específicos para esa carga de trabajo. 

1.  Cree canalizaciones de CI/CD para probar e implementar plantillas.  Defina pruebas para comprobar si hay errores de configuración y si las plantillas se ajustan a los estándares de su empresa. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [SEC01-BP06 Automatización de la implementación de controles de seguridad estándares](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls) 

 **Documentos relacionados:** 
+  [AWS Security Reference Architecture - Network account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html) 

 **Ejemplos relacionados:** 
+  [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/) 
+  [NetDevSecOps to modernize AWS networking deployments](https://aws.amazon.com/blogs/networking-and-content-delivery/netdevsecops-to-modernize-aws-networking-deployments/) 
+  [Integrating AWS CloudFormation security tests with AWS Security Hub CSPM and AWS CodeBuild reports](https://aws.amazon.com/blogs/security/integrating-aws-cloudformation-security-tests-with-aws-security-hub-and-aws-codebuild-reports/) 

 **Herramientas relacionadas:** 
+  [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 
+  [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) 
+  [cfn\$1nag](https://github.com/stelligent/cfn_nag) 

# Protección de la computación
<a name="protecting-compute"></a>

Los recursos de computación incluyen instancias EC2, contenedores, funciones de AWS Lambda, servicios de bases de datos, dispositivos del IoT y más. Cada uno de estos tipos de recursos de computación requiere enfoques diferentes para protegerlos. Sin embargo, comparten estrategias comunes que hay que tener en cuenta: una defensa exhaustiva, la administración de las vulnerabilidades, la reducción de la superficie expuesta a ataques, la automatización de la configuración y el funcionamiento y la ejecución de acciones a distancia. En esta sección, encontrará una guía general para proteger sus recursos de computación de los servicios clave. Para cada servicio de AWS utilizado, es importante que consulte las recomendaciones de seguridad específicas que figuran en la documentación del servicio.

**Topics**
+ [SEC06-BP01 Administración de las vulnerabilidades](sec_protect_compute_vulnerability_management.md)
+ [SEC06-BP02 Aprovisionamiento de computación a partir de imágenes reforzadas](sec_protect_compute_hardened_images.md)
+ [SEC06-BP03 Reducción de la administración manual y el acceso interactivo](sec_protect_compute_reduce_manual_management.md)
+ [SEC06-BP04 Validación de la integridad del software](sec_protect_compute_validate_software_integrity.md)
+ [SEC06-BP05 Automatización de la protección de computación](sec_protect_compute_auto_protection.md)

# SEC06-BP01 Administración de las vulnerabilidades
<a name="sec_protect_compute_vulnerability_management"></a>

Analice con frecuencia su código, sus dependencias y su infraestructura en busca de vulnerabilidades, y aplique parches para solucionarlas, para ayudarle a protegerse contra las nuevas amenazas.

 **Resultado deseado:** tiene una solución que analiza continuamente su carga de trabajo en busca de vulnerabilidades de software, posibles defectos y exposición no intencionada a la red. Ha establecido procesos y procedimientos para identificar, priorizar y corregir estas vulnerabilidades en función de los criterios de evaluación de riesgos. Además, ha implementado la administración automática de parches para sus instancias de computación. Su programa de gestión de vulnerabilidades está integrado en su ciclo de vida de desarrollo de software, con soluciones para escanear el código fuente durante la canalización de CI/CD. 

 **Patrones comunes de uso no recomendados:** 
+  No disponer de un programa de administración de vulnerabilidades. 
+  Aplicar parches en el sistema sin tener en cuenta la gravedad o la forma de evitar riesgos. 
+  Utilizar software que haya superado la fecha de fin de vida útil (EOL) de su proveedor. 
+  Implementar código en producción antes de analizarlo en busca de problemas de seguridad. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 La gestión de vulnerabilidades es un aspecto clave para mantener un entorno de nube seguro y sólido. Conlleva un proceso integral que incluye escaneos de seguridad, identificación y priorización de problemas y operaciones de parches para resolver las vulnerabilidades identificadas. La automatización desempeña un papel fundamental en este proceso, ya que facilita el análisis continuo de las cargas de trabajo para detectar posibles problemas y una exposición no intencionada a la red, así como las iniciativas de corrección. 

 El [modelo de responsabilidad compartida de AWS](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html) es un concepto fundamental que sustenta la gestión de vulnerabilidades. Según este modelo, AWS es responsable de proteger la infraestructura subyacente, incluido el equipo, el software, las redes y las instalaciones que ejecutan los servicios de AWS. Por el contrario, es su responsabilidad proteger sus datos, las configuraciones de seguridad y las tareas de administración asociadas a servicios como las instancias de Amazon EC2 y los objetos de Amazon S3. 

 AWS ofrece numerosos servicios para apoyar los programas de administración de vulnerabilidades. [Amazon Inspector](https://aws.amazon.com/inspector/) analiza continuamente las cargas de trabajo de AWS para detectar vulnerabilidades de software y accesos no deseados a la red, mientras que [AWSSystems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html) ayuda a administrar los parches en todas las instancias de Amazon EC2. Estos servicios se pueden integrar con [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/), un servicio de administración de la postura de seguridad en la nube que automatiza los controles de seguridad de AWS, centraliza las alertas de seguridad y proporciona una visión completa de la postura de seguridad de una organización. Además, [Amazon CodeGuru Security](https://aws.amazon.com/codeguru/) utiliza el análisis estático del código para identificar posibles problemas en las aplicaciones Java y Python durante la fase de desarrollo. 

 Al incorporar prácticas de gestión de vulnerabilidades en el ciclo de vida del desarrollo del software, puede abordar las vulnerabilidades de forma proactiva antes de que se introduzcan en los entornos de producción, lo que reduce el riesgo de eventos de seguridad y minimiza el posible impacto de las vulnerabilidades. 

### Pasos para la implementación
<a name="implementation-steps"></a>

1.  **Comprenda el modelo de responsabilidad compartida:** revise el modelo de responsabilidad compartida de AWS para comprender sus responsabilidades a la hora de proteger sus cargas de trabajo y los datos en la nube. AWS es responsable de proteger la infraestructura en la nube subyacente, mientras que es su responsabilidad proteger las aplicaciones, los datos y los servicios que utiliza. 

1.  **Implemente el análisis de vulnerabilidades**: configure un servicio de análisis de vulnerabilidades, como Amazon Inspector, para que analice automáticamente sus instancias de computación (por ejemplo, máquinas virtuales, contenedores o funciones sin servidor) en busca de vulnerabilidades de software, posibles defectos y exposición no intencionada a la red. 

1.  **Establezca procesos de gestión de vulnerabilidades:** defina procesos y procedimientos para identificar, priorizar y corregir las vulnerabilidades. Aquí se puede incluir la configuración de programas periódicos de escaneo de vulnerabilidades, el establecimiento de criterios de evaluación de riesgos y la definición de plazos de corrección en función de la gravedad de la vulnerabilidad. 

1.  **Configure la administración de parches:** utilice un servicio de administración de parches para automatizar el proceso de aplicación de parches a sus instancias de computación, tanto para los sistemas operativos como para las aplicaciones. Puede configurar el servicio para que analice las instancias en busca de parches ausentes e instalarlos automáticamente de manera planificada. Si lo considera oportuno, puede usar AWS Systems Manager Patch Manager para proporcionar esta funcionalidad. 

1.  **Configure la protección contra el malware:** implemente mecanismos para detectar software malicioso en su entorno. Por ejemplo, puede usar herramientas como [Amazon GuardDuty](https://aws.amazon.com/guardduty/) para analizar, detectar y alertar sobre el malware en los volúmenes de EC2 y EBS. GuardDuty también puede escanear los objetos recién cargados en Amazon S3 para detectar posibles virus o malware y tomar medidas para aislarlos antes de que se incorporen a los procesos posteriores. 

1.  **Integre el análisis de vulnerabilidades en las canalizaciones de CI/CD:** si utiliza una canalización de CI/CD para la implementación de sus aplicaciones, integre herramientas de análisis de vulnerabilidades en su canalización. Herramientas como Amazon CodeGuru Security y las opciones de código abierto pueden analizar el código fuente, las dependencias y los artefactos en busca de posibles problemas de seguridad. 

1.  **Configure un servicio de monitoreo de seguridad:** configure un servicio de monitoreo de seguridad, por ejemplo, AWS Security Hub CSPM, para obtener una perspectiva global del estado de su seguridad en varios servicios en la nube. El servicio debe recopilar los resultados de seguridad de diversas fuentes y presentarlos en un formato estandarizado para facilitar la priorización y la corrección. 

1.  **Implemente pruebas de penetración de aplicaciones web**: si su aplicación es una aplicación web y su organización tiene personal capacitado o puede contratar asistencia externa, podría implementar pruebas de penetración de aplicaciones web para identificar posibles vulnerabilidades en su aplicación. 

1.  **Automatice con la infraestructura como código**: utilice herramientas de infraestructura como código (IaC), por ejemplo [AWS CloudFormation](https://aws.amazon.com/cloudformation/), para automatizar la implementación y la configuración de sus recursos, incluidos los servicios de seguridad mencionados anteriormente. Esta práctica ayuda a crear una arquitectura de recursos más coherente y estandarizada en múltiples cuentas y entornos. 

1.  **Supervise y mejore continuamente**: supervise continuamente la eficacia de su programa de gestión de vulnerabilidades y realice las mejoras necesarias. Revise los resultados de seguridad, evalúe la eficacia de sus esfuerzos de corrección y ajuste sus procesos y herramientas en consecuencia. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 
+  [Security Overview of AWS Lambda](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf) 
+ [ Amazon CodeGuru ](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Improved, Automated Vulnerability Management for Cloud Workloads with a New Amazon Inspector ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)
+ [ Automate vulnerability management and remediation in AWS using Amazon Inspector and AWS Systems Manager – Part 1 ](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)

 **Videos relacionados:** 
+  [Securing Serverless and Container Services](https://youtu.be/kmSdyN9qiXY) 
+  [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI) 

# SEC06-BP02 Aprovisionamiento de computación a partir de imágenes reforzadas
<a name="sec_protect_compute_hardened_images"></a>

 Ofrezca menos oportunidades de acceso no deseado a sus entornos en tiempo de ejecución mediante la implementación desde imágenes reforzadas. Adquiera las dependencias de tiempo de ejecución (como imágenes de contenedores y bibliotecas de aplicaciones) únicamente de registros fiables y verifique sus firmas. Cree sus propios registros privados para almacenar imágenes y bibliotecas confiables para usarlas en sus procesos de desarrollo e implementación. 

 **Resultado deseado:** sus recursos informáticos se aprovisionan a partir de imágenes de referencia reforzadas. Recupera dependencias externas, como imágenes de contenedores y bibliotecas de aplicaciones, solamente de registros fiables y verifica sus firmas. Las almacena en registros privados para su consulta en los procesos de desarrollo e implementación. Escanea y actualiza las imágenes y las dependencias con regularidad para ayudar a protegerse contra cualquier vulnerabilidad recién descubierta. 

 **Patrones comunes de uso no recomendados:** 
+  Adquirir imágenes y bibliotecas de registros fiables, pero no verificar su firma ni analizar las vulnerabilidades antes de utilizarlas. 
+  Reforzar las imágenes, pero no probarlas con regularidad para detectar nuevas vulnerabilidades ni actualizarlas a la versión más reciente. 
+  Instalar o no eliminar paquetes de software que no sean necesarios durante el ciclo de vida esperado de la imagen. 
+  Confiar únicamente en los parches para mantener actualizados los recursos de computación de producción. El uso de parches por sí solo puede seguir haciendo que los recursos de computación diverjan del estándar reforzado con el paso del tiempo. También es posible que el uso de parches no elimine el malware que un actor de amenazas pueda haber instalado durante un evento de seguridad. 

 **Beneficios de establecer esta práctica recomendada:** el refuerzo de las imágenes ayuda a reducir la cantidad de rutas disponibles en el entorno de tiempo de ejecución que pueden permitir el acceso no deseado a usuarios o servicios no autorizados. También puede reducir el alcance del impacto en caso de que se produzca un acceso no deseado. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Para reforzar sus sistemas, comience con las versiones más recientes de los sistemas operativos, las imágenes de contenedores y las bibliotecas de aplicaciones. Aplique parches para solucionar los problemas conocidos. Reduzca al mínimo el sistema eliminando las aplicaciones, los servicios, los controladores de dispositivos, los usuarios predeterminados y otras credenciales que no sean necesarios. Lleve a cabo cualquier otra acción necesaria, como deshabilitar los puertos para crear un entorno que solo tenga los recursos y las capacidades que necesiten sus cargas de trabajo. A partir de ahí, puede instalar el software, los agentes u otros procesos que necesite para objetivos como la supervisión de la carga de trabajo o la administración de vulnerabilidades. 

 Puede reducir la carga que supone reforzar los sistemas utilizando la orientación que proporcionan orígenes fiables, como el [Center for Internet Security](https://www.cisecurity.org/) (CIS) y las [Security Technical Implementation Guides (STIG)](https://public.cyber.mil/stigs/) de la Defense Information Systems Agency (DISA). Le recomendamos que comience con una [imagen de máquina de Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (AMI) publicada por AWS o un socio de la APN y que utilice el [Generador de imágenes de AWS EC2](https://aws.amazon.com/image-builder/) para automatizar la configuración de acuerdo con una combinación adecuada de controles del CIS y las STIG. 

 Si bien existen imágenes reforzadas y recetas del Generador de imágenes de EC2 disponibles que aplican las recomendaciones del CIS o de las STIG de la DISA, es posible que su configuración impida que su software se ejecute correctamente. En esta situación, puede partir de una imagen de base no reforzada, instalar el software y, a continuación, aplicar los controles del CIS de forma gradual para comprobar su impacto. Para cualquier control del CIS que impida la ejecución del software, compruebe si puede implementar las recomendaciones de refuerzo más detalladas prescritas por la DISA. Lleve un registro de los diferentes controles del CIS y de las configuraciones especificadas en las STIG de la DISA que puede aplicar correctamente. Utilícelos para definir consecuentemente sus recetas de refuerzo de imágenes en el Generador de imágenes de EC2. 

 Para las cargas de trabajo en contenedores, hay imágenes reforzadas de Docker disponibles en el [repositorio público](https://aws.amazon.com/ecr/) de [Amazon Elastic Container Registry (ECR)](https://gallery.ecr.aws/docker). Puede usar el Generador de imágenes de EC2 para reforzar las imágenes de contenedor junto con las AMI. 

 Al igual que los sistemas operativos y las imágenes de contenedor, puede obtener paquetes de código (o *bibliotecas*) de repositorios públicos mediante herramientas como pip, npm, Maven y NuGet. Le recomendamos que administre los paquetes de código mediante la integración de repositorios privados, como los que hay en [AWS CodeArtifact](https://aws.amazon.com/codeartifact/), con repositorios públicos de confianza. Esta integración puede ocuparse de la recuperación, el almacenamiento y la actualización de los paquetes. Durante los procesos de desarrollo de aplicaciones, se puede obtener y probar la versión más reciente de estos paquetes junto con la aplicación, mediante técnicas como el análisis de composición de software (SCA), las pruebas de seguridad de aplicaciones estáticas (SAST) y las pruebas dinámicas de seguridad de aplicaciones (DAST). 

 Para las cargas de trabajo sin servidor que utilicen AWS Lambda, simplifique la administración de las dependencias de los paquetes mediante [capas de Lambda.](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) Use las capas de Lambda para configurar un conjunto de dependencias estándares que se compartan entre diferentes funciones en un archivo independiente. Puede crear y mantener capas según su propio proceso de creación, que proporciona un método centralizado de mantener al día sus funciones. 

## Pasos para la implementación
<a name="implementation-steps"></a>
+  Refuerce los sistemas operativos. Utilice imágenes de base de orígenes fiables para crear sus AMI reforzadas. Use el [Generador de imágenes de EC2](https://aws.amazon.com/image-builder/) para ayudar a personalizar el software instalado en las imágenes. 
+  Refuerce los recursos en contenedores. Configure los recursos en contenedores para cumplir con las prácticas recomendadas de seguridad. Cuando utilice contenedores, implemente el [análisis de imágenes de ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) en su canalización de compilación y aplíquelo de forma frecuente a su repositorio de imágenes para buscar CVE en sus contenedores.  
+  Cuando utilice la implementación sin servidor con AWS Lambda, utilice [capas de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) para dividir el código de función de la aplicación y las bibliotecas dependientes compartidas. Configure la [firma de código](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html) para Lambda para asegurarse de que solo se ejecute código fiable en sus funciones de Lambda. 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [OPS05-BP05 Administración de parches](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_patch_mgmt.html) 

 **Videos relacionados:** 
+  [Deep dive into AWS Lambda security](https://www.youtube.com/watch?v=FTwsMYXWGB0) 

 **Ejemplos relacionados:** 
+  [Quickly build STIG-compliant AMI using EC2 Image Builder](https://aws.amazon.com/blogs/security/quickly-build-stig-compliant-amazon-machine-images-using-amazon-ec2-image-builder/) 
+  [Building better container images](https://aws.amazon.com/blogs/containers/building-better-container-images/) 
+  [Using Lambda layers to simplify your development process](https://aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/) 
+  [Develop & Deploy AWS Lambda Layers using Serverless Framework](https://github.com/aws-samples/aws-serverless-lambda-layers) 
+  [Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST and DAST tools](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/) 

# SEC06-BP03 Reducción de la administración manual y el acceso interactivo
<a name="sec_protect_compute_reduce_manual_management"></a>

 Utilice la automatización para hacer tareas de implementación, configuración, mantenimiento e investigación siempre que sea posible. Plantéese el acceso manual a los recursos de computación en casos de procedimientos de emergencia o en entornos seguros (entornos de pruebas) cuando la automatización no esté disponible. 

 **Resultado deseado:** los scripts programáticos y los documentos de automatización (manuales de procedimientos) capturan las acciones autorizadas en sus recursos de computación. Estos manuales de procedimientos se inician de forma automática, mediante sistemas de detección de cambios, o manualmente, cuando se requiere una intervención humana. El acceso directo a los recursos de computación solo está disponible en situaciones de emergencia cuando la automatización no está disponible. Todas las actividades manuales se registran y se incorporan a un proceso de revisión para mejorar continuamente las capacidades de automatización. 

 **Patrones comunes de uso no recomendados:** 
+  Acceso interactivo a instancias de Amazon EC2 con protocolos como SSH o RDP. 
+  Mantener inicios de sesión de los usuarios individuales, como `/etc/passwd` o los usuarios locales de Windows. 
+  Compartir una contraseña o una clave privada para acceder a una instancia entre varios usuarios. 
+  Instalar el software y crear o actualizar los archivos de configuración manualmente. 
+  Actualizar o parchear el software manualmente. 
+  Iniciar sesión en una instancia para solucionar problemas. 

 **Beneficios de establecer esta práctica recomendada:** utilizar la automatización para llevar a cabo acciones le ayuda a reducir el riesgo operativo de los cambios no deseados y los errores de configuración. Eliminar el uso de Secure Shell (SSH) y Remote Desktop Protocol (RDP) para el acceso interactivo reduce el alcance del acceso a los recursos de computación. Todo esto elimina una ruta que se utiliza habitualmente para llevar a cabo acciones no autorizadas. Al reflejar las tareas de administración de recursos de computación en documentos de automatización y scripts programáticos, se proporciona un mecanismo para definir y auditar todo el alcance de las actividades autorizadas con un alto nivel de detalle. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Iniciar sesión en una instancia es un enfoque clásico de la administración del sistema. Tras instalar el sistema operativo del servidor, los usuarios suelen iniciar sesión manualmente para configurar el sistema e instalar el software deseado. A lo largo de la vida útil del servidor, los usuarios pueden iniciar sesión para llevar a cabo actualizaciones de software, aplicar parches, cambiar configuraciones y solucionar problemas. 

 Sin embargo, el acceso manual plantea una serie de riesgos. Requiere un servidor que escuche las solicitudes, como un servicio SSH o RDP, que pueden proporcionar una ruta potencial para el acceso no autorizado. También aumenta el riesgo de errores humanos asociados con los pasos manuales. Todo esto puede provocar incidentes relacionados con la carga de trabajo, corrupción o destrucción de datos u otros problemas de seguridad. El acceso humano también requiere protecciones contra el uso compartido de credenciales, lo que genera una sobrecarga de administración adicional.  

 Para mitigar estos riesgos, puede implementar una solución de acceso remoto basada en agentes, como [AWS Systems Manager](https://aws.amazon.com/systems-manager/). AWS Systems Manager El agente (SSM Agent) inicia un canal cifrado y, por lo tanto, no depende de la escucha de solicitudes iniciadas externamente. Tenga en cuenta la posibilidad de configurar el SSM Agent para [establecer este canal en un punto de conexión de VPC](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html). 

 Systems Manager le aporta un control detallado sobre cómo puede interactuar con las instancias administradas. Es el cliente quien define las automatizaciones que se ejecutarán, quién puede ejecutarlas y cuándo pueden ejecutarse. Systems Manager puede aplicar parches, instalar software y hacer cambios en la configuración sin acceso interactivo a la instancia. Systems Manager también puede proporcionar acceso a un intérprete de comandos remoto y registrar todos los comandos invocados y sus resultados durante la sesión en registros y en [Amazon S3](https://aws.amazon.com/s3/). [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) registra las invocaciones de las API de Systems Manager para su inspección. 

### Pasos para la implementación
<a name="implementation-steps"></a>

1.  [Instale el AWS Systems Manager Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) (SSM Agent) en sus instancias de Amazon EC2. Compruebe si el SSM Agent está incluido y se ha iniciado automáticamente como parte de la configuración básica de la AMI. 

1.  Compruebe que los roles de IAM asociados a sus perfiles de instancia de EC2 incluyan la [política de IAM administrada](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html) `AmazonSSMManagedInstanceCore`. 

1.  Inhabilite SSH, RDP y otros servicios de acceso remoto que se ejecuten en sus instancias. Para hacerlo, puede ejecutar scripts configurados en la sección de datos de usuario de sus plantillas de lanzamiento o crear AMI personalizadas con herramientas como el Generador de imágenes de EC2. 

1.  Compruebe que las reglas de ingreso de grupos de seguridad aplicables a sus instancias de EC2 no permitan el acceso al puerto 22/tcp (SSH) o al puerto 3389/tcp (RDP). Implemente la detección y las alertas en grupos de seguridad mal configurados mediante servicios como AWS Config. 

1.  Defina las automatizaciones, los manuales de procedimientos y los comandos de ejecución adecuados en Systems Manager. Utilice políticas de IAM para definir quién puede llevar a cabo estas acciones y las condiciones en las que están permitidas. Pruebe estas automatizaciones minuciosamente en un entorno que no sea de producción. Invoque estas automatizaciones cuando sea necesario, en lugar de acceder a la instancia de forma interactiva. 

1.  Use [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) para proporcionar acceso interactivo a las instancias cuando sea necesario. Active el registro de actividad de la sesión para mantener un registro de auditoría en [Registros de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) o [Amazon S3](https://aws.amazon.com/s3/).  

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [REL08-BP04 Implementación mediante una infraestructura inmutable](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_immutable_infrastructure.html) 

 **Ejemplos relacionados:** 
+  [Replacing SSH access to reduce management and security overhead with AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/) 

 **Herramientas relacionadas:** 
+  [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 

 **Videos relacionados:** 
+  [Controlling User Session Access to Instances in AWS Systems Manager Session Manager](https://www.youtube.com/watch?v=nzjTIjFLiow) 

# SEC06-BP04 Validación de la integridad del software
<a name="sec_protect_compute_validate_software_integrity"></a>

 Utilice la verificación criptográfica para validar la integridad de los artefactos de software (incluidas las imágenes) que utiliza su carga de trabajo.  Firme criptográficamente su software como protección contra los cambios no autorizados que se ejecuten en sus entornos de computación. 

 **Resultado deseado:** todos los artefactos se obtienen de orígenes confiables. Se validan los certificados del sitio web del proveedor.  Los artefactos descargados se verifican criptográficamente mediante sus firmas. Sus entornos de computación firman y verifican criptográficamente su propio software. 

 **Patrones comunes de uso no recomendados:** 
+  Confiar en los sitios web de proveedores acreditados para obtener artefactos de software, pero ignorar los avisos de caducidad de los certificados.  Continuar con las descargas sin confirmar que los certificados son válidos. 
+  Validar los certificados de los sitios web de los proveedores, pero no verificar criptográficamente los artefactos descargados de estos sitios web. 
+  Confiar únicamente en resúmenes o hashes para validar la integridad del software.  Los hashes establecen que los artefactos no se han modificado con respecto a la versión original, pero no validan su fuente. 
+  No firmar su propio software, código o bibliotecas, aunque solo los utilice en sus propias implementaciones.  

 **Beneficios de establecer esta práctica recomendada:** la validación de la integridad de los artefactos de los que depende su carga de trabajo ayuda a evitar que el malware acceda a sus entornos de computación.  La firma de su software ayuda a protegerse contra la ejecución no autorizada en sus entornos informáticos.   Proteja su cadena de suministro de software mediante la firma y verificación del código. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Las imágenes del sistema operativo, las imágenes de contenedores y los artefactos de código suelen distribuirse con comprobaciones de integridad disponibles, por ejemplo, mediante un resumen o un hash.  Esto permite a los clientes verificar la integridad calculando su propio hash de la carga útil y validando que sea el mismo que el publicado.  Si bien estas comprobaciones ayudan a verificar que la carga útil no se ha manipulado, no validan que provenga de la fuente original (su *procedencia*).  La verificación de la procedencia requiere un certificado emitido por una autoridad de confianza para firmar digitalmente el artefacto. 

 Si utiliza un software o artefactos descargados en su carga de trabajo, compruebe si el proveedor proporciona una clave pública para la verificación de la firma digital.  Estos son algunos ejemplos de cómo AWS proporciona una clave pública e instrucciones de verificación para el software que publicamos: 
+  [EC2 Image Builder: Verify the signature of the AWSTOE installation download](https://docs.aws.amazon.com/imagebuilder/latest/userguide/awstoe-verify-sig.html) 
+  [AWS Systems Manager: Verifying the signature of SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/verify-agent-signature.html) 
+  [Amazon CloudWatch: Verifying the signature of the CloudWatch agent package](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/verify-CloudWatch-Agent-Package-Signature.html) 

 Incorpore la verificación de firmas digitales en los procesos que utilice para obtener y reforzar las imágenes, como se explica en [SEC06-BP02 Aprovisionamiento de computación a partir de imágenes reforzadas](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html). 

 Puede usar [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) para administrar la verificación de firmas, así como su propio ciclo de vida de firma de código para su propio software y artefactos.  Tanto [AWS Lambda](https://aws.amazon.com/lambda/) como [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) proporcionan integraciones con Signer para verificar las firmas de su código y sus imágenes.  Con los ejemplos de la sección Recursos, puede incorporar Signer a sus procesos de integración y entrega continuas (CI/CD) para automatizar la verificación de las firmas y la firma de su propio código e imágenes. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Cryptographic Signing for Containers](https://aws.amazon.com/blogs/containers/cryptographic-signing-for-containers/) 
+  [Best Practices to help secure your container image build pipeline by using AWS Signer](https://aws.amazon.com/blogs/security/best-practices-to-help-secure-your-container-image-build-pipeline-by-using-aws-signer/) 
+  [Announcing Container Image Signing with AWS Signer and Amazon EKS](https://aws.amazon.com/blogs/containers/announcing-container-image-signing-with-aws-signer-and-amazon-eks/) 
+  [Configuring code signing for AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html) 
+  [Best practices and advanced patterns for Lambda code signing](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/) 
+  [Code signing using AWS Certificate Manager Private CA and AWS Key Management Service asymmetric keys](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/) 

 **Ejemplos relacionados:** 
+  [Automate Lambda code signing with Amazon CodeCatalyst and AWS Signer](https://aws.amazon.com/blogs/devops/automate-lambda-code-signing-with-amazon-codecatalyst-and-aws-signer/) 
+  [Signing and Validating OCI Artifacts with AWS Signer](https://aws.amazon.com/blogs/containers/signing-and-validating-oci-artifacts-with-aws-signer/) 

 **Herramientas relacionadas:** 
+  [AWS Lambda](https://aws.amazon.com/lambda/) 
+  [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) 
+  [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) 
+  [AWS Key Management Service](https://aws.amazon.com/kms/) 
+  [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) 

# SEC06-BP05 Automatización de la protección de computación
<a name="sec_protect_compute_auto_protection"></a>

 Automatice las operaciones de protección de computación para reducir la necesidad de intervención humana. Utilice el análisis automatizado para detectar posibles problemas en sus recursos de computación y use respuestas programáticas automatizadas u operaciones de administración de flotas para solucionarlos.  Incorpore la automatización en sus procesos de CI/CD para implementar cargas de trabajo fiables con dependencias actualizadas. 

 **Resultado deseado:** los sistemas automatizados llevan a cabo todos los escaneos y parches de los recursos de computación. Use la verificación automática para comprobar que las imágenes y dependencias del software provengan de orígenes fiables y que no se hayan manipulado. Las cargas de trabajo se comprueban automáticamente para determinar si las dependencias están actualizadas y se firman para establecer la fiabilidad en los entornos de computación de AWS.  Las correcciones automatizadas se inician cuando se detectan recursos no conformes con los requisitos.  

 **Patrones comunes de uso no recomendados:** 
+  Seguir la práctica de una infraestructura inmutable sin contar con una solución para la instalación de parches de emergencia o la sustitución de sistemas de producción. 
+  Usar la automatización para corregir los recursos mal configurados sin contar con un mecanismo de anulación manual.  Es posible que surjan situaciones en las que necesite ajustar los requisitos y tenga que suspender las automatizaciones hasta haber hecho estos cambios. 

 **Beneficios de establecer esta práctica recomendada:** la automatización puede reducir el riesgo de accesos y usos no autorizados de sus recursos de computación.  Ayuda a evitar que lleguen configuraciones incorrectas a los entornos de producción y a detectarla y corregirlas en caso de que se produzcan.  La automatización también contribuye a detectar el acceso y el uso no autorizados de los recursos informáticos para reducir el tiempo de respuesta.  Esto, a su vez, puede reducir el alcance general del impacto del problema. 

 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio 

## Guía para la implementación
<a name="implementation-guidance"></a>

 Puede aplicar las automatizaciones descritas en las prácticas del pilar de seguridad para proteger sus recursos de computación. En [SEC06-BP01 Administración de las vulnerabilidades](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_vulnerability_management.html) se describe cómo puede utilizar [Amazon Inspector](https://aws.amazon.com/inspector/) tanto en sus canalizaciones de CI/CD como para analizar continuamente sus entornos en tiempo de ejecución en busca de vulnerabilidades y exposiciones comunes (CVE) conocidas.  Puede usar [AWS Systems Manager](https://aws.amazon.com/systems-manager/) para aplicar parches o volver a implementar imágenes nuevas mediante manuales de procedimientos automatizados para mantener su flota de computación actualizada con el software y las bibliotecas más recientes.  Utilice estas técnicas para reducir la necesidad de recurrir a procesos manuales y el acceso interactivo a sus recursos informáticos.  Consulte [SEC06-BP03 Reducción de la administración manual y el acceso interactivo](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_reduce_manual_management.html) para obtener más información. 

 La automatización también desempeña un papel en la implementación de cargas de trabajo confiables, tal como se describe en [SEC06-BP02 Aprovisionamiento de computación a partir de imágenes reforzadas](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html) y [SEC06-BP04 Validación de la integridad del software](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_validate_software_integrity.html).  Puede usar servicios como el [Generador de imágenes de EC2](https://aws.amazon.com/image-builder/), [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html), [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) y [Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) para descargar, verificar, construir y almacenar dependencias de código e imágenes reforzadas y aprobadas.   Junto con Inspector, cada uno de estos elementos puede desempeñar un papel en su proceso de CI/CD, de modo que su carga de trabajo llegue al entorno de producción solo cuando se confirme que sus dependencias están actualizadas y provienen de orígenes fiables.  La carga de trabajo también está firmada para que los entornos de computación de AWS, como [AWS Lambda](https://aws.amazon.com/lambda/) y [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/), puedan verificar que no se ha manipulado antes de permitir su ejecución. 

 Además de estos controles preventivos, también puede utilizar la automatización en sus controles de detección para sus recursos de computación.  Por ejemplo, [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) ofrece el estándar [NIST 800-53 Rev. 5](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html), que incluye comprobaciones como esta: [[EC2.8] las instancias de EC2 deben usar la versión 2 del servicio de metadatos de instancia (IMDSv2)](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-8).  El IMDSv2 utiliza técnicas de autenticación de sesión y bloquea las solicitudes que contienen un encabezado HTTP X-Forwarded-For y un TTL de red de 1 para detener el tráfico que se origina en fuentes externas para recuperar información sobre la instancia de EC2. Esta comprobación en Security Hub CSPM puede detectar si las instancias de EC2 utilizan IMDSv1 e iniciar una corrección automatizada. Obtenga más información sobre la detección y las correcciones automatizadas en [SEC04-BP04 Inicio de correcciones para recursos no conformes](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html). 

### Pasos para la implementación
<a name="implementation-steps"></a>

1.  Automatice la creación de AMI seguras, compatibles y reforzadas con el [Generador de imágenes de EC2](https://docs.aws.amazon.com/imagebuilder/latest/userguide/integ-compliance-products.html).  Puede producir imágenes que incorporen los controles de los estándares comparativos del Center for Internet Security (CIS) o de la Security Technical Implementation Guide (STIG) a partir de imágenes base de AWS e imágenes de socios de APN. 

1.  Automatice la administración de la configuración. Aplique y valide configuraciones seguras en sus recursos de computación de forma automática mediante el uso de un servicio o herramienta de gestión de configuraciones.  

   1.  Administración automatizada de la configuración con [AWS Config](https://aws.amazon.com/config/) 

   1.  Administración automatizada de la posición de seguridad y cumplimiento mediante [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 

1.  Automatice la aplicación de parches o el reemplazo de instancias de Amazon Elastic Compute Cloud (Amazon EC2). AWS Systems Manager Patch Manager automatiza el proceso de aplicación de parches a instancias administradas con actualizaciones de seguridad y de otro tipo. Puede utilizar Patch Manager para aplicar parches a los sistemas operativos y a las aplicaciones. 

   1.  [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 

1.  Automatice el análisis de los recursos de computación en busca de vulnerabilidades y exposiciones comunes (CVE) e incorpore soluciones de análisis de seguridad en su proceso de desarrollo. 

   1.  [Amazon Inspector](https://aws.amazon.com/inspector/) 

   1.  [ECR Image Scanning](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html) 

1.  Plantéese el uso de Amazon GuardDuty para detectar amenazas y malware de forma automática con el fin de proteger los recursos de computación. GuardDuty también puede identificar posibles problemas cuando se invoca una función de [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) en su entorno de AWS.  

   1.  [Amazon GuardDuty](https://aws.amazon.com/guardduty/) 

1.  Tenga en cuenta las soluciones de socios de AWS. AWS Los socios ofrecen cientos de productos destacados que son equivalentes o idénticos a los controles que ya utiliza en sus entornos en las instalaciones o que pueden integrarse con ellos. Estos productos complementan a los servicios de AWS existentes y le permiten implementar una arquitectura de seguridad integral, así como disfrutar de una experiencia más fluida tanto en la nube como en los entornos en las instalaciones. 

   1.  [Seguridad de la infraestructura](https://aws.amazon.com/security/partner-solutions/#infrastructure_security) 

## Recursos
<a name="resources"></a>

 **Prácticas recomendadas relacionadas:** 
+  [SEC01-BP06 Automatización de la implementación de controles de seguridad estándares](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls.html) 

 **Documentos relacionados:** 
+  [Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/) 

 **Videos relacionados:** 
+  [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI) 