# Protección de redes
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
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
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
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
**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
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
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
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
**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
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
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
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
**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
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
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
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
**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)