**Presentamos una nueva experiencia de consola para AWS WAF**
Ahora puede usar la experiencia actualizada para acceder a las AWS WAF funciones desde cualquier parte de la consola. Para obtener más información, consulte [Trabajar con la consola](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html).
Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# AWS Shield
La protección contra los ataques de denegación de servicio distribuidos es de vital importancia para sus aplicaciones con acceso a Internet. DDo Al crear su aplicación AWS, puede utilizar las protecciones que AWS ofrece sin coste adicional. Además, puede utilizar el servicio de protección AWS Shield Advanced gestionada contra amenazas para mejorar su nivel de seguridad con funciones adicionales de detección, mitigación y respuesta al virus DDo S.
AWS se compromete a proporcionarle las herramientas, las mejores prácticas y los servicios que le ayudarán a garantizar una alta disponibilidad, seguridad y resiliencia en su defensa contra los delincuentes en Internet. Esta guía se proporciona para ayudar a los responsables de la toma de decisiones de TI y a los ingenieros de seguridad a comprender cómo utilizar Shield and Shield Advanced para proteger mejor sus aplicaciones de los ataques DDo S y otras amenazas externas.
Cuando crea su aplicación AWS, recibe protección automática AWS contra los vectores de ataque DDo S volumétricos más comunes, como los ataques de reflexión UDP y las inundaciones de TCP SYN. Puede aprovechar estas protecciones para garantizar la disponibilidad de las aplicaciones en las que se ejecuta AWS mediante el diseño y la configuración de su arquitectura para garantizar la resiliencia de DDo S.
Esta guía proporciona recomendaciones que pueden ayudarle a diseñar, crear y configurar las arquitecturas de sus aplicaciones para la resiliencia DDo S. Las aplicaciones que siguen las prácticas recomendadas en esta guía pueden beneficiarse de una mayor continuidad de disponibilidad cuando son objeto de ataques DDo S más grandes y de gamas más amplias de vectores de ataque DDo S. Además, esta guía le muestra cómo utilizar Shield Advanced para implementar una postura de protección DDo S optimizada para sus aplicaciones críticas. Estas incluyen las aplicaciones para las que ha garantizado un cierto nivel de disponibilidad para sus clientes y aquellas que requieren soporte operativo AWS durante los eventos DDo S.
La seguridad es una responsabilidad compartida entre usted AWS y usted. El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) la describe como seguridad *de* la nube y seguridad *en* la nube:
+ **Seguridad de la nube**: AWS es responsable de proteger la infraestructura que ejecuta AWS los servicios en la Nube de AWS. AWS también le proporciona servicios que puede utilizar de forma segura. Auditores externos prueban y verifican periódicamente la eficacia de nuestra seguridad en el marco de los [Programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/). Para obtener más información sobre los programas de conformidad que se aplican a Shield Avanzado, consulte [Servicios de AWS en el ámbito del programa de conformidad](https://aws.amazon.com/compliance/services-in-scope/).
+ **Seguridad en la nube**: su responsabilidad viene determinada por el AWS servicio que utilice. Usted también es responsable de otros factores, incluida la confidencialidad de los datos, los requisitos de la empresa y la legislación y los reglamentos aplicables.
![\[Un diagrama muestra un rectángulo dividido horizontalmente. La mitad superior se titula Cliente: responsabilidad por la seguridad “en” la nube y la mitad inferior, AWS: responsabilidad por la seguridad “de” la nube. La mitad superior de clientes consta de cuatro niveles. El primero es Datos de clientes. El segundo es Gestión de plataforma, aplicaciones, identidad y acceso. El tercero es Configuración del sistema operativo, la red y el firewall. El cuarto y último nivel del área de clientes se divide en tres secciones contiguas. La de la izquierda es Datos del cliente, cifrado e integridad de los datos y autenticación. La del medio es el cifrado del lado del servidor ( and/or datos del sistema de archivos). La de la derecha es Protección del tráfico de red (cifrado, integridad, identidad). Con esto se concluye el contenido de la mitad superior de clientes de la figura. La AWS mitad inferior de la figura contiene un nivel denominado Software en la parte superior y, debajo, un nivel denominado AWS Hardware/infraestructura global. El nivel de software se divide en cuatro subsecciones contiguas: Computación, Almacenamiento, Base de datos, Redes. El nivel de hardware se divide en tres subsecciones que están una al lado de la otra y son Regiones, Zonas de disponibilidad y Ubicaciones periféricas.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shared-responsibility-model.png)
# Cómo funcionan AWS Shield and Shield Advanced
En esta página se explica la diferencia entre AWS Shield Standard y AWS Shield Advanced. Además, se describen las clases de ataques que Shield detecta.
AWS Shield Standard y AWS Shield Advanced proporcionan protección contra los ataques de denegación de servicio (DDoS) distribuidos a los AWS recursos de las capas de red y transporte (capas 3 y 4) y de la capa de aplicación (capa 7). Un ataque DDo S es un ataque en el que varios sistemas comprometidos intentan inundar un objetivo con tráfico. Un ataque DDo S puede impedir que los usuarios finales legítimos accedan a los servicios de destino y provocar que el objetivo se bloquee debido a un volumen de tráfico abrumador.
AWS Shield proporciona protección contra una amplia gama de vectores de ataque DDo S y vectores de ataque de día cero conocidos. La detección y mitigación de Shield están diseñadas para brindar cobertura contra las amenazas, incluso si el servicio no las conoce explícitamente en el momento de la detección.
Shield Standard se proporciona automáticamente y sin costo adicional cuando se utiliza AWS. Para obtener mayores niveles de protección contra ataques, puede suscribirse a AWS Shield Advanced.
Entre las clases de ataques que Shield detecta se incluyen las siguientes:
+ **Ataques volumétricos de red (capa 3)**: se trata de una subcategoría de los vectores de ataque a la capa de infraestructura. Estos vectores intentan saturar la capacidad de la red o el recurso objetivo para denegar el servicio a los usuarios legítimos.
+ **Ataques de protocolo de red (capa 4)**: se trata de una subcategoría de los vectores de ataque a la capa de infraestructura. Estos vectores abusan de un protocolo para denegar el servicio al recurso objetivo. Un ejemplo común de ataque a un protocolo de red es una inundación de TCP SYN, que puede agotar el estado de la conexión en recursos como servidores, equilibradores de carga o firewalls. Un ataque de protocolo de red también puede ser volumétrico. Por ejemplo, una inundación TCP SYN mayor puede tener como objetivo saturar la capacidad de una red y, al mismo tiempo, agotar el estado del recurso objetivo o de los recursos intermedios.
+ **Ataques a la capa de aplicación (capa 7)**: esta categoría de vector de ataque intenta denegar el servicio a los usuarios legítimos inundando una aplicación con consultas que son válidas para el objetivo, como las inundaciones de solicitudes web.
**Contents**
+ [Descripción general de AWS Shield Standard](ddos-standard-summary.md)
+ [Descripción general de AWS Shield Advanced](ddos-advanced-summary.md)
+ [Lista de AWS recursos que AWS Shield Advanced protegen](ddos-advanced-summary-protected-resources.md)
+ [AWS Shield Advanced capacidades y opciones](ddos-advanced-summary-capabilities.md)
+ [Decidir si suscribirse a protecciones adicionales AWS Shield Advanced y aplicarlas](ddos-advanced-summary-deciding.md)
+ [Ejemplos de ataques DDo S](types-of-ddos-attacks.md)
+ [Cómo AWS Shield detecta los eventos](ddos-event-detection.md)
+ [AWS Shield lógica de detección de amenazas en la capa de infraestructura (capa 3 y capa 4)](ddos-event-detection-infrastructure.md)
+ [Lógica de detección de amenazas de Shield Avanzado en la capa de aplicación (capa 7)](ddos-event-detection-application.md)
+ [Lógica de detección de Shield Avanzado para varios recursos en una aplicación](ddos-event-detection-multiple-resources.md)
+ [Cómo AWS Shield mitiga los eventos](ddos-event-mitigation.md)
+ [Lista de funciones de mitigación de AWS Shield DDo S](ddos-event-mitigation-features.md)
+ [AWS Shield lógica de mitigación para CloudFront y Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield lógica de mitigación para AWS las regiones](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield lógica de mitigación para aceleradores AWS Global Accelerator estándar](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced lógica de mitigación para Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced lógica de mitigación para aplicaciones web](ddos-event-mitigation-logic-adv-web-app.md)
# Descripción general de AWS Shield Standard
AWS Shield es un servicio gestionado de protección contra amenazas que protege el perímetro de su aplicación. El perímetro es el primer punto de entrada para el tráfico de aplicaciones que proviene de fuera de la AWS red.
Para determinar dónde se encuentra el perímetro de la aplicación, considere la forma en que los usuarios acceden a la aplicación desde Internet. Si el primer punto de entrada se encuentra en una AWS región, el perímetro de la aplicación es su Amazon Virtual Private Cloud (VPC). Si Amazon Route 53 dirige a los usuarios a su aplicación y primero acceden a la aplicación mediante Amazon CloudFront o AWS Global Accelerator, a continuación, el perímetro de la aplicación comienza en el extremo de la AWS red.
Shield proporciona beneficios de detección y mitigación de DDo S para todas las aplicaciones en las que se ejecutan AWS, pero las decisiones que tome al diseñar la arquitectura de la aplicación influirán en su nivel de resiliencia de DDo S. DDoS La resiliencia es la capacidad de su aplicación para seguir funcionando dentro de los parámetros esperados durante un ataque.
Todos AWS los clientes se benefician de la protección automática de Shield Standard, sin coste adicional. Shield Standard ofrece protección contra los ataques de capa DDo S de red y transporte más comunes y frecuentes que tienen como objetivo su sitio web o sus aplicaciones. Si bien Shield Standard ayuda a proteger a todos AWS los clientes, usted obtiene beneficios especiales con las zonas alojadas de Amazon Route 53, CloudFront las distribuciones de Amazon y los aceleradores AWS Global Accelerator estándar. Estos recursos ofrecen una protección de disponibilidad integral contra todos los ataques conocidos a la capa de transporte y red.
# Descripción general de AWS Shield Advanced
AWS Shield Advanced es un servicio gestionado que le ayuda a proteger su aplicación contra amenazas externas, como los ataques DDo S, los bots volumétricos y los intentos de explotación de vulnerabilidades. Para obtener mayores niveles de protección contra ataques, puede suscribirse a AWS Shield Advanced.
Cuando te suscribes a Shield Advanced y añades protección a tus recursos, Shield Advanced ofrece una protección ampliada contra ataques DDo S para esos recursos. Las protecciones que reciba de Shield Avanzado pueden variar en función de la arquitectura y las opciones de configuración. Utilice la información de esta guía para crear y proteger aplicaciones resilientes con Shield Avanzado y para ampliarlas cuando necesite la ayuda de un experto.
**Suscripciones y AWS WAF costos de Shield Advanced**
Su suscripción a Shield Advanced cubre los costes de uso de AWS WAF las capacidades estándar para los recursos que proteja con Shield Advanced. Las AWS WAF tarifas estándar que cubren las protecciones Shield Advanced son el costo por paquete de protección (ACL web), el costo por regla y el precio base por millón de solicitudes de inspección de solicitudes web, hasta 1500 WCUs y hasta el tamaño corporal predeterminado.
Al habilitar la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced, se añade un grupo de reglas al paquete de protección (ACL web) que utiliza 150 unidades de capacidad de ACL web (WCUs). Esto se WCUs descuenta del uso de la WCU en su paquete de protección (ACL web). Para obtener más información, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md), [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md) y [Unidades de capacidad de ACL web (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Su suscripción a Shield Advanced no cubre el uso AWS WAF de recursos que no proteja con Shield Advanced. Tampoco cubre ningún AWS WAF coste adicional no estándar de los recursos protegidos. Algunos ejemplos de AWS WAF costes no estándar son los del control de bots, la acción de la CAPTCHA regla, la web ACLs que utiliza más de 1500 WCUs usuarios y la inspección del cuerpo de la solicitud por encima del tamaño predeterminado. La lista completa se encuentra en la página de AWS WAF precios. Su suscripción a Shield Advanced incluye el acceso al grupo de reglas gestionadas por Amazon DDo Anti-S de capa 7. Como parte de su suscripción, recibirá hasta 50 000 millones de solicitudes a los AWS WAF recursos protegidos de Shield Advanced en un mes natural. Las solicitudes superiores a 50 000 millones se facturarán según la página de AWS Shield Advanced precios.
Para obtener la información completa y ejemplos de precios, consulte [Precios de Shield](https://aws.amazon.com/shield/pricing/) y [Precios de AWS WAF](https://aws.amazon.com/waf/pricing/).
**Facturación de suscripciones de Shield Avanzado**
Si eres un distribuidor de AWS canales, ponte en contacto con tu equipo de cuentas para obtener información y orientación. Esta información de facturación es para clientes que no son distribuidores de AWS canal.
Para todos los demás, se aplican las siguientes pautas de suscripción y facturación:
+ En el caso de las cuentas que son miembros de una AWS Organizations organización, AWS factura las suscripciones de Shield Advanced a la cuenta de pagador de la organización, independientemente de si la propia cuenta de pagador está suscrita.
+ Al suscribir varias cuentas que pertenezcan a la misma [familia de cuentas de facturación de AWS Organizations consolidada](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), un único precio de suscripción cubre todas las cuentas suscritas de la familia. La organización debe ser propietaria de todas las Cuentas de AWS y de todos sus recursos.
+ Si suscribe varias cuentas para varias organizaciones, puede seguir pagando una única cuota de suscripción para todas las organizaciones, cuentas y recursos, siempre que sea el propietario de todos ellos. Póngase en contacto con su administrador de cuentas o con el servicio de AWS asistencia y solicite una exención de las tarifas de AWS Shield Advanced suscripción para todas las organizaciones excepto una.
Para obtener ejemplos e información detallada sobre precios, consulte [Precios de AWS Shield](https://aws.amazon.com/shield/pricing/).
**Topics**
# Lista de AWS recursos que AWS Shield Advanced protegen
**nota**
Las protecciones de Shield Advanced solo están habilitadas para los recursos que haya especificado explícitamente en Shield Advanced o que proteja mediante una política de AWS Firewall Manager Shield Advanced. Shield Avanzado no protege automáticamente sus recursos.
Puede usar Shield Avanzado para una supervisión y protección avanzadas con los siguientes tipos de recursos:
+ CloudFront Distribuciones de Amazon. Para CloudFront un despliegue continuo, Shield Advanced protege cualquier distribución provisional que esté asociada a una distribución principal protegida.
+ Zonas alojadas de Amazon Route 53.
+ AWS Global Accelerator aceleradores estándar.
+ Direcciones IP EC2 elásticas de Amazon. Shield Avanzado protege los recursos asociados a las direcciones IP elásticas protegidas.
+ EC2 Instancias de Amazon, mediante la asociación a direcciones IP EC2 elásticas de Amazon.
+ Los siguientes equilibradores de carga Elastic Load Balancing (ELB):
+ Equilibradores de carga de aplicación.
+ Equilibradores de carga clásicos.
+ Equilibradores de carga de red, mediante asociaciones a direcciones IP de Amazon EC2 Elastic.
Para obtener información adicional acerca de las protecciones para estos tipos de recursos, consulte [Lista de recursos que AWS Shield Advanced protegen](ddos-protections-by-resource-type.md).
# AWS Shield Advanced capacidades y opciones
AWS Shield Advanced la suscripción incluye las siguientes capacidades y opciones. Estas funciones complementan las funciones de detección y mitigación del virus DDo S que ya incluye AWS.
+ **AWS WAF integración**: Shield Advanced utiliza la AWS WAF web ACLs, las reglas y los grupos de reglas como parte de las protecciones de la capa de aplicación. Para obtener más información al respecto AWS WAF, consulte[Cómo AWS WAF funciona](how-aws-waf-works.md).
**nota**
Su suscripción a Shield Advanced cubre los costes de uso de AWS WAF las capacidades estándar para los recursos que proteja con Shield Advanced. Las AWS WAF tarifas estándar que cubren las protecciones Shield Advanced son el costo por paquete de protección (ACL web), el costo por regla y el precio base por millón de solicitudes de inspección de solicitudes web, hasta 1500 WCUs y hasta el tamaño corporal predeterminado.
Al habilitar la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced, se añade un grupo de reglas al paquete de protección (ACL web) que utiliza 150 unidades de capacidad de ACL web (WCUs). Esto se WCUs descuenta del uso de la WCU en su paquete de protección (ACL web). Para obtener más información, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md), [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md) y [Unidades de capacidad de ACL web (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Su suscripción a Shield Advanced no cubre el uso AWS WAF de recursos que no proteja con Shield Advanced. Tampoco cubre ningún AWS WAF coste adicional no estándar de los recursos protegidos. Algunos ejemplos de AWS WAF costes no estándar son los del control de bots, la acción de la CAPTCHA regla, la web ACLs que utiliza más de 1500 WCUs usuarios y la inspección del cuerpo de la solicitud por encima del tamaño predeterminado. La lista completa se encuentra en la página de AWS WAF precios. Su suscripción a Shield Advanced incluye el acceso al grupo de reglas gestionadas por Amazon DDo Anti-S de capa 7. Como parte de su suscripción, recibirá hasta 50 000 millones de solicitudes a los AWS WAF recursos protegidos de Shield Advanced en un mes natural. Las solicitudes superiores a 50 000 millones se facturarán según la página de AWS Shield Advanced precios.
Para obtener la información completa y ejemplos de precios, consulte [Precios de Shield](https://aws.amazon.com/shield/pricing/) y [Precios de AWS WAF](https://aws.amazon.com/waf/pricing/).
+ **Mitigación automática de la capa de aplicación DDo S**: puede configurar Shield Advanced para que responda automáticamente y mitigue los ataques de la capa de aplicación (capa 7) contra sus recursos protegidos. Con la mitigación automática, Shield Advanced impone límites de AWS WAF velocidad a las solicitudes de fuentes DDo S conocidas y agrega y administra automáticamente AWS WAF protecciones personalizadas en respuesta a los ataques DDo S detectados. Puede configurar la mitigación automática para contar o bloquear las solicitudes web que forman parte de un ataque.
Para obtener más información, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
+ **Detección basada en el estado**: puede utilizar los controles de estado de Amazon Route 53 con Shield Avanzado para informar sobre la detección y mitigación de eventos. Los controles de estado supervisan su aplicación de acuerdo con sus especificaciones y notifican que están en buen estado cuando se cumplen las especificaciones y en mal estado cuando no se cumplen. El uso de controles de estado con Shield Avanzado ayuda a prevenir los falsos positivos y proporciona una detección y mitigación más rápidas cuando un recurso protegido no está en buen estado. Puede usar la detección basada en el estado para cualquier tipo de recurso, excepto para las zonas alojadas en Route 53. La participación proactiva de Shield Avanzado solo está disponible para los recursos que tienen habilitada la detección basada en el estado.
Para obtener más información, consulte [Detección basada en el estado mediante comprobaciones de estado con Shield Avanzado y Route 53](ddos-advanced-health-checks.md).
+ **Grupos de protección**: puede usar los grupos de protección para crear agrupaciones lógicas de sus recursos protegidos, a fin de mejorar la detección y mitigación del grupo en su conjunto. Puede definir los criterios de pertenencia a un grupo de protección para que los recursos recién protegidos se incluyan automáticamente. Un recurso protegido puede pertenecer a varios grupos de protección.
Para obtener más información, consulte [Agrupación de sus protecciones AWS Shield Advanced](ddos-protection-groups.md).
+ **Visibilidad mejorada de los eventos y ataques DDo S**: Shield Advanced le brinda acceso a métricas e informes avanzados en tiempo real para una amplia visibilidad de los eventos y ataques a sus AWS recursos protegidos. Puedes acceder a esta información a través de la consola y la API Shield Advanced y a través de CloudWatch las métricas de Amazon.
Para obtener más información, consulte [Visibilidad de DDo los eventos S con Shield Advanced](ddos-viewing-events.md).
+ **Administración centralizada de las protecciones de Shield Advanced mediante AWS Firewall Manager**: puede usar Firewall Manager para aplicar automáticamente las protecciones de Shield Advanced a sus nuevas cuentas y recursos y para implementar AWS WAF reglas en su web ACLs. Las políticas de protección de Firewall Manager Shield Avanzado se incluyen sin cargo adicional para los clientes de Shield Avanzado. También puede centralizar las actividades de supervisión de Shield Avanzado para sus cuentas mediante Firewall Manager con un tema de Amazon Simple Notification Service (SNS) o AWS Security Hub CSPM.
Para obtener más información sobre el uso de Firewall Manager para administrar las protecciones de Shield Avanzado, consulte [AWS Firewall Manager](fms-chapter.md) y [Uso de AWS Shield Advanced políticas en Firewall Manager](shield-policies.md). Para obtener información acerca de los precios de Firewall Manager, consulte [Precios de AWS Firewall Manager](https://aws.amazon.com/firewall-manager/pricing/).
+ **AWS Shield Response Team (SRT)**: La SRT tiene una amplia experiencia en la protección AWS de Amazon.com y sus subsidiarias. Como AWS Shield Advanced cliente, puede ponerse en contacto con la SRT en cualquier momento para obtener ayuda durante un ataque tipo DDo S que afecte a la disponibilidad de su aplicación. También puede trabajar con el SRT para crear y administrar mitigaciones personalizadas para sus recursos. Para utilizar los servicios del SRT, debe haberse suscrito al [plan Business Support](https://aws.amazon.com/premiumsupport/business-support/) o en el [plan Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
Para obtener más información, consulte [Respuesta a eventos DDo S gestionada con el soporte del Shield Response Team (SRT)](ddos-srt-support.md).
+ **Interacción proactiva**: con la participación proactiva, el equipo de respuesta de Shield (SRT) se pone en contacto con usted directamente si la comprobación de estado de Amazon Route 53 que ha asociado a su recurso protegido deja de funcionar durante un evento detectado por Shield Avanzado. Esto le permite interactuar con los expertos con rapidez cuando la disponibilidad de su aplicación pueda verse afectada por un ataque sospechoso.
Para obtener más información, consulte [Configuración de una interacción proactiva para que el SRT se ponga en contacto con usted directamente](ddos-srt-proactive-engagement.md).
+ **Oportunidades de protección de costos**: Shield Advanced ofrece cierta protección de costos contra los picos en su AWS factura que podrían resultar de un ataque DDo S contra sus recursos protegidos. Esto puede incluir la cobertura de picos en las tarifas de uso de Shield Avanzado Data Transfer Out (DTO). Shield Advanced ofrece cualquier tipo de protección de costos en forma de créditos de servicio Shield Avanzado.
Para obtener más información, consulte [Solicitar un crédito AWS Shield Advanced después de un ataque](ddos-request-service-credit.md).
# Decidir si suscribirse a protecciones adicionales AWS Shield Advanced y aplicarlas
Revise los escenarios de esta sección para ayudarte a decidir a qué cuentas suscribirse AWS Shield Advanced y dónde aplicar protecciones adicionales. Con Shield Avanzado paga una cuota de suscripción mensual por todas las cuentas creadas en una cuenta de facturación unificada, más las tarifas de uso basadas en los GB de datos transferidos. Para obtener información sobre los precios de Shield Avanzado, consulte [Precios de AWS Shield Advanced](https://aws.amazon.com/shield/pricing/).
Para proteger una aplicación y sus recursos con Shield Avanzado, debe suscribir las cuentas que administran la aplicación a Shield Avanzado y, a continuación, añadir protecciones a los recursos de la aplicación. Para obtener información sobre la suscripción de cuentas y la protección de los recursos, consulte [Con AWS Shield Advanced figuración](getting-started-ddos.md).
**Suscripciones y AWS WAF costos de Shield Advanced**
Su suscripción a Shield Advanced cubre los costes de uso de AWS WAF las capacidades estándar para los recursos que proteja con Shield Advanced. Las AWS WAF tarifas estándar que cubren las protecciones Shield Advanced son el costo por paquete de protección (ACL web), el costo por regla y el precio base por millón de solicitudes de inspección de solicitudes web, hasta 1500 WCUs y hasta el tamaño corporal predeterminado.
Al habilitar la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced, se añade un grupo de reglas al paquete de protección (ACL web) que utiliza 150 unidades de capacidad de ACL web (WCUs). Esto se WCUs descuenta del uso de la WCU en su paquete de protección (ACL web). Para obtener más información, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md), [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md) y [Unidades de capacidad de ACL web (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Su suscripción a Shield Advanced no cubre el uso AWS WAF de recursos que no proteja con Shield Advanced. Tampoco cubre ningún AWS WAF coste adicional no estándar de los recursos protegidos. Algunos ejemplos de AWS WAF costes no estándar son los del control de bots, la acción de la CAPTCHA regla, la web ACLs que utiliza más de 1500 WCUs usuarios y la inspección del cuerpo de la solicitud por encima del tamaño predeterminado. La lista completa se encuentra en la página de AWS WAF precios. Su suscripción a Shield Advanced incluye el acceso al grupo de reglas gestionadas por Amazon DDo Anti-S de capa 7. Como parte de su suscripción, recibirá hasta 50 000 millones de solicitudes a los AWS WAF recursos protegidos de Shield Advanced en un mes natural. Las solicitudes superiores a 50 000 millones se facturarán según la página de AWS Shield Advanced precios.
Para obtener la información completa y ejemplos de precios, consulte [Precios de Shield](https://aws.amazon.com/shield/pricing/) y [Precios de AWS WAF](https://aws.amazon.com/waf/pricing/).
**Facturación de suscripciones de Shield Avanzado**
Si eres un distribuidor de AWS canales, ponte en contacto con tu equipo de cuentas para obtener información y orientación. Esta información de facturación es para clientes que no son distribuidores de AWS canal.
Para todos los demás, se aplican las siguientes pautas de suscripción y facturación:
+ En el caso de las cuentas que son miembros de una AWS Organizations organización, AWS factura las suscripciones de Shield Advanced a la cuenta de pagador de la organización, independientemente de si la propia cuenta de pagador está suscrita.
+ Al suscribir varias cuentas que pertenezcan a la misma [familia de cuentas de facturación de AWS Organizations consolidada](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), un único precio de suscripción cubre todas las cuentas suscritas de la familia. La organización debe ser propietaria de todas las Cuentas de AWS y de todos sus recursos.
+ Si suscribe varias cuentas para varias organizaciones, puede seguir pagando una única cuota de suscripción para todas las organizaciones, cuentas y recursos, siempre que sea el propietario de todos ellos. Póngase en contacto con su administrador de cuentas o con el servicio de AWS asistencia y solicite una exención de las tarifas de AWS Shield Advanced suscripción para todas las organizaciones excepto una.
Para obtener información detallada sobre precios, consulte [Precios de AWS Shield](https://aws.amazon.com/shield/pricing/).
**Identificación de las aplicaciones que se deben proteger**
Considere la posibilidad de implementar las protecciones Shield Avanzado para las aplicaciones en las que necesite alguno de los siguientes requisitos:
+ Disponibilidad garantizada para los usuarios de la aplicación.
+ Acceso rápido a expertos en mitigación DDo S si la aplicación se ve afectada por un ataque DDo S.
+ Consciente de AWS que la aplicación podría verse afectada por un ataque tipo DDo S y notifique a sus equipos de seguridad u operaciones si los ataques se producen o se intensifican. AWS
+ Los costes de la nube son predecibles, incluso si un ataque DDo tipo S afecta al uso de AWS los servicios.
Si una aplicación o sus recursos requieren alguno de los requisitos anteriores, considere la posibilidad de crear suscripciones para las cuentas relacionadas.
**Identificación de los recursos que se deben proteger**
Para cada cuenta suscrita, considere la posibilidad de añadir una protección Shield Avanzado a cada recurso que tenga alguna de las siguientes características:
+ El recurso está destinado a usuarios externos de Internet.
+ El recurso está expuesto a Internet y también forma parte de una aplicación crítica. Tenga en cuenta todos los recursos expuestos, independientemente de si tiene la intención de que los usuarios de Internet accedan a ellos.
+ El recurso está protegido por una ACL AWS WAF web.
Para obtener más información acerca de cómo crear y administrar protecciones para recursos, consulte [Protecciones de recursos en AWS Shield Advanced](ddos-resource-protections.md).
Además, siga las recomendaciones de esta guía para asegurarse de diseñar su aplicación para la resiliencia DDo S y de haber configurado correctamente las funciones de Shield Advanced para obtener una protección óptima.
# Ejemplos de ataques DDo S
AWS Shield Advanced proporciona una protección ampliada contra muchos tipos de ataques.
En la lista siguiente se describen algunos tipos de ataques comunes:
**Ataques de reflexión del protocolo de datagramas de usuario (UDP)**
En un ataque de reflexión de UDP, el atacante puede suplantar el origen de una solicitud y usar el UDP para obtener una respuesta grande del servidor. El tráfico de red adicional dirigido hacia la dirección IP suplantada y atacada puede ralentizar el servidor de destino e impedir que los usuarios finales obtengan acceso a los recursos necesarios.
**Inundación TCP SYN**
La intención de un ataque de inundación TCP SYN es agotar los recursos disponibles de un sistema dejando las conexiones en un estado semiabierto. Al conectarse un usuario a un servicio TCP como un servidor web, el cliente envía un paquete TCP SYN. El servidor devuelve un reconocimiento y el cliente devuelve su propio reconocimiento, completando el protocolo de tres modos. En una inundación TCP SYN, nunca se devuelve el tercer reconocimiento, mientras que el servidor permanece a la espera de una respuesta. Esto puede impedir que otros usuarios se conecten al servidor.
**Inundación de consultas DNS**
En una avalancha de consultas de DNS, un atacante utiliza varias consultas de DNS para agotar los recursos de un servidor DNS. AWS Shield Advanced puede ayudar a brindar protección contra los ataques de avalancha de consultas de DNS en los servidores DNS de Route 53.
**Ataques de inundación HTTP o ruptura de la caché (capa 7)**
Con una inundación HTTP, incluidas las inundaciones de `GET` y `POST`, un atacante envía varias solicitudes HTTP que parecen ser de un usuario real de la aplicación web. Los ataques de ruptura de la caché son un tipo de inundación HTTP que usa variaciones en la cadena de consulta de la solicitud HTTP que impiden el uso de contenido almacenado en caché con ubicación de borde y fuerza la distribución del contenido desde el servidor web de origen, lo que provoca una sobrecarga adicional y potencialmente perjudicial en el servidor web de origen.
# Cómo AWS Shield detecta los eventos
AWS opera sistemas de detección a nivel de servicio para la AWS red y AWS los servicios individuales, a fin de garantizar que permanezcan disponibles durante un ataque DDo S. Además, los sistemas de detección a nivel de recursos monitorean cada AWS recurso individual para garantizar que el tráfico hacia el recurso se mantenga dentro de los parámetros esperados. Esta combinación protege tanto el AWS recurso como los AWS servicios objetivo, al aplicar medidas de mitigación que descartan los paquetes defectuosos conocidos, destacan el tráfico potencialmente malicioso y priorizan el tráfico de los usuarios finales.
Los eventos detectados aparecen en los resúmenes de eventos, los detalles de los ataques y CloudWatch las métricas de Amazon de Shield Advanced como el nombre del vector de ataque DDo S o como `Volumetric` si la evaluación se hubiera basado en el volumen de tráfico y no en la firma. Para obtener más información sobre las dimensiones del vector de ataque disponibles en la `DDoSDetected` CloudWatch métrica, consulte[AWS Shield Advanced métricas](shield-metrics.md).
**Topics**
+ [AWS Shield lógica de detección de amenazas en la capa de infraestructura (capa 3 y capa 4)](ddos-event-detection-infrastructure.md)
+ [Lógica de detección de amenazas de Shield Avanzado en la capa de aplicación (capa 7)](ddos-event-detection-application.md)
+ [Lógica de detección de Shield Avanzado para varios recursos en una aplicación](ddos-event-detection-multiple-resources.md)
# AWS Shield lógica de detección de amenazas en la capa de infraestructura (capa 3 y capa 4)
En esta página se explica cómo funciona la detección de eventos en las capas de infraestructura (red y transporte).
La lógica de detección utilizada para proteger AWS los recursos objetivo contra los ataques DDo S en las capas de infraestructura (capa 3 y capa 4) depende del tipo de recurso y de si el recurso está protegido con él AWS Shield Advanced.
**Detección para Amazon CloudFront y Amazon Route 53**
Cuando suministra su aplicación web con CloudFront Route 53, todos los paquetes que llegan a la aplicación son inspeccionados por un sistema de mitigación DDo S totalmente integrado, que no introduce ninguna latencia observable. DDoLos ataques S contra CloudFront las distribuciones y las zonas alojadas en Route 53 se mitigan en tiempo real. Estas protecciones se aplican independientemente de si utiliza o no AWS Shield Advanced.
Siga la práctica recomendada de usar CloudFront Route 53 como punto de entrada a su aplicación web siempre que sea posible para detectar y mitigar los eventos DDo S con la mayor rapidez.
**Detección AWS Global Accelerator para servicios regionales**
La detección a nivel de recursos protege los aceleradores y recursos AWS Global Accelerator estándar que se lanzan en AWS las regiones, como los balanceadores de carga clásicos, los balanceadores de carga de aplicaciones y las direcciones IP elásticas (). EIPs Estos tipos de recursos se supervisan para detectar la elevación del tráfico que pueda indicar la presencia de un ataque DDo S que requiera una mitigación. Cada minuto, se evalúa el tráfico de cada recurso de AWS . Si el tráfico en un recurso es elevado, se realizan comprobaciones adicionales para medir la capacidad del recurso.
Shield realiza las siguientes comprobaciones estándar:
+ **Instancias de Amazon Elastic Compute Cloud (Amazon EC2), EIP asociados a instancias de Amazon EC2**: Shield recupera la capacidad del recurso protegido. La capacidad depende del tipo de instancia del objetivo, del tamaño de la instancia y de otros factores, como si la instancia utiliza una red mejorada.
+ **Equilibradores de carga clásicos y equilibradores de carga de aplicaciones**: Shield recupera la capacidad del nodo del equilibrador de carga objetivo.
+ **EIPs conectado a los balanceadores de carga de red**: Shield recupera la capacidad del balanceador de carga objetivo. La capacidad es independiente de la configuración del grupo del equilibrador de carga objetivo.
+ **AWS Global Accelerator aceleradores estándar**: Shield recupera la capacidad, que se basa en la configuración del punto final.
Estas evaluaciones se realizan en varias dimensiones del tráfico de la red, como el puerto y el protocolo. Si se supera la capacidad del recurso objetivo, Shield coloca una mitigación DDo S. Las mitigaciones implementadas por Shield reducirán el tráfico DDo S, pero es posible que no lo eliminen. Shield también puede suponer una mitigación si se supera una fracción de la capacidad del recurso en una dimensión de tráfico coherente con los vectores de ataque DDo S conocidos. Shield efectúa esta mitigación con un tiempo de vida limitado (TTL), que se prolonga mientras el ataque continúe.
**nota**
Las mitigaciones implementadas por Shield reducirán el tráfico DDo S, pero es posible que no lo eliminen. Puede ampliar Shield con soluciones como AWS Network Firewall , por ejemplo, un firewall en el host, iptables para evitar que su aplicación procese el tráfico que no es válido para su aplicación o que no ha sido generado por usuarios finales legítimos.
Las protecciones de Shield Avanzado agregan lo siguiente a las actividades de detección de Shield existentes:
+ **Umbrales de detección más bajos**: Shield Avanzado sitúa las mitigaciones a mitad de la capacidad calculada. Esto puede proporcionar una mitigación más rápida de los ataques que se intensifican lentamente y de los ataques que tienen una firma volumétrica más ambigua.
+ **Protección contra ataques intermitentes**: Shield Avanzado asigna a las mitigaciones un tiempo de vida (TTL) que aumenta exponencialmente en función de la frecuencia y la duración de los ataques. Esto mantiene las mitigaciones durante más tiempo cuando se ataca un recurso con frecuencia y cuando un ataque se produce en ráfagas cortas.
+ **Detección basada en estado**: al asociar una comprobación de estado de Route 53 a un recurso protegido de Shield Avanzado, el estado de la comprobación de estado se utiliza en la lógica de detección. Durante un evento detectado, si la comprobación de estado es buena, Shield Avanzado requiere mayor confianza en que se trata de un ataque antes de aplicar una mitigación. Si, por el contrario, la comprobación de estado no es buena, Shield Avanzado podría aplicar una medida de corrección incluso antes de que se haya establecido la confianza. Esta característica ayuda a evitar los falsos positivos y proporciona una reacción más rápida ante los ataques que afectan a la aplicación. Para obtener información sobre las comprobaciones de estado con Shield Avanzado, consulte [Detección basada en el estado mediante comprobaciones de estado con Shield Avanzado y Route 53](ddos-advanced-health-checks.md).
# Lógica de detección de amenazas de Shield Avanzado en la capa de aplicación (capa 7)
Esta página explica cómo funciona la detección de eventos en la capa de aplicación.
AWS Shield Advanced proporciona detección de capas de aplicaciones web para CloudFront distribuciones de Amazon protegidas y balanceadores de carga de aplicaciones. Cuando protege estos tipos de recursos con Shield Avanzado, puede asociar una ACL web de AWS WAF con su protección para activar la detección de la capa de aplicaciones web. Shield Avanzado consume los datos de solicitud de la ACL web asociada y crea una línea base de tráfico para su aplicación. La detección de la capa de aplicaciones web se basa en la integración nativa entre Shield Avanzado y AWS WAF. Para obtener más información sobre las protecciones de la capa de aplicaciones, incluida la asociación de una ACL AWS WAF web a un recurso protegido de Shield Advanced, consulte[Proteger la capa de aplicación (capa 7) con AWS Shield Advanced y AWS WAF](ddos-app-layer-protections.md).
Para la detección de la capa de aplicaciones web, Shield Avanzado supervisa el tráfico de las aplicaciones y lo compara con las líneas de base históricas en busca de anomalías. Esta supervisión cubre el volumen y la composición del tráfico totales. Durante un ataque DDo S, esperamos que cambien tanto el volumen como la composición del tráfico, y Shield Advanced requiere una desviación estadísticamente significativa en ambos para declarar un evento.
Shield Avanzado realiza sus mediciones en función de ventanas temporales históricas. Este enfoque reduce las notificaciones de falsos positivos derivadas de cambios legítimos en el volumen de tráfico o de cambios en el tráfico que coinciden con un patrón esperado, como una venta que se ofrece a la misma hora todos los días.
**nota**
Evite los falsos positivos en sus protecciones de Shield Avanzado dándole tiempo a Shield Avanzado para establecer líneas de base que representen patrones de tráfico normales y legítimos. Shield Avanzado comienza a recopilar información para la línea de base cuando se asocia una ACL web al recurso protegido. Asocie una ACL web a su recurso protegido al menos 24 horas antes de cualquier evento planificado que pueda provocar patrones inusuales en el tráfico web. La detección de la capa de aplicaciones web de Shield Avanzado es más precisa cuando ha observado 30 días de tráfico normal.
El tiempo que Shield Avanzado tarda en detectar un evento depende del cambio que observe en el volumen de tráfico. En el caso de cambios de menor volumen, Shield Avanzado observa el tráfico durante un período más prolongado para garantizar que se esté produciendo un evento. Para cambios de volumen más elevados, Shield Avanzado detecta e informa de un evento con mayor rapidez.
Una regla basada en tasas en su ACL web, ya sea agregada por usted o por la característica de mitigación automática de la capa de aplicación de Shield Avanzado, puede mitigar un ataque antes de que alcance un nivel detectable. Para obtener más información sobre la mitigación automática de la capa DDo S de aplicación, consulte[Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
**nota**
Puede diseñar su aplicación para escalar en respuesta a un tráfico o una carga elevados a fin de garantizar que no se vea afectada por avalanchas de solicitudes más pequeñas. Con Shield Avanzado, sus recursos protegidos están cubiertos por una protección de costos. Esto le ayuda a protegerse contra los aumentos inesperados en su factura de servicios en la nube que podrían producirse como resultado de un ataque DDo S. Para obtener más información sobre la protección de costos de Shield Avanzado, consulte [Solicitar un crédito AWS Shield Advanced después de un ataque](ddos-request-service-credit.md).
# Lógica de detección de Shield Avanzado para varios recursos en una aplicación
En esta página se explica cómo funciona la detección de eventos para varios recursos en una aplicación.
Puede usar grupos de AWS Shield Advanced protección para crear colecciones de recursos protegidos que formen parte de la misma aplicación. Puede elegir qué recursos protegidos desea colocar en un grupo o indicar que todos los recursos del mismo tipo se traten como un grupo. Por ejemplo, puede crear un grupo de todos los equilibradores de carga de aplicaciones. Al crear un grupo de protección, la detección de Shield Avanzado agrega todo el tráfico de los recursos protegidos del grupo. Esto resulta útil si tiene muchos recursos, cada uno de los cuales tiene una cantidad pequeña de tráfico, pero con un volumen agregado grande. También puede usar grupos de protección para preservar las líneas base de las aplicaciones, en el caso de implementaciones azul/verde en las que el tráfico se transfiere entre recursos protegidos.
Puede optar por agregar el tráfico de su grupo de protección de una de las siguientes maneras:
+ **Suma**: esta agregación combina todo el tráfico entre los recursos del grupo de protección. Puede usar esta agregación para asegurarse de que los recursos recién creados tengan una línea base existente y para reducir la sensibilidad de detección, lo que puede ayudar a evitar los falsos positivos.
+ **Media**: esta agregación utiliza el promedio de todo el tráfico del grupo de protección. Puede usar esta agregación para aplicaciones en las que el tráfico entre los recursos es uniforme, como los equilibradores de carga.
+ **Máximo**: esta agregación utiliza el tráfico más alto de cualquier recurso del grupo de protección. Puede usar esta agregación cuando hay varios niveles de una aplicación en un grupo de protección. Por ejemplo, puede tener un grupo de protección que incluya una CloudFront distribución, su origen de Application Load Balancer y los destinos de instancia Amazon EC2 de Application Load Balancer.
También puedes usar grupos de protección para mejorar la velocidad a la que Shield Advanced aplica las mitigaciones en el caso de ataques dirigidos a varios aceleradores Elastic IPs o estándar con acceso a Internet. AWS Global Accelerator Cuando el objetivo es un recurso de un grupo de protección, Shield Avanzado establece confianza para los demás recursos del grupo. Esto pone en alerta la detección de Shield Avanzado y puede reducir el tiempo necesario para crear mitigaciones adicionales.
Para obtener más información acerca de los grupos de protección, consulte [Agrupación de sus protecciones AWS Shield Advanced](ddos-protection-groups.md).
# Cómo AWS Shield mitiga los eventos
Esta página presenta cómo funciona la mitigación de AWS Shield eventos.
La lógica de mitigación que protege su aplicación puede variar en función de la arquitectura de su aplicación. Cuando protege una aplicación web con Amazon CloudFront y Amazon Route 53, se beneficia de las mitigaciones específicas de los casos de uso de la web y el DNS y que protegen todo el tráfico de los servicios. Cuando el punto de entrada de su aplicación es un recurso que se ejecuta en una AWS región, la lógica de mitigación varía en función del servicio, el tipo de recurso y el uso que haga del mismo. AWS Shield Advanced
AWS DDoLos ingenieros de Shield han desarrollado los sistemas de mitigación S y están estrechamente integrados con AWS los servicios. Los ingenieros tienen en cuenta aspectos de su arquitectura, como la capacidad y el estado de los recursos específicos. Los ingenieros de Shield supervisan continuamente la eficacia y el rendimiento de los sistemas de mitigación de DDo S y son capaces de responder rápidamente cuando se descubren o anticipan nuevas amenazas.
Puede diseñar su aplicación para que escale en respuesta a un tráfico o una carga elevados, a fin de garantizar que no se vea afectada por oleadas de solicitudes más pequeñas. Si usa Shield Advanced para proteger sus recursos, recibirá cobertura contra los aumentos inesperados en su factura de la nube que puedan producirse como resultado de un ataque DDo S.
**Mitigaciones de la infraestructura**
En el caso de los ataques a la capa de infraestructura, los sistemas de mitigación AWS Shield DDo S están presentes en los límites de la AWS red y en las ubicaciones AWS periféricas. La colocación de varios niveles de controles de seguridad en toda la AWS infraestructura proporciona defense-in-depth a sus aplicaciones en la nube.
Shield mantiene sistemas de mitigación DDo S en todos los puntos de entrada desde Internet. Cuando Shield detecta un ataque DDo S, para cada punto de entrada, redirige el tráfico a través de los sistemas de mitigación DDo S en la misma ubicación. Esto no introduce ninguna latencia adicional observable y proporciona una capacidad de mitigación de más de 100 TeraBits por segundo (Tbps) en todas AWS las regiones y ubicaciones periféricas. Shield protege la disponibilidad de sus recursos sin redirigir el tráfico a centros de depuración externos o remotos, lo que podría aumentar la latencia.
+ En el límite AWS de la red, para cualquier AWS servicio o recurso, DDo los sistemas de mitigación S mitigan los ataques a la capa de infraestructura procedentes de Internet. Los sistemas realizan sus mitigaciones cuando así lo indica la detección de Shield o un ingeniero del equipo de respuesta de Shield (SRT).
+ En las ubicaciones AWS periféricas, DDo los sistemas de mitigación S inspeccionan continuamente todos los paquetes que se reenvían a CloudFront las distribuciones de Amazon y a las zonas alojadas en Amazon Route 53, independientemente de su origen. Cuando es necesario, los sistemas aplican mitigaciones diseñadas específicamente para el tráfico web y de DNS. Una ventaja adicional de utilizar Amazon CloudFront y Amazon Route 53 para proteger sus aplicaciones web es que los ataques DDo S se mitigan inmediatamente, sin necesidad de una señal de detección de Shield.
**Mitigaciones en la capa de la aplicación**
Shield Advanced proporciona mitigaciones de la capa de aplicaciones web para las CloudFront distribuciones de Amazon y los balanceadores de carga de aplicaciones en las que has activado las protecciones de Shield Advanced. Cuando habilita la protección, asocia una ACL AWS WAF web al recurso para permitir la detección de la capa de aplicaciones web. Además, tiene la opción de habilitar la mitigación automática de la capa de aplicación, lo que indica a Shield Advanced que administre las protecciones por usted durante un ataque DDo S.
Shield solo ofrece mitigaciones personalizadas para ataques en la capa de aplicación en recursos en los que se haya activado Shield Avanzado y la mitigación automática de la capa de aplicación. Con la mitigación automática, Shield Advanced impone límites de AWS WAF velocidad a las solicitudes de fuentes DDo S conocidas y agrega y administra automáticamente AWS WAF protecciones personalizadas en respuesta a los ataques DDo S detectados. Para obtener información detallada sobre las mitigaciones de este tipo, consulte [Cómo administra Shield Avanzado la mitigación automática](ddos-automatic-app-layer-response-behavior.md).
Una regla basada en tasas en su ACL web, ya sea agregada por usted o por la característica de mitigación automática de la capa de aplicación de Shield Avanzado, puede mitigar un ataque antes de que alcance un nivel detectable. Para obtener más información acerca de la detección, consulte [Lógica de detección de amenazas de Shield Avanzado en la capa de aplicación (capa 7)](ddos-event-detection-application.md).
**Topics**
+ [Lista de funciones de mitigación de AWS Shield DDo S](ddos-event-mitigation-features.md)
+ [AWS Shield lógica de mitigación para CloudFront y Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield lógica de mitigación para AWS las regiones](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield lógica de mitigación para aceleradores AWS Global Accelerator estándar](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced lógica de mitigación para Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced lógica de mitigación para aplicaciones web](ddos-event-mitigation-logic-adv-web-app.md)
# Lista de funciones de mitigación de AWS Shield DDo S
Las principales características de la mitigación del AWS Shield DDo S son las siguientes:
+ **Validación de paquetes**: esto garantiza que cada paquete inspeccionado se ajuste a la estructura esperada y sea válido para su protocolo. Las validaciones de protocolo compatibles incluyen IP, TCP (incluidos el encabezado y las opciones), UDP, ICMP, DNS y NTP.
+ **Listas de control de acceso (ACLs) y modeladores**: una ACL evalúa el tráfico en función de atributos específicos y descarta el tráfico coincidente o lo asigna a un modelador. El modelador limita la velocidad de paquetes para el tráfico coincidente y elimina el exceso de paquetes para contener el volumen que llega al destino. AWS Shield Los ingenieros de detección y Shield Response Team (SRT) pueden proporcionar asignaciones de tarifas dedicadas al tráfico esperado y asignaciones de tarifas más restrictivas al tráfico con atributos que coincidan con los vectores de ataque DDo S conocidos. Los atributos que puede igualar una ACL incluyen el puerto, el protocolo, los indicadores TCP, la dirección de destino, el país de origen y los patrones arbitrarios de la carga útil del paquete.
+ **Puntuación de sospecha**: utiliza el conocimiento que Shield tiene sobre el tráfico esperado para aplicar una puntuación a cada paquete. A los paquetes que se ajustan más a los patrones de tráfico conocidos como seguros se les asigna una puntuación de sospecha más baja. La observación de los atributos de tráfico conocidos como maliciosos puede aumentar la puntuación de sospecha de un paquete. Cuando es necesario limitar la tasa de los paquetes, Shield descarta primero los paquetes con puntuaciones de sospecha más altas. Esto ayuda a Shield a mitigar los ataques DDo S conocidos y de día cero y, al mismo tiempo, evita los falsos positivos.
+ **Proxy TCP SYN**: proporciona protección contra las inundaciones de TCP SYN al enviar cookies TCP SYN para desafiar las nuevas conexiones antes de permitir que pasen al servicio protegido. El proxy TCP SYN que proporciona Shield DDo S Mitigation no tiene estado, lo que le permite mitigar los mayores ataques de inundación TCP SYN conocidos sin agotar el estado. Esto se logra mediante la integración con AWS los servicios para transferir el estado de la conexión en lugar de mantener un proxy continuo entre el cliente y el servicio protegido. El proxy TCP SYN está disponible actualmente en Amazon CloudFront y Amazon Route 53.
+ **Distribución de tasa**: ajusta continuamente los valores del modelador por ubicación según el patrón de entrada del tráfico hacia un recurso protegido. Esto evita limitar la velocidad del tráfico de clientes que podrían no ingresar a la AWS red de manera uniforme.
# AWS Shield lógica de mitigación para CloudFront y Route 53
En esta página, se explica cómo la mitigación de Shield DDo S inspecciona continuamente el tráfico en busca CloudFront de la Ruta 53. Estos servicios funcionan desde una red distribuida a nivel mundial de ubicaciones AWS periféricas que le proporcionan un amplio acceso a la capacidad de mitigación del tipo DDo S de Shield y distribuyen su aplicación desde una infraestructura más cercana a los usuarios finales.
**importante**
AWS Shield Advanced no es compatible con CloudFront los inquilinos.
+ **CloudFront**— Las mitigaciones de Shield DDo S solo permiten que el tráfico válido para las aplicaciones web pase al servicio. Esto proporciona protección automática contra muchos vectores DDo S comunes, como los ataques de reflexión UDP.
CloudFront mantiene las conexiones persistentes con el origen de la aplicación, las inundaciones de TCP SYN se mitigan automáticamente mediante la integración con la función de proxy TCP SYN Shield y Transport Layer Security (TLS) finaliza en la periferia. Estas funciones combinadas garantizan que el origen de la aplicación solo reciba solicitudes web bien formalizadas y que esté protegido contra los ataques DDo S de nivel inferior, las inundaciones de conexiones y el abuso del TLS.
CloudFront utiliza una combinación de dirección del tráfico DNS y enrutamiento anycast. Estas técnicas mejoran la resiliencia de su aplicación al mitigar los ataques cerca del origen, aislar las fallas y garantizar el acceso a la capacidad necesaria para mitigar los ataques más grandes conocidos.
+ **Route 53:** las mitigaciones de Shield solo permiten que las solicitudes de DNS válidas lleguen al servicio. Shield mitiga la avalancha de consultas de DNS mediante una puntuación de sospecha que prioriza las consultas que se sabe que son válidas y deja de priorizar las consultas que contienen atributos de ataque S sospechosos o conocidos. DDo
Route 53 utiliza la fragmentación aleatoria para proporcionar un conjunto único de cuatro direcciones IP de resolución a cada zona alojada, tanto para como para. IPv4 IPv6 Cada dirección IP corresponde a un subconjunto diferente de ubicaciones de Route 53. Cada subconjunto de ubicaciones consta de servidores DNS autorizados que solo se superponen parcialmente con la infraestructura de cualquier otro subconjunto. Esto garantiza que si la consulta de un usuario falla por cualquier motivo, se atenderá correctamente al volver a intentarlo.
Route 53 usa el enrutamiento anycast para dirigir las consultas de DNS a la ubicación periférica más cercana, en función de la proximidad de la red. Anycast también distribuye el tráfico DDo S a muchas ubicaciones periféricas, lo que evita que los ataques se centren en una sola ubicación.
Además de la velocidad de mitigación, CloudFront Route 53 ofrece un amplio acceso a la capacidad distribuida a nivel mundial de Shield. Para aprovechar estas capacidades, utilice estos servicios como punto de entrada para sus aplicaciones web dinámicas o estáticas.
Para obtener más información sobre el uso CloudFront de Route 53 para proteger las aplicaciones web, consulte [Cómo ayudar a proteger las aplicaciones web dinámicas contra los ataques DDo S mediante Amazon CloudFront y Amazon Route 53](https://aws.amazon.com/blogs/security/how-to-protect-dynamic-web-applications-against-ddos-attacks-by-using-amazon-cloudfront-and-amazon-route-53/). Para obtener más información sobre el aislamiento de fallas en Route 53, consulte [Un estudio de caso en el aislamiento global de fallas](https://aws.amazon.com/blogs/architecture/a-case-study-in-global-fault-isolation/).
# AWS Shield lógica de mitigación para AWS las regiones
En esta página, se explica cómo funciona la lógica de mitigación de eventos de Shield en AWS las regiones.
Los recursos que se lanzan en AWS las regiones están protegidos por sistemas de mitigación AWS Shield DDo S colocados mediante la detección a nivel de recursos de Shield. Los recursos regionales incluyen Elastic IPs (EIPs), Classic Load Balancers y Application Load Balancers.
Antes de implementar una mitigación, Shield identifica el recurso objetivo y su capacidad. Shield utiliza la capacidad para determinar el tráfico total máximo que sus mitigaciones deberían permitir que se reenvíe al recurso. Las listas de control de acceso (ACLs) y otros factores de configuración incluidos en la mitigación pueden reducir los volúmenes permitidos para parte del tráfico, por ejemplo, el tráfico que coincide con los vectores de ataque DDo S conocidos o que no se espera que tenga un gran volumen. Esto limita aun más la cantidad de tráfico que permiten las mitigaciones para ataques de reflexión UDP o para tráfico TCP que tiene indicadores TCP SYN o FIN.
Shield determina la capacidad y coloca las mitigaciones de forma diferente para cada tipo de recurso.
+ En el caso de una instancia Amazon EC2 o una EIP adjunta a una instancia de Amazon EC2, Shield calcula la capacidad en función del tipo de instancia y otros atributos de la instancia, como si la instancia tuviese habilitada la red mejorada.
+ En el caso de un Application Load Balancer o un Classic Load Balancer, Shield calcula la capacidad de forma individual para cada nodo objetivo del balanceador de cargas. DDoLas mitigaciones de los ataques S para estos recursos se proporcionan mediante una combinación de mitigaciones de Shield DDo S y el escalado automático mediante el balanceador de cargas. Cuando el equipo de respuesta de Shield (SRT) emprende un ataque contra un recurso de equilibrador de carga de aplicación o un equilibrador de carga clásico, es posible que acelere el escalado como medida de protección adicional.
+ Shield calcula la capacidad de algunos AWS recursos en función de la capacidad disponible de la AWS infraestructura subyacente. Estos tipos de recursos incluyen los balanceadores de carga de red (NLBs) y los recursos que enrutan el tráfico a través de los balanceadores de carga de puerta de enlace o. AWS Network Firewall
**nota**
Proteja sus balanceadores de carga de red conectándolos EIPs protegidos por Shield Advanced. Puede trabajar con SRT para crear mitigaciones personalizadas basadas en el tráfico esperado y la capacidad de la aplicación subyacente.
Cuando Shield aplica una mitigación, los límites de velocidad iniciales que Shield define en la lógica de mitigación se aplican por igual a todos los sistemas de mitigación de Shield DDo S. Por ejemplo, si Shield establece una mitigación con un límite de 100.000 paquetes por segundo (pps), inicialmente permitirá 100.000 pps en cada ubicación. Luego, Shield agrega continuamente métricas de mitigación para determinar la proporción real de tráfico y usa la proporción para adaptar el límite de tasa para cada ubicación. Esto evita los falsos positivos y garantiza que las mitigaciones no sean demasiado permisivas.
# AWS Shield lógica de mitigación para aceleradores AWS Global Accelerator estándar
En esta página, se explica cómo funciona la lógica de mitigación de eventos de Shield para los aceleradores AWS Global Accelerator estándar. Las mitigaciones de Shield permitirán que solo el tráfico válido llegue a los puntos de conexión oyentes de un acelerador estándar de Global Accelerator.
Los aceleradores estándar se implementan en todo el mundo y le proporcionan direcciones IP que puede usar para dirigir el tráfico a AWS los recursos de cualquier AWS región. Los límites de tasa que Shield aplica para mitigar el Global Accelerator se basan en las capacidades de los recursos a los que el acelerador estándar dirige el tráfico. Shield aplica mitigaciones cuando el tráfico total supera la velocidad determinada y también cuando se supera una fracción de esa velocidad en el caso de los vectores DDo S conocidos.
Cuando configura un acelerador estándar, define grupos de puntos de conexión para cada región de AWS a la que enrutará el tráfico de su aplicación. Cuando Shield coloca una mitigación, calcula la capacidad de cada grupo de puntos finales y actualiza los límites de velocidad en cada sistema de mitigación Shield DDo S en consecuencia. La tarifa varía para cada ubicación, según las suposiciones de Shield sobre cómo se enrutará el tráfico de Internet a sus AWS recursos. La capacidad de un grupo de puntos de conexión se calcula multiplicando la cantidad de recursos del grupo por la capacidad más baja de cualquier recurso del grupo. A intervalos regulares, Shield recalcula la capacidad de su aplicación y actualiza los límites de tasa según sea necesario.
**nota**
El uso de los diales de tráfico para cambiar el porcentaje de tráfico que se dirige a un grupo de puntos finales no cambia la forma en que Shield calcula o distribuye los límites de velocidad a sus sistemas de mitigación DDo S. Si usa controles de tráfico, configure sus grupos de puntos de conexión para que se reflejen entre sí en términos de tipo y cantidad de recursos. Esto ayuda a garantizar que la capacidad calculada por Shield sea representativa de los recursos que atienden el tráfico de su aplicación.
Para obtener más información sobre los grupos de puntos de conexión y los números de tráfico en Global Accelerator, consulte [Grupos de puntos de conexión en aceleradores estándar de AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups.html).
# AWS Shield Advanced lógica de mitigación para Elastic IPs
En esta página, se explica cómo funciona la lógica de mitigación de eventos de Shield para Elastic IPs with AWS Shield Advanced. Al proteger una IP elástica (EIP) con ella AWS Shield Advanced, Shield Advanced mejora las mitigaciones que Shield aplica durante un evento S. DDo
Los sistemas de mitigación Shield Advanced DDo S replican la configuración de ACL de red (NACL) para la subred pública a la que está asociada la EIP. Por ejemplo, si su NACL está configurada para bloquear todo el tráfico UDP, Shield Avanzado combina esa regla con las mitigaciones colocadas por Shield.
Esta funcionalidad adicional puede ayudarlo a evitar los riesgos de disponibilidad debido a un tráfico que no es válido para su aplicación. También se pueden utilizar NACLs para bloquear direcciones IP de origen individuales o rangos de CIDR de direcciones IP de origen. Esta puede ser una herramienta de mitigación útil para los ataques DDo S que no se distribuyen. También le permite administrar fácilmente sus propias listas de permitidos o bloquear las direcciones IP que no deberían comunicarse con su aplicación, sin depender de la intervención de los AWS ingenieros.
# AWS Shield Advanced lógica de mitigación para aplicaciones web
AWS Shield Advanced utiliza AWS WAF para mitigar los ataques a la capa de aplicaciones web. AWS WAF está incluido en Shield Advanced sin coste adicional.
**Protección estándar de la capa de aplicación**
Cuando proteges una CloudFront distribución de Amazon o un Application Load Balancer con Shield Advanced, puedes usar Shield Advanced para asociar una ACL AWS WAF web a tu recurso protegido, si aún no tienes una asociada. Si aún no ha configurado una ACL web, puede usar el asistente de consola de Shield Avanzado para crear una y agregarle una regla basada en tasas. Una regla basada en tasas limita el número de solicitudes por intervalo de cinco minutos para cada dirección IP, lo que proporciona protecciones básicas contra inundación de solicitudes de la capa de aplicaciones web. Puede configurar la tasa, empezando por 10. Para obtener más información, consulte [Protección de la capa de aplicaciones con AWS WAF web ACLs y Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
También puede utilizar el AWS WAF servicio para gestionar la ACL web. De este AWS WAF modo, puede ampliar la configuración de la ACL web para hacer cosas como inspeccionar componentes específicos de las solicitudes web para comprobar si coinciden con las cadenas o patrones, añadir un tratamiento personalizado de las solicitudes y las respuestas y compararlos con la geolocalización del origen de la solicitud. Para obtener más información sobre AWS WAF las reglas, consulte. [AWS WAF reglas](waf-rules.md)
**Mitigación automática en la capa de aplicación**
Para una protección mejorada, active la mitigación automática de la capa de aplicación Shield Avanzado. Con esta opción, Shield Advanced mantiene una regla AWS WAF de limitación de velocidad para las solicitudes de fuentes DDo S conocidas y proporciona mitigaciones personalizadas para los ataques DDo S detectados.
Cuando Shield Avanzado detecta un ataque a un recurso protegido, intenta identificar una firma de ataque que aísle el tráfico de ataque del tráfico normal a su aplicación. Shield Avanzado evalúa la firma del ataque identificada comparándola con los patrones de tráfico históricos del recurso que está siendo atacado, así como de cualquier otro recurso que esté asociado a la misma ACL web.
Si Shield Advanced determina que la firma del ataque aísla solo el tráfico implicado en el ataque DDo S, implementa la firma en AWS WAF las reglas de la ACL web asociada. Puede indicar a Shield Avanzado que coloque mitigaciones que solo cuenten el tráfico con el que coinciden o que lo bloqueen, y puede cambiar la configuración en cualquier momento. Cuando Shield Avanzado determina que sus reglas de mitigación ya no son necesarias, las elimina de la ACL web. Para obtener más información sobre la mitigación de eventos de la capa de aplicaciones, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
Para obtener más información sobre las mitigaciones de la capa de aplicación de Shield Avanzado, consulte [Proteger la capa de aplicación (capa 7) con AWS Shield Advanced y AWS WAF](ddos-app-layer-protections.md).
# Creación de arquitecturas resilientes básicas en DDo S con Shield Advanced
En esta página se explica la resistencia a la denegación de servicio (DDoS) distribuida y se presentan dos ejemplos de arquitecturas.
DDoLa resiliencia S es la capacidad de la arquitectura de su aplicación para resistir los ataques DDo S y, al mismo tiempo, seguir sirviendo a los usuarios finales legítimos. Una aplicación muy resistente puede permanecer disponible durante un ataque con un impacto mínimo en las métricas de rendimiento, como los errores o la latencia. En esta sección se muestran algunos ejemplos de arquitecturas comunes y se describe cómo utilizar las capacidades de detección y mitigación de DDo S que proporciona AWS y Shield Advanced para aumentar su resiliencia DDo S.
Los ejemplos de arquitecturas de esta sección destacan los AWS servicios que ofrecen las mayores ventajas de resiliencia DDo S para las aplicaciones implementadas. Algunas de las ventajas de los servicios destacados son las siguientes:
+ **Acceso a una capacidad de red distribuida a nivel mundial**: los servicios Amazon CloudFront y Amazon Route 53 le proporcionan acceso a Internet y a la capacidad de mitigación del DDo S en toda la red perimetral AWS global. AWS Global Accelerator Esto resulta útil para mitigar los ataques volumétricos más grandes, que pueden alcanzar una escala de terabits. Puede ejecutar su aplicación en cualquier AWS región y utilizar estos servicios para proteger la disponibilidad y optimizar el rendimiento de sus usuarios legítimos.
+ **Protección contra los vectores de ataque de la capa DDo S** de aplicaciones web: la mejor forma de mitigar los ataques de la capa DDo S de aplicaciones web es mediante una combinación de escala de aplicaciones y un firewall de aplicaciones web (WAF). Shield Advanced utiliza registros de inspección de solicitudes web AWS WAF para detectar anomalías que se pueden mitigar automáticamente o mediante la colaboración con el equipo de respuesta de AWS Shield (SRT). La mitigación automática está disponible a través de reglas AWS WAF basadas en tasas implementadas y también a través de la mitigación automática de la capa DDo S de aplicaciones Shield Advanced.
Además de revisar estos ejemplos, revise y siga las mejores prácticas aplicables en [AWS Best Practices for DDo S Resiliency.](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency)
**Topics**
+ [Ejemplo de arquitectura de resiliencia Shield Advanced DDo S para aplicaciones web comunes](ddos-resiliency-example-web.md)
+ [Ejemplo de arquitectura de resiliencia Shield Advanced DDo S para aplicaciones TCP y UDP](ddos-resiliency-example-tcp-udp.md)
# Ejemplo de arquitectura de resiliencia Shield Advanced DDo S para aplicaciones web comunes
Esta página proporciona un ejemplo de arquitectura para maximizar la resiliencia contra los ataques DDo S con aplicaciones web. AWS
Puede crear una aplicación web en cualquier AWS región y recibir protección automática contra el virus DDo S gracias a las funciones de detección y mitigación que AWS ofrece la región.
Este ejemplo es para arquitecturas que dirigen a los usuarios a una aplicación web mediante recursos como los Equilibradores de carga clásicos, Equilibradores de carga de aplicaciones, Equilibradores de carga de redes, soluciones Marketplace de AWS o su propia capa de proxy. Puede mejorar la resiliencia de DDo S insertando zonas alojadas de Amazon Route 53, CloudFront distribuciones de Amazon y AWS WAF sitios web ACLs entre estos recursos de aplicaciones web y sus usuarios. Estas inserciones pueden ocultar el origen de la aplicación, atender las solicitudes más cerca de los usuarios finales y detectar y mitigar la avalancha de solicitudes en la capa de aplicaciones. Las aplicaciones que ofrecen contenido estático o dinámico a sus usuarios con Route 53 están protegidas por un sistema de mitigación DDo S integrado CloudFront y totalmente integrado que mitiga los ataques a la capa de infraestructura en tiempo real.
Con estas mejoras arquitectónicas, podrá proteger sus zonas alojadas en Route 53 y sus CloudFront distribuciones con Shield Advanced. Al proteger CloudFront las distribuciones, Shield Advanced le pide que asocie la AWS WAF web ACLs y cree reglas basadas en tarifas para ellas, y le da la opción de habilitar la mitigación automática de la capa DDo S de aplicación o la participación proactiva. La interacción proactiva y la mitigación automática de la capa DDo S de aplicación utilizan las comprobaciones de estado de Route 53 que se asocian al recurso. Para obtener más información sobre estas opciones, consulte [Protecciones de recursos en AWS Shield Advanced](ddos-resource-protections.md).
El siguiente diagrama de referencia muestra esta arquitectura flexible DDo S para una aplicación web.
![\[El diagrama muestra un rectángulo titulado AWS cloud, con un grupo de usuarios a su izquierda. Dentro del rectángulo de la nube hay otros dos rectángulos, uno al lado del otro. El rectángulo izquierdo se denomina AWS Shield Advanced y el rectángulo derecho se denomina VPC. El AWS Shield Advanced triángulo de la izquierda contiene tres AWS iconos, apilados verticalmente. De arriba a abajo, los íconos son Amazon Route 53 CloudFront, Amazon y AWS WAF. El icono de CloudFront tiene flechas que van hacia y desde el icono de AWS WAF. El grupo de usuarios tiene una flecha que sale horizontalmente a su derecha y que se divide para señalar los íconos de Route 53 y CloudFront. A la derecha del rectángulo Shield Avanzado, el rectángulo de VPC contiene dos iconos que están uno al lado del otro. De izquierda a derecha, estos íconos son Elastic Load Balancing y Amazon Elastic Compute Cloud. El CloudFront icono tiene una flecha que sale horizontalmente a la derecha y va al icono de Elastic Load Balancing. El icono de Elastic Load Balancing tiene una flecha que sale horizontalmente a su derecha y va hacia el icono de Amazon EC2. Por lo tanto, las solicitudes de los usuarios se envían a Route 53 y CloudFront. CloudFront interactúa con el balanceador de cargas AWS WAF y también envía solicitudes al mismo, que a su vez envía solicitudes a Amazon EC2.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-resilient-web-app-arch.png)
Los beneficios que este enfoque proporciona a su aplicación web incluyen los siguientes:
+ Protección contra los ataques de nivel S de infraestructura (capa 3 y capa 4) que se utilizan con frecuencia, sin DDo demoras en la detección. Además, si un recurso es atacado con frecuencia, Shield Avanzado coloca las mitigaciones durante períodos de tiempo más largos. Shield Advanced también utiliza el contexto de la aplicación deducido de Network ACLs (NACLs) para bloquear el tráfico no deseado en sentido ascendente. Esto aísla las fallas más cerca de su origen, lo que minimiza el efecto en los usuarios legítimos.
+ Protección contra las inundaciones de TCP SYN. Los sistemas de mitigación DDo S que se integran con CloudFront Route 53 AWS Global Accelerator proporcionan una función de proxy TCP SYN que desafía los nuevos intentos de conexión y solo sirven a usuarios legítimos.
+ Protección contra los ataques a la capa de aplicaciones del DNS, ya que Route 53 es responsable de ofrecer respuestas de DNS fiables.
+ Protección contra las inundaciones de solicitudes en la capa de aplicaciones web. La regla basada en la velocidad que configuras en tu ACL AWS WAF web bloquea la fuente IPs cuando envía más solicitudes de las que permite la regla.
+ Mitigación automática de la capa DDo S de aplicación para sus CloudFront distribuciones, si decide habilitar esta opción. Con la mitigación automática de DDo S, Shield Advanced mantiene una regla basada en la tasa en la ACL AWS WAF web asociada a la distribución que limita el volumen de solicitudes de fuentes DDo S conocidas. Asimismo, cuando Shield Avanzado detecta un evento que afecta al estado de la aplicación, crea, prueba y administra automáticamente las reglas de mitigación en la ACL web.
+ Interacción proactiva con el Shield Response Team (SRT), si decide habilitar esta opción. Cuando Shield Avanzado detecta un evento que afecta al estado de su aplicación, el SRT responde e interactúa de forma proactiva con sus equipos de seguridad u operaciones utilizando la información de contacto que proporcione. El SRT analiza los patrones del tráfico y puede actualizar AWS WAF las reglas para bloquear el ataque.
# Ejemplo de arquitectura de resiliencia Shield Advanced DDo S para aplicaciones TCP y UDP
Este ejemplo muestra una arquitectura resiliente en DDo S para aplicaciones TCP y UDP en una AWS región que utiliza instancias de Amazon Elastic Compute Cloud (Amazon EC2) o direcciones IP elásticas (EIP).
Puede seguir este ejemplo general para mejorar la resiliencia de DDo S en los siguientes tipos de aplicaciones:
+ Aplicaciones TCP o UDP. Por ejemplo, las aplicaciones utilizadas para juegos, IoT y voz sobre IP.
+ Aplicaciones web que requieren direcciones IP estáticas o que utilizan protocolos que Amazon CloudFront no admite. Por ejemplo, es posible que tu aplicación requiera direcciones IP que los usuarios puedan añadir a sus listas de firewalls permitidas y que ningún otro AWS cliente utilice.
Puede mejorar la resiliencia de DDo S para estos tipos de aplicaciones introduciendo Amazon Route 53 y AWS Global Accelerator. Estos servicios pueden dirigir a los usuarios a su aplicación y pueden proporcionar a su aplicación direcciones IP estáticas que se enrutan con el método anycast a través de la red perimetral global de AWS . Los aceleradores estándar de Global Accelerator pueden mejorar la latencia de los usuarios hasta en un 60 %. Si tiene una aplicación web, puede detectar y mitigar las inundaciones de solicitudes de la capa de aplicaciones web ejecutando la aplicación en un Application Load Balancer y, a continuación, protegiendo el Application Load Balancer con AWS WAF una ACL web.
Una vez que haya creado la aplicación, proteja las zonas alojadas de Route 53, los aceleradores estándar de Global Accelerator y cualquier equilibrador de carga de aplicaciones con Shield Avanzado. Al proteger los balanceadores de carga de aplicaciones, puede asociarlos a la AWS WAF web ACLs y crear reglas basadas en la velocidad para ellos. Puede configurar la interacción proactiva con el SRT tanto para sus aceleradores estándar de Global Accelerator como para sus equilibradores de carga de aplicaciones asociando comprobaciones de estado de Route 53 nuevas o existentes. Para obtener más información sobre las opciones, consulte [Protecciones de recursos en AWS Shield Advanced](ddos-resource-protections.md).
El siguiente diagrama de referencia muestra un ejemplo DDo de arquitectura flexible para aplicaciones TCP y UDP.
![\[El diagrama muestra los usuarios conectados a Route 53 y a un AWS Global Accelerator. El acelerador está conectado a un icono de Elastic Load Balancing que está protegido por AWS Shield Advanced y AWS WAF. El equilibrador de carga Elastic está conectado a su vez a una instancia de Amazon EC2. Esta instancia de Elastic Load Balancing y la instancia de Amazon EC2 se encuentran en la región 1. También AWS Global Accelerator está conectado directamente a otra instancia de Amazon EC2, que no está detrás de una instancia protegida de Elastic Load Balancing. Esta segunda instancia de Amazon EC2 se encuentra en la región n.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-resilient-tcp-udp-app-arch.png)
Los beneficios que este enfoque proporciona a su aplicación incluyen los siguientes:
+ Protección contra los ataques a la capa de infraestructura más grande conocida (capa 3 y capa 4) DDo. Si el volumen de un ataque provoca congestión en las fases anteriores AWS, la falla se aislará más cerca de su origen y tendrá un efecto mínimo en los usuarios legítimos.
+ Protección contra los ataques a la capa de aplicaciones del DNS, ya que Route 53 es responsable de ofrecer respuestas de DNS fiables.
+ Si tiene una aplicación web, este enfoque proporciona protección contra las inundaciones de solicitudes en la capa de aplicaciones web. La regla basada en la velocidad que configuras en tu ACL AWS WAF web bloquea la fuente IPs mientras envía más solicitudes de las que permite la regla.
+ Interacción proactiva con el equipo de respuesta de Shield (SRT), si decide habilitar esta opción para los recursos elegibles. Cuando Shield Avanzado detecta un evento que afecta al estado de su aplicación, el SRT responde e interactúa de forma proactiva con sus equipos de seguridad u operaciones utilizando la información de contacto que proporcione.
# Combinación de Shield Advanced con otros Servicios de AWS
Puede utilizar Shield Avanzado para proteger sus recursos en muchos tipos de situaciones. Sin embargo, en algunos casos, debe utilizar otros servicios o combinar otros servicios con Shield Avanzado para ofrecer la mejor protección. Los siguientes son ejemplos de cómo usar Shield Advanced u otros AWS servicios para ayudar a proteger sus recursos.
| Objetivo | Servicios sugeridos | Documentación del servicio relacionada |
| --- | --- | --- |
| Proteja una aplicación web y RESTful APIs contra un ataque DDo S | Shield Advanced protege una CloudFront distribución de Amazon y un Application Load Balancer | Documentación de [Elastic Load Balancing, CloudFront documentación](https://docs.aws.amazon.com/elasticloadbalancing/) [de Amazon](https://docs.aws.amazon.com/cloudfront/) |
| Proteja una aplicación basada en TCP contra un ataque S DDo | Shield Advanced protege un acelerador AWS Global Accelerator estándar; se adjunta a una dirección IP elástica | [AWS Global Accelerator Documentación, documentación](https://docs.aws.amazon.com/global-accelerator/) de [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/) |
| Proteja un servidor de juegos basado en UDP contra un ataque S DDo | Shield Advanced: protección de una EC2 instancia de Amazon conectada a una dirección IP elástica | [Documentación de Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/ec2/) |
Por ejemplo, si usa Shield Avanzado para proteger una dirección IP elástica, Shield Avanzado protege cualquier recurso que esté asociado a ella. Durante un ataque, Shield Advanced despliega automáticamente la red ACLs en el borde de la AWS red. Cuando su red ACLs se encuentra en el límite de la red, Shield Advanced puede brindar protección contra eventos DDo S más grandes. Por lo general, la red ACLs se aplica cerca de EC2 las instancias de Amazon dentro de la VPC de Amazon. La ACL de red puede mitigar ataques tan grandes como el volumen que puedan gestionar la instancia y Amazon VPC. Si la interfaz de red conectada a tu EC2 instancia de Amazon puede procesar hasta 10 Gbps, los volúmenes de más de 10 Gbps se ralentizan y, posiblemente, bloquean el tráfico a esa instancia. Durante un ataque, Shield Avanzado promueve la ACL de red a la frontera de AWS , lo que permite procesar varios terabytes de tráfico. Su ACL de red puede proporcionar protección a sus recursos más allá de la capacidad normal de su red. [Para obtener más información sobre la red ACLs, consulta Red. ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html)
# Con AWS Shield Advanced figuración
En este tutorial se explica cómo empezar a AWS Shield Advanced utilizar la consola Shield Advanced.
**nota**
Shield Advanced requiere una suscripción, pero AWS Shield Standard no la necesita. Las protecciones proporcionadas por Shield Standard están disponibles de forma gratuita para todos los clientes de AWS .
Shield Advanced proporciona una protección avanzada de detección y mitigación de DDo S para ataques de capa de red (capa 3), capa de transporte (capa 4) y capa de aplicación (capa 7). Para obtener más información sobre Shield Avanzado, consulte [Descripción general de AWS Shield Advanced](ddos-advanced-summary.md).
La comunidad AWS técnica ha publicado un ejemplo de un proceso automatizado para configurar Shield Advanced utilizando las herramientas de infraestructura como código (IaC) AWS CloudFormation y Terraform. Puede utilizarla AWS Firewall Manager con esta solución si sus cuentas forman parte de una organización AWS Organizations y si está protegiendo algún tipo de recurso, excepto Amazon Route 53 o AWS Global Accelerator. [Para explorar esta opción, consulte el repositorio de código en [aws-samples/ aws-shield-advanced-one-click-deployment y el tutorial en One-click deployment](https://github.com/aws-samples/aws-shield-advanced-one-click-deployment) of Shield Advanced.](https://youtu.be/LCA3FwMk_QE)
**nota**
Es importante que configure completamente Shield Advanced antes de que se produzca un evento de denegación de servicio (DDoS) distribuida. Complete la configuración para garantizar que su aplicación esté protegida y que esté preparado para responder en caso de que su aplicación se vea afectada por un ataque DDo S.
Siga los siguientes pasos en orden para empezar a utilizar Shield Avanzado.
**Contents**
+ [Suscribirse a AWS Shield Advanced](enable-ddos-prem.md)
+ [Cómo agregar y configurar protecciones de recursos con Shield Avanzado](ddos-choose-resources.md)
+ [Configuración de las protecciones de la capa de aplicación (capa 7) DDo S con AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Configuración de la detección basada en el estado para las protecciones con Shield Avanzado y Route 53](ddos-get-started-health-checks.md)
+ [Configuración de alarmas y notificaciones con Shield Avanzado y Amazon SNS](ddos-get-started-create-alarms.md)
+ [Revisión y finalización de la configuración de protección en Shield Avanzado](ddos-get-started-review-and-configure.md)
+ [Configuración del soporte AWS del Shield Response Team (SRT) para la respuesta a eventos DDo S](authorize-srt.md)
+ [Creación de un panel DDo S CloudWatch y configuración de CloudWatch alarmas](deploy-waf-dashboard.md)
# Suscribirse a AWS Shield Advanced
En esta página se explica cómo suscribir sus cuentas a Shield Avanzado para empezar a utilizar el servicio.
Debe suscribirse a Shield Advanced para cada uno de los productos Cuenta de AWS que desee proteger. No es necesario suscribirse a Shield Standard.
**Facturación de suscripciones de Shield Avanzado**
Si es distribuidor de AWS canales, póngase en contacto con su equipo de cuentas para obtener información y orientación. Esta información de facturación es para clientes que no son distribuidores de AWS canal.
Para todos los demás, se aplican las siguientes pautas de suscripción y facturación:
+ En el caso de las cuentas que son miembros de una AWS Organizations organización, AWS factura las suscripciones de Shield Advanced a la cuenta de pagador de la organización, independientemente de si la propia cuenta de pagador está suscrita.
+ Al suscribir varias cuentas que pertenezcan a la misma [familia de cuentas de facturación de AWS Organizations consolidada](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html), un único precio de suscripción cubre todas las cuentas suscritas de la familia. La organización debe ser propietaria de todas las Cuentas de AWS y de todos sus recursos.
+ Si suscribe varias cuentas para varias organizaciones, puede seguir pagando una única cuota de suscripción para todas las organizaciones, cuentas y recursos, siempre que sea el propietario de todos ellos. Póngase en contacto con su administrador de cuentas o con el servicio de AWS asistencia y solicite una exención de las tarifas de AWS Shield Advanced suscripción para todas las organizaciones excepto una.
Para obtener ejemplos e información detallada sobre precios, consulte [Precios de AWS Shield](https://aws.amazon.com/shield/pricing/).
**Considere la posibilidad de simplificar las suscripciones con AWS Firewall Manager**
Si sus cuentas forman parte de una organización, le recomendamos que utilice AWS Firewall Manager si puede, para automatizar las suscripciones y las protecciones de la organización. Firewall Manager admite todos los tipos de recursos protegidos, excepto Amazon Route 53 y AWS Global Accelerator. Para usar Firewall Manager, consulte [AWS Firewall Manager](fms-chapter.md) y [Configuración de AWS Firewall Manager AWS Shield Advanced políticas](getting-started-fms-shield.md).
Si no usa el Firewall Manager, suscríbase y agregue protecciones para cada cuenta con recursos que proteger mediante los siguientes procedimientos.
**Para suscribir una cuenta a AWS Shield Advanced**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En la barra de navegación de **AWS Shield**, seleccione **Introducción**. Seleccione **Suscribirse a Shield Avanzado**.
1. En la página **Suscribirse a Shield Avanzado**, lea cada término del acuerdo y, a continuación, marque todas las casillas de verificación para indicar que acepta los términos. En el caso de una familia de facturación consolidada, debe aceptar los términos de cada cuenta.
**importante**
Cuando esté suscrito, para cancelar la suscripción, debe ponerse en contacto con [AWS Support](https://console.aws.amazon.com/support).
[Para deshabilitar la renovación automática de su suscripción, debe usar la operación Shield API o el comando de CLI [UpdateSubscription](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_UpdateSubscription.html)update-subscription.](https://docs.aws.amazon.com/cli/latest/reference/shield/update-subscription.html)
Seleccione **Suscribirse a Shield Avanzado**. De este modo suscribe su cuenta a Shield Avanzado y activa el servicio.
Su cuenta está suscrita. Siga estos pasos para proteger los recursos de su cuenta con Shield Avanzado.
**nota**
Shield Avanzado no protege automáticamente los recursos después de suscribirse. Debe especificar los recursos que desea que Shield Avanzado proteja.
# Cómo agregar y configurar protecciones de recursos con Shield Avanzado
En esta página, se proporcionan instrucciones para agregar y configurar la protección para sus recursos.
Shield Avanzado solo protege los recursos que se especifiquen, ya sea mediante Shield Avanzado o en una política Shield Advanced de Firewall Manager. No protege automáticamente los recursos de una cuenta suscrita.
**nota**
Si utilizas una póliza AWS Firewall Manager Shield Advanced para tus protecciones, no necesitas realizar este paso. La política se configura con los tipos de recursos que se van a proteger y Firewall Manager agrega automáticamente protecciones a los recursos que se encuentren dentro del ámbito de la política.
Si no usa Firewall Manager, siga los siguientes procedimientos para toda cuenta donde tenga recursos que proteger.
**Elección de los recursos que se van a proteger con Shield Avanzado**
1. Seleccione **Agregar recursos que se protegerán** en la página de confirmación de la suscripción del procedimiento anterior o en la página **Recursos protegidos** u **Información general**.
1. En la página **Elegir los recursos que se protegerán con Shield Avanzado**, en **Especificar la región y los tipos de recursos**, proporcione las especificaciones de región y de tipo de recurso de los recursos que desea proteger. Puede proteger los recursos de varias regiones seleccionando **Todas las regiones** y puede limitar la selección a los recursos globales seleccionando **Global**. Puede deseleccionar cualquier tipo de recurso que no desee proteger. Para obtener información sobre las protecciones de sus tipos de recursos, consulte [Lista de recursos que AWS Shield Advanced protegen](ddos-protections-by-resource-type.md).
1. Elija **Cargar recursos**. Shield Avanzado rellena la sección **Seleccionar recursos** con los recursos de AWS que coinciden con sus criterios.
1. En la sección **Seleccionar recursos**, puede filtrar la lista de recursos introduciendo una cadena para buscarla en las listas de recursos.
Seleccione los recursos que desea proteger.
1. En la sección **Etiquetas**, si desea agregar etiquetas a las protecciones Shield Avanzado que está creando, especifíquelas. Para obtener información acerca de cómo etiquetar los recursos de AWS , consulte [Uso de Tag Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).
1. Elija **Proteger con Shield Avanzado**. Esto agrega las protecciones de Shield Avanzado a los recursos.
Continúe recorriendo las pantallas del asistente de la consola para completar la configuración de las protecciones de sus recursos.
**Topics**
+ [Configuración de las protecciones de la capa de aplicación (capa 7) DDo S con AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Configuración de la detección basada en el estado para las protecciones con Shield Avanzado y Route 53](ddos-get-started-health-checks.md)
+ [Configuración de alarmas y notificaciones con Shield Avanzado y Amazon SNS](ddos-get-started-create-alarms.md)
+ [Revisión y finalización de la configuración de protección en Shield Avanzado](ddos-get-started-review-and-configure.md)
# Configuración de las protecciones de la capa de aplicación (capa 7) DDo S con AWS WAF
Esta página proporciona instrucciones para configurar las protecciones de la capa de aplicación con la AWS WAF web ACLs.
Para proteger un recurso de la capa de aplicación, Shield Advanced utiliza una ACL AWS WAF web con una regla basada en la velocidad como punto de partida. AWS WAF es un firewall de aplicaciones web que permite supervisar las solicitudes HTTP y HTTPS que se reenvían a los recursos de la capa de aplicaciones y controlar el acceso al contenido en función de las características de las solicitudes. Una regla basada en la velocidad limita el volumen de tráfico en función de los criterios de agregación de solicitudes, lo que proporciona DDo una protección S básica a la aplicación. Para obtener más información, consulte [Cómo AWS WAF funciona](how-aws-waf-works.md) y [Uso de declaraciones de reglas basadas en tasas en AWS WAF](waf-rule-statement-type-rate-based.md).
Si lo desea, también puede activar la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced, para recibir solicitudes de límite de velocidad de Shield Advanced procedentes de fuentes DDo S conocidas y proporcionarle automáticamente protecciones específicas para cada incidente.
**importante**
Si administra sus protecciones de Shield Advanced AWS Firewall Manager mediante una política de Shield Advanced, no podrá administrar las protecciones de la capa de aplicación aquí. Debe administrarlas en su política de Shield Avanzado de Firewall Manager.
**Suscripciones y AWS WAF costos de Shield Advanced**
Su suscripción a Shield Advanced cubre los costes de uso de AWS WAF las capacidades estándar para los recursos que proteja con Shield Advanced. Las AWS WAF tarifas estándar que cubren las protecciones Shield Advanced son el costo por paquete de protección (ACL web), el costo por regla y el precio base por millón de solicitudes de inspección de solicitudes web, hasta 1500 WCUs y hasta el tamaño corporal predeterminado.
Al habilitar la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced, se añade un grupo de reglas al paquete de protección (ACL web) que utiliza 150 unidades de capacidad de ACL web (WCUs). Esto se WCUs descuenta del uso de la WCU en su paquete de protección (ACL web). Para obtener más información, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md), [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md) y [Unidades de capacidad de ACL web (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Su suscripción a Shield Advanced no cubre el uso AWS WAF de recursos que no proteja con Shield Advanced. Tampoco cubre ningún AWS WAF coste adicional no estándar de los recursos protegidos. Algunos ejemplos de AWS WAF costes no estándar son los del control de bots, la acción de la CAPTCHA regla, la web ACLs que utiliza más de 1500 WCUs usuarios y la inspección del cuerpo de la solicitud por encima del tamaño predeterminado. La lista completa se encuentra en la página de AWS WAF precios. Su suscripción a Shield Advanced incluye el acceso al grupo de reglas gestionadas por Amazon DDo Anti-S de capa 7. Como parte de su suscripción, recibirá hasta 50 000 millones de solicitudes a los AWS WAF recursos protegidos de Shield Advanced en un mes natural. Las solicitudes superiores a 50 000 millones se facturarán según la página de AWS Shield Advanced precios.
Para obtener la información completa y ejemplos de precios, consulte [Precios de Shield](https://aws.amazon.com/shield/pricing/) y [Precios de AWS WAF](https://aws.amazon.com/waf/pricing/).
**Para configurar las protecciones de capa 7 DDo S para una región**
Shield Advanced le ofrece la opción de configurar la mitigación de capa 7 DDo S para cada región en la que se encuentren los recursos que elija. Si va a agregar protecciones en varias regiones, el asistente le guiará por el siguiente procedimiento para cada región.
1. La página **Configurar las protecciones de la capa 7 DDo S** muestra todos los recursos que aún no están asociados a una ACL web. Para cada uno de ellos, elija una ACL web existente o cree una ACL web nueva. En el caso de cualquier recurso que ya tenga una ACL web asociada, puede cambiar de web ACLs desasociando primero la ACL actual mediante ella. AWS WAF Para obtener más información, consulte [Asociar o disociar la protección a un recurso AWS](web-acl-associating-aws-resource.md).
En el caso de sitios web ACLs que aún no tengan una regla basada en la velocidad, el asistente de configuración le pedirá que agregue una. Una regla basada en tasas limita el tráfico de las direcciones IP cuando estas envían un gran volumen de solicitudes. Las reglas basadas en tarifas ayudan a proteger tu aplicación contra la avalancha de solicitudes web y pueden proporcionar alertas sobre picos repentinos de tráfico que podrían indicar un posible ataque S. DDo Para agregar una regla basada en tasas a una ACL web, seleccione **Agregar regla de límite de tasas** y, a continuación, especifique una acción para limitar la tasa y establecer una regla. Puede configurar protecciones adicionales en la ACL web mediante. AWS WAF
Para obtener información sobre el uso de reglas web ACLs y basadas en tarifas en sus protecciones Shield Advanced, incluidas las opciones de configuración adicionales para las reglas basadas en tarifas, consulte. [Protección de la capa de aplicaciones con AWS WAF web ACLs y Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md)
1. Para la **mitigación automática de la capa de aplicación DDo S**, si desea que Shield Advanced mitigue automáticamente los ataques DDo S contra los recursos de la capa de aplicación, elija **Activar** y, a continuación, seleccione la acción de AWS WAF regla que quiere que Shield Advanced utilice en sus reglas personalizadas. Esta configuración se aplica a toda la web ACLs para los recursos que gestione en esta sesión del asistente.
Con la mitigación automática de la capa DDo S de aplicación, Shield Advanced mantiene una regla basada en la tasa en la ACL AWS WAF web del recurso que limita el volumen de solicitudes de fuentes DDo S conocidas. Además, Shield Advanced compara los patrones de tráfico actuales con las líneas de base de tráfico históricas para detectar desviaciones que puedan indicar un ataque DDo S. Cuando Shield Advanced detecta un ataque DDo S, responde creando, evaluando e implementando AWS WAF reglas personalizadas para responder. Especifique si las reglas personalizadas cuentan o bloquean los ataques en su nombre.
**nota**
La mitigación automática de la capa de aplicación DDo S solo funciona con los paquetes de protección (web ACLs) que se crearon con la última versión de AWS WAF (v2).
Para obtener más información sobre la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced, incluidas las advertencias y las mejores prácticas para el uso de esta función, consulte[Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
1. Elija **Siguiente**. El asistente de la consola pasa a la página de detección basada en el estado.
# Configuración de la detección basada en el estado para las protecciones con Shield Avanzado y Route 53
En esta página se incluyen las instrucciones para configurar Shield Avanzado para que utilice la detección basada en el estado. Esto puede ayudar a mejorar la capacidad de respuesta y la precisión en la detección y la mitigación de ataques.
Para lograr una detección precisa de los eventos, es esencial que las comprobaciones de estado estén bien configuradas. Puede configurar la detección basada en el estado para cualquier tipo de recurso, excepto para las zonas alojadas en Route 53.
Para utilizar la detección basada en el estado, defina una comprobación de estado para su recurso en Route 53 y luego, asocie la comprobación de estado con su protección de Shield Avanzado. Es importante que la comprobación de estado que configure refleje con precisión el estado del recurso. Para obtener información y ejemplos sobre cómo configurar las comprobaciones de estado para utilizarlas con Shield Avanzado, consulte [Detección basada en el estado mediante comprobaciones de estado con Shield Avanzado y Route 53](ddos-advanced-health-checks.md).
Se requieren comprobaciones de estado para poder contar con el apoyo proactivo del equipo de respuesta de Shield (SRT). Para obtener información sobre la interacción proactiva, consulte [Configuración de una interacción proactiva para que el SRT se ponga en contacto con usted directamente](ddos-srt-proactive-engagement.md).
**nota**
Las comprobaciones de estado deben declararse en buen estado cuando las asocie a sus protecciones de Shield Avanzado.
**Configuración de una detección basada en el estado**
1. En **Associated Health Check (Comprobación de estado asociada)**, elija el identificador de la comprobación de estado que desea asociar a la protección.
**nota**
Si no ve la comprobación de estado que necesita, vaya a la consola de Route 53 y verifique la comprobación de estado y su ID. Para obtener más información, consulte [Creación y actualización de comprobaciones de estado](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html).
1. Elija **Siguiente**. El asistente de la consola pasa a la página de alarmas y notificaciones.
# Configuración de alarmas y notificaciones con Shield Avanzado y Amazon SNS
En esta página se proporcionan instrucciones para configurar de forma opcional las notificaciones de Amazon Simple Notification Service para las CloudWatch alarmas de Amazon detectadas y la actividad de las reglas basadas en tasas. Puede utilizarlos para recibir notificaciones cuando Shield detecte un evento en un recurso protegido o cuando se supere un límite de tasa configurado en una regla basada en tasas.
Para obtener información sobre las CloudWatch métricas de Shield Advanced, consulte[AWS Shield Advanced métricas](shield-metrics.md). Para obtener información sobre Amazon SNS, consulte la [Guía para desarrolladores de Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/).
**Configuración de alarmas y notificaciones**
1. Seleccione los temas de Amazon SNS para los que desea recibir notificaciones. Puede usar un solo tema de Amazon SNS para todos los recursos protegidos y las reglas basadas en tasas, o puede elegir diferentes temas, personalizados para su organización. Por ejemplo, puede crear un tema de SNS para cada equipo responsable de la respuesta a incidentes para un conjunto específico de recursos.
1. Elija **Siguiente**. El asistente de la consola pasa a la página de revisión de la protección de recursos.
# Revisión y finalización de la configuración de protección en Shield Avanzado
**Para revisar y finalizar la configuración**
1. En la página **Revisar y configurar la mitigación y la visibilidad de DDo S**, revise sus ajustes. Para realizar modificaciones, elija **Editar** en el área que desee modificar. Esto lo lleva de vuelta a la página asociada del asistente de consola. Realice los cambios y, a continuación, seleccione **Siguiente** en las páginas siguientes hasta que vuelva a la página **Revisar y configurar la mitigación y la visibilidad de DDo S.**
1. Seleccione **Finalizar la configuración**. La página **Recursos protegidos** muestra los recursos recién protegidos.
# Configuración del soporte AWS del Shield Response Team (SRT) para la respuesta a eventos DDo S
Esta página proporciona instrucciones para configurar el soporte del equipo de respuesta de Shield (SRT).
El SRT incluye ingenieros de seguridad que se especializan en la respuesta a DDo los eventos S. Si lo desea, puede añadir permisos que le permitan al SRT gestionar los recursos en su nombre durante un evento DDo S. Además, puede configurar el SRT para que interactúe con usted de forma proactiva si las comprobaciones de estado de Route 53 asociadas a sus recursos protegidos no funcionan correctamente durante un evento detectado. Estas dos incorporaciones a sus protecciones permiten responder más rápidamente a DDo los eventos S.
**nota**
Para utilizar los servicios del equipo de respuesta de Shield (SRT), debe haberse registrado en el [plan de soporte Business](https://aws.amazon.com/premiumsupport/business-support/) o en el [plan de soporte Enterprise](https://aws.amazon.com/premiumsupport/enterprise-support/).
El SRT puede monitorear los datos y registros de las AWS WAF solicitudes durante los eventos de la capa de aplicación para identificar el tráfico anómalo. Pueden ayudar a elaborar AWS WAF reglas personalizadas para mitigar las fuentes de tráfico infractoras. Según sea necesario, el SRT podría hacer recomendaciones de arquitectura para ayudarlo a alinear mejor sus recursos con AWS las recomendaciones.
Para obtener más información sobre la SRT, consulte [Respuesta a eventos DDo S gestionada con el soporte del Shield Response Team (SRT)](ddos-srt-support.md).
**Cómo conceder permisos al SRT**
1. En la página de **descripción general** de la AWS Shield consola, en **Configurar la compatibilidad con AWS SRT**, selecciona **Editar el acceso a SRT**. Se abre la página de **acceso al equipo de respuesta de Edit AWS Shield (SRT)**.
1. Para **Configuración de acceso de SRT**, seleccione una de las siguientes opciones:
+ **No conceder al SRT acceso a mi cuenta**: Shield elimina cualquier permiso que se haya otorgado anteriormente al SRT para acceder a su cuenta y sus recursos.
+ **Crear un nuevo rol para que el SRT acceda a mi cuenta**: Shield crea un rol que confía en la entidad principal del servicio `drt.shield.amazonaws.com`, que representa al SRT, y le asocia la política administrada `AWSShieldDRTAccessPolicy`. La política gestionada permite al SRT realizar AWS Shield Advanced llamadas a la AWS WAF API en tu nombre y acceder a tus AWS WAF registros. Para obtener más información sobre la política administrada, consulte [AWS política gestionada: AWSShield DRTAccess política](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
+ **Elija un rol existente para que el SRT pueda acceder a mis cuentas**. Para elegir esta opción, debe modificar la configuración del rol en AWS Identity and Access Management (IAM) de la siguiente manera:
+ Asocie la política `AWSShieldDRTAccessPolicy` administrada al rol. Esta política gestionada permite al SRT realizar AWS Shield Advanced llamadas a la AWS WAF API en tu nombre y acceder a tus registros. AWS WAF Para obtener más información sobre la política administrada, consulte [AWS política gestionada: AWSShield DRTAccess política](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). Para obtener información sobre cómo asociar la política administrada a su rol, consulte [Cómo asociar y desasociar políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+ Modifique el rol para confiar en la entidad principal de servicio `drt.shield.amazonaws.com`. Esta es la entidad principal de servicio que representa el SRT. Para obtener más información, consulte [Elemento de la política de JSON de IAM: Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
1. Elija **Guardar** para guardar los cambios.
Para obtener más información sobre cómo permitir que el SRT acceda a sus protecciones y datos, consulte [Concesión del acceso al SRT](ddos-srt-access.md).
**Habilitación de la interacción proactiva de SRT**
1. En la página de **información general** de la AWS Shield consola, en **Interacción proactiva y contactos**, en el área de contactos, selecciona **Editar**.
En la página **Editar contactos**, proporcione la información de contacto de las personas con las que desea que el SRT se ponga en contacto para tener una interacción proactiva.
Si proporciona más de un contacto, en **Notas**, indique las circunstancias en las que debe utilizarse cada contacto. Incluya las designaciones de los contactos principales y secundarios y proporcione los horarios de disponibilidad y las zonas horarias de cada contacto.
Ejemplos de notas de contacto:
+ Esta es una línea directa que cuenta con personal las 24 horas del día, todos los días de la semana, todos los días del año. Trabaje con el analista que le responda, le dirigirá a la persona adecuada en la llamada.
+ Póngase en contacto conmigo si la línea directa no responde en 5 minutos.
1. Seleccione **Save (Guardar)**.
La página **Información general** refleja la información de contacto actualizada.
1. Seleccione **Editar característica de interacción proactiva**, seleccione **Habilitar** y, a continuación, seleccione **Guardar** para habilitar la interacción proactiva.
Para obtener más información sobre la interacción proactiva, consulte [Configuración de una interacción proactiva para que el SRT se ponga en contacto con usted directamente](ddos-srt-proactive-engagement.md).
# Creación de un panel DDo S CloudWatch y configuración de CloudWatch alarmas
En esta página, se proporcionan instrucciones para crear un panel DDo S CloudWatch y configurar CloudWatch las alarmas.
Puedes monitorizar la posible actividad de DDo S con Amazon CloudWatch, que recopila datos sin procesar de Shield Advanced y los procesa en métricas legibles prácticamente en tiempo real. Puede utilizar las estadísticas CloudWatch para obtener una perspectiva del rendimiento de su aplicación o servicio web. Para obtener más información sobre el uso CloudWatch, consulta [Qué hay CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) en la *Guía del CloudWatch usuario de Amazon*.
+ Para obtener instrucciones sobre cómo crear un CloudWatch panel de control, consulte[Monitorización con Amazon CloudWatch](monitoring-cloudwatch.md).
+ Para obtener descripciones de las métricas de Shield Avanzado que puede agregar a su panel, consulte [AWS Shield Advanced métricas](shield-metrics.md).
Shield Advanced informa de las métricas de recursos con CloudWatch más frecuencia durante los eventos DDo S que cuando no hay ningún evento en curso. Shield Avanzado informa de las métricas una vez por minuto durante un evento y, después, una vez finalizado el evento. Aunque no haya eventos en curso, Shield Avanzado notifica las métricas una vez al día, a una hora asignada al recurso. Este informe periódico mantiene las métricas activas y disponibles para usarlas en tus CloudWatch alarmas personalizadas.
Con esto se completa el tutorial de introducción a Shield Avanzado. Para aprovechar al máximo las protecciones que ha elegido, siga explorando las características y opciones de Shield Avanzado. Para empezar, familiarícese con las opciones para ver y responder a los eventos en [Visibilidad de DDo los eventos S con Shield Advanced](ddos-viewing-events.md) y [Respondiendo a DDo los eventos S en AWS](ddos-responding.md).
# Respuesta a eventos DDo S gestionada con el soporte del Shield Response Team (SRT)
En esta página se describe la función del equipo de respuesta de Shield (SRT).
El SRT brinda asistencia adicional a los clientes de Shield Avanzado. Los SRT son ingenieros de seguridad que se especializan en la respuesta a DDo un evento S. Como capa de apoyo adicional a su plan de AWS Support , puede trabajar directamente con el SRT y aprovechar su experiencia como parte de su flujo de trabajo de respuesta a eventos. Para obtener información acerca de las opciones y las instrucciones de configuración, consulte los siguientes temas.
**nota**
Para utilizar los servicios del equipo de respuesta de Shield (SRT), debe haberse registrado en el [plan de soporte Business](https://aws.amazon.com/premiumsupport/business-support/) o en el [plan de asistencia Enterprise](https://aws.amazon.com/premiumsupport/enterprise-support/).
El equipo de respuesta de Shield (SRT) presta servicios en las regiones en las que Shield Advanced está disponible y a los clientes de GovCloud las regiones (EE. UU. Este) y AWS GovCloud AWS GovCloud (EE. UU. Oeste).
**Actividades de asistencia del SRT**
El objetivo principal de una interacción con el SRT es proteger la disponibilidad y el rendimiento de su aplicación. Según el tipo de evento DDo S y la arquitectura de su aplicación, el SRT puede realizar una o más de las siguientes acciones:
+ **AWS WAF reglas y análisis de registros**: en el caso de los recursos que utilizan una ACL AWS WAF web, el SRT puede analizar AWS WAF los registros para identificar las características de los ataques en las solicitudes web de las aplicaciones. Con su aprobación durante la interacción, el SRT puede aplicar cambios a su ACL web para bloquear los ataques que haya identificado.
+ **Crear mitigaciones de red personalizadas**: el SRT puede crear mitigaciones personalizadas para los ataques a la capa de infraestructura. El SRT puede ayudarlo a comprender el tráfico esperado para su aplicación, bloquear el tráfico inesperado y optimizar los límites de velocidad de paquetes por segundo. Para obtener más información, consulte [Configuración de mitigaciones personalizadas contra los ataques DDo S con el SRT](ddos-srt-custom-mitigations.md).
+ **Ingeniería de tráfico de red**: el SRT trabaja en estrecha colaboración con los equipos de AWS redes para proteger a los clientes de Shield Advanced. Cuando sea necesario, AWS puede cambiar la forma en que el tráfico de Internet llega a la AWS red para asignar más capacidad de mitigación a su aplicación.
+ **Recomendaciones de arquitectura**: el SRT puede determinar que la mejor mitigación de un ataque requiere cambios en la arquitectura para alinearlos mejor con las AWS mejores prácticas, y ayudarán a respaldar la implementación de estas prácticas. Para obtener más información, consulte [las AWS mejores prácticas para la resiliencia de DDo los Estados Unidos.](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency)
Las siguientes secciones incluyen instrucciones sobre cómo interactuar con el SRT
**Topics**
+ [Concesión del acceso al SRT](ddos-srt-access.md)
+ [Configuración de una interacción proactiva para que el SRT se ponga en contacto con usted directamente](ddos-srt-proactive-engagement.md)
+ [Ponerse en contacto con el SRT para obtener ayuda en caso de sospecha de un episodio DDo S](ddos-srt-contacting.md)
+ [Configuración de mitigaciones personalizadas contra los ataques DDo S con el SRT](ddos-srt-custom-mitigations.md)
# Concesión del acceso al SRT
Esta página proporciona instrucciones para conceder permiso a la SRT para que actúe en su nombre, de modo que pueda acceder a sus AWS WAF registros y realizar llamadas AWS Shield Advanced y AWS WAF APIs gestionar las protecciones.
Durante DDo los eventos de la capa de aplicación S, el SRT puede supervisar AWS WAF las solicitudes para identificar el tráfico anómalo y ayudar a elaborar AWS WAF reglas personalizadas para mitigar las fuentes de tráfico infractoras.
Además, puede conceder al SRT acceso a otros datos que haya almacenado en los buckets de Amazon S3, como capturas de paquetes o registros de un Application Load Balancer, CloudFront Amazon o de fuentes de terceros.
**nota**
Para utilizar los servicios del equipo de respuesta de Shield (SRT), debe haberse registrado en el [plan de soporte Business](https://aws.amazon.com/premiumsupport/business-support/) o en el [plan de asistencia Enterprise](https://aws.amazon.com/premiumsupport/enterprise-support/).
**Administración de los permisos del SRT**
1. **En la página de **información general** de la AWS Shield consola, en **Configurar la compatibilidad con AWS SRT**, selecciona Editar el acceso a SRT.** Se abre la página de **acceso al equipo de respuesta de Edit AWS Shield (SRT)**.
1. Para **Configuración de acceso de SRT**, seleccione una de las siguientes opciones:
+ **No conceder al SRT acceso a mi cuenta**: Shield elimina cualquier permiso que se haya otorgado anteriormente al SRT para acceder a su cuenta y sus recursos.
+ **Crear un nuevo rol para que el SRT acceda a mi cuenta**: Shield crea un rol que confía en la entidad principal del servicio `drt.shield.amazonaws.com`, que representa al SRT, y le asocia la política administrada `AWSShieldDRTAccessPolicy`. La política gestionada permite al SRT realizar AWS Shield Advanced llamadas a la AWS WAF API en tu nombre y acceder a tus AWS WAF registros. Para obtener más información sobre la política administrada, consulte [AWS política gestionada: AWSShield DRTAccess política](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
+ **Elija un rol existente para que el SRT pueda acceder a mis cuentas**. Para elegir esta opción, debe modificar la configuración del rol en AWS Identity and Access Management (IAM) de la siguiente manera:
+ Asocie la política `AWSShieldDRTAccessPolicy` administrada al rol. Esta política gestionada permite al SRT realizar AWS Shield Advanced llamadas a la AWS WAF API en tu nombre y acceder a tus registros. AWS WAF Para obtener más información sobre la política administrada, consulte [AWS política gestionada: AWSShield DRTAccess política](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). Para obtener información sobre cómo asociar la política administrada a su rol, consulte [Cómo asociar y desasociar políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+ Modifique el rol para confiar en la entidad principal de servicio `drt.shield.amazonaws.com`. Esta es la entidad principal de servicio que representa el SRT. Para obtener más información, consulte [Elemento de la política de JSON de IAM: Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
1. Para **(opcional): conceda acceso SRT a un bucket de Amazon S3**. Si necesita compartir datos que no están en sus registros de ACL AWS WAF web, configúrelo. Por ejemplo, los registros de acceso de Application Load Balancer, los CloudFront registros de Amazon o los registros de fuentes de terceros.
**nota**
No necesitas hacer esto para tus registros de ACL AWS WAF web. El SRT obtiene acceso a ellos cuando conceda acceso a su cuenta.
1. Configure los buckets de Amazon S3 según las siguientes directrices:
+ Las ubicaciones de los cubos deben estar en las Cuenta de AWS mismas ubicaciones a las que le diste acceso general al SRT, en el paso anterior, el acceso al **AWS Shield Response Team (SRT)**.
+ Los buckets pueden ser de texto sin formato o cifrado SSE-S3. Para obtener más información sobre el cifrado SSE-S3 de Amazon S3, consulte [Protección de datos utilizando el cifrado del servidor con las claves de cifrado de Amazon S3-Managed Encryption Keys (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html) en la Guía del usuario de Amazon S3.
El SRT no puede ver ni procesar los registros que están almacenados en depósitos cifrados con claves almacenadas en (). AWS Key Management Service AWS KMS
1. En la sección **(Opcional): Conceder al SRT acceso a un bucket de Amazon S3**, introduzca el nombre del bucket y elija **Agregar bucket** para cada bucket de Amazon S3 en el que se almacenen sus datos o registros. Puede agregar hasta 10 buckets.
Esto otorga al SRT los siguientes permisos en cada bucket: `s3:GetBucketLocation`, `s3:GetObject` y `s3:ListBucket`.
Si quiere dar permiso al SRT para acceder a más de 10 buckets, puede hacerlo editando las políticas de bucket adicionales y concediendo manualmente los permisos que se indican aquí para el SRT.
A continuación, se muestra una lista de políticas de ejemplo.
```
{
"Sid": "AWSDDoSResponseTeamAccessS3Bucket",
"Effect": "Allow",
"Principal": {
"Service": "drt.shield.amazonaws.com"
},
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
}
```
1. Elija **Guardar** para guardar los cambios.
[También puede autorizar el SRT a través de la API creando un rol de IAM, adjuntándole la AWSShield DRTAccess política y, a continuación, transfiriendo el rol al asociado de la operación. DRTRole](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_AssociateDRTRole.html)
# Configuración de una interacción proactiva para que el SRT se ponga en contacto con usted directamente
En esta página se incluyen las instrucciones para configurar una interacción proactiva con el SRT.
Con una interacción proactiva, el SRT se pone en contacto con usted directamente cuando la disponibilidad o el rendimiento de su aplicación se ven afectados por un posible ataque. Recomendamos este modelo de interacción porque proporciona la respuesta más rápida del SRT y le permite empezar a solucionar problemas incluso antes de ponerse en contacto con usted.
La participación proactiva está disponible para eventos de capa de red y capa de transporte en direcciones IP elásticas y aceleradores AWS Global Accelerator estándar, y para inundaciones de solicitudes web en CloudFront distribuciones de Amazon y balanceadores de carga de aplicaciones. La interacción proactiva solo está disponible para las protecciones de recursos de Shield Avanzado que tengan una comprobación de estado de Amazon Route 53 asociada. Para obtener información acerca de la administración y el uso de las comprobaciones de estado, consulte [Detección basada en el estado mediante comprobaciones de estado con Shield Avanzado y Route 53](ddos-advanced-health-checks.md).
Durante un evento detectado por Shield Avanzado, el SRT utiliza el estado de sus comprobaciones de estado para determinar si el evento cumple los requisitos para una interacción proactiva. En caso afirmativo, el SRT se pondrá en contacto con usted de acuerdo con las instrucciones de contacto que haya proporcionado en su configuración de interacción proactiva.
Puede configurar hasta diez contactos para una interacción proactiva y puede dar indicaciones que sirvan de guía al SRT para contactar con usted. Sus contactos de interacción proactiva deberían estar disponibles para interactuar con la SRT durante los eventos. Si no dispone de un centro de operaciones abierto las 24 horas del día, los siete días de la semana, puede proporcionar un número de busca e indicar esta preferencia de contacto en sus indicaciones de contacto.
Para utilizar la interacción proactiva, debe hacer lo siguiente:
+ Debe estar suscrito al [plan Business Support](https://aws.amazon.com/premiumsupport/business-support/) o en el [plan Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/).
+ Debe asociar una comprobación de estado de Amazon Route 53 a cualquier recurso que desee proteger mediante la interacción proactiva. El SRT utiliza el estado de sus comprobaciones de estado para determinar si un evento requiere de una interacción proactiva, por lo que es importante que sus controles de estado reflejen con precisión el estado de sus recursos protegidos. Para obtener más información y orientación, consulte [Detección basada en el estado mediante comprobaciones de estado con Shield Avanzado y Route 53](ddos-advanced-health-checks.md).
+ Para un recurso que tenga una ACL AWS WAF web asociada, debe crear la ACL web con AWS WAF (v2), que es la versión más reciente de. AWS WAF
+ Debe proporcionar al menos un contacto para que el SRT lo utilice para la interacción proactiva durante un evento. Mantenga la información de contacto completa y actualizada.
**Habilitación de la interacción proactiva de SRT**
1. En la página de **descripción general** de la AWS Shield consola, en **Participación proactiva y contactos**, en el área de contactos, seleccione **Editar**.
En la página **Editar contactos**, proporcione la información de contacto de las personas con las que desea que el SRT se ponga en contacto para tener una interacción proactiva.
Si proporciona más de un contacto, en **Notas**, indique las circunstancias en las que debe utilizarse cada contacto. Incluya las designaciones de los contactos principales y secundarios y proporcione los horarios de disponibilidad y las zonas horarias de cada contacto.
Ejemplos de notas de contacto:
+ Esta es una línea directa que cuenta con personal las 24 horas del día, todos los días de la semana, todos los días del año. Trabaje con el analista que le responda, le dirigirá a la persona adecuada en la llamada.
+ Póngase en contacto conmigo si la línea directa no responde en 5 minutos.
1. Seleccione **Save (Guardar)**.
La página **Información general** refleja la información de contacto actualizada.
1. Seleccione **Editar característica de interacción proactiva**, seleccione **Habilitar** y, a continuación, seleccione **Guardar** para habilitar la interacción proactiva.
# Ponerse en contacto con el SRT para obtener ayuda en caso de sospecha de un episodio DDo S
Puede ponerse en contacto con el SRT de una de las siguientes maneras:
**Caso de soporte**
Puede abrir un caso en **AWS Shield** a través de la consola del **Centro de Soporte de AWS **.
Para obtener información sobre cómo crear un caso de soporte, consulte el [Centro de AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
Seleccione la gravedad de su situación y proporcione sus datos de contacto. En la descripción, proporcione tantos detalles como sea posible. Facilite información sobre los recursos protegidos que crea que pueden verse afectados y el estado actual de su experiencia de usuario final. Por ejemplo, si su experiencia de usuario está degradada o hay partes de la aplicación que no están disponibles actualmente, proporcione esa información.
+ En caso **de sospecha de un ataque DDo S**: si la disponibilidad o el rendimiento de su aplicación se ven afectados actualmente por un posible ataque DDo S, elija las siguientes opciones de gravedad y contacto:
+ En cuanto a la gravedad, elija la gravedad más alta disponible para su plan de asistencia:
+ Para la asistencia Business, es **Sistema de producción caído: < 1 hora**.
+ Para la asistencia Enterprise, es **Sistema esencial para la empresa caído: < 15 minutos**.
+ Para la opción de contacto, seleccione **Teléfono** o **Chat** y facilite sus datos. El uso de un método de contacto en directo ofrece la respuesta más rápida.
**Interacción proactiva**
Con una participación AWS Shield Advanced proactiva, el SRT se pone en contacto con usted directamente si la comprobación de estado de Amazon Route 53 asociada a su recurso protegido deja de funcionar durante un evento detectado. Para obtener más información acerca de esta opción, consulta [Configuración de una interacción proactiva para que el SRT se ponga en contacto con usted directamente](ddos-srt-proactive-engagement.md).
# Configuración de mitigaciones personalizadas contra los ataques DDo S con el SRT
Esta página proporciona instrucciones para trabajar con el SRT a fin de crear mitigaciones personalizadas contra los ataques S. DDo
Para tus aceleradores Elastic IPs (EIPs) y AWS Global Accelerator estándar, puedes trabajar con el SRT para configurar mitigaciones personalizadas. Esto resulta útil si conoce una lógica específica que deba aplicarse cuando se aplique una mitigación. Por ejemplo, es posible que desee permitir únicamente el tráfico procedente de determinados países, aplicar límites de tasa específicos, configurar validaciones opcionales, impedir los fragmentos o permitir únicamente el tráfico que coincida con un patrón específico en la carga útil del paquete.
A continuación, se muestran ejemplos de mitigaciones personalizadas comunes:
+ **Coincidencia de patrones**: si opera un servicio que interactúa con aplicaciones del cliente, puede optar por hacer coincidir los patrones conocidos que sean exclusivos de esas aplicaciones. Por ejemplo, puede operar un servicio de juegos o comunicaciones que requiera que el usuario final instale el software específico que distribuye. Puede incluir un número mágico en cada paquete que la aplicación envíe a su servicio. Puede hacer coincidir hasta 128 bytes (separados o contiguos) de la carga útil y los encabezados de un paquete TCP o UDP no fragmentado. La coincidencia se puede expresar en notación hexadecimal como un desplazamiento específico desde el principio de la carga útil del paquete o un desplazamiento dinámico que sigue un valor conocido. Por ejemplo, la mitigación puede buscar el byte `0x01` y esperar que `0x12345678` sean los cuatro bytes siguientes.
+ **DNS específico**: si utilizas tu propio servicio de DNS autorizado mediante servicios como Global Accelerator o Amazon Elastic Compute Cloud EC2 (Amazon), puedes solicitar una mitigación personalizada que valide los paquetes para garantizar que sean consultas de DNS válidas y aplicar una puntuación de sospecha que evalúe los atributos que son específicos del tráfico de DNS.
Para obtener información sobre cómo trabajar con el SRT para crear mitigaciones personalizadas, cree un caso de asistencia en AWS Shield. [Para obtener más información sobre la creación de AWS Support casos, consulta Cómo empezar con. AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html)
# Protecciones de recursos en AWS Shield Advanced
Puede añadir y configurar AWS Shield Advanced protecciones para sus recursos. Puede administrar las protecciones de un solo recurso y agrupar los recursos protegidos en colecciones lógicas para una mejor administración de los eventos. También puede realizar un seguimiento de los cambios en sus protecciones Shield Advanced utilizando AWS Config.
**nota**
Shield Advanced protege solo los recursos que haya especificado en Shield Advanced o mediante una política de AWS Firewall Manager Shield Advanced. No protege automáticamente sus recursos.
Si utilizas una política AWS Firewall Manager Shield Advanced, no necesitas gestionar las protecciones de los recursos que están dentro del ámbito de aplicación de la política. Firewall Manager administra automáticamente las protecciones de las cuentas y los recursos que están dentro del ámbito de una política, de acuerdo con la configuración de la política. Para obtener más información, consulte [Uso de AWS Shield Advanced políticas en Firewall Manager](shield-policies.md).
**Topics**
+ [Lista de recursos que AWS Shield Advanced protegen](ddos-protections-by-resource-type.md)
+ [Protección de EC2 las instancias de Amazon y los balanceadores de carga de red con Shield Advanced](ddos-protections-ec2-nlb.md)
+ [Proteger la capa de aplicación (capa 7) con AWS Shield Advanced y AWS WAF](ddos-app-layer-protections.md)
+ [Detección basada en el estado mediante comprobaciones de estado con Shield Avanzado y Route 53](ddos-advanced-health-checks.md)
+ [Añadir AWS Shield Advanced protección a AWS los recursos](configure-new-protection.md)
+ [Edición de AWS Shield Advanced protecciones](manage-protection.md)
+ [Creación de alarmas y notificaciones para los recursos protegidos por Shield Avanzado](add-alarm-ddos.md)
+ [Eliminar AWS Shield Advanced la protección de un AWS recurso](remove-protection.md)
+ [Agrupación de sus protecciones AWS Shield Advanced](ddos-protection-groups.md)
+ [Cambios en la protección avanzada de recursos de Tracking Shield AWS Config](ddos-add-config.md)
# Lista de recursos que AWS Shield Advanced protegen
En esta sección, se proporciona información sobre las protecciones de Shield Avanzado para cada tipo de recurso.
Shield Advanced protege AWS los recursos en las capas de red y transporte (capas 3 y 4) y en la capa de aplicación (capa 7). Puede proteger algunos recursos directamente y otros asociándolos a recursos protegidos. Shield Advanced admite IPv4 y no admite IPv6.
**nota**
Shield Avanzado protege solo los recursos que haya especificado en Shield Avanzado o mediante una política avanzada de Shield Avanzado de AWS Firewall Manager . No protege automáticamente sus recursos.
Puede usar Shield Avanzado para una supervisión y protección avanzadas con los siguientes tipos de recursos:
+ CloudFront Distribuciones de Amazon. Para CloudFront un despliegue continuo, Shield Advanced protege cualquier distribución provisional que esté asociada a una distribución principal protegida.
+ Zonas alojadas de Amazon Route 53.
+ AWS Global Accelerator aceleradores estándar.
+ Direcciones IP EC2 elásticas de Amazon. Shield Avanzado protege los recursos asociados a las direcciones IP elásticas protegidas.
+ EC2 Instancias de Amazon, mediante la asociación a direcciones IP EC2 elásticas de Amazon.
+ Los siguientes equilibradores de carga Elastic Load Balancing (ELB):
+ Equilibradores de carga de aplicación.
+ Equilibradores de carga clásicos.
+ Equilibradores de carga de red, mediante asociaciones a direcciones IP de Amazon EC2 Elastic.
**nota**
No puede usar Shield Avanzado para proteger ningún otro tipo de recurso. Por ejemplo, no puede proteger los aceleradores de enrutamiento personalizados de AWS Global Accelerator ni los equilibradores de carga de puerta de enlace.
**nota**
Las puertas de enlace NAT gestionan únicamente el tráfico saliente, mientras que Shield Advanced protege contra el S entrante. DDo Para proteger el tráfico saliente, utilice. [AWS Network Firewall](https://docs.aws.amazon.com//network-firewall/latest/developerguide/what-is-aws-network-firewall.html)
Puede supervisar y proteger hasta un máximo de 1000 recursos de cada uno de estos tipos de recursos por cuenta de Cuenta de AWS. Por ejemplo, en una sola cuenta, podría proteger 1000 direcciones IP de Amazon EC2 Elastic, 1000 CloudFront distribuciones y 1000 balanceadores de carga de aplicaciones. Puede solicitar un aumento del número de recursos que puede proteger con Shield Advanced a través de la consola Service Quotas en [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/).
# Protección de EC2 las instancias de Amazon y los balanceadores de carga de red con Shield Advanced
En esta página, se explica cómo utilizar AWS Shield Advanced las protecciones para las EC2 instancias de Amazon y los balanceadores de carga de red.
Puede proteger EC2 las instancias de Amazon y los balanceadores de carga de red adjuntando primero estos recursos a las direcciones IP elásticas y, a continuación, protegiendo las direcciones IP elásticas en Shield Advanced.
Al proteger las direcciones IP elásticas, Shield Avanzado identifica y protege los recursos a los que están conectadas. Shield Avanzado identifica automáticamente el tipo de recurso que está adjunto a una dirección IP elástica y aplica las detecciones y mitigaciones adecuadas para ese recurso. Esto incluye configurar redes ACLs específicas para la dirección IP elástica. Para obtener más información sobre el uso de direcciones IP elásticas con sus recursos de AWS , consulte la siguiente guía: [Documentación de Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/ec2/) o [Documentación del Equilibrador de carga elástico](https://docs.aws.amazon.com/elasticloadbalancing/).
Durante un ataque, Shield Advanced despliega automáticamente la red ACLs en el borde de la AWS red. Cuando su red ACLs se encuentra en el límite de la red, Shield Advanced puede brindar protección contra eventos DDo S más grandes. Por lo general, la red ACLs se aplica cerca de EC2 las instancias de Amazon dentro de la VPC de Amazon. La ACL de red puede mitigar ataques tan grandes como el volumen que puedan gestionar la instancia y Amazon VPC. Por ejemplo, si la interfaz de red conectada a tu EC2 instancia de Amazon puede procesar hasta 10 Gbps, los volúmenes de más de 10 Gbps se ralentizarán y, posiblemente, bloquearán el tráfico a esa instancia. Durante un ataque, Shield Avanzado promueve la ACL de red a la frontera de AWS , lo que permite procesar varios terabytes de tráfico. Su ACL de red puede proporcionar protección a sus recursos más allá de la capacidad normal de su red. [Para obtener más información sobre la red ACLs, consulta Red. ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html)
Algunas herramientas de escalado AWS Elastic Beanstalk, por ejemplo, no permiten adjuntar automáticamente una dirección IP elástica a un Network Load Balancer. En esos casos, debe adjuntar manualmente la dirección IP elástica.
# Proteger la capa de aplicación (capa 7) con AWS Shield Advanced y AWS WAF
En esta página, se explica cómo Shield Advanced y Shield AWS WAF trabajan juntos para proteger los recursos en la capa de aplicación (capa 7).
Para proteger los recursos de la capa de aplicación con Shield Avanzado, comience por asociar una ACL web de AWS WAF al recurso y agregarle una o más reglas basadas en tasas. Además, puede habilitar la mitigación automática de la capa DDo S de aplicación, lo que hace que Shield Advanced cree y administre automáticamente reglas de ACL web en su nombre en respuesta a los ataques DDo S.
Al proteger un recurso de la capa de aplicación con Shield Avanzado, Shield Avanzado analiza el tráfico a lo largo del tiempo para establecer y mantener las líneas base. Shield Advanced utiliza estas líneas de base para detectar anomalías en los patrones de tráfico que podrían indicar un ataque S. DDo El punto en el que Shield Avanzado detecta un ataque depende del tráfico que Shield Avanzado haya podido observar antes del ataque y de la arquitectura que utilice para sus aplicaciones web. Las variaciones de arquitectura que pueden afectar al comportamiento de Shield Avanzado incluyen el tipo de instancia que utilice, el tamaño de la instancia y si el tipo de instancia admite redes mejoradas. También puede configurar Shield Avanzado para que mitigue automáticamente los ataques a la capa de aplicación.
**Suscripciones y AWS WAF costos de Shield Advanced**
Su suscripción a Shield Advanced cubre los costes de uso de AWS WAF las capacidades estándar para los recursos que proteja con Shield Advanced. Las AWS WAF tarifas estándar que cubren las protecciones Shield Advanced son el costo por paquete de protección (ACL web), el costo por regla y el precio base por millón de solicitudes de inspección de solicitudes web, hasta 1500 WCUs y hasta el tamaño corporal predeterminado.
Al habilitar la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced, se añade un grupo de reglas al paquete de protección (ACL web) que utiliza 150 unidades de capacidad de ACL web (WCUs). Esto se WCUs descuenta del uso de la WCU en su paquete de protección (ACL web). Para obtener más información, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md), [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md) y [Unidades de capacidad de ACL web (WCUs) en AWS WAF](aws-waf-capacity-units.md).
Su suscripción a Shield Advanced no cubre el uso AWS WAF de recursos que no proteja con Shield Advanced. Tampoco cubre ningún AWS WAF coste adicional no estándar de los recursos protegidos. Algunos ejemplos de AWS WAF costes no estándar son los del control de bots, la acción de la CAPTCHA regla, la web ACLs que utiliza más de 1500 WCUs usuarios y la inspección del cuerpo de la solicitud por encima del tamaño predeterminado. La lista completa se encuentra en la página de AWS WAF precios. Su suscripción a Shield Advanced incluye el acceso al grupo de reglas gestionadas por Amazon DDo Anti-S de capa 7. Como parte de su suscripción, recibirá hasta 50 000 millones de solicitudes a los AWS WAF recursos protegidos de Shield Advanced en un mes natural. Las solicitudes superiores a 50 000 millones se facturarán según la página de AWS Shield Advanced precios.
Para obtener la información completa y ejemplos de precios, consulte [Precios de Shield](https://aws.amazon.com/shield/pricing/) y [Precios de AWS WAF](https://aws.amazon.com/waf/pricing/).
**Topics**
+ [Lista de factores que afectan a la detección y mitigación de eventos de la capa de aplicación con Shield Avanzado](ddos-app-layer-detection-mitigation.md)
+ [Protección de la capa de aplicaciones con AWS WAF web ACLs y Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md)
+ [Protección de la capa de aplicaciones con reglas AWS WAF basadas en tasas y Shield Advanced](ddos-app-layer-rbr.md)
+ [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md)
# Lista de factores que afectan a la detección y mitigación de eventos de la capa de aplicación con Shield Avanzado
En esta sección se describen los factores que afectan a la detección y mitigación de los eventos de la capa de aplicación por parte de Shield Avanzado.
**Comprobaciones de estado**
Las comprobaciones de estado, que informan con precisión acerca del estado general de su aplicación, proporcionan a Shield Avanzado información sobre las condiciones de tráfico que experimenta su aplicación. Shield Avanzado requiere menos información que indique sobre un posible ataque cuando la aplicación informa que está en mal estado y requiere de una mayor cantidad de pruebas que indiquen sobre un ataque en caso de que la aplicación informe que está en buen estado.
Es importante configurar las comprobaciones de estado para que informen con precisión del estado de la aplicación. Para obtener más información y orientación, consulte [Detección basada en el estado mediante comprobaciones de estado con Shield Avanzado y Route 53](ddos-advanced-health-checks.md).
**Tráfico de referencia**
El tráfico de referencia proporciona a Shield Avanzado información sobre las características del tráfico normal de su aplicación. Shield Avanzado utiliza estas referencias para reconocer cuándo su aplicación no recibe tráfico normal, de modo que pueda notificárselo y, según esté configurado, empezar a diseñar y probar opciones de mitigación para contrarrestar un posible ataque. Para obtener información adicional sobre cómo Shield Avanzado utiliza el tráfico de referencia para detectar posibles eventos, consulte la sección de información general [Lógica de detección de amenazas de Shield Avanzado en la capa de aplicación (capa 7)](ddos-event-detection-application.md).
Shield Avanzado crea sus referencias a partir de la información que ACL web asociada le proporciona al recurso protegido. La ACL web debe permanecer asociada al recurso durante al menos 24 horas y hasta 30 días antes de que Shield Avanzado pueda determinar de forma confiable las referencias de la aplicación. El tiempo necesario comienza cuando se asocia la ACL web, a través de Shield Avanzado o a través de AWS WAF.
Para obtener más información sobre el uso de una ACL web con las protecciones de la capa de aplicación Shield Avanzado, consulte [Protección de la capa de aplicaciones con AWS WAF web ACLs y Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
**Reglas basadas en frecuencia**
Las reglas basadas en tasas pueden ayudar a mitigar los ataques. También pueden ocultar los ataques, al mitigarlos antes de que se conviertan en un problema lo bastante grande, como para que aparezcan en las referencias de tráfico normales o en los informes de estado de la comprobación de estado.
Cuando proteja un recurso de aplicación con Shield Avanzado, le recomendamos que utilice reglas basadas en tasas en su ACL web. Si bien sus medidas de mitigación pueden ocultar un posible ataque, son una valiosa primera línea de defensa, ya que ayudan a garantizar que su aplicación permanezca disponible para sus clientes legítimos. El tráfico que detectan sus reglas basadas en tasas y el límite de velocidad se muestran en sus métricas de AWS WAF .
Además de sus propias reglas basadas en tasas, si habilita la mitigación automática de la capa DDo S de aplicación, Shield Advanced añade un grupo de reglas a su ACL web que utiliza para mitigar los ataques. En este grupo de reglas, Shield Advanced siempre cuenta con una regla basada en la velocidad que limita el volumen de solicitudes de direcciones IP que se sabe que son fuentes de ataques DDo S. Las métricas del tráfico que mitigan las reglas de Shield Avanzado no están disponibles para que las vea.
Para obtener más información acerca de las reglas basadas en tasas, consulte [Uso de declaraciones de reglas basadas en tasas en AWS WAF](waf-rule-statement-type-rate-based.md). Para obtener información sobre la regla basada en la velocidad que Shield Advanced utiliza para la mitigación automática de la capa DDo S de aplicación, consulte[Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md).
Para obtener más información sobre Shield Advanced y AWS WAF las métricas, consulte[Monitorización con Amazon CloudWatch](monitoring-cloudwatch.md).
# Protección de la capa de aplicaciones con AWS WAF web ACLs y Shield Advanced
En esta página se explica cómo AWS WAF web ACLs y Shield Advanced trabajan en conjunto para crear protecciones básicas en la capa de aplicaciones.
Para proteger un recurso de la capa de aplicación con Shield Advanced, comience por asociar una ACL AWS WAF web al recurso. AWS WAF es un firewall de aplicaciones web que permite supervisar las solicitudes HTTP y HTTPS que se reenvían a los recursos de la capa de aplicaciones y controlar el acceso al contenido en función de las características de las solicitudes. Puede configurar una ACL web para supervisar y administrar las solicitudes en función de factores como el origen de la solicitud, el contenido de las cadenas de consulta y las cookies, y la tasa de solicitudes procedentes de una sola dirección IP. Como mínimo, su protección Shield Avanzado requiere que asocie una ACL web a una regla basada en tasas, que limita la tasa de solicitudes para cada dirección IP.
Si la ACL web asociada no tiene definida una regla basada en tasas, Shield Avanzado le pide que defina al menos una. Las reglas basadas en la velocidad bloquean automáticamente el tráfico procedente de la fuente IPs cuando supera los umbrales que usted defina. Ayudan a proteger tu aplicación contra la avalancha de solicitudes web y pueden proporcionar alertas sobre picos repentinos de tráfico que podrían indicar un posible ataque S. DDo
**nota**
Una regla basada en tasas responde muy rápidamente a los picos de tráfico que la regla está supervisando. Por ello, una regla basada en tasas puede impedir no solo un ataque, sino también la detección de un posible ataque a través de la detección de Shield Avanzado. Esta compensación favorece la prevención por encima de la visibilidad total de los patrones de ataque. Recomendamos que utilice una regla basada en tasas como su primera línea de defensa contra los ataques.
Una vez instalada la ACL web, si se produce un ataque DDo S, se aplican medidas de mitigación añadiendo y gestionando reglas en la ACL web. Puede hacerlo directamente, con la ayuda del Shield Response Team (SRT), o automáticamente mediante la mitigación automática de la capa DDo S de aplicación.
**importante**
Si también utiliza la mitigación automática de la capa DDo S de aplicaciones, consulte las mejores prácticas para gestionar su ACL web en[Mejores prácticas para utilizar la mitigación automática de la capa DDo S de aplicación](ddos-automatic-app-layer-response-bp.md).
Para obtener información sobre cómo AWS WAF administrar las reglas de monitoreo y administración de sus solicitudes web, consulte[Creación de un paquete de protección (ACL web) en AWS WAF](web-acl-creating.md).
# Protección de la capa de aplicaciones con reglas AWS WAF basadas en tasas y Shield Advanced
En esta página, se explica cómo las reglas AWS WAF basadas en tasas y Shield Advanced trabajan juntas para crear protecciones básicas en la capa de aplicaciones.
Cuando utiliza una regla basada en tasas con su configuración predeterminada, evalúa AWS WAF periódicamente el tráfico durante el intervalo de tiempo anterior de 5 minutos. AWS WAF bloquea las solicitudes de cualquier dirección IP que supere el umbral de la regla hasta que la tasa de solicitudes baje a un nivel aceptable. Al configurar una regla basada en tasas a través de Shield Avanzado, configure su umbral de tasa en un valor superior a la tasa de tráfico normal que espera de cualquier IP de origen en cualquier intervalo de tiempo de cinco minutos.
Es posible que desee utilizar más de una regla basada en tasas en una ACL web. Por ejemplo, podría tener una regla basada en tasas con un umbral alto para todo el tráfico, además de una o más reglas adicionales configuradas para que coincidan con determinadas partes de la aplicación web y que tengan umbrales más bajos. Por ejemplo, puede hacer coincidir el URI `/login.html` con un umbral más bajo para evitar abusos en una página de inicio de sesión.
Puede configurar una regla basada en tasas para utilizar un intervalo de tiempo de evaluación diferente y agregar las solicitudes en función de varios componentes de la solicitud, como los valores de los encabezados, las etiquetas y los argumentos de consulta. Para obtener más información, consulte [Uso de declaraciones de reglas basadas en tasas en AWS WAF](waf-rule-statement-type-rate-based.md).
Para obtener información y orientación adicionales, consulte la entrada del blog sobre seguridad [Las tres reglas AWS WAF basadas en tarifas más importantes](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/).
**Se ampliaron las opciones de configuración mediante AWS WAF**
La consola de Shield Avanzado le permite agregar una regla basada en tasas y configurarla con los ajustes básicos predeterminados. Puede definir opciones de configuración adicionales gestionando sus reglas basadas en tarifas mediante AWS WAF. Por ejemplo, puede configurar la regla para agregar solicitudes basadas en claves como una dirección IP reenviada, una cadena de consulta y una etiqueta. También puede añadir una declaración de restricción a la regla para filtrar algunas solicitudes de evaluación y limitación de tasas. Para obtener más información, consulte [Uso de declaraciones de reglas basadas en tasas en AWS WAF](waf-rule-statement-type-rate-based.md).
# Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced
**nota**
A partir del 26 de marzo de 2026, el DDo Anti-S Managed Rule Group (Anti-DDoS AMR) pasará a AWS WAF ser la solución predeterminada de protección contra los ataques por inundación de solicitudes HTTP (consulte el blog de lanzamiento de [DDoAnti-S AMR](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-the-aws-waf-application-layer-ddos-protection/)). Sustituye a la función de mitigación automática de nivel 7 (L7AM). Si ya es cliente de Shield Advanced, puede seguir utilizando la solución antigua con AWS cuentas nuevas o existentes. Sin embargo, le recomendamos que adopte el grupo de reglas gestionadas contra DDo S. El grupo de reglas gestionadas DDo Anti-S detecta y mitiga los ataques en cuestión de segundos en lugar de minutos. Si es un cliente nuevo de Shield Advanced y necesita acceso a la solución anterior, póngase en contacto con AWS Support.
En esta página se presenta el tema de la mitigación automática de la capa DDo S de aplicación y se enumeran las advertencias asociadas.
Puede configurar Shield Avanzado para que responda automáticamente y mitigue los ataques de capa de aplicación (capa 7) contra recursos protegidos de la capa de aplicaciones mediante el conteo o el bloqueo de las solicitudes web que formen parte del ataque. Esta opción es una adición a la protección de la capa de aplicación que se agrega a través de Shield Advanced con una ACL AWS WAF web y su propia regla basada en la tasa.
Cuando la mitigación automática está habilitada para un recurso, Shield Avanzado mantiene un grupo de reglas en la ACL web asociada al recurso, donde administra las reglas de mitigación en su nombre. El grupo de reglas contiene una regla basada en la velocidad que rastrea el volumen de solicitudes de direcciones IP que se sabe que son fuentes de ataques DDo S.
Además, Shield Advanced compara los patrones de tráfico actuales con las líneas de base de tráfico históricas para detectar desviaciones que puedan indicar un ataque DDo S. Shield Advanced responde a los ataques DDo S detectados mediante la creación, evaluación e implementación de AWS WAF reglas personalizadas adicionales en el grupo de reglas.
## Advertencias sobre el uso de la mitigación automática de la capa DDo S de aplicación
La siguiente lista describe las advertencias de la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced y describe los pasos que puede tomar en respuesta.
+ La mitigación automática de la capa DDo S de aplicaciones solo funciona con los paquetes de protección (web ACLs) que se crearon con la última versión de AWS WAF (v2).
+ Shield Avanzado necesita tiempo para establecer una línea de referencia del tráfico normal e histórico de la aplicación, que aprovecha para detectar y aislar el tráfico de ataque del tráfico normal, a fin de mitigar el tráfico de ataques. El tiempo necesario para establecer una línea de referencia es de 24 horas a 30 días a partir del momento en que se asocia una ACL web al recurso de aplicación protegido. Para obtener más información acerca de las líneas de referencia de tráfico, consulte [Lista de factores que afectan a la detección y mitigación de eventos de la capa de aplicación con Shield Avanzado](ddos-app-layer-detection-mitigation.md).
+ Al habilitar la mitigación automática de la capa DDo S de aplicaciones, se agrega un grupo de reglas al paquete de protección (ACL web) que utiliza 150 unidades de capacidad de ACL web (WCUs). Esto se WCUs descuenta del uso de la WCU en su paquete de protección (ACL web). Para obtener más información, consulte [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md) y [Unidades de capacidad de ACL web (WCUs) en AWS WAF](aws-waf-capacity-units.md).
+ El grupo de reglas Shield Advanced genera AWS WAF métricas, pero no se pueden ver. Esto es igual que para cualquier otro grupo de reglas que utilice en su paquete de protección (ACL web) pero que no sea de su propiedad, como los grupos de reglas de reglas AWS administradas. Para obtener más información sobre AWS WAF las métricas, consulte[AWS WAF métricas y dimensiones](waf-metrics.md). Para obtener información acerca de esta opción de protección de Shield Avanzado, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](#ddos-automatic-app-layer-response).
+ En el caso de sitios web ACLs que protegen varios recursos, la mitigación automática solo implementa mitigaciones personalizadas que no afectan negativamente a ninguno de los recursos protegidos.
+ El tiempo que transcurre entre el inicio de un ataque DDo S y el momento en que Shield Advanced aplica reglas de mitigación automática personalizadas varía según el evento. Es posible que algunos ataques DDo S finalicen antes de que se implementen las reglas personalizadas. Otros ataques pueden producirse cuando ya existe una mitigación y, por lo tanto, podrían mitigarse con esas reglas desde el inicio del evento. Además, las reglas basadas en tasas del grupo de reglas ACL web y Shield Avanzado pueden mitigar el tráfico de ataques antes de que se detecte como un posible evento.
+ En el caso de los balanceadores de carga de aplicaciones que reciben tráfico a través de una red de entrega de contenido (CDN), como Amazon CloudFront, se reducirán las capacidades de mitigación automática de la capa de aplicaciones de Shield Advanced para esos recursos del Application Load Balancer. Shield Advanced utiliza los atributos de tráfico del cliente para identificar y aislar el tráfico de ataque del tráfico normal hacia su aplicación, y no CDNs puede conservar ni reenviar los atributos de tráfico del cliente originales. Si lo usa CloudFront, le recomendamos que habilite la mitigación automática en la CloudFront distribución.
+ La mitigación automática de la capa de aplicación DDo S no interactúa con los grupos de protección. Puede habilitar la mitigación automática para los recursos que se encuentran en grupos de protección, pero Shield Avanzado no aplica automáticamente mitigaciones de ataques en función de los resultados de los grupos de protección. Shield Avanzado aplica mitigaciones de ataque automáticas a recursos individuales.
**Contents**
+ [Advertencias sobre el uso de la mitigación automática de la capa DDo S de aplicación](#ddos-automatic-app-layer-response-caveats)
+ [Mejores prácticas para utilizar la mitigación automática de la capa DDo S de aplicación](ddos-automatic-app-layer-response-bp.md)
+ [Habilitación de la mitigación automática de la capa DDo S de aplicación](ddos-automatic-app-layer-response-config.md)
+ [Qué ocurre cuando se habilita la mitigación automática](ddos-automatic-app-layer-response-config.md#ddos-automatic-app-layer-response-enable)
+ [Cómo administra Shield Avanzado la mitigación automática](ddos-automatic-app-layer-response-behavior.md)
+ [Cómo responde Shield Advanced a los ataques DDo S con mitigación automática](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-ddos-attack)
+ [Cómo Shield Avanzado administra la configuración de acciones de las reglas](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action)
+ [Cómo administra Shield Avanzado las mitigaciones cuando un ataque remite](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-after-attack)
+ [Qué ocurre cuando se deshabilita la mitigación automática](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-disable)
+ [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md)
+ [Visualización de la configuración de mitigación automática de la capa DDo S de aplicación para un recurso](view-automatic-app-layer-response-configuration.md)
+ [Activación y desactivación de la mitigación automática de la capa DDo S de aplicación](enable-disable-automatic-app-layer-response.md)
+ [Cambiar la acción utilizada para la mitigación automática de la capa DDo S de aplicación](change-action-of-automatic-app-layer-response.md)
+ [Uso AWS CloudFormation con mitigación automática de la capa DDo S de aplicación](manage-automatic-mitigation-in-cfn.md)
# Mejores prácticas para utilizar la mitigación automática de la capa DDo S de aplicación
Siga las instrucciones que se proporcionan en esta sección cuando utilice la mitigación automática.
**Administración de protecciones generales**
Siga estas pautas para planificar e implementar sus protecciones de mitigación automática.
+ Administre todas sus protecciones de mitigación automática a través de Shield Advanced o, si las utiliza AWS Firewall Manager para administrar la configuración de mitigación automática de Shield Advanced, a través de Firewall Manager. No mezcle el uso de Shield Avanzado y Firewall Manager para administrar estas protecciones.
+ Administre recursos similares utilizando la misma configuración web ACLs y de protección, y administre recursos diferentes utilizando una web ACLs diferente. Cuando Shield Advanced mitiga un ataque DDo S a un recurso protegido, define las reglas para la ACL web asociada al recurso y, a continuación, las compara con el tráfico de todos los recursos asociados a la ACL web. Shield Avanzado solo aplicará las reglas si no afectan negativamente a ninguno de los recursos asociados. Para obtener más información, consulte [Cómo administra Shield Avanzado la mitigación automática](ddos-automatic-app-layer-response-behavior.md).
+ En el caso de los balanceadores de carga de aplicaciones que tienen todo su tráfico de Internet redirigido mediante proxy a través de una CloudFront distribución de Amazon, solo habilita la mitigación automática en la CloudFront distribución. La CloudFront distribución siempre tendrá la mayor cantidad de atributos de tráfico originales, que Shield Advanced aprovecha para mitigar los ataques.
**Optimización de la detección y mitigación**
Siga estas pautas para optimizar las protecciones que la mitigación automática proporciona a los recursos protegidos. Para obtener una descripción general de la detección y mitigación de la capa de aplicación, consulte [Lista de factores que afectan a la detección y mitigación de eventos de la capa de aplicación con Shield Avanzado](ddos-app-layer-detection-mitigation.md).
+ Configure la comprobación de estado de sus recursos protegidos y utilícelos para habilitar la detección basada en el estado en sus protecciones de Shield Avanzado. Para obtener instrucciones, consulte [Detección basada en el estado mediante comprobaciones de estado con Shield Avanzado y Route 53](ddos-advanced-health-checks.md).
+ Active la mitigación automática en el modo Count hasta que Shield Avanzado haya establecido una línea base para el tráfico normal e histórico. Shield Avanzado requiere de 24 horas a 30 días para establecer una referencia.
Para establecer una base de patrones de tráfico normales se requiere lo siguiente:
+ La asociación de una ACL web con el recurso protegido. Puede utilizarla AWS WAF directamente para asociar su ACL web o puede hacer que Shield Advanced la asocie cuando active la protección de la capa de aplicaciones de Shield Advanced y especifique la ACL web que desee utilizar.
+ Flujo de tráfico normal hacia su aplicación protegida. Si su aplicación no experimenta un tráfico normal, por ejemplo, antes de que se inicie, o si no cuenta con tráfico de producción durante períodos prolongados, no se podrán recopilar los datos históricos.
**Administración de ACL web**
Siga estas pautas para administrar la web ACLs que utiliza con la mitigación automática.
+ Si necesita reemplazar la ACL web asociada al recurso protegido, realice los siguientes cambios en este orden:
1. En Shield Avanzado, active la mitigación automática.
1. En AWS WAF, desasocie la antigua ACL web y asocie la nueva ACL web.
1. En Shield Avanzado, active la mitigación automática.
Shield Avanzado no transfiere automáticamente la mitigación automática de la antigua ACL web a la nueva.
+ No elimine ninguna regla de grupo de reglas de la web ACLs cuyo nombre comience por. `ShieldMitigationRuleGroup` Si elimina este grupo de reglas, deshabilite las protecciones que proporciona la mitigación automática de Shield Avanzado para cada recurso asociado a la ACL web. Además, Shield Avanzado puede tardar algún tiempo en recibir la notificación del cambio y actualizar su configuración. Durante este tiempo, las páginas de la consola de Shield Avanzado proporcionarán información incorrecta.
Para obtener más información acerca de este grupo de reglas, consulte [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md).
+ No modifique el nombre de una regla del grupo de reglas que comience por `ShieldMitigationRuleGroup`. Si lo hace, puede interferir en las protecciones que proporciona la mitigación automática de Shield Avanzado a través de la ACL web.
+ Al crear reglas y grupos de reglas, no utilice nombres que comiencen por `ShieldMitigationRuleGroup`. Shield Avanzado utiliza esta cadena para gestionar las mitigaciones automáticas.
+ Al administrar sus reglas de ACL web, no asigne una configuración de prioridad de 10.000.000. Shield Avanzado asigna esta configuración de prioridad a su regla del grupo de reglas de mitigación automática cuando la agrega.
+ Mantenga la prioridad de la regla `ShieldMitigationRuleGroup` en relación con las demás reglas de su ACL web para que se ejecute cuando desee. Shield Avanzado añade la regla del grupo de reglas a la ACL web con una prioridad de 10.000.000 para que se ejecute después de las demás reglas. Si usa el asistente de AWS WAF consola para administrar su ACL web, ajuste la configuración de prioridad según sea necesario después de agregar reglas a la ACL web.
+ Si lo utiliza AWS CloudFormation para administrar su web ACLs, no necesita administrar la `ShieldMitigationRuleGroup` regla del grupo de reglas. Siga las instrucciones de [Uso AWS CloudFormation con mitigación automática de la capa DDo S de aplicación](manage-automatic-mitigation-in-cfn.md).
# Habilitación de la mitigación automática de la capa DDo S de aplicación
Esta página explica cómo configurar Shield Avanzado para que responda automáticamente a ataques en la capa de aplicación.
Habilita la mitigación automática de Shield Advanced como parte de las protecciones de la capa DDo S de aplicación para su recurso. Para obtener información sobre cómo hacer esto con la consola, consulte [Configure las protecciones de la capa DDo S de aplicación](manage-protection.md#configure-app-layer-protection).
La función de mitigación automática requiere que haga lo siguiente:
+ **Asociar una ACL web al recurso**: esto se requiere para cualquier protección de la capa de aplicación de Shield Avanzado. Puede utilizar la misma ACL web para varios recursos. Recomendamos hacer esto solo para los recursos que tienen un tráfico similar. Para obtener información sobre la webACLs, incluidos los requisitos para utilizarla con varios recursos, consulte[Cómo AWS WAF funciona](how-aws-waf-works.md).
+ **Habilite y configure la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced**: al habilitarla, especifique si desea que Shield Advanced bloquee o cuente automáticamente las solicitudes web que determine que forman parte de un ataque DDo S. Shield Advanced agrega un grupo de reglas a la ACL web asociada y lo usa para administrar dinámicamente su respuesta a los ataques DDo S al recurso. Para obtener información sobre las opciones de acción de las reglas, consulte [Uso de acciones de reglas en AWS WAF](waf-rule-action.md).
+ **(Opcional, pero recomendable) Añada una regla basada en la velocidad a la ACL web**: de forma predeterminada, la regla basada en la velocidad proporciona a su recurso una protección básica contra los ataques DDo S al evitar que cualquier dirección IP individual envíe demasiadas solicitudes en poco tiempo. Para obtener información sobre las reglas basadas en tasas, incluidas las opciones de agregación de solicitudes personalizadas y algunos ejemplos, consulte [Uso de declaraciones de reglas basadas en tasas en AWS WAF](waf-rule-statement-type-rate-based.md).
## Qué ocurre cuando se habilita la mitigación automática
Al habilitar la mitigación automática, Shield Avanzado hace lo siguiente:
+ **Según sea necesario, agrega un grupo de reglas para el uso avanzado de Shield**: si la ACL AWS WAF web que ha asociado al recurso aún no tiene una AWS WAF regla de grupo de reglas dedicada a la mitigación automática de la capa DDo S de aplicación, Shield Advanced agrega una.
El nombre del grupo de reglas comienza con `ShieldMitigationRuleGroup`. El grupo de reglas siempre contiene una regla denominada «basada en la velocidad»`ShieldKnownOffenderIPRateBasedRule`, que limita el volumen de solicitudes procedentes de direcciones IP que se sabe que son fuentes de ataques DDo tipo S. Para obtener información adicional sobre el grupo de reglas de Shield Avanzado y la regla ACL web en la que se referencia, consulte [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md).
+ **Comienza a responder a los ataques DDo S contra el recurso**: Shield Advanced responde automáticamente a los ataques DDo S del recurso protegido. Además de la regla basada en la velocidad, que siempre está presente, Shield Advanced usa su grupo de reglas para implementar AWS WAF reglas personalizadas para la mitigación de DDo los ataques S. Shield Avanzado adapta estas reglas a su aplicación y a los ataques que sufre, y las comprueba con el tráfico histórico del recurso antes de implementarlas.
Shield Avanzado utiliza una única regla del grupo de reglas en cualquier ACL web que utilice para la mitigación automática. Si Shield Avanzado ya ha agregado el grupo de reglas para otro recurso protegido, no agrega un grupo de reglas adicional a la ACL web.
La mitigación automática de la capa de aplicación DDo S depende de la presencia del grupo de reglas para mitigar los ataques. Si el grupo de reglas se elimina de la ACL AWS WAF web por algún motivo, la eliminación deshabilita la mitigación automática de todos los recursos asociados a la ACL web.
# Cómo administra Shield Avanzado la mitigación automática
Los temas de esta sección describen cómo Shield Advanced gestiona los cambios de configuración para la mitigación automática de la capa DDo S de aplicación y cómo gestiona los ataques DDo S cuando la mitigación automática está habilitada.
**Topics**
+ [Cómo responde Shield Advanced a los ataques DDo S con mitigación automática](#ddos-automatic-app-layer-response-ddos-attack)
+ [Cómo Shield Avanzado administra la configuración de acciones de las reglas](#ddos-automatic-app-layer-response-rule-action)
+ [Cómo administra Shield Avanzado las mitigaciones cuando un ataque remite](#ddos-automatic-app-layer-response-after-attack)
+ [Qué ocurre cuando se deshabilita la mitigación automática](#ddos-automatic-app-layer-response-disable)
## Cómo responde Shield Advanced a los ataques DDo S con mitigación automática
Cuando tiene habilitada la mitigación automática en un recurso protegido, la regla basada `ShieldKnownOffenderIPRateBasedRule` en la velocidad del grupo de reglas Shield Advanced responde automáticamente a los volúmenes de tráfico elevados procedentes de fuentes DDo S conocidas. Este límite de tasas se aplica de forma rápida y actúa como defensa de primera línea contra los ataques.
Cuando Shield Avanzado detecta un ataque, hace lo siguiente:
1. Intenta identificar una firma de ataque que aísle el tráfico de ataque del tráfico normal que llega a su aplicación. El objetivo es crear reglas de mitigación de DDo S de alta calidad que, una vez implementadas, solo afecten al tráfico de ataques y no al tráfico normal de la aplicación.
1. Evalúa la firma del ataque identificada comparándola con los patrones de tráfico históricos del recurso que está siendo atacado, así como de cualquier otro recurso que esté asociado a la misma ACL web. Shield Avanzado realiza esta acción antes de implementar cualquier regla en respuesta al evento.
Dependiendo de los resultados de la evaluación, Shield Avanzado realiza una de las siguientes acciones:
+ Si Shield Advanced determina que la firma del ataque aísla solo el tráfico implicado en el ataque DDo S, implementa la firma en AWS WAF las reglas del grupo de reglas de mitigación de Shield Advanced de la ACL web. Shield Avanzado proporciona a estas reglas la configuración de acción que haya configurado para la mitigación automática del recurso, ya sea Count o Block.
+ De lo contrario, Shield Avanzado no aplica ninguna mitigación.
Durante un ataque, Shield Avanzado envía las mismas notificaciones y proporciona la misma información de eventos que las protecciones básicas de la capa de aplicación de Shield Avanzado. Puedes ver la información sobre los eventos y los ataques DDo S, así como sobre cualquier mitigación de los ataques de Shield Advanced, en la consola de eventos de Shield Advanced. Para obtener información, consulte [Visibilidad de DDo los eventos S con Shield Advanced](ddos-viewing-events.md).
Si ha configurado la mitigación automática para usar la acción de la regla de Block y las reglas de mitigación que Shield Avanzado ha implementado dan falsos positivos, puede cambiar la acción de la regla a Count. Para obtener información acerca de cómo hacerlo, consulte [Cambiar la acción utilizada para la mitigación automática de la capa DDo S de aplicación](change-action-of-automatic-app-layer-response.md).
## Cómo Shield Avanzado administra la configuración de acciones de las reglas
Puede configurar la acción de la regla para sus mitigaciones automáticas hacia Block o Count.
Al cambiar la configuración de la acción de la regla de mitigación automática de un recurso protegido, Shield Avanzado actualiza la configuración de todas las reglas del recurso. Actualiza todas las reglas que estén actualmente en vigor para el recurso en el grupo de reglas de Shield Avanzado y utiliza la nueva configuración de acciones cuando crea nuevas reglas.
Para los recursos que utilizan la misma ACL web, si especifica acciones diferentes, Shield Avanzado utiliza la configuración de acciones Block para la regla basada en tasas `ShieldKnownOffenderIPRateBasedRule` del grupo de reglas. Shield Avanzado crea y administra otras reglas del grupo de reglas en nombre de un recurso protegido específico y usa la configuración de acciones que especificó para el recurso. Todas las reglas del grupo de reglas de Shield Avanzado de una ACL web se aplican al tráfico web de todos los recursos asociados.
Un cambio en la configuración de acción puede tardar unos segundos en propagarse. Durante este tiempo, es posible que vea la configuración anterior en algunos lugares donde se usa el grupo de reglas y la nueva en otros lugares.
Puede cambiar la configuración de las acciones de las reglas de la configuración de mitigación automática en la página de eventos de la consola y en la página de configuración de la capa de aplicación. Para obtener información sobre la página de eventos, consulte [Respondiendo a DDo los eventos S en AWS](ddos-responding.md). Para obtener información sobre la página de configuración, consulte [Configure las protecciones de la capa DDo S de aplicación](manage-protection.md#configure-app-layer-protection).
## Cómo administra Shield Avanzado las mitigaciones cuando un ataque remite
Cuando Shield Avanzado determina que las reglas de mitigación que se desplegaron para un ataque concreto ya no son necesarias, las elimina del grupo de reglas de mitigación de Shield Avanzado.
La eliminación de las reglas de mitigación no coincidirá necesariamente con el final del ataque. Shield Avanzado supervisa los patrones de ataque que detecta en sus recursos protegidos. Podría defenderse de forma proactiva contra la repetición de un ataque con una firma específica manteniendo en vigor las reglas que ha aplicado contra la primera incidencia de este ataque. Según sea necesario, Shield Avanzado aumenta el período de tiempo durante el que mantiene las reglas en vigor. De esta forma, Shield Avanzado podría mitigar los ataques repetidos con una firma específica antes de que afecten a los recursos protegidos.
Shield Advanced nunca elimina la regla basada en la velocidad`ShieldKnownOffenderIPRateBasedRule`, que limita el volumen de solicitudes de direcciones IP que se sabe que son fuentes de ataques DDo S.
## Qué ocurre cuando se deshabilita la mitigación automática
Al deshabilitar la mitigación automática de un recurso, Shield Avanzado hace lo siguiente:
+ **Deja de responder automáticamente a los ataques DDo S**: Shield Advanced interrumpe sus actividades de respuesta automática para el recurso.
+ **Elimina las reglas innecesarias del grupo de reglas de Shield Avanzado**: si Shield Avanzado mantiene alguna regla en su grupo de reglas administradas en nombre del recurso protegido, la elimina.
+ **Elimina el grupo de reglas de Shield Avanzado, si ya no está en uso**: si la ACL web que ha asociado al recurso no está asociada a ningún otro recurso que tenga habilitada la mitigación automática, Shield Avanzado elimina su regla del grupo de reglas de la ACL web.
# Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado
En esta página, se explica cómo funciona el grupo de reglas de Shield Avanzado en su ACL web.
Shield Avanzado administra las actividades de mitigación automáticas mediante reglas de un grupo de reglas del que es propietario y que administra por usted. Shield Avanzado hace referencia al grupo de reglas con una regla de la ACL web que ha asociado a su recurso protegido.
**La regla del grupo de reglas de su ACL web**
La regla de grupo de reglas de Shield Avanzado de su ACL web presenta las siguientes propiedades:
+ **Nombre**: `ShieldMitigationRuleGroup``_account-id_web-acl-id_unique-identifier`
+ **Unidades de capacidad de ACL web (WCU)**: 150. Esto se WCUs descuenta del uso de la WCU en su ACL web.
Shield Advanced crea esta regla en la ACL web con una configuración de prioridad de 10 000 000, de modo que se ejecute después de las demás reglas y grupos de reglas de la ACL web. AWS WAF ejecuta las reglas en una ACL web desde la configuración de prioridad numérica más baja hacia arriba. Durante la administración de la ACL web, esta configuración de prioridad puede cambiar.
La funcionalidad de mitigación automática no consume ningún AWS WAF recurso adicional de su cuenta, aparte de los que WCUs utiliza el grupo de reglas de su ACL web. Por ejemplo, el grupo de reglas de Shield Avanzado no se cuenta como uno de los grupos de reglas de su cuenta. Para obtener información sobre los límites de las cuentas AWS WAF, consulte[AWS WAF cuotas](limits.md).
**Reglas en el grupo de reglas**
Dentro del grupo de reglas Shield Advanced al que se hace referencia, Shield Advanced mantiene una regla basada en la velocidad`ShieldKnownOffenderIPRateBasedRule`, que limita el volumen de solicitudes de direcciones IP que se sabe que son fuentes de ataques DDo S. Esta regla sirve como primera línea de defensa contra cualquier ataque, ya que siempre está presente en el grupo de reglas y no se basa en el análisis de los patrones de tráfico para contener los ataques. La acción de esta regla se establece en la acción que elija para las mitigaciones automáticas, al igual que las demás reglas del grupo de reglas. Para obtener información acerca de las reglas basadas en tasas, consulte [Uso de declaraciones de reglas basadas en tasas en AWS WAF](waf-rule-statement-type-rate-based.md).
**nota**
La regla basada en tasas `ShieldKnownOffenderIPRateBasedRule` funciona independientemente de la detección de eventos de Shield Avanzado. Si bien la mitigación automática está habilitada, esta regla limita la frecuencia de las direcciones IP que se sabe que son fuentes de ataques DDo S. Para estas direcciones IP, la limitación de velocidad de la regla puede evitar los ataques y también evitar que los ataques aparezcan en la información de detección de Shield Avanzado. Esta compensación favorece la prevención por encima de la visibilidad total de los patrones de ataque.
Además de la regla permanente basada en la tasa descrita anteriormente, el grupo de reglas contiene todas las reglas que Shield Advanced esté utilizando actualmente para mitigar los ataques DDo S. Shield Avanzado agrega, modifica y elimina estas reglas según sea necesario. Para obtener información, consulte [Cómo administra Shield Avanzado la mitigación automática](ddos-automatic-app-layer-response-behavior.md).
**Métricas**
El grupo de reglas genera AWS WAF métricas, pero como este grupo de reglas es propiedad de Shield Advanced, estas métricas no están disponibles para su visualización. Para obtener más información, consulte [AWS WAF métricas y dimensiones](waf-metrics.md).
# Visualización de la configuración de mitigación automática de la capa DDo S de aplicación para un recurso
Puede ver la configuración de mitigación automática de la capa DDo S de aplicación de un recurso en la página **Recursos protegidos** y en las páginas de protecciones individuales.
**Para ver la configuración de mitigación automática de la capa DDo S de aplicación**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Recursos protegidos**. En la lista de recursos protegidos, la columna **Mitigación automática de la capa DDo S de aplicación** indica si la mitigación automática está habilitada y, si está habilitada, la acción que Shield Advanced utilizará en sus mitigaciones.
También puede seleccionar cualquier recurso de la capa de aplicación para ver la misma información que aparece en la página de protecciones del recurso.
# Activación y desactivación de la mitigación automática de la capa DDo S de aplicación
En el siguiente procedimiento, se muestra cómo habilitar o deshabilitar la respuesta automática de un recurso protegido.
**Para habilitar o deshabilitar la mitigación automática de la capa DDo S de aplicación para un solo recurso**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Recursos protegidos**.
1. En la pestaña **Protecciones**, seleccione el recurso de capa de aplicación para el que desee habilitar la mitigación automática. Se abre la página de protecciones del recurso.
1. En la página de protecciones del recurso, elija **Editar**.
1. En la página **Configurar la mitigación de la capa 7 DDo para los recursos globales *(opcional)***, para la **mitigación automática de la capa DDo S de aplicaciones**, elija la opción que desee utilizar para las mitigaciones automáticas. Las opciones de la consola son las siguientes:
+ **Mantener la configuración actual**: no se realizan cambios en la configuración de mitigación automática del recurso protegido.
+ **Habilitar**: se habilita la mitigación automática para el recurso protegido. Al elegir esta opción, seleccione también la acción de regla que desee que utilicen las mitigaciones automáticas en las reglas de ACL web. Para obtener información sobre la configuración de las acciones de las reglas, consulte [Uso de acciones de reglas en AWS WAF](waf-rule-action.md).
Si su recurso protegido aún no tiene un historial del tráfico de aplicaciones habitual, active la mitigación automática en el modo Count hasta que Shield Avanzado pueda establecer una línea de base. Shield Avanzado comienza a recopilar información para la línea de base cuando asocia una ACL web a su recurso protegido, y puede demorar entre 24 horas y 30 días en establecer una buena línea de base del tráfico normal.
+ **Deshabilitar**: se deshabilita la mitigación automática del recurso protegido.
1. Recorra el resto de páginas hasta que termine y guarde la configuración.
En la página **Protecciones**, se actualiza la configuración de mitigación automática del recurso.
# Cambiar la acción utilizada para la mitigación automática de la capa DDo S de aplicación
Puede cambiar la acción que Shield Avanzado utiliza para la respuesta automática de la capa de aplicación en varias ubicaciones de la consola:
+ **Configuración de mitigación automática**: cambie la acción al configurar la mitigación automática para su recurso. Para conocer el procedimiento, consulte la sección anterior [Activación y desactivación de la mitigación automática de la capa DDo S de aplicación](enable-disable-automatic-app-layer-response.md).
+ **Página de detalles del evento**: cambie la acción en la página de detalles del evento cuando vea la información del evento en la consola. Para obtener información, consulte [Visualización de los detalles del AWS Shield Advanced evento](ddos-event-details.md).
Si tiene dos recursos protegidos que comparten una ACL web y establece la acción Count en uno y Block en el otro, Shield Avanzado establece la acción de la regla basada en tasas del grupo de reglas `ShieldKnownOffenderIPRateBasedRule` a Block.
# Uso AWS CloudFormation con mitigación automática de la capa DDo S de aplicación
En esta página, se explica CloudFormation cómo administrar sus protecciones y su AWS WAF web ACLs.
**Activación o desactivación de la mitigación automática de la capa DDo S de aplicación**
Puede activar y desactivar la mitigación automática de la capa DDo S de aplicación mediante el `AWS::Shield::Protection` recurso. AWS CloudFormation El efecto es el mismo que cuando se habilita o deshabilita la característica a través de la consola o cualquier otra interfaz. Para obtener información sobre el CloudFormation recurso, consulte [AWS::Shield::Protection](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-shield-protection.html)la *guía del AWS CloudFormation usuario*.
**Gestión de la web ACLs utilizada con mitigación automática**
Shield Advanced administra la mitigación automática de su recurso protegido mediante una regla de grupo de reglas en la ACL AWS WAF web del recurso protegido. A través de la AWS WAF consola APIs, verá la regla incluida en las reglas de su ACL web, con un nombre que comience por`ShieldMitigationRuleGroup`. Esta regla está dedicada a la mitigación automática de la capa DDo S de aplicación y Shield Advanced y Shield Advanced y AWS WAF. Para obtener más información, consulte [Protección de la capa de aplicaciones con el grupo de reglas de Shield Avanzado](ddos-automatic-app-layer-response-rg.md) y [Cómo administra Shield Avanzado la mitigación automática](ddos-automatic-app-layer-response-behavior.md).
Si lo usa CloudFormation para administrar su web ACLs, no agregue la regla de grupo de reglas Shield Advanced a su plantilla de ACL web. Cuando actualizas una ACL web que se está utilizando con tus protecciones de mitigación automática, administra AWS WAF automáticamente la regla del grupo de reglas en la ACL web.
Verás las siguientes diferencias en comparación con otras páginas web a través de las ACLs que gestionas CloudFormation:
+ CloudFormation no mostrará ningún desfase en el estado de desviación de la pila entre la configuración real de la ACL web, con la regla del grupo de reglas Shield Advanced, y la plantilla de ACL web, sin la regla. La regla de Shield Avanzado no aparecerá en los detalles de desviación de la lista del recurso.
Podrá ver la regla del grupo de reglas Shield Advanced en las listas de ACL web de las que accede AWS WAF, por ejemplo, a través de la AWS WAF consola o AWS WAF APIs.
+ Si modifica la plantilla de ACL web de una pila AWS WAF y Shield Advanced mantiene automáticamente la regla de mitigación automática de Shield Advanced en la ACL web actualizada. Las protecciones de mitigación automática ofrecidas por Shield Avanzado no se ven interrumpidas por la actualización de la ACL web.
No administre la regla Shield Advanced en su plantilla de ACL CloudFormation web. La plantilla de la ACL web no debe incluir la regla de Shield Avanzado. Siga las prácticas recomendadas para la administración de ACL web en [Mejores prácticas para utilizar la mitigación automática de la capa DDo S de aplicación](ddos-automatic-app-layer-response-bp.md).
# Detección basada en el estado mediante comprobaciones de estado con Shield Avanzado y Route 53
Puede configurar Shield Avanzado para que utilice la detección basada en el estado a fin de mejorar la capacidad de respuesta y la precisión en la detección y mitigación de ataques. Puede usar esta opción con cualquier tipo de recurso, excepto en las zonas alojadas en Route 53.
Para configurar la detección basada en el estado, defina una comprobación de estado de su recurso en Route 53, compruebe que el informe esté en buen estado y, a continuación, asociarla a su protección Shield Avanzado. Para obtener información sobre las comprobaciones de estado de Route 53, consulte [Cómo comprueba Amazon Route 53 el estado de sus recursos](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html) y [Cómo crear, actualizar y eliminar las comprobaciones de estado](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html) en la Guía para desarrolladores de Amazon Route 53.
**nota**
Se requieren comprobaciones de estado para poder contar con el apoyo proactivo del equipo de respuesta de Shield (SRT). Para obtener información sobre la interacción proactiva, consulte [Configuración de una interacción proactiva para que el SRT se ponga en contacto con usted directamente](ddos-srt-proactive-engagement.md).
Las comprobaciones de estado miden el estado de los recursos en función de los requisitos que defina. El estado de la comprobación de estado proporciona información crucial a los mecanismos de detección Shield Avanzado, lo que les da una mayor sensibilidad al estado actual de sus aplicaciones específicas.
Puede habilitar la detección basada en el estado para cualquier tipo de recurso, excepto para las zonas alojadas en Route 53.
+ **Recursos de la capa de red y transporte (capa 3/capa 4)**: la detección basada en el estado mejora la precisión de la detección y la mitigación de eventos en las capas de red y transporte para los equilibradores de carga de red, las direcciones IP elásticas y los aceleradores estándar de Global Accelerator. Al proteger estos tipos de recursos con Shield Avanzado, Shield Avanzado puede proporcionar mitigaciones para ataques más pequeños y una mitigación más rápida para los ataques, incluso cuando el tráfico está dentro de la capacidad de la aplicación.
Cuando agrega la detección basada en estado, durante los períodos en los que la comprobación de estado se registra como en mal estado, Shield Avanzado puede aplicar mitigaciones aún más rápidamente y en umbrales más bajos.
+ **Recursos de la capa de aplicación (capa 7)**: la detección basada en el estado mejora la precisión de la detección de inundaciones de solicitudes web para CloudFront distribuciones y balanceadores de carga de aplicaciones. Al proteger estos tipos de recursos con Shield Avanzado, recibirá alertas de detección de inundaciones por solicitudes web cuando haya una desviación estadísticamente significativa en el volumen de tráfico que se combine con cambios significativos en los patrones de tráfico, según las características de la solicitud.
Con la detección basada en estado, durante los períodos en que la comprobación de estado de Route 53 asociada se registra como en mal estado, Shield Avanzado requiere desviaciones más pequeñas para enviar alertas de los eventos y registrarlos con mayor rapidez. Cuando la comprobación de estado de Route 53 se registra como en buen estado, Shield Avanzado requiere desviaciones mayores para enviar alertas.
Lo que más le beneficiará es utilizar una comprobación de estado con Shield Avanzado si la comprobación de estado solo informa de que está en buen estado cuando la aplicación se ejecuta dentro de los parámetros aceptables y solo informa de que está en mal estado cuando no lo está. Utilice las instrucciones de esta sección para gestionar sus asociaciones de comprobación de estado en Shield Avanzado.
**nota**
Shield Avanzado no gestiona automáticamente sus comprobaciones de estado.
Para poder realizar una comprobación de estado con Shield Avanzado, se requiere lo siguiente:
+ La comprobación de estado debe ser correcta cuando la asocie a su protección Shield Avanzado.
+ La comprobación de estado debe ser relevante para el estado de su recurso protegido. Es responsable de definir y mantener las comprobaciones de estado que informen con precisión sobre el estado de su aplicación, en función de los requisitos específicos de la aplicación.
+ La comprobación de estado debe permanecer disponible para que la utilice la protección Shield Avanzado. No elimine una comprobación de estado en Route 53 que esté utilizando para la protección de Shield Avanzado.
**Contents**
+ [Prácticas recomendadas para utilizar comprobaciones de estado con Shield Avanzado](health-checks-best-practices.md)
+ [CloudWatch métricas que se utilizan habitualmente para los controles de estado con Shield Advanced](health-checks-metrics.md)
+ [Métricas utilizadas en la supervisión el estado de la aplicación](health-checks-metrics.md#health-checks-metrics-common)
+ [CloudWatch Métricas de Amazon para cada tipo de recurso](health-checks-metrics.md#health-checks-protected-resource-metrics)
+ [Asociación de una comprobación de estado a su recurso protegido por Shield Avanzado](associate-health-check.md)
+ [Desasociación de una comprobación de estado de un recurso protegido por Shield Avanzado](disassociate-health-check.md)
+ [Visualización del estado de la asociación de comprobación de estado en Shield Avanzado](health-check-association-status.md)
+ [Ejemplos de comprobación de estado para Shield Avanzado](health-checks-examples.md)
+ [CloudFront Distribuciones de Amazon](health-checks-examples.md#health-checks-example-cloudfront)
+ [Equilibradores de carga](health-checks-examples.md#health-checks-example-load-balancer)
+ [Dirección IP EC2 elástica (EIP) de Amazon](health-checks-examples.md#health-checks-example-elastic-ip)
# Prácticas recomendadas para utilizar comprobaciones de estado con Shield Avanzado
Siga las prácticas recomendadas de esta sección cuando cree y utilice comprobaciones de estado con Shield Avanzado.
+ Planifique sus comprobaciones de estado identificando los componentes de su infraestructura que desea supervisar. Tenga en cuenta los siguientes tipos de recursos para las comprobaciones de estado:
+ Recursos cruciales.
+ Cualquier recurso en el que desees una mayor sensibilidad en la detección y mitigación de Shield Avanzado.
+ Recursos para los que quieres que Shield Avanzado se ponga en contacto contigo de forma proactiva. El estado de las comprobaciones de estado se basa en el estado de las comprobaciones de estado.
Entre los ejemplos de recursos que puede que desee supervisar se incluyen CloudFront las distribuciones de Amazon, los balanceadores de carga con acceso a Internet y las instancias de Amazon EC2.
+ Defina comprobaciones de estado que reflejen con precisión el estado del origen de su aplicación con el menor número de notificaciones posible.
+ Realiza comprobaciones de estado para que solo estén en mal estado cuando la aplicación no esté disponible o no funcione dentro de los parámetros aceptables. Es responsable de definir y mantener las comprobaciones de estado en función de los requisitos específicos de su aplicación.
+ Realice el menor número posible de comprobaciones de estado y, al mismo tiempo, informe con precisión sobre el estado de su aplicación. Por ejemplo, varias alarmas de varias áreas de la aplicación que informen sobre el mismo problema podrían sobrecargar sus actividades de respuesta sin añadir valor informativo.
+ Usa controles de estado calculados para monitorear el estado de las aplicaciones mediante una combinación de CloudWatch métricas de Amazon. Por ejemplo, puede calcular el estado combinado en función de la latencia de los servidores de aplicaciones y sus tasas de error de 5 veces mayores, lo que indica que el servidor de origen no atendió la solicitud.
+ Cree y publique sus propios indicadores de estado de la aplicación en métricas CloudWatch personalizadas según sea necesario y utilícelos en una comprobación de estado calculada.
+ Implemente y gestione sus comprobaciones de estado para mejorar la detección y reducir las actividades de mantenimiento innecesarias.
+ Antes de asociar una comprobación de estado a una protección Shield Avanzado, asegúrate de que se encuentre en buen estado. Asociar una comprobación de estado que indique que no está funcionando puede sesgar los mecanismos de detección de Shield Avanzado para sus recursos protegidos.
+ Mantenga sus controles de salud disponibles para que los utilice Shield Avanzado. No elimine una comprobación de estado en Route 53 que esté utilizando para la protección de Shield Avanzado.
+ Utilice los entornos de ensayo y pruebe únicamente para comprobar sus comprobaciones de estado. Mantenga asociaciones de comprobación de estado únicamente para entornos que requieran un rendimiento y una disponibilidad de producción. No mantenga una asociación de comprobación de estado en Shield Avanzado para los entornos de ensayo y prueba.
# CloudWatch métricas que se utilizan habitualmente para los controles de estado con Shield Advanced
En esta sección se enumeran las CloudWatch métricas de Amazon que se utilizan habitualmente en las comprobaciones de estado para medir el estado de las aplicaciones durante los eventos de denegación de servicio (DDoS) distribuida. Para obtener información completa sobre las CloudWatch métricas de cada tipo de recurso, consulta la lista que sigue a la tabla.
**Topics**
+ [Métricas utilizadas en la supervisión el estado de la aplicación](#health-checks-metrics-common)
+ [CloudWatch Métricas de Amazon para cada tipo de recurso](#health-checks-protected-resource-metrics)
## Métricas utilizadas en la supervisión el estado de la aplicación
| Recurso | Métrica | Description (Descripción) |
| --- | --- | --- |
| Route 53 | `HealthCheckStatus` | El estado del punto de conexión de comprobación de estado. |
| CloudFront | `5xxErrorRate` | El porcentaje de todas las solicitudes para las que el código de estado de HTTP es 5xx. Esto indica que se trata de un ataque que está afectando a la aplicación. |
| Equilibrador de carga de aplicación | `HTTPCode_ELB_5XX_Count` | El número de códigos de error del cliente HTTP 5XX generados por el equilibrador de carga. |
| Equilibrador de carga de aplicación | `RejectedConnectionCount` | El número de conexiones que se rechazaron porque el equilibrador de carga alcanzó el número máximo de conexiones. |
| Equilibrador de carga de aplicación | `TargetConnectionErrorCount` | El número de conexiones que no se establecieron correctamente entre el equilibrador de carga y el destino. |
| Equilibrador de carga de aplicación | `TargetResponseTime` | El tiempo transcurrido, en segundos, desde que la solicitud abandona el equilibrador de carga hasta que se recibe una respuesta del destino. |
| Equilibrador de carga de aplicación | `UnHealthyHostCount` | El número de destinos que se considera que no están en buen estado. |
| Amazon EC2 | `CPUUtilization` | El porcentaje de unidades de EC2 cómputo asignadas que están actualmente en uso. |
## CloudWatch Métricas de Amazon para cada tipo de recurso
Para obtener información adicional sobre las métricas disponibles para sus recursos protegidos, consulte las siguientes secciones de las guías de recursos:
+ Amazon Route 53: [monitoriza tus recursos con los controles de estado de Amazon Route 53 y Amazon CloudWatch](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html) en la guía para desarrolladores de Amazon Route 53.
+ Amazon CloudFront : [Monitorización CloudFront con Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/monitoring-using-cloudwatch.html) en la Guía para CloudFront desarrolladores de Amazon.
+ Application Load Balancer: [CloudWatch métricas de su Application Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) Balancer en la guía del usuario de Application Load Balancer.
+ Network Load Balancer: [CloudWatch métricas de su Network Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) Balancer en la Guía del usuario de Network Load Balancer.
+ AWS Global Accelerator — [Uso de Amazon CloudWatch con AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/cloudwatch-monitoring.html) la Guía para AWS Global Accelerator desarrolladores.
+ Amazon Elastic Compute Cloud: [muestra las CloudWatch métricas disponibles para tus instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) en la https://docs.aws.amazon.com/AWSEC2/ última UserGuide actualización/ /.
+ Amazon EC2 Auto Scaling: [monitorea CloudWatch las métricas de tus grupos e instancias de Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) en la Guía del usuario de Amazon EC2 Auto Scaling.
# Asociación de una comprobación de estado a su recurso protegido por Shield Avanzado
El procedimiento siguiente muestra cómo asociar una comprobación de estado de Amazon Route 53 a una protección.
**nota**
Antes de asociar una comprobación de estado a una protección Shield Avanzado, asegúrate de que se encuentre en buen estado. Para obtener información, consulte [Supervisión del estado de las comprobaciones de estado y recepción de notificaciones](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html) en la Guía para desarrolladores de Amazon Route 53.
**Asociación de una comprobación de estado**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Recursos protegidos**.
1. En la pestaña **Protecciones**, seleccione el recurso que desee asociar a una comprobación de estado.
1. Elija **Configurar las protecciones**.
1. Seleccione **Siguiente** hasta llegar a la página **Configurar la detección DDo S basada en controles de estado *(opcional)***.
1. En **Associated Health Check (Comprobación de estado asociada)**, elija el identificador de la comprobación de estado que desea asociar a la protección.
**nota**
Si no ve la comprobación de estado que necesita, vaya a la consola de Route 53 y verifique la comprobación de estado y su ID. Para obtener más información, consulte [Creación y actualización de comprobaciones de estado](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html).
1. Recorra el resto de las páginas hasta que termine la configuración. En la página de **Protecciones**, aparece la asociación de comprobación de estado actualizada del recurso.
1. En la página de **Protecciones**, compruebe que la comprobación de estado que acaba de asociar esté funcionando correctamente.
No puede empezar a utilizar correctamente una comprobación de estado en Shield Avanzado mientras la comprobación de estado indica que no funciona correctamente. Si lo hace, Shield Avanzado detecta falsos positivos en umbrales muy bajos y también puede afectar negativamente a la capacidad del equipo de respuesta de Shield (SRT) de interactuar proactivamente con el recurso.
Si la nueva comprobación de estado asociada indica que no es correcto, haga lo siguiente:
1. Desvincule la comprobación de estado de su protección en Shield Avanzado.
1. Revisite las especificaciones de las comprobaciones de estado en Amazon Route 53 y compruebe el rendimiento y la disponibilidad generales de la aplicación.
1. Cuando su aplicación funcione dentro de sus parámetros de buen estado y su comprobación de estado informe que funciona correctamente, intente de nuevo asociar la comprobación de estado en Shield Avanzado.
El procedimiento de asociación de comprobación de estado estará completo cuando haya establecido su nueva asociación de comprobación de estado y se notifique que está en buen estado en Shield Avanzado.
# Desasociación de una comprobación de estado de un recurso protegido por Shield Avanzado
El siguiente procedimiento muestra cómo desasociar una comprobación de estado de Amazon Route 53 de un recurso protegido.
**Desasociación de una comprobación de estado**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Recursos protegidos**.
1. En la pestaña **Protecciones**, seleccione el recurso que desee desasociar de una comprobación de estado.
1. Elija **Configurar las protecciones**.
1. Seleccione **Siguiente** hasta llegar a la página **Configurar la detección DDo S basada en controles de estado *(opcional)***.
1. En **comprobación de estado asociada**, elija la opción vacía, que aparece como **-**.
1. Recorra el resto de las páginas hasta que termine la configuración.
En la página **Protecciones**, el campo de comprobación de estado del recurso está establecido en **-**, lo que indica que no hay ninguna asociación de comprobación de estado.
# Visualización del estado de la asociación de comprobación de estado en Shield Avanzado
Puede ver el estado de la comprobación de estado asociada a una protección en la página de **recursos protegidos** de la consola de Shield AWS WAF y en la página de detalles de cada recurso.
+ **Saludable**: la comprobación de estado está disponible y se indica que es correcto.
+ **Insalubre**: la comprobación de estado está disponible y se indica que no es saludable.
+ **No disponible**: Shield Avanzado no puede utilizar la comprobación de estado.
**Para resolver una comprobación de estado **no disponible****
Crear y utilizar una nueva comprobación de estado. No intente volver a asociar una comprobación de estado después de que haya tenido el estado de no disponible en Shield Avanzado.
Para obtener instrucciones detalladas acerca de cómo seguir estos pasos, consulte los temas anteriores.
1. En Shield Avanzado, desasocie la comprobación de estado del recurso.
1. A continuación, en Route 53, cree una nueva comprobación de estado para la protección y anote su ID. Para obtener información, consulte [Creación y actualización de comprobaciones de estado](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html) en la Guía para desarrolladores de Amazon Route 53.
1. En Shield Avanzado, asociamos la comprobación de estado nueva con el recurso.
# Ejemplos de comprobación de estado para Shield Avanzado
En esta sección se muestran ejemplos de comprobaciones de estado que puede utilizar en una comprobación de estado calculada. Una comprobación de estado calculada utiliza una serie de comprobaciones de estado individuales para determinar un estado combinado. El estado de cada control de estado individual se basa en el estado de un punto final o en el estado de una CloudWatch métrica de Amazon. Las comprobaciones de estado se combinan en un control de estado calculado y, a continuación, se configura el control de estado calculado para informar sobre el estado de salud en función del estado de salud combinado de las comprobaciones de estado individuales. Ajuste la sensibilidad de las comprobaciones de estado calculadas en función de sus requisitos de rendimiento y disponibilidad de las aplicaciones.
Para obtener información sobre las comprobaciones de estado calculadas, consulte [Supervisión de otras comprobaciones de estado (comprobaciones de estado calculadas)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-calculated) en la Guía para desarrolladores de Amazon Route 53. Para obtener información adicional, consulte la entrada del blog [Route 53 Improvements: Calculated Health Checks and Latency Checks](https://aws.amazon.com/blogs/aws/route-53-improvements-calculated-health-checks-and-latency-checks/).
**Topics**
+ [CloudFront Distribuciones de Amazon](#health-checks-example-cloudfront)
+ [Equilibradores de carga](#health-checks-example-load-balancer)
+ [Dirección IP EC2 elástica (EIP) de Amazon](#health-checks-example-elastic-ip)
## CloudFront Distribuciones de Amazon
Los siguientes ejemplos describen los controles de estado que podrían combinarse en un control de estado calculado para una CloudFront distribución:
+ Supervise un punto de conexión especificando un nombre de dominio en una ruta de la distribución que ofrece contenido dinámico. Una respuesta correcta incluiría los códigos de respuesta HTTP 2xx y 3xx.
+ Supervisa el estado de una CloudWatch alarma que mide el estado del CloudFront origen. Por ejemplo, puede mantener una CloudWatch alarma en la métrica `TargetResponseTime` Application Load Balancer y crear una comprobación de estado que refleje el estado de la alarma. La comprobación de estado puede no funcionar correctamente cuando el tiempo de respuesta, entre la solicitud que sale del equilibrador de carga y el momento en que el equilibrador de carga recibe una respuesta del objetivo, supera el umbral configurado en la alarma.
+ Supervisa el estado de una CloudWatch alarma que mide el porcentaje de solicitudes para las que el código de estado HTTP de la respuesta es 5xx. Si la tasa de error de 5xx de la CloudFront distribución es superior al umbral definido en la CloudWatch alarma, el estado de esta comprobación de estado pasará a ser insalubre.
## Equilibradores de carga
Los siguientes ejemplos describen las comprobaciones de estado que podrían usarse en las comprobaciones de estado calculadas para un acelerador estándar del Equilibrador de carga de aplicación, Equilibrador de carga de red o Global Accelerator.
+ Supervise el estado de una CloudWatch alarma que mide la cantidad de nuevas conexiones establecidas por los clientes al balanceador de carga. Puede establecer el umbral de alarma para el número medio de conexiones nuevas en un grado superior al promedio diario. Las métricas para cada tipo de recurso son las siguientes:
+ Equilibrador de carga de aplicación: `NewConnectionCount`
+ Equilibrador de carga de red: `ActiveFlowCount`
+ Global Accelerator: `NewFlowCount`
+ En el caso de Application Load Balancer y Network Load Balancer, supervise el estado de CloudWatch una alarma que mida la cantidad de balanceadores de carga que se consideran en buen estado. Puede configurar el umbral de alarma en la zona de disponibilidad o en la cantidad mínima de hosts en buen estado que requiere el equilibrador de carga. Las métricas disponibles para los recursos del equilibrador de carga son las siguientes:
+ Equilibrador de carga de aplicación: `HealthyHostCount`
+ Equilibrador de carga de red: `HealthyHostCount`
+ En el caso de Application Load Balancer, supervise el estado de una CloudWatch alarma que mida la cantidad de códigos de respuesta HTTP 5xx generados por los objetivos del balanceador de carga. Para un Equilibrador de carga de aplicación, puede usar la métrica `HTTPCode_Target_5XX_Count` y basar el umbral de alarma en la suma de todos los 5xx errores del equilibrador de carga.
## Dirección IP EC2 elástica (EIP) de Amazon
Los siguientes ejemplos de comprobaciones de estado podrían combinarse en una comprobación de estado calculada para una dirección IP EC2 elástica de Amazon:
+ Para supervisar un punto de conexión, especifique una dirección IP para la dirección IP elástica. La comprobación de estado se mantendrá en buen estado siempre que se pueda establecer una conexión TCP con el recurso detrás de la dirección IP.
+ Supervisa el estado de una CloudWatch alarma que mide el porcentaje de unidades EC2 informáticas de Amazon asignadas que se utilizan actualmente en la instancia. Puedes usar la EC2 métrica de Amazon `CPUUtilization` y basar el umbral de alarma en lo que consideres una tasa alta de uso de la CPU para tu aplicación, como el 90%.
# Añadir AWS Shield Advanced protección a AWS los recursos
Sigue las instrucciones de esta sección para añadir la protección Shield Avanzado a uno o más recursos.
**Para añadir protección a un AWS recurso**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel de navegación, AWS Shield seleccione **Recursos protegidos**.
1. Seleccione **Añadir recursos para proteger**.
1. En la página **Elegir los recursos que se protegerán con Shield Avanzado**, en **Especificar la región y los tipos de recursos**, proporcione las especificaciones de región y de tipo de recurso de los recursos que desea proteger. Puede proteger los recursos de varias regiones seleccionando **Todas las regiones** y puede limitar la selección a los recursos globales seleccionando **Global**. Puede deseleccionar cualquier tipo de recurso que no desee proteger. Para obtener información sobre las protecciones de sus tipos de recursos, consulte [Lista de recursos que AWS Shield Advanced protegen](ddos-protections-by-resource-type.md).
1. Elija **Cargar recursos**. Shield Avanzado rellena la sección **Seleccionar recursos** con los recursos de AWS que coinciden con sus criterios.
1. En la sección **Seleccionar recursos**, puede filtrar la lista de recursos introduciendo una cadena para buscarla en las listas de recursos.
Seleccione los recursos que desea proteger.
1. En la sección **Etiquetas**, si desea agregar etiquetas a las protecciones Shield Avanzado que está creando, especifíquelas. Para obtener información acerca de cómo etiquetar los recursos de AWS , consulte [Uso de Tag Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).
1. Elija **Proteger con Shield Avanzado**. Esto agrega las protecciones de Shield Avanzado a los recursos.
# Edición de AWS Shield Advanced protecciones
Puedes cambiar la configuración de tus AWS Shield Advanced protecciones en cualquier momento. Para ello, debe recorrer las opciones de todas las protecciones seleccionadas y modificar la configuración que necesite cambiar.
**Administración de recursos protegidos**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Recursos protegidos**.
1. En la pestaña **Protecciones**, seleccione los recursos que desea proteger.
1. Elija **Configurar las protecciones** y la opción de especificación de recursos que desee.
1. Revise cada una de las opciones de protección de recursos y realice los cambios necesarios.
## Configure las protecciones de la capa DDo S de aplicación
Para protegerse contra los ataques a los recursos de Amazon CloudFront y Application Load Balancer, puede añadir reglas AWS WAF web ACLs y reglas basadas en tarifas. Para obtener información acerca de este tema, consulte [Protección de la capa de aplicaciones con AWS WAF web ACLs y Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
También puede activar la mitigación automática de la capa DDo S de la aplicación Shield Advanced. Para obtener información sobre cómo AWS WAF funciona, consulte[AWS WAF](waf-chapter.md). Para obtener información sobre la característica de mitigación automática, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
**importante**
Si administra sus protecciones de Shield Advanced AWS Firewall Manager mediante una política de Shield Advanced, no podrá administrar las protecciones de la capa de aplicación aquí. Para todos los demás recursos, recomendamos que, como mínimo, adjunte una ACL web a cada recurso, incluso si la ACL web no contiene ninguna regla.
**nota**
Cuando habilita la mitigación automática de la capa DDo S de aplicación para un recurso, si es necesario, la operación agrega automáticamente un rol vinculado a un servicio a su cuenta para otorgar a Shield Advanced los permisos que necesita para administrar sus protecciones de ACL web. Para obtener información, consulte [Uso de roles vinculados a servicios para Shield Avanzado](shd-using-service-linked-roles.md).
**Para configurar las protecciones de la capa S de DDo aplicaciones**
1. En la página **Configurar las protecciones de la capa 7 DDo S**, si el recurso aún no está asociado a una ACL web, puede elegir una ACL web existente o crear la suya propia.
Para crear una ACL web, siga estos pasos:
1. Elija **Create web ACL (Crear ACL web)**.
1. Escriba un nombre. No se puede cambiar el nombre después de crear la ACL web.
1. Seleccione **Crear**.
**nota**
Si un recurso ya está asociado a una ACL web, no puede cambiar a otra ACL web. Si desea cambiar la ACL web, primero debe eliminar la web asociada ACLs del recurso. Para obtener más información, consulte [Asociar o disociar la protección a un recurso AWS](web-acl-associating-aws-resource.md).
1. Si la ACL web no tiene definida una regla basada en la velocidad, puede agregar una. Para ello, seleccione **Añadir regla basada en tasas** y, a continuación, lleve a cabo los siguientes pasos:
1. Escriba un nombre.
1. Escriba un límite de frecuencia. Esta es la cantidad máxima de solicitudes permitidas en cualquier período de cinco minutos desde cualquier dirección IP antes de que se aplique la acción de regla basada en tasas a la dirección IP. Cuando las solicitudes de la dirección IP caen por debajo del límite, la acción se interrumpe.
1. Establezca la acción de regla para contar o bloquear solicitudes de direcciones IP cuando sus recuentos de solicitudes superen el límite. La acción de aplicación y eliminación de la regla puede tener efecto uno o dos minutos después de que cambie la tasa de solicitudes de direcciones IP.
1. Seleccione **Agregar regla**.
1. Para la **mitigación automática de la capa DDo S de aplicación**, elija si quiere que Shield Advanced mitigue automáticamente los ataques DDo S en su nombre, de la siguiente manera:
+ Para activar la mitigación automática, elija **Activar** y, a continuación, seleccione la acción de AWS WAF regla que quiere que Shield Advanced utilice en sus reglas personalizadas. Sus opciones son Count y Block. Para obtener información sobre estas acciones de AWS WAF regla, consulte[Uso de acciones de reglas en AWS WAF](waf-rule-action.md). Para obtener información sobre cómo Shield Avanzado administra esta configuración de acción, consulte [Cómo Shield Avanzado administra la configuración de acciones de las reglas](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action).
+ Para deshabilitar la mitigación automática, seleccione **Desactivar**.
+ Para dejar la configuración de mitigación automática sin cambios para los recursos que está administrando, deje la opción predeterminada **Mantener la configuración actual**.
Para obtener información sobre la mitigación automática de la capa DDo S de aplicaciones de Shield Advanced, consulte[Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
1. Elija **Siguiente**.
# Creación de alarmas y notificaciones para los recursos protegidos por Shield Avanzado
El siguiente procedimiento muestra cómo administrar CloudWatch las alarmas de los recursos protegidos.
**nota**
CloudWatch incurre en costes adicionales. Para CloudWatch conocer los precios, consulta [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
**Creación de notificaciones y alarmas de Amazon**
1. En la página de protecciones **Crear alarmas y notificaciones de Amazon CloudWatch *(opcional)***, configure los temas de SNS para las alarmas y notificaciones que desea recibir. Para los recursos para los que no desea recibir notificaciones, elija **Ningún tema**. Puede añadir un tema de Amazon SNS o crear uno nuevo.
1. Para crear un tema de Amazon SNS, siga estos pasos:
1. En la lista desplegable, seleccione **Crear nuevo tema**.
1. Escriba un nombre de tema.
1. Opcionalmente, escriba una dirección de correo electrónico a la que se enviarán los mensajes de Amazon SNS y, a continuación, elija **Añadir dirección de correo electrónico**. Puede introducir más de una.
1. Seleccione **Crear**.
1. Elija **Siguiente**.
# Eliminar AWS Shield Advanced la protección de un AWS recurso
Puede eliminar AWS Shield Advanced la protección de cualquiera de sus AWS recursos en cualquier momento.
**importante**
Al eliminar un AWS recurso, no se elimina el recurso de AWS Shield Advanced. También debe quitar la protección del recurso AWS Shield Advanced, tal y como se describe en este procedimiento.
**Quitar AWS Shield Advanced la protección de un AWS recurso**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Recursos protegidos**.
1. En la pestaña **Protecciones**, seleccione los recursos cuyas protecciones desee eliminar.
1. Elija **Eliminar protección**.
1. Si tienes una CloudWatch alarma de Amazon configurada como protección, tienes la opción de eliminar la alarma junto con la protección. Si decides no eliminar la alarma en este momento, puedes eliminarla más adelante mediante la CloudWatch consola.
**nota**
En el caso de las protecciones que tienen configurada una comprobación de estado de Amazon Route 53, si agrega la protección de nuevo más adelante, la protección seguirá incluyendo la comprobación de estado.
Los pasos anteriores eliminan AWS Shield Advanced la protección de AWS recursos específicos. No cancelan tu AWS Shield Advanced suscripción. Se le seguirá cobrando por el servicio. Para obtener información sobre su AWS Shield Advanced suscripción, póngase en contacto con el [AWS Support Centro](https://console.aws.amazon.com/support/home#/).
## Eliminar una CloudWatch alarma de las protecciones Shield Advanced
Para eliminar una CloudWatch alarma de las protecciones Shield Advanced, realice una de las siguientes acciones:
+ Elimine la protección como se describe en [Eliminar AWS Shield Advanced la protección de un AWS recurso](#remove-protection). Asegúrese de seleccionar la casilla de verificación situada junto a **Eliminar también la DDo SDetection alarma relacionada**.
+ Elimine la alarma con la CloudWatch consola. Empieza por el nombre de la alarma que se va a eliminar **DDoSDetectedAlarmForProtection**.
# Agrupación de sus protecciones AWS Shield Advanced
Use los grupos de protección para crear colecciones lógicas de sus recursos protegidos y administre sus protecciones como un grupo. Para obtener más información sobre la administración de los recursos de protección, consulte [Edición de AWS Shield Advanced protecciones](manage-protection.md).
**nota**
La mitigación automática de la capa DDo S de aplicación no interactúa con los grupos de protección. Puede habilitar la mitigación automática para los recursos que se encuentran en grupos de protección, pero Shield Avanzado no aplica automáticamente mitigaciones de ataques en función de los resultados de los grupos de protección. Shield Avanzado aplica mitigaciones de ataque automáticas a recursos individuales.
AWS Shield Advanced Los grupos de protección ofrecen una forma de autoservicio de personalizar el alcance de la detección y la mitigación al tratar varios recursos protegidos como una sola unidad. La agrupación de recursos puede ofrecer una serie de ventajas.
+ Mejore la precisión de la detección.
+ Reduzca las notificaciones de eventos no procesables.
+ Aumente la cobertura de las acciones de mitigación para incluir los recursos protegidos que también podrían verse afectados durante un evento.
+ Acelere el tiempo necesario para mitigar los ataques con varios objetivos similares.
+ Facilite la protección automática de los recursos protegidos recién creados.
Los grupos de protección pueden ayudar a reducir los falsos positivos en situaciones como el blue/green intercambio, en el que los recursos alternan entre una carga casi nula o una carga completa. Otro ejemplo es cuando creas y eliminas recursos con frecuencia y, al mismo tiempo, mantienes un nivel de carga que comparten los miembros del grupo. En situaciones como estas, la supervisión de los recursos individuales puede generar falsos positivos, mientras que la supervisión del estado del grupo de recursos no.
Puede configurar los grupos de protección para que incluyan todos los recursos protegidos, todos los recursos de tipos de recursos específicos o los recursos especificados individualmente. Los recursos recién protegidos que cumplen los criterios del grupo de protección se incluyen automáticamente en el grupo de protección. Un recurso protegido puede pertenecer a varios grupos de protección.
# Creación de un grupo de protección Shield Avanzado
**Creación de un grupo de protección**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Recursos protegidos**.
1. Seleccione la pestaña **Grupos de protección** y, a continuación, seleccione **Crear grupo de protección**.
1. En la página **Crear grupo de protección**, proporcione un nombre para el grupo. Utilizará este nombre para identificar el grupo en su lista de recursos protegidos. No puede cambiar el nombre de un grupo de protección después de crearlo.
1. En cuanto a los **Criterios de agrupamiento de Protection**, seleccione los criterios que desee que Shield Avanzado utilice para identificar los recursos protegidos que desee incluir en el grupo. Realice las selecciones adicionales en función de los criterios que haya elegido.
1. En **Agregar**, seleccione cómo quiere que Shield Avanzado combine los datos de recursos del grupo para detectar, mitigar e informar sobre los eventos.
+ **Sumar**: utilice el tráfico total del grupo. Es una buena opción para la mayoría de los casos. Los ejemplos incluyen direcciones IP elásticas para EC2 instancias de Amazon que se escalan manual o automáticamente.
+ **Media**: utilice el promedio del tráfico en todo el grupo. Esta es una buena opción para los recursos que comparten el tráfico de manera uniforme. Algunos ejemplos son los aceleradores y los equilibradores de carga.
+ **Máximo**: utilice el tráfico más alto de cada recurso. Esto resulta útil para los recursos que no comparten tráfico y para los recursos que lo comparten de forma no uniforme. Algunos ejemplos son CloudFront las distribuciones de Amazon y los recursos de origen para las CloudFront distribuciones.
1. Elija **Guardar** para guardar el grupo de protección y volver a la página de **Recursos protegidos**.
En la página **Eventos** **Shield**, puede ver los eventos de su grupo de protección y profundizar para ver información adicional sobre los recursos protegidos que están en el grupo.
# Actualización de un grupo de protección Shield Avanzado
**Actualización de un grupo de protección**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Recursos protegidos**.
1. En la pestaña **Grupos de protección**, active la casilla de verificación situada al lado del grupo de protección que desea modificar.
1. En la página del grupo de protección, seleccione **Editar**. Realice los cambios que desee en la configuración del grupo de protección.
1. Elija **Guardar** para guardar los cambios.
# Eliminación de un grupo de protección de Shield Avanzado
**Eliminación de un grupo de protección**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Recursos protegidos**.
1. En la pestaña **Grupos de protección**, active la casilla de verificación situada al lado del grupo de protección que desea eliminar.
1. En la página del grupo de protección, seleccione **Eliminar** y confirme la acción.
# Cambios en la protección avanzada de recursos de Tracking Shield AWS Config
En esta página se explica cómo registrar los cambios en la AWS Shield Advanced protección de los recursos que utiliza AWS Config. A continuación, puede utilizar esta información para mantener un historial de cambios de configuración para auditoría y solución de problemas.
Para registrar los cambios de protección, AWS Config habilítelos para cada recurso del que desee realizar un seguimiento. Para obtener más información, consulte [Introducción a AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html) en la *Guía para desarrolladores de AWS Config *.
Debe habilitarlo AWS Config para cada uno de los Región de AWS que contengan los recursos rastreados. Puede activarlos AWS Config manualmente o utilizar la CloudFormation plantilla «Activar AWS Config» en la sección [Plantillas de CloudFormation StackSets muestra](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-sampletemplates.html) de la *Guía del CloudFormation usuario*.
Si la habilitas AWS Config, se te cobrará tal y como se detalla en la página de [AWS Config precios](https://aws.amazon.com/config/pricing/).
**nota**
Si ya has AWS Config activado las regiones y los recursos necesarios, no necesitas hacer nada. AWS Config los registros relacionados con los cambios de protección de sus recursos comienzan a rellenarse automáticamente.
Tras activarla AWS Config, utilice la región EE.UU. Este (Virginia del Norte) de la AWS Config consola para ver el historial de cambios de configuración de los recursos AWS Shield Advanced globales.
Consulte el historial de cambios de los recursos AWS Shield Advanced regionales a través de la AWS Config consola en las regiones EE.UU. Este (Norte de Virginia), EE.UU. Este (Ohio), EE.UU. Oeste (Oregón), EE.UU. Oeste (Norte de California), Europa (Irlanda), Europa (Fráncfort), Asia Pacífico (Tokio) y Asia Pacífico (Sídney).
# Visibilidad de DDo los eventos S con Shield Advanced
AWS Shield proporciona visibilidad sobre las siguientes categorías de eventos y actividades de eventos:
+ **Global**: todos los clientes pueden acceder a una visión agregada de la actividad de las amenazas globales durante las últimas dos semanas. Puede consultar esta información en las páginas de **introducción** y del **panel de control de amenazas globales** de la AWS Shield consola. Para obtener más información, consulte [Visualización de la actividad AWS Shield global y de la cuenta](ddos-standard-event-visibility.md).
+ **Cuenta**: todos los clientes pueden acceder a un resumen de los eventos de su cuenta durante el año anterior. Puede ver esta información en la página de **introducción** de la AWS Shield consola. Para obtener más información, consulte [Visualización de la actividad AWS Shield global y de la cuenta](ddos-standard-event-visibility.md).
Cuando se suscribe a Shield Advanced y añade protecciones a sus recursos, obtiene acceso a información adicional sobre los eventos y los ataques DDo S a los recursos protegidos:
+ **Eventos sobre recursos protegidos**: Shield Advanced proporciona información detallada de cada evento a través de la página **Eventos** de la AWS Shield consola. Para obtener más información, consulte [Visualización de AWS Shield Advanced eventos](ddos-events.md).
+ **Métricas de eventos para recursos protegidos**: Shield Advanced publica las CloudWatch métricas de detección, mitigación y principales contribuyentes de Amazon para todos los recursos que protege. Puede utilizar estas métricas para configurar CloudWatch cuadros de mando y alarmas. Para obtener más información, consulte [AWS Shield Advanced métricas](shield-metrics.md).
+ **Visibilidad de eventos entre cuentas para recursos protegidos**: si utiliza AWS Firewall Manager para administrar sus protecciones de Shield Advanced, puede habilitar la visibilidad de las protecciones en varias cuentas mediante el uso combinado AWS Security Hub CSPM de Firewall Manager. Para obtener más información, consulte [Visualización de los eventos de Shield Advanced en varios Cuentas de AWS con AWS Firewall Manager y AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md).
Si habilita la mitigación automática de la capa DDo S de aplicación para una protección de la capa de aplicación, Shield Advanced agrega un grupo de reglas a su paquete de protección (ACL web) que utiliza para administrar las protecciones automatizadas. Este grupo de reglas genera AWS WAF métricas, pero no se pueden ver. Esto es igual que para cualquier otro grupo de reglas que utilice en su paquete de protección (ACL web) pero que no sea de su propiedad, como los grupos de reglas de reglas AWS administradas. Para obtener más información sobre AWS WAF las métricas, consulte[AWS WAF métricas y dimensiones](waf-metrics.md). Para obtener información acerca de esta opción de protección de Shield Avanzado, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
**Topics**
+ [Visualización de la actividad AWS Shield global y de la cuenta](ddos-standard-event-visibility.md)
+ [Visualización de AWS Shield Advanced eventos](ddos-events.md)
+ [Visualización de los eventos de Shield Advanced en varios Cuentas de AWS con AWS Firewall Manager y AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md)
# Visualización de la actividad AWS Shield global y de la cuenta
En esta página se proporcionan instrucciones para acceder a una vista global de la actividad de las amenazas globales y a un resumen de los eventos por cuenta en las páginas de **introducción** y del **panel de control de amenazas globales** de la AWS Shield consola.
En la siguiente captura de pantalla se muestra un ejemplo de la página de **Introducción**.
![\[La AWS Shield consola muestra la página de introducción, que contiene los paneles de resumen de amenazas globales y eventos relacionados con la cuenta.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-console-global-account.png)
**Para acceder a la AWS Shield consola**
+ Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
No necesita una suscripción a Shield Avanzado para acceder a la información resumida de actividades globales y los eventos de las cuentas.
**Actividad global**
Esta información está disponible en el panel **global de amenazas de la AWS Shield consola** y en las páginas de **introducción**. En la siguiente captura de pantalla se muestra un ejemplo del panel de actividades globales.
![\[Un panel de AWS Shield consola titulado Actividad global detectada por Shield muestra un mapa mundial superpuesto por marcas de mapas térmicos de las áreas en las que se han detectado amenazas globales en las últimas dos semanas.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-console-global-activity.png)
La actividad global describe DDo los eventos observados en todos los clientes. AWS Una vez por hora, AWS actualiza la información de las dos semanas anteriores. En el panel de la consola, puedes ver los resultados, divididos por AWS región y mostrados en un mapa térmico mundial. Junto al mapa, Shield muestra información resumida, como el mayor ataque de paquetes, la mayor velocidad de bits, el vector más común, el número total de ataques y el nivel de amenaza. El nivel de amenaza es una evaluación de la actividad global actual en comparación con lo que AWS suele observar. El valor predeterminado del nivel de amenaza es **Normal.** AWS actualiza automáticamente el valor a **Alto** para una actividad DDo S elevada.
El **Panel de amenazas globales** también proporciona métricas de series temporales y le permite cambiar entre períodos de tiempo. Para ver el historial de los ataques DDo S más importantes, puede personalizar el panel de control para ver las vistas desde el último día hasta las dos últimas semanas. Las métricas de series temporales proporcionan una vista de la mayor velocidad de bits, velocidad de paquetes o tasa de solicitudes de todos los eventos detectados AWS Shield por las aplicaciones que se estén ejecutando AWS durante el período de tiempo que seleccione.
**Actividad de la cuenta**
Esta información está disponible en la página de **introducción** de la AWS Shield consola.
En la siguiente captura de pantalla se muestra un ejemplo del panel de actividades de la cuenta.
![\[Un panel de AWS Shield consola titulado Account activity detected by Shield muestra un resumen de los eventos del año pasado, con información como el número total de eventos y la mayor tasa de paquetes y solicitudes.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-console-account-activity.png)
La actividad de la cuenta describe los eventos DDo S que Shield detectó para tus recursos que son aptos para la protección de Shield Advanced. Todos los días, Shield crea métricas resumidas para el año que finalizó a las 00:00 UTC del día anterior y, a continuación, muestra el total de eventos, la velocidad de bits más alta, la velocidad de paquetes más alta y la tasa de solicitudes más alta.
+ La métrica total de eventos refleja cada vez que Shield detectó atributos sospechosos en el tráfico destinado a su aplicación. Los atributos sospechosos pueden incluir tráfico con un volumen superior al normal, tráfico que no coincida con el perfil histórico de la aplicación o tráfico que no coincida con las heurísticas definidas por Shield para el tráfico de aplicaciones válido.
+ Las estadísticas de mayor velocidad de bits y mayor velocidad de paquetes están disponibles para cada recurso.
+ La estadística de mayor tasa de solicitudes solo está disponible para CloudFront las distribuciones de Amazon y los balanceadores de carga de aplicaciones que tienen una ACL web asociada AWS WAF .
**nota**
También puede acceder al resumen de eventos a nivel de cuenta a través de la operación de la AWS Shield API. [DescribeAttackStatistics](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_DescribeAttack.html)
# Visualización de AWS Shield Advanced eventos
En esta página se proporcionan instrucciones para acceder a la información sobre los eventos en Shield Avanzado.
Cuando se suscribe a Shield Avanzado y protege sus recursos, obtiene acceso a características de visibilidad adicionales para los recursos. Estos incluyen notificaciones casi en tiempo real de los eventos detectados por Shield Avanzado e información adicional sobre los eventos detectados y las mitigaciones.
**nota**
La información de sus eventos en la consola de Shield Avanzado se basa en las métricas de Shield Avanzado. Para obtener información acerca de las métricas de Shield Avanzado, consulte [AWS Shield Advanced métricas](shield-metrics.md).
AWS Shield evalúa el tráfico hacia su recurso protegido en múltiples dimensiones. Cuando se detecta una anomalía, Shield Avanzado crea un evento independiente para cada recurso afectado.
Puede acceder a los resúmenes y detalles de los eventos a través de la página **Eventos** de la consola de Shield. La página **Eventos** de nivel superior proporciona una descripción general de los eventos actuales y pasados.
En la siguiente captura de pantalla se muestra un ejemplo de página de **Eventos** con un único evento en curso. Este evento activo también está marcado en el panel de navegación izquierdo.
![\[En el panel de navegación izquierdo de la AWS Shield consola, la selección de eventos está resaltada en rojo, con el número 1 al lado y dentro de un círculo rojo. La página Eventos está abierta y muestra una sola fila en la lista de eventos. La fila muestra un AWS recurso de tipo CloudFront distribución. El campo Estado actual contiene un icono rojo triangular junto a las palabras Mitigación en curso. El campo de Estado de los vectores de ataque contiene Tráfico de UDP. El campo Hora de inicio contiene 16 de septiembre de 2020 a las 14:43:00 SAST. El campo Duración contiene 6 minutos.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-console-event-summary1.png)
Shield Avanzado también puede aplicar automáticamente mitigaciones contra los ataques, según el tipo de tráfico y las protecciones configuradas. Estas mitigaciones pueden evitar que su recurso reciba un exceso de tráfico o tráfico que coincida con una firma de ataque DDo S conocida.
La siguiente captura de pantalla muestra un ejemplo de una lista **Eventos** de todos los eventos que Shield Avanzado mitigó o que disminuyeron por sí solos.
![\[Una página de AWS Shield consola llamada Eventos muestra los eventos que se han detectado recientemente y su estado actual.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-console-events.png)
**Proteja sus recursos antes de un evento**
Mejore la precisión de la detección de eventos protegiendo los recursos con Shield Advanced mientras reciben el tráfico normal esperado, antes de que sean objeto de un ataque DDo S.
Para informar con precisión de los eventos de un recurso protegido, Shield Avanzado debe establecer primero una referencia de los patrones de tráfico que se esperan para ese recurso.
+ Shield Avanzado informa de los eventos de la capa de infraestructura de los recursos después de que hayan estado protegidos durante al menos 15 minutos.
+ Shield Avanzado informa de los eventos de la capa de aplicación web para recursos después de que hayan estado protegidos durante al menos 24 horas. La precisión de la detección de los eventos de la capa de aplicación es mejor después de que Shield Avanzado haya observado el tráfico esperado durante 30 días.
**Para acceder a la información de los eventos en la AWS Shield consola**
1. Inicie sesión en la Consola de administración de AWS consola AWS WAF & Shield y ábrala en [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. En el panel AWS Shield de navegación, elija **Eventos**. La consola muestra la página **Eventos**.
1. En la página **Eventos**, puede seleccionar cualquier evento de la lista para ver información resumida adicional y detalles del evento.
**Topics**
+ [Lista de campos en los resúmenes de AWS Shield Advanced eventos](ddos-event-summaries.md)
+ [Visualización de los detalles del AWS Shield Advanced evento](ddos-event-details.md)
# Lista de campos en los resúmenes de AWS Shield Advanced eventos
En esta página se enumeran y definen los campos de los resúmenes de eventos de Shield Avanzado.
Puede ver el resumen y la información detallada de un evento en la página de consola del evento. Para abrir la página de un evento, seleccione su nombre de AWS recurso en la lista de páginas de **eventos**.
En la siguiente captura de pantalla se muestra un ejemplo de resumen de un evento de capa de red.
![\[El panel de resumen de la página de eventos de la AWS Shield consola muestra la información de un evento e incluye el AWS recurso afectado, los vectores de ataque, las horas de inicio y finalización y la información sobre la mitigación y el estado.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-console-event-summary2.png)
La información del resumen de la página del evento incluye la siguiente información.
+ **Estado actual**: valores que indican el estado del evento y las acciones que Shield Avanzado ha realizado en el evento. Los valores de estado se aplican a los eventos de la capa de infraestructura (capa 3 o 4) y de la capa de aplicación (capa 7).
+ **Identificado (en curso)** e **Identificado (disminuido)**: indican que Shield Avanzado detectó un evento, pero no ha tomado ninguna medida al respecto hasta el momento. **Identificado (disminuido)**: indica que el tráfico sospechoso que detectó Shield se detuvo sin intervención.
+ **Mitigación en curso** y **Mitigado**: indican que Shield Advanced detectó un evento y ha tomado medidas al respecto. **Mitigation** también se usa cuando el recurso objetivo es una CloudFront distribución de Amazon o una zona alojada en Amazon Route 53, que tienen sus propias mitigaciones integradas automáticas.
+ Vectores de **ataque: vectores** de ataque DDo S, como las inundaciones de TCP SYN, y las heurísticas de detección de Shield Advanced, como las inundaciones de solicitudes. Estos pueden ser indicadores de un ataque tipo S. DDo
+ **Hora de inicio**: fecha y hora en que se detectó el primer punto de datos de tráfico anómalos.
+ **Duración u hora de finalización**: indica el tiempo transcurrido entre la hora de inicio del evento y el último punto de datos anómalos observado por Shield Avanzado. Mientras un evento esté en curso, estos valores seguirán aumentando.
+ **Protección**: nombra la protección de Shield Avanzado que está asociada al recurso y proporciona un enlace a su página de protección. Esto está disponible en la página del evento individual.
+ **Mitigación automática de la capa DDo S** de aplicación: se utiliza para las protecciones de la capa de aplicación, para indicar si la mitigación automática de la capa DDo S de la aplicación Shield Advanced está habilitada para el recurso. Si se habilita, proporciona un enlace para acceder a la configuración y administrarla. Esto está disponible en la página del evento individual.
+ **Mitigación automática de la capa de red**: indica si el recurso tiene una mitigación automática en la capa de red. Si un recurso tiene un componente de capa de red, lo tendrá habilitado. Esta información está disponible en la página del evento individual.
En el caso de los recursos a los que se dirige con frecuencia, Shield puede implementar mitigaciones una vez que se haya reducido el exceso de tráfico, para evitar que se repitan más eventos.
**nota**
También puede acceder a los resúmenes de eventos de los recursos protegidos a través de la operación de la AWS Shield API. [ListAttacks](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_ListAttacks.html)
# Visualización de los detalles del AWS Shield Advanced evento
Puede ver los detalles sobre la detección y mitigación de un evento y los principales colaboradores en la sección inferior de la página de la consola correspondiente al evento. Esta sección puede incluir una combinación de tráfico legítimo y potencialmente no deseado, y puede representar tanto el tráfico que se ha transferido a su recurso protegido como el tráfico que ha sido bloqueado por las mitigaciones de Shield.
+ **Detección y mitigación**: proporciona información sobre el evento observado y cualquier medida de mitigación aplicada al mismo. Para obtener información acerca de la mitigación de eventos, consulte [Respondiendo a DDo los eventos S en AWS](ddos-responding.md).
+ **Principales colaboradores**: clasifica el tráfico implicado en el evento y enumera los principales orígenes del tráfico que Shield ha identificado para cada categoría. En el caso de los eventos de la capa de aplicación, utilice la información de los principales contribuyentes para hacerse una idea general de la naturaleza de un evento, pero utilice los AWS WAF registros para tomar decisiones de seguridad. Para obtener más información, consulte las secciones siguientes.
La información de sus eventos en la consola de Shield Avanzado se basa en las métricas de Shield Avanzado. Para obtener información acerca de las métricas de Shield Avanzado, consulte [AWS Shield Advanced métricas](shield-metrics.md).
Las métricas de mitigación no se incluyen para los recursos de Amazon CloudFront o Amazon Route 53, ya que estos servicios están protegidos por un sistema de mitigación que siempre está habilitado y no requiere mitigaciones para los recursos individuales.
Las secciones de detalles varían en función de si la información corresponde a un evento de la capa de infraestructura o de la capa de aplicación.
**Topics**
+ [Visualización de los detalles de los eventos de la capa de aplicación (capa 7) en Shield Avanzado](ddos-event-details-application-layer.md)
+ [Visualización de los detalles de los eventos de la capa de infraestructura (capa 3 o 4) en Shield Avanzado](ddos-event-details-infrastructure-layer.md)
# Visualización de los detalles de los eventos de la capa de aplicación (capa 7) en Shield Avanzado
Puede ver los detalles sobre la detección y mitigación de un evento de la capa de aplicación y los principales colaboradores en la sección inferior de la página de la consola correspondiente al evento. Esta sección puede incluir una combinación de tráfico legítimo y potencialmente no deseado, y puede representar tanto el tráfico que se ha transferido a su recurso protegido como el tráfico que ha sido bloqueado por las mitigaciones de Shield Avanzado.
Los detalles de mitigación se refieren a cualquier regla de la ACL web que esté asociada al recurso, incluidas las reglas que se implementan específicamente en respuesta a un ataque y las reglas basadas en tasas que se definen en la ACL web. Si habilita la mitigación automática de la capa DDo S de una aplicación, las métricas de mitigación incluyen métricas para esas reglas adicionales. Para obtener información sobre estas protecciones de la capa de aplicación, consulte [Proteger la capa de aplicación (capa 7) con AWS Shield Advanced y AWS WAF](ddos-app-layer-protections.md).
## Detección y mitigación
Para un evento de capa de aplicación (capa 7), la pestaña **Detección y mitigación** muestra las métricas de detección que se basan en la información obtenida de los AWS WAF registros. Las métricas de mitigación se basan en las reglas de AWS WAF de la ACL web asociada que están configuradas para bloquear el tráfico no deseado.
En el caso de CloudFront las distribuciones de Amazon, puedes configurar Shield Advanced para que te aplique mitigaciones automáticas. Con cualquier recurso de capa de aplicación, se puede elegir definir reglas de mitigación propias en la ACL web y solicitar ayuda al equipo de respuesta de Shield (SRT). Para obtener información sobre estas opciones, consulte [Respondiendo a DDo los eventos S en AWS](ddos-responding.md).
En la siguiente captura de pantalla se muestra un ejemplo de las métricas de detección de un evento de la capa de aplicaciones que desapareció después de varias horas.
![\[Un gráfico de métricas de detección muestra la detección de tráfico con inundación de solicitudes desde las 11:30 hasta que disminuye a las 16:00.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-app-detection-metrics.png)
El tráfico de eventos que disminuye antes de que entre en vigor una regla de mitigación no se representa en las métricas de mitigación. Esto puede provocar una diferencia entre el tráfico de solicitudes web que se muestra en los gráficos de detección y las métricas de permiso y bloqueo que se muestran en los gráficos de mitigación.
## Colaboradores principales
La pestaña **Colaboradores principales** de los eventos de la capa de aplicación muestra los 5 principales contribuyentes que Shield ha identificado para el evento, en función de los AWS WAF registros que ha recuperado. Shield clasifica la información de los principales contribuyentes por dimensiones, como la IP de origen, el país de origen y la URL de destino.
**nota**
Para obtener la información más precisa sobre el tráfico que contribuye a un evento de la capa de aplicaciones, utilice los AWS WAF registros.
Utilice la información de los principales colaboradores de la capa de aplicación de Shield solo para hacerse una idea general de la naturaleza de un ataque y no base sus decisiones de seguridad en ella. En el caso de los eventos de la capa de aplicación, los AWS WAF registros son la mejor fuente de información para comprender los factores que contribuyen a un ataque y para diseñar sus estrategias de mitigación.
La información de los principales colaboradores de The Shield no siempre refleja completamente los datos de los AWS WAF registros. Cuando incorpora los registros, Shield prioriza la reducción del impacto en el rendimiento del sistema en vez de recuperar todos los datos de los registros. Esto puede provocar una pérdida del grado de detalle en los datos que estén disponibles para que Shield los analice. En la mayoría de los casos, la mayor parte de la información está disponible, pero es posible que los datos de los principales contribuyentes estén sesgados hasta cierto punto debido a un ataque.
En la siguiente captura de pantalla se muestra un ejemplo de la pestaña de **Colaboradores principales** en un evento de capa de aplicación.
![\[La pestaña de colaboradores principales de un evento de capa de aplicación describe a los cinco principales colaboradores respecto a una serie de características de las solicitudes web. La pantalla muestra las 5 direcciones IP de origen principales, los 5 principales destinos URLs, los 5 principales países de origen y los 5 principales agentes de usuario.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-app-event-top-contributors.png)
La información de los colaboradores se basa en las solicitudes de tráfico legítimo y potencialmente no deseado. Los eventos de mayor volumen y los eventos en los que los orígenes de solicitudes no están muy distribuidos tienen más probabilidades de tener colaboradores principales identificables. Un ataque muy distribuido puede tener múltiples orígenes, lo que dificulta la identificación de los principales contribuyentes al ataque. Si Shield Avanzado no identifica a los contribuyentes importantes de una categoría específica, muestra los datos como no disponibles.
# Visualización de los detalles de los eventos de la capa de infraestructura (capa 3 o 4) en Shield Avanzado
Puede ver los detalles sobre la detección y mitigación de un evento de la capa de la infraestructura, y los principales colaboradores en la sección inferior de la página de la consola correspondiente al evento. Esta sección puede incluir una combinación de tráfico legítimo y potencialmente no deseado, y puede representar tanto el tráfico que se ha transferido a su recurso protegido como el tráfico que ha sido bloqueado por las mitigaciones de Shield.
## Detección y mitigación
En el caso de un evento de capa de infraestructura (capa 3 o 4), la pestaña **Detección y mitigación** muestra las métricas de detección que se basan en flujos de red muestreados y las métricas de mitigación que se basan en el tráfico observado por los sistemas de mitigación. Las métricas de mitigación son una medida más precisa del tráfico que llega a su recurso.
Shield crea automáticamente una mitigación para los tipos de recursos protegidos Elastic IP (EIP), Classic Load Balancer (CLB), Application Load Balancer (ALB) y Standard Accelerator. AWS Global Accelerator Las métricas de mitigación de las direcciones EIP y los aceleradores AWS Global Accelerator estándar indican la cantidad de paquetes aprobados y descartados.
La siguiente captura de pantalla muestra un ejemplo de la pestaña **Detección y mitigación** para un evento de la capa de infraestructura.
![\[Los gráficos de detección y mitigación de un evento de red muestran un aumento del tráfico de inundaciones SYN y de paquetes en las métricas de detección, junto con un aumento de las mitigaciones que disminuyen el tráfico unos segundos después, en las métricas de mitigación. Tras unos 30 segundos de aumento de las mitigaciones, las inundaciones de tráfico cesan.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-network-event-detection-mitigation.png)
El tráfico de eventos que disminuye antes de que Shield aplique una mitigación no se representa en las métricas de mitigación. Esto puede provocar una diferencia entre el tráfico que se muestra en los gráficos de detección y las métricas de permiso y bloqueo que se muestran en los gráficos de mitigación.
## Colaboradores principales
La pestaña **Colaboradores principales** para eventos de la capa de infraestructura enumera las métricas de hasta 100 colaboradores principales en varias dimensiones del tráfico. Los detalles incluyen las propiedades de la capa de red para cualquier dimensión en la que se puedan identificar al menos cinco orígenes de tráfico importantes. Algunos ejemplos de orígenes de tráfico son la IP de origen y el ASN de origen.
En la siguiente captura de pantalla se muestra un ejemplo de pestaña de **Colaboradores principales** en un evento de capa de infraestructura.
![\[La pestaña de colaboradores principales de un evento de la red muestra las categorías de tráfico que más han contribuido al evento. En este caso, las categorías incluyen el volumen por protocolo, el volumen por protocolo y puerto de destino, el volumen por protocolo y ASN de origen y el volumen por marcadores TCP.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-network-event-top-contributors.png)
Las métricas de colaboradores se basan en flujos de red muestreados, tanto para el tráfico legítimo como para el potencialmente no deseado. Los eventos de mayor volumen y los eventos en los que los orígenes de tráfico no están muy distribuidos tienen más probabilidades de tener colaboradores principales identificables. Un ataque muy distribuido puede tener múltiples orígenes, lo que dificulta la identificación de los principales contribuyentes al ataque. Si Shield no identifica a ningún contribuyente importante de una categoría o métrica específica, muestra los datos como no disponibles.
En un ataque de nivel DDo S de infraestructura, las fuentes de tráfico pueden estar falsificadas o reflejadas. Un origen suplantado ha sido falsificado a propósito por el atacante. Un origen reflejado es el verdadero origen del tráfico detectado, pero no participa voluntariamente en el ataque. Por ejemplo, un atacante podría generar un gran flujo de tráfico amplificado hacia un objetivo a base de reflejar el ataque en servicios de Internet que, por lo general, son legítimos. En este caso, la información del origen puede ser válida aunque no sea el origen real del ataque. Estos factores pueden limitar la viabilidad de las técnicas de mitigación que bloquean los orígenes en función de los encabezados de paquetes.
# Visualización de los eventos de Shield Advanced en varios Cuentas de AWS con AWS Firewall Manager y AWS Security Hub CSPM
Puede usar, AWS Security Hub CSPM administrar AWS Firewall Manager y monitorear los recursos AWS Shield Advanced protegidos en varias cuentas.
Con Firewall Manager, puede crear una política de seguridad de Shield Advanced que informe e imponga el cumplimiento de la protección DDo S en todas sus cuentas. Firewall Manager supervisa sus recursos protegidos e incluye la incorporación de protecciones a los nuevos recursos que entran dentro de la política de Shield Avanzado.
Puede integrar Firewall Manager AWS Security Hub CSPM para obtener un panel único que informe DDo de los eventos detectados por las comprobaciones de cumplimiento de Shield Advanced y Firewall Manager, cuando Firewall Manager identifica un recurso que no cumple con su política de seguridad de Shield Advanced.
La siguiente figura muestra una arquitectura típica para supervisar los recursos protegidos de Shield Advanced con Firewall Manager y Security Hub (CSPM).
![\[En la parte superior de la figura hay un AWS Organizations icono. Tiene una flecha que apunta hacia abajo y que se divide para señalar a dos iconos uno al lado del otro. El icono de la izquierda tiene el título Production OU y el de la derecha el título Security OU. Debajo de estos íconos hay tres íconos, titulados de izquierda a derecha: AWS Shield Advanced AWS Firewall Manager, y AWS Security Hub CSPM. El icono de OU de producción tiene una flecha que apunta hacia abajo hasta el icono de Shield Avanzado. El icono de la unidad organizativa de seguridad tiene una flecha que apunta hacia abajo y que se divide para señalar los iconos CSPM del Firewall Manager y del Security Hub. El icono de Shield Avanzado tiene una flecha que apunta hacia abajo a un rectángulo con el título Shield Advanced protected resources. Dentro del rectángulo hay iconos para Application Load Balancer, la CloudFront distribución y la dirección IP elástica. El icono de Firewall Manager también tiene una flecha que apunta hacia el rectángulo Shield Advanced protected resources y está etiquetada Enforces compliance of protected resources. El icono de Shield Avanzado tiene una flecha horizontal que apunta hacia el icono de Firewall Manager que está etiquetado DDoS alarm. El icono del Firewall Manager tiene una flecha horizontal que apunta a su derecha, hacia el icono CSPM del Security Hub que lleva la etiqueta. DDoS alarm and compliance findings\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-arch-fms-ash-integration.png)
Al integrar Firewall Manager con Security Hub CSPM, puede ver los hallazgos de seguridad en un solo lugar, junto con otras alertas e información sobre el estado de cumplimiento de las aplicaciones en las que se ejecuta. AWS
La siguiente captura de pantalla resalta la información que puede ver sobre un evento de Shield Advanced en la consola CSPM de Security Hub cuando tiene una integración de este tipo.
![\[La captura de pantalla muestra la página de hallazgos de la consola CSPM de Security Hub, subtitulada Un hallazgo es un problema de seguridad o una comprobación de seguridad fallida. . La sección tiene líneas rojas que resaltan las cadenas: Título IGUAL a Shield Avanzado detectó un ataque contra un recurso supervisado y Nombre del producto IGUAL a Firewall Manager. La pantalla muestra un conjunto de detalles sobre el ataque específico y su estado.\]](http://docs.aws.amazon.com/es_es/waf/latest/developerguide/images/shield-console-security-hub-event.png)
Para obtener información sobre cómo integrar Firewall Manager y Security Hub (CSPM) con Shield Advanced para centralizar la supervisión de eventos y el cumplimiento en todas sus cuentas protegidas, consulte el blog de AWS seguridad: [configure la supervisión centralizada para los eventos DDo S y corrija automáticamente](https://aws.amazon.com/blogs/security/set-up-centralized-monitoring-for-ddos-events-and-auto-remediate-noncompliant-resources/) los recursos que no cumplan con las normas.
# Respondiendo a DDo los eventos S en AWS
En esta página, se explica cómo AWS responde a los ataques DDo S y se proporcionan opciones para seguir respondiendo.
AWS mitiga automáticamente los ataques DDo S de red y de transporte (capa 3 y capa 4). Si utiliza Shield Advanced para proteger sus EC2 instancias de Amazon, durante un ataque, Shield Advanced despliega automáticamente su red de Amazon VPC en el borde de AWS la ACLs red. Esto permite que Shield Advanced brinde protección contra eventos DDo S más grandes. Para obtener más información sobre la red ACLs, consulte [Red ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).
En el caso de los ataques a nivel de aplicación (capa 7) DDo S, AWS intenta detectar y notificar a AWS Shield Advanced los clientes mediante CloudWatch alarmas. De forma predeterminada, no aplica mitigaciones automáticamente para evitar bloquear inadvertidamente el tráfico de usuarios válidos.
En el caso de los recursos de la capa de aplicación (capa 7), dispone de las siguientes opciones para responder a un ataque.
+ **Proporcionar sus propias mitigaciones**: puede investigar y mitigar el ataque por su cuenta. Para obtener información, consulte [Mitigación manual de un ataque a la capa DDo S de aplicación](ddos-responding-manual.md).
+ **Ponerse en contacto con el servicio de asistencia**: si es cliente de Shield Avanzado, puede ponerse en contacto con el [Centro de AWS Support](https://console.aws.amazon.com/support/home#/) para obtener ayuda con las mitigaciones. Los casos críticos y urgentes se envían directamente a los expertos de DDo Estados Unidos. Para obtener información, consulte [Ponerse en contacto con el centro de soporte durante un ataque de capa DDo S de aplicación](ddos-responding-contact-support.md).
Además, antes de que se produzca un ataque, puede activar de forma proactiva las siguientes opciones de mitigación:
+ **Mitigaciones automáticas en las CloudFront distribuciones de Amazon**: con esta opción, Shield Advanced define y gestiona las reglas de mitigación para usted en su ACL web. Para obtener información sobre la mitigación automática de la capa de aplicaciones, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
+ **Interacción proactiva**: cuando AWS Shield Advanced detecta un ataque de gran tamaño en la capa de aplicación contra una de sus aplicaciones, el SRT puede ponerse en contacto con usted de forma proactiva. El SRT clasifica el evento DDo S y crea mitigaciones. AWS WAF El SRT se pone en contacto con usted y, con su consentimiento, puede aplicar las reglas de AWS WAF . Para obtener más información acerca de esta opción, consulta [Configuración de una interacción proactiva para que el SRT se ponga en contacto con usted directamente](ddos-srt-proactive-engagement.md).
# Ponerse en contacto con el centro de soporte durante un ataque de capa DDo S de aplicación
Esta página proporciona instrucciones para ponerse en contacto con el centro de soporte durante un ataque a la capa de aplicación DDo S.
Si es AWS Shield Advanced cliente, puede ponerse en contacto con el [AWS Support Centro](https://console.aws.amazon.com/support/home#/) para obtener ayuda con las mitigaciones. Los casos críticos y urgentes se envían directamente a los expertos de EE. UU. DDo De AWS Shield Advanced este modo, los casos complejos se pueden remitir al AWS Shield Response Team (SRT), que tiene una amplia experiencia en la protección AWS de Amazon.com y sus subsidiarias. Para obtener más información sobre SRT, consulte [Respuesta a eventos DDo S gestionada con el soporte del Shield Response Team (SRT)](ddos-srt-support.md).
Para obtener asistencia del equipo de respuesta de Shield (SRT), póngase en contacto con el [Centro de AWS Support](https://console.aws.amazon.com/support/home#/). El tiempo de respuesta de su caso depende de la gravedad que seleccione y los tiempos de respuesta, que están documentados en la página [Planes de AWS Support](https://aws.amazon.com/premiumsupport/compare-plans/).
Seleccione las siguientes opciones:
+ Tipo de caso: soporte técnico
+ Servicio: Denegación de servicio distribuida DDo
+ Categoría: Entrante a AWS
+ Gravedad: *elija la opción correspondiente*
Cuando hables con nuestro representante, explica que eres un AWS Shield Advanced cliente que está sufriendo un posible ataque DDo tipo S. Nuestro representante dirigirá su llamada a los expertos DDo estadounidenses correspondientes. Si presenta un caso ante el [AWS Support Centro](https://console.aws.amazon.com/support/home#/) mediante el tipo de servicio **distribuido de denegación de servicio (DDoS)**, puede hablar directamente con un experto en DDo S por chat o por teléfono. DDoLos ingenieros de soporte de S pueden ayudarlo a identificar los ataques, recomendar mejoras en su AWS arquitectura y brindarle orientación sobre el uso de AWS los servicios para mitigar DDo los ataques S.
En el caso de los ataques en la capa de aplicación, el SRT puede ayudarlo a analizar la actividad sospechosa. Si tiene habilitada la mitigación automática para su recurso, el SRT puede revisar las mitigaciones que Shield Avanzado aplica automáticamente contra el ataque. En cualquier caso, el SRT puede ayudarlo a revisar y mitigar el problema. Las medidas de mitigación que recomienda la SRT suelen requerir que la SRT cree o actualice las listas de control de acceso a la AWS WAF web (web ACLs) en su cuenta. El SRT necesitará su permiso para realizar este trabajo.
**importante**
Te recomendamos que, como parte de la activación AWS Shield Advanced, sigas los pasos que se indican [Concesión del acceso al SRT](ddos-srt-access.md) a continuación para proporcionar al SRT de forma proactiva los permisos que necesita para ayudarte durante un ataque. Proporcionar permiso de antemano ayuda a evitar retrasos si se produce un ataque real.
El SRT le ayuda a clasificar el ataque DDo S para identificar las características y patrones del ataque. Con su consentimiento, el SRT crea e implementa AWS WAF reglas para mitigar el ataque.
También puede ponerse en contacto con el SRT antes o durante un posible ataque para revisar mitigaciones y desarrollar e implementar mitigaciones personalizadas. Por ejemplo, si ejecuta una aplicación web y solo necesita tener abiertos los puertos 80 y 443, puede trabajar con el SRT para preconfigurar una ACL web que permita ("allow") únicamente los puertos 80 y 443.
Debe autorizar y contactar con el SRT en el nivel de cuenta. Es decir, si utiliza Shield Advanced en una política de Shield Avanzado de Firewall Manager, es el propietario de la cuenta, no el administrador de Firewall Manager, quien debe ponerse en contacto con el SRT para solicitar asistencia. El administrador de Firewall Manager puede contactar con el SRT solo para las cuentas de las que sea propietario.
# Mitigación manual de un ataque a la capa DDo S de aplicación
Esta página proporciona instrucciones para mitigar manualmente un ataque a la capa de aplicación DDo S.
Si determina que la actividad de la página de eventos de su recurso representa un ataque DDo S, puede crear sus propias AWS WAF reglas en su ACL web para mitigar el ataque. Esta es la única opción disponible si no eres cliente de Shield Advanced. AWS WAF se incluye sin AWS Shield Advanced coste adicional. Para obtener información sobre la creación de reglas en su ACL web, consulte [Configuración de la protección en AWS WAF](web-acl.md).
Si las usa AWS Firewall Manager, puede agregar sus AWS WAF reglas a una AWS WAF política de Firewall Manager.
**Para mitigar manualmente un posible ataque a la capa DDo S de aplicación**
1. Cree declaraciones de reglas en su ACL web con criterios que coincidan con el comportamiento inusual. Para empezar, configúrelas para que cuenten las solicitudes coincidentes. Para obtener información sobre la configuración de la ACL web y las declaraciones de reglas, consulte [Uso de paquetes de protección (web ACLs) con reglas y grupos de reglas en AWS WAF](web-acl-processing.md) y [Probando y ajustando sus AWS WAF protecciones](web-acl-testing.md).
**nota**
Pruebe siempre primero las reglas; para ello, utilice inicialmente la acción de regla Count en lugar de Block. Cuando tenga la seguridad de que sus nuevas reglas identifican las solicitudes correctas, puede modificarlas para bloquear las solicitudes.
1. Supervise los recuentos de solicitudes para determinar si desea bloquear las solicitudes coincidentes. Si el volumen de solicitudes sigue siendo inusualmente alto y está seguro de que sus reglas están capturando las solicitudes que están causando el alto volumen, cambie las reglas de su ACL web para bloquear las solicitudes.
1. Continúe supervisando la página de eventos para asegurarse de que su tráfico se gestiona como desee.
AWS proporciona plantillas preconfiguradas para que pueda empezar rápidamente. Las plantillas incluyen un conjunto de AWS WAF reglas que puede personalizar y utilizar para bloquear los ataques habituales basados en la web. Para obtener más información, consulte [Automatizaciones de seguridad de AWS WAF](https://aws.amazon.com/solutions/aws-waf-security-automations/).
# Solicitar un crédito AWS Shield Advanced después de un ataque
Si está suscrito AWS Shield Advanced y sufre un ataque DDo S que aumente la utilización de un recurso protegido de Shield Advanced, puede solicitar un crédito de servicio de Shield Advanced para los cargos relacionados con el aumento de la utilización, en la medida en que Shield Advanced no lo mitigue.
**nota**
Los créditos recibidos a través de este proceso se pueden aplicar únicamente en Shield Avanzado. Los créditos de Shield Avanzado no están disponibles para utilizarse con otros servicios.
Los créditos solo están disponibles para los siguientes tipos de cargos:
+ Transferencia de datos Shield Avanzado
+ Solicitudes CloudFront HTTP/HTTPS de Amazon
+ CloudFront transferencia de datos saliente
+ Amazon Route 53
+ AWS Global Accelerator aceleración estándar de transferencia de datos
+ Unidades de capacidad del equilibrador de carga para el equilibrador de carga de aplicación
+ Costos de instancia para instancias protegidas de Amazon Elastic Compute Cloud (Amazon EC2) que se crearon mediante una política de autoscalamiento en respuesta al ataque
**Requisitos previos para solicitar un crédito**
Para poder recibir un crédito, antes de que comenzara el ataque, debes haber hecho lo siguiente:
+ Debe haber agregado la protección Shield Avanzado a los recursos para los que desea solicitar un crédito. Los recursos protegidos que se añadan durante un ataque no son aptos para la protección de costos.
**nota**
Al activar Shield Advanced en su Cuenta de AWS dispositivo, no se habilita automáticamente la protección de Shield Advanced para recursos individuales.
Para obtener más información sobre cómo proteger AWS los recursos con Shield Advanced, consulte[Añadir AWS Shield Advanced protección a AWS los recursos](configure-new-protection.md).
+ Para los recursos aplicables CloudFront y protegidos por Application Load Balancer, debe haber asociado una ACL AWS WAF web e implementado una regla basada en la velocidad en la ACL web en modo. Block Para obtener información acerca de las reglas basadas en tasas de AWS WAF , consulte [Uso de declaraciones de reglas basadas en tasas en AWS WAF](waf-rule-statement-type-rate-based.md). Para obtener información sobre cómo asociar la web ACLs con AWS los recursos, consulte. [Configuración de la protección en AWS WAF](web-acl.md)
+ Debe haber implementado las mejores prácticas adecuadas en [AWS Best Practices for DDo S Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency) para configurar su aplicación de manera que se minimicen los costes durante un ataque DDo S.
**¿Cómo solicitar un crédito?**
Para poder optar a un crédito, debe presentar su solicitud de crédito dentro del período de 15 días inmediatamente siguiente al mes de facturación en el que se produjo el ataque.
Para solicitar un crédito, presente un caso de facturación a través del [Centro AWS Support](https://console.aws.amazon.com/support/home#/). En la solicitud, incluya lo siguiente:
+ Las palabras «Concesión DDo S» en la línea de asunto
+ Las fechas y horas de cada evento o interrupción de disponibilidad para los que solicita un crédito
+ Los AWS servicios y recursos específicos que se vieron afectados
Tras enviar una solicitud, el AWS Shield Response Team (SRT) validará si se ha producido un ataque DDo S y, de ser así, si algún recurso protegido se ha escalado para absorber el ataque DDo S. Si AWS determina que los recursos protegidos se adaptaron para absorber el ataque DDo S, AWS emitirá un crédito por la parte del tráfico que AWS determine que fue causada por el DDo ataque S. Los créditos son válidos durante 12 meses.
# Seguridad en el uso del AWS Shield servicio
En esta sección se explica cómo se aplica el modelo de responsabilidad compartida a AWS Shield.
La seguridad en la nube AWS es la máxima prioridad. Como AWS cliente, usted se beneficia de una arquitectura de centro de datos y red diseñada para cumplir con los requisitos de las organizaciones más sensibles a la seguridad.
**nota**
Esta sección proporciona una guía AWS de seguridad estándar para el uso del AWS Shield servicio y sus AWS recursos, como las protecciones Shield Advanced.
Para obtener información sobre cómo proteger sus AWS recursos con Shield and Shield Advanced, consulte el resto de la AWS Shield guía.
La seguridad es una responsabilidad compartida entre usted AWS y usted. El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) la describe como seguridad *de* la nube y seguridad *en* la nube:
+ **Seguridad de la nube**: AWS es responsable de proteger la infraestructura que ejecuta AWS los servicios en la Nube de AWS. AWS también le proporciona servicios que puede utilizar de forma segura. Auditores externos prueban y verifican periódicamente la eficacia de nuestra seguridad en el marco de los [Programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/). Para obtener más información sobre los programas de conformidad que se aplican a Shield, consulte [Servicios de AWS en el ámbito del programa de conformidad](https://aws.amazon.com/compliance/services-in-scope/).
+ **Seguridad en la nube**: su responsabilidad viene determinada por el AWS servicio que utilice. Usted también es responsable de otros factores, incluida la confidencialidad de los datos, los requisitos de la empresa y la legislación y los reglamentos aplicables.
Esta documentación le ayuda a comprender cómo aplicar el modelo de responsabilidad compartida cuando se utiliza Shield. En los siguientes temas, se le mostrará cómo configurar Shield para satisfacer sus objetivos de seguridad y conformidad. También aprenderá a utilizar otros AWS servicios que le ayudan a supervisar y proteger sus recursos de Shield.
**Topics**
+ [Protección de sus datos en Shield](shd-data-protection.md)
+ [Uso de IAM con AWS Shield](shd-security-iam.md)
+ [Registro y supervisión en Shield](shd-incident-response.md)
+ [Validación del cumplimiento en Shield](shd-security-compliance.md)
+ [Infraestructura para la resiliencia en Shield](shd-disaster-recovery-resiliency.md)
+ [Seguridad de la infraestructura en AWS Shield](shd-infrastructure-security.md)
# Protección de sus datos en Shield
En esta sección se explica cómo se aplica el modelo de responsabilidad AWS compartida a la protección de datos en Shield.
El modelo de [responsabilidad AWS compartida modelo](https://aws.amazon.com/compliance/shared-responsibility-model/) se aplica a la protección de datos en AWS Shield. Como se describe en este modelo, AWS es responsable de proteger la infraestructura global que ejecuta todos los Nube de AWS. Eres responsable de mantener el control sobre el contenido alojado en esta infraestructura. También eres responsable de las tareas de administración y configuración de seguridad para los Servicios de AWS que utiliza. Para obtener más información sobre la privacidad de los datos, consulte las [Preguntas frecuentes sobre la privacidad de datos](https://aws.amazon.com/compliance/data-privacy-faq/). Para obtener información sobre la protección de datos en Europa, consulte la publicación de blog sobre el [Modelo de responsabilidad compartida de AWS y GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) en el * Blog de seguridad de AWS *.
Con fines de protección de datos, le recomendamos que proteja Cuenta de AWS las credenciales y configure los usuarios individuales con AWS IAM Identity Center o AWS Identity and Access Management (IAM). De esta manera, solo se otorgan a cada usuario los permisos necesarios para cumplir sus obligaciones laborales. También recomendamos proteger sus datos de la siguiente manera:
+ Utiliza la autenticación multifactor (MFA) en cada cuenta.
+ Se utiliza SSL/TLS para comunicarse con AWS los recursos. Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Configure la API y el registro de actividad de los usuarios con AWS CloudTrail. Para obtener información sobre el uso de CloudTrail senderos para capturar AWS actividades, consulte [Cómo trabajar con CloudTrail senderos](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) en la *Guía del AWS CloudTrail usuario*.
+ Utilice soluciones de AWS cifrado, junto con todos los controles de seguridad predeterminados Servicios de AWS.
+ Utiliza servicios de seguridad administrados avanzados, como Amazon Macie, que lo ayuden a detectar y proteger la información confidencial almacenada en Amazon S3.
+ Si necesita módulos criptográficos validados por FIPS 140-3 para acceder a AWS través de una interfaz de línea de comandos o una API, utilice un punto final FIPS. Para obtener más información sobre los puntos de conexión de FIPS disponibles, consulte [Estándar de procesamiento de la información federal (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Se recomienda encarecidamente no introducir nunca información confidencial o sensible, como por ejemplo, direcciones de correo electrónico de clientes, en etiquetas o campos de formato libre, tales como el campo **Nombre**. Esto incluye cuando trabaja con Shield u otro Servicios de AWS dispositivo mediante la consola, la API o AWS SDKs. AWS CLI Cualquier dato que introduzca en etiquetas o campos de formato libre utilizados para los nombres se pueden emplear para los registros de facturación o diagnóstico. Si proporciona una URL a un servidor externo, recomendamos encarecidamente que no incluya información de credenciales en la URL a fin de validar la solicitud para ese servidor.
Las entidades de escudo, como las protecciones, se cifran en reposo, excepto en ciertas regiones donde el cifrado no está disponible, incluidas China (Pekín) y China (Ningxia). Para cada región se utilizan claves de cifrado únicas.
# Uso de IAM con AWS Shield
En esta sección se explica cómo usar IAM con. AWS Shield
AWS Identity and Access Management (IAM) es una herramienta Servicio de AWS que ayuda al administrador a controlar de forma segura el acceso a los AWS recursos. Los administradores de IAM controlan quién puede estar *autenticado* (ha iniciado sesión) y *autorizado* (tiene permisos) para utilizar recursos de Shield. La IAM es una Servicio de AWS herramienta que puede utilizar sin coste adicional.
**Topics**
+ [Público](#security_iam_audience)
+ [Autenticación con identidades](#security_iam_authentication)
+ [Administración del acceso con políticas](#security_iam_access-manage)
+ [Cómo AWS Shield funciona con IAM](shd-security_iam_service-with-iam.md)
+ [Ejemplos de políticas basadas en la identidad para AWS Shield](shd-security_iam_id-based-policy-examples.md)
+ [AWS políticas gestionadas para AWS Shield](shd-security-iam-awsmanpol.md)
+ [Solución de problemas AWS Shield de identidad y acceso](shd-security_iam_troubleshoot.md)
+ [Uso de roles vinculados a servicios para Shield Avanzado](shd-using-service-linked-roles.md)
## Público
La forma de usar AWS Identity and Access Management (IAM) varía según el trabajo que se realice en Shield.
**Usuario de servicio**: si utiliza el servicio de Shield para realizar su trabajo, su administrador le proporciona las credenciales y los permisos que necesita. A medida que utilice más características de Shield para realizar su trabajo, es posible que necesite permisos adicionales. Entender cómo se administra el acceso puede ayudarlo a solicitar los permisos correctos al administrador. Si no puede acceder a una característica de Shield, consulte [Solución de problemas AWS Shield de identidad y acceso](shd-security_iam_troubleshoot.md).
**Administrador de servicio**: si está a cargo de los recursos de Shield en su empresa, probablemente tenga acceso completo a Shield. Su trabajo consiste en determinar a qué características y recursos de Shield deben acceder los usuarios del servicio. Luego, debe enviar solicitudes a su administrador de IAM para cambiar los permisos de los usuarios de su servicio. Revise la información de esta página para conocer los conceptos básicos de IAM. Para obtener más información sobre cómo su empresa puede utilizar IAM con Shield, consulte [Cómo AWS Shield funciona con IAM](shd-security_iam_service-with-iam.md).
**Administrador de IAM**: si es administrador de IAM, es posible que quiera conocer más detalles sobre cómo escribir políticas para administrar el acceso a Shield. Para consultar ejemplos de políticas basadas en identidad de Shield que puede utilizar en IAM, consulte [Ejemplos de políticas basadas en la identidad para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## Autenticación con identidades
La autenticación es la forma de iniciar sesión AWS con sus credenciales de identidad. Debe autenticarse como usuario de Usuario raíz de la cuenta de AWS IAM o asumir una función de IAM.
Puede iniciar sesión como una identidad federada con las credenciales de una fuente de identidad, como AWS IAM Identity Center (IAM Identity Center), la autenticación de inicio de sesión único o las credenciales. Google/Facebook Para obtener más información sobre el inicio de sesión, consulte [Cómo iniciar sesión en la Cuenta de AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) en la *Guía del usuario de AWS Sign-In *.
Para el acceso programático, AWS proporciona un SDK y una CLI para firmar criptográficamente las solicitudes. Para obtener más información, consulte [AWS Signature Version 4 para solicitudes de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) en la *Guía del usuario de IAM*.
### Cuenta de AWS usuario root
Al crear un Cuenta de AWS, se comienza con una identidad de inicio de sesión denominada *usuario Cuenta de AWS raíz* que tiene acceso completo a todos Servicios de AWS los recursos. Se recomiendaencarecidamente que no utilice el usuario raíz para las tareas diarias. Para ver las tareas que requieren credenciales de usuario raíz, consulte [Tareas que requieren credenciales de usuario raíz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) en la *Guía del usuario de IAM*.
### Identidad federada
Como práctica recomendada, exija a los usuarios humanos que utilicen la federación con un proveedor de identidades para acceder Servicios de AWS mediante credenciales temporales.
Una *identidad federada* es un usuario del directorio empresarial, del proveedor de identidades web o al Directory Service que se accede Servicios de AWS mediante credenciales de una fuente de identidad. Las identidades federadas asumen roles que proporcionan credenciales temporales.
Para una administración de acceso centralizada, se recomienda AWS IAM Identity Center. Para obtener más información, consulte [¿Qué es el Centro de identidades de IAM?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) en la *Guía del usuario de AWS IAM Identity Center *.
### Usuarios y grupos de IAM
Un *[usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* es una identidad con permisos específicos para una sola persona o aplicación. Recomendamos el uso de credenciales temporales en lugar de usuarios de IAM con credenciales de larga duración. Para obtener más información, consulte [Exigir a los usuarios humanos que utilicen la federación con un proveedor de identidad para acceder AWS mediante credenciales temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) en la Guía del usuario de *IAM*.
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica un conjunto de usuarios de IAM y facilita la administración de los permisos para grupos grandes de usuarios. Para obtener más información, consulte [Casos de uso para usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) en la *Guía del usuario de IAM*.
### Roles de IAM
Un *[Rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* es una identidad con permisos específicos que proporciona credenciales temporales. Puede asumir un rol [cambiando de un rol de usuario a uno de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) o llamando a una AWS CLI operación de AWS API. Para obtener más información, consulte [Métodos para asumir un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) en la *Guía del usuario de IAM*.
Los roles de IAM son útiles para el acceso de usuario federado, los permisos de usuario de IAM temporales, el acceso entre cuentas, el acceso entre servicios y las aplicaciones que se ejecutan en Amazon EC2. Para obtener más información, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
## Administración del acceso con políticas
El acceso se controla AWS creando políticas y adjuntándolas a AWS identidades o recursos. Una política define los permisos cuando están asociados a una identidad o un recurso. AWS evalúa estas políticas cuando un director hace una solicitud. La mayoría de las políticas se almacenan AWS como documentos JSON. Para obtener más información sobre los documentos de políticas de JSON, consulte [Información general de políticas de JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) en la *Guía del usuario de IAM*.
Mediante las políticas, los administradores especifican quién tiene acceso a qué, definiendo qué **entidad principal** puede realizar **acciones** sobre qué **recursos** y en qué **condiciones**.
De forma predeterminada, los usuarios y los roles no tienen permisos. Un administrador de IAM crea políticas de IAM y las agrega a roles, que los usuarios pueden asumir posteriormente. Las políticas de IAM definen permisos independientemente del método que se utilice para realizar la operación.
### Políticas basadas en identidades
Las políticas basadas en identidad son documentos de política de permisos JSON que asocia a una identidad (usuario, grupo o rol). Estas políticas controlan qué acciones pueden realizar las identidades, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en la identidad, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.
Las políticas basadas en identidad pueden ser *políticas insertadas* (incrustadas directamente en una sola identidad) o *políticas administradas* (políticas independientes asociadas a varias identidades). Para obtener información sobre cómo elegir entre políticas administradas e insertadas, consulte [Selección entre políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) en la *Guía del usuario de IAM*.
### Políticas basadas en recursos
Las políticas basadas en recursos son documentos de políticas JSON que se asocian a un recurso. Los ejemplos incluyen las *Políticas de confianza de roles* de IAM y las *Políticas de bucket* de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos.
Las políticas basadas en recursos son políticas insertadas que se encuentran en ese servicio. No puedes usar políticas AWS gestionadas de IAM en una política basada en recursos.
### Listas de control de acceso () ACLs
Las listas de control de acceso (ACLs) controlan qué responsables (miembros de la cuenta, usuarios o roles) tienen permisos para acceder a un recurso. ACLs son similares a las políticas basadas en recursos, aunque no utilizan el formato de documento de políticas JSON.
Amazon S3 y Amazon VPC son ejemplos de servicios compatibles. AWS WAF ACLs Para obtener más información ACLs, consulte la [descripción general de la lista de control de acceso (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) en la *Guía para desarrolladores de Amazon Simple Storage Service*.
### Otros tipos de políticas
AWS admite tipos de políticas adicionales que pueden establecer los permisos máximos otorgados por los tipos de políticas más comunes:
+ **Límites de permisos:** establecen los permisos máximos que una política basada en identidad puede conceder a una entidad de IAM. Para obtener más información, consulte [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) en la *Guía del usuario de IAM*.
+ **Políticas de control de servicios (SCPs)**: especifican los permisos máximos para una organización o unidad organizativa en AWS Organizations. Para obtener más información, consulte [Políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) en la *Guía del usuario de AWS Organizations *.
+ **Políticas de control de recursos (RCPs)**: establece los permisos máximos disponibles para los recursos de tus cuentas. Para obtener más información, consulte [Políticas de control de recursos (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) en la *Guía del AWS Organizations usuario*.
+ **Políticas de sesión:** políticas avanzadas que se pasan como parámetro cuando se crea una sesión temporal para un rol o un usuario federado. Para obtener más información, consulte [Políticas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) en la *Guía del usuario de IAM*.
### Varios tipos de políticas
Cuando se aplican varios tipos de políticas a una solicitud, los permisos resultantes son más complicados de entender. Para saber cómo se AWS determina si se debe permitir una solicitud cuando se trata de varios tipos de políticas, consulte la [lógica de evaluación de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) en la *Guía del usuario de IAM*.
# Cómo AWS Shield funciona con IAM
En esta sección se explica cómo utilizar las funciones de IAM con. AWS Shield
Antes de utilizar IAM para administrar el acceso a Shield, conozca qué características de IAM se pueden utilizar con Shield.
**Funciones de IAM que puede utilizar con AWS Shield**
| Característica de IAM | Compatibilidad con Shield |
| --- | --- |
| [Políticas basadas en identidades](#shd-security_iam_service-with-iam-id-based-policies) | Sí |
| [Políticas basadas en recursos](#shd-security_iam_service-with-iam-resource-based-policies) | No |
| [Acciones de políticas](#shd-security_iam_service-with-iam-id-based-policies-actions) | Sí |
| [Recursos de políticas](#shd-security_iam_service-with-iam-id-based-policies-resources) | Sí |
| [Claves de condición de política (específicas del servicio)](#shd-security_iam_service-with-iam-id-based-policies-conditionkeys) | Sí |
| [ACLs](#shd-security_iam_service-with-iam-acls) | No |
| [ABAC (etiquetas en políticas)](#shd-security_iam_service-with-iam-tags) | Parcial |
| [Credenciales temporales](#shd-security_iam_service-with-iam-roles-tempcreds) | Sí |
| [Sesiones de acceso directo (FAS)](#shd-security_iam_service-with-iam-principal-permissions) | Sí |
| [Roles de servicio](#shd-security_iam_service-with-iam-roles-service) | Sí |
| [Roles vinculados al servicio](#shd-security_iam_service-with-iam-roles-service-linked) | Sí |
Para obtener una visión general de cómo funcionan Shield y otros AWS servicios con la mayoría de las funciones de IAM, consulte [AWS los servicios que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) en la Guía del usuario de *IAM*.
## Políticas de Shield basadas en identidades
En esta sección se proporcionan ejemplos de políticas basadas en la identidad para. AWS Shield
**Compatibilidad con las políticas basadas en identidad:** sí
Las políticas basadas en identidad son documentos de políticas de permisos JSON que puede asociar a una identidad, como un usuario de IAM, un grupo de usuarios o un rol. Estas políticas controlan qué acciones pueden realizar los usuarios y los roles, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en la identidad, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.
Con las políticas basadas en identidades de IAM, puede especificar las acciones y los recursos permitidos o denegados, así como las condiciones en las que se permiten o deniegan las acciones. Para obtener más información sobre los elementos que puede utilizar en una política de JSON, consulte [Referencia de los elementos de la política de JSON de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) en la *Guía del usuario de IAM*.
Para ver ejemplos de políticas basadas en identidad de Shield, consulte [Ejemplos de políticas basadas en la identidad para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## Políticas basadas en recursos de Shield
**Admite políticas basadas en recursos:** no
Las políticas basadas en recursos son documentos de política JSON que se asocian a un recurso. Los ejemplos de políticas basadas en recursos son las *políticas de confianza de roles* de IAM y las *políticas de bucket* de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Para el recurso al que se asocia la política, la política define qué acciones puede realizar una entidad principal especificada en ese recurso y en qué condiciones. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos. Los principales pueden incluir cuentas, usuarios, roles, usuarios federados o. Servicios de AWS
Para habilitar el acceso entre cuentas, puede especificar toda una cuenta o entidades de IAM de otra cuenta como la entidad principal de una política en función de recursos. Para obtener más información, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
## Acciones de política para Shield
**Compatibilidad con las acciones de políticas:** sí
Los administradores pueden usar las políticas de AWS JSON para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Action` de una política JSON describe las acciones que puede utilizar para conceder o denegar el acceso en una política. Incluya acciones en una política para conceder permisos y así llevar a cabo la operación asociada.
Para ver una lista de las acciones de Shield, consulte [Acciones definidas por AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions) en la *Referencia de autorizaciones de servicio*.
Las acciones de políticas de Shield utilizan el siguiente prefijo antes de la acción:
```
shield
```
Para especificar varias acciones en una única instrucción, sepárelas con comas.
```
"Action": [
"shield:action1",
"shield:action2"
]
```
Puede utilizar caracteres comodín (\$1) para especificar varias acciones . Por ejemplo, para especificar todas las acciones de Shield que comiencen con `List`, incluya la siguiente acción:
```
"Action": "shield:List*"
```
Para ver ejemplos de políticas basadas en identidad de Shield, consulte [Ejemplos de políticas basadas en la identidad para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## Recursos de políticas de Shield
**Compatibilidad con los recursos de políticas:** sí
Los administradores pueden usar las políticas de AWS JSON para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Resource` de la política JSON especifica el objeto u objetos a los que se aplica la acción. Como práctica recomendada, especifique un recurso utilizando el [Nombre de recurso de Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). En el caso de las acciones que no admiten permisos por recurso, utilice un carácter comodín (\$1) para indicar que la instrucción se aplica a todos los recursos.
```
"Resource": "*"
```
Para ver la lista de tipos de recursos de Shield y sus tipos ARNs, consulte [los recursos definidos por AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-resources-for-iam-policies) en la *Referencia de autorización de servicio*. Para obtener información sobre las acciones con las que puede especificar el ARN de cada recurso, consulte [Acciones definidas por AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions). Para permitir o denegar el acceso a un subconjunto de recursos de Shield, incluya el ARN del recurso en el elemento `resource` de la política.
En AWS Shield, los recursos son *protecciones* y *ataques*. Estos recursos tienen nombres de recursos de Amazon (ARNs) exclusivos asociados a ellos, como se muestra en la siguiente tabla.
****
| Nombre en la AWS Shield consola | Nombre en AWS Shield SDK/CLI | Formato de ARN |
| --- | --- | --- |
| Evento o ataque | AttackDetail | `arn:aws:shield::account:attack/ID` |
| Protección | Protection | `arn:aws:shield::account:protection/ID` |
Para permitir o denegar el acceso a un subconjunto de recursos de Shield, incluya el ARN del recurso en el elemento `resource` de la política. Los ARNs for Shield tienen el siguiente formato:
```
arn:partition:shield::account:resource/ID
```
Sustituya las *ID* variables *account**resource*, y por valores válidos. Los valores válidos pueden ser los siguientes:
+ *account*: El identificador de su Cuenta de AWS. Debe especificar un valor.
+ *resource*: El tipo de recurso Shield, uno `attack` u otro`protection`.
+ *ID*: el ID del recurso Shield o un comodín (`*`) para indicar todos los recursos del tipo especificado que están asociados al especificado Cuenta de AWS.
Por ejemplo, los siguientes ARN especifican todas las protecciones de la cuenta `111122223333`:
```
arn:aws:shield::111122223333:protection/*
```
Los recursos ARNs de of Shield tienen el siguiente formato:
```
arn:partition:shield:region:account-id:scope/resource-type/resource-name/resource-id
```
Para obtener información general sobre las especificaciones del ARN, consulte [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) en el. Referencia general de Amazon Web Services
A continuación se enumeran los requisitos específicos ARNs de los `wafv2` recursos:
+ *region*: En el caso de los recursos de Shield que utilizas para proteger CloudFront las distribuciones de Amazon, establécelo en. `us-east-1` De lo contrario, establézcalo en la región que esté utilizando con sus recursos regionales protegidos.
+ *scope*: establece el alcance `global` para usarlo con una CloudFront distribución de Amazon o `regional` para usarlo con cualquiera de los recursos regionales AWS WAF compatibles. Los recursos regionales son una API REST de Amazon API Gateway, un Application Load Balancer, una API de AWS AppSync GraphQL, un grupo de usuarios de Amazon Cognito, un AWS App Runner servicio y una instancia de Verified Access. AWS
+ *resource-type*: especifique uno de los siguientes valores: `attack` para eventos o ataques, `protection` para protecciones.
+ *resource-name*: especifique el nombre que asignó al recurso Shield o especifique un comodín (`*`) para indicar todos los recursos que cumplen las demás especificaciones del ARN. Debe especificar el nombre y el identificador del recurso, o especificar un comodín para ambos.
+ *resource-id*: especifique el ID del recurso Shield o especifique un comodín (`*`) para indicar todos los recursos que cumplen las demás especificaciones del ARN. Debe especificar el nombre y el identificador del recurso, o especificar un comodín para ambos.
Por ejemplo, el siguiente ARN especifica todos los sitios web ACLs con alcance regional para la cuenta `111122223333` en Región: `us-west-1`
```
arn:aws:wafv2:us-west-1:111122223333:regional/webacl/*/*
```
El siguiente ARN especifica el grupo de reglas denominado `MyIPManagementRuleGroup` con un alcance global para la cuenta `111122223333` en la región `us-east-1`:
```
arn:aws:wafv2:us-east-1:111122223333:global/rulegroup/MyIPManagementRuleGroup/1111aaaa-bbbb-cccc-dddd-example-id
```
Para ver ejemplos de políticas basadas en identidad de Shield, consulte [Ejemplos de políticas basadas en la identidad para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## Claves de condición de política de Shield
**Compatibilidad con claves de condición de políticas específicas del servicio:** sí
Los administradores pueden usar las políticas de AWS JSON para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Condition` especifica cuándo se ejecutan las instrucciones en función de criterios definidos. Puede crear expresiones condicionales que utilizan [operadores de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tales como igual o menor que, para que la condición de la política coincida con los valores de la solicitud. Para ver todas las claves de condición AWS globales, consulte las claves de [contexto de condición AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) en la *Guía del usuario de IAM*.
Para ver una lista de las claves de condición de Shield, consulte [Claves de condición para AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-policy-keys) en la *Referencia de autorizaciones de servicio*. Para saber con qué acciones y recursos puede utilizar una clave de condición, consulte [Acciones definidas por AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions).
Para ver ejemplos de políticas basadas en identidad de Shield, consulte [Ejemplos de políticas basadas en la identidad para AWS Shield](shd-security_iam_id-based-policy-examples.md).
## ACLs en Shield
**Soportes ACLs:** No
Las listas de control de acceso (ACLs) controlan qué directores (miembros de la cuenta, usuarios o roles) tienen permisos para acceder a un recurso. ACLs son similares a las políticas basadas en recursos, aunque no utilizan el formato de documento de políticas JSON.
## ABAC con Shield
**Compatibilidad con ABAC (etiquetas en las políticas):** parcial
El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define permisos en función de atributos denominados etiquetas. Puede adjuntar etiquetas a las entidades y AWS los recursos de IAM y, a continuación, diseñar políticas de ABAC para permitir las operaciones cuando la etiqueta del director coincida con la etiqueta del recurso.
Para controlar el acceso en función de etiquetas, debe proporcionar información de las etiquetas en el [elemento de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de una política utilizando las claves de condición `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`.
Si un servicio admite las tres claves de condición para cada tipo de recurso, el valor es **Sí** para el servicio. Si un servicio admite las tres claves de condición solo para algunos tipos de recursos, el valor es **Parcial**.
*Para obtener más información sobre ABAC, consulte [Definición de permisos con la autorización de ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) en la Guía del usuario de IAM*. Para ver un tutorial con los pasos para configurar ABAC, consulte [Uso del control de acceso basado en atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) en la *Guía del usuario de IAM*.
## Uso de credenciales temporales con Shield
**Compatibilidad con credenciales temporales:** sí
Las credenciales temporales proporcionan acceso a AWS los recursos a corto plazo y se crean automáticamente cuando se utiliza la federación o se cambia de rol. AWS recomienda generar credenciales temporales de forma dinámica en lugar de utilizar claves de acceso a largo plazo. Para obtener más información, consulte [Credenciales de seguridad temporales en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) y [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) en la *Guía del usuario de IAM*.
## Sesiones de acceso directo para Shield
**Admite sesiones de acceso directo (FAS):** sí
Las sesiones de acceso directo (FAS) utilizan los permisos del principal que llama y los que solicitan Servicio de AWS para realizar solicitudes a los servicios descendentes. Servicio de AWS Para obtener información sobre las políticas a la hora de realizar solicitudes de FAS, consulte [Sesiones de acceso directo](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Roles de servicio de Shield
**Compatible con roles de servicio:** sí
Un rol de servicio es un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que asume un servicio para realizar acciones en su nombre. Un administrador de IAM puede crear, modificar y eliminar un rol de servicio desde IAM. Para obtener más información, consulte [Crear un rol para delegar permisos a un Servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) en la *Guía del usuario de IAM*.
**aviso**
Cambiar los permisos de un rol de servicio podría interrumpir la funcionalidad de Shield. Edite los roles de servicio solo cuando Shield proporcione orientación para hacerlo.
## Roles vinculados a servicios de Shield
**Compatible con roles vinculados al servicio:** sí
Un rol vinculado a un servicio es un tipo de rol de servicio que está vinculado a un. Servicio de AWS El servicio puede asumir el rol para realizar una acción en su nombre. Los roles vinculados al servicio aparecen en usted Cuenta de AWS y son propiedad del servicio. Un administrador de IAM puede ver, pero no editar, los permisos de los roles vinculados a servicios.
Para obtener más información acerca de cómo crear o administrar roles vinculados a servicios Shield, consulte [Uso de roles vinculados a servicios para Shield Avanzado](shd-using-service-linked-roles.md).
# Ejemplos de políticas basadas en la identidad para AWS Shield
De forma predeterminada, los usuarios y roles no tienen permiso para crear o modificar recursos de Shield. Un administrador de IAM puede crear políticas de IAM para conceder permisos a los usuarios para realizar acciones en los recursos que necesitan.
Para obtener información acerca de cómo crear una política basada en identidades de IAM mediante el uso de estos documentos de políticas JSON de ejemplo, consulte [Creación de políticas de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) en la *Guía del usuario de IAM*.
Para obtener más información sobre las acciones y los tipos de recursos definidos por Shield, incluido el ARNs formato de cada uno de los tipos de recursos, consulte [las claves de condición, recursos y acciones de AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html) la *Referencia de autorización de servicio*.
**Topics**
+ [Prácticas recomendadas sobre las políticas](#shd-security_iam_service-with-iam-policy-best-practices)
+ [Uso de la consola de Shield](#shd-security_iam_id-based-policy-examples-console)
+ [Cómo permitir a los usuarios consultar sus propios permisos](#shd-security_iam_id-based-policy-examples-view-own-permissions)
+ [Concesión de acceso de lectura a sus protecciones de Shield Avanzado](#shd-example0)
+ [Otorgue acceso de solo lectura a Shield, y CloudFront CloudWatch](#shd-example1)
+ [Otorga acceso completo a Shield CloudFront, y CloudWatch](#shd-example2)
## Prácticas recomendadas sobre las políticas
Las políticas basadas en identidades determinan si alguien puede crear, acceder o eliminar los recursos de Shield de la cuenta. Estas acciones pueden generar costos adicionales para su Cuenta de AWS. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidades:
+ **Comience con las políticas AWS administradas y avance hacia los permisos con privilegios mínimos**: para empezar a conceder permisos a sus usuarios y cargas de trabajo, utilice las *políticas AWS administradas* que otorgan permisos para muchos casos de uso comunes. Están disponibles en su. Cuenta de AWS Le recomendamos que reduzca aún más los permisos definiendo políticas administradas por el AWS cliente que sean específicas para sus casos de uso. Con el fin de obtener más información, consulte las [políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o las [políticas administradas por AWS para funciones de tarea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) en la *Guía de usuario de IAM*.
+ **Aplique permisos de privilegio mínimo**: cuando establezca permisos con políticas de IAM, conceda solo los permisos necesarios para realizar una tarea. Para ello, debe definir las acciones que se pueden llevar a cabo en determinados recursos en condiciones específicas, también conocidos como *permisos de privilegios mínimos*. Con el fin de obtener más información sobre el uso de IAM para aplicar permisos, consulte [Políticas y permisos en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario de IAM*.
+ **Utilice condiciones en las políticas de IAM para restringir aún más el acceso**: puede agregar una condición a sus políticas para limitar el acceso a las acciones y los recursos. Por ejemplo, puede escribir una condición de políticas para especificar que todas las solicitudes deben enviarse utilizando SSL. También puedes usar condiciones para conceder el acceso a las acciones del servicio si se utilizan a través de una acción específica Servicio de AWS, por ejemplo CloudFormation. Para obtener más información, consulte [Elementos de la política de JSON de IAM: Condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) en la *Guía del usuario de IAM*.
+ **Utiliza el analizador de acceso de IAM para validar las políticas de IAM con el fin de garantizar la seguridad y funcionalidad de los permisos**: el analizador de acceso de IAM valida políticas nuevas y existentes para que respeten el lenguaje (JSON) de las políticas de IAM y las prácticas recomendadas de IAM. El analizador de acceso de IAM proporciona más de 100 verificaciones de políticas y recomendaciones procesables para ayudar a crear políticas seguras y funcionales. Para más información, consulte [Validación de políticas con el Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) en la *Guía del usuario de IAM*.
+ **Requerir autenticación multifactor (MFA**): si tiene un escenario que requiere usuarios de IAM o un usuario raíz en Cuenta de AWS su cuenta, active la MFA para mayor seguridad. Para exigir la MFA cuando se invoquen las operaciones de la API, añada condiciones de MFA a sus políticas. Para más información, consulte [Acceso seguro a la API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) en la *Guía del usuario de IAM*.
Para obtener más información sobre las prácticas recomendadas de IAM, consulte [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*.
## Uso de la consola de Shield
Para acceder a la AWS Shield consola, debe tener un conjunto mínimo de permisos. Estos permisos deben permitirle enumerar y ver detalles sobre los recursos de Shield que tiene Cuenta de AWS. Si crea una política basada en identidades que sea más restrictiva que el mínimo de permisos necesarios, la consola no funcionará del modo esperado para las entidades (usuarios o roles) que tengan esa política.
No es necesario que concedas permisos mínimos de consola a los usuarios que solo realicen llamadas a la API AWS CLI o a la AWS API. En su lugar, permita el acceso únicamente a las acciones que coincidan con la operación de API que intentan realizar.
Los usuarios que pueden acceder a la AWS consola y utilizarla también pueden acceder a AWS Shield ella. No requieren otros permisos.
### Solo para consola APIs
Puede acceder a la siguiente información sobre los ataques de denegación de servicio distribuido en la consola. DDo Especifique los siguientes permisos de API en una política de IAM para permitir o denegar acciones específicas.
| Action | Description (Descripción) |
| --- | --- |
| DescribeAttackContributors | Otorga permiso para obtener información detallada sobre las personas que contribuyen a un ataque DDo S específico. |
| ListMitigations | Otorga permiso para recuperar una lista de las acciones de mitigación que se han aplicado durante los ataques DDo S. |
| GetGlobalThreatData | Otorga permiso para recuperar datos y tendencias de inteligencia sobre amenazas globales de los sistemas de monitoreo de amenazas de AWS Shield. |
En este ejemplo, se muestra cómo puede crear una política que le permita ver la información sobre DDo los ataques S en la consola.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"shield:DescribeAttackContributors"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"shield:ListMitigations"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"shield:GetGlobalThreatData"
],
"Resource": "*"
}
]
}
```
------
## Cómo permitir a los usuarios consultar sus propios permisos
En este ejemplo, se muestra cómo podría crear una política que permita a los usuarios de IAM ver las políticas administradas e insertadas que se asocian a la identidad de sus usuarios. Esta política incluye permisos para completar esta acción en la consola o mediante programación mediante la API AWS CLI o AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Concesión de acceso de lectura a sus protecciones de Shield Avanzado
AWS Shield permite el acceso a los recursos entre cuentas, pero no permite crear protecciones de recursos entre cuentas. Solo puede crear protecciones para los recursos desde la cuenta que posee esos recursos.
A continuación, se muestra un ejemplo de política que concede permisos para la acción `shield:ListProtections` en todos los recursos. Shield no permite identificar recursos específicos mediante el recurso ARNs (también denominados permisos de nivel de recurso) para algunas de las acciones de la API, por lo que debes especificar un carácter comodín (\$1). Esto solo permite el acceso a los recursos que puede recuperar a través de la acción `ListProtections`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListProtections",
"Effect": "Allow",
"Action": [
"shield:ListProtections"
],
"Resource": "*"
}
]
}
```
------
## Otorgue acceso de solo lectura a Shield, y CloudFront CloudWatch
La siguiente política otorga a los usuarios acceso de solo lectura a Shield y a los recursos asociados, incluidos los recursos de Amazon CloudFront y las métricas de Amazon CloudWatch . Es útil para los usuarios que necesitan permiso para ver la configuración de las protecciones y los ataques de Shield y para monitorear las métricas en ella CloudWatch. Estos usuarios no pueden crear, actualizar ni eliminar recursos de Shield.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ProtectedResourcesReadAccess",
"Effect": "Allow",
"Action": [
"cloudfront:List*",
"route53:List*",
"cloudfront:Describe*",
"elasticloadbalancing:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"cloudfront:GetDistribution*",
"globalaccelerator:ListAccelerators",
"globalaccelerator:DescribeAccelerator"
],
"Resource": [
"arn:aws:elasticloadbalancing:*:*:*",
"arn:aws:cloudfront::*:*",
"arn:aws:route53:::hostedzone/*",
"arn:aws:cloudwatch:*:*:*:*",
"arn:aws:globalaccelerator::*:*"
]
},
{
"Sid": "ShieldReadOnly",
"Effect": "Allow",
"Action": [
"shield:List*",
"shield:Describe*",
"shield:Get*"
],
"Resource": "*"
}
]
}
```
------
## Otorga acceso completo a Shield CloudFront, y CloudWatch
La siguiente política permite a los usuarios realizar cualquier operación de Shield, realizar cualquier operación en distribuciones CloudFront web y monitorear las métricas y una muestra de solicitudes en CloudWatch. Resulta muy útil para los usuarios que son administradores de Shield.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ProtectedResourcesReadAccess",
"Effect": "Allow",
"Action": [
"cloudfront:List*",
"route53:List*",
"cloudfront:Describe*",
"elasticloadbalancing:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"cloudfront:GetDistribution*",
"globalaccelerator:ListAccelerators",
"globalaccelerator:DescribeAccelerator"
],
"Resource": [
"arn:aws:elasticloadbalancing:*:*:*",
"arn:aws:cloudfront::*:*",
"arn:aws:route53:::hostedzone/*",
"arn:aws:cloudwatch:*:*:*:*",
"arn:aws:globalaccelerator::*:*"
]
},
{
"Sid": "ShieldFullAccess",
"Effect": "Allow",
"Action": [
"shield:*"
],
"Resource": "*"
}
]
}
```
------
Recomendamos encarecidamente que configure la autenticación multifactor (MFA) para los usuarios que tienen permisos administrativos. Para obtener más información, consulte [Uso de la autenticación multifactor (MFA) en dispositivos con AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingMFA.html) en la *Guía del usuario de IAM*.
# AWS políticas gestionadas para AWS Shield
Una política AWS administrada es una política independiente creada y administrada por AWS. AWS Las políticas administradas están diseñadas para proporcionar permisos para muchos casos de uso comunes, de modo que pueda empezar a asignar permisos a usuarios, grupos y funciones.
Ten en cuenta que es posible que las políticas AWS administradas no otorguen permisos con privilegios mínimos para tus casos de uso específicos, ya que están disponibles para que los usen todos los AWS clientes. Se recomienda definir [políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) específicas para sus casos de uso a fin de reducir aún más los permisos.
No puedes cambiar los permisos definidos en AWS las políticas administradas. Si AWS actualiza los permisos definidos en una política AWS administrada, la actualización afecta a todas las identidades principales (usuarios, grupos y roles) a las que está asociada la política. AWS es más probable que actualice una política AWS administrada cuando Servicio de AWS se lance una nueva o cuando estén disponibles nuevas operaciones de API para los servicios existentes.
Para obtener más información, consulte [Políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) en la *Guía del usuario de IAM*.
## AWS política gestionada: AWSShield DRTAccess política
En esta sección se explica cómo utilizar las políticas AWS gestionadas para Shield.
AWS Shield utiliza esta política gestionada cuando concedes permiso al Shield Response Team (SRT) para que actúe en tu nombre. Esta política otorga al SRT acceso limitado a su AWS cuenta para ayudar a mitigar los ataques DDo S durante eventos de alta gravedad. Esta política permite a la SRT gestionar sus AWS WAF reglas y las protecciones de Shield Advanced y acceder a sus AWS WAF registros.
Para obtener información sobre cómo conceder permisos al SRT para que opere en su nombre, consulte. [Concesión del acceso al SRT](ddos-srt-access.md)
Para obtener más información sobre esta política, consulte la [AWSShieldDRTAccessPolítica](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSShieldDRTAccessPolicy) en la consola de IAM.
## AWS política gestionada: AWSShield ServiceRolePolicy
Shield Advanced usa esta política administrada cuando habilita la mitigación automática de la capa DDo S de aplicación, a fin de establecer los permisos que necesita para administrar los recursos de su cuenta. Esta política permite a Shield Advanced crear y aplicar AWS WAF reglas y grupos de reglas en la web ACLs que haya asociado a sus recursos protegidos para responder automáticamente a los ataques DDo S.
No puedes asociarte AWSShield ServiceRolePolicy a tus entidades de IAM. Shield asocia esta política al rol vinculado a servicios `AWSServiceRoleForAWSShield` para permitir que Shield realice acciones en su nombre.
Shield Advanced permite el uso de esta política al activar la mitigación automática de la capa DDo S de aplicación. Para obtener más información acerca del uso de esta política, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
Para obtener información sobre el rol vinculado al servicio AWSService RoleFor AWSShield que usa esta política, consulte [Uso de roles vinculados a servicios para Shield Avanzado](shd-using-service-linked-roles.md)
Para obtener más información sobre esta política, consulte [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy)en la consola de IAM.
## Shield actualiza las políticas AWS gestionadas
Consulta los detalles sobre las actualizaciones de las políticas AWS gestionadas de Shield desde que este servicio comenzó a rastrear estos cambios. Para obtener alertas automáticas sobre cambios en esta página, suscríbase a la fuente RSS en la página de historial de documentos de Shield en [Historial de documentos](doc-history.md).
| Política | Descripción del cambio | Date |
| --- | --- | --- |
| `AWSShieldServiceRolePolicy` Esta política permite a Shield acceder a AWS los recursos y gestionarlos para responder automáticamente a los ataques de la capa de aplicación DDo S en su nombre. Detalles en la consola de IAM: [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy) El rol vinculado al servicio `AWSServiceRoleForAWSShield` emplea esta política. Para obtener información, consulte [Uso de roles vinculados a servicios para Shield Avanzado](shd-using-service-linked-roles.md). | Se agregó esta política para proporcionar a Shield Advanced los permisos necesarios para la funcionalidad de mitigación automática de la capa DDo S. Para obtener información acerca de esta característica, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md). | 1 de diciembre de 2021 |
| Shield comenzó a realizar un seguimiento de los cambios | Shield comenzó a realizar un seguimiento de los cambios en sus políticas AWS gestionadas. | 3 de marzo de 2021 |
# Solución de problemas AWS Shield de identidad y acceso
Utilice la siguiente información para ayudar a diagnosticar y solucionar los problemas comunes que puedan surgir cuando trabaje con Shield e IAM.
**Topics**
+ [No tengo autorización para realizar una acción en Shield](#shd-security_iam_troubleshoot-no-permissions)
+ [No estoy autorizado a realizar tareas como: PassRole](#shd-security_iam_troubleshoot-passrole)
+ [Quiero permitir que personas ajenas a mí accedan Cuenta de AWS a mis recursos de Shield](#shd-security_iam_troubleshoot-cross-account-access)
## No tengo autorización para realizar una acción en Shield
Si recibe un error que indica que no tiene autorización para realizar una acción, las políticas se deben actualizar para permitirle realizar la acción.
En el siguiente ejemplo, el error se produce cuando el usuario de IAM `mateojackson` intenta utilizar la consola para consultar los detalles acerca de un recurso ficticio `my-example-widget`, pero no tiene los permisos ficticios `shield:GetWidget`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: shield:GetWidget on resource: my-example-widget
```
En este caso, la política del usuario `mateojackson` debe actualizarse para permitir el acceso al recurso `my-example-widget` mediante la acción `shield:GetWidget`.
Si necesita ayuda, póngase en contacto con su AWS administrador. El administrador es la persona que le proporcionó las credenciales de inicio de sesión.
## No estoy autorizado a realizar tareas como: PassRole
Si recibe un error que indica que no tiene autorización para realizar la acción `iam:PassRole`, se deben actualizar las políticas a fin de permitirle pasar un rol a Shield.
Algunas Servicios de AWS permiten transferir una función existente a ese servicio en lugar de crear una nueva función de servicio o una función vinculada a un servicio. Para ello, debe tener permisos para transferir la función al servicio.
En el siguiente ejemplo, el error se produce cuando un usuario de IAM denominado `marymajor` intenta utilizar la consola para realizar una acción en Shield. Sin embargo, la acción requiere que el servicio cuente con permisos que otorguen un rol de servicio. Mary no tiene permisos para transferir el rol al servicio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
En este caso, las políticas de Mary se deben actualizar para permitirle realizar la acción `iam:PassRole`.
Si necesita ayuda, póngase en contacto con su AWS administrador. El administrador es la persona que le proporcionó las credenciales de inicio de sesión.
## Quiero permitir que personas ajenas a mí accedan Cuenta de AWS a mis recursos de Shield
Se puede crear un rol que los usuarios de otras cuentas o las personas externas a la organización puedan utilizar para acceder a sus recursos. Se puede especificar una persona de confianza para que asuma el rol. En el caso de los servicios que respaldan las políticas basadas en recursos o las listas de control de acceso (ACLs), puede usar esas políticas para permitir que las personas accedan a sus recursos.
Para obtener más información, consulte lo siguiente:
+ Para obtener información acerca de si Shield admite estas características, consulte [Cómo AWS Shield funciona con IAM](shd-security_iam_service-with-iam.md).
+ Para obtener información sobre cómo proporcionar acceso a los recursos de su Cuentas de AWS propiedad, consulte [Proporcionar acceso a un usuario de IAM en otro de su propiedad en la Cuenta de AWS Guía del usuario](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) de *IAM*.
+ Para obtener información sobre cómo proporcionar acceso a tus recursos a terceros Cuentas de AWS, consulta Cómo [proporcionar acceso a recursos que Cuentas de AWS son propiedad de terceros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) en la Guía del usuario de *IAM*.
+ Para obtener información sobre cómo proporcionar acceso mediante una federación de identidades, consulte [Proporcionar acceso a usuarios autenticados externamente (identidad federada)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) en la *Guía del usuario de IAM*.
+ Para obtener información sobre la diferencia entre los roles y las políticas basadas en recursos para el acceso entre cuentas, consulte [Cómo los roles de IAM difieren de las políticas basadas en recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) en la *Guía del usuario de IAM*.
# Uso de roles vinculados a servicios para Shield Avanzado
En esta sección se explica cómo utilizar las funciones vinculadas a servicios para dar a Shield Advanced acceso a los recursos de su AWS cuenta.
AWS Shield Advanced [usa roles vinculados al AWS Identity and Access Management servicio (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un rol vinculado a un servicio es un tipo único de rol de IAM que está vinculado directamente a Shield Avanzado. Shield Advanced predefine las funciones vinculadas al servicio e incluyen todos los permisos que el servicio requiere para llamar a otros AWS servicios en su nombre.
Un rol vinculado a un servicio simplifica la configuración de Shield Avanzado, puesto que ya no hará falta añadir manualmente los permisos necesarios. Shield Avanzado define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Shield Avanzado puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda adjuntar a ninguna otra entidad de IAM.
Solo es posible eliminar un rol vinculado a un servicio después de eliminar sus recursos relacionados. De esta forma, se protegen los recursos de Shield Avanzado, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
Para obtener información acerca de otros servicios que admiten roles vinculados a servicios, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Sí** en la columna **Rol vinculado a un servicio**. Elija una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
## Permisos de roles vinculados a servicios para Shield Avanzado
Shield Advanced usa el rol vinculado al servicio denominado. **AWSServiceRoleForAWSShield** Esta función permite a Shield Advanced acceder a AWS los recursos y gestionarlos para responder automáticamente a los ataques de la capa DDo S de aplicación en su nombre. Para obtener más información acerca de esta funcionalidad, consulte [Automatizar la mitigación de la capa DDo S de aplicación con Shield Advanced](ddos-automatic-app-layer-response.md).
El rol AWSService RoleFor AWSShield vinculado al servicio confía en los siguientes servicios para asumir el rol:
+ `shield.amazonaws.com`
La política de permisos de roles denominada AWSShield ServiceRolePolicy permite a Shield Advanced realizar las siguientes acciones en todos los AWS recursos:
+ `wafv2:GetWebACL`
+ `wafv2:UpdateWebACL`
+ `wafv2:GetWebACLForResource`
+ `wafv2:ListResourcesForWebACL`
+ `cloudfront:ListDistributions`
+ `cloudfront:GetDistribution`
Cuando se permiten acciones en todos los AWS recursos, esto se indica en la política como`"Resource": "*"`. Esto solo significa que la función vinculada al servicio puede realizar cada acción indicada en todos los AWS recursos *compatibles con la acción*. Por ejemplo, la acción `wafv2:GetWebACL` solo es compatible con los recursos de ACL web de `wafv2`.
Shield Advanced solo realiza llamadas a la API a nivel de recursos para los recursos protegidos para los que haya habilitado la función de protección de la capa de aplicación y para la web ACLs que estén asociados a esos recursos protegidos.
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear, editar o eliminar un rol vinculado a servicios. Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*.
## Creación de un rol vinculado a un servicio para Shield Avanzado
No necesita crear manualmente un rol vinculado a servicios. Cuando habilita la mitigación automática de la capa DDo S de aplicación para un recurso en la Consola de administración de AWS AWS CLI, la o la AWS API, Shield Advanced crea el rol vinculado al servicio automáticamente.
Si elimina este rol vinculado a servicios y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Al habilitar la mitigación automática de la capa DDo S de aplicación para un recurso, Shield Advanced vuelve a crear el rol vinculado al servicio para usted.
## Modificación de un rol vinculado a un servicio para Shield Avanzado
Shield Advanced no permite editar el rol AWSService RoleFor AWSShield vinculado al servicio. Después de crear un rol vinculado al servicio, no podrá cambiar el nombre del rol, ya que varias entidades podrían hacer referencia al rol. Sin embargo, sí puede editar la descripción del rol con IAM. Para obtener más información, consulte [Edición de un rol vinculado a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*.
## Eliminación de un rol vinculado a un servicio para Shield Avanzado
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. Así no tendrá una entidad no utilizada que no se supervise ni mantenga de forma activa. Sin embargo, debe limpiar los recursos de su rol vinculado al servicio antes de eliminarlo manualmente.
**nota**
Si Shield Avanzado está utilizando el rol cuando se intentan eliminar los recursos, es posible que se produzcan errores en la operación de eliminación. En tal caso, espere unos minutos e intente de nuevo la operación.
**Para eliminar los recursos de Shield Advanced que utiliza el AWSService RoleFor AWSShield**
Para todos los recursos que tengan configuradas las protecciones de la capa de aplicación DDo S, desactive la mitigación automática de la capa de aplicación DDo S. Para obtener instrucciones sobre la consola, consulte [Configure las protecciones de la capa DDo S de aplicación](manage-protection.md#configure-app-layer-protection).
**Para eliminar manualmente el rol vinculado a servicios mediante IAM**
Utilice la consola de IAM AWS CLI, la o la AWS API para eliminar la función vinculada al AWSService RoleFor AWSShield servicio. Para obtener más información, consulte [Eliminación de un rol vinculado a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*.
## Regiones admitidas para los roles vinculados a servicios de Shield Avanzado
Shield Avanzado admite el uso de roles vinculados a servicios en todas las regiones en las que el servicio esté disponible. Para obtener más información, consulte [Puntos de conexiones y cuotas de Shield Avanzado](https://docs.aws.amazon.com/general/latest/gr/shield.html).
# Registro y supervisión en Shield
En esta sección se explica cómo utilizar AWS las herramientas para supervisar y responder a los eventos en AWS Shield.
La supervisión es una parte importante del mantenimiento de la fiabilidad, la disponibilidad y el rendimiento de Shield y sus AWS soluciones. Debe recopilar los datos de supervisión de todas las partes de la AWS solución para poder depurar con mayor facilidad una falla multipunto en caso de que se produzca alguna. AWS proporciona varias herramientas para supervisar tus recursos de Shield y responder a posibles eventos:
** CloudWatch Alarmas Amazon**
Al usar CloudWatch las alarmas, puede observar una única métrica durante un período de tiempo que especifique. Si la métrica supera un umbral determinado, CloudWatch envía una notificación a un tema o AWS Auto Scaling política de Amazon SNS. Para obtener más información, consulte [Monitorización con Amazon CloudWatch](monitoring-cloudwatch.md).
**AWS CloudTrail Registros**
CloudTrail proporciona un registro de las acciones realizadas por un usuario, un rol o un AWS servicio en Shield. Con la información recopilada por CloudTrail, puede determinar la solicitud que se realizó a Shield, la dirección IP desde la que se realizó la solicitud, quién la hizo, cuándo se realizó y detalles adicionales. Para obtener más información, consulte [Registro de llamadas a la API de AWS CloudTrail con](logging-using-cloudtrail.md).
# Validación del cumplimiento en Shield
En esta sección se explica su responsabilidad de cumplimiento al utilizarlos AWS Shield.
Para saber si un programa de cumplimiento Servicio de AWS está dentro del ámbito de aplicación de programas de cumplimiento específicos, consulte [Servicios de AWS Alcance por programa](https://aws.amazon.com/compliance/services-in-scope/) de de cumplimiento y elija el programa de cumplimiento que le interese. Para obtener información general, consulte Programas de [AWS cumplimiento > Programas AWS](https://aws.amazon.com/compliance/programs/) .
Puede descargar informes de auditoría de terceros utilizando AWS Artifact. Para obtener más información, consulte [Descarga de informes en AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Su responsabilidad de cumplimiento al Servicios de AWS utilizarlos viene determinada por la confidencialidad de sus datos, los objetivos de cumplimiento de su empresa y las leyes y reglamentos aplicables. Para obtener más información sobre su responsabilidad de conformidad al utilizarlos Servicios de AWS, consulte [AWS la documentación de seguridad](https://docs.aws.amazon.com/security/).
# Infraestructura para la resiliencia en Shield
En esta sección se explica cómo la AWS arquitectura admite la redundancia de datos para. AWS Shield
La infraestructura AWS global se basa en zonas Regiones de AWS de disponibilidad. Regiones de AWS proporcionan varias zonas de disponibilidad aisladas y separadas físicamente, que están conectadas mediante redes de baja latencia, alto rendimiento y alta redundancia. Con las zonas de disponibilidad, puede diseñar y utilizar aplicaciones y bases de datos que realizan una conmutación por error automática entre zonas de disponibilidad sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de centros de datos únicos o múltiples.
[Para obtener más información sobre las zonas de disponibilidad Regiones de AWS y las zonas de disponibilidad, consulte Infraestructura global.AWS](https://aws.amazon.com/about-aws/global-infrastructure/)
# Seguridad de la infraestructura en AWS Shield
En esta sección se explica cómo AWS Shield aísla el tráfico de servicio.
Como servicio gestionado, AWS Shield está protegido por la seguridad de la red AWS global. Para obtener información sobre los servicios AWS de seguridad y cómo se AWS protege la infraestructura, consulte [Seguridad AWS en la nube](https://aws.amazon.com/security/). Para diseñar su AWS entorno utilizando las mejores prácticas de seguridad de la infraestructura, consulte [Protección de infraestructuras en un marco](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) de buena * AWS arquitectura basado en el pilar de la seguridad*.
Utiliza las llamadas a la API AWS publicadas para acceder a Shield a través de la red. Los clientes deben admitir lo siguiente:
+ Seguridad de la capa de transporte (TLS). Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Conjuntos de cifrado con confidencialidad directa total (PFS) como DHE (Ephemeral Diffie-Hellman) o ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles con estos modos.
# AWS Shield Advanced cuotas
AWS Shield Advanced tiene cuotas predeterminadas en cuanto al número de entidades por región. Puede [solicitar un aumento](https://console.aws.amazon.com/servicequotas/home/services/shield/quotas) de dichas cuotas.
| Recurso | Cuota predeterminada |
| --- | --- |
| Número máximo de recursos protegidos por cuenta para cada tipo de recurso que AWS Shield Advanced ofrece protección. | 1 000 |
| Número máximo de grupos de protección por cuenta. | 100 |
| Número máximo de recursos protegidos individuales que puede incluir específicamente en un grupo de protección. En la API, esto se aplica a los `Members` que se especifiquen al configurar el grupo de protección `Pattern` como `ARBITRARY`. En la consola, esto se aplica a los recursos que seleccione para la agrupación de protección **Elija entre los recursos protegidos**. | 1 000 |