• El panel de AWS Systems Manager CloudWatch dejará de estar disponible después del 30 de abril de 2026. Los clientes pueden seguir utilizando la consola de Amazon CloudWatch para ver, crear y administrar sus paneles de Amazon CloudWatch, tal y como lo hacen actualmente. Para obtener más información, consulte la [documentación del panel de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
# AWS Systems Manager Patch Manager
Patch Manager, una herramienta de AWS Systems Manager, automatiza el proceso de aplicación de revisiones a los nodos administrados con actualizaciones relacionadas con la seguridad y otros tipos de actualizaciones.
**nota**
Systems Manager proporciona soporte para las *políticas de revisiones* en Quick Setup, una herramienta de AWS Systems Manager. El uso de políticas de revisiones es el método recomendado para configurar las operaciones de aplicación de revisiones. Con una configuración de política de revisiones única, puede definir la aplicación de revisiones para todas las cuentas de todas las regiones de su organización; solo para las cuentas y regiones que elija; o para un solo par de cuentas-regiones. Para obtener más información, consulte [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md).
Puede utilizar Patch Manager para aplicar revisiones a los sistemas operativos y a las aplicaciones. (En Windows Server, la compatibilidad con las aplicaciones se limita a las actualizaciones de las aplicaciones publicadas por Microsoft). Puede utilizar Patch Manager para instalar Service Packs en los nodos de Windows y realizar actualizaciones de versiones secundarias en nodos de Linux. Puede aplicar revisiones a flotas de instancias de Amazon Elastic Compute Cloud (Amazon EC2), dispositivos de borde, servidores en las instalaciones y a máquinas virtuales (VM) por tipo de sistema operativo. Esto incluye las versiones compatibles de varios sistemas operativos, tal como se indica en [Patch ManagerRequisitos previos de](patch-manager-prerequisites.md). Puede analizar instancias solo para ver un informe de las revisiones que faltan, o bien puede analizar e instalar automáticamente todas las revisiones que faltan. Para comenzar a utilizar Patch Manager, abra la [consola de Systems Manager](https://console.aws.amazon.com//systems-manager/patch-manager). En el panel de navegación, elija **Patch Manager**.
AWS no prueba las revisiones antes de que estén disponibles en Patch Manager. Además, Patch Manager no admite la actualización de versiones principales de sistemas operativos, como Windows Server 2016 a Windows Server 2019 o Red Hat Enterprise Linux (RHEL) 7.0 a RHEL 8.0.
Para los tipos de sistemas operativos basados en Linux que informan de un nivel de gravedad de las revisiones, Patch Manager utiliza el nivel de gravedad notificado por el editor de software para el aviso de actualización o la revisión individual. Patch Manager no deriva los niveles de gravedad de orígenes de terceros, como el [Sistema de puntuación de vulnerabilidades comunes](https://www.first.org/cvss/) (CVSS), ni de métricas publicadas por la [Base de datos nacional de vulnerabilidades](https://nvd.nist.gov/vuln) (NVD).
## ¿Cómo puede Patch Manager beneficiar a mi organización?
Patch Manager automatiza el proceso de aplicación de revisiones a los nodos administrados con actualizaciones relacionadas con la seguridad y otros tipos de actualizaciones. Proporciona varios beneficios clave:
+ **Control de revisiones centralizado**: mediante políticas de revisiones, puede configurar operaciones de revisión periódicas para todas las cuentas en todas las regiones de su organización, cuentas y regiones específicas o un solo par de cuenta y región.
+ **Operaciones de revisión flexibles**: puede analizar instancias para ver solo un informe de las revisiones que faltan, o bien puede analizar todas las revisiones que faltan e instalarlas automáticamente.
+ **Informes de conformidad exhaustivos**: tras las operaciones de análisis, puede ver información detallada sobre qué nodos administrados no cumplen con las revisiones y qué revisiones faltan.
+ **Compatibilidad entre plataformas**: Patch Manager admite varios sistemas operativos, incluidas varias distribuciones de Linux, macOS y Windows Server.
+ **Líneas de base de revisiones personalizadas**: puede definir qué constituye el cumplimiento de las revisiones para su organización mediante líneas de base de revisiones personalizadas que especifican qué revisiones están aprobados para su instalación.
+ **Integración con otros servicios de AWS**: Patch Manager se integra con AWS Organizations, AWS Security Hub CSPM, AWS CloudTrail y AWS Config para mejorar la administración y la seguridad.
+ **Actualizaciones deterministas**: es compatible con actualizaciones deterministas mediante repositorios versionados para sistemas operativos como Amazon Linux 2023.
## ¿Quién debe utilizar Patch Manager?
Patch Manager está diseñado para lo siguiente:
+ Administradores de TI que necesitan mantener el cumplimiento de las revisiones en toda su flota de nodos administrados.
+ Gerentes de operaciones que necesitan visibilidad del estado de cumplimiento de las revisiones en toda su infraestructura.
+ Arquitectos de nube que desean implementar soluciones de aplicación de revisiones automatizadas a escala.
+ Ingenieros de DevOps que necesitan integrar la aplicación de revisiones en sus flujos de trabajo operativos.
+ Organizaciones con implementaciones de varias cuentas o regiones que necesitan una administración de revisiones centralizada.
+ Cualquier persona responsable de mantener la postura de seguridad y el estado operativo de los nodos administrados, los dispositivos de periferia, los servidores en las instalaciones y las máquinas virtuales de AWS
## ¿Cuáles son las características principales de Patch Manager?
Patch Manager ofrece varias características fundamentales:
+ **Políticas de revisión**: configure las operaciones de revisión en varias Cuentas de AWS y regiones mediante una única política a través de la integración con AWS Organizations.
+ **Líneas de base de revisiones personalizadas**: defina reglas para la aprobación automática de revisiones a los pocos días de su lanzamiento, junto con listas de revisiones aprobadas y rechazadas.
+ **Múltiples métodos de revisión**: elija entre políticas de revisiones, ventanas de mantenimiento u operaciones bajo demanda del tipo “Aplicar revisión ahora” para satisfacer sus necesidades específicas.
+ **Informes de cumplimiento**: genere informes detallados sobre el estado de cumplimiento de las revisiones que se pueden enviar a un bucket de Amazon S3 en formato CSV.
+ **Compatibilidad entre plataformas**: revise tanto a sistemas operativos como a aplicaciones en Windows Server, en varias distribuciones de Linux y en macOS.
+ **Flexibilidad de planificación**: establezca diferentes plazos para analizar e instalar revisiones mediante expresiones de frecuencia o CRON personalizadas.
+ **Enlaces de ciclo de vida**: ejecute scripts personalizados antes y después de las operaciones de revisión mediante documentos de Systems Manager.
+ **Enfoque de seguridad**: Patch Manager se centra de forma predeterminada en las actualizaciones relacionadas con la seguridad en lugar de instalar todas las revisiones disponibles.
+ **Control de velocidad**: configure los umbrales de concurrencia y error para las operaciones de revisión a fin de minimizar el impacto operativo.
## ¿En qué consiste el cumplimiento en Patch Manager?
El punto de referencia para determinar qué constituye la *conformidad de las revisiones* para los nodos administrados de sus flotas de Systems Manager no está definido por AWS, los proveedores de sistemas operativos (SO) ni terceros, como las empresas de consultoría de seguridad.
En su lugar, usted define lo que significa el cumplimiento de las revisiones para los nodos administrados de su organización o cuenta a partir de una *línea de base de revisiones*. Una línea de base de revisiones es una configuración que especifica las reglas sobre qué revisiones deben instalarse en un nodo administrado. Un nodo administrado es compatible con las revisiones cuando está actualizado con todas las revisiones que cumplen los criterios de aprobación que se especifican en la línea de base de revisiones.
Tenga en cuenta que el *cumplimiento* con la línea de base de revisiones no significa que un nodo administrado sea necesariamente *seguro*. El cumplimiento implica que las revisiones definidas en la línea de base de revisiones, que están *disponibles* y han sido *aprobadas*, se han instalado en el nodo. La seguridad general de un nodo administrado viene determinada por muchos factores ajenos al ámbito de Patch Manager. Para obtener más información, consulte [Seguridad en AWS Systems Manager](security.md).
La línea de base de revisiones es una configuración para un tipo de sistema operativo (SO) compatible específico, como Red Hat Enterprise Linux (RHEL), macOS o Windows Server. La línea de base de revisiones puede definir las reglas de aplicación de revisiones para todas las versiones compatibles de un sistema operativo o limitarse únicamente a las que usted especifique, como RHEL 7.8 y RHEL 9.3.
En una línea de base de revisiones, puede especificar que se aprueben para la instalación todas las revisiones con determinadas clasificaciones y niveles de gravedad. Por ejemplo, puede incluir todas las revisiones clasificadas como `Security`, pero excluir otras clasificaciones, como `Bugfix` o `Enhancement`. También puede incluir todas las revisiones con una gravedad `Critical` igual o excluir otras, como `Important` y `Moderate`.
También puede definir las revisiones de forma explícita en una línea de base de revisiones si agrega sus ID a listas de revisiones específicas para aprobarlas o rechazarlas, como `KB2736693` para Windows Server o `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` para Amazon Linux 2023 (AL2023). Si lo desea, puede especificar un número determinado de días de espera para aplicar las revisiones una vez que una revisión esté disponible. En el caso de Linux y macOS, tiene la opción de especificar una lista externa de revisiones para garantizar el cumplimiento (una lista de anulación de la instalación) en lugar de las definidas en la reglas de la línea de base de revisiones.
Cuando se ejecuta una operación de aplicación de revisiones, Patch Manager compara las revisiones aplicadas actualmente a un nodo administrado con las que deberían aplicarse de acuerdo con las reglas establecidas en la línea de base de revisiones o en una lista de anulación de la instalación. Puede optar por que Patch Manager muestre solo un informe de las revisiones faltantes (una operación `Scan`) o puede optar por que Patch Manager instale automáticamente todas las revisiones que encuentre que faltan en un nodo administrado (un operación `Scan and install`).
**nota**
Los datos de conformidad de las revisiones representan una instantánea puntual de la última operación de aplicación de revisiones exitosa. Cada informe de conformidad contiene un tiempo de captura que identifica cuándo se calculó el estado de conformidad. Cuando revise los datos de conformidad, tenga en cuenta el tiempo de captura para determinar si la operación se ejecutó según lo previsto.
Patch Manager proporciona líneas de base de revisiones predefinidas que puede utilizar para sus operaciones de aplicación de revisiones; sin embargo, estas configuraciones predefinidas se proporcionan como ejemplos y no como prácticas recomendadas. Le recomendamos que cree sus propias líneas de base de revisiones personalizadas para tener un mayor control sobre lo que constituye el cumplimiento de las revisiones en su flota.
Para obtener más información sobre la creación de líneas de base de revisiones personalizadas, consulte los temas siguientes:
+ [Líneas de base de revisiones personalizadas y predefinidas](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md)
+ [Visualización de bases de referencia de parches predefinidas de AWS](patch-manager-view-predefined-patch-baselines.md)
+ [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md)
+ [Trabajo con informes de conformidad de las revisiones](patch-manager-compliance-reports.md)
## Componentes principales
Antes de empezar a trabajar con la herramienta Patch Manager, debe familiarizarse con algunos componentes y características principales de las operaciones de aplicación de revisiones de la herramienta.
**líneas de base de revisiones**
Patch Manager utiliza *líneas de base de revisiones*, las cuales incluyen reglas para la aprobación automática de revisiones a los pocos días de su lanzamiento, así como una lista de las revisiones aprobadas y rechazadas. Cuando se ejecuta una operación de aplicación de revisiones, Patch Manager compara las revisiones aplicadas actualmente a un nodo administrado con las que deberían aplicarse de acuerdo con las reglas establecidas en la línea de base de revisiones. Puede optar por que Patch Manager muestre solo un informe de las revisiones faltantes (una operación `Scan`) o puede optar por que Patch Manager instale automáticamente todas las revisiones que encuentre que faltan en un nodo administrado (un operación `Scan and install`).
**Métodos de operación de aplicación de revisiones**
Patch Manager ofrece actualmente cuatro métodos para ejecutar operaciones `Scan` y `Scan and install`:
+ **(Recomendado) Una política de revisiones configurada en Quick Setup**: basada en la integración con AWS Organizations, una única política de revisiones puede definir programaciones de aplicación de revisiones y líneas de base de revisiones para toda una organización, incluidas varias Cuentas de AWS y en las Regiones de AWS que operan todas esas cuentas. Una política de revisiones también puede dirigirse únicamente a algunas unidades organizativas (OU) de una organización. Puede utilizar una única política de revisiones para analizar e instalar en diferentes programaciones. Para obtener más información, consulte [Cómo configurar las revisiones para las instancias de una organización mediante una política de parches Quick Setup](quick-setup-patch-manager.md) y [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md).
+ **Una opción de administración de host configurada en Quick Setup**: las configuraciones de administración de host también son compatibles con la integración con AWS Organizations, lo que permite ejecutar una operación de aplicación de revisiones para una organización completa. Sin embargo, esta opción se limita a analizar revisiones faltantes utilizando la línea de base de revisiones predeterminada actual y a proporcionar resultados en los informes de conformidad. Este método de operación no puede instalar revisiones. Para obtener más información, consulte [Instalar la administración de host de Amazon EC2 mediante Quick Setup](quick-setup-host-management.md).
+ **Un periodo de mantenimiento para ejecutar una tarea `Scan` o `Install` de revisiones**: se puede establecer un periodo de mantenimiento, el cual se configura en la herramienta de Systems Manager denominada Maintenance Windows, para ejecutar diferentes tipos de tareas según una programación que defina. Se puede utilizar una tarea de tipo Run Command para ejecutar tareas `Scan` o `Scan and install` en un conjunto de nodos administrados que usted elija. Cada tarea del periodo de mantenimiento puede dirigirse a los nodos administrados en un único par de Cuenta de AWS-Región de AWS. Para obtener más información, consulte [Tutorial: creación de un periodo de mantenimiento para la aplicación de revisiones mediante la consola](maintenance-window-tutorial-patching.md).
+ **Una operación de **Aplicar revisión ahora** bajo demanda en Patch Manager**: la opción de **Aplicar revisión ahora** le permite omitir las configuraciones programadas cuando necesite aplicar revisiones a los nodos administrados lo antes posible. Con **Patch now** (Aplicar revisión ahora), se especifica si se va a ejecutar una operación de `Scan` o `Scan and install` y en qué nodos administrados se va a ejecutar la operación. También puede optar por ejecutar documentos de Systems Manager (documentos SSM) como enlaces de ciclo de vida durante la operación de revisión. Cada operación de **Patch now** (Aplicar revisión ahora) puede dirigirse a los nodos administrados en un único par Cuenta de AWS-Región de AWS. Para obtener más información, consulte [Aplicación de revisiones a nodos administrados bajo demanda](patch-manager-patch-now-on-demand.md).
**Informes de conformidad**
Tras una operación de `Scan`, puede utilizar la consola de Systems Manager para ver información sobre cuáles nodos administrados no cumplen con las revisiones y qué revisiones faltan en cada uno de esos nodos. También puede generar informes relativos a la conformidad de las revisiones en formato .csv que se envían a un bucket de Amazon Simple Storage Service (Amazon S3) de su elección. Puede generar informes por única vez o generarlos de manera periódica. Para un único nodo administrado, los informes incluyen detalles de todas las revisiones del nodo. Para un informe sobre todos los nodos administrados, solo se proporciona un resumen de cuántas revisiones faltan. Después de generar un informe, puede utilizar una herramienta como Amazon Quick para importar y analizar los datos. Para obtener más información, consulte [Trabajo con informes de conformidad de las revisiones](patch-manager-compliance-reports.md).
**nota**
Un elemento de conformidad generado mediante el uso de una política de revisiones tiene un tipo de ejecución de `PatchPolicy`. Un elemento de conformidad no generado en una operación de política de revisiones tiene un tipo de ejecución de `Command`.
**Integraciones**
Patch Manager se integra con los siguientes otros Servicios de AWS:
+ **AWS Identity and Access Management (IAM)**: utilice IAM para controlar qué usuarios, grupos y roles tienen acceso a las operaciones de Patch Manager. Para obtener más información, consulte [Cómo funciona AWS Systems Manager con IAM](security_iam_service-with-iam.md) y [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md).
+ **AWS CloudTrail** – utilice CloudTrail para registrar un historial auditable de los eventos de operación de aplicación de revisiones iniciados por usuarios, roles o grupos. Para obtener más información, consulte [Registro de llamadas a la API de AWS Systems Manager con AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **AWS Security Hub CSPM**: se pueden enviar los datos de conformidad de revisiones de Patch Manager a AWS Security Hub CSPM. Security Hub CSPM ofrece una visión completa de las alertas de seguridad de alta prioridad y el estado de conformidad. También monitorea el estado de aplicación de revisiones de la flota. Para obtener más información, consulte [Integración de Patch Manager con AWS Security Hub CSPM](patch-manager-security-hub-integration.md).
+ **AWS Config**: configure la grabación en AWS Config para ver los datos de administración de instancias de Amazon EC2 en el panel de control de Patch Manager. Para obtener más información, consulte [Visualización de resúmenes del panel de revisiones](patch-manager-view-dashboard-summaries.md).
**Topics**
+ [¿Cómo puede Patch Manager beneficiar a mi organización?](#how-can-patch-manager-benefit-my-organization)
+ [¿Quién debe utilizar Patch Manager?](#who-should-use-patch-manager)
+ [¿Cuáles son las características principales de Patch Manager?](#what-are-the-main-features-of-patch-manager)
+ [¿En qué consiste el cumplimiento en Patch Manager?](#patch-manager-definition-of-compliance)
+ [Componentes principales](#primary-components)
+ [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md)
+ [Patch ManagerRequisitos previos de](patch-manager-prerequisites.md)
+ [Cómo funcionan las operaciones de Patch Manager](patch-manager-patching-operations.md)
+ [Documentos de comando de SSM para la aplicación de revisiones a nodos administrados](patch-manager-ssm-documents.md)
+ [líneas de base de revisiones](patch-manager-patch-baselines.md)
+ [Uso de Kernel Live Patching en nodos administrados de Amazon Linux 2](patch-manager-kernel-live-patching.md)
+ [Trabajo con los recursos Patch Manager y el cumplimiento mediante la consola](patch-manager-console.md)
+ [Trabajar con recursos Patch Manager mediante la AWS CLI](patch-manager-cli-commands.md)
+ [Tutoriales de AWS Systems Manager Patch Manager](patch-manager-tutorials.md)
+ [Resolución de problemas de Patch Manager](patch-manager-troubleshooting.md)
# Configuraciones de políticas de revisiones en Quick Setup
AWS recomienda el uso de *políticas de revisiones* para configurar las revisiones para su organización y sus Cuentas de AWS. Las políticas de revisiones se introdujeron en Patch Manager en diciembre de 2022.
Una política de revisiones es un ajuste que se configura mediante Quick Setup, una herramienta de AWS Systems Manager. Las políticas de revisiones brindan un control más amplio y centralizado sobre sus operaciones de aplicación de revisiones que el que estaba disponible con los métodos anteriores de configuración de aplicación de revisiones. Las políticas de revisiones se pueden usar con [todos los sistemas operativos compatibles con Patch Manager](patch-manager-prerequisites.md#pm-prereqs), incluidas las versiones compatibles de Linux, macOS y Windows Server. Para obtener instrucciones sobre cómo crear una política de revisión, consulte [Cómo configurar las revisiones para las instancias de una organización mediante una política de parches Quick Setup](quick-setup-patch-manager.md).
## Características principales de las políticas de revisiones
En lugar de usar otros métodos para aplicar revisiones a sus nodos, use una política de revisiones para aprovechar estas características principales:
+ **Configuración única**: la configuración de operaciones de aplicación de revisiones mediante un periodo de mantenimiento o una asociación State Manager puede requerir múltiples tareas en diferentes partes de la consola de Systems Manager. Mediante una política de revisiones, todas las operaciones de aplicación de revisiones se pueden configurar en un solo asistente.
+ **Compatibilidad con cuentas y regiones múltiples**: al usar un periodo de mantenimiento, una asociación State Manager o la función **Patch now** (Aplicar revisión ahora) en Patch Manager, usted se ve limitado a apuntar a los nodos administrados en un único par Cuenta de AWS-Región de AWS. Si utiliza varias cuentas y regiones, sus tareas de configuración y mantenimiento pueden requerir una gran cantidad de tiempo, ya que debe realizar tareas de configuración en cada par de cuenta y región. Sin embargo, si utiliza AWS Organizations, puede configurar una política de revisiones que aplique a todos sus nodos administrados en todas las Regiones de AWS en todas sus Cuentas de AWS. O, si lo desea, la política de revisiones solo se puede aplicar a algunas unidades organizativas (OU) de las cuentas y regiones que elija. También se puede aplicar una política de revisiones a una sola cuenta local, si así lo desea.
+ **Soporte de instalación a nivel organizativo**: la opción de configuración de administración de host existente en Quick Setup brinda soporte para un análisis diario de sus nodos administrados para la conformidad de revisiones. Sin embargo, este análisis se realiza en un momento predeterminado y solo proporciona información sobre la conformidad de las revisiones. No se realiza ninguna instalación de revisiones. Mediante una política de revisiones, puede especificar diferentes programaciones de análisis e instalación. También puede elegir la frecuencia y el tiempo de estas operaciones mediante expresiones CRON o Rate personalizadas. Por ejemplo, puede hacer un análisis para encontrar revisiones faltantes todos los días y así obtener información de conformidad que se actualiza periódicamente. Sin embargo, su programación de instalación puede ser solo una vez por semana para evitar tiempos de inactividad no deseados.
+ **Selección simplificada de la línea de base de revisiones**: las políticas de revisiones aún incorporan líneas de base de revisiones y no hay cambios en la forma en que estas se configuran. Sin embargo, cuando crea o actualiza una política de revisiones, puede seleccionar la línea de base de AWS personalizada o administrada que desea utilizar para cada tipo de sistema operativo (SO) en una sola lista. No es necesario especificar la línea de base predeterminada para cada tipo de sistema operativo en tareas independientes.
**nota**
Cuando se ejecutan operaciones de aplicación de revisiones basadas en una política de revisiones, utilizan el documento de SSM `AWS-RunPatchBaseline`. Para obtener más información, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
**Información relacionada**
[Implemente de forma centralizada las operaciones de aplicación de revisiones en toda la organización de AWS mediante Systems Manager Quick Setup](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/) (Blog sobre operaciones y migraciones en la nube de AWS)
## Otras diferencias con las políticas de revisiones
Estas son algunas otras diferencias que se deben tener en cuenta al utilizar políticas de revisiones en lugar de los métodos anteriores para configurar la aplicación de revisiones:
+ **No se requieren grupos de revisiones**: en operaciones de aplicación de revisiones anteriores, podía etiquetar varios nodos para que pertenecieran a un grupo de revisiones y luego especificar la línea de base de revisiones que se usaría para ese grupo de revisiones. Si no se definió ningún grupo de revisiones, Patch Manager aplicó revisiones en las instancias con la línea de base de revisiones predeterminada actual para el tipo de sistema operativo. Con las políticas de revisiones, ya no es necesario configurar y mantener grupos de revisiones.
**nota**
La consola no admite la funcionalidad de grupos de parches para pares de cuentas y regiones que no usaban grupos de parches antes de que se publicara la compatibilidad con las políticas de parches el 22 de diciembre de 2022. La funcionalidad de grupos de parches sigue estando disponible en los pares de cuentas y regiones que empezaron a usar grupos de parches antes de esta fecha.
+ **Se eliminó la página "Configurar aplicación de revisiones"**: antes del lanzamiento de las políticas de aplicación de revisiones, podía especificar valores predeterminados para qué nodos aplicar revisiones, una programación de aplicación de revisiones y una operación de aplicación de revisiones en una página para **Configurar aplicación de revisiones**. Se ha eliminado esta página de Patch Manager. Estas opciones ahora se especifican en las políticas de revisiones.
+ **No hay compatibilidad con ‘Patch now’** (Aplicar revisión ahora): la capacidad de aplicar revisiones a nodos bajo demanda todavía está limitada a un solo par Cuenta de AWS-Región de AWS a la vez. Para obtener más información, consulte [Aplicación de revisiones a nodos administrados bajo demanda](patch-manager-patch-now-on-demand.md).
+ **Políticas de revisiones e información de conformidad**: cuando se analizan sus nodos administrados para verificar la conformidad de acuerdo con una configuración de política de aplicación de revisiones, los datos de conformidad se ponen a su disposición. Puede ver los datos y trabajar con ellos de la misma manera que con otros métodos de análisis de conformidad. Aunque puede configurar una política de revisiones para toda una organización o varias unidades organizativas, la información de conformidad se brinda individualmente para cada par Cuenta de AWS-Región de AWS. Para obtener más información, consulte [Trabajo con informes de conformidad de las revisiones](patch-manager-compliance-reports.md).
+ **Estado de conformidad de la asociación y políticas de revisiones**: el estado de las revisiones para un nodo administrado bajo una política de revisiones de Quick Setup coincide con el estado de la ejecución de la asociación de State Manager de ese nodo. Si el estado de ejecución de la asociación es `Compliant`, el estado de las revisiones del nodo administrado también se marca como `Compliant`. Si el estado de ejecución de la asociación es `Non-Compliant`, el estado de las revisiones del nodo administrado también se marca como `Non-Compliant`.
## Regiones de AWS compatibles con las políticas de revisiones
Las configuraciones de políticas de revisiones en Quick Setup se admiten actualmente en las siguientes regiones:
+ Este de EE. UU. (Ohio) (us-east-2)
+ Este de EE. UU. (Norte de Virginia) (us-east-1)
+ EE. UU. Oeste (Norte de California) (us-west-1)
+ Oeste de EE. UU. (Oregón) (us-west-2)
+ Asia-Pacífico (Mumbai) (ap-south-1)
+ Asia-Pacífico (Seúl) (ap-northeast-2)
+ Asia-Pacífico (Singapur) (ap-southeast-1)
+ Asia-Pacífico (Sídney) (ap-southeast-2)
+ Asia-Pacífico (Tokio) (ap-northeast-1)
+ Canadá (centro) (ca-central-1)
+ Europa (Fráncfort) (eu-central-1)
+ Europa (Irlanda) (eu-west-1)
+ Europa (Londres) (eu-west-2)
+ UE (París) (eu-west-3)
+ Europa (Estocolmo) (eu-north-1)
+ América del Sur (São Paulo) (sa-east-1)
# Patch ManagerRequisitos previos de
Asegúrese de que haya cumplido los requisitos previos necesarios antes de usar Patch Manager, una herramienta de AWS Systems Manager.
**Topics**
+ [SSM AgentVersión](#agent-versions)
+ [Versión de Python](#python-version)
+ [Requisitos adicionales del paquete](#additional-package-requirements)
+ [Conectividad con la fuente de revisiones](#source-connectivity)
+ [Acceso al punto de enlace de S3](#s3-endpoint-access)
+ [Permisos para instalar revisiones localmente](#local-installation-permissions)
+ [Sistemas operativos admitidos por Patch Manager](#supported-os)
## SSM AgentVersión
La versión 2.0.834.0 o una versión posterior de SSM Agent debe ejecutarse en los nodos administrados que desee administrar con Patch Manager.
**nota**
Cada vez que se agregan herramientas nuevas a Systems Manager o se actualizan las herramientas existentes, se lanza una versión actualizada de SSM Agent. No utilizar la versión más reciente del agente puede impedir que el nodo administrado utilice diversas herramientas y características de Systems Manager. Por este motivo, se recomienda automatizar el proceso de mantener SSM Agent actualizado en los equipos. Para obtener más información, consulte [Automatización de las actualizaciones de SSM Agent](ssm-agent-automatic-updates.md). Suscríbase a la página [SSM Agent Release Notes](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) en GitHub para recibir notificaciones sobre las actualizaciones de SSM Agent.
## Versión de Python
En la actualidad, para macOS y la mayoría de los sistemas operativos (SO) Linux, Patch Manager es compatible con las versiones 2.6 a 3.12 de Python. Los sistemas operativos de AlmaLinux, Debian Server y Ubuntu Server requieren una versión compatible de Python 3 (3.0 a 3.12).
## Requisitos adicionales del paquete
En el caso de los sistemas operativos basados en DNF, es posible que se necesiten las utilidades `zstd`, `xz` y `unzip` para descomprimir la información del repositorio y los archivos de parches. Los sistemas operativos basados en DNF incluyen Amazon Linux 2023, Red Hat Enterprise Linux 8 y versiones posteriores, Oracle Linux 8 y versiones posteriores, Rocky Linux, AlmaLinux y CentOS 8 y versiones posteriores. Si ve un error similar al de `No such file or directory: b'zstd'`, `No such file or directory: b'unxz'`, o si el fallo al aplicar los parches se debe a que falta `unzip`, debe instalar estas utilidades. `zstd`, `xz` y `unzip` se pueden instalar si ejecuta lo siguiente:
```
dnf install zstd xz unzip
```
## Conectividad con la fuente de revisiones
Si los nodos administrados no disponen de una conexión directa a Internet y utiliza una Amazon Virtual Private Cloud (Amazon VPC) con un punto de conexión de VPC, debe asegurarse de que los nodos tengan acceso a los repositorios (repos) de revisiones de origen. En los nodos de Linux, las actualizaciones de revisiones suelen descargarse de los repositorios remotos configurados en el nodo. Por lo tanto, el nodo debe poder conectarse a los repositorios para que puedan aplicarse las revisiones. Para obtener más información, consulte [Cómo se seleccionan los parches de seguridad](patch-manager-selecting-patches.md).
Cuando aplique revisiones a un nodo que se ejecuta en un entorno exclusivo de IPv6, asegúrese de que el nodo tenga conectividad con la fuente de la revisión. Puede comprobar el resultado Run Command de la ejecución de la revisión para comprobar si hay advertencias sobre repositorios inaccesibles. En el caso de los sistemas operativos basados en DNF, es posible configurar los repositorios no disponibles para que se omitan durante la aplicación de revisiones si la opción `skip_if_unavailable` está establecida en `True` en `/etc/dnf/dnf.conf`. Los sistemas operativos basados en DNF incluyen Amazon Linux 2023, Red Hat Enterprise Linux 8 y versiones posteriores, Oracle Linux 8 y versiones posteriores, Rocky Linux, AlmaLinux y CentOS 8 y versiones posteriores. En Amazon Linux 2023, la opción `skip_if_unavailable` está establecida en `True` de forma predeterminada.
**CentOS Stream: Activa la bandera `EnableNonSecurity`**
Los nodos CentOS Stream utilizan DNF como administrador de paquetes, que utiliza el concepto de aviso de actualización. Un aviso de actualización es simplemente una colección de paquetes que solucionan un problema determinado.
Sin embargo, los repositorios predeterminados de CentOS Stream no se configuran con un aviso de actualización. Esto significa que Patch Manager no detecta paquetes en repositorios de CentOS Stream predeterminados. Para permitir que Patch Manager procese paquetes no incluidos en avisos de actualización, debe activar la marca `EnableNonSecurity` en las reglas de base de referencia de los parches.
**Windows Server: garantiza la conectividad al catálogo de Windows Update o a Windows Server Update Services (WSUS)**
Windows ServerLos nodos administrados de deben poder conectarse al catálogo de Windows Update o a Windows Server Update Services (WSUS). Confirme que los nodos cuentan con conectividad al [catálogo de Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx) a través de una puerta de enlace de Internet, una puerta de enlace NAT o una instancia NAT. Si utiliza WSUS, confirme que el nodo dispone de conectividad con el servidor WSUS de su entorno. Para obtener más información, consulte [Asunto: el nodo administrado no tiene acceso al catálogo de Windows Update ni a WSUS](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access).
## Acceso al punto de enlace de S3
Tanto si los nodos administrados operan en una red privada como en una pública, sin tener acceso a los buckets requeridos de Amazon Simple Storage Service (Amazon S3) administrados por AWS, las operaciones de aplicación de revisiones pueden producir errores. Para obtener información acerca de los buckets de S3 a los que deben tener acceso los nodos administrados, consulte [SSM Agent Comunicaciones de AWS con buckets de S3 administrados de](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) y [Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager](setup-create-vpc.md).
## Permisos para instalar revisiones localmente
En los sistemas operativos Windows Server y Linux, Patch Manager asume las cuentas de administrador y usuario raíz, respectivamente, para instalar las revisiones.
Sin embargo, en macOS, para Brew y Brew Cask, Homebrew no admite que sus comandos se ejecuten con la cuenta del usuario raíz. Como resultado, Patch Manager consulta y ejecuta los comandos de Homebrew como propietario del directorio de Homebrew o como usuario válido perteneciente al grupo de propietarios de ese directorio. Por lo tanto, para instalar las revisiones, el propietario del directorio `homebrew` también necesita permisos de propietario recursivos para el directorio `/usr/local`.
**sugerencia**
El siguiente comando proporciona este permiso al usuario especificado:
```
sudo chown -R $USER:admin /usr/local
```
## Sistemas operativos admitidos por Patch Manager
Es posible que la herramienta Patch Manager no sea compatible con las mismas versiones de sistemas operativos que sí lo son con las demás herramientas de Systems Manager. (Para ver una lista completa de los sistemas operativos admitidos por Systems Manager, consulte ). [Sistemas operativos compatibles con Systems Manager](operating-systems-and-machine-types.md#prereqs-operating-systems).) Por lo tanto, asegúrese de que los nodos administrados que desea utilizar con Patch Manager ejecutan uno de los sistemas operativos que se muestran en la siguiente tabla.
**nota**
Patch Manager utiliza los repositorios de revisiones que estén configurados en un nodo administrado, como el Catálogo de Windows Update y Windows Server Update Services para Windows, para recuperar las revisiones disponibles que se deben instalar. Por lo tanto, para versiones del sistema operativo en el final de su vida útil (EOL), si no hay nuevas actualizaciones disponibles, es posible que Patch Manager no pueda informar sobre las nuevas actualizaciones. Esto puede deberse a que el responsable de la distribución de Linux, Microsoft o Apple no han publicado nuevas actualizaciones, o a que el nodo administrado no dispone de la licencia adecuada para acceder a las nuevas actualizaciones.
Le recomendamos encarecidamente que evite utilizar versiones del sistema operativo que hayan llegado al final de su vida útil (EOL). Los proveedores de sistemas operativos, incluso AWS, no suelen proporcionar revisiones de seguridad ni otras actualizaciones para las versiones que han llegado al final de su vida útil. Seguir utilizando un sistema EOL aumenta considerablemente el riesgo de no poder aplicar las actualizaciones, incluidas las correcciones de seguridad, y otros problemas operativos. AWS no prueba la funcionalidad de Systems Manager en las versiones del sistema operativo que han alcanzado el final de su vida.
Patch Manager informa del estado de conformidad respecto de las revisiones disponibles en el nodo administrado. Por lo tanto, si en una instancia se está ejecutando un sistema operativo EOL y no hay actualizaciones disponibles, es posible que Patch Manager indique que el nodo es conforme, dependiendo de las líneas de base de revisiones configuradas para la operación de revisión.
| Sistema operativo | Details |
| --- | --- |
| Linux | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-prerequisites.html) |
| macOS | *macOS solo es compatible con las instancias de Amazon EC2.* 13.0-13.7 (Ventura) 14*.x* (Sonoma) 15*.x* (Sequoia) Actualizaciones del sistema operativo macOS Patch Manager no es compatible con actualizaciones ni mejoras del sistema operativo (SO) para macOS, tales como pasar de la versión 13.1 a la 13.2. Para realizar actualizaciones de la versión del SO macOS, se recomienda utilizar los mecanismos de actualización del SO integrados de Apple. Para obtener más información, consulte [Device Management](https://developer.apple.com/documentation/devicemanagement) en el sitio web Apple Developer Documentation. Compatibilidad con Homebrew Patch Manager requiere que Homebrew, el sistema de administración de paquetes de software de código abierto, esté instalado en cualquiera de las siguientes ubicaciones de instalación predeterminadas: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-prerequisites.html) Las operaciones de revisión que utilizan Patch Manager no funcionan correctamente cuando Homebrew no está instalado. Compatibilidad de regiones macOS no se admite en todas las Regiones de AWS. Para obtener más información sobre la compatibilidad de Amazon EC2 con macOS, consulte [Instancias de Mac de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) en la *Guía del usuario de Amazon EC2*. Dispositivos periféricos de macOS No se admite SSM Agent para los dispositivos de núcleo de AWS IoT Greengrass en macOS. No se puede utilizar Patch Manager para aplicar revisiones a dispositivos de borde de macOS. |
| Windows | De Windows Server 2012 a Windows Server 2025, incluidas las versiones R2. No se admite SSM Agent para los dispositivos de núcleo AWS IoT Greengrass en Windows 10. No se puede utilizar Patch Manager para aplicar revisiones a dispositivos de borde de Windows 10. Windows Server 2012 y soporte de R2 de 2012 La compatibilidad con Windows Server 2012 y 2012 R2 finalizó el 10 de octubre de 2023. Para utilizar Patch Manager con estas versiones, se recomienda utilizar también las actualizaciones de seguridad ampliada (ESU) de Microsoft. Para obtener más información, consulte [Finaliza el soporte para Windows Server 2012 y 2012 R2](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support) en el sitio web de Microsoft. |
# Cómo funcionan las operaciones de Patch Manager
Esta sección proporciona detalles técnicos que explican cómo Patch Manager, una herramienta de AWS Systems Manager, determina cuáles son las revisiones que deben instalarse y el modo en que lo hace en cada sistema operativo compatible. En el caso de los sistemas operativos Linux, también proporciona información sobre cómo especificar un repositorio de origen en una base de referencia de revisiones personalizada para revisiones distintas de las predeterminadas configuradas en un nodo administrado. En esta sección se proporciona también información detallada acerca de cómo funcionan las reglas de líneas de base de revisiones en diversas distribuciones del sistema operativo Linux.
**nota**
La información en los siguientes temas se aplica independientemente del método o el tipo de configuración que utilice para las operaciones de aplicación de revisiones:
Una política de revisiones configurada en Quick Setup
Una opción de administración de host configurada en Quick Setup
Una ventana de mantenimiento para ejecutar una revisión `Scan` o una tarea `Install`
Una operación **Patch Now** (Aplicar revisión ahora) bajo demanda
**Topics**
+ [Cómo se calculan las fechas de lanzamiento y actualización de los paquetes](patch-manager-release-dates.md)
+ [Cómo se seleccionan los parches de seguridad](patch-manager-selecting-patches.md)
+ [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md)
+ [Cómo se instalan los parches](patch-manager-installing-patches.md)
+ [Funcionamiento de las reglas de bases de referencia de parches en los sistemas basados en Linux](patch-manager-linux-rules.md)
+ [Diferencias en la operación de revisiones entre Linux y Windows Server](patch-manager-windows-and-linux-differences.md)
# Cómo se calculan las fechas de lanzamiento y actualización de los paquetes
**importante**
La información de esta página se aplica a los sistemas operativos (SO) Amazon Linux 2 y Amazon Linux 2023 para las instancias de Amazon Elastic Compute Cloud (Amazon EC2). Amazon Web Services crea y mantiene los paquetes para estos tipos de sistemas operativos. La forma en que los fabricantes de otros sistemas operativos administran sus paquetes y repositorios afecta a la forma en que se calculan sus fechas de lanzamiento y actualización. Para sistemas operativos distintos de Amazon Linux 2 y Amazon Linux 2023, como Red Hat Enterprise Linux, consulte la documentación del fabricante para obtener información sobre cómo se actualizan y mantienen sus paquetes.
En la configuración de las [líneas de base de revisiones personalizadas](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) que cree, para la mayoría de los tipos de sistemas operativos, puede especificar que la instalación de las revisiones se apruebe automáticamente después de un número de días determinado. AWS proporciona varias líneas de base de revisiones predefinidas que incluyen fechas de aprobación automática de 7 días.
Un *tiempo de espera hasta la aprobación automática* es el número de días que se debe esperar después de que se haya lanzado la revisión y antes de que se apruebe automáticamente para aplicarla. Por ejemplo, se crea una regla mediante la clasificación de `CriticalUpdates` y se configura para establecer un tiempo de espera hasta la aprobación automática de 7 días. Como resultado, una nueva revisión crítica con una fecha de lanzamiento o una fecha de última actualización datada del 7 de julio se aprueba automáticamente el 14 de julio.
Para evitar resultados inesperados en el tiempo de espera hasta la aprobación automática en Amazon Linux 2 y Amazon Linux 2023, es importante entender cómo se calculan sus fechas de lanzamiento y actualización.
**nota**
Si un repositorio de Amazon Linux 2 o Amazon Linux 2023 no proporciona información sobre la fecha de publicación de los paquetes, Patch Manager utiliza el tiempo de compilación como la fecha de las especificaciones de aprobación automática. Si no se puede determinar el tiempo de compilación del paquete, Patch Manager utiliza una fecha predeterminada del 1 de enero de 1970. Esto resulta en que Patch Manager omita cualquier especificación de fecha de aprobación automática en las líneas base de revisiones que estén configuradas para aprobar revisiones en cualquier fecha posterior al 1 de enero de 1970.
En la mayoría de los casos, el tiempo de espera hasta la aprobación automática para instalar las revisiones se calcula a partir de un valor de `Updated Date` en `updateinfo.xml`, no un valor de `Release Date`. Los siguientes son detalles importantes sobre estos cálculos de fechas:
+ La `Release Date` es la fecha en que se lanza un *aviso*. Esto no significa que el paquete esté necesariamente disponible en los repositorios asociados.
+ La `Update Date` es la fecha más reciente en que se actualizó el aviso. La actualización de un aviso puede representar algo tan pequeño como la actualización de un texto o descripción. Esto no significa que el paquete se lanzó ese día o que esté necesariamente disponible en los repositorios asociados.
Esto significa que un paquete puede tener un valor de `Update Date` del 7 de julio, pero no podrá instalarse hasta, por ejemplo, el 13 de julio. Supongamos que, en este caso, una línea de base de revisiones que especifica un tiempo de espera de 7 días hasta la aprobación automática se ejecuta en una operación `Install` el 14 de julio. Dado que el valor de `Update Date` es 7 días antes de la fecha de ejecución, las revisiones y actualizaciones del paquete se instalan el 14 de julio. La instalación se realiza a pesar de que solo ha pasado 1 día desde que el paquete se puede instalar.
+ Un paquete que contenga revisiones del sistema operativo o aplicación se puede actualizar más de una vez después del lanzamiento inicial.
+ Se puede lanzar un paquete en los repositorios administrados por AWS, y más tarde revertirse si se identifican problemas relacionados con él.
En algunas operaciones de aplicación de revisiones, es posible que estos factores no sean importantes. Por ejemplo, si una línea de base de revisiones está configurada para instalar una revisión con valores de gravedad de `Low` y `Medium`, además de una clasificación de `Recommended`, cualquier tiempo de espera hasta la aprobación automática podría tener poco impacto en las operaciones.
Sin embargo, en los casos de revisiones críticas o de gravedad alta cuya programación sea más importante, puede ser conveniente tener un mayor control sobre cuándo deben instalarse. El método recomendado para hacerlo es utilizar repositorios de origen de revisiones alternativos en lugar de los predeterminados para las operaciones de aplicación de revisiones en un nodo administrado.
Puede especificar repositorios de origen de parches alternativos al crear una base de referencia de parches personalizada. En cada base de referencia de parches personalizada, es posible especificar configuraciones de origen de parches para un máximo de 20 versiones de un sistema operativo Linux compatible. Para obtener más información, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md).
# Cómo se seleccionan los parches de seguridad
Patch Manager, una herramienta de AWS Systems Manager, se centra principalmente en instalar actualizaciones relacionadas con la seguridad de los sistemas operativos en los nodos administrados. De forma predeterminada, Patch Manager no instala todos los parches disponibles, sino un conjunto de parches más reducido centrado en la seguridad.
Patch Manager no reemplaza de forma predeterminada un paquete que se haya marcado como obsoleto en un repositorio de paquetes con ningún paquete de reemplazo con un nombre diferente, a menos que este reemplazo sea necesario para la instalación de otra actualización de paquete. En cambio, para los comandos que actualizan un paquete, Patch Manager solo informa las actualizaciones que faltan para el paquete que está instalado, pero obsoleto y las instala. Esto se debe a que la sustitución de un paquete obsoleto suele requerir la desinstalación de un paquete existente y la instalación de uno de reemplazo. Reemplazar el paquete obsoleto podría introducir cambios importantes o funcionalidades adicionales que no se habían previsto.
Este comportamiento es coherente con el comando `update-minimal` de YUM y DNF, que se centra en las actualizaciones de seguridad más que en las mejoras de características. Para obtener más información, consulte [Cómo se instalan los parches](patch-manager-installing-patches.md).
**nota**
Cuando utiliza el parámetro `ApproveUntilDate` o el parámetro `ApproveAfterDays` en una regla de líneas de base de revisiones, Patch Manager evalúa las fechas de lanzamiento de la revisión mediante la hora universal coordinada (UTC).
Por ejemplo, en el caso de `ApproveUntilDate`, si especifica una fecha como `2025-11-16`, las revisiones publicadas entre `2025-11-16T00:00:00Z` y se `2025-11-16T23:59:59Z` aprobarán.
Tenga en cuenta que las fechas de lanzamiento de las revisiones que muestran los administradores de paquetes nativos de los nodos administrados pueden mostrar diferentes horas según la zona horaria local del sistema, pero Patch Manager siempre utiliza la fecha y hora UTC para los cálculos de aprobación. Esto garantiza la coherencia con las fechas de lanzamiento de las revisiones publicadas en los sitios web oficiales de asesoramiento de seguridad.
Para los tipos de sistemas operativos basados en Linux que informan de un nivel de gravedad de las revisiones, Patch Manager utiliza el nivel de gravedad notificado por el editor de software para el aviso de actualización o la revisión individual. Patch Manager no deriva los niveles de gravedad de orígenes de terceros, como el [Sistema de puntuación de vulnerabilidades comunes](https://www.first.org/cvss/) (CVSS), ni de las métricas publicadas por la [Base de datos nacional de vulnerabilidades](https://nvd.nist.gov/vuln) (NVD).
**nota**
En todos los sistemas basados en Linux compatibles con Patch Manager, es posible elegir un repositorio de origen distinto configurado para el nodo administrado, normalmente para instalar actualizaciones no relacionadas con la seguridad. Para obtener más información, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md).
Elija entre las siguientes pestañas para obtener información acerca de cómo Patch Manager selecciona parches de seguridad para el sistema operativo.
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
Los repositorios preconfigurados se administran de forma diferente en Amazon Linux 2 que en Amazon Linux 2023.
En Amazon Linux 2, el servicio de línea de base de revisiones de Systems Manager utiliza repositorios preconfigurados en los nodos administrados. Normalmente, hay dos repositorios preconfigurados (repos) en un nodo:
**En Amazon Linux 2**
+ **ID del repositorio**: `amzn2-core/2/architecture`
**Nombre del repositorio**: `Amazon Linux 2 core repository`
+ **ID del repositorio**: `amzn2extra-docker/2/architecture`
**Nombre del repositorio**: `Amazon Extras repo for docker`
**nota**
El valor *arquitectura* puede ser x86\$164 o aarch64 (para procesadores Graviton).
Cuando crea una instancia de Amazon Linux 2023 (AL2023), esta contiene las actualizaciones que estaban disponibles en la versión de AL2023 y la AMI específica que seleccionó. Su instancia AL2023 no recibe de manera automática las actualizaciones de seguridad críticas e importantes adicionales en el momento del lanzamiento. En cambio, con la característica de *actualizaciones deterministas a través de repositorios versionados* compatibles con AL2023, que está activada de forma predeterminada, puede aplicar las actualizaciones según una programación que se adapte a sus necesidades específicas. Para obtener información, consulte [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) en la *Guía del usuario de Amazon Linux 2023*.
En AL2023, el repositorio preconfigurado es el siguiente:
+ **ID del repositorio**: `amazonlinux`
**Nombre del repositorio**: repositorio de Amazon Linux 2023
En Amazon Linux 2023 (versión preliminar), los repositorios preconfigurados están vinculados a *las versiones bloqueadas* de las actualizaciones de paquetes. Cuando se lanzan nuevos Amazon Machine Images (AMIs) para AL2023, se bloquean en una versión específica. Para las actualizaciones de revisiones, Patch Manager recupera la última versión bloqueada del repositorio de actualizaciones de revisiones y, a continuación, actualiza los paquetes en el nodo administrado en función del contenido de esa versión bloqueada.
**Administradores de paquetes**
Los nodos administrados de Amazon Linux 2 utilizan Yum como administrador de paquetes. Amazon Linux 2023 utiliza DNF como el administrador de paquetes.
Ambos administradores de paquetes utilizan el concepto de un *aviso de actualización* como un archivo llamado `updateinfo.xml`. Un aviso de actualización es simplemente una colección de paquetes que solucionan un problema determinado. considera todos los paquetes que se encuentran en un aviso de actualización como paquetes de seguridad Patch Manager. A los paquetes individuales no se les asignan clasificaciones ni niveles de gravedad. Por este motivo, Patch Manager asigna los atributos de un aviso de actualización a los paquetes relacionados.
**nota**
Si selecciona la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** en la página **Crear una línea de base de revisiones**, los paquetes que no estén clasificados en un archivo `updateinfo.xml` (o un paquete que contenga un archivo sin los valores de Clasificación, Gravedad y Fecha con el formato correcto) se podrán incluir en la lista de revisiones filtrada con anterioridad. Sin embargo, para poder aplicar un parche, este debe seguir cumpliendo las reglas de base de referencia de parches especificadas por el usuario.
Para obtener más información sobre la opción **Incluir actualizaciones no relacionadas con la seguridad**, consulte [Cómo se instalan los parches](patch-manager-installing-patches.md) y [Funcionamiento de las reglas de bases de referencia de parches en los sistemas basados en Linux](patch-manager-linux-rules.md).
------
#### [ CentOS Stream ]
En CentOS Stream, el servicio de base de referencia de revisiones de Systems Manager utiliza repositorios (repos) preconfigurados en el nodo administrado. En la siguiente lista, se muestran ejemplos para una Amazon Machine Image (AMI) de CentOS 9.2 ficticia:
+ **ID del repositorio**: `example-centos-9.2-base`
**Nombre del repositorio**: `Example CentOS-9.2 - Base`
+ **ID del repositorio**: `example-centos-9.2-extras`
**Nombre del repositorio**: `Example CentOS-9.2 - Extras`
+ **ID del repositorio**: `example-centos-9.2-updates`
**Nombre del repositorio**: `Example CentOS-9.2 - Updates`
+ **ID del repositorio**: `example-centos-9.x-examplerepo`
**Nombre del repositorio**: `Example CentOS-9.x – Example Repo Packages`
**nota**
Todas las actualizaciones se descargan desde los repositorios remotos configurados en el nodo administrado. Por lo tanto, el nodo debe tener acceso saliente a Internet para conectarse a los repositorios y que puedan implementarse las revisiones.
Los nodos de CentOS Stream utilizan DNF como administrador de paquetes. El administrador de paquetes utiliza el concepto de un aviso de actualización. Un aviso de actualización es simplemente una colección de paquetes que solucionan un problema determinado.
Sin embargo, los repositorios predeterminados de CentOS Stream no se configuran con un aviso de actualización. Esto significa que Patch Manager no detecta paquetes en repositorios de CentOS Stream predeterminados. Para permitir que Patch Manager procese paquetes no incluidos en avisos de actualización, debe activar la marca `EnableNonSecurity` en las reglas de base de referencia de los parches.
**nota**
Los avisos de actualización de CentOS Stream son compatibles. Los repositorios con avisos de actualización se pueden descargar tras el lanzamiento.
------
#### [ Servidor Debian ]
En Debian Server, el servicio de base de referencia de parches de Systems Manager utiliza repositorios (repos) preconfigurados en la instancia. Estos repositorios preconfigurados se utilizan para obtener una lista actualizada de actualizaciones de paquetes disponibles. Por este motivo, Systems Manager realiza el equivalente a un comando `sudo apt-get update`.
A continuación, los paquetes se filtran desde los repositorios `debian-security codename`. Esto significa que en cada versión de Debian Server, Patch Manager solo identifica las actualizaciones que son parte del repositorio asociado para esta versión, como se muestra a continuación:
+ Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`
------
#### [ Oracle Linux ]
En Oracle Linux, el servicio de base de referencia de revisiones de Systems Manager utiliza repositorios (repos) preconfigurados en el nodo administrado. Normalmente, hay dos repositorios preconfigurados en un nodo.
**Oracle Linux 7**:
+ **ID del repositorio**: `ol7_UEKR5/x86_64`
**Nombre del repositorio**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **ID del repositorio**: `ol7_latest/x86_64`
**Nombre del repositorio**: `Oracle Linux 7Server Latest (x86_64)`
**Oracle Linux 8**:
+ **ID del repositorio**: `ol8_baseos_latest`
**Nombre del repositorio**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **ID del repositorio**: `ol8_appstream`
**Nombre del repositorio**: `Oracle Linux 8 Application Stream (x86_64)`
+ **ID del repositorio**: `ol8_UEKR6`
**Nombre del repositorio**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`
**Oracle Linux 9**:
+ **ID del repositorio**: `ol9_baseos_latest`
**Nombre del repositorio**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **ID del repositorio**: `ol9_appstream`
**Nombre del repositorio**: `Oracle Linux 9 Application Stream Packages(x86_64)`
+ **ID del repositorio**: `ol9_UEKR7`
**Nombre del repositorio**: `Oracle Linux UEK Release 7 (x86_64)`
**nota**
Todas las actualizaciones se descargan desde los repositorios remotos configurados en el nodo administrado. Por lo tanto, el nodo debe tener acceso saliente a Internet para conectarse a los repositorios y que puedan implementarse las revisiones.
Oracle Linux Los nodos administrados de utilizan Yum como administrador de paquetes y Yum utiliza el concepto de aviso de actualización como un archivo denominado `updateinfo.xml`. Un aviso de actualización es simplemente una colección de paquetes que solucionan un problema determinado. A los paquetes individuales no se les asignan clasificaciones ni niveles de gravedad. Por este motivo, Patch Manager asigna los atributos de un aviso de actualización a los paquetes relacionados e instala los paquetes en función de los filtros de clasificación especificados en la base de referencia de parches.
**nota**
Si selecciona la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** en la página **Crear una línea de base de revisiones**, los paquetes que no estén clasificados en un archivo `updateinfo.xml` (o un paquete que contenga un archivo sin los valores de Clasificación, Gravedad y Fecha con el formato correcto) se podrán incluir en la lista de revisiones filtrada con anterioridad. Sin embargo, para poder aplicar un parche, este debe seguir cumpliendo las reglas de base de referencia de parches especificadas por el usuario.
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
En AlmaLinux, Red Hat Enterprise Linux y Rocky Linux, el servicio de línea de base de revisiones de Systems Manager utiliza repositorios (repos) preconfigurados en el nodo administrado. Normalmente, hay tres repositorios preconfigurados en un nodo.
Todas las actualizaciones se descargan desde los repositorios remotos configurados en el nodo administrado. Por lo tanto, el nodo debe tener acceso saliente a Internet para conectarse a los repositorios y que puedan implementarse las revisiones.
**nota**
Si selecciona la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** en la página **Crear una línea de base de revisiones**, los paquetes que no estén clasificados en un archivo `updateinfo.xml` (o un paquete que contenga un archivo sin los valores de Clasificación, Gravedad y Fecha con el formato correcto) se podrán incluir en la lista de revisiones filtrada con anterioridad. Sin embargo, para poder aplicar un parche, este debe seguir cumpliendo las reglas de base de referencia de parches especificadas por el usuario.
Los nodos administrados de Red Hat Enterprise Linux 7 utilizan YUM como administrador de paquetes. Los nodos administrados de AlmaLinux, Red Hat Enterprise Linux 8 y Rocky Linux utilizan DNF como gestor de paquetes. Ambos administradores de paquetes utilizan el concepto de un aviso de actualización como un archivo llamado `updateinfo.xml`. Un aviso de actualización es simplemente una colección de paquetes que solucionan un problema determinado. A los paquetes individuales no se les asignan clasificaciones ni niveles de gravedad. Por este motivo, Patch Manager asigna los atributos de un aviso de actualización a los paquetes relacionados e instala los paquetes en función de los filtros de clasificación especificados en la base de referencia de parches.
RHEL 7
Los siguientes ID de repositorio están asociados con RHUI 2. RHUI 3 se lanzó en diciembre de 2019 y supuso la introducción de un esquema de nomenclatura diferente para los ID de repositorio de Yum. En función de la AMI RHEL-7 desde la que cree los nodos administrados, es posible que tenga que actualizar los comandos. Para obtener más información, consulte [Repository IDs for RHEL 7 in AWS Have Changed](https://access.redhat.com/articles/4599971) en el *Portal del cliente de Red Hat*.
+ **ID del repositorio**: `rhui-REGION-client-config-server-7/x86_64`
**Nombre del repositorio**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **ID del repositorio**: `rhui-REGION-rhel-server-releases/7Server/x86_64`
**Nombre del repositorio**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **ID del repositorio**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`
**Nombre del repositorio**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`
AlmaLinux 8, RHEL 8 y Rocky Linux 8
+ **ID del repositorio**: `rhel-8-appstream-rhui-rpms`
**Nombre del repositorio**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **ID del repositorio**: `rhel-8-baseos-rhui-rpms`
**Nombre del repositorio**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **ID del repositorio**: `rhui-client-config-server-8`
**Nombre del repositorio**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`
AlmaLinux 9, RHEL 9 y Rocky Linux 9
+ **ID del repositorio**: `rhel-9-appstream-rhui-rpms`
**Nombre del repositorio**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **ID del repositorio**: `rhel-9-baseos-rhui-rpms`
**Nombre del repositorio**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **ID del repositorio**: `rhui-client-config-server-9`
**Nombre del repositorio**: `Red Hat Enterprise Linux 9 Client Configuration`
------
#### [ SLES ]
En los nodos administrados de SUSE Linux Enterprise Server (SLES), la biblioteca ZYPP obtiene la lista de revisiones disponibles (una colección de paquetes) de las siguientes ubicaciones:
+ Lista de repositorios: `etc/zypp/repos.d/*`
+ Información de paquetes: `/var/cache/zypp/raw/*`
SLESLos nodos administrados de utilizan Zypper como administrador de paquetes, y Zypper utiliza el concepto de revisión. Un parche es una simple colección de paquetes que corrigen un problema concreto. Patch Manager se ocupa de todos los paquetes que se referencian en un parche como relacionados con la seguridad. Dado que a los paquetes individuales no se les asignan clasificaciones ni gravedad, Patch Manager les asigna los atributos del parche al que pertenecen.
------
#### [ Servidor Ubuntu ]
En Ubuntu Server, el servicio de base de referencia de revisiones de Systems Manager utiliza repositorios (repos) preconfigurados en el nodo administrado. Estos repositorios preconfigurados se utilizan para obtener una lista actualizada de actualizaciones de paquetes disponibles. Por este motivo, Systems Manager realiza el equivalente a un comando `sudo apt-get update`.
A continuación, los paquetes se filtran desde los repositorios `codename-security`, cuyo nombre de código es único para la versión de lanzamiento, como `trusty` para Ubuntu Server 14. Patch Manager identifica únicamente las actualizaciones que forman parte de estos repositorios:
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS (`jammy-security`)
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)
------
#### [ Windows Server ]
En los sistemas operativos Microsoft Windows, Patch Manager recupera una lista de las actualizaciones disponibles que Microsoft publica a través de los servicios de Microsoft Update y que están disponibles de manera automática para Windows Server Update Services (WSUS).
**nota**
Patch Manager solo pone a disposición parches para versiones del sistema operativo Windows Server que son compatibles con Patch Manager. Por ejemplo, Patch Manager no se puede utilizar para aplicar parches a Windows RT.
Patch Manager monitorea continuamente las nuevas actualizaciones en cada Región de AWS. La lista de las actualizaciones de Windows disponibles se actualiza en cada región al menos una vez al día. Cuando la información sobre parches de Microsoft se procesa, Patch Manager elimina las actualizaciones que se han sustituido por actualizaciones posteriores de su lista de parches. Por lo tanto, solo se muestra la última actualización y, en su caso, están disponibles para su instalación. Por ejemplo, si `KB4012214` sustituye a `KB3135456`, solo `KB4012214` estará disponible como una actualización en Patch Manager.
Del mismo modo, solo Patch Manager puede instalar las revisiones que estén disponibles en el nodo gestionado durante la operación de aplicación de revisiones. De forma predeterminada, en Windows Server 2019 y Windows Server 2022 se eliminan las actualizaciones que se sustituyen por actualizaciones posteriores. Como resultado, si utiliza el parámetro `ApproveUntilDate` en la línea de base de revisiones Windows Server, pero la fecha seleccionada en el parámetro `ApproveUntilDate` es *anterior* a la fecha del último parche, se produce la siguiente situación:
+ La revisión sustituida se elimina del nodo y, por lo tanto, no se puede instalar con Patch Manager.
+ La última revisión de reemplazo está presente en el nodo, pero aún no se ha aprobado su instalación en la fecha especificada por el parámetro `ApproveUntilDate`.
Esto significa que el nodo gestionado es compatible con las operaciones de Systems Manager, aunque es posible que no se haya instalado una revisión crítica del mes anterior. Esta misma situación puede ocurrir cuando se utiliza el parámetro `ApproveAfterDays`. Debido al comportamiento de las revisiones sustituidas por Microsoft, es posible establecer un número (generalmente superior a 30 días) para que las revisiones para Windows Server no se instalen nunca si la última revisión disponible de Microsoft se publica antes de que hayan transcurrido los días en `ApproveAfterDays`. Tenga en cuenta que este comportamiento del sistema no se aplica si ha modificado la configuración con objetos de políticas globales (GPO) de Windows para que la versión sustituida esté disponible en los nodos administrados.
**nota**
En algunos casos, Microsoft lanza parches para las aplicaciones que no especifican una hora ni una fecha de actualización. En estos casos, se suministra una fecha y hora actualizadas de `01/01/1970` de forma predeterminada.
------
# Cómo especificar un repositorio de origen de parches alternativo (Linux)
Cuando se utilizan los repositorios predeterminados configurados en un nodo administrado para operaciones de aplicación de revisiones, Patch Manager, una herramienta de AWS Systems Manager, busca o instala las revisiones relacionadas con la seguridad. Este es el comportamiento predeterminado de Patch Manager. Para obtener información completa acerca de cómo Patch Manager selecciona e instala los parches de seguridad, consulte [Cómo se seleccionan los parches de seguridad](patch-manager-selecting-patches.md).
Sin embargo, en los sistemas Linux, también puede utilizar Patch Manager para instalar revisiones que no estén relacionadas con la seguridad o que se encuentren en un repositorio de origen diferente del configurado de forma predeterminada en el nodo administrado. Puede especificar repositorios de origen de parches alternativos al crear una base de referencia de parches personalizada. En cada base de referencia de parches personalizada, es posible especificar configuraciones de origen de parches para un máximo de 20 versiones de un sistema operativo Linux compatible.
Por ejemplo, supongamos que su flota de Ubuntu Server incluye los nodos administrados de Ubuntu Server 25.04. En este caso, puede especificar repositorios alternativos para cada versión en la misma base de referencia de parches personalizada. Para cada versión, es necesario proporcionar un nombre y especificar el tipo de versión del sistema operativo (producto), así como proporcionar una configuración de repositorio. También es posible especificar un único repositorio de origen alternativo que se aplique a todas las versiones de un sistema operativo compatible.
**nota**
La ejecución de una base de referencia de revisiones personalizada que especifica repositorios de revisiones alternativos para un nodo administrado no los convierte en los nuevos repositorios predeterminados del sistema operativo. Una vez completada la operación de aplicación de revisiones, los repositorios previamente configurados como valores predeterminados del sistema operativo del nodo siguen siendo los predeterminados.
Para obtener una lista de escenarios de ejemplo del uso de esta opción, consulte [Ejemplos de uso de repositorios de origen de parches alternativos](#patch-manager-alternative-source-repository-examples) más adelante en este tema.
Para obtener más información sobre las bases de referencia de parches predeterminadas y personalizadas, consulte [Líneas de base de revisiones personalizadas y predefinidas](patch-manager-predefined-and-custom-patch-baselines.md).
**Ejemplo: uso de la consola**
Para especificar repositorios de origen de parches alternativos al trabajar en la consola de Systems Manager, utilice la sección **Patch sources** (Orígenes de parches) de la página **Create patch baseline** (Crear una base de referencia de parches). Para obtener información sobre el uso de las opciones de **Orígenes de parches**, consulte [Creación de una línea de base de revisiones personalizada para Linux](patch-manager-create-a-patch-baseline-for-linux.md).
**Ejemplos: uso de la AWS CLI**
Para ver un ejemplo de cómo usar la opción `--sources` con la AWS Command Line Interface (AWS CLI), consulte [Creación de una base de referencia de parches con repositorios personalizados para distintas versiones del sistema operativo](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources).
**Topics**
+ [Consideraciones importantes para repositorios alternativos](#alt-source-repository-important)
+ [Ejemplos de uso de repositorios de origen de parches alternativos](#patch-manager-alternative-source-repository-examples)
## Consideraciones importantes para repositorios alternativos
Tenga en cuenta los siguientes puntos a la hora de planificar su estrategia de aplicación de parches con repositorios de parches alternativos.
**Aplicar verificaciones de actualización de repositorios (YUM y DNF)**
La configuración predeterminada de un administrador de paquetes en una distribución de Linux podría estar configurada para omitir un repositorio de paquetes inalcanzable sin errores si no puede establecerse la conexión con el repositorio. Para hacer cumplir las actualizaciones del repositorio, agregue `skip_if_unavailable=False` a la configuración del repositorio.
Para obtener más información acerca de la opción `skip_if_available`, consulte [Conectividad con la fuente de revisiones](patch-manager-prerequisites.md#source-connectivity).
**Solo se utilizan los repositorios especificados para la aplicación de parches**
Especificar repositorios alternativos no significa especificar repositorios *adicionales*. Puede elegir especificar repositorios distintos de los configurados como valores predeterminados en un nodo administrado. Sin embargo, también debe especificar los repositorios predeterminados como parte de la configuración de origen de parches alternativos si desea que sus actualizaciones se apliquen.
Por ejemplo, en los nodos administrados de Amazon Linux 2, los repositorios predeterminados son `amzn2-core` y `amzn2extra-docker`. Si desea incluir el repositorio Extra Packages for Enterprise Linux (EPEL) en sus operaciones de aplicación de parches, debe especificar los tres repositorios como repositorios alternativos.
**nota**
La ejecución de una base de referencia de revisiones personalizada que especifica repositorios de revisiones alternativos para un nodo administrado no los convierte en los nuevos repositorios predeterminados del sistema operativo. Una vez completada la operación de aplicación de revisiones, los repositorios previamente configurados como valores predeterminados del sistema operativo del nodo siguen siendo los predeterminados.
**El comportamiento de aplicación de parches para las distribuciones basadas en YUM depende del manifiesto updateinfo.xml.**
Al especificar repositorios de revisión alternativos para las distribuciones basadas en YUM, como Amazon Linux 2 o Red Hat Enterprise Linux, el comportamiento de las revisiones depende de si el repositorio incluye un manifiesto de actualización en forma de un archivo `updateinfo.xml` con formato completo y correcto. Este archivo especifica la fecha de lanzamiento, clasificaciones y gravedad de los distintos paquetes. Cualquiera de los siguientes afectarán al comportamiento de aplicación de parches:
+ Si filtra por **Classification** (Clasificación) y **Severity** (Gravedad), pero no están especificados en `updateinfo.xml`, el paquete no se incluirá el filtro. Esto también significa que los paquetes sin un archivo `updateinfo.xml` no se incluyen en la aplicación de parches.
+ Si filtra por **ApprovalAfterDays**, pero la fecha de lanzamiento del paquete no está en formato de fecha de inicio Unix (o no tiene fecha de lanzamiento especificada), el paquete no se incluirá en el filtro.
+ Existe una excepción cuando selecciona la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** en la página **Crear línea de base de revisiones**. En este caso, los paquetes sin un archivo `updateinfo.xml` (o que contengan este archivo sin valores de **Clasificación**, **Gravedad** y **Fecha** con el formato adecuado) *se incluirán* en la lista de revisiones previamente filtrada. (Deben seguir cumpliendo los otros requisitos de reglas de base de referencia de los parches para instalarse).
## Ejemplos de uso de repositorios de origen de parches alternativos
**Ejemplo 1: actualizaciones que no son de seguridad para Ubuntu Server**
Ya está utilizando Patch Manager para instalar revisiones de seguridad en una flota de nodos administrados de Ubuntu Server mediante la base de referencia de revisiones predefinida proporcionada por AWS, `AWS-UbuntuDefaultPatchBaseline`. Puede crear una nueva base de referencia de parches basada en esta base predeterminada, pero especifica en las reglas de aprobación que también desea instalar las actualizaciones que no son de seguridad y que forman parte de la distribución predeterminada. Cuando esta base de referencia de revisiones se ejecuta en los nodos, se aplican tanto las revisiones de seguridad como las que no lo son. También puede elegir aprobar los parches que no son de seguridad en las excepciones de parches especificadas para una base de referencia.
**Ejemplo 2: Personal Package Archives (PPA) para Personal Package Archives Ubuntu Server**
Los nodos administrados de Ubuntu Server ejecutan software que se distribuye a través de [Personal Package Archives (PPA) para Ubuntu](https://launchpad.net/ubuntu/+ppas). En este caso, debe crear una base de referencia de revisiones que especifica un repositorio de PPA que ha configurado en el nodo administrado como repositorio de origen para la operación de aplicación de revisiones. A continuación, utilice Run Command para ejecutar el documento de base de referencia de revisiones en los nodos.
**Ejemplo 3: aplicaciones corporativas internas en versiones de Amazon Linux compatibles**
Necesita ejecutar algunas aplicaciones necesarias para el cumplimiento normativo del sector en los nodos administrados de Amazon Linux. Puede configurar un repositorio para estas aplicaciones en los nodos, utilizar YUM para instalar inicialmente las aplicaciones y, a continuación, actualizar o crear una nueva base de referencia de revisiones para incluir este nuevo repositorio corporativo. Una vez hecho esto, puede utilizar Run Command para ejecutar el documento `AWS-RunPatchBaseline` con la opción `Scan` para comprobar si el paquete corporativo aparece entre los paquetes instalados y está actualizado en el nodo administrado. Si no está actualizado, puede ejecutar el documento de nuevo con la opción `Install` para actualizar las aplicaciones.
# Cómo se instalan los parches
Patch Manager, una herramienta de AWS Systems Manager, utiliza el administrador de paquetes integrado en el sistema operativo para instalar actualizaciones en los nodos administrados. Por ejemplo, utiliza la API de Windows Update en Windows Server y `DNF` en Amazon Linux 2023. Patch Manager respeta las configuraciones de los repositorios y administradores de paquetes existentes en los nodos, e incluye ajustes como el estado del repositorio, las URL duplicadas, la verificación de GPG y opciones como `skip_if_unavailable`.
Patch Manager no instala un paquete nuevo que sustituya a un paquete obsoleto que esté instalado actualmente. (Excepciones: el paquete nuevo es una dependencia de otro paquete que se está actualizando o el paquete nuevo tiene el mismo nombre que el paquete obsoleto). En su lugar, Patch Manager informa sobre las actualizaciones disponibles para los paquetes instalados y las instala. Este enfoque ayuda a evitar cambios inesperados en la funcionalidad del sistema que pueden producirse cuando un paquete reemplaza a otro.
Si necesita desinstalar un paquete que ha quedado obsoleto e instalar un paquete que lo sustituya, puede que necesite utilizar un script personalizado o utilizar comandos del administrador de paquetes fuera de las operaciones estándar del Patch Manager.
Elija entre las siguientes pestañas para obtener información acerca de cómo Patch Manager instala parches en un sistema operativo.
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
En los nodos administrados de Amazon Linux 2 y Amazon Linux 2023, el flujo de trabajo de instalación de revisiones es el siguiente:
1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.
Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.
1. Si hay varias versiones de un parche aprobadas, se aplica la última.
1. La API de actualización de YUM (Amazon Linux, 2) o la API de actualización de DNF (Amazon Linux 2023) se aplica a las revisiones aprobadas de la siguiente manera:
+ Para las líneas de base de revisiones predeterminadas y proporcionadas por AWS, solo se aplican las revisiones especificadas en `updateinfo.xml` (solo actualizaciones de seguridad). Esto se debe a que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** no está seleccionada. Las líneas de base predefinidas equivalen a una línea de base personalizada con lo siguiente:
+ La casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** no está seleccionada
+ Una lista de GRAVEDAD de `[Critical, Important]`
+ Una lista de CLASIFICACIÓN de `[Security, Bugfix]`
En Amazon Linux 2, el comando yum equivalente para este flujo de trabajo es el siguiente:
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
En Amazon Linux 2023, el comando dnf equivalente para este flujo de trabajo es el siguiente:
```
sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
```
Si la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** está seleccionada, se aplican las revisiones que están en `updateinfo.xml` y no las que están en `updateinfo.xml` (actualizaciones de seguridad y no relacionadas con la seguridad).
En Amazon Linux 2, si se selecciona una línea de base con **Incluir actualizaciones no relacionadas con la seguridad** y tiene una lista de gravedad de `[Critical, Important]` y una lista de clasificación de `[Security, Bugfix]`, el comando yum equivalente es el siguiente:
```
sudo yum update --security --sec-severity=Critical,Important --bugfix -y
```
En Amazon Linux 2023, el comando dnf equivalente es el siguiente:
```
sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
```
**nota**
Los paquetes nuevos que sustituyen a los ya obsoletos con nombres diferentes se instalan si ejecuta estos comandos `yum` o `dnf` fuera del Patch Manager. Sin embargo, *no* se instalan mediante las operaciones equivalentes del Patch Manager.
**Detalles adicionales sobre los parches para Amazon Linux 2023**
Asistencia para el nivel de gravedad “None”
Amazon Linux 2023 también admite el nivel de gravedad de revisiones `None`, el cual reconoce el administrador de paquetes DNF.
Asistencia para el nivel de gravedad “Medium”
Para Amazon Linux 2023, un nivel de gravedad de revisiones `Medium` equivale a un nivel de gravedad `Moderate` que podría definirse en algunos repositorios externos. Si incluye `Medium` revisiones de gravedad en la línea de base de revisiones, también se instalarán en las instancias `Moderate` revisiones de gravedad de revisiones externas.
Cuando consulta los datos de cumplimiento mediante la acción [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) de la API, el filtrado para el nivel de gravedad `Medium` informa revisiones con niveles de gravedad tanto `Medium` como `Moderate`.
Manejo transitivo de dependencias para Amazon Linux 2023
En el caso de Amazon Linux 2023, Patch Manager puede instalar versiones de dependencias transitivas distintas a las que instalan los comandos de `dnf` equivalentes. Las dependencias transitivas son paquetes que se instalan automáticamente para satisfacer los requisitos de otros paquetes (dependencias de dependencias).
Por ejemplo, `dnf upgrade-minimal --security` instala las versiones *mínimas* de las dependencias transitivas necesarias para resolver los problemas de seguridad conocidos, mientras que Patch Manager instala las **últimas versiones disponibles de las mismas dependencias transitivas.
1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
**nota**
La configuración predeterminada de un administrador de paquetes en una distribución de Linux podría estar configurada para omitir un repositorio de paquetes inalcanzable sin errores. En esos casos, la operación de aplicación de revisiones correspondiente se lleva a cabo sin instalar las actualizaciones del repositorio y finaliza de manera satisfactoria. Para hacer cumplir las actualizaciones del repositorio, agregue `skip_if_unavailable=False` a la configuración del repositorio.
Para obtener más información acerca de la opción `skip_if_available`, consulte [Conectividad con la fuente de revisiones](patch-manager-prerequisites.md#source-connectivity).
------
#### [ CentOS Stream ]
En los nodos administrados CentOS Stream, el flujo de trabajo de instalación de revisiones es el siguiente:
1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.
Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.
Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.
1. Si hay varias versiones de un parche aprobadas, se aplica la última.
1. La actualización de DNF en CentOS Stream se aplica a las revisiones aprobadas.
**nota**
En el caso de CentOS Stream, Patch Manager podría instalar versiones de dependencias transitivas diferentes a las que instalan los comandos equivalentes de `dnf`. Las dependencias transitivas son paquetes que se instalan automáticamente para satisfacer los requisitos de otros paquetes (dependencias de dependencias).
Por ejemplo, `dnf upgrade-minimal ‐‐security` instala las versiones *mínimas* de las dependencias transitivas necesarias para resolver los problemas de seguridad conocidos, mientras que Patch Manager instala las *últimas* versiones disponibles de las mismas dependencias transitivas.
1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
------
#### [ Servidor Debian ]
En las instancias de Debian Server, el flujo de trabajo de instalación de parches es el siguiente:
1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.
1. Si está disponible una actualización para `python3-apt` (una interfaz de biblioteca de Python para `libapt`), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción **Include nonsecurity updates** [Incluir actualizaciones no relacionadas con la seguridad]).
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.
**nota**
Como no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Debian Server, las opciones de aprobación automática no son compatibles con este sistema operativo.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.
Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
**nota**
En Debian Server, las versiones candidatas a revisiones se limitan a las revisiones incluidas en `debian-security`.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.
1. La biblioteca de APT se utiliza para actualizar paquetes.
**nota**
Patch Manager no admite el uso de la opción `Pin-Priority` de APT para asignar prioridades a los paquetes. Patch Manager agrega las actualizaciones disponibles de todos los repositorios habilitados y selecciona la actualización más reciente que coincide con la línea de base de cada paquete instalado.
1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
------
#### [ macOS ]
En los nodos administrados macOS, el flujo de trabajo de instalación de revisiones es el siguiente:
1. La lista de propiedades `/Library/Receipts/InstallHistory.plist` es un registro de software que se ha instalado y actualizado mediante los administradores de paquetes `softwareupdate` y `installer`. Mediante la herramienta de línea de comandos `pkgutil` (para `installer`) y el administrador de paquetes `softwareupdate`, se ejecutan comandos de la CLI para analizar esta lista.
Para `installer`, la respuesta a los comandos de la CLI incluye detalles de `package name`, `version`, `volume`, `location` y `install-time`, pero Patch Manager solo utiliza `package name` y `version`.
Para `softwareupdate`, la respuesta a los comandos de la CLI incluye el nombre del paquete (`display name`), `version` y `date`, pero Patch Manager utiliza únicamente el nombre del paquete y la versión.
Para Brew y Brew Cask, Homebrew no admite que sus comandos se ejecuten con el usuario raíz. Como resultado, Patch Manager consulta y ejecuta los comandos de Homebrew como propietario del directorio de Homebrew o como usuario válido perteneciente al grupo de propietarios de ese directorio. Los comandos se asemejan a `softwareupdate` y `installer`, y se ejecutan a través de un subproceso de Python para recopilar los datos de los paquetes, y el resultado se analiza con el objetivo de identificar los nombres y las versiones de los paquetes.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.
1. Si hay varias versiones de un parche aprobadas, se aplica la última.
1. Invoque la CLI del paquete correspondiente en el nodo administrado para procesar las revisiones aprobadas de la siguiente manera:
**nota**
`installer` carece de la funcionalidad para buscar e instalar actualizaciones. Por lo tanto, para `installer`, Patch Manager solo notifica qué paquetes están instalados. Como resultado, los paquetes `installer` nunca se notifican como `Missing`.
+ Para las líneas de base de revisiones predeterminadas proporcionadas por AWS y las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *no* está seleccionada, solo se aplican las actualizaciones de seguridad.
+ Para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *sí* está seleccionada, se aplican tanto las actualizaciones de seguridad como las que no están relacionadas con la seguridad.
1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
------
#### [ Oracle Linux ]
En los nodos administrados Oracle Linux, el flujo de trabajo de instalación de revisiones es el siguiente:
1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.
Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.
1. Si hay varias versiones de un parche aprobadas, se aplica la última.
1. En los nodos administrados de la versión 7, la API de actualización de YUM se aplica a las revisiones aprobadas como se indica a continuación:
+ Para las líneas de base de revisiones proporcionadas por AWS y para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *no* está seleccionada, solo se aplican las revisiones especificadas en `updateinfo.xml` (solo actualizaciones de seguridad).
El comando yum equivalente para este flujo de trabajo es:
```
sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
```
+ Para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *sí* está seleccionada, se aplican las revisiones que están en `updateinfo.xml` y las que no están en `updateinfo.xml` (actualizaciones de seguridad y no relacionadas con la seguridad).
El comando yum equivalente para este flujo de trabajo es:
```
sudo yum update --security --bugfix -y
```
En los nodos administrados de las versiones 8 y 9, la API de actualización de DNF se aplica a las revisiones aprobadas como se indica a continuación:
+ Para las líneas de base de revisiones proporcionadas por AWS y para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *no* está seleccionada, solo se aplican las revisiones especificadas en `updateinfo.xml` (solo actualizaciones de seguridad).
El comando yum equivalente para este flujo de trabajo es:
```
sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
```
**nota**
En el caso de Oracle Linux, Patch Manager puede instalar versiones de dependencias transitivas distintas a las que instalan los comandos de `dnf` equivalentes. Las dependencias transitivas son paquetes que se instalan automáticamente para satisfacer los requisitos de otros paquetes (dependencias de dependencias).
Por ejemplo, `dnf upgrade-minimal --security` instala las versiones *mínimas* de las dependencias transitivas necesarias para resolver los problemas de seguridad conocidos, mientras que Patch Manager instala las *últimas* versiones disponibles de las mismas dependencias transitivas.
+ Para las líneas de base de revisiones personalizadas en las que la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** *sí* está seleccionada, se aplican las revisiones que están en `updateinfo.xml` y las que no están en `updateinfo.xml` (actualizaciones de seguridad y no relacionadas con la seguridad).
El comando yum equivalente para este flujo de trabajo es:
```
sudo dnf upgrade --security --bugfix
```
**nota**
Los paquetes nuevos que sustituyen a los ya obsoletos con nombres diferentes se instalan si ejecuta estos comandos `yum` o `dnf` fuera del Patch Manager. Sin embargo, *no* se instalan mediante las operaciones equivalentes del Patch Manager.
1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
**nota**
La configuración predeterminada de un administrador de paquetes en una distribución de Linux podría estar configurada para omitir un repositorio de paquetes inalcanzable sin errores. En esos casos, la operación de aplicación de revisiones correspondiente se lleva a cabo sin instalar las actualizaciones del repositorio y finaliza de manera satisfactoria. Para hacer cumplir las actualizaciones del repositorio, agregue `skip_if_unavailable=False` a la configuración del repositorio.
Para obtener más información acerca de la opción `skip_if_available`, consulte [Conectividad con la fuente de revisiones](patch-manager-prerequisites.md#source-connectivity).
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
En los nodos administrados de AlmaLinux, Red Hat Enterprise Linux y Rocky Linux, el flujo de trabajo de instalación de revisión es el siguiente:
1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.
Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.
1. Si hay varias versiones de un parche aprobadas, se aplica la última.
1. La API de actualización de YUM (en RHEL 7) o la API de actualización de DNF (en AlmaLinux 8 y 9, RHEL 8, 9 y 10, y Rocky Linux 8 y 9) se aplica a las revisiones aprobadas de acuerdo con las siguientes reglas:
**Situación 1: se excluyen las actualizaciones no relacionadas con la seguridad**
+ **Se aplica a**: líneas de base de revisiones predeterminadas y predefinidas proporcionadas por AWS y líneas de base de revisiones personalizadas.
+ Casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad**: *no* está seleccionada.
+ **Revisiones aplicadas**: las revisiones especificadas en `updateinfo.xml` (solo actualizaciones de seguridad) se aplican *únicamente* si coinciden con la configuración de la línea de base de revisiones y se encuentran en los repositorios configurados.
En algunos casos, es posible que una revisión especificada en `updateinfo.xml` ya no esté disponible en un repositorio configurado. Los repositorios configurados suelen tener solo la última versión de una revisión, que es una recopilación acumulativa de todas las actualizaciones anteriores, pero es posible que la última versión no cumpla con las reglas de la línea de base de revisiones y se omita en la operación de aplicación de revisiones.
+ **Comandos**: en RHEL 7, el comando yum equivalente para este flujo de trabajo es:
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
En AlmaLinux, RHEL 8 y Rocky Linux, los comandos dnf equivalentes para este flujo de trabajo son los siguientes:
```
sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y
```
**nota**
En el caso de AlmaLinux, RHEL, y Rocky LinuxRocky Linux, es posible que Patch Manager instale versiones de dependencias transitivas distintas a las que instalan los comandos de `dnf` equivalentes. Las dependencias transitivas son paquetes que se instalan automáticamente para satisfacer los requisitos de otros paquetes (dependencias de dependencias).
Por ejemplo, `dnf upgrade-minimal --security` instala las versiones *mínimas* de las dependencias transitivas necesarias para resolver los problemas de seguridad conocidos, mientras que Patch Manager instala las *últimas* versiones disponibles de las mismas dependencias transitivas.
**Situación 2: se incluyen actualizaciones no relacionadas con la seguridad**
+ **Se aplica a**: líneas de base de revisiones personalizadas.
+ Casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad**: está seleccionada.
+ **Revisiones aplicadas**: se aplican las revisiones incluidas en `updateinfo.xml` *y* las que no están en `updateinfo.xml` (actualizaciones de seguridad y no relacionadas con la seguridad).
+ **Comandos**: en RHEL 7, el comando yum equivalente para este flujo de trabajo es:
```
sudo yum update --security --bugfix -y
```
En AlmaLinux 8 y 9, RHEL 8 y 9 y Rocky Linux 8 y 9, el comando dnf equivalente para este flujo de trabajo es el siguiente:
```
sudo dnf update --security --bugfix -y
```
**nota**
Los paquetes nuevos que sustituyen a los ya obsoletos con nombres diferentes se instalan si ejecuta estos comandos `yum` o `dnf` fuera del Patch Manager. Sin embargo, *no* se instalan mediante las operaciones equivalentes del Patch Manager.
1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
**nota**
La configuración predeterminada de un administrador de paquetes en una distribución de Linux podría estar configurada para omitir un repositorio de paquetes inalcanzable sin errores. En esos casos, la operación de aplicación de revisiones correspondiente se lleva a cabo sin instalar las actualizaciones del repositorio y finaliza de manera satisfactoria. Para hacer cumplir las actualizaciones del repositorio, agregue `skip_if_unavailable=False` a la configuración del repositorio.
Para obtener más información acerca de la opción `skip_if_available`, consulte [Conectividad con la fuente de revisiones](patch-manager-prerequisites.md#source-connectivity).
------
#### [ SLES ]
En los nodos administrados de SUSE Linux Enterprise Server (SLES), el flujo de trabajo de instalación de revisiones es el siguiente:
1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.
Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.
1. Si hay varias versiones de un parche aprobadas, se aplica la última.
1. La API de actualización de Zypper se aplica a los parches aprobados.
1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
------
#### [ Servidor Ubuntu ]
En los nodos administrados Ubuntu Server, el flujo de trabajo de instalación de revisiones es el siguiente:
1. Si se especifica una lista de parches mediante una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) con el parámetro `InstallOverrideList` para los documentos `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`, se instalan los parches de la lista y se omiten los pasos comprendidos entre el 2 y el 7.
1. Si está disponible una actualización para `python3-apt` (una interfaz de biblioteca de Python para `libapt`), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción **Include nonsecurity updates** [Incluir actualizaciones no relacionadas con la seguridad]).
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) tal y como se especifica en la línea de base de revisiones, de modo que se mantendrán los paquetes cualificados para poder procesarse más adelante.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) tal y como se especifica en la línea de base de revisiones. Cada regla de aprobación puede definir un paquete como aprobado.
**nota**
Debido a que no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Ubuntu Server, las opciones de aprobación automática no son compatibles con este sistema operativo.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad.
Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
**nota**
Para cada versión de Ubuntu Server, las versiones candidatas a parches se limitan a los parches que forman parte del repositorio asociado a esa versión, como se muestra a continuación:
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS): `focal-security`
Ubuntu Server 22.04 LTS: `jammy-security`
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) tal y como se especifica en la línea de base de revisiones. Las revisiones aprobadas se aprueban para su actualización, incluso si se descartan por [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) o si ninguna regla de aprobación especificada en [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) les concede la aprobación.
1. Aplique [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) tal y como se especifica en la línea de base de revisiones. Los parches rechazados se eliminan de la lista de parches aprobados y no se aplicarán.
1. La biblioteca de APT se utiliza para actualizar paquetes.
**nota**
Patch Manager no admite el uso de la opción `Pin-Priority` de APT para asignar prioridades a los paquetes. Patch Manager agrega las actualizaciones disponibles de todos los repositorios habilitados y selecciona la actualización más reciente que coincide con la línea de base de cada paquete instalado.
1. El nodo administrado se reinicia si las actualizaciones se instalaron. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
------
#### [ Windows Server ]
Cuando se realiza una operación de aplicación de revisiones en un nodo administrado de Windows Server, este solicita una instantánea de la base de referencia de revisiones adecuada a Systems Manager. Esta instantánea contiene la lista de todas las actualizaciones disponibles en la base de referencia de parches que se aprobaron para su implementación. Esta lista de actualizaciones se envía a la API de Windows Update, que determina qué actualizaciones son aplicables al nodo administrado y se instala cuando sea necesario. Windows solo permite instalar la versión más reciente disponible de una KB. Patch Manager instala la última versión de una KB cuando esta, o cualquier versión anterior de la KB, coincide con la línea de base de revisiones aplicada. Si se instalan las actualizaciones, el nodo administrado se reinicia después, tantas veces como sea necesario para completar todas las revisiones necesarias. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)). El resumen de la operación de aplicación de parches se puede encontrar en la salida de la solicitud de Run Command. Puede encontrar más registros en el nodo administrado de la carpeta `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`.
Como la API de Windows Update se utiliza para descargar e instalar KB, se respetan todos los ajustes de la política de grupos de Windows Update. No se necesitan ajustes de la política de grupos para utilizar Patch Manager, pero se aplicará la configuración que haya definido, por ejemplo, dirigir nodos administrados a un servidor Windows Server Update Services (WSUS).
**nota**
De forma predeterminada, Windows descarga todos los KB del sitio de Windows Update de Microsoft porque Patch Manager utiliza la API de Windows Update para impulsar la descarga e instalar los parches. Como resultado, el nodo administrado debe poder acceder al sitio de Microsoft Windows Update; si no, la aplicación de revisiones no se realizará correctamente. De forma alternativa, puede configurar un servidor WSUS para que funcione como un repositorio de KB y configurar los nodos administrados para que se dirijan al servidor WSUS mediante las políticas de grupo.
Patch Manager puede hacer referencia a los ID de KB al crear líneas de base de revisiones personalizadas para Windows Server, por ejemplo, cuando se incluye una lista de **revisiones aprobadas** o una lista de **revisiones rechazadas** en la configuración de línea de base. Patch Manager solo instala las actualizaciones a las que se les asigna un ID de KB en Microsoft Windows Update o en un servidor WSUS. Las actualizaciones que carecen de un ID de KB no se incluyen en las operaciones de aplicación de revisiones.
Para obtener información sobre la creación de líneas de base de revisiones personalizadas, consulte los temas siguientes:
[Cómo crear una línea de base de revisiones personalizada para Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
[Creación de una línea de base de revisiones de revisiones (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Formatos de nombre de paquete para sistemas operativos Windows](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)
------
# Funcionamiento de las reglas de bases de referencia de parches en los sistemas basados en Linux
Las reglas de una base de referencia de parches para distribuciones de Linux funcionan de forma diferente en función del tipo de distribución. A diferencia de actualizaciones de revisiones en los nodos administrados de Windows Server, las reglas se evalúan en cada nodo para tener en cuenta los repositorios configurados en la instancia. Patch Manager, una herramienta de AWS Systems Manager, utiliza el administrador de paquetes nativo para impulsar la instalación de revisiones aprobadas por la línea de base de revisiones.
Para los tipos de sistemas operativos basados en Linux que informan de un nivel de gravedad de las revisiones, Patch Manager utiliza el nivel de gravedad notificado por el editor de software para el aviso de actualización o la revisión individual. Patch Manager no deriva los niveles de gravedad de orígenes de terceros, como el [Sistema de puntuación de vulnerabilidades comunes](https://www.first.org/cvss/) (CVSS), ni de métricas publicadas por la [Base de datos nacional de vulnerabilidades](https://nvd.nist.gov/vuln) (NVD).
**Topics**
+ [Funcionamiento de las reglas de línea de base de revisiones en Amazon Linux 2 y Amazon Linux 2023](#linux-rules-amazon-linux)
+ [Funcionamiento de las reglas de líneas de base de revisiones en CentOS Stream](#linux-rules-centos)
+ [Funcionamiento de las reglas de líneas de base de revisiones en Debian Server](#linux-rules-debian)
+ [Funcionamiento de las reglas de líneas de base de revisiones en macOS](#linux-rules-macos)
+ [Funcionamiento de las reglas de líneas de base de revisiones en Oracle Linux](#linux-rules-oracle)
+ [Funcionamiento de las reglas de líneas de base de revisiones en AlmaLinux, RHEL y Rocky Linux](#linux-rules-rhel)
+ [Funcionamiento de las reglas de líneas de base de revisiones en SUSE Linux Enterprise Server](#linux-rules-sles)
+ [Funcionamiento de las reglas de líneas de base de revisiones en Ubuntu Server](#linux-rules-ubuntu)
## Funcionamiento de las reglas de línea de base de revisiones en Amazon Linux 2 y Amazon Linux 2023
**nota**
Amazon Linux 2023 (AL2023) usa repositorios versionados que se pueden bloquear en una versión específica mediante una o más configuraciones del sistema. Para todas las operaciones de aplicación de parches en las instancias de EC2 de AL2023, Patch Manager usa las versiones más recientes del repositorio, independientemente de la configuración del sistema. Para obtener información, consulte [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) en la *Guía del usuario de Amazon Linux 2023*.
En Amazon Linux 2 y Amazon Linux 2023, el procedimiento de selección de revisiones es el siguiente:
1. En el nodo administrado, la biblioteca YUM (Amazon Linux 2) o la biblioteca DNF (Amazon Linux 2023) accede al archivo `updateinfo.xml` de cada repositorio configurado.
Si no encuentra el archivo `updateinfo.xml`, la instalación de las revisiones variará en función de la configuración de la opción **Incluir actualizaciones no relacionadas con la seguridad** y **Aprobación automática**. Por ejemplo, si se permiten las actualizaciones no relacionadas con la seguridad, se instalarán en el momento en que se realice la aprobación automática.
1. Cada aviso de actualización de `updateinfo.xml` incluye varios atributos que denota las propiedades de los paquetes del aviso, tal y como se describe en la siguiente tabla.
**Atributos de aviso de actualización**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
1. El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.
1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).
## Funcionamiento de las reglas de líneas de base de revisiones en CentOS Stream
Los repositorios predeterminados de CentOS Stream no incluyen un archivo `updateinfo.xml`. Sin embargo, los repositorios personalizados que se cree o se utilicen pueden incluir este archivo. En este tema, las referencias a `updateinfo.xml` se aplicarán únicamente a estos repositorios personalizados.
En las instancias de CentOS Stream, el proceso de selección de parches es el siguiente:
1. En el nodo administrado, la biblioteca DNF accede al archivo `updateinfo.xml`, si existe en un repositorio personalizado, correspondiente a cada uno de los repositorios configurados.
Si no encuentra el archivo `updateinfo.xml`, el cual incluye los repositorios predeterminados, la instalación de los parches variará según la configuración de la opción **Incluir actualizaciones no relacionadas con la seguridad** y **Aprobación automática**. Por ejemplo, si se permiten las actualizaciones no relacionadas con la seguridad, se instalarán en el momento en que se realice la aprobación automática.
1. Si `updateinfo.xml` está presente, cada aviso de actualización en el archivo incluye varios atributos que denota las propiedades de los paquetes del aviso, tal y como se describe en la siguiente tabla.
**Atributos de aviso de actualización**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
1. En todos los casos, el producto del nodo administrado se determina según el SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.
1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).
## Funcionamiento de las reglas de líneas de base de revisiones en Debian Server
En Debian Server, el servicio de línea de base de revisiones permite filtrar en los campos *Prioridad* y *Sección*. Estos campos suelen estar presentes para todos los paquetes de Debian Server. Para determinar si un parche se ha seleccionado mediante la base de referencia de parches, Patch Manager hace lo siguiente:
1. En sistemas Debian Server, el equivalente de `sudo apt-get update` es ejecutar para actualizar la lista de paquetes disponibles. Los repositorios no están configurados y los datos se obtienen de los repositorios configurados en una lista de `sources`.
1. Si está disponible una actualización para `python3-apt` (una interfaz de biblioteca de Python para `libapt`), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción **Include nonsecurity updates** [Incluir actualizaciones no relacionadas con la seguridad]).
1. Después, se aplican las listas de [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) y [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches).
**nota**
Como no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Debian Server, las opciones de aprobación automática no son compatibles con este sistema operativo.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. En este caso, en Debian Server, las versiones candidatas a revisiones se limitan a las revisiones incluidas en los siguientes repositorios:
Estos repositorios se denominan de la siguiente manera:
+ Debian Server 11: `debian-security bullseye`
+ Debian Server 12: `debian-security bookworm`
Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
Para obtener información acerca de los formatos aceptados para las listas de parches aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
Para ver el contenido de los campos *Priority* y *Section *, ejecute el siguiente comando `aptitude`:
**nota**
Es posible que necesite instalar por primera vez Aptitude en sistemas Debian Server.
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
En la respuesta a este comando, todos los paquetes actualizables se notifican en este formato:
```
name, priority, section, archive, candidate version
```
Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).
## Funcionamiento de las reglas de líneas de base de revisiones en macOS
En las instancias de macOS, el proceso de selección de parches es el siguiente:
1. En el nodo administrado, Patch Manager accede al contenido analizado del archivo `InstallHistory.plist` e identifica los nombres y las versiones de los paquetes.
Para obtener más detalles acerca del proceso de análisis, consulte la pestaña **macOS** en [Cómo se instalan los parches](patch-manager-installing-patches.md).
1. El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.
1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).
## Funcionamiento de las reglas de líneas de base de revisiones en Oracle Linux
En las instancias de Oracle Linux, el proceso de selección de parches es el siguiente:
1. En el nodo administrado, la biblioteca YUM accede al archivo `updateinfo.xml` de cada repositorio configurado.
**nota**
El archivo `updateinfo.xml` podría no estar disponible si Oracle no administra el repositorio. Si no encuentra el archivo `updateinfo.xml`, la instalación de las revisiones variará en función de la configuración de la opción **Incluir actualizaciones no relacionadas con la seguridad** y **Aprobación automática**. Por ejemplo, si se permiten las actualizaciones no relacionadas con la seguridad, se instalarán en el momento en que se realice la aprobación automática.
1. Cada aviso de actualización de `updateinfo.xml` incluye varios atributos que denota las propiedades de los paquetes del aviso, tal y como se describe en la siguiente tabla.
**Atributos de aviso de actualización**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
1. El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.
1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).
## Funcionamiento de las reglas de líneas de base de revisiones en AlmaLinux, RHEL y Rocky Linux
En AlmaLinux, Red Hat Enterprise Linux (RHEL) y Rocky Linux, el proceso de selección de revisiones es el siguiente:
1. En el nodo administrado, la biblioteca YUM (RHEL 7) o la biblioteca DNF (AlmaLinux 8 y 9, RHEL 8, 9 y 10, y Rocky Linux 8 y 9) accede al archivo `updateinfo.xml` de cada repositorio configurado.
**nota**
El archivo `updateinfo.xml` podría no estar disponible si Red Hat no administra el repositorio. Si no se encuentra `updateinfo.xml`; no se aplica ningún parche.
1. Cada aviso de actualización de `updateinfo.xml` incluye varios atributos que denota las propiedades de los paquetes del aviso, tal y como se describe en la siguiente tabla.
**Atributos de aviso de actualización**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
1. El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave [Product (Producto)PatchFilter del tipo de datos ](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la base de referencia de parches.
1. Los paquetes se seleccionan para la actualización de acuerdo con las siguientes directrices:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).
## Funcionamiento de las reglas de líneas de base de revisiones en SUSE Linux Enterprise Server
En SLES, cada parche incluye los siguientes atributos que denotan las propiedades de los paquetes del parche:
+ **Category**: Corresponde al valor del atributo clave **Classification** en el tipo de datos [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la línea de base de revisiones. Denota el tipo de parche incluido en el aviso de actualización.
Puede consultar la lista de valores admitidos mediante el comando **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** de la AWS CLI o la operación **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** de la API. También puede consultar la lista en el área **Approval rules** (Reglas de aprobación) de la página **Create patch baseline** (Crear una base de referencia de parches) o **Edit patch baseline** (Editar una base de referencia de parches) de la consola de Systems Manager.
+ **Gravedad**: corresponde al valor del atributo clave **Gravedad** en el tipo de datos [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la línea de base de revisiones. Denota la gravedad de los parches.
Puede consultar la lista de valores admitidos mediante el comando **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** de la AWS CLI o la operación **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** de la API. También puede consultar la lista en el área **Approval rules** (Reglas de aprobación) de la página **Create patch baseline** (Crear una base de referencia de parches) o **Edit patch baseline** (Editar una base de referencia de parches) de la consola de Systems Manager.
El producto del nodo administrado se determina en función del SSM Agent. Este atributo corresponde al valor del atributo clave **Product** del tipo de datos [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) de la línea de base de revisiones.
En cada parche, la base de referencia de parches se usa como filtro, de modo que solo se incluyen en la actualización los paquetes cualificados. Si varios paquetes son aplicables después de la aplicación de la definición de bases de referencia de parches, se usa la más reciente.
Para obtener información acerca de los formatos aceptados para las listas de parches aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
## Funcionamiento de las reglas de líneas de base de revisiones en Ubuntu Server
En Ubuntu Server, el servicio de línea de base de revisiones permite filtrar en los campos *Prioridad* y *Sección*. Estos campos suelen estar presentes para todos los paquetes de Ubuntu Server. Para determinar si un parche se ha seleccionado mediante la base de referencia de parches, Patch Manager hace lo siguiente:
1. En sistemas Ubuntu Server, el equivalente de `sudo apt-get update` es ejecutar para actualizar la lista de paquetes disponibles. Los repositorios no están configurados y los datos se obtienen de los repositorios configurados en una lista de `sources`.
1. Si está disponible una actualización para `python3-apt` (una interfaz de biblioteca de Python para `libapt`), se actualiza a la versión más reciente. (Este paquete no relacionado con la seguridad se actualiza aunque no haya seleccionado la opción **Include nonsecurity updates** [Incluir actualizaciones no relacionadas con la seguridad]).
1. Después, se aplican las listas de [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) y [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches).
**nota**
Debido a que no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Ubuntu Server, las opciones de aprobación automática no son compatibles con este sistema operativo.
Sin embargo, las reglas de aprobación también están sujetas a si se seleccionó la casilla de verificación **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad) durante la creación o la última actualización de una base de referencia de parches.
Además, si se excluyen las actualizaciones no relacionadas con la seguridad, se aplica una regla implícita para seleccionar únicamente los paquetes con actualizaciones en repositorios de seguridad. Para cada paquete, la versión candidata del paquete (que suele ser la última) debe formar parte de un repositorio de seguridad. En este caso, en Ubuntu Server, las versiones candidatas a revisiones se limitan a las revisiones incluidas en los siguientes repositorios:
+ Ubuntu Server 16.04 LTS: `xenial-security`
+ Ubuntu Server 18.04 LTS: `bionic-security`
+ Ubuntu Server 20.04 LTS: `focal-security`
+ Ubuntu Server 22.04 LTS (`jammy-security`)
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)
Si se incluyen actualizaciones no relacionadas con la seguridad, también se tienen en cuenta los parches de los demás repositorios.
Para obtener información acerca de los formatos aceptados para las listas de parches aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
Para ver el contenido de los campos *Priority* y *Section *, ejecute el siguiente comando `aptitude`:
**nota**
Es posible que necesite instalar por primera vez Aptitude en sistemas Ubuntu Server 16.
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
En la respuesta a este comando, todos los paquetes actualizables se notifican en este formato:
```
name, priority, section, archive, candidate version
```
Para obtener información sobre los valores de estado de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).
# Diferencias en la operación de revisiones entre Linux y Windows Server
En este tema se describen las principales diferencias entre la aplicación de revisiones de Linux y Windows Server en Patch Manager, una herramienta de AWS Systems Manager.
**nota**
Para aplicar revisiones a los nodos administrados de Linux, los nodos deben ejecutar la versión de SSM Agent 2.0.834.0 o posterior.
Cada vez que se agregan herramientas nuevas a Systems Manager o se actualizan las herramientas existentes, se lanza una versión actualizada de SSM Agent. No utilizar la versión más reciente del agente puede impedir que el nodo administrado utilice diversas herramientas y características de Systems Manager. Por este motivo, se recomienda automatizar el proceso de mantener SSM Agent actualizado en los equipos. Para obtener más información, consulte [Automatización de las actualizaciones de SSM Agent](ssm-agent-automatic-updates.md). Suscríbase a la página [SSM Agent Release Notes](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) en GitHub para recibir notificaciones sobre las actualizaciones de SSM Agent.
## Diferencia 1: evaluación de parches
Patch Manager utiliza procesos diferentes en los nodos administrados por Windows y los nodos administrados por Linux con el fin de evaluar qué revisiones deben incluirse.
**Linux**
En la aplicación de revisiones de Linux, Systems Manager evalúa las reglas de bases de referencia de revisiones y la lista de las revisiones aprobadas y rechazadas en *cada* nodo administrado. Systems Manager debe evaluar la aplicación de revisiones en cada nodo debido a que el servicio recupera la lista de actualizaciones y revisiones conocidas a partir de los repositorios configurados en el nodo administrado.
**Windows**
En la aplicación de parches de Windows, Systems Manager evalúa las reglas de base de referencia de parches y la lista de los parches aprobados y rechazados *directamente en el servicio*. Puede hacerlo porque los parches de Windows se obtienen de un único repositorio (Windows Update).
## Diferencia 2: parches `Not Applicable`
Debido a la gran cantidad de paquetes disponibles para los sistemas operativos Linux, Systems Manager no informa los detalles sobre parches en el estado *Not Applicable* (No aplicable). Un parche `Not Applicable` es, por ejemplo, un parche del software Apache cuando la instancia no tiene instalado dicho servicio. Systems Manager informa la cantidad de revisiones `Not Applicable` en el resumen, pero si llama a la API [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) para un nodo administrado, los datos devueltos no incluyen revisiones cuyo estado sea `Not Applicable`. Este comportamiento es diferente en Windows.
## Diferencia 3: compatibilidad con documentos SSM
El documento `AWS-ApplyPatchBaseline` de Systems Manager (documento de SSM) no admite nodos administrados de Linux. Para aplicar bases de referencia de revisiones a nodos administrados de Linux, macOS y Windows Server, el documento de SSM recomendado es `AWS-RunPatchBaseline`. Para obtener más información, consulte [Documentos de comando de SSM para la aplicación de revisiones a nodos administrados](patch-manager-ssm-documents.md) y [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
## Diferencia 4: parches de aplicación
Patch Manager se centra principalmente en aplicar parches a sistemas operativos. Sin embargo, también puede utilizar Patch Manager para aplicar revisiones a algunas aplicaciones de los nodos administrados.
**Linux**
En los sistemas operativos Linux, Patch Manager utiliza los repositorios configurados para actualizaciones y no distingue entre sistemas operativos y parches de aplicaciones. Puede utilizar Patch Manager para definir de qué repositorios obtendrá actualizaciones. Para obtener más información, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md).
**Windows**
En nodos administrados de Windows Server, puede aplicar reglas de aprobación, así como excepciones de revisiones *aprobadas* o *rechazadas*, para las aplicaciones publicadas por Microsoft, como Microsoft Word 2016 o Microsoft Exchange Server 2016. Para obtener más información, consulte [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md).
## Diferencia 5: opciones de listas de revisiones rechazadas en líneas de base de revisiones personalizadas
Al crear una línea de base de revisiones personalizada, puede especificar una o más revisiones para una lista de **revisiones rechazadas**. En el caso de los nodos gestionados por Linux, también puede optar por permitir su instalación si son dependencias de otra revisión permitida por la línea de base.
Windows Server, sin embargo, no admite el concepto de dependencias de revisiones. Puede agregar una revisión a la lista de **revisiones rechazadas** en una línea de base personalizada para Windows Server, pero el resultado depende de (1) si la revisión rechazada ya está instalada o no en un nodo gestionado y (2) de la opción que elija para la **acción de revisiones rechazadas**.
Consulte la siguiente tabla para obtener más información sobre las opciones de revisiones rechazadas en Windows Server.
| Estado de la instalación | Opción: “Permitir como dependencia” | Opción: “Bloque” |
| --- | --- | --- |
| La revisión ya está instalada | Estado registrado: INSTALLED\$1OTHER | Estado registrado: INSTALLED\$1REJECTED |
| La revisión no está instalada | Revisión omitida | Revisión omitida |
Cada revisión para Windows Server que Microsoft lanza normalmente contiene toda la información necesaria para que la instalación se realice correctamente. Sin embargo, en ocasiones, es posible que se requiera un paquete de requisitos previos, que debe instalarse manualmente. Patch Manager no proporciona información acerca de estos requisitos previos. Para obtener información relacionada, consulte [Solución de problemas de actualización de Windows](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting) en el sitio web de Microsoft.
# Documentos de comando de SSM para la aplicación de revisiones a nodos administrados
En este tema se describen los nueve documentos de Systems Manager (documentos de SSM) disponibles para que pueda mantener los nodos administrados actualizados con las últimas revisiones relacionadas con la seguridad.
Se recomienda utilizar solo cinco de estos documentos en las operaciones de aplicación de revisiones. En conjunto, estos cinco documentos de SSM le proporcionan una gama completa de opciones de aplicación de revisiones con AWS Systems Manager. Cuatro de estos documentos se publicaron después de los cuatro documentos de SSM heredados a los que sustituyen, y contienen ampliaciones o consolidaciones de funcionalidad.
**Documentos de SSM recomendados para las revisiones**
Recomendamos utilizar los cinco documentos de SSM a continuación en las operaciones de revisión.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**Documentos de SSM heredados para las revisiones**
Los siguientes cuatro documentos de SSM heredados permanecen disponibles en algunas Regiones de AWS, pero ya no se actualizan ni se admiten. No se garantiza que estos documentos funcionen en entornos IPv6, y solo son compatibles con IPv4. No se puede garantizar que funcionen en todos los escenarios y es posible que pierdan soporte en el futuro. Le recomendamos que no utilice estos documentos para las operaciones de aplicación de parches.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Para ver los pasos para configurar las operaciones de aplicación de revisiones en un entorno que solo admite IPv6, consulte [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md).
Consulte las secciones siguientes para obtener más información sobre el uso de estos documentos de SSM en las operaciones de aplicación de revisiones.
**Topics**
+ [Documentos de SSM recomendados para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-recommended)
+ [Documentos de SSM heredados para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-legacy)
+ [Limitaciones conocidas de los documentos de SSM para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-known-limitations)
+ [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Ejemplo de escenario para utilizar el parámetro InstallOverrideList en `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Uso del parámetro BaselineOverride](patch-manager-baselineoverride-parameter.md)
## Documentos de SSM recomendados para la aplicación de revisiones a nodos administrados
Se recomienda utilizar los siguientes cinco documentos de SSM para las operaciones de aplicación de revisiones en los nodos administrados.
**Topics**
+ [`AWS-ConfigureWindowsUpdate`](#patch-manager-ssm-documents-recommended-AWS-ConfigureWindowsUpdate)
+ [`AWS-InstallWindowsUpdates`](#patch-manager-ssm-documents-recommended-AWS-InstallWindowsUpdates)
+ [`AWS-RunPatchBaseline`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaseline)
+ [`AWS-RunPatchBaselineAssociation`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineAssociation)
+ [`AWS-RunPatchBaselineWithHooks`](#patch-manager-ssm-documents-recommended-AWS-RunPatchBaselineWithHooks)
### `AWS-ConfigureWindowsUpdate`
Admite configurar las funciones básicas de Windows Update y utilizarlas para instalar actualizaciones de forma automática (o para desactivar las actualizaciones automáticas). Disponible en todas las Regiones de AWS.
Este documento de SSM indica a Windows Update que descargue e instale las actualizaciones especificadas y que reinicie los nodos administrados según sea necesario. Utilice este documento con State Manager, una herramienta de AWS Systems Manager, para asegurarse de que Windows Update conserve su configuración. También puede ejecutarlo de forma manual con Run Command, una herramienta de AWS Systems Manager, para cambiar la configuración de Windows Update.
Los parámetros disponibles en este documento permiten especificar la categoría de actualizaciones que se deben instalar (o si se deben desactivar las actualizaciones automáticas), así como especificar el día de la semana y la hora del día en que se deben ejecutar las operaciones de aplicación de revisiones. Este documento de SSM es más útil si no se necesita un control estricto sobre las actualizaciones de Windows y no es necesario recopilar información de conformidad.
**Documentos de SSM heredados a los que sustituye: **
+ *Ninguno*
### `AWS-InstallWindowsUpdates`
Instala actualizaciones en un nodo administrado de Windows Server. Disponible en todas las Regiones de AWS.
Este documento de SSM proporciona la funcionalidad básica de aplicación de revisiones para los casos en los que se desea instalar una actualización específica (mediante el parámetro `Include Kbs`), o se desea instalar revisiones con clasificaciones o categorías específicas, pero no se necesita información de conformidad de revisiones.
**Documentos de SSM heredados a los que sustituye:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Los tres documentos heredados realizan diferentes funciones, pero se pueden alcanzar los mismos resultados mediante una configuración de parámetros distinta con el documento de SSM más reciente `AWS-InstallWindowsUpdates`. Esta configuración de parámetros se describe en [Documentos de SSM heredados para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-legacy).
### `AWS-RunPatchBaseline`
Instala revisiones en los nodos administrados o los examina para determinar si falta alguna revisión que sea aplicable. Disponible en todas las Regiones de AWS.
`AWS-RunPatchBaseline` le permite controlar las aprobaciones de revisiones mediante la línea de base de revisiones que se especifica como “predeterminada” para un tipo de sistema operativo. Genera informes de conformidad de revisiones que se pueden visualizar con las herramientas de conformidad de Systems Manager. Estas herramientas proporcionan información sobre el estado de conformidad de revisiones de los nodos administrados como, por ejemplo, en qué nodos faltan revisiones y cuáles son esas revisiones. Cuando utiliza `AWS-RunPatchBaseline`, la información relativa a la conformidad de revisiones se registra mediante el comando `PutInventory` de la API. En el caso de los sistemas operativos Linux, se proporciona información sobre la conformidad para las revisiones tanto del repositorio de origen predeterminado configurado en un nodo administrado como de los repositorios de origen alternativos que se especifiquen en una base de referencia de revisiones personalizada. Para obtener más información sobre los repositorios de origen alternativos, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md). Para obtener más información acerca de las herramientas de conformidad de Systems Manager, consulte [Conformidad de AWS Systems Manager](systems-manager-compliance.md).
**Documentos heredados a los que sustituye:**
+ `AWS-ApplyPatchBaseline`
El documento heredado `AWS-ApplyPatchBaseline` se aplica únicamente en el caso de los nodos administrados de Windows Server y no ofrece soporte para la aplicación de revisiones. El nuevo documento `AWS-RunPatchBaseline` ofrece la misma compatibilidad para sistemas Windows y Linux. Es necesario disponer de la versión 2.0.834.0 del SSM Agent u otra posterior para poder utilizar el documento `AWS-RunPatchBaseline`.
Para obtener más información acerca del documento `AWS-RunPatchBaseline` de SSM, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
### `AWS-RunPatchBaselineAssociation`
Instala revisiones en las instancias o las examina para determinar si falta alguna revisión que sea aplicable. Disponible en todas las comerciales Regiones de AWS.
`AWS-RunPatchBaselineAssociation` difiere de `AWS-RunPatchBaseline` en algunos aspectos relevantes:
+ `AWS-RunPatchBaselineAssociation` está diseñado para que se utilice principalmente con asociaciones de State Manager creadas con Quick Setup, una herramienta de AWS Systems Manager. Especialmente cuando se utiliza el tipo de configuración Quick Setup de administración de host, si elige la opción **escanear las instancias para detectar las revisiones que faltan cada día**, el sistema utiliza `AWS-RunPatchBaselineAssociation` para efectuar la operación.
Sin embargo, en la mayoría de los casos, a la hora de configurar sus propias operaciones de aplicación de revisiones, debe elegir [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) o [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) en lugar de `AWS-RunPatchBaselineAssociation`.
Para obtener más información, consulte los temas siguientes:
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` admite el uso de etiquetas que permiten identificar cuál es la línea de base de revisiones que se utilizará con un conjunto de destinos cuando se ejecute.
+ Para las operaciones de aplicación de revisiones que utilizan `AWS-RunPatchBaselineAssociation`, los datos de conformidad de las revisiones se compilan en función de una asociación específica de State Manager. Los datos de conformidad de revisiones que se recopilan cuando se ejecuta `AWS-RunPatchBaselineAssociation` se registran mediante el comando `PutComplianceItems` de la API en lugar del comando `PutInventory`. Por consiguiente, se evita que se sobrescriban los datos de conformidad que no se encuentran relacionados con esta asociación en particular.
En el caso de los sistemas operativos Linux, se proporciona información sobre la conformidad para las revisiones tanto del repositorio de origen predeterminado configurado en una instancia como de los repositorios de origen alternativos que se especifiquen en una línea de base de revisiones personalizada. Para obtener más información sobre los repositorios de origen alternativos, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md). Para obtener más información acerca de las herramientas de conformidad de Systems Manager, consulte [Conformidad de AWS Systems Manager](systems-manager-compliance.md).
**Documentos heredados a los que sustituye:**
+ **Ninguno**
Para obtener más información acerca del documento `AWS-RunPatchBaselineAssociation` de SSM, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).
### `AWS-RunPatchBaselineWithHooks`
Instala revisiones en los nodos administrados o analiza los nodos para determinar si falta alguna revisión aplicable, con enlaces opcionales que se pueden utilizar para ejecutar documentos de SSM en tres puntos durante el ciclo de aplicación de revisiones. Disponible en todas las comerciales Regiones de AWS. No se admite en macOS.
`AWS-RunPatchBaselineWithHooks` se diferencia de `AWS-RunPatchBaseline` en la operación `Install`.
`AWS-RunPatchBaselineWithHooks` admite enlaces de ciclo de vida que se ejecutan en puntos designados durante la aplicación de revisiones en los nodos administrados. Dado que las instalaciones de revisiones en ocasiones requieren que se reinicien los nodos administrados, la operación de aplicación de revisiones se divide en dos eventos, lo que supone un total de tres enlaces que permiten una funcionalidad personalizada. El primer enlace tiene lugar antes de la operación `Install with NoReboot`. El segundo enlace tiene lugar después de la operación `Install with NoReboot`. El tercer enlace está disponible después del reinicio del nodo.
**Documentos heredados a los que sustituye:**
+ **Ninguno**
Para obtener más información acerca del documento `AWS-RunPatchBaselineWithHooks` de SSM, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
## Documentos de SSM heredados para la aplicación de revisiones a nodos administrados
Los cuatro documentos de SSM a continuación aún están disponibles en algunas Regiones de AWS. Sin embargo, ya no están actualizados y puede que ya no cuenten con más soporte en el futuro, por lo que recomendamos que no se utilicen. En su lugar, utilice los documentos se describe en [Documentos de SSM recomendados para la aplicación de revisiones a nodos administrados](#patch-manager-ssm-documents-recommended).
**Topics**
+ [`AWS-ApplyPatchBaseline`](#patch-manager-ssm-documents-legacy-AWS-ApplyPatchBaseline)
+ [`AWS-FindWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-AWS-FindWindowsUpdates)
+ [`AWS-InstallMissingWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallMissingWindowsUpdates)
+ [`AWS-InstallSpecificWindowsUpdates`](#patch-manager-ssm-documents-legacy-AWS-InstallSpecificWindowsUpdates)
### `AWS-ApplyPatchBaseline`
Admite solo los nodos administrados de Windows Server, pero no incluye la compatibilidad con el uso de revisiones en aplicaciones que se encuentra en su sustitución, `AWS-RunPatchBaseline`. No está disponible en Regiones de AWS lanzadas después de agosto de 2017.
**nota**
El sustituto de este documento de SSM, `AWS-RunPatchBaseline`, requiere la versión 2.0.834.0 del SSM Agent u otra posterior. Puede utilizar el documento `AWS-UpdateSSMAgent` para actualizar los nodos administrados a la versión más reciente del agente.
### `AWS-FindWindowsUpdates`
Ha sido sustituido por `AWS-InstallWindowsUpdates`, que puede realizar las mismas acciones. No está disponible en Regiones de AWS lanzadas después de abril de 2017.
Para lograr el mismo resultado que obtendría a partir de este documento de SSM heredado, utilice la siguiente configuración de parámetros con el documento de sustitución recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
Ha sido sustituido por `AWS-InstallWindowsUpdates`, que puede realizar las mismas acciones. No está disponible en ninguna de las Regiones de AWS lanzadas después de abril de 2017.
Para lograr el mismo resultado que obtendría a partir de este documento de SSM heredado, utilice la siguiente configuración de parámetros con el documento de sustitución recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
Ha sido sustituido por `AWS-InstallWindowsUpdates`, que puede realizar las mismas acciones. No está disponible en ninguna de las Regiones de AWS lanzadas después de abril de 2017.
Para lograr el mismo resultado que obtendría a partir de este documento de SSM heredado, utilice la siguiente configuración de parámetros con el documento de sustitución recomendado, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *lista de artículos de KB separada por comas*
## Limitaciones conocidas de los documentos de SSM para la aplicación de revisiones a nodos administrados
### Interrupciones de reinicio externo
Si el sistema del nodo inicia un reinicio durante la instalación de una revisión (por ejemplo, para aplicar actualizaciones al firmware o a características como SecureBoot), la ejecución del documento de revisión puede interrumpirse y marcarse como fallida aunque las revisiones se hayan instalado de manera correcta. Esto se debe a que el agente de SSM no puede conservar y reanudar el estado de ejecución del documento tras reinicios externos.
Para comprobar el estado de instalación de la revisión tras una ejecución fallida, ejecute una operación de `Scan` de aplicación de revisiones y, a continuación, compruebe los datos de cumplimiento del parche en Patch Manager para evaluar el estado de cumplimiento actual.
# Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`
AWS Systems Manager es compatible con `AWS-RunPatchBaseline`, un documento de Systems Manager (documento de SSM) para Patch Manager, una herramienta de AWS Systems Manager. Este documento de SSM realiza operaciones de aplicación de revisiones en los nodos administrados para actualizaciones relacionadas con la seguridad y de otros tipos. Cuando el documento se ejecuta, utiliza la línea de base de revisiones especificada como “predeterminada” para un tipo de sistema operativo en caso de que no se hubiera indicado ningún grupo de revisiones. En caso contrario, utiliza la línea de base de revisiones que se asocia con el grupo de revisiones. Para obtener información acerca de los grupos de revisiones, consulte [Grupos de revisiones](patch-manager-patch-groups.md).
Puede utilizar el documento `AWS-RunPatchBaseline` para aplicar revisiones a los sistemas operativos y a las aplicaciones. (En Windows Server, la compatibilidad con las aplicaciones se limita a las actualizaciones de las aplicaciones publicadas por Microsoft).
Este documento es compatible con los nodos administrados de Linux, macOS y Windows Server. El documento se encargará de realizar las acciones adecuadas para cada plataforma.
**nota**
Patch Manager Además, es compatible con el documento de SSM heredado `AWS-ApplyPatchBaseline`. Sin embargo, este documento solo es compatible con la aplicación de revisiones en nodos administrados de Windows. Se recomienda que utilice `AWS-RunPatchBaseline` en su lugar porque es compatible con la aplicación de revisiones en los tipos de nodos administrados de Linux, macOS y Windows Server. Es necesario disponer de la versión 2.0.834.0 del SSM Agent u otra posterior para poder utilizar el documento `AWS-RunPatchBaseline`.
------
#### [ Windows Server ]
En nodos administrados de Windows Server, el documento `AWS-RunPatchBaseline` descarga e invoca un módulo de PowerShell, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones contiene una lista de revisiones aprobadas que se compila al consultar dicha línea de base de revisiones en un servidor de Windows Server Update Services (WSUS). Esta lista se transfiere a la API de Windows Update, que controla la descarga y la instalación de las revisiones aprobadas, según proceda.
------
#### [ Linux ]
En nodos administrados de Linux, el documento `AWS-RunPatchBaseline` invoca un módulo de Python, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones utiliza las reglas definidas y las listas de revisiones aprobadas y bloqueadas con el fin de impulsar el administrador de paquetes adecuado para cada tipo de nodo:
+ Los nodos administrados de Amazon Linux 2, Oracle Linux y RHEL 7 utilizan YUM. Para las operaciones de YUM, Patch Manager requiere `Python 2.6` o una versión posterior compatible (2.6 a 3.12). Amazon Linux 2023 usa DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12).
+ RHELLos nodos administrados de 8 utilizan DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12). (Ninguna de las dos versiones viene instalada en RHEL 8 de forma predeterminada. Para ello, deberá instalar una u otra versión manualmente).
+ Las instancias de Debian Server y Ubuntu Server usan APT. Para las operaciones de APT, Patch Manager requiere una versión compatible de `Python 3` (3.0 a 3.12).
------
#### [ macOS ]
En nodos administrados de macOS, el documento `AWS-RunPatchBaseline` invoca un módulo de Python, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. A continuación, un subproceso de Python invoca la AWS Command Line Interface (AWS CLI) en el nodo a fin de recuperar la información de instalación y actualización de los administradores de paquetes especificados e impulsar el administrador de paquetes adecuado para cada paquete de actualización.
------
Cada instantánea se corresponde con una Cuenta de AWS, un grupo de revisiones, un sistema operativo y un ID de instantánea. La instantánea se entrega a través de una URL prefirmada de Amazon Simple Storage Service (Amazon S3), que se vence transcurridas las 24 horas desde la creación de la instantánea. Sin embargo, si desea aplicar el mismo contenido de la instantánea a otros nodos administrados una vez que la URL se haya vencido, puede generar una nueva dirección de Amazon S3 prefirmada hasta tres días después de la creación de la instantánea. Para ello, utilice el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Cuando se han instalado todas las actualizaciones aprobadas y aplicables, y se han realizado los reinicios necesarios, se genera la información de conformidad de revisiones en un nodo administrado y se notifica a Patch Manager.
**nota**
Si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia después de que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
Para obtener información sobre cómo ver los datos de conformidad de revisiones, consulte [Acerca de la conformidad de parches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaseline`Parámetros
`AWS-RunPatchBaseline` admite seis parámetros. El parámetro `Operation` es obligatorio. Los parámetros `InstallOverrideList`, `BaselineOverride` y `RebootOption` son opcionales. `Snapshot-ID` es opcional desde el punto de vista técnico, pero se recomienda proporcionar un valor personalizado al ejecutar `AWS-RunPatchBaseline` fuera de un periodo de mantenimiento. Patch Manager puede suministrar el valor automáticamente cuando el documento se ejecuta como parte de una operación de un periodo de mantenimiento.
**Topics**
+ [Nombre del parámetro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nombre del parámetro: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [Nombre del parámetro: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [Nombre del parámetro: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [Nombre del parámetro: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [Nombre del parámetro: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### Nombre del parámetro: `Operation`
**Usage**: requerido.
**Opciones**: `Scan` \$1 `Install`.
Examen
Cuando elige la opción `Scan`, `AWS-RunPatchBaseline` determina el estado de conformidad de las revisiones del nodo administrado y notifica esta información a Patch Manager. `Scan` no solicita que se instalen actualizaciones ni que se reinicien los nodos administrados. En lugar de ello, la operación identifica las actualizaciones aprobadas que faltan y que son aplicables al nodo.
Instalación
Al elegir la opción `Install`, `AWS-RunPatchBaseline` intenta instalar las actualizaciones aprobadas y aplicables que faltan en el nodo administrado. La información de conformidad de revisiones generada como parte de una operación `Install` no muestra las actualizaciones que faltan, pero podría notificar aquellas que presentan un estado de error si la instalación de la actualización no se ha podido realizar por cualquier motivo. Cuando una actualización se instala en un nodo administrado, este se reinicia para garantizar que la actualización esté instalada y activa. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaseline`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)).
Si se instala una revisión especificada por las reglas de la línea de base *antes* de que Patch Manager actualice el nodo administrado, es posible que el sistema no se reinicie como es debido. Esto puede ocurrir cuando un usuario instala manualmente una revisión o cuando la instala automáticamente otro programa, como el `unattended-upgrades` paquete de Ubuntu Server.
### Nombre del parámetro: `AssociationId`
**Usage**: opcional.
`AssociationId` es el ID de una asociación existente en State Manager, una herramienta de AWS Systems Manager. Patch Manager lo utiliza para agregar datos de conformidad a la asociación especificada. Esta asociación está relacionada con una operación de aplicación de revisiones que está [configurada en una política de revisiones en Quick Setup](quick-setup-patch-manager.md).
**nota**
Con el `AWS-RunPatchBaseline`, si se proporciona un valor `AssociationId` junto con una anulación de la línea de base de la política de revisiones, la aplicación de revisiones se realiza como una operación `PatchPolicy` y el valor `ExecutionType` informado en `AWS:ComplianceItem` también es `PatchPolicy`. Si no se proporciona un valor `AssociationId`, la aplicación de revisiones se realiza como una operación `Command` y el informe del valor `ExecutionType` en el `AWS:ComplianceItem` enviado también es `Command`.
Si aún no dispone de una asociación que desee utilizar, puede crear una mediante la ejecución del comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html).
### Nombre del parámetro: `Snapshot ID`
**Usage**: opcional.
`Snapshot ID` es un ID exclusivo (GUID) que utiliza Patch Manager para garantizar que un conjunto de nodos administrados en los que se aplican revisiones en una sola operación tenga el mismo conjunto de revisiones aprobadas. Aunque el parámetro se define como opcional, nuestra mejor práctica recomendada depende de si se ejecuta o no `AWS-RunPatchBaseline` en un periodo de mantenimiento, tal como se describe en la siguiente tabla.
**`AWS-RunPatchBaseline`Prácticas recomendadas de**
| Mode | Práctica recomendada | Details |
| --- | --- | --- |
| Ejecución de AWS-RunPatchBaseline dentro de un periodo de mantenimiento | No proporcione un ID de instantánea, sino que Patch Manager lo hará en su lugar. | Si utiliza un periodo de mantenimiento para ejecutar `AWS-RunPatchBaseline`, no debe proporcionar su propio ID de instantánea generado. En este caso, Systems Manager proporciona un valor GUID en función del ID de ejecución del periodo de mantenimiento. De este modo, se garantiza que se utilice un ID correcto para todas las invocaciones de `AWS-RunPatchBaseline` en dicho periodo de mantenimiento. Si especifica un valor en este caso, tenga en cuenta que la instantánea de la línea de base de revisiones no podría mantenerse durante más de tres días. Después de eso, se generará una nueva instantánea, aunque especifique el mismo ID después de que expire la instantánea. |
| Ejecución de AWS-RunPatchBaseline fuera de un periodo de mantenimiento | Genere y especifique un valor GUID personalizado para el ID de instantánea.¹ | Cuando no esté utilizando un periodo de mantenimiento para ejecutar `AWS-RunPatchBaseline`, se recomienda generar y especificar un ID de instantánea exclusivo por cada línea de base de revisiones, especialmente si ejecuta el documento `AWS-RunPatchBaseline` en varios nodos administrados durante la misma operación. Si no especifica un ID en este caso, Systems Manager genera otro ID de instantánea para cada nodo administrado al que se envía el comando. Esto podría generar diferentes conjuntos de revisiones que se especifican entre los nodos administrados. Por ejemplo, supongamos que se ejecuta el documento `AWS-RunPatchBaseline` directamente a través de Run Command, una herramienta de AWS Systems Manager, y selecciona como destino un grupo de 50 nodos administrados. Al especificar un ID de instantánea personalizado, se genera una sola instantánea de la línea de base que se utiliza para evaluar y aplicar revisiones en todos los nodos, lo que garantiza que tengan un estado coherente. |
| ¹ Puede utilizar cualquier herramienta que genere un GUID con el fin de crear un valor para el parámetro de ID de la instantánea. Por ejemplo, en PowerShell, puede utilizar el cmdlet `New-Guid` para generar un GUID con el formato `12345699-9405-4f69-bc5e-9315aEXAMPLE`. |
### Nombre del parámetro: `InstallOverrideList`
**Usage**: opcional.
Mediante `InstallOverrideList`, se puede especificar una URL de https o una URL de tipo ruta de Amazon S3 a una lista de revisiones que deben instalarse. Esta lista de instalación de revisiones, que mantiene en formato YAML, invalida las revisiones especificadas por la línea de base de revisiones predeterminada actual. De este modo, se le proporcionará un control pormenorizado sobre qué revisiones se instalan en los nodos administrados.
**importante**
El nombre de archivo `InstallOverrideList` no puede contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
El comportamiento de la operación de revisión cuando se utiliza el parámetro `InstallOverrideList` difiere entre Linux y los nodos administrados por macOS y los nodos administrados por Windows Server. En Linux y macOS, Patch Manager intenta aplicar los parches incluidos en la lista de parches de `InstallOverrideList` que estén presentes en cualquier repositorio habilitado en el nodo, independientemente de que los parches coincidan o no con las reglas de la línea de base de revisiones. Sin embargo, en los nodos Windows Server, los parches de la lista de parches `InstallOverrideList` se aplican *solo* si también cumplen con las reglas de la línea de base de revisiones.
Tenga en cuenta que los informes de conformidad reflejan los estados de revisiones de acuerdo con lo que se especifica en la línea de base de revisiones, no lo que especifique en una lista de revisiones `InstallOverrideList`. En otras palabras, las operaciones de análisis omiten el parámetro `InstallOverrideList`. De este modo, se garantiza que los informes de conformidad reflejen de forma coherente los estados de revisiones de acuerdo con la política, en lugar de lo que se ha aprobado una operación específica para la aplicación de revisiones.
**nota**
Cuando aplique revisiones a un nodo que solo usa IPv6, asegúrese de que se pueda acceder a la URL proporcionada desde el nodo. Si la opción de configuración `UseDualStackEndpoint` de SSM Agent está establecida en `true`, se utiliza un cliente S3 de pila doble cuando se proporciona una URL de S3. Consulte [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obtener más información sobre cómo configurar el agente para usar la pila doble.
Para obtener una descripción de cómo puede utilizar el parámetro `InstallOverrideList` para aplicar diferentes tipos de revisiones a un grupo de destino en diferentes programaciones de ventanas de mantenimiento al tiempo que utiliza una única línea de base de revisiones, consulte [Ejemplo de escenario para utilizar el parámetro InstallOverrideList en `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md).
**Formatos de URL válidos**
**nota**
Si su archivo se encuentra almacenado en un bucket de acceso público, puede especificar un formato de URL de https o una URL de tipo ruta de Amazon S3. Si su archivo se encuentra almacenado en un bucket privado, debe especificar una URL de tipo ruta de Amazon S3.
+ **Formato de URL https**:
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **URL de tipo ruta de Amazon S**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formatos de contenido YAML válidos**
Los formatos que utiliza para especificar revisiones en su lista dependen del sistema operativo del nodo administrado. El formato general, sin embargo, es el siguiente:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Aunque puede proporcionar campos adicionales en su archivo YAML, estos se pasan por alto durante las operaciones de revisiones.
Además, le recomendamos que verifique que el formato de su archivo YAML es válido antes de añadir o actualizar la lista de su bucket de S3. Para obtener más información acerca del formato YAML, consulte [yaml.org](http://www.yaml.org). Para consultar las opciones de herramientas de validación, realice una búsqueda web de "validadores de formato yaml".
------
#### [ Linux ]
**id**
El campo **id** es obligatorio. Utilícelo para especificar revisiones mediante el nombre del paquete y la arquitectura. Por ejemplo: `'dhclient.x86_64'`. Puede utilizar comodines en id para indicar varios paquetes. Por ejemplo: `'dhcp*'` y `'dhcp*1.*'`.
**Título**
El campo **title (título)** es opcional, pero en sistemas Linux ofrece capacidades de filtrado adicionales. Si utiliza **title (título)**, debería contener información de la versión del paquete en uno de los siguientes formatos:
YUM/SUSE Linux Enterprise Server (SLES):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Para los títulos de las revisiones de Linux, puede utilizar uno o varios comodines en cualquier posición para ampliar el número de paquetes coincidentes. Por ejemplo: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Por ejemplo:
+ la versión del paquete apt 1.2.25 actualmente está instalada en el nodo administrado, pero la versión 1.2.27 ya está disponible.
+ Puede añadir la versión apt.amd64 1.2.27 a la lista de revisiones. Depende de la versión apt utils.amd64 1.2.27, pero la versión apt-utils.amd64 1.2.25 se especifica en la lista.
En este caso, la versión apt 1.2.27 se bloqueará a partir de la instalación y se registrará como "Failed-NonCompliant".
------
#### [ Windows Server ]
**id**
El campo **id** es obligatorio. Úselo para especificar las revisiones con los ID de la Base de conocimientos de Microsoft (por ejemplo, KB2736693) y del boletín de seguridad de Microsoft (por ejemplo, MS17-023).
Cualquier otro campo que desee proporcionar en una lista de revisiones para Windows es opcional y solo para fines informativos propios. Puede utilizar campos adicionales como, por ejemplo, **title (título)**, **classification (clasificación)**, **severity (gravedad)** o cualquier otro para proporcionar información más detallada sobre las revisiones especificados.
------
#### [ macOS ]
**id**
El campo **id** es obligatorio. Se puede proporcionar el valor del campo **id** mediante un formato `{package-name}.{package-version}` o un formato \$1package\$1name\$1.
------
**Listas de revisiones de ejemplo**
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Debian Server**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **macOS**
```
patches:
-
id: 'XProtectPlistConfigData'
-
id: 'MRTConfigData.1.61'
-
id: 'Command Line Tools for Xcode.11.5'
-
id: 'Gatekeeper Configuration Data'
```
+ **Oracle Linux**
```
patches:
-
id: 'audit-libs.x86_64'
title: '*2.8.5-4.el7'
-
id: 'curl.x86_64'
title: '*.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:2.02-0.81.0.1.el7'
-
id: 'grub2.x86_64'
title: 'grub2.x86_64:1:*-0.81.0.1.el7'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nombre del parámetro: `RebootOption`
**Usage**: opcional.
**Opciones**: `RebootIfNeeded` \$1 `NoReboot`
**Valor predeterminado**: `RebootIfNeeded`
**aviso**
La opción predeterminada es `RebootIfNeeded`. Asegúrese de seleccionar la opción correcta para su caso de uso. Por ejemplo, si los nodos administrados deben reiniciarse inmediatamente para completar un proceso de configuración, elija `RebootIfNeeded`. O bien, si necesita mantener la disponibilidad de los nodos administrados hasta una hora de reinicio programada, elija `NoReboot`.
**importante**
No recomendamos el uso de Patch Manager para revisar las instancias de clústeres en Amazon EMR (antes denominado Amazon Elastic MapReduce). En concreto, no seleccione la opción `RebootIfNeeded` para el parámetro `RebootOption`. (Esta opción está disponible en los documentos de SSM Command para implementar revisiones `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation`, y `AWS-RunPatchBaselineWithHooks`).
Los comandos subyacentes para implementar revisiones mediante el uso de Patch Manager y los comandos `yum` y `dnf`. Por lo tanto, las operaciones generan incompatibilidades debido a la forma en que se instalan los paquetes. Para obtener información sobre los métodos preferidos para actualizar el software en los clústeres de Amazon EMR, consulte [Uso de la AMI predeterminada para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) en la *Guía de administración de Amazon EMR*.
RebootIfNeeded
Cuando se elige la opción `RebootIfNeeded`, el nodo administrado se reinicia en cualquiera de los siguientes casos:
+ Patch Manager instaló una o más revisiones.
Patch Manager no evalúa si la revisión *requiere* llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.
+ Patch Manager detecta uno o más revisiones con un estado de `INSTALLED_PENDING_REBOOT` durante la operación `Install`.
El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación `Install` o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
El reinicio de los nodos administrados en estos dos casos garantiza que los paquetes actualizados se eliminen de la memoria y mantiene un comportamiento de aplicación de revisiones y reinicio consistente en todos los sistemas operativos.
NoReboot
Cuando elige la opción `NoReboot`, Patch Manager no reinicia un nodo administrado aunque haya instalado revisiones durante la operación `Install`. Esta opción es útil si sabe que los nodos administrados no requieren reinicio después de aplicar las revisiones, o si dispone de aplicaciones o procesos que se ejecutan en un nodo que no deberían verse interrumpidos como consecuencia del reinicio de una operación de aplicación de revisiones. También es útil cuando se desea tener más control sobre el tiempo de los reinicios del nodo administrado, por ejemplo, mediante un periodo de mantenimiento.
Si elige la opción `NoReboot` y se ha instalado una revisión, se asigna a la revisión un estado de `InstalledPendingReboot`. Sin embargo, el nodo administrado en sí mismo está marcado como `Non-Compliant`. Una vez que se produce un reinicio y se ejecuta una operación `Scan`, el estado del nodo administrado se actualiza a `Compliant`.
La opción `NoReboot` solo impide los reinicios a nivel del sistema operativo. Los reinicios a nivel de servicio aún pueden producirse como parte del proceso de aplicación de revisiones. Por ejemplo, cuando se actualiza Docker, los servicios dependientes, como Amazon Elastic Container Service, pueden reiniciarse automáticamente incluso con `NoReboot` habilitado. Si tiene servicios críticos que no deben interrumpirse, considere tomar medidas adicionales, como eliminar temporalmente las instancias del servicio o programar la aplicación de revisiones durante los periodos de mantenimiento.
**Archivo de seguimiento de instalación de revisiones**: para realizar un seguimiento de la instalación de revisiones, especialmente las instaladas desde el último reinicio del sistema, Systems Manager mantiene un archivo en el nodo administrado.
**importante**
No elimine ni modifique el archivo de seguimiento. Si este archivo se elimina o está dañado, el informe de conformidad de revisiones para el nodo administrado es inexacto. Si esto sucede, reinicie el nodo y ejecute una operación de análisis de revisiones para restaurar el archivo.
Este archivo de seguimiento se almacena en las siguientes ubicaciones de los nodos administrados:
+ Sistemas operativos Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operativo :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nombre del parámetro: `BaselineOverride`
**Usage**: opcional.
Puede definir las preferencias de aplicación de revisiones en tiempo de ejecución mediante el parámetro `BaselineOverride`. Esta anulación de la base de referencia se mantiene como un objeto JSON en un bucket de S3. Garantiza que las operaciones de aplicación de revisiones utilicen las bases de referencia proporcionadas que concuerdan con el sistema operativo del host en lugar de aplicar las reglas de la línea de base de revisiones predeterminada
**importante**
El nombre de archivo `BaselineOverride` no puede contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
Para obtener más información acerca de cómo utilizar el parámetro `BaselineOverride`, consulte [Uso del parámetro BaselineOverride](patch-manager-baselineoverride-parameter.md).
### Nombre del parámetro: `StepTimeoutSeconds`
**Usage**: requerido.
El tiempo en segundos, entre 1 y 36 000 segundos (10 horas), para que un comando se complete antes de considerar que se ha producido un error.
# Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineAssociation`
Al igual que el documento `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` realiza operaciones de aplicación de revisiones en las instancias para actualizaciones relacionadas con la seguridad y de otros tipos. Además, puede utilizar el documento `AWS-RunPatchBaselineAssociation` para aplicar revisiones a los sistemas operativos y a las aplicaciones. (En Windows Server, la compatibilidad con las aplicaciones se limita a las actualizaciones de las aplicaciones publicadas por Microsoft).
Este documento admite instancias de Amazon Elastic Compute Cloud (Amazon EC2) para Linux, macOS y Windows Server. No admite nodos que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). El documento se encargará de realizar las acciones adecuadas para cada plataforma, para lo cual invocará un módulo de Python en las instancias de Linux y macOS, así como un módulo de PowerShell en las instancias de Windows.
Sin embargo, `AWS-RunPatchBaselineAssociation` se diferencia de `AWS-RunPatchBaseline` en los siguientes aspectos:
+ `AWS-RunPatchBaselineAssociation` está diseñado para que se utilice principalmente con asociaciones de State Manager creadas con [Quick Setup](systems-manager-quick-setup.md), una herramienta de AWS Systems Manager. Especialmente cuando se utiliza el tipo de configuración Quick Setup de administración de host, si elige la opción **escanear las instancias para detectar las revisiones que faltan cada día**, el sistema utiliza `AWS-RunPatchBaselineAssociation` para efectuar la operación.
Sin embargo, en la mayoría de los casos, a la hora de configurar sus propias operaciones de aplicación de revisiones, debe elegir [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) o [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) en lugar de `AWS-RunPatchBaselineAssociation`.
+ Cuando se utiliza el documento `AWS-RunPatchBaselineAssociation`, se puede especificar un par de claves de etiqueta en el campo correspondiente al parámetro `BaselineTags` del documento. Si una línea de base de revisiones personalizada en su Cuenta de AWS comparte estas etiquetas, Patch Manager, una herramienta de AWS Systems Manager, utiliza esa línea de base etiquetada cuando se ejecuta en las instancias de destino en lugar de la línea de base de revisiones “predeterminada” que actualmente se encuentra especificada para el tipo de sistema operativo.
**nota**
Si elige utilizar `AWS-RunPatchBaselineAssociation` en las operaciones de aplicación de revisiones distintas de las configuradas mediante Quick Setup, y desea utilizar el parámetro opcional `BaselineTags`, es necesario que proporcione algunos permisos adicionales al [perfil de instancias](setup-instance-permissions.md) para las instancias de Amazon Elastic Compute Cloud (Amazon EC2). Para obtener más información, consulte [Nombre del parámetro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).
Los dos siguientes formatos son válidos para su parámetro `BaselineTags`:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**importante**
Los valores y las claves de las etiquetas no pueden contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
+ Los datos de conformidad de revisiones que se recopilan cuando se ejecuta `AWS-RunPatchBaselineAssociation` se registran mediante el comando `PutComplianceItems` de la API en lugar del comando `PutInventory`, que utiliza `AWS-RunPatchBaseline`. Esta diferencia implica que la información de conformidad de revisiones se almacena y notifica en función de una *asociación* específica. Los datos de conformidad de revisiones generados fuera de esta asociación no se sobrescriben.
+ La información de conformidad con la revisión notificada con posterioridad a la ejecución de `AWS-RunPatchBaselineAssociation` indica si una instancia está en conformidad o no. No se incluyen los detalles a nivel de revisión, como se demuestra con la salida del siguiente comando de la AWS Command Line Interface (AWS CLI). El comando filtra en `Association` como el tipo de conformidad:
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
El sistema devuelve información similar a la siguiente.
```
{
"ComplianceItems": [
{
"Status": "NON_COMPLIANT",
"Severity": "UNSPECIFIED",
"Title": "MyPatchAssociation",
"ResourceType": "ManagedInstance",
"ResourceId": "i-02573cafcfEXAMPLE",
"ComplianceType": "Association",
"Details": {
"DocumentName": "AWS-RunPatchBaselineAssociation",
"PatchBaselineId": "pb-0c10e65780EXAMPLE",
"DocumentVersion": "1"
},
"ExecutionSummary": {
"ExecutionTime": 1590698771.0
},
"Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
}
]
}
```
Si se ha especificado un valor de par de claves de etiqueta como parámetro para el documento `AWS-RunPatchBaselineAssociation`, Patch Manager busca una línea de base de revisiones personalizada que concuerde con el tipo de sistema operativo y que se haya etiquetado con ese mismo par de claves de etiquetas. Esta búsqueda no se limita a la línea de base de revisiones predeterminada que se haya especificado ni a la base de referencia asignada a un grupo de revisiones. Si no se encuentra ninguna base de referencia con las etiquetas especificadas, Patch Manager busca a continuación un grupo de revisiones, siempre que se haya especificado uno en el comando que ejecuta `AWS-RunPatchBaselineAssociation`. Si no hay ningún grupo de revisiones que concuerde, Patch Manager vuelve a la línea de base de revisiones predeterminada actual para la cuenta del sistema operativo.
Si se encuentra más de una línea de base de revisiones con las etiquetas especificadas en el documento `AWS-RunPatchBaselineAssociation`, Patch Manager devuelve un mensaje de error donde se indica que solo es posible etiquetar una línea de base de revisiones con ese par de valor de clave para proceder con la operación.
**nota**
En los nodos de Linux, se utiliza el administrador de paquetes adecuado para cada tipo de nodo a fin de instalar los paquetes:
Las instancias de Amazon Linux 2, Oracle Linux y RHEL usan YUM. Para las operaciones de YUM, Patch Manager requiere `Python 2.6` o una versión posterior compatible (2.6 a 3.12). Amazon Linux 2023 usa DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12)
Las instancias de Debian Server y Ubuntu Server usan APT. Para las operaciones de APT, Patch Manager requiere una versión compatible de `Python 3` (3.0 a 3.12).
Una vez que se haya completado un análisis, o bien después de que se hayan instalado todas las actualizaciones aprobadas y aplicables, y se hayan realizado los reinicios necesarios, se genera la información de conformidad de revisiones en una instancia y se notifica al servicio de conformidad de revisiones.
**nota**
Si el parámetro `RebootOption` se establece en `NoReboot` en el documento `AWS-RunPatchBaselineAssociation`, la instancia no se reinicia después de que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).
Para obtener información sobre cómo ver los datos de conformidad de revisiones, consulte [Acerca de la conformidad de parches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaselineAssociation`Parámetros
`AWS-RunPatchBaselineAssociation` admite cinco parámetros. Los parámetros `Operation` y `AssociationId` son obligatorios. Los parámetros `InstallOverrideList`, `RebootOption` y `BaselineTags` son opcionales.
**Topics**
+ [Nombre del parámetro: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Nombre del parámetro: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Nombre del parámetro: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Nombre del parámetro: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### Nombre del parámetro: `Operation`
**Usage**: requerido.
**Opciones**: `Scan` \$1 `Install`.
Examen
Cuando elija la opción `Scan`, `AWS-RunPatchBaselineAssociation` determina el estado de conformidad de las revisiones de la instancia y notifica esta información a Patch Manager. `Scan` no solicita que se instalen actualizaciones ni que se reinicien las instancias. En lugar de ello, la operación identifica las actualizaciones aprobadas que faltan y que son aplicables a la instancia.
Instalación
Al elegir la opción `Install`, `AWS-RunPatchBaselineAssociation` intenta instalar las actualizaciones aprobadas y aplicables que faltan en la instancia. La información de conformidad de revisiones generada como parte de una operación `Install` no muestra las actualizaciones que faltan, pero podría notificar aquellas que presentan un estado de error si la instalación de la actualización no se ha podido realizar por cualquier motivo. Cuando una actualización se instala en una instancia, esta se reinicia para garantizar que la actualización esté instalada y activa. (Excepción: si el parámetro `RebootOption` se establece en `NoReboot` en el documento `AWS-RunPatchBaselineAssociation`, la instancia no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).)
Si se instala una revisión especificado por las reglas de la base de referencia *antes* de que Patch Manager actualice la instancia, es posible que el sistema no se reinicie como es debido. Esto puede ocurrir cuando un usuario instala manualmente una revisión o cuando lo instala automáticamente otro programa, como el `unattended-upgrades` paquete de Ubuntu Server.
### Nombre del parámetro: `BaselineTags`
**Usage**: opcional.
`BaselineTags` es un par de valor de clave de etiqueta único que usted elige y asigna a una línea de base de revisiones personalizada particular. Puede especificar uno o más valores para este parámetro. Los dos formatos que se indican a continuación son válidos:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**importante**
Los valores y las claves de las etiquetas no pueden contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
Patch Manager utiliza el valor `BaselineTags` para garantizar que un conjunto de instancias en las que se aplican revisiones en una sola operación tenga el mismo conjunto de revisiones aprobados. Cuando se ejecuta la operación de aplicación de revisiones, Patch Manager comprueba si una línea de base de revisiones para el tipo de sistema operativo está etiquetada con el mismo par de valor de clave que se especifica para `BaselineTags`. Si hay una concordancia, se utiliza esta línea de base de revisiones personalizada. Si no hay ninguna concordancia, se identifica una línea de base de revisiones en función de cualquier grupo de revisiones especificado para la operación de aplicación de revisiones. En caso de que no haya ninguno, se utiliza la línea de base de revisiones predefinida administrada por AWS para ese sistema operativo.
**Requisitos de permisos adicionales**
Si elige utilizar `AWS-RunPatchBaselineAssociation` en las operaciones de aplicación de revisiones distintas de las configuradas mediante Quick Setup, y desea utilizar el parámetro opcional `BaselineTags`, es necesario que agregue los siguientes permisos al [perfil de instancias](setup-instance-permissions.md) para las instancias de Amazon Elastic Compute Cloud (Amazon EC2).
**nota**
Quick Setup y `AWS-RunPatchBaselineAssociation` no admiten servidores locales ni máquinas virtuales.
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
Sustituya *patch-baseline-arn* por el nombre de recurso de Amazon (ARN) de la línea de base de revisiones al que desea proporcionar acceso, con el formato `arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`.
### Nombre del parámetro: `AssociationId`
**Usage**: requerido.
`AssociationId` es el ID de una asociación existente en State Manager, una herramienta de AWS Systems Manager. Patch Manager lo utiliza para agregar datos de conformidad a la asociación especificada. Esta asociación está relacionada con una operación de revisión `Scan` habilitada en una configuración de [Administración de host creada en Quick Setup](quick-setup-host-management.md) . Con el envío de los resultados de la aplicación de revisiones como datos de conformidad de la asociación en lugar de datos de conformidad de inventario, la información de conformidad de inventario existente para sus instancias ni otros ID de asociación no se sobrescribe luego de una operación de aplicación de revisiones. Si aún no dispone de una asociación que desee utilizar, puede crear una mediante la ejecución del comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html). Por ejemplo:
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-RunPatchBaselineAssociation" \
--association-name "MyPatchHostConfigAssociation" \
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
--parameters "Operation=Scan" \
--schedule-expression "cron(0 */30 * * * ? *)" \
--sync-compliance "MANUAL" \
--region us-east-2
```
------
#### [ Windows Server ]
```
aws ssm create-association ^
--name "AWS-RunPatchBaselineAssociation" ^
--association-name "MyPatchHostConfigAssociation" ^
--targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
--parameters "Operation=Scan" ^
--schedule-expression "cron(0 */30 * * * ? *)" ^
--sync-compliance "MANUAL" ^
--region us-east-2
```
------
### Nombre del parámetro: `InstallOverrideList`
**Usage**: opcional.
Mediante `InstallOverrideList`, se puede especificar una URL de https o una URL de tipo ruta de Amazon Simple Storage Service (Amazon S3) para una lista de revisiones que deben instalarse. Esta lista de instalación de revisiones, que mantiene en formato YAML, invalida las revisiones especificados por la línea de base de revisiones predeterminada actual. De este modo, se le proporcionará un control más detallado sobre qué revisiones se instalan en las instancias.
**importante**
El nombre de archivo `InstallOverrideList` no puede contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
El comportamiento de la operación de revisión cuando se utiliza el parámetro `InstallOverrideList` difiere entre Linux y los nodos administrados por macOS y los nodos administrados por Windows Server. En Linux y macOS, Patch Manager intenta aplicar los parches incluidos en la lista de parches de `InstallOverrideList` que estén presentes en cualquier repositorio habilitado en el nodo, independientemente de que los parches coincidan o no con las reglas de la línea de base de revisiones. Sin embargo, en los nodos Windows Server, los parches de la lista de parches `InstallOverrideList` se aplican *solo* si también cumplen con las reglas de la línea de base de revisiones.
Tenga en cuenta que los informes de conformidad reflejan los estados de revisiones de acuerdo con lo que se especifica en la línea de base de revisiones, no lo que especifique en una lista de revisiones `InstallOverrideList`. En otras palabras, las operaciones de análisis omiten el parámetro `InstallOverrideList`. De este modo, se garantiza que los informes de conformidad reflejen de forma coherente los estados de revisiones de acuerdo con la política, en lugar de lo que se ha aprobado una operación específica para la aplicación de revisiones.
**Formatos de URL válidos**
**nota**
Si su archivo se encuentra almacenado en un bucket de acceso público, puede especificar un formato de URL de https o una URL de tipo ruta de Amazon S3. Si su archivo se encuentra almacenado en un bucket privado, debe especificar una URL de tipo ruta de Amazon S3.
+ **Ejemplo de formato de URL https**:
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Ejemplo de URL de estilo ruta de Amazon S3**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Formatos de contenido YAML válidos**
Los formatos que utiliza para especificar revisiones en su lista dependen del sistema operativo de la instancia. El formato general, sin embargo, es el siguiente:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Aunque puede proporcionar campos adicionales en su archivo YAML, estos se pasan por alto durante las operaciones de revisiones.
Además, le recomendamos que verifique que el formato de su archivo YAML es válido antes de añadir o actualizar la lista de su bucket de S3. Para obtener más información acerca del formato YAML, consulte [yaml.org](http://www.yaml.org). Para consultar las opciones de herramientas de validación, realice una búsqueda web de "validadores de formato yaml".
+ Microsoft Windows
**id**
El campo **id** es obligatorio. Úselo para especificar las revisiones con los ID de la Base de conocimientos de Microsoft (por ejemplo, KB2736693) y del boletín de seguridad de Microsoft (por ejemplo, MS17-023).
Cualquier otro campo que desee proporcionar en una lista de revisiones para Windows es opcional y solo para fines informativos propios. Puede utilizar campos adicionales como, por ejemplo, **title (título)**, **classification (clasificación)**, **severity (gravedad)** o cualquier otro para proporcionar información más detallada sobre las revisiones especificados.
+ Linux
**id**
El campo **id** es obligatorio. Utilícelo para especificar revisiones mediante el nombre del paquete y la arquitectura. Por ejemplo: `'dhclient.x86_64'`. Puede utilizar comodines en id para indicar varios paquetes. Por ejemplo: `'dhcp*'` y `'dhcp*1.*'`.
**título**
El campo **title (título)** es opcional, pero en sistemas Linux ofrece capacidades de filtrado adicionales. Si utiliza **title (título)**, debería contener información de la versión del paquete en uno de los siguientes formatos:
YUM/Red Hat Enterprise Linux (RHEL):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Para los títulos de las revisiones de Linux, puede utilizar uno o varios comodines en cualquier posición para ampliar el número de paquetes coincidentes. Por ejemplo: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Por ejemplo:
+ la versión del paquete apt 1.2.25 actualmente está instalada en la instancia, pero la versión 1.2.27 ya está disponible.
+ Puede añadir la versión apt.amd64 1.2.27 a la lista de revisiones. Depende de la versión apt utils.amd64 1.2.27, pero la versión apt-utils.amd64 1.2.25 se especifica en la lista.
En este caso, la versión apt 1.2.27 se bloqueará a partir de la instalación y se registrará como "Failed-NonCompliant".
**Otros campos**
Cualquier otro campo que desee proporcionar en una lista de revisiones para Linux es opcional y solo para fines informativos propios. Puede utilizar campos adicionales como, por ejemplo, **classification (clasificación)**, **severity (gravedad)** o cualquier otro para proporcionar información más detallada sobre las revisiones especificados.
**Listas de revisiones de ejemplo**
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
+ **APT**
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Amazon Linux 2**
```
patches:
-
id: 'kernel.x86_64'
-
id: 'bind*.x86_64'
title: '39.11.4-26.P2.amzn2.5.2'
id: 'glibc*'
-
id: 'dhclient*'
title: '*4.2.5-58.amzn2'
-
id: 'dhcp*'
title: '*4.2.5-77.amzn2'
```
+ **Red Hat Enterprise Linux (RHEL)**
```
patches:
-
id: 'NetworkManager.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'NetworkManager-*.x86_64'
title: '*1:1.10.2-14.el7_5'
-
id: 'audit.x86_64'
title: '*0:2.8.1-3.el7'
-
id: 'dhclient.x86_64'
title: '*.el7_5.1'
-
id: 'dhcp*.x86_64'
title: '*12:5.2.5-68.el7'
```
+ **SUSE Linux Enterprise Server (SLES)**
```
patches:
-
id: 'amazon-ssm-agent.x86_64'
-
id: 'binutils'
title: '*0:2.26.1-9.12.1'
-
id: 'glibc*.x86_64'
title: '*2.19*'
-
id: 'dhcp*'
title: '0:4.3.3-9.1'
-
id: 'lib*'
```
+ **Ubuntu Server **
```
patches:
-
id: 'apparmor.amd64'
title: '2.10.95-0ubuntu2.9'
-
id: 'cryptsetup.amd64'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'cryptsetup-bin.*'
title: '*2:1.6.6-5ubuntu2.1'
-
id: 'apt.amd64'
title: '*1.2.27'
-
id: 'apt-utils.amd64'
title: '*1.2.25'
```
+ **Windows**
```
patches:
-
id: 'KB4284819'
title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
-
id: 'KB4284833'
-
id: 'KB4284835'
title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
-
id: 'KB4284880'
-
id: 'KB4338814'
```
### Nombre del parámetro: `RebootOption`
**Usage**: opcional.
**Opciones**: `RebootIfNeeded` \$1 `NoReboot`
**Valor predeterminado**: `RebootIfNeeded`
**aviso**
La opción predeterminada es `RebootIfNeeded`. Asegúrese de seleccionar la opción correcta para su caso de uso. Por ejemplo, si las instancias deben reiniciarse inmediatamente para completar un proceso de configuración, elija `RebootIfNeeded`. O bien, si necesita mantener la disponibilidad de las instancias hasta una hora de reinicio programada, elija `NoReboot`.
**importante**
La opción `NoReboot` solo impide los reinicios a nivel del sistema operativo. Los reinicios a nivel de servicio aún pueden producirse como parte del proceso de aplicación de revisiones. Por ejemplo, cuando se actualiza Docker, los servicios dependientes, como Amazon Elastic Container Service, pueden reiniciarse automáticamente incluso con `NoReboot` habilitado. Si tiene servicios críticos que no deben interrumpirse, considere tomar medidas adicionales, como eliminar temporalmente las instancias del servicio o programar la aplicación de revisiones durante los periodos de mantenimiento.
**importante**
No recomendamos el uso de Patch Manager para revisar las instancias de clústeres en Amazon EMR (antes denominado Amazon Elastic MapReduce). En concreto, no seleccione la opción `RebootIfNeeded` para el parámetro `RebootOption`. (Esta opción está disponible en los documentos de SSM Command para implementar revisiones `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation`, y `AWS-RunPatchBaselineWithHooks`).
Los comandos subyacentes para implementar revisiones mediante el uso de Patch Manager y los comandos `yum` y `dnf`. Por lo tanto, las operaciones generan incompatibilidades debido a la forma en que se instalan los paquetes. Para obtener información sobre los métodos preferidos para actualizar el software en los clústeres de Amazon EMR, consulte [Uso de la AMI predeterminada para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) en la *Guía de administración de Amazon EMR*.
RebootIfNeeded
Cuando se elige la opción `RebootIfNeeded`, la instancia se reinicia en cualquiera de los siguientes casos:
+ Patch Manager instaló uno o más revisiones.
Patch Manager no evalúa si la revisión *requiere* llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.
+ Patch Manager detecta uno o más revisiones con un estado de `INSTALLED_PENDING_REBOOT` durante la operación `Install`.
El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación `Install` o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
El reinicio de las instancias en estos dos casos garantiza que los paquetes actualizados se eliminen de la memoria y mantiene un comportamiento de aplicación de revisiones y reinicio consistente en todos los sistemas operativos.
NoReboot
Cuando elige la opción `NoReboot`, Patch Manager no reinicia una instancia aunque haya instalado revisiones durante la operación `Install`. Esta opción es útil si sabe que las instancias no requieren reinicio después de aplicar las revisiones, o si dispone de aplicaciones o procesos que se ejecutan en una instancia que no deberían verse interrumpidos como consecuencia del reinicio de una operación de aplicación de revisiones. También es útil cuando se desea tener más control sobre el tiempo de los reinicios de la instancia, por ejemplo, mediante un periodo de mantenimiento.
**Archivo de seguimiento de instalación de revisiones**: para realizar un seguimiento de la instalación de revisiones, especialmente las revisiones que se hayan instalados desde el último reinicio del sistema, Systems Manager mantiene un archivo en la instancia administrada.
**importante**
No elimine ni modifique el archivo de seguimiento. Si este archivo se elimina o está dañado, el informe de conformidad de revisiones para la instancia es inexacto. Si esto sucede, reinicie la instancia y ejecute una operación de análisis de revisión para restaurar el archivo.
Este archivo de seguimiento se almacena en las siguientes ubicaciones de las instancias administradas:
+ Sistemas operativos Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operativo :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager es compatible con `AWS-RunPatchBaselineWithHooks`, un documento de Systems Manager (documento de SSM) para Patch Manager, una herramienta de AWS Systems Manager. Este documento de SSM realiza operaciones de aplicación de revisiones en los nodos administrados para actualizaciones relacionadas con la seguridad y de otros tipos.
`AWS-RunPatchBaselineWithHooks` se diferencia de `AWS-RunPatchBaseline` en los siguientes aspectos:
+ **Un documento contenedor:** `AWS-RunPatchBaselineWithHooks` es un contenedor de `AWS-RunPatchBaseline` y se basa en `AWS-RunPatchBaseline` para realizar algunas de sus operaciones.
+ **La operación `Install`**: `AWS-RunPatchBaselineWithHooks` admite enlaces de ciclo de vida que se ejecutan en puntos designados durante la aplicación de revisiones en los nodos administrados. Dado que las instalaciones de revisiones en ocasiones requieren que se reinicien los nodos administrados, la operación de aplicación de revisiones se divide en dos eventos, lo que supone un total de tres enlaces que permiten una funcionalidad personalizada. El primer enlace tiene lugar antes de la operación `Install with NoReboot`. El segundo enlace tiene lugar después de la operación `Install with NoReboot`. El tercer enlace está disponible después del reinicio del nodo administrado.
+ **Sin compatibilidad con la lista de parches personalizados:** `AWS-RunPatchBaselineWithHooks` no admite el parámetro `InstallOverrideList`.
+ **Compatibilidad con SSM Agent**: `AWS-RunPatchBaselineWithHooks` requiere que se instale la versión 3.0.502 o una posterior de SSM Agent en el nodo administrado en el que se aplicará la revisión.
Cuando el documento se ejecuta, utiliza la base de referencia de parches que actualmente se encuentra especificada como “predeterminada” para un tipo de sistema operativo en caso de que no se hubiera indicado ningún grupo de parches. En caso contrario, utiliza las bases de referencia de parches que se asocian con el grupo de parches. Para obtener información acerca de los grupos de parches, consulte [Grupos de revisiones](patch-manager-patch-groups.md).
Puede utilizar el documento `AWS-RunPatchBaselineWithHooks` para aplicar revisiones a los sistemas operativos y a las aplicaciones. (En Windows Server, la compatibilidad con las aplicaciones se limita a las actualizaciones de las aplicaciones publicadas por Microsoft).
Este documento es compatible con los nodos administrados de Linux y Windows Server. El documento se encargará de realizar las acciones adecuadas para cada plataforma.
**nota**
`AWS-RunPatchBaselineWithHooks` no es compatible conmacOS.
------
#### [ Linux ]
En nodos administrados de Linux, el documento `AWS-RunPatchBaselineWithHooks` invoca un módulo de Python, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones utiliza las reglas definidas y las listas de revisiones aprobadas y bloqueadas con el fin de impulsar el administrador de paquetes adecuado para cada tipo de nodo:
+ Los nodos administrados de Amazon Linux 2, Oracle Linux y RHEL 7 utilizan YUM. Para las operaciones de YUM, Patch Manager requiere `Python 2.6` o una versión posterior compatible (2.6 a 3.12). Amazon Linux 2023 usa DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12).
+ RHELLos nodos administrados de 8 utilizan DNF. Para las operaciones de DNF, Patch Manager requiere una versión compatible de `Python 2` o `Python 3` (2.6 a 3.12). (Ninguna de las dos versiones viene instalada en RHEL 8 de forma predeterminada. Para ello, deberá instalar una u otra versión manualmente).
+ Las instancias de Debian Server y Ubuntu Server usan APT. Para las operaciones de APT, Patch Manager requiere una versión compatible de `Python 3` (3.0 a 3.12).
------
#### [ Windows Server ]
En nodos administrados de Windows Server, el documento `AWS-RunPatchBaselineWithHooks` descarga e invoca un módulo de PowerShell, que a su vez descarga una instantánea de la línea de base de revisiones que se aplica al nodo administrado. Esta instantánea de la línea de base de revisiones contiene una lista de revisiones aprobadas que se compila al consultar dicha línea de base de revisiones en un servidor de Windows Server Update Services (WSUS). Esta lista se transfiere a la API de Windows Update, que controla la descarga y la instalación de los parches aprobados, según proceda.
------
Cada instantánea se corresponde con una Cuenta de AWS, un grupo de parches, un sistema operativo y un ID de instantánea. La instantánea se entrega a través de una URL prefirmada de Amazon Simple Storage Service (Amazon S3), que se vence transcurridas las 24 horas desde la creación de la instantánea. Sin embargo, si desea aplicar el mismo contenido de la instantánea a otros nodos administrados una vez que la URL se haya vencido, puede generar una nueva dirección de Amazon S3 prefirmada hasta tres días después de la creación de la instantánea. Para ello, utilice el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-deployable-patch-snapshot-for-instance.html).
Cuando se han instalado todas las actualizaciones aprobadas y aplicables, y se han realizado los reinicios necesarios, se genera la información de conformidad de revisiones en un nodo administrado y se notifica a Patch Manager.
Si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaselineWithHooks`, el nodo administrado no se reinicia después de que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
**importante**
Si bien la opción `NoReboot` impide el reinicio del sistema operativo, no impide los reinicios a nivel de servicio que pueden producirse cuando se actualizan determinados paquetes. Por ejemplo, la actualización de paquetes como Docker puede provocar el reinicio automático de los servicios dependientes (como los servicios de orquestación de contenedores) incluso cuando `NoReboot` está especificado.
Para obtener información sobre cómo ver los datos de conformidad de revisiones, consulte [Acerca de la conformidad de parches](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaselineWithHooks`Pasos operativos de
Cuando se ejecuta `AWS-RunPatchBaselineWithHooks`, se llevan a cabo los siguientes pasos:
1. **Análisis**: se ejecuta una operación `Scan` con `AWS-RunPatchBaseline` en el nodo administrado, y, de este modo, se genera y carga un informe de conformidad.
1. **Verificación de los estados del parche local:** se ejecuta un script para determinar los pasos que se llevarán a cabo en función de la operación seleccionada y el resultado de `Scan` del paso 1.
1. Si la operación seleccionada es `Scan`, esta se marcará como completada. La operación finaliza.
1. Si la operación seleccionada es `Install`, Patch Manager evalúa el resultado de `Scan` del paso 1 para determinar qué ejecutar a continuación:
1. Si no se detectan parches faltantes ni se requieren reinicios pendientes, la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. Si no se detectan parches faltantes, pero hay reinicios pendientes, y la opción de reinicio seleccionada es `NoReboot`, la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. De lo contrario, la operación continúa con el siguiente paso.
1. **Operación de enlace previa a la aplicación de revisiones**: el documento de SSM que ha proporcionado para el primer enlace de ciclo de vida, `PreInstallHookDocName`, se ejecuta en el nodo administrado.
1. **Instalación con NoReboot**: se ejecuta una operación `Install` con la opción de reinicio de `NoReboot` mediante `AWS-RunPatchBaseline` en el nodo administrado, y, de este modo, se genera y carga un informe de conformidad.
1. **Operación de enlace posterior a la instalación**: el documento de SSM que ha proporcionado para el segundo enlace de ciclo de vida, `PostInstallHookDocName`, se ejecuta en el nodo administrado.
1. **Verificación del reinicio**: se ejecuta un script para determinar si es necesario reiniciar el nodo administrado y cuáles son los pasos a ejecutar:
1. Si la opción de reinicio seleccionada es `NoReboot`, la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. Si la opción de reinicio seleccionada es `RebootIfNeeded`, Patch Manager verifica que no haya reinicios pendientes necesarios a partir del inventario recopilado en el paso 4. Esto significa que la operación continúa con el paso 7 y el nodo administrado se reinicia en cualquiera de los siguientes casos:
1. Patch Manager instaló una o más revisiones. (Patch Manager no evalúa si la revisión requiere llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.)
1. Patch Manager detecta una o más revisiones con un estado `INSTALLED_PENDING_REBOOT` durante la operación de instalación. El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación de instalación o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
Si no se encuentran revisiones que requieran un reinicio, la operación de aplicación de revisiones en el nodo administrado se completa, de modo que la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios.
1. **Instalación e informe**: se ejecuta una operación de instalación con la opción de reinicio de `RebootIfNeeded` en el nodo administrado mediante `AWS-RunPatchBaseline`, y, de este modo, se genera y carga un informe de conformidad.
1. **Operación de enlace posterior al reinicio**: el documento de SSM que ha proporcionado para el tercer enlace de ciclo de vida, `OnExitHookDocName`, se ejecuta en el nodo administrado.
Para una operación `Scan`, si se produce un error en el paso 1, el proceso de ejecución del documento se detiene y ese paso se notifica como un error, aunque los posteriores se hayan realizado correctamente.
Para una operación `Install`, si se produce un error en alguno de los pasos de `aws:runDocument` durante la operación, esos se notifican como error, de modo que la operación continúa directamente con el último paso (paso 8), que incluye un enlace que usted ha proporcionado. Se omiten los pasos intermedios. Este paso se notifica como error, mientras que el último paso notifica el estado del resultado de su operación, y todos los pasos intermedios se notifican como realizados correctamente.
## `AWS-RunPatchBaselineWithHooks`Parámetros
`AWS-RunPatchBaselineWithHooks` admite seis parámetros.
El parámetro `Operation` es obligatorio.
Los parámetros `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` e `OnExitHookDocName` son opcionales.
`Snapshot-ID` es opcional desde el punto de vista técnico, pero se recomienda que proporcione un valor personalizado cuando ejecute `AWS-RunPatchBaselineWithHooks` fuera de un periodo de mantenimiento. Permita que Patch Manager proporcione el valor automáticamente cuando se ejecute el documento como parte de una operación del periodo de mantenimiento.
**Topics**
+ [Nombre del parámetro: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Nombre del parámetro: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Nombre del parámetro: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Nombre del parámetro: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Nombre del parámetro: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### Nombre del parámetro: `Operation`
**Usage**: requerido.
**Opciones**: `Scan` \$1 `Install`.
Examen
Cuando elige la opción `Scan`, el sistema utiliza el documento `AWS-RunPatchBaseline` para determinar el estado de conformidad de las revisiones del nodo administrado y notifica esta información a Patch Manager. `Scan` no solicita que se instalen actualizaciones ni que se reinicien los nodos administrados. En lugar de ello, la operación identifica las actualizaciones aprobadas que faltan y que son aplicables al nodo.
Instalación
Al elegir la opción `Install`, `AWS-RunPatchBaselineWithHooks` intenta instalar las actualizaciones aprobadas y aplicables que faltan en el nodo administrado. La información de conformidad de revisiones generada como parte de una operación `Install` no muestra las actualizaciones que faltan, pero podría notificar aquellas que presentan un estado de error si la instalación de la actualización no se ha podido realizar por cualquier motivo. Cuando una actualización se instala en un nodo administrado, este se reinicia para garantizar que la actualización esté instalada y activa. (Excepción: si el parámetro `RebootOption` se configura en `NoReboot` en el documento `AWS-RunPatchBaselineWithHooks`, el nodo administrado no se reinicia una vez que se ejecuta Patch Manager. Para obtener más información, consulte [Nombre del parámetro: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)).
Si se instala una revisión especificada por las reglas de la línea de base *antes* de que Patch Manager actualice el nodo administrado, es posible que el sistema no se reinicie como es debido. Esto puede ocurrir cuando un usuario instala manualmente una revisión o cuando la instala automáticamente otro programa, como el `unattended-upgrades` paquete de Ubuntu Server.
### Nombre del parámetro: `Snapshot ID`
**Usage**: opcional.
`Snapshot ID` es un ID exclusivo (GUID) que utiliza Patch Manager para garantizar que un conjunto de nodos administrados en los que se aplican revisiones en una sola operación tenga el mismo conjunto de revisiones aprobadas. Aunque el parámetro se define como opcional, nuestra mejor práctica recomendada depende de si se ejecuta o no `AWS-RunPatchBaselineWithHooks` en un periodo de mantenimiento, tal como se describe en la siguiente tabla.
**`AWS-RunPatchBaselineWithHooks`Prácticas recomendadas de**
| Mode | Práctica recomendada | Details |
| --- | --- | --- |
| Ejecución de AWS-RunPatchBaselineWithHooks dentro de un periodo de mantenimiento | No proporcione un ID de instantánea, sino que Patch Manager lo hará en su lugar. | Si utiliza un periodo de mantenimiento para ejecutar `AWS-RunPatchBaselineWithHooks`, no debe proporcionar su propio ID de instantánea generado. En este caso, Systems Manager proporciona un valor GUID en función del ID de ejecución del periodo de mantenimiento. De este modo, se garantiza que se utilice un ID correcto para todas las invocaciones de `AWS-RunPatchBaselineWithHooks` en dicho periodo de mantenimiento. Si especifica un valor en este caso, tenga en cuenta que la instantánea de la línea de base de revisiones no podría mantenerse durante más de tres días. Después de eso, se generará una nueva instantánea, aunque especifique el mismo ID después de que expire la instantánea. |
| Ejecución de AWS-RunPatchBaselineWithHooks fuera de un periodo de mantenimiento | Genere y especifique un valor GUID personalizado para el ID de instantánea.¹ | Cuando no esté utilizando un periodo de mantenimiento para ejecutar `AWS-RunPatchBaselineWithHooks`, se recomienda generar y especificar un ID de instantánea exclusivo por cada línea de base de revisiones, especialmente si ejecuta el documento `AWS-RunPatchBaselineWithHooks` en varios nodos administrados durante la misma operación. Si no especifica un ID en este caso, Systems Manager genera otro ID de instantánea para cada nodo administrado al que se envía el comando. Esto podría generar diferentes conjuntos de revisiones que se especifican entre los nodos. Por ejemplo, supongamos que se ejecuta el documento `AWS-RunPatchBaselineWithHooks` directamente a través de Run Command, una herramienta de AWS Systems Manager, y selecciona como destino un grupo de 50 nodos administrados. Al especificar un ID de instantánea personalizado, se genera una sola instantánea de la base de referencia que se utiliza para evaluar y aplicar revisiones en todos los nodos administrados, lo que garantiza que tengan un estado coherente. |
| ¹ Puede utilizar cualquier herramienta que genere un GUID con el fin de crear un valor para el parámetro de ID de la instantánea. Por ejemplo, en PowerShell, puede utilizar el cmdlet `New-Guid` para generar un GUID con el formato `12345699-9405-4f69-bc5e-9315aEXAMPLE`. |
### Nombre del parámetro: `RebootOption`
**Usage**: opcional.
**Opciones**: `RebootIfNeeded` \$1 `NoReboot`
**Valor predeterminado**: `RebootIfNeeded`
**aviso**
La opción predeterminada es `RebootIfNeeded`. Asegúrese de seleccionar la opción correcta para su caso de uso. Por ejemplo, si los nodos administrados deben reiniciarse inmediatamente para completar un proceso de configuración, elija `RebootIfNeeded`. O bien, si necesita mantener la disponibilidad de los nodos administrados hasta una hora de reinicio programada, elija `NoReboot`.
**importante**
No recomendamos el uso de Patch Manager para revisar las instancias de clústeres en Amazon EMR (antes denominado Amazon Elastic MapReduce). En concreto, no seleccione la opción `RebootIfNeeded` para el parámetro `RebootOption`. (Esta opción está disponible en los documentos de SSM Command para implementar revisiones `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation`, y `AWS-RunPatchBaselineWithHooks`).
Los comandos subyacentes para implementar revisiones mediante el uso de Patch Manager y los comandos `yum` y `dnf`. Por lo tanto, las operaciones generan incompatibilidades debido a la forma en que se instalan los paquetes. Para obtener información sobre los métodos preferidos para actualizar el software en los clústeres de Amazon EMR, consulte [Uso de la AMI predeterminada para Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) en la *Guía de administración de Amazon EMR*.
RebootIfNeeded
Cuando se elige la opción `RebootIfNeeded`, el nodo administrado se reinicia en cualquiera de los siguientes casos:
+ Patch Manager instaló una o más revisiones.
Patch Manager no evalúa si la revisión *requiere* llevar a cabo un reinicio. El sistema se reinicia aunque la revisión no requiera el reinicio.
+ Patch Manager detecta uno o más revisiones con un estado de `INSTALLED_PENDING_REBOOT` durante la operación `Install`.
El estado `INSTALLED_PENDING_REBOOT` puede indicar que la opción `NoReboot` se seleccionó la última vez que se ejecutó la operación `Install` o que se instaló un parche por fuera de Patch Manager desde la última vez que se reinició el nodo administrado.
El reinicio de los nodos administrados en estos dos casos garantiza que los paquetes actualizados se eliminen de la memoria y mantiene un comportamiento de aplicación de revisiones y reinicio consistente en todos los sistemas operativos.
NoReboot
Cuando elige la opción `NoReboot`, Patch Manager no reinicia un nodo administrado aunque haya instalado revisiones durante la operación `Install`. Esta opción es útil si sabe que los nodos administrados no requieren reinicio después de aplicar las revisiones, o si dispone de aplicaciones o procesos que se ejecutan en un nodo que no deberían verse interrumpidos como consecuencia del reinicio de una operación de aplicación de revisiones. También es útil cuando se desea tener más control sobre el tiempo de los reinicios del nodo administrado, por ejemplo, mediante un periodo de mantenimiento.
Si elige la opción `NoReboot` y se ha instalado una revisión, se asigna a la revisión un estado de `InstalledPendingReboot`. Sin embargo, el nodo administrado en sí mismo está marcado como `Non-Compliant`. Una vez que se produce un reinicio y se ejecuta una operación `Scan`, el estado del nodo se actualiza a `Compliant`.
**Archivo de seguimiento de instalación de revisiones**: para realizar un seguimiento de la instalación de revisiones, especialmente las instaladas desde el último reinicio del sistema, Systems Manager mantiene un archivo en el nodo administrado.
**importante**
No elimine ni modifique el archivo de seguimiento. Si este archivo se elimina o está dañado, el informe de conformidad de revisiones para el nodo administrado es inexacto. Si esto sucede, reinicie el nodo y ejecute una operación de análisis de revisiones para restaurar el archivo.
Este archivo de seguimiento se almacena en las siguientes ubicaciones de los nodos administrados:
+ Sistemas operativos Linux:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows ServerSistema operativo :
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Nombre del parámetro: `PreInstallHookDocName`
**Usage**: opcional.
**Valor predeterminado**: `AWS-Noop`.
El valor que se debe proporcionar para el parámetro `PreInstallHookDocName` es el nombre o el nombre de recurso de Amazon (ARN) de un documento de SSM de su elección. Puede proporcionar el nombre de un documento administrado por AWS o el nombre o ARN de un documento de SSM personalizado que haya creado o que le hayan compartido. (En el caso de un documento de SSM que le hayan compartido desde una Cuenta de AWS diferente, deberá especificar el ARN completo del recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
El documento de SSM que se especifica se ejecuta antes de la operación `Install` y lleva a cabo cualquier acción admitida por SSM Agent, como un script de shell que verifique la comprobación de estado de la aplicación antes de implementar revisiones en el nodo administrado. (Para ver la lista de acciones, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md)). El nombre del documento de SSM predeterminado es `AWS-Noop`, el cual no realiza ninguna operación en el nodo administrado.
Para obtener información acerca de cómo crear un documento de SSM personalizado, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).
### Nombre del parámetro: `PostInstallHookDocName`
**Usage**: opcional.
**Valor predeterminado**: `AWS-Noop`.
El valor que se debe proporcionar para el parámetro `PostInstallHookDocName` es el nombre o el nombre de recurso de Amazon (ARN) de un documento de SSM de su elección. Puede proporcionar el nombre de un documento administrado por AWS o el nombre o ARN de un documento de SSM personalizado que haya creado o que le hayan compartido. (En el caso de un documento de SSM que le hayan compartido desde una Cuenta de AWS diferente, deberá especificar el ARN completo del recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
El documento de SSM que se especifica se ejecuta después de la operación `Install with NoReboot` y realiza cualquier acción admitida por SSM Agent, como un script de shell que permite instalar actualizaciones de terceros antes de proceder al reinicio. (Para ver la lista de acciones, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md)). El nombre del documento de SSM predeterminado es `AWS-Noop`, el cual no realiza ninguna operación en el nodo administrado.
Para obtener información acerca de cómo crear un documento de SSM personalizado, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).
### Nombre del parámetro: `OnExitHookDocName`
**Usage**: opcional.
**Valor predeterminado**: `AWS-Noop`.
El valor que se debe proporcionar para el parámetro `OnExitHookDocName` es el nombre o el nombre de recurso de Amazon (ARN) de un documento de SSM de su elección. Puede proporcionar el nombre de un documento administrado por AWS o el nombre o ARN de un documento de SSM personalizado que haya creado o que le hayan compartido. (En el caso de un documento de SSM que le hayan compartido desde una Cuenta de AWS diferente, deberá especificar el ARN completo del recurso, como `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`).
El documento de SSM que se especifica se ejecuta después de la operación de reinicio del nodo administrado y lleva a cabo cualquier acción admitida por SSM Agent, como un script de shell que compruebe el estado del nodo una vez completada la operación de aplicación de revisiones. (Para ver la lista de acciones, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md)). El nombre del documento de SSM predeterminado es `AWS-Noop`, el cual no realiza ninguna operación en el nodo administrado.
Para obtener información acerca de cómo crear un documento de SSM personalizado, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).
# Ejemplo de escenario para utilizar el parámetro InstallOverrideList en `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation`
Puede utilizar el parámetro `InstallOverrideList` cuando desee anular las revisiones especificadas por la línea de base de revisiones predeterminada actual en Patch Manager, una herramienta de AWS Systems Manager. Este tema proporciona una serie de ejemplos que muestran cómo utilizar este parámetro para obtener los siguientes resultados:
+ Aplique diferentes conjuntos de revisiones a un grupo de nodos administrados de destino.
+ Aplique estos conjuntos de revisiones en diferentes frecuencias.
+ Utilice la misma línea de base de revisiones para ambas operaciones.
Imagine que desea instalar dos categorías de revisiones distintas en los nodos administrados de Amazon Linux 2. Quiere instalar estas revisiones en diferentes programaciones mediante períodos de mantenimiento. Quiere que se ejecute un período de mantenimiento todas las semanas y que instale todas las revisiones de `Security`. Quiere que se ejecute otro período de mantenimiento una vez al mes y que instale todas las revisiones disponibles, o revisiones de categorías distintas a `Security`.
Sin embargo, solo se puede definir una línea de base de revisiones a la vez como la predeterminada de un sistema operativo. Este requisito ayuda a evitar situaciones en las que una línea de base de revisiones aprueba una revisión mientras que otra la bloquea, lo que puede provocar problemas entre versiones en conflicto.
La siguiente estrategia le permite utilizar el parámetro `InstallOverrideList` para aplicar diferentes tipos de revisiones a un grupo de destino, en diferentes programaciones, sin dejar de utilizar la misma línea de base de revisiones.
1. En la línea de base de revisiones predeterminada, asegúrese de que solo se especifican las actualizaciones `Security`.
1. Cree un periodo de mantenimiento que ejecute `AWS-RunPatchBaseline` o `AWS-RunPatchBaselineAssociation` cada semana. No especifique una lista de anulación.
1. Cree una lista de anulación de las revisiones de todos los tipos que desee aplicar mensualmente y almacénela en un bucket de Amazon Simple Storage Service (Amazon S3).
1. Cree un segundo período de mantenimiento que se ejecute una vez al mes. Sin embargo, para la tarea Run Command que registre en este periodo de mantenimiento, especifique la ubicación de su lista de anulación.
El resultado: solo se instalan las revisiones de `Security` semanalmente, tal como se define en su línea de base de revisiones. Todas las revisiones disponibles, o cualquier subconjunto de revisiones que defina, se instalan cada mes.
**nota**
Cuando aplique revisiones a un nodo que solo usa IPv6, asegúrese de que se pueda acceder a la URL proporcionada desde el nodo. Si la opción de configuración `UseDualStackEndpoint` de SSM Agent está establecida en `true`, se utiliza un cliente S3 de pila doble cuando se proporciona una URL de S3. Consulte [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obtener más información sobre cómo configurar el agente para usar la pila doble.
Para obtener más información y muestras, consulte [Nombre del parámetro: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).
# Uso del parámetro BaselineOverride
Puede definir las preferencias de parches en tiempo de ejecución mediante la característica de anulación de base de referencia de parches en Patch Manager, una herramienta de AWS Systems Manager. Para ello, especifique un bucket de Amazon Simple Storage Service (Amazon S3) que contenga un objeto JSON con una lista de bases de referencia de parches. La operación de aplicación de parches utiliza las bases de referencia proporcionadas en el objeto JSON que concuerda con el sistema operativo del host en lugar de aplicar las reglas de la base de referencia de parches predeterminada
**importante**
El nombre de archivo `BaselineOverride` no puede contener los siguientes caracteres: comillas invertidas (`), comillas simples ('), comillas dobles (") ni signos de dólar (\$1).
Salvo cuando una operación de revisión utiliza una política de revisión, el uso del parámetro `BaselineOverride` no sobrescribe la conformidad con la línea de base proporcionada en el parámetro. Los resultados de salida se registran en los registros Stdout de Run Command, una herramienta de AWS Systems Manager. Los resultados solo imprimen los paquetes marcados como `NON_COMPLIANT`. Esto significa que el paquete está marcado como `Missing`, `Failed`, `InstalledRejected`, o `InstalledPendingReboot`.
No obstante, cuando una operación de revisión utiliza una política de revisión, el sistema pasa el parámetro de anulación desde el bucket de S3 asociado y se actualiza el valor de conformidad del nodo administrado. Para obtener más información sobre los comportamientos de las políticas de revisiones, consulte [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md).
**nota**
Cuando aplique revisiones a un nodo que solo usa IPv6, asegúrese de que se pueda acceder a la URL proporcionada desde el nodo. Si la opción de configuración `UseDualStackEndpoint` de SSM Agent está establecida en `true`, se utiliza un cliente S3 de pila doble cuando se proporciona una URL de S3. Consulte [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md) para obtener más información sobre cómo configurar el agente para usar la pila doble.
## Uso de la anulación de la base de referencia de parches con los parámetros de ID de instantánea o de lista de anulación de instalación
Se dan dos casos en los que la anulación de la base de referencia de parches presenta un comportamiento destacable.
**Uso de la anulación de la base de referencia y el ID de la instantánea al mismo tiempo**
Los ID de las instantáneas garantizan que todos los nodos administrados de un determinado comando de aplicación de revisiones apliquen lo mismo. Por ejemplo, si se aplican revisiones a 1000 nodos a la vez, estas serán las mismas.
Cuando se utiliza un ID de instantánea como una anulación de la base de referencia de parches, el ID de instantánea tiene prioridad sobre la anulación de la base de referencia de parches. Las reglas de anulación de la base de referencia se seguirán utilizando, pero solo se evaluarán una vez. En el ejemplo anterior, las revisiones en los 1000 nodos administrados continuarán siendo siempre las mismas. Si a mitad de la operación de aplicación de parches cambió el archivo JSON en el bucket de S3 referenciado para que sea diferente, los parches aplicados seguirán siendo los mismos. Esto se debe a que se proporcionó el ID de la instantánea.
**Uso de la anulación de la base de referencia y de la lista de anulación de la instalación al mismo tiempo**
No se pueden utilizar estos dos parámetros a la vez. El documento de aplicación de revisiones presenta un error si se proporcionan ambos parámetros, y no realiza ningún análisis ni instalación en el nodo administrado.
## Ejemplos de código
En el siguiente ejemplo de código para Python, se muestra cómo generar la anulación de la base de referencia de parches.
```
import boto3
import json
ssm = boto3.client('ssm')
s3 = boto3.resource('s3')
s3_bucket_name = 'my-baseline-override-bucket'
s3_file_name = 'MyBaselineOverride.json'
baseline_ids_to_export = ['pb-0000000000000000', 'pb-0000000000000001']
baseline_overrides = []
for baseline_id in baseline_ids_to_export:
baseline_overrides.append(ssm.get_patch_baseline(
BaselineId=baseline_id
))
json_content = json.dumps(baseline_overrides, indent=4, sort_keys=True, default=str)
s3.Object(bucket_name=s3_bucket_name, key=s3_file_name).put(Body=json_content)
```
De este modo, se obtiene una anulación de la base de referencia de parches como la que se muestra a continuación.
```
[
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 0,
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": false,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "AMAZON_LINUX_2",
"RejectedPatches": [],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
},
{
"ApprovalRules": {
"PatchRules": [
{
"ApproveUntilDate": "2021-01-06",
"ComplianceLevel": "UNSPECIFIED",
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "PRODUCT",
"Values": [
"*"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"*"
]
},
{
"Key": "SEVERITY",
"Values": [
"*"
]
}
]
}
}
]
},
"ApprovedPatches": [
"open-ssl*"
],
"ApprovedPatchesComplianceLevel": "UNSPECIFIED",
"ApprovedPatchesEnableNonSecurity": false,
"GlobalFilters": {
"PatchFilters": []
},
"OperatingSystem": "SUSE",
"RejectedPatches": [
"python*"
],
"RejectedPatchesAction": "ALLOW_AS_DEPENDENCY",
"Sources": []
}
]
```
# líneas de base de revisiones
Los temas de esta sección proporcionan información acerca de cómo funcionan las líneas de base de revisiones en Patch Manager, una herramienta de AWS Systems Manager, cuando ejecuta una operación de `Scan` o `Install` en los nodos administrados.
**Topics**
+ [Líneas de base de revisiones personalizadas y predefinidas](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md)
+ [Grupos de revisiones](patch-manager-patch-groups.md)
+ [Revisiones de aplicaciones publicadas por Microsoft en Windows Server](patch-manager-patching-windows-applications.md)
# Líneas de base de revisiones personalizadas y predefinidas
Patch Manager, una herramienta de AWS Systems Manager, proporciona líneas de base de revisiones predefinidas para todos los sistemas operativos compatibles con Patch Manager. Puede utilizar estas bases de referencia tal como están configuradas actualmente (no puede personalizarlas) o puede crear sus propias líneas de base de revisiones personalizadas. Las líneas de base de revisiones personalizadas le permiten tener un mayor control sobre qué revisiones se aprueban o rechazan en su entorno. Además, las bases de referencia predefinidas asignan un nivel de conformidad de `Unspecified` a todas las revisiones instalados con esas bases de referencia. Para asignar valores de conformidad, puede crear una copia de una base de referencia predefinida y especificar los valores de conformidad que desea asignar a las revisiones. Para obtener más información, consulte [Líneas de base personalizadas](#patch-manager-baselines-custom) y [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md).
**nota**
La información de este tema aplica independientemente del método o tipo de configuración que utilice para sus operaciones de aplicación de revisiones:
Una política de revisiones configurada en Quick Setup
Una opción de administración de host configurada en Quick Setup
Una ventana de mantenimiento para ejecutar una revisión `Scan` o una tarea `Install`
Una operación **Patch Now** (Aplicar revisión ahora) bajo demanda
**Topics**
+ [Líneas de base predefinidas](#patch-manager-baselines-pre-defined)
+ [Líneas de base personalizadas](#patch-manager-baselines-custom)
## Líneas de base predefinidas
En la tabla siguiente se describe cada una de las líneas de base de revisiones predefinidas con Patch Manager.
Para obtener información acerca de qué versiones de cada sistema operativo admite Patch Manager, consulte [Patch ManagerRequisitos previos de](patch-manager-prerequisites.md).
****
| Nombre | Sistemas operativos compatible | Details |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | Aprueba todas las revisiones del sistema operativo que están clasificadas como "Security" y con una gravedad de "Crítica" o "Importante". También aprueba todas las revisiones que están clasificadas como “Bugfix”. Las revisiones se aprueban automáticamente 7 días después de su lanzamiento o actualización.¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | Aprueba todas las revisiones del sistema operativo que están clasificadas como "Security" y con una gravedad de "Crítica" o "Importante". También aprueba todas las revisiones con una clasificación “Bugfix”. Las revisiones se aprueban automáticamente siete días después de su lanzamiento.¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | Aprueba todas las revisiones del sistema operativo que están clasificadas como "Security" y con una gravedad de "Crítica" o "Importante". Las revisiones se aprueban automáticamente siete días después de su publicación. También aprueba todas las revisiones con una clasificación de "Bugfix" siete días después de su publicación. |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | Aprueba todas las actualizaciones siete días después de que estén disponibles (incluidas las actualizaciones que no son de seguridad). |
| AWS-DebianDefaultPatchBaseline | Debian Server | Aprueba inmediatamente todas las revisiones relacionadas con la seguridad del sistema operativo que tienen una prioridad de "Obligatorio", "Importante", "Estándar", "Opcional" o "Extra" No hay ninguna espera antes de la aprobación porque en los repositorios no hay fechas de lanzamiento fiables. |
| AWS-MacOSDefaultPatchBaseline | macOS | Aprueba todas las revisiones del sistema operativo que están clasificadas como “Security” (Seguridad). También aprueba todos los paquetes con una actualización vigente. |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | Aprueba todas las revisiones del sistema operativo que están clasificadas como "Security" y con una gravedad de "Importante" o "Moderada". También aprueba todas las revisiones clasificadas como “Bugfix” siete días después de su lanzamiento. Las revisiones se aprueban automáticamente 7 días después de su lanzamiento o actualización.¹ |
| `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | Aprueba todas las revisiones del sistema operativo que están clasificadas como "Security" y con una gravedad de "Crítica" o "Importante". También aprueba todas las revisiones que están clasificadas como “Bugfix”. Las revisiones se aprueban automáticamente 7 días después de su lanzamiento o actualización.¹ |
| `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | Aprueba todas las revisiones del sistema operativo que están clasificadas como "Security" y con una gravedad de "Crítica" o "Importante". También aprueba todas las revisiones que están clasificadas como “Bugfix”. Las revisiones se aprueban automáticamente 7 días después de su lanzamiento o actualización.¹ |
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | Aprueba todas las revisiones del sistema operativo que están clasificadas como "Security" y con una gravedad "Crítica" o "Importante". Las revisiones se aprueban automáticamente 7 días después de su lanzamiento o actualización.¹ |
| `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | Aprueba inmediatamente todas las revisiones relacionadas con la seguridad del sistema operativo que tienen una prioridad de "Obligatorio", "Importante", "Estándar", "Opcional" o "Extra" No hay ninguna espera antes de la aprobación porque en los repositorios no hay fechas de lanzamiento fiables. |
| AWS-DefaultPatchBaseline | Windows Server | Aprueba todas las revisiones del sistema operativo Windows Server que están clasificados como "CriticalUpdates" o "SecurityUpdates" y que tienen una gravedad de MSRC de "Crítica" o "Importante". Las revisiones se aprueban automáticamente 7 días después de su lanzamiento o actualización.² |
| AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | Aprueba todas las revisiones del sistema operativo Windows Server que están clasificados como "CriticalUpdates" o "SecurityUpdates" y que tienen una gravedad de MSRC de "Crítica" o "Importante". Las revisiones se aprueban automáticamente 7 días después de su lanzamiento o actualización.² |
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Para el sistema operativo Windows Server, aprueba todas las revisiones que están clasificadas como "CriticalUpdates" o "SecurityUpdates" y que tienen una gravedad de MSRC de "Crítica" o "Importante". Para aplicaciones publicadas por Microsoft, aprueba todas las revisiones. Las revisiones para sistemas operativos y aplicaciones se aprueban automáticamente 7 días después de su lanzamiento o actualización.² |
¹ En el caso de Amazon Linux 2, el tiempo de espera de 7 días antes de que las revisiones se aprueben automáticamente se calcula a partir del valor de `Updated Date` en `updateinfo.xml` y no de `Release Date`. Hay varios factores que pueden afectar al valor de `Updated Date`. Otros sistemas operativos administran las fechas de lanzamiento y actualización de forma diferente. Para obtener información que le ayude a evitar resultados inesperados en el tiempo de espera hasta la aprobación automática, consulte [Cómo se calculan las fechas de lanzamiento y actualización de los paquetes](patch-manager-release-dates.md).
² Para Windows Server, las líneas de base predeterminadas incluyen un retraso de 7 días en la aprobación automática. Para instalar una revisión dentro de los 7 días posteriores al lanzamiento, debe crear una línea de base personalizada.
## Líneas de base personalizadas
Utilice la siguiente información para ayudarle a crear líneas de base de revisiones personalizadas para cumplir sus objetivos de aplicación de revisiones.
**Topics**
+ [Cómo utilizar aprobaciones automáticas en líneas de base personalizadas](#baselines-auto-approvals)
+ [Información adicional para crear líneas de base de revisiones](#baseline-additional-info)
### Cómo utilizar aprobaciones automáticas en líneas de base personalizadas
Si crea su propia línea de base de revisiones, puede elegir qué revisiones se aprueban automáticamente mediante las categorías siguientes.
+ **Sistema operativo**: versiones compatibles de Windows Server, Amazon Linux, Ubuntu Server, etcétera.
+ **Nombre de producto** (para sistemas operativos): por ejemplo, RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2, etcétera.
+ **Nombre del producto** (solo para las aplicaciones publicadas por Microsoft que se ejecutan en Windows Server): por ejemplo, Word 2016, BizTalk Server, etc.
+ **Clasificación**: por ejemplo: actualizaciones críticas, actualizaciones de seguridad, etc.
+ **Gravedad**: por ejemplo: crítica, importante, etc.
Para cada regla de aprobación que cree, puede elegir especificar un retraso de aprobación automática o una fecha límite de aprobación de revisiones.
**nota**
Debido a que no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Ubuntu Server, las opciones de aprobación automática no son compatibles con este sistema operativo.
Un tiempo de espera hasta la aprobación automática es el número de días que se debe esperar después de que se haya lanzado o actualizado la revisión y antes de que se apruebe automáticamente su aplicación Por ejemplo, si crea una regla que use la clasificación `CriticalUpdates` y la configura con un tiempo de espera hasta la aprobación automática de siete días, una nueva revisión crítica lanzada el 7 de julio se aprobará automáticamente el 14 de julio.
Si un repositorio de Linux no proporciona información sobre la fecha de publicación de los paquetes, Patch Manager utiliza el tiempo de compilación como la fecha de las especificaciones de aprobación automática para Amazon Linux 2, Amazon Linux 2023 y Red Hat Enterprise Linux (RHEL). Si no se puede determinar el tiempo de compilación del paquete, Patch Manager utiliza una fecha predeterminada del 1 de enero de 1970. Esto resulta en que Patch Manager omita cualquier especificación de fecha de aprobación automática en las líneas base de revisiones que estén configuradas para aprobar revisiones en cualquier fecha posterior al 1 de enero de 1970.
Al especificar una fecha límite de aprobación automática, Patch Manager aplica automáticamente todas las revisiones lanzadas o actualizadas en esa fecha o antes de ella. Por ejemplo, si especifica el 7 de julio de 2023 como fecha límite, no se instalarán automáticamente las revisiones lanzadas o actualizadas por última vez a partir del 8 de julio de 2023.
Cuando crea una línea de base de revisiones personalizada, puede especificar un nivel de gravedad de conformidad para las revisiones aprobadas por esa línea de base de revisiones, como `Critical` o `High`. Si se informa del estado de cualquier revisión aprobada como `Missing`, la gravedad de la conformidad general notificada por la línea de base de revisiones será el nivel de gravedad que haya especificado.
### Información adicional para crear líneas de base de revisiones
Tenga en cuenta lo siguiente cuando cree una línea de base de revisiones:
+ Patch Manager proporciona una línea de base de revisiones predefinida para cada sistema operativo admitido. Estas líneas de base de revisiones predefinidas se utilizan como las líneas de base de revisiones predeterminadas para cada tipo de sistema operativo a menos que cree su propia línea de base de revisiones y la designe como la opción predeterminada para el tipo de sistema operativo correspondiente.
**nota**
Para Windows Server, se proporcionan tres líneas de base de revisiones predefinidas. Las líneas de base de revisiones `AWS-DefaultPatchBaseline` y `AWS-WindowsPredefinedPatchBaseline-OS` solo admiten actualizaciones del sistema operativo en el propio sistema operativo Windows. `AWS-DefaultPatchBaseline` se utiliza como base de referencia de revisiones predeterminada para los nodos administrados de Windows Server, a menos que se especifique una base de referencia distinta. Los ajustes de configuración en estas dos líneas de base de revisiones son los mismos. El más nuevo de los dos, `AWS-WindowsPredefinedPatchBaseline-OS`, se creó para que se diferenciara de la tercera línea de base de revisiones predefinida para Windows Server. Esa línea de base de revisiones, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, puede utilizarse para aplicar revisiones al sistema operativo Windows Server y a las aplicaciones compatibles publicadas por Microsoft.
+ De forma predeterminada, en Windows Server 2019 y Windows Server 2022 se eliminan las actualizaciones que se sustituyen por actualizaciones posteriores. Como resultado, si utiliza el parámetro `ApproveUntilDate` en la línea de base de revisiones de Windows Server, pero la fecha seleccionada en el parámetro `ApproveUntilDate` es anterior a la fecha de la última revisión, la nueva revisión no se instalará cuando se ejecute la operación de revisiones. Para obtener más información sobre la creación de reglas de revisiones en Windows Server, consulte la pestaña Windows Server en [Cómo se seleccionan los parches de seguridad](patch-manager-selecting-patches.md).
Esto significa que el nodo gestionado es compatible con las operaciones de Systems Manager, aunque es posible que no se haya instalado una revisión crítica del mes anterior. Esta misma situación puede ocurrir cuando se utiliza el parámetro `ApproveAfterDays`. Debido al comportamiento de las revisiones sustituidas por Microsoft, es posible establecer un número (generalmente superior a 30 días) para que las revisiones para Windows Server no se instalen nunca si la última revisión disponible de Microsoft se publica antes de que hayan transcurrido los días en `ApproveAfterDays`.
+ Solo en el caso de Windows Server, la revisión de actualización de seguridad disponible que no está aprobada por la línea de base de revisiones puede tener un valor de conformidad de `Compliant` o `Non-Compliant`, tal como se define en una línea de base de revisiones personalizada.
Al crear o actualizar una línea de base de revisiones, usted elige el estado que desee asignar a las revisiones de seguridad que están disponibles pero no aprobadas porque no cumplen con los criterios de instalación especificados en la línea de base de revisiones. Por ejemplo, las revisiones de seguridad que desee instalar se pueden omitir si ha especificado un periodo prolongado de espera después del lanzamiento de la revisión antes de la instalación. Si se publica una actualización de la revisión durante el periodo de espera especificado, el periodo de espera para instalar la revisión vuelve a comenzar. Si el periodo de espera es demasiado extenso, es posible que se lancen varias versiones de la revisión, pero nunca se instalen.
Si utiliza la consola para crear o actualizar una línea de base de revisiones, especifique esta opción en el campo **Estado de cumplimiento de las actualizaciones de seguridad disponibles**. Si utiliza la AWS CLI para ejecutar el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) o [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html), especifique esta opción en el parámetro `available-security-updates-compliance-status`.
+ Para los servidores locales y las máquinas virtuales, Patch Manager intenta utilizar su línea de base de revisiones predeterminada personalizada. Si no existe una línea de base de revisiones predeterminada personalizada, el sistema usa la línea de base de revisiones predefinida para el sistema operativo correspondiente.
+ Si una revisión aparece como aprobado y rechazado en la misma línea de base de revisiones, se rechaza.
+ Un nodo administrado solo puede tener una base de referencia de revisiones definida para él.
+ Los formatos de nombres de paquetes que se pueden agregar a las Listas de revisiones aprobados y rechazados en una línea de base de revisiones dependen del tipo de sistema operativo al que se le apliquen las revisiones.
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
+ Si utiliza una [configuración de política de revisiones](patch-manager-policies.md) en Quick Setup, las actualizaciones que realice en las líneas de base de revisiones personalizadas se sincronizan con Quick Setup cada hora.
Si se elimina una línea de base de revisiones personalizada a la que se hacía referencia en una política de revisiones, aparece un banner en la página **Configuration details** (Detalles de configuración) de Quick Setup correspondiente a la política de revisiones. El banner le informa que la política de revisiones hace referencia a una línea de base de revisiones que ya no existe y que las operaciones de aplicación de revisiones posteriores fallarán. En este caso, vuelva a la página **Configurations** (Configuraciones) de Quick Setup, seleccione la configuración de Patch Manager y elija **Actions** (Acciones), **Edit configuration** (Editar configuración). El nombre de la línea de base de revisiones eliminado aparece resaltado y debe seleccionar una nueva línea de base de revisiones para el sistema operativo afectado.
+ Al crear una regla de aprobación con múltiples valores de `Classification` y `Severity`, los parches se aprueban en función de sus atributos disponibles. Los paquetes con los atributos `Classification` y `Severity` coincidirán con los valores de la línea de base seleccionados para ambos campos. Los paquetes que solo tienen atributos `Classification` solo se comparan con los valores de `Classification` de la línea de base. Los requisitos de gravedad de la misma regla se ignoran en el caso de los paquetes que no tienen atributos `Severity`.
Para obtener más información sobre cómo crear una línea de base de revisiones, consulte [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md) y [Tutorial: implementación de revisiones en un entorno de servidores mediante la AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).
# Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas
Los formatos de nombres de paquetes que se pueden agregar a las listas de parches aprobados y rechazados dependen del tipo de sistema operativo al que se le apliquen los parches.
## Formatos de nombre de paquete para sistemas operativos Linux
Los formatos que puede especificar para parches aprobados y rechazados en su base de referencia de parches varían en función del tipo de Linux. En concreto, los formatos que se admiten dependen del administrador de paquetes utilizados por el tipo de sistema operativo Linux.
**Topics**
+ [Amazon Linux 2, Amazon Linux 2023, Oracle Linux y Red Hat Enterprise Linux (RHEL)](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server y Ubuntu Server](#patch-manager-approved-rejected-package-name-formats-ubuntu)
+ [SUSE Linux Enterprise Server (SLES)](#patch-manager-approved-rejected-package-name-formats-sles)
### Amazon Linux 2, Amazon Linux 2023, Oracle Linux y Red Hat Enterprise Linux (RHEL)
**Administrador de paquetes**: YUM, excepto Amazon Linux 2023 y RHEL 8, que utiliza DNF como administrador de paquetes.
**Parches aprobados**: para este tipo de parches, puede especificar cualquiera de los siguientes elementos:
+ ID de Bugzilla, en el formato `1234567` (el sistema procesa solo números de cadenas como los ID de Bugzilla).
+ ID de CVE con el formato `CVE-2018-1234567`
+ ID de Advisory con formatos como `RHSA-2017:0864` y `ALAS-2018-123`
+ Nombres de paquetes que se crean con uno o varios de los componentes disponibles para la nomenclatura de paquetes. A modo ilustrativo, para el paquete denominado `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, los componentes son los siguientes:
+ `name`: `dbus`
+ `architecture`: `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
Se admiten nombres de paquetes con las siguientes construcciones:
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
Presentamos algunos ejemplos:
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ También se admiten componentes de nombres de paquetes con un único comodín en los formatos anteriores, como los siguientes:
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
**Parches rechazados**: para este tipo de parches, puede especificar cualquiera de los siguientes elementos:
+ Nombres de paquetes que se crean con uno o varios de los componentes disponibles para la nomenclatura de paquetes. A modo ilustrativo, para el paquete denominado `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`, los componentes son los siguientes:
+ `name`: `dbus`
+ `architecture`; `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
Se admiten nombres de paquetes con las siguientes construcciones:
+ `name`
+ `name.arch`
+ `name-version`
+ `name-version-release`
+ `name-version-release.arch`
+ `version`
+ `version-release`
+ `epoch:version-release`
+ `name-epoch:version-release`
+ `name-epoch:version-release.arch`
+ `epoch:name-version-release.arch`
+ `name.arch:epoch:version-release`
Presentamos algunos ejemplos:
+ `dbus.x86_64`
+ `dbus-1.12.28`
+ `dbus-1.12.28-1.amzn2023.0.1`
+ `dbus-1:1.12.28-1.amzn2023.0.1.x86_64`
+ También se admiten componentes de nombres de paquetes con un único comodín en los formatos anteriores, como los siguientes:
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
### Debian Server y Ubuntu Server
**Administrador de paquetes**: APT
**Parches aprobados** y **rechazados**: para estos tipos de parches, especifique lo siguiente:
+ Nombres de paquete en el formato `ExamplePkg33`
**nota**
Para las listas de Debian Server y Ubuntu Server, no incluya elementos como la arquitectura o las versiones. Por ejemplo, especifique el nombre del paquete `ExamplePkg33` para incluir todo lo siguiente en la lista de parches:
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`
### SUSE Linux Enterprise Server (SLES)
**Administrador de paquetes**: Zypper
**Parches aprobados** y **rechazados**: para estos tipos de parches, puede especificar cualquiera de los elementos siguientes:
+ Nombres de paquetes completos, con formatos como:
+ `SUSE-SLE-Example-Package-15-2023-123`
+ `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ Nombres de formatos con un solo comodín, como:
+ `SUSE-SLE-Example-Package-15-2023-*`
+ `example-pkg-2023.15.4-46.17.1.*.rpm`
## Formatos de nombres de paquetes para macOS
**Administradores de paquetes admitidos**: softwareupdate, installer, Brew, Brew Cask
**Parches aprobados** y **parches rechazados**: en las listas de estos tipos de parches, debe especificar los nombres completos de los paquetes en formatos tales como los siguientes:
+ `XProtectPlistConfigData`
+ `MRTConfigData`
No se admiten comodines en las listas de parches aprobados y rechazados para macOS.
## Formatos de nombre de paquete para sistemas operativos Windows
Para sistemas operativos de Windows, especifique los parches con los ID de la Base de conocimientos de Microsoft y del boletín de seguridad de Microsoft; por ejemplo:
```
KB2032276,KB2124261,MS10-048
```
# Grupos de revisiones
**nota**
Los grupos de revisiones no se usan en operaciones de aplicación de revisiones basadas en *políticas de revisiones*. Para obtener información sobre el uso de las políticas de revisiones, consulte [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md).
La consola no admite la funcionalidad de grupos de parches para pares de cuentas y regiones que no usaban grupos de parches antes de que se publicara la compatibilidad con las políticas de parches el 22 de diciembre de 2022. La funcionalidad de grupos de parches sigue estando disponible en los pares de cuentas y regiones que empezaron a usar grupos de parches antes de esta fecha.
Puede utilizar un *grupo de revisiones* para asociar nodos administrados a una línea de base de revisiones específica en Patch Manager, una herramienta de AWS Systems Manager. Los grupos de revisiones ayudan a garantizar que implementará las revisiones adecuadas al conjunto correcto de nodos en función de las reglas de base de referencia de revisiones asociadas. Los grupos de revisiones también pueden ayudarle a evitar la implementación de revisiones antes de que estos se hayan probado suficientemente. Por ejemplo, puede crear grupos de revisiones para diferentes entornos (como desarrollo, prueba y producción) y registrar cada grupo de revisiones en una línea de base de revisiones adecuada.
Cuando ejecuta `AWS-RunPatchBaseline` o cualquier otro documento de comandos SSM para revisiones, puede tomar como objetivo nodos administrados mediante sus ID o etiquetas. Luego, SSM Agent y Patch Manager evalúan qué línea de base de revisiones se utilizará en función del valor del grupo de revisiones que agregó al nodo administrado.
## Uso de etiquetas para definir grupos de revisiones
Puede crear un grupo de revisiones con etiquetas aplicadas a sus instancias de Amazon Elastic Compute Cloud (Amazon EC2) y a nodos que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). Tenga en cuenta los siguientes detalles sobre el uso de etiquetas para los grupos de revisiones:
+
Un grupo de revisiones debe definirse mediante la clave de etiqueta `Patch Group` o `PatchGroup` aplicada a sus nodos administrados. Al registrar un grupo de revisiones para una línea de base de revisiones, cualquier *valor* idéntico especificado para estas dos claves se interpreta como parte del mismo grupo. Por ejemplo, supongamos que etiquetó cinco nodos con el primero de los siguientes pares clave-valor y cinco con el segundo:
+ `key=PatchGroup,value=DEV`
+ `key=Patch Group,value=DEV`
El comando Patch Manager para crear una referencia combina estos 10 nodos administrados en un único grupo en función del valor `DEV`. El equivalente AWS CLI del comando en la creación de una línea de base de revisiones para grupos de parches es el siguiente:
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group DEV
```
La combinación de valores de diferentes claves en un solo objetivo es exclusiva de este comando Patch Manager para crear un nuevo grupo de revisiones y no es compatible con otras acciones de la API. Por ejemplo, si ejecuta acciones [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) con las claves `PatchGroup` y `Patch Group` con los mismos valores, se dirige a dos conjuntos de nodos completamente diferentes:
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:PatchGroup,Values=DEV"
```
```
aws ssm send-command \
--document-name AWS-RunPatchBaseline \
--targets "Key=tag:Patch Group,Values=DEV"
```
+ Existen límites en la segmentación basada en etiquetas. Cada matriz de destinos para `SendCommand` puede contener un máximo de cinco pares clave-valor.
+ Le recomendamos que elija solo una de estas convenciones de claves de etiquetas, ya sea `PatchGroup` (sin espacio) o `Patch Group` (con espacio). Si ha [permitido las etiquetas en los metadatos de las instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), debe usar `PatchGroup`.
+ La clave distingue entre mayúsculas y minúsculas. Puede especificar cualquier *valor* que le ayude a identificar y destinar los recursos de ese grupo, por ejemplo, "servidores web" o "US-EAST-PROD", pero la clave debe ser `Patch Group` o `PatchGroup`.
Después de crear un grupo de revisiones y etiquetar nodos administrados, puede registrar el grupo de revisiones con una base de referencia de revisiones. Registrar el grupo de revisiones en una base de referencia de revisiones garantiza que los nodos del grupo de revisiones utilicen las reglas definidas en la base de referencia de revisiones asociada.
Para obtener más información acerca de cómo crear un grupo de revisiones y asociarlo a una línea de base de revisiones, consulte [Creación y administración de grupos de revisiones](patch-manager-tag-a-patch-group.md) y [Agregar un grupo de revisiones a una línea de base de revisiones](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline).
Para ver un ejemplo de cómo crear una línea de base de revisiones y grupos de revisiones mediante la AWS Command Line Interface (AWS CLI), consulte [Tutorial: implementación de revisiones en un entorno de servidores mediante la AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). Para obtener más información sobre las etiquetas de Amazon EC2, consulte [Etiquetado de los recursos de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) en la *Guía del usuario de Amazon EC2*.
## Funcionamiento
Cuando el sistema ejecuta la tarea para aplicar una base de referencia de revisiones a un nodo administrado, SSM Agent verifica si se ha definido un valor de grupo de revisiones para el nodo. Si se asigna el nodo a un grupo de revisiones, Patch Manager comprueba qué base de referencia de revisiones está registrada en ese grupo. Si se encuentra una línea de base de revisiones para ese grupo, Patch Manager indica a SSM Agent que utilice la línea de base de revisiones asociada. Si un nodo no está configurado para un grupo de revisiones, Patch Manager indica automáticamente a SSM Agent que debe utilizar la base de referencia de revisiones predeterminada que se encuentra configurada en la actualidad.
**importante**
Un nodo administrado solo puede estar en un grupo de revisiones.
Un grupo de revisiones puede registrarse con solo una línea de base de revisiones para cada tipo de sistema operativo.
Puede aplicar la etiqueta `Patch Group` (con un espacio) a una instancia de Amazon EC2 si la opción **Allow tags in instance metadata** (Permitir etiquetas en los metadatos de la instancia) no puede estar habilitada en la instancia. Al permitir etiquetas en los metadatos de la instancia, se impide que los nombres de las claves de las etiquetas contengan espacios. Si tiene [etiquetas permitidas en metadatos de instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), debe usar la clave de etiqueta `PatchGroup` (sin espacio).
**Diagrama 1: ejemplo general de flujo de proceso de operaciones de aplicación de revisiones**
En el siguiente diagrama, se muestra un ejemplo general de los procesos que Systems Manager lleva a cabo al enviar una tarea de Run Command a la flota de servidores a la que se aplicarán revisiones mediante Patch Manager. Estos procesos determinan qué líneas de base de revisiones que se deben usar en las operaciones de aplicación de revisiones. (Se emplea un proceso similar cuando se ha configurado un periodo de mantenimiento para enviar un comando que aplique revisiones mediante Patch Manager.
El proceso completo se explica debajo de la ilustración.
![\[Flujo de trabajo de Patch Manager para determinar qué líneas de base de revisiones se deben usar cuando se realizan operaciones de aplicación de revisiones.\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)
En este ejemplo, tenemos tres grupos de instancias EC2 de Windows Server con las siguientes etiquetas aplicadas:
****
| Grupo de instancias EC2 | Etiquetas |
| --- | --- |
| Grupo 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` |
| Grupo 2 | `key=OS,value=Windows` |
| Grupo 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` |
En este ejemplo, también tenemos estas dos líneas de base de revisiones de Windows Server:
****
| ID de línea de base de revisiones | Predeterminado/a | Grupo de revisiones asociado |
| --- | --- | --- |
| `pb-0123456789abcdef0` | Sí | `Default` |
| `pb-9876543210abcdef0` | No | `DEV` |
El proceso general de análisis o instalación de revisiones mediante Run Command, una herramienta de AWS Systems Manager, y Patch Manager es como se indica a continuación:
1. **Envío de un comando para aplicar revisiones**: utilice la consola de Systems Manager, el SDK, la AWS Command Line Interface (AWS CLI) o AWS Tools for Windows PowerShell para enviar una tarea de Run Command mediante el documento `AWS-RunPatchBaseline`. En el diagrama se muestra una tarea de Run Command para aplicar revisiones a instancias administradas al tomar como objetivo la etiqueta `key=OS,value=Windows`.
1. **Determinación de la línea de base de revisiones**: SSM Agent verifica las etiquetas de grupos de revisiones que se aplican a la instancia de EC2 y consulta a Patch Manager la línea de base de revisiones correspondiente.
+ **Coincidencia del valor de un grupo de revisiones asociado con una línea de base de revisiones:**
1. SSM Agent, que está instalado en instancias EC2 en el grupo uno, recibe el comando ejecutado en el paso 1 para empezar una operación de aplicación de revisiones. SSM Agent valida que las instancias EC2 tengan el valor de etiqueta `DEV` del grupo de revisiones aplicado y consulta a Patch Manager una línea de base de revisiones asociada.
1. Patch Manager verifica que la línea de base de revisiones `pb-9876543210abcdef0` tenga el grupo de revisiones `DEV` asociado y se lo notifica a SSM Agent.
1. SSM Agent recupera una instantánea de la línea de base de revisiones desde Patch Manager en función de las reglas de aprobación y las excepciones configuradas en `pb-9876543210abcdef0` y avanza al siguiente paso.
+ **La instancia no tiene una etiqueta de grupo de revisiones añadida:**
1. SSM Agent, que está instalado en instancias de EC2 en el grupo dos, recibe el comando ejecutado en el paso 1 para empezar una operación de aplicación de revisiones. SSM Agent valida que las instancias EC2 no tengan una etiqueta `Patch Group` o `PatchGroup` aplicada y, en consecuencia, SSM Agent consulta a Patch Manager la línea de base de revisiones de Windows predeterminada.
1. Patch Manager verifica que la línea de base de revisiones de Windows Server predeterminada sea `pb-0123456789abcdef0` y se lo notifica a SSM Agent.
1. SSM Agent recupera una instantánea de la línea de base de revisiones desde Patch Manager en función de las reglas de aprobación y las excepciones configuradas en la línea de base de revisiones predeterminada `pb-0123456789abcdef0` y avanza al siguiente paso.
+ **La línea de base de revisiones no tiene un valor de grupo de revisiones coincidente asociado:**
1. SSM Agent, que está instalado en instancias EC2 en el grupo tres, recibe el comando ejecutado en el paso 1 para empezar una operación de aplicación de revisiones. SSM Agent valida que las instancias EC2 tengan el valor de etiqueta `QA` del grupo de revisiones aplicado y consulta a Patch Manager una línea de base de revisiones asociada.
1. Patch Manager no encuentra una línea de base de revisiones que tenga el grupo de revisiones `QA` asociado.
1. Patch Manager indica a SSM Agent que debe usar la línea de base de revisiones de Windows predeterminada `pb-0123456789abcdef0`.
1. SSM Agent recupera una instantánea de la línea de base de revisiones desde Patch Manager en función de las reglas de aprobación y las excepciones configuradas en la línea de base de revisiones predeterminada `pb-0123456789abcdef0` y avanza al siguiente paso.
1. **Análisis de detección de revisiones o instalación de revisiones**: después de determinar la línea de base de revisiones adecuada que se va a utilizar, SSM Agent comienza el análisis de detección de revisiones o la instalación de revisiones en función del valor de operación especificado en el paso 1. las revisiones que se analizan o se instalan se determinan a partir de las reglas de aprobación y las excepciones de revisiones que están definidas en la instantánea de la línea de base de revisiones que Patch Manager proporciona.
**Más información**
+ [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md)
# Revisiones de aplicaciones publicadas por Microsoft en Windows Server
Utilice la información de este tema para prepararse para aplicar revisiones a las aplicaciones en Windows Server mediante Patch Manager, una herramienta de AWS Systems Manager.
**Uso de parches en aplicaciones de Microsoft**
La compatibilidad con el uso de revisiones para las aplicaciones en los nodos administrados por Windows Server se limita a las aplicaciones publicadas por Microsoft.
**nota**
En algunos casos, Microsoft lanza parches para las aplicaciones que no especifican una hora ni una fecha de actualización. En estos casos, se suministra una fecha y hora actualizadas de `01/01/1970` de forma predeterminada.
**Bases de referencia de parches para usar parches en las aplicaciones publicadas por Microsoft**
Para Windows Server, se proporcionan tres líneas de base de revisiones predefinidas. Las líneas de base de revisiones `AWS-DefaultPatchBaseline` y `AWS-WindowsPredefinedPatchBaseline-OS` solo admiten actualizaciones del sistema operativo en el propio sistema operativo Windows. `AWS-DefaultPatchBaseline` se utiliza como base de referencia de revisiones predeterminada para los nodos administrados de Windows Server, a menos que se especifique una base de referencia distinta. Los ajustes de configuración en estas dos líneas de base de revisiones son los mismos. El más nuevo de los dos, `AWS-WindowsPredefinedPatchBaseline-OS`, se creó para que se diferenciara de la tercera línea de base de revisiones predefinida para Windows Server. Esa base de referencia de parches, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, puede utilizarse para aplicar parches al sistema operativo Windows Server y a las aplicaciones compatibles publicadas por Microsoft.
También puede crear una base de referencia de parches personalizada para actualizar aplicaciones publicadas por Microsoft en máquinas de Windows Server.
**Compatibilidad con la aplicación de revisiones en aplicaciones lanzadas por Microsoft en servidores en las instalaciones, dispositivos periféricos, máquinas virtuales y otros nodos que no sean de EC2**
Para revisar las aplicaciones lanzadas por Microsoft en máquinas virtuales (VM) y nodos administrados que no son de EC2, es necesario que active el nivel de instancias avanzadas. El uso del nivel de instancias avanzadas conlleva un cargo. **Sin embargo, no hay ningún cargo adicional por usar revisiones en las aplicaciones lanzadas por Microsoft en instancias de Amazon Elastic Compute Cloud (Amazon EC2).** Para obtener más información, consulte [Configuración de los niveles de instancias](fleet-manager-configure-instance-tiers.md).
**Opción de actualización de Windows para “otros productos de Microsoft”**
Para que Patch Manager pueda usar revisiones en las aplicaciones publicadas por Microsoft en los nodos administrados por Windows Server, se debe activar la opción de Windows Update **Give me updates for other Microsoft products when I update Windows** (Ofrecerme actualizaciones para otros productos de Microsoft cuando actualice Windows) en el nodo administrado.
Para obtener información acerca de cómo permitir esta opción en un único nodo administrado, consulte [Actualización de Office con Microsoft Update](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) en el sitio web de soporte técnico de Microsoft.
En el caso de una flota de nodos administrados que ejecuten la versión de Windows Server 2016 y posteriores, puede utilizar un objeto de política de grupo (GPO) para activar la configuración. En el editor de administración de políticas de grupo, vaya a **Computer Configuration** (Configuración del equipo), **Administrative Templates** (Plantillas administrativas), **Windows Components** (Componentes de Windows), **Windows Updates** (Actualizaciones de Windows) y, a continuación, elija **Install updates for other Microsoft products** (Instalar actualizaciones para otros productos de Microsoft). También se recomienda configurar el GPO con parámetros adicionales que impidan las actualizaciones automáticas no planificadas y los reinicios fuera de Patch Manager. Para obtener más información, consulte [Configuring Automatic Updates in a Non-Active Directory Environment](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499) (Configuración de actualizaciones automáticas en un entorno que no es de Active Directory) en el sitio web de documentación técnica de Microsoft.
En el caso de una flota de nodos administrados que ejecuten la versión de Windows Server 2012 o 2012 R2, puede activar la opción mediante un script, según se describe en [Habilitar y desactivar Microsoft Update en Windows 7 mediante Script](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script) en el sitio web del blog de Microsoft Docs. Por ejemplo, podría hacer lo siguiente:
1. Guarde el script de la publicación de blog en un archivo.
1. Cargue el archivo en un bucket de Amazon Simple Storage Service (Amazon S3) o en otra ubicación accesible.
1. Utilice Run Command, una herramienta de AWS Systems Manager, para ejecutar el script en los nodos administrados mediante el documento de Systems Manager (documento de SSM) `AWS-RunPowerShellScript` con un comando similar al siguiente.
```
Invoke-WebRequest `
-Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
-Outfile "C:\script.vbs" cscript c:\script.vbs
```
**Requisitos mínimos de los parámetros**
Para incluir aplicaciones publicadas por Microsoft en su base de referencia de parches personalizada, debe, como mínimo, especificar el producto al que desea aplicar parches. El siguiente comando de la AWS Command Line Interface (AWS CLI) muestra los requisitos mínimos para aplicar parches a un producto como, Microsoft Office 2016.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT,Values='Office 2016'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
Si especifica la familia de productos de aplicaciones de Microsoft, cada producto que especifique debe ser un miembro compatible de la familia de productos seleccionados. Por ejemplo, para aplicar parches al producto "Active Directory Rights Management Services Client 2.0", debe especificar su familia de productos como "Active Directory" y no, por ejemplo, "Office" ni "SQL Server". En el siguiente comando de la AWS CLI, se muestra un correcto emparejamiento de familia de productos y producto.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "My-Windows-App-Baseline" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "My-Windows-App-Baseline" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=PRODUCT_FAMILY,Values='Active Directory'},{Key=PRODUCT,Values='Active Directory Rights Management Services Client 2.0'},{Key=PATCH_SET,Values='APPLICATION'}]},ApproveAfterDays=5}]"
```
------
**nota**
Si recibe un mensaje de error sobre un emparejamiento de producto y familia incorrecto, consulte [Asunto: pares de familia de productos y productos no coincidentes](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch) para obtener asistencia sobre cómo solucionar el problema.
# Uso de Kernel Live Patching en nodos administrados de Amazon Linux 2
Kernel Live Patching para Amazon Linux 2 le permite aplicar revisiones de vulnerabilidad de seguridad y de errores críticos a un kernel de Linux en ejecución, sin reinicios ni interrupciones en las aplicaciones en ejecución. Esto le permite beneficiarse de una mejor disponibilidad de servicios y aplicaciones, a la vez que mantiene su infraestructura segura y actualizada. Kernel Live Patching se admite en instancias de Amazon EC2, dispositivos de núcleo de AWS IoT Greengrass y [máquinas virtuales locales](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html) que ejecutan Amazon Linux 2.
Para obtener información general sobre Kernel Live Patching, consulte [Kernel Live Patching on AL2](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html) en la *Guía del usuario de Amazon Linux 2*.
Después de activar Kernel Live Patching en un nodo administrado de Amazon Linux 2, puede utilizar Patch Manager, una herramienta de AWS Systems Manager, para aplicar revisiones en caliente del kernel al nodo administrado. El uso de Patch Manager es una alternativa al uso de los flujos de trabajo yum existentes en el nodo para aplicar las actualizaciones.
**Antes de empezar**
Para utilizar Patch Manager para aplicar revisiones en caliente del kernel a los nodos administrados de Amazon Linux 2, asegúrese de que los nodos se basan en la arquitectura y la versión del kernel correctas. Para obtener información, consulte [Configuraciones admitidas y requisitos previos](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) en la *Guía del usuario de Amazon EC2*.
**Topics**
+ [Kernel Live Patching mediante Patch Manager](#about-klp)
+ [Cómo funciona Kernel Live Patching mediante Patch Manager](#how-klp-works)
+ [Activación de Kernel Live Patching con Run Command](enable-klp.md)
+ [Aplicación de actualizaciones en caliente del kernel mediante Run Command](install-klp.md)
+ [Desactivación de Kernel Live Patching con Run Command](disable-klp.md)
## Kernel Live Patching mediante Patch Manager
Actualización de la versión del kernel
No es necesario reiniciar un nodo administrado después de aplicar una revisión en caliente del kernel. Sin embargo, AWS proporciona revisiones en caliente del kernel para una versión del kernel de Amazon Linux 2 durante un máximo de tres meses después de su lanzamiento. Después del período de tres meses, debe actualizar a una versión posterior del kernel para continuar recibiendo actualizaciones en caliente de kernel. Recomendamos utilizar un periodo de mantenimiento para programar un reinicio del nodo al menos una vez cada tres meses para solicitar la actualización de la versión del kernel.
Desinstalación de actualizaciones en caliente del kernel
las revisiones en caliente del kernel no se pueden desinstalar mediante Patch Manager. En su lugar, puede deshabilitar Kernel Live Patching, lo que elimina los paquetes RPM de las revisiones en caliente del kernel aplicados. Para obtener más información, consulte [Desactivación de Kernel Live Patching con Run Command](disable-klp.md).
Conformidad del kernel
En algunos casos, la instalación de todas las correcciones de CVE desde actualizaciones en caliente para la versión actual del kernel puede llevar ese kernel al mismo estado de conformidad que tendría una versión más reciente del kernel. Cuando eso sucede, la versión más reciente se notifica como `Installed`, y el nodo administrado se informa como `Compliant`. Sin embargo, no se informa de tiempo de instalación para la versión más reciente del kernel.
Una actualización en caliente del kernel, varias CVE
Si una actualización en caliente del kernel se dirige a varias CVE, y esas CVE tienen varios valores de clasificación y gravedad, solo se informará de la clasificación y gravedad más altas de entre las CVE para la revisión.
En el resto de esta sección, se describe cómo utilizar Patch Manager para aplicar revisiones en caliente del kernel a los nodos administrados que cumplan estos requisitos.
## Cómo funciona Kernel Live Patching mediante Patch Manager
AWS lanza dos tipos de revisiones en caliente del kernel para Amazon Linux 2: actualizaciones de seguridad y correcciones de errores. Para aplicar estos tipos de revisiones, se utiliza un documento de línea de base de revisiones que se centra únicamente en las clasificaciones y gravedades enumeradas en la siguiente tabla.
| Clasificación | Gravedad |
| --- | --- |
| Security | Critical, Important |
| Bugfix | All |
Puede crear una línea de base de revisiones personalizada que se orienta únicamente a estos revisiones, o utilizar la línea de base de revisiones predefinida de `AWS-AmazonLinux2DefaultPatchBaseline`. En otras palabras, puede utilizar `AWS-AmazonLinux2DefaultPatchBaseline` con nodos administrados de Amazon Linux 2 en los que Kernel Live Patching está habilitado, y las revisiones en caliente del kernel se aplicarán.
**nota**
La configuración de `AWS-AmazonLinux2DefaultPatchBaseline` especifica un periodo de espera de siete días después del lanzamiento o última actualización de una revisión antes de que se instale automáticamente. Si no desea esperar ese plazo para que se aprueben automáticamente las revisiones en caliente del kernel, puede crear y utilizar una línea de base de revisiones personalizada. En la línea de base de revisiones, puede especificar que no haya ningún periodo de espera para la aprobación automática, o bien puede especificar uno más corto o más largo. Para obtener más información, consulte [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md).
Recomendamos la siguiente estrategia para aplicar revisiones a los nodos administrados con actualizaciones en vivo del kernel:
1. Active Kernel Live Patching en los nodos administrados de Amazon Linux 2.
1. Utilice Run Command, una herramienta de AWS Systems Manager, para ejecutar una operación `Scan` en los nodos administrados mediante la `AWS-AmazonLinux2DefaultPatchBaseline` predefinida o una línea de base de revisiones personalizada que también tiene como objetivo solo las actualizaciones de `Security` con gravedad clasificada como `Critical` o `Important` y la gravedad `Bugfix` de `All`.
1. Utilice Cumplimiento, una herramienta de AWS Systems Manager, con el fin de revisar si se notifica la falta de conformidad para la aplicación de revisiones en cualquiera de los nodos administrados que se analizaron. Si es así, consulte los detalles de conformidad del nodo para determinar si faltan actualizaciones en caliente del kernel en el nodo administrado.
1. Para instalar las actualizaciones en caliente del kernel que faltan, use Run Command con la misma línea de base de revisiones que especificó antes, pero esta vez ejecute una operación `Install` en lugar de una operación `Scan`.
Debido a que las revisiones en vivo del kernel se instalan sin necesidad de reiniciar, puede elegir la opción de reinicio `NoReboot` para esta operación.
**nota**
Todavía puede reiniciar el nodo administrado si es necesario para otros tipos de revisiones instaladas en el nodo, o si desea actualizar a un kernel más reciente. En estos casos, elija la opción de reinicio `RebootIfNeeded` en su lugar.
1. Vuelva a Compliance para verificar que se instalaron las actualizaciones en caliente del kernel.
# Activación de Kernel Live Patching con Run Command
Para activar Kernel Live Patching, puede ejecutar comandos `yum` en los nodos administrados o utilizar Run Command y un documento de Systems Manager personalizado (documento de SSM) que cree.
Para obtener información sobre cómo activar Kernel Live Patching mediante la ejecución de comandos `yum` directamente en el nodo administrado, consulte [Habilitación de Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) en la *Guía del usuario de Amazon EC2*.
**nota**
Cuando se activa Kernel Live Patching, el proceso instala la versión más reciente del kernel disponible y reinicia el nodo administrado si el kernel que se esté ejecutando en el nodo administrado es una versión *anterior* a la versión `kernel-4.14.165-131.185.amzn2.x86_64` (la versión mínima admitida). Si el nodo ya está ejecutando la versión `kernel-4.14.165-131.185.amzn2.x86_64` o posterior, el proceso no instala una versión más reciente ni reinicia el nodo.
**Para activar Kernel Live Patching con Run Command (consola)**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Run Command**.
1. Elija **Run command (Ejecutar comando)**.
1. En la lista **Command document** (Documento de Command), elija el documento de SSM `AWS-ConfigureKernelLivePatching` personalizado.
1. En la sección **Command parameters** (Parámetros de comandos) especifique si desea que los nodos administrados se reinicien como parte de esta operación.
1. Para obtener información sobre cómo trabajar con los controles restantes de esta página, consulte [Ejecución de comandos desde la consola](running-commands-console.md).
1. Seleccione **Ejecutar**.
**Para activar Kernel Live Patching (AWS CLI)**
+ Ejecute el siguiente comando en el equipo local.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--parameters "EnableOrDisable=Enable" \
--targets "Key=instanceids,Values=instance-id"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--parameters "EnableOrDisable=Enable" ^
--targets "Key=instanceids,Values=instance-id"
```
------
Sustituya *instance-id* por el ID del nodo administrado de Amazon Linux 2 en el que desea activar la característica, como i-02573cafcfEXAMPLE. Para activar la característica en varios nodos administrados, puede utilizar cualquiera de los siguientes formatos.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Para obtener información acerca de otras opciones que puede utilizar con el comando, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) en la *Referencia de comandos de la AWS CLI*.
# Aplicación de actualizaciones en caliente del kernel mediante Run Command
Para aplicar revisiones en caliente del kernel, puede ejecutar comandos `yum` en los nodos administrados o utilizar Run Command y el documento de SSM `AWS-RunPatchBaseline`.
Para obtener información sobre cómo aplicar revisiones activas del kernel mediante la ejecución de comandos `yum` directamente en el nodo administrado, consulte [Aplicación de revisiones activas del kernel](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply) en la *Guía del usuario de Amazon EC2*.
**Para aplicar actualizaciones en caliente del kernel mediante Run Command (consola)**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Run Command**.
1. Elija **Run command (Ejecutar comando)**.
1. En la lista **Command document** (Documento de Command), elija el documento de SSM `AWS-RunPatchBaseline`.
1. En la sección **Command parameters (Parámetros de comandos)** realice una de las acciones siguientes:
+ Si está verificando si hay nuevos revisiones en caliente del kernel disponibles, en **Operation** (Operación), elija `Scan`. En **Reboot Option** (Opción de reinicio), elija `NoReboot` si no desea que los nodos administrados se reinicien después de esta operación. Una vez completada la operación, puede verificar si hay nuevos revisiones y el estado de conformidad en Compliance.
+ Si ya ha comprobado la conformidad de las revisiones y está listo para aplicar las actualizaciones en caliente del kernel disponibles, en **Operation (Operación)**, elija `Install`. En **Reboot Option** (Opción de reinicio), elija `NoReboot` si no desea que los nodos administrados se reinicien después de esta operación.
1. Para obtener información sobre cómo trabajar con los controles restantes de esta página, consulte [Ejecución de comandos desde la consola](running-commands-console.md).
1. Seleccione **Ejecutar**.
**Para aplicar actualizaciones en caliente del kernel mediante Run Command (AWS CLI)**
1. Para realizar una operación `Scan` antes de verificar sus resultados en Compliance, ejecute el siguiente comando desde su equipo local.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Scan"],"RebootOption":["RebootIfNeeded"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Scan\"],\"RebootOption\":[\"RebootIfNeeded\"]}
```
------
Para obtener información acerca de otras opciones que puede utilizar con el comando, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) en la *Referencia de comandos de la AWS CLI*.
1. Para realizar una operación `Install` después de verificar los resultados en Compliance, ejecute el siguiente comando desde el equipo local.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunPatchBaseline" \
--targets "Key=InstanceIds,Values=instance-id" \
--parameters '{"Operation":["Install"],"RebootOption":["NoReboot"]}'
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--parameters {\"Operation\":[\"Install\"],\"RebootOption\":[\"NoReboot\"]}
```
------
En los dos comandos anteriores, reemplace *instance-id* por el ID del nodo administrado de Amazon Linux 2 en el que desea aplicar revisiones en caliente del kernel, como i-02573cafcfEXAMPLE. Para activar la característica en varios nodos administrados, puede utilizar cualquiera de los siguientes formatos.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Para obtener información sobre otras opciones que puede utilizar con estos comandos, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) en la *Referencia de comandos de la AWS CLI*.
# Desactivación de Kernel Live Patching con Run Command
Para desactivar Kernel Live Patching, puede ejecutar comandos `yum` en los nodos administrados o utilizar Run Command y un documento de SSM `AWS-ConfigureKernelLivePatching` personalizado.
**nota**
Si ya no necesita utilizar Kernel Live Patching, puede desactivarlo en cualquier momento. En la mayoría de los casos, no es necesario desactivar la característica.
Para obtener información sobre cómo desactivar Kernel Live Patching mediante la ejecución de comandos `yum` directamente en el nodo administrado, consulte [Habilitación de Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable) en la *Guía del usuario de Amazon EC2*.
**nota**
Cuando desactiva Kernel Live Patching, el proceso desinstala el complemento de Kernel Live Patching y, a continuación, reinicia el nodo administrado.
**Para desactivar Kernel Live Patching con Run Command (consola)**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Run Command**.
1. Elija **Run command (Ejecutar comando)**.
1. En la lista **Command document** (Documento de Command), elija el documento de SSM `AWS-ConfigureKernelLivePatching`.
1. En la sección **Command Parameters**, especifique los valores de los parámetros obligatorios.
1. Para obtener información sobre cómo trabajar con los controles restantes de esta página, consulte [Ejecución de comandos desde la consola](running-commands-console.md).
1. Seleccione **Ejecutar**.
**Para desactivar Kernel Live Patching(AWS CLI)**
+ Ejecute un comando similar al siguiente:
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-ConfigureKernelLivePatching" \
--targets "Key=instanceIds,Values=instance-id" \
--parameters "EnableOrDisable=Disable"
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-ConfigureKernelLivePatching" ^
--targets "Key=instanceIds,Values=instance-id" ^
--parameters "EnableOrDisable=Disable"
```
------
Sustituya *instance-id* por el ID del nodo administrado de Amazon Linux 2 en el que desea desactivar la característica, como i-02573cafcfEXAMPLE. Para desactivar la característica en varios nodos administrados, puede utilizar cualquiera de los siguientes formatos.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Para obtener información acerca de otras opciones que puede utilizar con el comando, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) en la *Referencia de comandos de la AWS CLI*.
# Trabajo con los recursos Patch Manager y el cumplimiento mediante la consola
Para usar Patch Manager, una herramienta de AWS Systems Manager, complete las siguientes tareas. Estas tareas se describen con más detalle en esta sección.
1. Compruebe que la línea de base de revisiones predefinida de AWS para cada tipo de sistema operativo que utiliza seas adecuada para sus necesidades. Si no es así, cree una base de referencia de revisiones que defina un conjunto estándar de revisiones para dicho tipo de nodo administrado y establézcalo como la opción predeterminada.
1. Organice los nodos administrados en grupos de revisiones mediante etiquetas de Amazon Elastic Compute Cloud (Amazon EC2) (opcional, pero recomendado).
1. Realice una de las siguientes acciones:
+ (Recomendado) Configure una política de revisiones en Quick Setup, una herramienta de Systems Manager, que le permita instalar revisiones faltantes en una programación para una organización completa, un subconjunto de unidades organizacionales o una sola Cuenta de AWS. Para obtener más información, consulte [Cómo configurar las revisiones para las instancias de una organización mediante una política de parches Quick Setup](quick-setup-patch-manager.md).
+ Cree un periodo de mantenimiento que utilice el documento de Systems Manager (documento de SSM) `AWS-RunPatchBaseline` en un tipo de tarea de Run Command. Para obtener más información, consulte [Tutorial: creación de un periodo de mantenimiento para la aplicación de revisiones mediante la consola](maintenance-window-tutorial-patching.md).
+ Ejecute manualmente `AWS-RunPatchBaseline` en una operación Run Command. Para obtener más información, consulte [Ejecución de comandos desde la consola](running-commands-console.md).
+ Aplique revisiones manualmente a los nodos bajo demanda con la función **Patch now** (Aplicar revisión ahora). Para obtener más información, consulte [Aplicación de revisiones a nodos administrados bajo demanda](patch-manager-patch-now-on-demand.md).
1. Monitorice la aplicación de revisiones para verificar la conformidad e investigar los errores.
**Topics**
+ [Cómo crear una política de revisiones](patch-manager-create-a-patch-policy.md)
+ [Visualización de resúmenes del panel de revisiones](patch-manager-view-dashboard-summaries.md)
+ [Trabajo con informes de conformidad de las revisiones](patch-manager-compliance-reports.md)
+ [Aplicación de revisiones a nodos administrados bajo demanda](patch-manager-patch-now-on-demand.md)
+ [Trabajo con línea de base de revisiones](patch-manager-create-a-patch-baseline.md)
+ [Visualización de parches disponibles](patch-manager-view-available-patches.md)
+ [Creación y administración de grupos de revisiones](patch-manager-tag-a-patch-group.md)
+ [Integración de Patch Manager con AWS Security Hub CSPM](patch-manager-security-hub-integration.md)
# Cómo crear una política de revisiones
Una política de revisiones es un ajuste que se configura mediante Quick Setup, una herramienta de AWS Systems Manager. Las políticas de revisiones brindan un control más amplio y centralizado sobre sus operaciones de aplicación de revisiones que el que estaba disponible con otros métodos de configuración de aplicación de revisiones. Una política de revisiones define la programación y la línea de base que se usarán cuando se apliquen revisiones automáticamente a sus nodos y aplicaciones.
Para obtener más información, consulte los temas siguientes:
+ [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md)
+ [Cómo configurar las revisiones para las instancias de una organización mediante una política de parches Quick Setup](quick-setup-patch-manager.md)
# Visualización de resúmenes del panel de revisiones
La pestaña **Panel** en Patch Manager proporciona una vista de resumen en la consola que puede utilizar para supervisar las operaciones de aplicación de revisiones en una vista consolidada. Patch Manager es una herramienta de AWS Systems Manager. En la pestaña **Dashboard** (Panel), puede ver los siguientes gráficos:
+ Una instantánea que muestra cuántos nodos administrados están en conformidad o no con las reglas de aplicación de revisiones.
+ Una instantánea que muestra la antigüedad de los resultados de conformidad de las revisiones para los nodos administrados.
+ Recuento vinculado de cuántos nodos administrados no conformes existen para cada uno de los motivos más comunes de no conformidad.
+ Lista vinculada de las operaciones de revisión más recientes.
+ Lista vinculada de las tareas de revisión periódicas que se han configurado.
**Para ver los resúmenes del panel de revisiones**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Elija la pestaña **Dashboard** (Panel).
1. Desplácese hasta la sección que contiene los datos resumidos que desea ver:
+ **Amazon EC2 instance management (Administración de instancias de Amazon EC**
+ **Compliance summary (Resumen de conformidad**
+ **Noncompliance counts (Recuentos de no conformidad**
+ **Compliance reports (Informes de conformidad**
+ **Non-patch policy-based operations (Operaciones basadas en políticas no relacionadas con revisiones**
+ **Non-patch policy-based recurring tasks (Tareas recurrentes basadas en políticas no relacionadas con revisiones**
# Trabajo con informes de conformidad de las revisiones
Utilice la información en los siguientes temas como ayuda para generar y trabajar con informes de conformidad de las revisiones en Patch Manager, una herramienta de AWS Systems Manager.
La información de los siguientes temas se aplica independientemente del método o el tipo de configuración que utilice para las operaciones de aplicación de revisiones:
+ Una política de revisiones configurada en Quick Setup
+ Una opción de administración de host configurada en Quick Setup
+ Una ventana de mantenimiento para ejecutar una revisión `Scan` o una tarea `Install`
+ Una operación **Patch Now** (Aplicar revisión ahora) bajo demanda
**importante**
Los informes de conformidad de las revisiones son instantáneas puntuales generadas únicamente por operaciones de aplicación de revisiones exitosas. Cada informe contiene un tiempo de captura que identifica cuándo se calculó el estado de conformidad.
Si tiene varios tipos de operaciones implementadas para analizar las instancias en busca de conformidad de revisiones, recuerde que cada análisis sobreescribe los datos de conformidad de revisiones de los análisis anteriores. Como consecuencia, es posible que obtenga resultados inesperados en los datos de cumplimiento de sus revisiones. Para obtener más información, consulte [Identificación de la ejecución que creó los datos de conformidad de la revisión](patch-manager-compliance-data-overwrites.md).
Para comprobar qué línea de base de revisiones se utilizó para generar la información de cumplimiento más reciente, vaya a la pestaña **Informes de cumplimiento** en Patch Manager, busque la fila del nodo administrado del que desea obtener información y elija el ID de referencia en la columna **ID de línea de base utilizado**.
**Topics**
+ [Ver resultados de conformidad de parches](patch-manager-view-compliance-results.md)
+ [Cómo generar informes de conformidad de parches en formato .csv](patch-manager-store-compliance-results-in-s3.md)
+ [Corrección de los nodos gestionados no conformes con Patch Manager](patch-manager-noncompliant-nodes.md)
+ [Identificación de la ejecución que creó los datos de conformidad de la revisión](patch-manager-compliance-data-overwrites.md)
# Ver resultados de conformidad de parches
Utilice estos procedimientos para ver la información de conformidad de revisiones sobre los nodos administrados.
Este procedimiento se aplica a las operaciones de parches que utilizan el documento `AWS-RunPatchBaseline`. Para obtener información acerca de cómo ver la información de conformidad de parches para las operaciones de parches que utilizan el documento `AWS-RunPatchBaselineAssociation`, consulte [Identificación de nodos administrados no conformes](patch-manager-find-noncompliant-nodes.md).
**nota**
Las operaciones de escaneo de revisiones para Quick Setup y Explorer utilizan el documento `AWS-RunPatchBaselineAssociation`. Tanto Quick Setup como Explorer son herramientas de AWS Systems Manager.
**Identificar la solución de parches para un problema CVE específico (Linux)**
Para muchos sistemas operativos basados en Linux, los resultados de conformidad de parches indican qué problemas del boletín de vulnerabilidades y exposiciones comunes (CVE) se solucionan con cada uno de los parches. Esta información puede ayudarlo a determinar con qué urgencia necesita instalar un parche faltante o fallido.
Se incluyen detalles de la CVE para las versiones compatibles de los siguientes tipos de sistemas operativos:
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux
**nota**
De forma predeterminada, CentOS Stream no proporciona información de CVE relativa a las actualizaciones. Sin embargo, puede permitir este soporte mediante el uso de repositorios de terceros como es el caso del repositorio Extra Packages for Enterprise Linux (EPEL) publicado por Fedora. Para obtener información, consulte [EPEL](https://fedoraproject.org/wiki/EPEL) en el wiki de Fedora.
En la actualidad, los valores de ID de CVE solo se reportan para los parches con el estado `Missing` o `Failed`.
También puede agregar ID de CVE a sus listas de parches aprobados o rechazados en sus bases de referencia de parches, según lo justifique la situación y sus objetivos de aplicación de parches.
Para obtener información acerca de cómo trabajar con las listas de parches aprobados y rechazados, consulte los siguientes temas:
+ [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md)
+ [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md)
+ [Funcionamiento de las reglas de bases de referencia de parches en los sistemas basados en Linux](patch-manager-linux-rules.md)
+ [Cómo se instalan los parches](patch-manager-installing-patches.md)
**nota**
En algunos casos, Microsoft lanza parches para las aplicaciones que no especifican una hora ni una fecha de actualización. En estos casos, se suministra una fecha y hora actualizadas de `01/01/1970` de forma predeterminada.
## Visualización de los resultados de conformidad de revisiones
Utilice los siguientes procedimientos para ver los resultados de conformidad de parches en la consola de AWS Systems Manager.
**nota**
Para obtener información acerca de cómo generar informes de conformidad de parches que se descargan en un bucket de Amazon Simple Storage Service (Amazon S3), consulte [Cómo generar informes de conformidad de parches en formato .csv](patch-manager-store-compliance-results-in-s3.md).
**Para ver los resultados de conformidad de parches**
1. Aplique alguna de las siguientes acciones.
**Opción 1** (recomendada). Navegue desde Patch Manager, una herramienta de AWS Systems Manager:
+ En el panel de navegación, elija **Patch Manager**.
+ Elija la pestaña **Compliance reporting** (Informes de conformidad).
+ En el área de **Detalles de revisión de nodos**, seleccione el ID del nodo administrado para el cual quiera revisar los resultados de conformidad de los parches. Los nodos que estén en estado `stopped` o `terminated` no aparecerán aquí.
+ En el área **Detalles**, en la lista **Propiedades**, seleccione **Parches**.
**Opción 2**. Navegue desde Cumplimiento, una herramienta de AWS Systems Manager:
+ En el panel de navegación, elija **Compliance**.
+ En la sección **Compliance resources summary** (Resumen de recursos de conformidad), elija un número en la columna correspondiente a los tipos de recursos de parches que desee revisar, como **Non-Compliant resources** (Recursos no conformes).
+ Debajo, en la lista **Recursos**, seleccione el ID del nodo administrado para el cual quiera revisar los resultados de conformidad de los parches.
+ En el área **Detalles**, en la lista **Propiedades**, seleccione **Parches**.
**Opción 3**. Navegue desde Fleet Manager, una herramienta de AWS Systems Manager.
+ En el panel de navegación, elija **Fleet Manager**.
+ En el área **Instancias administradas**, seleccione el ID del nodo administrado para el cual quiera revisar los resultados de conformidad de los parches.
+ En el área **Detalles**, en la lista **Propiedades**, seleccione **Parches**.
1. (Opcional) En el cuadro de búsqueda (![\[The Search icon\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/search-icon.png)), elija entre los filtros disponibles.
Por ejemplo, para Red Hat Enterprise Linux (RHEL), elija entre las siguientes opciones:
+ Nombre
+ Clasificación
+ Estado
+ Gravedad
Para Windows Server, elija entre las siguientes opciones:
+ KB
+ Clasificación
+ Estado
+ Gravedad
1. Elija uno de los valores disponibles para el tipo de filtro que seleccionó. Por ejemplo, si eligió **State** (Estado), ahora elija un estado de conformidad como **InstalledPendingReboot** (Instalado pendiente de reinicio), **Failed** (Con error) o **Missing** (Ausente).
**nota**
En la actualidad, los valores de ID de CVE solo se reportan para los parches con el estado `Missing` o `Failed`.
1. En función del estado de conformidad del nodo administrado, puede elegir qué acción llevar a cabo para corregir los nodos no conformes.
Por ejemplo, puede elegir aplicar una revisión a los nodos administrados no conformes de forma inmediata. Para obtener información acerca de la aplicación de revisiones a los nodos administrados bajo demanda, consulte [Aplicación de revisiones a nodos administrados bajo demanda](patch-manager-patch-now-on-demand.md).
Para obtener información acerca de los estados de conformidad de parches, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md).
# Cómo generar informes de conformidad de parches en formato .csv
Puede utilizar la consola de AWS Systems Manager para generar informes de conformidad de parches que se guardan como un archivo .csv en un bucket de Amazon Simple Storage Service (Amazon S3) de su elección. Puede generar un informe único bajo demanda o especificar una programación para generar los informes de forma automática.
Los informes se pueden generar para un único nodo administrado o para todos los nodos administrados de la selección de Cuenta de AWS y Región de AWS. En el caso de un único nodo, un informe presenta detalles completos, incluidos los ID de las revisiones relacionadas con un nodo que no es conforme. En el caso de un informe sobre todos los nodos administrados, solo se proporciona información de resumen y recuentos de las revisiones de los nodos no conformes.
Después de generar un informe, puede utilizar una herramienta como Amazon Quick para importar y analizar los datos. Quick es un servicio de inteligencia empresarial (BI) que se puede utilizar para explorar e interpretar la información en un entorno visual interactivo. Para obtener más información, consulte la [Guía del usuario de Amazon Quick](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html).
**nota**
Cuando crea una línea de base de revisiones personalizada, puede especificar un nivel de gravedad de conformidad para las revisiones aprobadas por esa línea de base de revisiones, como `Critical` o `High`. Si se informa del estado de cualquier revisión aprobada como `Missing`, la gravedad de la conformidad general notificada por la línea de base de revisiones será el nivel de gravedad que haya especificado.
También puede especificar un tema de Amazon Simple Notification Service (Amazon SNS) que se utilizará para enviar notificaciones cuando se genera un informe.
**Roles de servicio para la generación de informes de conformidad de parches**
La primera vez que se genera un informe, Systems Manager crea un rol de asunción de Automation denominado `AWS-SystemsManager-PatchSummaryExportRole` para utilizarlo en el proceso de exportación a S3.
**nota**
Si va a exportar datos de conformidad a un bucket de S3 cifrado, debe actualizar su política de claves de AWS KMS asociada para proporcionar los permisos necesarios para `AWS-SystemsManager-PatchSummaryExportRole`. Por ejemplo, agregue un permiso similar a este a la política AWS KMS del bucket de S3:
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "role-arn"
}
```
Reemplace *role-arn* por el nombre de recurso de Amazon (ARN) del creado en su cuenta, en el formato `arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`.
Para obtener más información, consulte [Políticas de claves en AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) en la *Guía para desarrolladores de AWS Key Management Service*.
La primera vez que se genera un informe en una programación, Systems Manager crea otro rol de servicio denominado `AWS-EventBridge-Start-SSMAutomationRole`, así como el rol de servicio `AWS-SystemsManager-PatchSummaryExportRole` (en caso de no haberse creado ya) para utilizarlo en el proceso de exportación. `AWS-EventBridge-Start-SSMAutomationRole` permite que Amazon EventBridge inicie una automatización mediante el manual de procedimientos [AWS-ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).
Se recomienda no intentar modificar estas políticas y roles. En caso de hacerlo, podría producirse un error al generar el informe de conformidad de parches. Para obtener más información, consulte [Solución de problemas relacionados con la generación de informes de conformidad de parches](#patch-compliance-reports-troubleshooting).
**Topics**
+ [¿Qué incluye un informe de conformidad de parches generado?](#patch-compliance-reports-to-s3-examples)
+ [Cómo generar informes de conformidad de revisiones para un único nodo administrado](#patch-compliance-reports-to-s3-one-instance)
+ [Cómo generar informes de conformidad de revisiones para todos los nodos administrados](#patch-compliance-reports-to-s3-all-instances)
+ [Cómo visualizar el historial de informes de conformidad de parches](#patch-compliance-reporting-history)
+ [Cómo visualizar la programación de generación de informes de conformidad de parches](#patch-compliance-reporting-schedules)
+ [Solución de problemas relacionados con la generación de informes de conformidad de parches](#patch-compliance-reports-troubleshooting)
## ¿Qué incluye un informe de conformidad de parches generado?
Este tema proporciona información acerca de los tipos de contenido incluidos en los informes de conformidad de parches que se generan y descargan en un bucket de S3 especificado.
### Formato de informe para un único nodo administrado
Un informe generado para un único nodo administrado proporciona información de resumen y detallada.
[Descargar un ejemplo de informe (único nodo)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)
La información de resumen de un único nodo administrado incluye lo siguiente:
+ Index
+ ID de instancia
+ Nombre de instancia
+ IP de la instancia
+ nombre de la plataforma
+ Versión de la plataforma
+ SSM AgentVersión
+ línea de base de revisiones
+ grupo de parches
+ Compliance status (Estado de conformidad)
+ severidad de la conformidad
+ recuento de parches de severidad crítica no conformes
+ recuento de parches de severidad alta no conformes
+ recuento de parches de severidad media no conformes
+ recuento de parches de severidad baja no conformes
+ recuento de parches de severidad informativa no conformes
+ recuento de parches de severidad sin especificar no conformes
La información detallada de un único nodo administrado incluye lo siguiente:
+ Index
+ ID de instancia
+ Nombre de instancia
+ nombre del parche
+ ID de KB o ID de parche
+ estado del parche
+ hora del último informe
+ nivel de conformidad
+ gravedad del parche
+ clasificación del parche
+ ID de CVE
+ línea de base de revisiones
+ URL de registros
+ IP de la instancia
+ nombre de la plataforma
+ Versión de la plataforma
+ SSM AgentVersión
**nota**
Cuando crea una línea de base de revisiones personalizada, puede especificar un nivel de gravedad de conformidad para las revisiones aprobadas por esa línea de base de revisiones, como `Critical` o `High`. Si se informa del estado de cualquier revisión aprobada como `Missing`, la gravedad de la conformidad general notificada por la línea de base de revisiones será el nivel de gravedad que haya especificado.
### Formato de informe para todos los nodos administrados
Un informe generado para todos los nodos administrados proporciona únicamente información de resumen.
[Descargar un informe de ejemplo (todos los nodos administrados)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)
La información de resumen de todos los nodos administrados incluye lo siguiente:
+ Index
+ ID de instancia
+ Nombre de instancia
+ IP de la instancia
+ nombre de la plataforma
+ Versión de la plataforma
+ SSM AgentVersión
+ línea de base de revisiones
+ grupo de parches
+ Compliance status (Estado de conformidad)
+ severidad de la conformidad
+ recuento de parches de severidad crítica no conformes
+ recuento de parches de severidad alta no conformes
+ recuento de parches de severidad media no conformes
+ recuento de parches de severidad baja no conformes
+ recuento de parches de severidad informativa no conformes
+ recuento de parches de severidad sin especificar no conformes
## Cómo generar informes de conformidad de revisiones para un único nodo administrado
Utilice el siguiente procedimiento para generar un informe de resumen de revisiones para un único nodo administrado en la Cuenta de AWS. El informe para un único nodo administrado proporciona detalles sobre cada revisión que no está en conformidad, incluidos los nombres e ID de las revisiones.
**Cómo generar informes de conformidad de revisiones para un único nodo administrado**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Elija la pestaña **Compliance reporting** (Informes de conformidad).
1. Elija el botón de la fila del nodo administrado para el que desea generar un informe y, a continuación, elija **View detail** (Ver detalle).
1. En la sección **Patch summary** (Resumen de revisiones), elija **Export to S3** (Exportar a S3).
1. En **Report name** (Nombre del informe), ingrese un nombre que le permita identificar el informe más adelante.
1. En **Reporting frequency** (Frecuencia de la generación de informes), elija una de las siguientes opciones:
+ **On demand** (Bajo demanda): cree un informe único Vaya al paso 9.
+ **On a schedule** (Programación): especifique una programación periódica para la generación automática de informes. Continúe con el paso 8.
1. En **Schedule type** (Tipo de programación), especifique una expresión rate, por ejemplo, cada 3 días, o proporcione una expresión cron que configure la frecuencia del informe.
Para obtener más información acerca de las expresiones cron, consulte [Referencia: expresiones cron y rate para Systems Manager](reference-cron-and-rate-expressions.md).
1. En **Bucket name** (Nombre del bucket), seleccione el nombre de un bucket de S3 en el que desee almacenar los archivos de informe .csv.
**importante**
Si trabaja en una Región de AWS que se lanzó después del 20 de marzo de 2019, deberá seleccionar un bucket de S3 en la misma región. Las regiones lanzadas después de esa fecha se desactivaron de forma predeterminada. Para obtener más información sobre estas regiones y una lista de ellas, consulte [Enabling a Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) en la *Referencia general de Amazon Web Services*.
1. (Opcional) Para enviar notificaciones cuando se genere el informe, expanda la sección **SNS topic** (Tema de SNS) y, a continuación, elija un tema de Amazon SNS existente desde **SNS topic Amazon Resource Name (ARN)** (Nombre de recurso de Amazon (ARN) del tema de SNS).
1. Elija **Enviar**.
Para obtener información acerca de cómo ver un historial de informes generados, consulte [Cómo visualizar el historial de informes de conformidad de parches](#patch-compliance-reporting-history).
Para obtener información acerca de cómo ver los detalles de las programaciones de generación de informes que ha creado, consulte [Cómo visualizar la programación de generación de informes de conformidad de parches](#patch-compliance-reporting-schedules).
## Cómo generar informes de conformidad de revisiones para todos los nodos administrados
Utilice el siguiente procedimiento para generar un informe de resumen de revisiones para todos los nodos administrados en la Cuenta de AWS. El informe de todos los nodos administrados muestra cuáles son los nodos y los números de las revisiones que no están en conformidad. No proporciona los nombres ni otros identificadores de los parches. Para obtener estos detalles adicionales, puede generar un informe de conformidad de revisiones para un único nodo administrado. Para obtener información, consulte la sección [Cómo generar informes de conformidad de revisiones para un único nodo administrado](#patch-compliance-reports-to-s3-one-instance) que se ha expuesto anteriormente en este tema.
**Cómo generar informes de conformidad de revisiones para todos los nodos administrados**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Elija la pestaña **Compliance reporting** (Informes de conformidad).
1. Elija **Export to S3** (Exportar a S3). (No seleccione primero un ID de nodo).
1. En **Report name** (Nombre del informe), ingrese un nombre que le permita identificar el informe más adelante.
1. En **Reporting frequency** (Frecuencia de la generación de informes), elija una de las siguientes opciones:
+ **On demand** (Bajo demanda): cree un informe único Vaya al paso 8.
+ **On a schedule** (Programación): especifique una programación periódica para la generación automática de informes. Continúe en el paso 7.
1. En **Schedule type** (Tipo de programación), especifique una expresión rate, por ejemplo, cada 3 días, o proporcione una expresión cron que configure la frecuencia del informe.
Para obtener más información acerca de las expresiones cron, consulte [Referencia: expresiones cron y rate para Systems Manager](reference-cron-and-rate-expressions.md).
1. En **Bucket name** (Nombre del bucket), seleccione el nombre de un bucket de S3 en el que desee almacenar los archivos de informe .csv.
**importante**
Si trabaja en una Región de AWS que se lanzó después del 20 de marzo de 2019, deberá seleccionar un bucket de S3 en la misma región. Las regiones lanzadas después de esa fecha se desactivaron de forma predeterminada. Para obtener más información sobre estas regiones y una lista de ellas, consulte [Enabling a Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) en la *Referencia general de Amazon Web Services*.
1. (Opcional) Para enviar notificaciones cuando se genere el informe, expanda la sección **SNS topic** (Tema de SNS) y, a continuación, elija un tema de Amazon SNS existente desde **SNS topic Amazon Resource Name (ARN)** (Nombre de recurso de Amazon (ARN) del tema de SNS).
1. Elija **Enviar**.
Para obtener información acerca de cómo ver un historial de informes generados, consulte [Cómo visualizar el historial de informes de conformidad de parches](#patch-compliance-reporting-history).
Para obtener información acerca de cómo ver los detalles de las programaciones de generación de informes que ha creado, consulte [Cómo visualizar la programación de generación de informes de conformidad de parches](#patch-compliance-reporting-schedules).
## Cómo visualizar el historial de informes de conformidad de parches
Utilice la información de este tema para que pueda ver los detalles acerca de los informes de conformidad de parches generados en su Cuenta de AWS.
**Cómo visualizar el historial de informes de conformidad de parches**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Elija la pestaña **Compliance reporting** (Informes de conformidad).
1. Elija **View all S3 exports** (Ver todas las exportaciones de S3) y, a continuación, elija la pestaña **Export history** (Historial de exportación).
## Cómo visualizar la programación de generación de informes de conformidad de parches
Utilice la información de este tema para que pueda ver los detalles acerca de las programaciones de generación de informes de conformidad de parches que ha creado en su Cuenta de AWS.
**Cómo visualizar el historial de informes de conformidad de parches**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Elija la pestaña **Compliance reporting** (Informes de conformidad).
1. Elija **View all S3 exports** (Ver todas las exportaciones de S3) y, a continuación, elija la pestaña **Report scheduled rules** (Informar reglas programadas).
## Solución de problemas relacionados con la generación de informes de conformidad de parches
Utilice la siguiente información que lo ayudará a solucionar problemas con la generación de informes de conformidad de parches en Patch Manager, una herramienta de AWS Systems Manager.
**Topics**
+ [Un mensaje notifica que la política `AWS-SystemsManager-PatchManagerExportRolePolicy` está dañada.](#patch-compliance-reports-troubleshooting-1)
+ [Después de eliminar roles o políticas de conformidad de parches, los informes programados no se generan correctamente](#patch-compliance-reports-troubleshooting-2)
### Un mensaje notifica que la política `AWS-SystemsManager-PatchManagerExportRolePolicy` está dañada.
**Problema:** recibe un mensaje de error similar al siguiente, en el que se indica que `AWS-SystemsManager-PatchManagerExportRolePolicy` está dañado:
```
An error occurred while updating the AWS-SystemsManager-PatchManagerExportRolePolicy
policy. If you have edited the policy, you might need to delete the policy, and any
role that uses it, then try again. Systems Manager recreates the roles and policies
you have deleted.
```
+ **Solución**: utilice la consola Patch Manager o la AWS CLI para eliminar los roles y las políticas afectadas antes de generar un nuevo informe de cumplimiento de las revisiones.
**Cómo eliminar la política dañada con la consola**
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Realice una de las siguientes acciones:
**Informes bajo demanda:** si el problema se produjo cuando se generaba un informe bajo demanda único, en el panel de navegación izquierdo, elija **Policies** (Políticas), busque `AWS-SystemsManager-PatchManagerExportRolePolicy`, y, a continuación, elimine la política. Luego, elija **Roles** (Roles), busque `AWS-SystemsManager-PatchSummaryExportRole` y, a continuación, elimine el rol.
**Informes programados:** si el problema se produjo mientras generaba un informe en una programación, en el panel de navegación izquierdo, elija **Políticas**, busque una a la vez en `AWS-EventBridge-Start-SSMAutomationRolePolicy` y `AWS-SystemsManager-PatchManagerExportRolePolicy` y elimine cada política. Luego, elija **Roles** (Roles), busque uno a la vez en `AWS-EventBridge-Start-SSMAutomationRole` y `AWS-SystemsManager-PatchSummaryExportRole` y, a continuación, elimine cada rol.
**Cómo eliminar una política dañada con la AWS CLI**
Sustituya los *valores de marcador* por su ID de la cuenta.
+ Si el problema se produjo al generar un informe único bajo demanda, ejecute los siguientes comandos:
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
Si el problema se produjo al generar un informe programado, ejecute los siguientes comandos:
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-EventBridge-Start-SSMAutomationRolePolicy
```
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-EventBridge-Start-SSMAutomationRole
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
Después de completar cualquiera de los procedimientos, siga los pasos para generar o programar un nuevo informe de conformidad de revisiones.
### Después de eliminar roles o políticas de conformidad de parches, los informes programados no se generan correctamente
**Problema:** la primera vez que se genera un informe, Systems Manager crea un rol de servicio y una política para utilizarlos en el proceso de exportación (`AWS-SystemsManager-PatchSummaryExportRole` y `AWS-SystemsManager-PatchManagerExportRolePolicy`). La primera vez que se genera un informe en una programación, Systems Manager crea otro rol de servicio y una política (`AWS-EventBridge-Start-SSMAutomationRole` y `AWS-EventBridge-Start-SSMAutomationRolePolicy`). Estas permiten que Amazon EventBridge inicie una automatización mediante el manual de procedimientos [AWS-ExportPatchReportToS3 ](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3).
Si elimina alguna de estas políticas o roles, es posible que se pierdan las conexiones entre su programación y el bucket de S3 y el tema de Amazon SNS especificados.
+ **Solución**: para resolver este problema, se recomienda eliminar la programación anterior y crear una nueva que reemplace a la que presentaba problemas.
# Corrección de los nodos gestionados no conformes con Patch Manager
Los temas incluidos en esta sección ofrecen información general sobre cómo identificar los nodos administrados que no están conformes con la aplicación de revisiones y cómo lograr esa conformidad.
**Topics**
+ [Identificación de nodos administrados no conformes](patch-manager-find-noncompliant-nodes.md)
+ [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md)
+ [Revisiones en nodos administrados que no están en conformidad](patch-manager-compliance-remediation.md)
# Identificación de nodos administrados no conformes
Los nodos administrados que no están en conformidad se identifican en el momento en que se ejecuta cualquiera de los dos documentos de AWS Systems Manager (documentos de SSM). Estos documentos de SSM hacen referencia a la línea de base de revisiones adecuada para cada nodo administrado en Patch Manager, una herramienta de AWS Systems Manager. A continuación, se evalúa el estado de la revisión del nodo administrado y se ponen a disposición los resultados de conformidad.
Hay dos documentos de SSM que se utilizan para identificar o actualizar los nodos administrados no conformes: `AWS-RunPatchBaseline` y `AWS-RunPatchBaselineAssociation`. Cada una de ellas se utiliza en diferentes procesos, y sus resultados de conformidad se encuentran disponibles en distintos canales. En la siguiente tabla se exponen las diferencias entre estos documentos.
**nota**
Se pueden enviar los datos de conformidad de revisiones de Patch Manager a AWS Security Hub CSPM. Security Hub CSPM ofrece una visión completa de las alertas de seguridad de alta prioridad y el estado de conformidad. También monitorea el estado de aplicación de revisiones de la flota. Para obtener más información, consulte [Integración de Patch Manager con AWS Security Hub CSPM](patch-manager-security-hub-integration.md).
| | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` |
| --- | --- | --- |
| Procesos que utilizan el documento | **Revisión bajo demanda:** puede analizar o aplicar revisiones a nodos administrados bajo demanda mediante la opción **Patch now** (Aplicar revisión ahora). Para obtener más información, consulte [Aplicación de revisiones a nodos administrados bajo demanda](patch-manager-patch-now-on-demand.md). **Políticas de revisiones de Quick Setup de Systems Manager**: puede crear una configuración de revisiones en Quick Setup, una herramienta de AWS Systems Manager, que pueda buscar o instalar las revisiones que faltan según programaciones independientes para toda una organización, un subconjunto de unidades organizativas o una sola Cuenta de AWS. Para obtener más información, consulte [Cómo configurar las revisiones para las instancias de una organización mediante una política de parches Quick Setup](quick-setup-patch-manager.md). **Ejecución de un comando**: puede ejecutar `AWS-RunPatchBaseline` manualmente en una operación en Run Command, una herramienta de AWS Systems Manager. Para obtener más información, consulte [Ejecución de comandos desde la consola](running-commands-console.md). **Periodo de mantenimiento**: puede crear un periodo de mantenimiento que utilice el documento de SSM `AWS-RunPatchBaseline` en un tipo de tarea de Run Command. Para obtener más información, consulte [Tutorial: creación de un periodo de mantenimiento para la aplicación de revisiones mediante la consola](maintenance-window-tutorial-patching.md). | **Administración de host de Quick Setup de Systems Manager**: puede habilitar una opción de configuración de administración de host en Quick Setup para analizar diariamente sus instancias administradas con el fin de comprobar la conformidad de las revisiones. Para obtener más información, consulte [Instalar la administración de host de Amazon EC2 mediante Quick Setup](quick-setup-host-management.md). **[Explorer](Explorer.md) de Systems Manager**: cuando permite Explorer, una herramienta de AWS Systems Manager, esta analiza periódicamente sus instancias administradas con el fin de comprobar la conformidad con las revisiones e informa los resultados en el panel de Explorer. |
| Formato de los datos de los resultados obtenidos en el análisis de revisiones | Una vez que se ejecuta `AWS-RunPatchBaseline`, Patch Manager envía un objeto `AWS:PatchSummary` a Inventario, una herramienta de AWS Systems Manager. Este informe se genera únicamente si las operaciones de aplicación de revisiones se realizan correctamente e incluye un tiempo de captura que identifica cuándo se calculó el estado de conformidad. | Una vez que se ejecuta `AWS-RunPatchBaselineAssociation`, Patch Manager envía un objeto `AWS:ComplianceItem` a Systems Manager Inventory. |
| Visualización de informes de conformidad de revisiones en la consola | Puede visualizar la información de conformidad de las revisiones para los procesos que utilizan `AWS-RunPatchBaseline` en [Conformidad de configuración de Systems Manager](systems-manager-compliance.md) y [Trabajo con nodos administrados](fleet-manager-managed-nodes.md). Para obtener más información, consulte [Ver resultados de conformidad de parches](patch-manager-view-compliance-results.md). | Si utiliza Quick Setup para analizar sus instancias administradas para comprobar la conformidad con las revisiones, podrá consultar el informe de conformidad en [Systems Manager Fleet Manager](fleet-manager.md). En la consola Fleet Manager, elija el ID de nodo del nodo administrado. En el menú **General**, seleccione **Cumplimiento de la configuración**. Si utiliza Explorer para analizar sus instancias administradas para comprobar la conformidad con las revisiones, podrá consultar el informe de conformidad tanto en Explorer como en [Systems Manager OpsCenter](OpsCenter.md). |
| Comandos de la AWS CLI para visualizar los resultados de conformidad de revisiones | Para los procesos que utilizan `AWS-RunPatchBaseline`, puede usar los siguientes comandos de la AWS CLI para obtener información de resumen acerca de las revisiones en un nodo administrado. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | Para los procesos que utilizan `AWS-RunPatchBaselineAssociation`, puede usar el siguiente comando de la AWS CLI para obtener información de resumen acerca de las revisiones en una instancia. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) |
| Operaciones de aplicación de revisiones | Para los procesos que utilizan `AWS-RunPatchBaseline`, se especifica si se desea que la operación ejecute únicamente una operación `Scan` o una operación `Scan and install`. Si el objetivo es identificar los nodos administrados no conformes en lugar de corregirlos, ejecute únicamente una operación `Scan`. | Los procesos Quick Setup y Explorer, que utilizan AWS-RunPatchBaselineAssociation, ejecutan únicamente una operación Scan. |
| Más información | [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) | [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) |
Para obtener información acerca de los distintos estados de conformidad de las revisiones que se podrían notificar, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md)
Para obtener información acerca de cómo corregir los nodos administrados que no están en conformidad con las revisiones, consulte [Revisiones en nodos administrados que no están en conformidad](patch-manager-compliance-remediation.md).
# Valores de estado de conformidad de las revisiones
La información sobre las revisiones de un nodo administrado incluye un informe sobre el estado de cada revisión individual.
**sugerencia**
Si desea asignar un estado de conformidad de revisiones específico a un nodo administrado, puede utilizar el comando de la AWS Command Line Interface (AWS CLI) [https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/put-compliance-items.html) o la operación de la API [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html). La asignación del estado de conformidad no se admite en la consola.
Utilice la información que aparece en las siguientes tablas para que pueda identificar el motivo por el cual un nodo administrado podría no estar en conformidad con las revisiones.
## Valores de conformidad de revisiones para Debian Server y Ubuntu Server
En el caso de Debian Server y Ubuntu Server, las reglas para la clasificación de los paquetes en los diferentes estados de conformidad se describen en la siguiente tabla.
**nota**
Tenga en cuenta lo siguiente al evaluar los valores de estado `INSTALLED`, `INSTALLED_OTHER`, y `MISSING`: Si no selecciona la casilla **Incluir actualizaciones no relacionadas con la seguridad** al crear o actualizar una línea de base de revisiones, las versiones candidatas a parches se limitan a los parches en los siguientes repositorios:
Ubuntu Server 16.04 LTS: `xenial-security`
Ubuntu Server 18.04 LTS: `bionic-security`
Ubuntu Server 20.04 LTS: `focal-security`
Ubuntu Server 22.04 LTS (`jammy-security`)
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
`debian-security` (Debian Server)
Si selecciona la casilla **Include nonsecurity updates** (Incluir actualizaciones no relacionadas con la seguridad), también se tendrán en cuenta los parches de otros repositorios.
| Estado del parche | Descripción | Compliance status (Estado de conformidad) |
| --- | --- | --- |
| **`INSTALLED`** | La revisión aparece en la base de referencia de revisiones y se instala en el nodo administrado. Podría haberse instalado de forma manual por un usuario o de forma automática por Patch Manager cuando se ejecutó el documento `AWS-RunPatchBaseline` en el nodo administrado. | Conforme |
| **`INSTALLED_OTHER`** | La revisión no se incluye en la base de referencia ni se encuentra aprobada por ella, pero se instala en el nodo administrado. Es posible que el parche se haya instalado manualmente, que el paquete sea una dependencia necesaria de otro parche aprobado o que se haya incluido en una operación InstallOverrideList. Si no especifica `Block` como acción de **parches rechazados**, los parches `INSTALLED_OTHER` también incluyen los parches instalados pero que han sido rechazados. | Conforme |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` puede significar cualquiera de las siguientes posibilidades: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-compliance-states.html) En ninguno de los dos casos significa que una revisión con este estado *requiera* un reinicio, solo que el nodo no se ha reiniciado desde que se instaló el parche. | No conforme |
| **`INSTALLED_REJECTED`** | La revisión está instalada en el nodo administrado, pero se especifica en una lista de **revisiones rechazadas**. Normalmente esto significa que el parche se instaló antes de que se añadiera a una lista de parches rechazados. | No conforme |
| **`MISSING`** | La revisión está aprobada en la base de referencia, pero no se ha instalado en el nodo administrado. Si configura la tarea de documento `AWS-RunPatchBaseline` para analizar (en vez de instalar), el sistema informa este estado para los parches que se encontraron durante el análisis, pero que no se han instalado. | No conforme |
| **`FAILED`** | El parche está aprobado en la base de referencia, pero no se ha podido instalar. Para resolver esta situación, revise la salida del comando para buscar información que pueda ayudarle a comprender el problema. | No conforme |
## Valores de conformidad de parches para otros sistemas operativos
Para todos los sistemas operativos además de Debian Server y Ubuntu Server, las reglas para la clasificación de los paquetes en los diferentes estados de conformidad se describen en la siguiente tabla.
| Estado del parche | Descripción | Valor de conformidad |
| --- | --- | --- |
| **`INSTALLED`** | La revisión aparece en la base de referencia de revisiones y se instala en el nodo administrado. Podría haberse instalado de forma manual por un usuario o de forma automática por Patch Manager cuando se ejecutó el documento `AWS-RunPatchBaseline` en el nodo. | Conforme |
| **`INSTALLED_OTHER`**1 | La revisión no está en la base de referencia, pero se ha instalado en el nodo administrado. Existen dos razones posibles para ello: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-compliance-states.html) | Conforme |
| **`INSTALLED_REJECTED`** | La revisión está instalada en el nodo administrado, pero se especifica en una lista de revisiones rechazadas. Normalmente esto significa que el parche se instaló antes de que se añadiera a una lista de parches rechazados. | No conforme |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` puede significar cualquiera de las siguientes posibilidades: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/patch-manager-compliance-states.html) En ninguno de los dos casos significa que una revisión con este estado *requiera* un reinicio, solo que el nodo no se ha reiniciado desde que se instaló el parche. | No conforme |
| **`MISSING`** | La revisión está aprobada en la base de referencia, pero no se ha instalado en el nodo administrado. Si configura la tarea de documento `AWS-RunPatchBaseline` para analizar (en vez de instalar), el sistema informa este estado para los parches que se encontraron durante el análisis, pero que no se han instalado. | No conforme |
| **`FAILED`** | El parche está aprobado en la base de referencia, pero no se ha podido instalar. Para resolver esta situación, revise la salida del comando para buscar información que pueda ayudarle a comprender el problema. | No conforme |
| **`NOT_APPLICABLE`**1 | *Este estado de cumplimiento solo se notifica en los sistemas operativos de Windows Server.* La revisión está aprobada en la base de referencia, pero el servicio o la característica que usa la revisión no se ha instalado en el nodo administrado. Por ejemplo, una revisión de un servicio de servidor web como Internet Information Services (IIS) mostrará `NOT_APPLICABLE` si se ha aprobado en la base de referencia, pero el servicio web no se ha instalado en el nodo administrado. También se puede marcar un parche `NOT_APPLICABLE` si se ha reemplazado por una actualización posterior. Esto significa que la actualización posterior está instalada y la actualización `NOT_APPLICABLE` ya no es necesaria. | No aplicable |
| AVAILABLE\$1SECURITY\$1UPDATES | *Este estado de cumplimiento solo se notifica en los sistemas operativos de Windows Server.* La revisión de actualización de seguridad disponible que no esté aprobada por la línea de base de revisiones puede tener un valor de conformidad `Compliant` o `Non-Compliant`, tal como se define en una línea de base de revisiones personalizada. Al crear o actualizar una línea de base de revisiones, usted elige el estado que desee asignar a las revisiones de seguridad que están disponibles pero no aprobadas porque no cumplen con los criterios de instalación especificados en la línea de base de revisiones. Por ejemplo, las revisiones de seguridad que desee instalar se pueden omitir si ha especificado un periodo prolongado de espera después del lanzamiento de la revisión antes de la instalación. Si se publica una actualización de la revisión durante el periodo de espera especificado, el periodo de espera para instalar la revisión vuelve a comenzar. Si el periodo de espera es demasiado extenso, es posible que se lancen varias versiones de la revisión, pero nunca se instalen. En cuanto a los recuentos resumidos de revisiones, cuando una revisión se notifica como `AvailableSecurityUpdate`, siempre se incluirá en `AvailableSecurityUpdateCount`. Si la línea de base está configurada para indicar estas revisiones como `NonCompliant`, también se incluye en `SecurityNonCompliantCount`. Si la línea de base está configurada para indicar estas revisiones como `Compliant`, no se incluyen en `SecurityNonCompliantCount`. Estas revisiones siempre se notifican con una gravedad no especificada y nunca se incluyen en el `CriticalNonCompliantCount`. | Conforme o No conforme, según la opción seleccionada para las actualizaciones de seguridad disponibles. Si utiliza la consola para crear o actualizar una línea de base de revisiones, especifique esta opción en el campo **Estado de cumplimiento de las actualizaciones de seguridad disponibles**. Si utiliza la AWS CLI para ejecutar el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-patch-baseline.html) o [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-patch-baseline.html), especifique esta opción en el parámetro `available-security-updates-compliance-status`. |
¹ Para revisiones con el estado `INSTALLED_OTHER` y `NOT_APPLICABLE`, Patch Manager omite algunos datos de los resultados de la consulta en función del comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patches.html), como los valores de `Classification` y `Severity`. Esto se hace para ayudar a evitar que se supere el límite de datos en los nodos individuales de Inventario, una herramienta de AWS Systems Manager. Para ver todos los detalles de la revisión, puede utilizar el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html).
# Revisiones en nodos administrados que no están en conformidad
Muchas de las mismas herramientas y procesos de AWS Systems Manager que puede utilizar para verificar la conformidad de los nodos administrados con las revisiones sirven para lograr que los nodos cumplan las reglas de las revisiones que se les aplican actualmente. Para que los nodos administrados estén en conformidad con la revisión, Patch Manager, una herramienta de AWS Systems Manager, debe ejecutar una operación `Scan and install`. (Si el objetivo es solo identificar los nodos administrados que no están en conformidad en vez de corregirlos, ejecute una operación `Scan` en su lugar. Para obtener más información, consulte [Identificación de nodos administrados no conformes](patch-manager-find-noncompliant-nodes.md)).
**Instalar revisiones con Systems Manager**
Puede elegir entre varias herramientas para realizar una operación `Scan and install`:
+ (Recomendado) Configure una política de revisiones en Quick Setup, una herramienta de Systems Manager, que le permita instalar revisiones faltantes en una programación para una organización completa, un subconjunto de unidades organizacionales o una sola Cuenta de AWS. Para obtener más información, consulte [Cómo configurar las revisiones para las instancias de una organización mediante una política de parches Quick Setup](quick-setup-patch-manager.md).
+ Cree un periodo de mantenimiento que utilice el documento de Systems Manager (documento de SSM) `AWS-RunPatchBaseline` en un tipo de tarea de Run Command. Para obtener más información, consulte [Tutorial: creación de un periodo de mantenimiento para la aplicación de revisiones mediante la consola](maintenance-window-tutorial-patching.md).
+ Ejecute manualmente `AWS-RunPatchBaseline` en una operación Run Command. Para obtener más información, consulte [Ejecución de comandos desde la consola](running-commands-console.md).
+ Instale las revisiones bajo demanda con la opción **Patch now** (Aplicar revisión ahora). Para obtener más información, consulte [Aplicación de revisiones a nodos administrados bajo demanda](patch-manager-patch-now-on-demand.md).
# Identificación de la ejecución que creó los datos de conformidad de la revisión
Los datos de conformidad de las revisiones representan una instantánea puntual de la última operación de aplicación de revisiones exitosa. Cada informe de conformidad incluye un identificador de ejecución y un tiempo de captura que ayudan a identificar qué operación creó los datos de conformidad y cuándo se generaron.
Si tiene varios tipos de operaciones implementadas para analizar las instancias para comprobar la conformidad de revisiones, cada análisis sobrescribe los datos de conformidad de revisiones de los análisis anteriores. Como consecuencia, es posible que obtenga resultados inesperados en los datos de cumplimiento de sus revisiones.
Por ejemplo, supongamos que crea una política de revisiones que analiza la conformidad de las revisiones todos los días a las 2:00 h, hora local. Esa política utiliza una línea de base de revisiones que se centra en las revisiones con una gravedad marcada como `Critical`, `Important`, y `Moderate`. Esta línea de base de revisiones también especifica algunas revisiones que se rechazaron de forma específica.
Supongamos también que ya configuró un periodo de mantenimiento para analizar el mismo conjunto de nodos administrados todos los días a las 4 h, hora local, que no elimina ni desactiva. La tarea de ese periodo de mantenimiento utiliza una línea de base de revisiones diferente, una que se enfoca solo en las revisiones con una gravedad `Critical` y no excluye ninguna revisión específica.
Cuando el periodo de mantenimiento realiza este segundo análisis, los datos de conformidad de las revisiones del primer análisis se eliminan y se reemplazan por los del segundo análisis.
Por lo tanto, recomendamos encarecidamente usar solo un método automatizado para analizar e instalar en sus operaciones de aplicación de revisiones. Si está configurando políticas de revisiones, debe eliminar o desactivar otros métodos de análisis para comprobar el cumplimiento de revisiones. Para obtener más información, consulte los temas siguientes:
+ Para eliminar una tarea de operación de aplicación de revisiones de un periodo de mantenimiento: [Actualizar o eliminar tareas de un periodo de mantenimiento mediante la consola](sysman-maintenance-update.md#sysman-maintenance-update-tasks)
+ Para eliminar una asociación de State Manager: [Eliminación de una asociación](systems-manager-state-manager-delete-association.md).
Para desactivar los análisis diarios de cumplimiento de revisiones en una configuración de administración de host, haga lo siguiente en Quick Setup:
1. En el panel de navegación, elija **Quick Setup**.
1. Seleccione la configuración de administración de host para actualizar.
1. Elija **Actions (Acciones) y Edit configuration (Editar la configuración)**.
1. Desactive la casilla **Scan instances for missing patches daily** (Analizar diariamente las instancias en busca de revisiones que falten).
1. Elija **Actualizar**.
**nota**
El uso de la opción **Patch now** (Aplicar revisión ahora) para analizar un nodo administrado para comprobar la conformidad también da como resultado una sobrescritura de los datos de conformidad de las revisiones.
# Aplicación de revisiones a nodos administrados bajo demanda
Puede ejecutar las operaciones de aplicación de revisiones bajo demanda desde la consola de Systems Manager mediante la opción **Aplicar el parche ahora** en Patch Manager, una herramienta de AWS Systems Manager. De este modo, no tendrá que crear una programación para actualizar el estado de conformidad de los nodos administrados o para instalar revisiones en los nodos no conformes. Tampoco es necesario cambiar la consola de Systems Manager entre Patch Manager y Maintenance Windows, una herramienta de AWS Systems Manager, para configurar o modificar un periodo de aplicación de revisiones programado.
**Patch now** (Aplicar revisión ahora) resulta de gran utilidad cuando se deben aplicar actualizaciones de día cero o instalar otras revisiones críticas en los nodos administrados lo antes posible.
**nota**
Se admite la aplicación de revisiones bajo demanda para un solo par de Cuenta de AWS-Región de AWS a la vez. No se puede usar con operaciones de revisiones basadas en *políticas de revisiones*. Recomendamos utilizar políticas de revisiones para mantener todos los nodos administrados en conformidad. Para obtener más información sobre el uso de las políticas de revisiones, consulte [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md).
**Topics**
+ [Funcionamiento de “Patch now” (Aplicar revisión ahora)](#patch-on-demand-how-it-works)
+ [Ejecución de “Patch now” (Aplicar revisión ahora)](#run-patch-now)
## Funcionamiento de “Patch now” (Aplicar revisión ahora)
Para ejecutar **Patch now** (Aplicar revisión ahora), solo tiene que especificar dos ajustes necesarios:
+ Si se analizan solo las revisiones faltantes o si se analizan *e* instalan las revisiones en los nodos administrados
+ En qué nodos administrados se ejecuta la operación
Cuando la operación **Patch now** (Aplicar revisión ahora) se ejecuta, determina qué línea de base de revisiones se va a utilizar de la misma manera que se selecciona una para otras operaciones de revisiones. Si un nodo administrado está asociado a un grupo de revisiones, se utiliza la base de referencia de revisiones especificada para ese grupo. Si el nodo administrado no está asociado a un grupo de revisiones, la operación utiliza la base de referencia de revisiones que está configurada actualmente como predeterminada para el tipo de sistema operativo del nodo administrado. Puede tratarse de una base de referencia predefinida o de la base de referencia personalizada que haya definido como predeterminada. Para obtener más información acerca de la selección de línea de base de revisiones, consulte [Grupos de revisiones](patch-manager-patch-groups.md).
Las opciones que se pueden especificar para **Patch now** (Aplicar revisión ahora) incluyen elegir cuándo reiniciar los nodos administrados después de la aplicación de revisiones, o si corresponde hacerlo, especificar un bucket de Amazon Simple Storage Service (Amazon S3) para almacenar los datos de registro de esa operación de aplicación de revisiones y ejecutar documentos de Systems Manager (documentos de SSM) como enlaces de ciclo de vida durante la aplicación de revisiones.
### Umbrales de concurrencia y error para ‘Patch now’
Para las operaciones de **Patch now** (Aplicar revisión ahora), las opciones de umbral de concurrencia y de error se gestionan mediante Patch Manager. No es necesario especificar en cuántos nodos administrados se aplicará la revisión a la vez ni cuántos errores se permiten antes de que la operación no funcione. Patch Manager aplica las configuraciones de simultaneidad y límites de errores descritas en las siguientes tablas cuando se aplica una revisión bajo demanda.
**importante**
Los siguientes umbrales se aplican únicamente a las operaciones `Scan and install`. En el caso de las operaciones `Scan`, Patch Manager intenta analizar hasta 1000 nodos simultáneamente y continúa el análisis hasta que haya detectado un máximo de 1000 errores.
**Simultaneidad: operaciones de instalación**
| Número total de nodos administrados en la operación **Patch now** (Aplicar revisión ahora) | Número de nodos administrados analizados o con revisiones a la vez |
| --- | --- |
| Menos de 25 | 1 |
| 25-100 | 5% |
| 101 a 1000 | 8 % |
| Más de 1000 | 10% |
**Umbral de error: operaciones de instalación**
| Número total de nodos administrados en la operación **Patch now** (Aplicar revisión ahora) | Número de errores permitidos antes de que la operación no funcione |
| --- | --- |
| Menos de 25 | 1 |
| 25-100 | 5 |
| 101 a 1000 | 10 |
| Más de 1000 | 10 |
### Uso de los enlaces de ciclo de vida ‘Patch now’
**Patch now** (Aplicar revisión ahora) le proporciona la capacidad de ejecutar documentos de comando de SSM como enlaces de ciclo de vida durante una operación de revisióno de `Install`. Puede utilizar estos enlaces para tareas tales como apagar aplicaciones antes de aplicar revisiones o ejecutar comprobaciones de estado en las aplicaciones después de aplicar revisiones o después de un reinicio.
Para obtener más información acerca del uso de enlaces de ciclo de vida, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
En la siguiente tabla se indican los enlaces de ciclo de vida disponibles para cada uno de las tres opciones de reinicio **Patch now** (Aplicar revisión ahora), además de los usos de muestra para cada enlace.
**Enlaces de ciclo de vida y usos de muestra**
| Opción de reinicio | Enlace: antes de la instalación | Enlace: después de la instalación | Enlace: en la salida | Enlace: después del reinicio programado |
| --- | --- | --- | --- | --- |
| Reboot if needed (Reiniciar si es necesario | Ejecute un documento SSM antes de que comience la revisióno. Ejemplo de uso: Cierre las aplicaciones de forma segura antes de que comience el proceso de revisiones. | Ejecute un documento SSM al final de la operación de aplicación de revisiones y antes del reinicio del nodo administrado. Ejemplo de uso: Ejecute operaciones como la instalación de aplicaciones de terceros antes de un posible reinicio. | Ejecute un documento de SSM después de que finalice la operación de revisión y se hayan reiniciado las instancias. Ejemplo de uso: Asegúrese de que las aplicaciones se ejecuten según lo esperado tras la aplicación de revisiones. | No disponible |
| Do not reboot my instances (No reiniciar mis instancias | Igual que lo mencionado anteriormente. | Ejecute un documento de SSM al final de la operación de revisióno. Ejemplo de uso: Asegúrese de que las aplicaciones se ejecuten según lo esperado tras la aplicación de revisiones. | *No disponible* | *No disponible* |
| Schedule a reboot time (Programar una hora de reinicio | Igual que lo mencionado anteriormente. | Igual que para Do not reboot my instances (No reiniciar mis instancias) | No disponible | Ejecute un documento de SSM inmediatamente después de que finalice el reinicio programado. Ejemplo de uso: Asegúrese de que las aplicaciones se ejecuten según lo esperado después del reinicio. |
## Ejecución de “Patch now” (Aplicar revisión ahora)
Utilice el siguiente procedimiento para aplicar revisiones a los nodos administrados bajo demanda.
**Para ejecutar “Patch now” (Aplicar revisión ahora)**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Elija **Patch now** (Aplicar revisión ahora).
1. En **Patching operation** (Operación de aplicación de revisiones), elija una de las siguientes opciones:
+ **Scan** (Analizar): Patch Manager busca las revisiones que faltan en los nodos administrados, pero no las instala. Puede ver los resultados en el panel **Compliance** o en otras herramientas que utilice para la visualización de la conformidad de las revisiones.
+ **Scan and install** (Analizar e instalar): Patch Manager busca las revisiones faltantes en los nodos administrados y las instala.
1. Utilice este paso solo si eligió la opción **Scan and install** (Analizar e instalar) en el paso anterior. En **Reboot** (Reinicio), elija una de las siguientes opciones:
+ **Reboot if needed** (Reiniciar si es necesario): luego de la instalación, Patch Manager reinicia los nodos administrados solo si es necesario para completar la instalación de una revisión.
+ **Don't reboot my instances** (No reiniciar las instancias): luego de la instalación, Patch Manager no reinicia los nodos administrados. Puede reiniciar los nodos administrados de forma manual en el momento que desee o administrar los reinicios fuera de Patch Manager.
+ **Schedule a reboot time** (Programar una hora de reinicio): especifique la fecha, la hora y la zona horaria UTC para que Patch Manager reinicie los nodos administrados. Después de ejecutar la operación **Patch now** (Aplicar revisión ahora), el reinicio programado aparece como asociación en State Manager con el nombre `AWS-PatchRebootAssociation`.
**importante**
Si cancela la operación principal de aplicación de revisiones una vez iniciada, la asociación `AWS-PatchRebootAssociation` de State Manager NO se cancela automáticamente. Para evitar reinicios inesperados, debe eliminar `AWS-PatchRebootAssociation` manualmente desde State Manager si ya no desea que se produzca el reinicio programado. Si no lo hace, podrían producirse reinicios imprevistos del sistema, lo que podría afectar las cargas de trabajo de producción. Puede encontrar esta asociación en la consola de Systems Manager, en **State Manager** > **Asociaciones**.
1. En **Instances to patch** (Instancias a las que se aplicarán revisiones), elija una de las siguientes opciones:
+ **Patch all instances** (Aplicar revisiones a todas las instancias): Patch Manager ejecuta la operación especificada en todos los nodos administrados en su Cuenta de AWS en la Región de AWS actual.
+ **Patch only the target instances I specify** (Aplicar revisiones solo a las instancias de destino especificadas): debe especificar los nodos administrados a los que se aplican revisiones en el siguiente paso.
1. Utilice este paso solo si elige **Patch only the target instances I specify** (Aplicar revisiones solo a las instancias de destino especificadas) en el paso anterior. En la sección **Target selection** (Selección de destinos), identifique los nodos en los que desea ejecutar esta operación, especifique las etiquetas, seleccione los nodos manualmente o especifique un grupo de recursos.
**nota**
Si un nodo administrado que espera ver no aparece en la lista, consulte [Solución de problemas de disponibilidad de nodos administrados](fleet-manager-troubleshooting-managed-nodes.md) para obtener consejos de solución de problemas.
Si elige como destino un grupo de recursos, tenga en cuenta que estos grupos que se basan en una pila de AWS CloudFormation aún deben etiquetarse con la etiqueta `aws:cloudformation:stack-id` predeterminada. Si se ha eliminado, es posible que Patch Manager no pueda determinar cuáles son los nodos administrados que pertenecen al grupo de recursos.
1. (Opcional) En **Patching log storage** (Almacenamiento de registros de aplicación de revisiones), si desea crear y guardar registros de esta operación de aplicación de revisiones, seleccione el bucket de S3 para almacenar los registros.
**nota**
Los permisos de S3 que conceden la capacidad de escribir datos en un bucket de S3 son los del perfil de instancia (para instancias de EC2) o rol de servicio de IAM (máquinas activadas de manera híbrida) asignados a la instancia, no los del usuario de IAM que realiza esta tarea. Para obtener más información, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md) o [Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube](hybrid-multicloud-service-role.md). Además, si el bucket de S3 especificado se encuentra en una Cuenta de AWS diferente, asegúrese de que el perfil de instancias o el rol de servicio de IAM asociado al nodo administrado tenga los permisos necesarios para escribir en ese bucket.
1. Si desea ejecutar documentos de SSM como enlaces de ciclo de vida durante puntos específicos de la operación de aplicación de revisiones, haga lo siguiente:
+ Elija **Use lifecycle hooks** (Usar enlaces de ciclo de vida).
+ En cada enlace disponible, seleccione el documento de SSM a ejecutar en el punto especificado de la operación:
+ Antes de la instalación
+ Después de la instalación
+ A la salida
+ Después del reinicio programado
**nota**
El documento predeterminado, `AWS-Noop`, no ejecuta operaciones.
1. Elija **Patch now** (Aplicar revisión ahora).
Se abre la página **Association execution summary** (Resumen de la ejecución de la asociación). (La opción “Aplicar el parche ahora” utiliza asociaciones en State Manager, una herramienta de AWS Systems Manager, para sus operaciones). En el área **Operation summary** (Resumen de la operación), puede monitorear el estado del análisis o la aplicación de revisiones en los nodos administrados que especificó.
# Trabajo con línea de base de revisiones
Una línea de base de revisiones en Patch Manager, una herramienta de AWS Systems Manager, define qué revisiones se aprueban para la instalación en los nodos administrados. Puede especificar revisiones aprobadas o rechazadas de forma de uno en uno. También puede crear reglas de aprobación automática para especificar que determinados tipos de actualizaciones (por ejemplo, las actualizaciones críticas) se deben aprobar automáticamente. La lista de rechazados anula las reglas y la lista de aprobados. Para utilizar una lista de revisiones aprobadas para instalar paquetes específicos, primero elimine las reglas de aprobación automática. Si identifica explícitamente una revisión como rechazada, no se aprobará ni instalará, aunque concuerde con todos los criterios de una regla de aprobación automática. Además, una revisión solo se instala en un nodo administrado si se aplica al software de este, aunque haya sido aprobada para el nodo administrado.
**Topics**
+ [Visualización de bases de referencia de parches predefinidas de AWS](patch-manager-view-predefined-patch-baselines.md)
+ [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md)
+ [Configuración de una línea de base de revisiones existente como valor predeterminado](patch-manager-default-patch-baseline.md)
**Más información**
+ [líneas de base de revisiones](patch-manager-patch-baselines.md)
# Visualización de bases de referencia de parches predefinidas de AWS
Patch Manager, una herramienta de AWS Systems Manager, cuenta con una línea de base de revisiones predefinida para todos los sistemas operativos compatibles con Patch Manager. Puede utilizar estas bases de referencia de parches (no puede personalizarlas) o puede crear una. El siguiente procedimiento describe cómo ver una base de referencia de parches predefinida para comprobar si cumple sus necesidades. Para obtener más información sobre las bases de referencia de parches, consulte [Líneas de base de revisiones personalizadas y predefinidas](patch-manager-predefined-and-custom-patch-baselines.md).
**Para ver bases de referencia de parches predefinidas de AWS**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. En la lista de bases de referencia de parches, seleccione el ID de base de referencia de una de las bases de referencia de parches predefinida.
-o bien-
Si va a acceder a Patch Manager por primera vez en la Región de AWS actual, elija **Comenzar con una descripción general**, elija la pestaña **Líneas de base de revisiones**, y luego, elija el ID de la línea de base de una de las líneas de base de revisiones predefinidas.
**nota**
Para Windows Server, se proporcionan tres líneas de base de revisiones predefinidas. Las líneas de base de revisiones `AWS-DefaultPatchBaseline` y `AWS-WindowsPredefinedPatchBaseline-OS` solo admiten actualizaciones del sistema operativo en el propio sistema operativo Windows. `AWS-DefaultPatchBaseline` se utiliza como base de referencia de revisiones predeterminada para los nodos administrados de Windows Server, a menos que se especifique una base de referencia distinta. Los ajustes de configuración en estas dos líneas de base de revisiones son los mismos. El más nuevo de los dos, `AWS-WindowsPredefinedPatchBaseline-OS`, se creó para que se diferenciara de la tercera línea de base de revisiones predefinida para Windows Server. Esa base de referencia de parches, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, puede utilizarse para aplicar parches al sistema operativo Windows Server y a las aplicaciones compatibles publicadas por Microsoft.
Para obtener más información, consulte [Configuración de una línea de base de revisiones existente como valor predeterminado](patch-manager-default-patch-baseline.md).
1. Elija la sección **Reglas de aprobación** y revise la configuración de la línea de base de revisiones.
1. Si la configuración es aceptable para los nodos administrados, puede pasar directamente al procedimiento [Creación y administración de grupos de revisiones](patch-manager-tag-a-patch-group.md).
-o bien-
Para crear su propia base de referencia de parches predeterminada, continúe con el tema [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md).
# Uso de bases de referencia de parches personalizadas
Patch Manager, una herramienta de AWS Systems Manager, cuenta con una línea de base de revisiones predefinida para todos los sistemas operativos compatibles con Patch Manager. Puede utilizar estas bases de referencia de parches (no puede personalizarlas) o puede crear una.
En los siguientes procedimientos se describe cómo crear, actualizar y eliminar su propia base de referencia de parches personalizada. Para obtener más información sobre las bases de referencia de parches, consulte [Líneas de base de revisiones personalizadas y predefinidas](patch-manager-predefined-and-custom-patch-baselines.md).
**Topics**
+ [Creación de una línea de base de revisiones personalizada para Linux](patch-manager-create-a-patch-baseline-for-linux.md)
+ [Cómo crear una línea de base de revisiones personalizada para macOS](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Cómo crear una línea de base de revisiones personalizada para Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
+ [Actualización o eliminación de una línea de base de revisiones personalizada](patch-manager-update-or-delete-a-patch-baseline.md)
# Creación de una línea de base de revisiones personalizada para Linux
Utilice el siguiente procedimiento para crear una línea de base de revisiones personalizada para nodos administrados de Linux en Patch Manager, una herramienta de AWS Systems Manager.
Para obtener información sobre la creación de una base de referencia de revisiones para nodos administrados macOS, consulte [Cómo crear una línea de base de revisiones personalizada para macOS](patch-manager-create-a-patch-baseline-for-macos.md). Para obtener información sobre la creación de una base de referencia de revisiones para nodos administrados de Windows, consulte [Cómo crear una línea de base de revisiones personalizada para Windows Server](patch-manager-create-a-patch-baseline-for-windows.md).
**Para crear una base de referencia de revisiones personalizada para nodos administrados de Linux**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Seleccione la pestaña **Bases de referencia de parches**, y luego **Crear una base de referencia de parches**.
-o bien-
Si va a acceder a Patch Manager por primera vez en la Región de AWS actual, seleccione **Comience por la información general**, luego la pestaña **Bases de referencia de parches** y, por último, **Crear una base de referencia de parches**.
1. En **Nombre**, escriba un nombre para la nueva línea de base de revisiones; por ejemplo, `MyRHELPatchBaseline`.
1. (Opcional) En **Description (Descripción)**, escriba una descripción para esta línea de base de revisiones.
1. En **Operating system (Sistema operativo)** elija un sistema operativo; por ejemplo, `Red Hat Enterprise Linux`.
1. Si desea empezar a utilizar esta línea de base de revisiones de forma predeterminada para el sistema operativo seleccionado tan pronto como la haya creado, active la casilla de verificación situada junto a **Set this patch baseline as the default patch baseline for *operating system name* instances (Establecer esta línea de base de revisiones como la línea de base de revisiones para las instancias de [nombre del sistema operativo])**.
**nota**
Esta opción solo está disponible si accedió a Patch Manager por primera vez antes de las [políticas de parches](patch-manager-policies.md) publicadas el 22 de diciembre de 2022.
Para obtener información sobre la configuración de una línea de base de revisiones existente como la opción predeterminada, consulte [Configuración de una línea de base de revisiones existente como valor predeterminado](patch-manager-default-patch-baseline.md).
1. En la sección **Approval Rules for operating-systems (Reglas de aprobación para sistemas operativos)**, use los campos para crear una o varias reglas de aprobación automática.
+ **Productos**: versión de los sistemas operativos a la que se aplica la regla de aprobación; por ejemplo, `RedhatEnterpriseLinux7.4`. La selección predeterminada es `All`.
+ **Clasificación**: el tipo de revisiones a los que se aplica la regla de aprobación; como `Security` o `Enhancement`. La selección predeterminada es `All`.
**sugerencia**
Puede configurar una línea de base de revisiones para controlar si se instalan actualizaciones de versiones secundarias para Linux, como RHEL 7.8. Patch Manager puede instalar automáticamente actualizaciones de versiones secundarias siempre que la actualización esté disponible en el repositorio adecuado.
Para los sistemas operativos Linux, las actualizaciones de versiones secundarias no se clasifican de forma consistente. Pueden clasificarse como correcciones de errores o actualizaciones de seguridad, o no clasificarse, incluso dentro de la misma versión del kernel. A continuación se muestran algunas opciones para controlar si una línea de base de revisiones las instala.
**Opción 1**: la regla de aprobación más amplia para garantizar que se instalen actualizaciones de versiones secundarias cuando estén disponibles es especificar **Clasificación** como `All` (\$1) y elegir la opción **Incluir las actualizaciones que no sean de seguridad**.
**Opción 2**: para asegurarse de que se instalan revisiones para una versión del sistema operativo, puede utilizar un comodín (\$1) para especificar el formato del kernel en la sección **Excepciones de revisiones** de la base de referencia. Por ejemplo, el formato del kernel para RHEL 7.\$1 es `kernel-3.10.0-*.el7.x86_64`.
Ingrese `kernel-3.10.0-*.el7.x86_64` en la lista **Approved patches** (Revisiones aprobadas) de la base de referencia de revisiones para asegurarse de que todas las revisiones, incluidas las actualizaciones de versiones secundarias, se aplican a los nodos administrados de RHEL 7.\$1. (Si conoce el nombre exacto del paquete de una revisión de versión secundaria, puede escribirlo en su lugar).
**Opción 3**: puede tener el máximo control sobre qué revisiones se aplican a los nodos administrados, incluidas las actualizaciones de versiones secundarias, mediante el parámetro [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist) del documento `AWS-RunPatchBaseline`. Para obtener más información, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
+ **Severity (Gravedad)**: el valor de gravedad de las revisiones a los que se aplica la regla; como `Critical`. La selección predeterminada es `All`.
+ **Auto-approval (Aprobación automática)**: método para seleccionar revisiones para su aprobación automática.
**nota**
Debido a que no es posible determinar de forma fiable las fechas de lanzamiento de los paquetes de actualización para Ubuntu Server, las opciones de aprobación automática no son compatibles con este sistema operativo.
+ **Approve patches after a specified number of days** (Aprobar las revisiones después de una cantidad determinada de días): la cantidad de días que Patch Manager debe esperar después de lanzar o actualizar por última vez una revisión y antes de que se apruebe automáticamente. Puede ingresar cualquier número entero entre cero (0) y 360. En la mayoría de los casos, se recomienda no esperar más de 100 días.
+ **Approve patches released up to a specific date** (Aprobar las revisiones publicadas hasta una fecha específica): la fecha de lanzamiento de la revisión para la que Patch Manager aplica automáticamente todas las revisiones publicadas o actualizadas en esa fecha o con anterioridad a ella. Por ejemplo, si especifica el 7 de julio de 2023, no se instalarán automáticamente las revisiones publicadas o actualizadas a partir del 8 de julio de 2023.
+ (Opcional). **Informes de conformidad**: el nivel de gravedad que desea asignar a las revisiones aprobadas por la línea de base, como `Critical` o `High`.
**nota**
Si especifica un nivel de notificación de conformidad y se informa el estado de cualquier revisión aprobada como `Missing`, la gravedad de la conformidad general notificada por la línea de base de revisiones será el nivel de gravedad que especificó.
+ **Include non-security updates (Incluir actualizaciones que no son de seguridad)**: seleccione esta casilla de verificación para instalar las revisiones del sistema operativo Linux que no son de seguridad y que están disponibles en el repositorio de origen, además de las revisiones relacionados con la seguridad.
Para obtener más información sobre cómo trabajar con reglas de aprobación en una línea de base de revisiones personalizada, consulte [Líneas de base personalizadas](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).
1. Si desea aprobar alguna revisión de forma explícita además de los que cumplan las reglas de aprobación, haga lo siguiente en la sección **Patch exceptions (Excepciones de revisiones)**:
+ En **Approved patches (revisiones aprobados)** escriba una lista separada por comas de las revisiones que desea aprobar.
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
+ (Opcional). En **Approved patches compliance level (Nivel de conformidad de revisiones aprobados)**, asigne un nivel de conformidad a las revisiones de la lista.
+ Si alguna de las revisiones aprobadas que ha especificado no está relacionada con la seguridad, seleccione la casilla de verificación **Incluir actualizaciones no relacionadas con la seguridad** para que se instalen también estas revisiones en su sistema operativo Linux.
1. Si desea rechazar alguna revisión de forma explícita que cumpla las reglas de aprobación, haga lo siguiente en la sección **Patch exceptions (Excepciones de revisiones)**:
+ En **Rejected patches (revisiones rechazados)** escriba una lista separada por comas de las revisiones que desea rechazar.
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
+ En **Rejected patches action** (Acción de revisiones rechazados), seleccione la acción que Patch Manager realizará en las revisiones de la lista **Rejected patches** (revisiones rechazados).
+ **Allow as dependency** (Permitir como dependencia): un paquete en la lista **Rejected patches** (revisiones rechazados) solo se instala si es una dependencia de otro paquete. Se considera conforme con la línea de base de revisiones y su estado se registra como *InstalledOther*. Esta es la opción predeterminada si no se especifica ninguna opción.
+ **Bloquear**: Patch Manager no instala, bajo ninguna circunstancia, los paquetes de la lista **Parches rechazados** y los paquetes que los incluyen como dependencias. Si un paquete se instaló antes de agregarlo a la lista **Parches rechazados**, o si luego se instala por fuera de Patch Manager, se considera no conforme con la línea de base de revisiones y su estado se reporta como *InstalledRejected*.
**nota**
Patch Manager busca las dependencias de las revisiones de forma recursiva.
1. (Opcional) Si desea especificar repositorios de revisiones alternativos para diferentes versiones de un sistema operativo, como *AmazonLinux2016.03* y *AmazonLinux2017.09*, haga lo siguiente para cada producto en la sección **Patch sources (Orígenes de revisiones)**:
+ En **Name (Nombre)**, escriba un nombre que le ayude a identificar la configuración de origen.
+ En **Product (Producto)**, seleccione la versión de los sistemas operativos a los que va dirigido el repositorio de origen de revisiones, por ejemplo `RedhatEnterpriseLinux7.4`.
+ En **Configuración**, ingrese el valor de la configuración del repositorio que desea utilizar en el formato apropiado:
------
#### [ Example for yum repositories ]
```
[main]
name=MyCustomRepository
baseurl=https://my-custom-repository
enabled=1
```
**sugerencia**
Para obtener información sobre otras opciones disponibles para la configuración del repositorio yum, consulte [dnf.conf(5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html).
------
#### [ Examples for Servidor Ubuntu and Servidor Debian ]
`deb http://security.ubuntu.com/ubuntu jammy main`
`deb https://site.example.com/debian distribution component1 component2 component3`
La información del repositorio para los repositorios de Ubuntu Server debe especificarse en una sola línea. Para obtener más ejemplos e información, consulte [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) en el sitio web *Manuales del servidor Ubuntu* y [sources.list format](https://wiki.debian.org/SourcesList#sources.list_format) en la *wiki de Debian*.
------
Elija **Add another source** (Añadir otro origen) para especificar un repositorio de origen para cada versión adicional del sistema operativo, hasta un máximo de 20.
Para obtener más información sobre los repositorios de origen de revisiones alternativos, consulte [Cómo especificar un repositorio de origen de parches alternativo (Linux)](patch-manager-alternative-source-repository.md).
1. (Opcional) En **Manage tags (Administrar etiquetas)**, aplique uno o varios pares de claves nombre/valor al a la línea de base de revisiones.
Las etiquetas son metadatos opcionales que usted asigna a un recurso. Las etiquetas permiten clasificar los recursos de diversas maneras, por ejemplo, según la finalidad, el propietario o el entorno. Por ejemplo, es posible que desee etiquetar una línea de base de revisiones para identificar el nivel de seguridad de revisiones que especifica, la familia de sistemas operativos a la que se aplica y el tipo de entorno. En este caso, puede especificar etiquetas similares a los siguientes pares de claves nombre-valor:
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. Elija **Create patch baseline** (Crear base de referencia de revisiones).
# Cómo crear una línea de base de revisiones personalizada para macOS
Utilice el siguiente procedimiento para crear una línea de base de revisiones personalizada para nodos administrados de macOS en Patch Manager, una herramienta de AWS Systems Manager.
Para obtener información sobre la creación de una base de referencia de revisiones para nodos administrados Windows Server, consulte [Cómo crear una línea de base de revisiones personalizada para Windows Server](patch-manager-create-a-patch-baseline-for-windows.md). Para obtener información sobre la creación de una base de referencia de revisiones para nodos administrados de Linux, consulte [Creación de una línea de base de revisiones personalizada para Linux](patch-manager-create-a-patch-baseline-for-linux.md).
**nota**
macOS no se admite en todas las Regiones de AWS. Para obtener más información sobre la compatibilidad de Amazon EC2 con macOS, consulte [Instancias de Mac de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) en la *Guía del usuario de Amazon EC2*.
**Cómo crear una base de referencia de revisiones personalizada para nodos administrados de macOS**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Seleccione la pestaña **Bases de referencia de parches**, y luego **Crear una base de referencia de parches**.
-o bien-
Si va a acceder a Patch Manager por primera vez en la Región de AWS actual, seleccione **Comience por la información general**, luego la pestaña **Bases de referencia de parches** y, por último, **Crear una base de referencia de parches**.
1. En **Nombre**, escriba un nombre para la nueva línea de base de revisiones; por ejemplo, `MymacOSPatchBaseline`.
1. (Opcional) En **Description (Descripción)**, escriba una descripción para esta línea de base de revisiones.
1. En **Operating system (Sistema operativo)**, elija macOS.
1. Si desea empezar a utilizar esta base de referencia de parches de forma predeterminada para macOS tan pronto como la haya creado, tilde la casilla de verificación situada junto a **Set this patch baseline as the default patch baseline for macOS instances** (Establezca esta base de referencia de parches como la predeterminada para las instancias de macOS).
**nota**
Esta opción solo está disponible si accedió a Patch Manager por primera vez antes de las [políticas de parches](patch-manager-policies.md) publicadas el 22 de diciembre de 2022.
Para obtener información sobre la configuración de una línea de base de revisiones existente como la opción predeterminada, consulte [Configuración de una línea de base de revisiones existente como valor predeterminado](patch-manager-default-patch-baseline.md).
1. En la sección **Approval Rules for operating-systems (Reglas de aprobación para sistemas operativos)**, use los campos para crear una o varias reglas de aprobación automática.
+ **Productos**: versión de los sistemas operativos a la que se aplica la regla de aprobación; por ejemplo, `BigSur11.3.1` o `Ventura13.7`. La selección predeterminada es `All`.
+ **Classification** (Clasificación): el administrador o los administradores de paquetes a los que desea aplicar los paquetes durante el proceso de aplicación de parches. Puede elegir entre las siguientes opciones:
+ softwareupdate
+ installer (instalador)
+ brew
+ brew cask
La selección predeterminada es `All`.
+ (Opcional). **Informes de conformidad**: el nivel de gravedad que desea asignar a las revisiones aprobadas por la línea de base, como `Critical` o `High`.
**nota**
Si especifica un nivel de notificación de conformidad y se informa el estado de cualquier revisión aprobada como `Missing`, la gravedad de la conformidad general notificada por la línea de base de revisiones será el nivel de gravedad que especificó.
Para obtener más información sobre cómo trabajar con reglas de aprobación en una línea de base de revisiones personalizada, consulte [Líneas de base personalizadas](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).
1. Si desea aprobar alguna revisión de forma explícita además de los que cumplan las reglas de aprobación, haga lo siguiente en la sección **Patch exceptions (Excepciones de revisiones)**:
+ En **Approved patches (revisiones aprobados)** escriba una lista separada por comas de las revisiones que desea aprobar.
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
+ (Opcional). En **Approved patches compliance level (Nivel de conformidad de revisiones aprobados)**, asigne un nivel de conformidad a las revisiones de la lista.
1. Si desea rechazar alguna revisión de forma explícita que cumpla las reglas de aprobación, haga lo siguiente en la sección **Patch exceptions (Excepciones de revisiones)**:
+ En **Rejected patches (revisiones rechazados)** escriba una lista separada por comas de las revisiones que desea rechazar.
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
+ En **Rejected patches action** (Acción de revisiones rechazados), seleccione la acción que Patch Manager realizará en las revisiones de la lista **Rejected patches** (revisiones rechazados).
+ **Allow as dependency** (Permitir como dependencia): un paquete en la lista **Rejected patches** (revisiones rechazados) solo se instala si es una dependencia de otro paquete. Se considera conforme con la línea de base de revisiones y su estado se registra como *InstalledOther*. Esta es la opción predeterminada si no se especifica ninguna opción.
+ **Bloquear**: Patch Manager no instala, bajo ninguna circunstancia, los paquetes de la lista **Parches rechazados** y los paquetes que los incluyen como dependencias. Si un paquete se instaló antes de agregarlo a la lista **Parches rechazados**, o si luego se instala por fuera de Patch Manager, se considera no conforme con la línea de base de revisiones y su estado se reporta como *InstalledRejected*.
1. (Opcional) En **Manage tags (Administrar etiquetas)**, aplique uno o varios pares de claves nombre/valor al a la línea de base de revisiones.
Las etiquetas son metadatos opcionales que usted asigna a un recurso. Las etiquetas permiten clasificar los recursos de diversas maneras, por ejemplo, según la finalidad, el propietario o el entorno. Por ejemplo, es posible que desee etiquetar una base de referencia de parches para identificar el nivel de gravedad de parches que especifica, el administrador de paquetes al que se aplica y el tipo de entorno. En este caso, puede especificar etiquetas similares a los siguientes pares de claves nombre-valor:
+ `Key=PatchSeverity,Value=Critical`
+ `Key=PackageManager,Value=softwareupdate`
+ `Key=Environment,Value=Production`
1. Elija **Create patch baseline** (Crear base de referencia de revisiones).
# Cómo crear una línea de base de revisiones personalizada para Windows Server
Utilice el siguiente procedimiento para crear una línea de base de revisiones personalizada para nodos administrados de Windows en Patch Manager, una herramienta de AWS Systems Manager.
Para obtener información sobre la creación de una base de referencia de revisiones para nodos administrados de Linux, consulte [Creación de una línea de base de revisiones personalizada para Linux](patch-manager-create-a-patch-baseline-for-linux.md). Para obtener información sobre la creación de una línea de base de revisiones para nodos administrados macOS, consulte [Cómo crear una línea de base de revisiones personalizada para macOS](patch-manager-create-a-patch-baseline-for-macos.md).
Para obtener un ejemplo de creación de una línea de base de revisiones limitada para instalar únicamente Service Packs de Windows, consulte [Tutorial: creación de una línea de base de revisiones para instalar Service Packs de Windows mediante la consola](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
**Cómo crear una línea de base de revisiones personalizada (Windows)**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Seleccione la pestaña **Bases de referencia de parches**, y luego **Crear una base de referencia de parches**.
-o bien-
Si va a acceder a Patch Manager por primera vez en la Región de AWS actual, seleccione **Comience por la información general**, luego la pestaña **Bases de referencia de parches** y, por último, **Crear una base de referencia de parches**.
1. En **Nombre**, escriba un nombre para la nueva línea de base de revisiones; por ejemplo, `MyWindowsPatchBaseline`.
1. (Opcional) En **Description (Descripción)**, escriba una descripción para esta línea de base de revisiones.
1. En **Operating system (Sistema operativo)**, elija `Windows`.
1. En **Estado de cumplimiento de las actualizaciones de seguridad disponibles**, elija el estado que desee asignar a las revisiones de seguridad que están disponibles pero no aprobadas, porque no cumplen con los criterios de instalación especificados en la línea de base de revisiones: **No conforme** o **Conforme**.
Situación de ejemplo: las revisiones de seguridad que desee instalar se pueden omitir si ha especificado un periodo prolongado de espera después del lanzamiento de la revisión antes de la instalación. Si se publica una actualización de la revisión durante el periodo de espera especificado, el periodo de espera para instalar la revisión vuelve a comenzar. Si el periodo de espera es demasiado extenso, es posible que se lancen varias versiones de la revisión, pero nunca se instalen.
1. Si desea comenzar a utilizar esta línea de base de revisiones de forma predeterminada para Windows tan pronto como la cree, seleccione **Set this patch baseline as the default patch baseline for Windows Server instances (Establecer esta línea de base de revisiones como la línea de base de revisiones predeterminada para las instancias de Windows Server)**.
**nota**
Esta opción solo está disponible si accedió a Patch Manager por primera vez antes de las [políticas de parches](patch-manager-policies.md) publicadas el 22 de diciembre de 2022.
Para obtener información sobre la configuración de una línea de base de revisiones existente como la opción predeterminada, consulte [Configuración de una línea de base de revisiones existente como valor predeterminado](patch-manager-default-patch-baseline.md).
1. En la sección **Approval Rules for operating systems (Reglas de aprobación para sistemas operativos)**, use los campos para crear una o varias reglas de aprobación automática.
+ **Productos**: versión de los sistemas operativos a la que se aplica la regla de aprobación; por ejemplo, `WindowsServer2012`. La selección predeterminada es `All`.
+ **Clasificación**: el tipo de revisiones a los que se aplica la regla de aprobación; como `CriticalUpdates`, `Drivers` y `Tools`. La selección predeterminada es `All`.
**sugerencia**
Puede incluir instalaciones de Service Packs de Windows en las reglas de aprobación incluyendo `ServicePacks` o eligiendo `All` en la lista **Clasificación**. Para ver un ejemplo, consulta [Tutorial: creación de una línea de base de revisiones para instalar Service Packs de Windows mediante la consola](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
+ **Severity (Gravedad)**: el valor de gravedad de las revisiones a los que se aplica la regla; como `Critical`. La selección predeterminada es `All`.
+ **Auto-approval (Aprobación automática)**: método para seleccionar revisiones para su aprobación automática.
+ **Approve patches after a specified number of days** (Aprobar las revisiones después de una cantidad determinada de días): la cantidad de días que Patch Manager debe esperar después de que se lance o actualice una revisión y antes de que se apruebe automáticamente. Puede ingresar cualquier número entero entre cero (0) y 360. En la mayoría de los casos, se recomienda no esperar más de 100 días.
+ **Approve patches released up to a specific date** (Aprobar las revisiones publicadas hasta una fecha específica): la fecha de lanzamiento de la revisión para la que Patch Manager aplica automáticamente todas las revisiones publicadas o actualizadas en esa fecha o con anterioridad a ella. Por ejemplo, si especifica el 7 de julio de 2023, no se instalarán automáticamente las revisiones publicadas o actualizadas a partir del 8 de julio de 2023.
+ (Opcional). **Compliance reporting** (Informes de conformidad): el nivel de gravedad que desea asignar a las revisiones aprobadas por la base de referencia, como `High`.
**nota**
Si especifica un nivel de notificación de conformidad y se informa el estado de cualquier revisión aprobada como `Missing`, la gravedad de la conformidad general notificada por la línea de base de revisiones será el nivel de gravedad que especificó.
1. (Opcional) En la sección **Approval rules for applications** (Reglas de aprobación para aplicaciones) use los campos para crear una o más reglas de aprobación automática.
**nota**
En lugar de especificar reglas de aprobación, puede especificar Listas de revisiones aprobados y rechazados como excepciones de revisiones. Consulte los pasos 10 y 11.
+ **Product family (Familia de productos)**: la familia de productos de Microsoft generales para la que desea especificar una regla, como, por ejemplo, `Office` o `Exchange Server`.
+ **Productos**: versión de la aplicación a la que se aplica la regla de aprobación; por ejemplo, `Office 2016` o `Active Directory Rights Management Services Client 2.0 2016`. La selección predeterminada es `All`.
+ **Classification (Clasificación)**: el tipo de revisiones a los que se aplica la regla de aprobación; como `CriticalUpdates`. La selección predeterminada es `All`.
+ **Severity (Gravedad)**: el valor de gravedad de las revisiones a los que se aplica la regla, como `Critical`. La selección predeterminada es `All`.
+ **Auto-approval (Aprobación automática)**: método para seleccionar revisiones para su aprobación automática.
+ **Approve patches after a specified number of days** (Aprobar las revisiones después de una cantidad determinada de días): la cantidad de días que Patch Manager debe esperar después de que se lance o actualice una revisión y antes de que se apruebe automáticamente. Puede ingresar cualquier número entero entre cero (0) y 360. En la mayoría de los casos, se recomienda no esperar más de 100 días.
+ **Approve patches released up to a specific date** (Aprobar las revisiones publicadas hasta una fecha específica): la fecha de lanzamiento de la revisión para la que Patch Manager aplica automáticamente todas las revisiones publicadas o actualizadas en esa fecha o con anterioridad a ella. Por ejemplo, si especifica el 7 de julio de 2023, no se instalarán automáticamente las revisiones publicadas o actualizadas a partir del 8 de julio de 2023.
+ (Opcional). **Informes de conformidad**: el nivel de gravedad que desea asignar a las revisiones aprobadas por la línea de base, como `Critical` o `High`.
**nota**
Si especifica un nivel de notificación de conformidad y se informa el estado de cualquier revisión aprobada como `Missing`, la gravedad de la conformidad general notificada por la línea de base de revisiones será el nivel de gravedad que especificó.
1. (Opcional) Si desea aprobar explícitamente las revisiones en lugar de dejar que estos se seleccionen conforme a las reglas de aprobación, haga lo siguiente en la sección **Patch exceptions** (Excepciones de revisiones):
+ En **Approved patches (revisiones aprobados)** escriba una lista separada por comas de las revisiones que desea aprobar.
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
+ (Opcional). En **Approved patches compliance level (Nivel de conformidad de revisiones aprobados)**, asigne un nivel de conformidad a las revisiones de la lista.
1. Si desea rechazar alguna revisión de forma explícita que cumpla las reglas de aprobación, haga lo siguiente en la sección **Patch exceptions (Excepciones de revisiones)**:
+ En **Rejected patches (revisiones rechazados)** escriba una lista separada por comas de las revisiones que desea rechazar.
Para obtener información acerca de los formatos aceptados para las Listas de revisiones aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
+ En **Rejected patches action** (Acción de revisiones rechazados), seleccione la acción que Patch Manager realizará en las revisiones de la lista **Rejected patches** (revisiones rechazados).
+ **Permitir como dependencia**: Windows Server no admite el concepto de dependencias de paquetes. Si un paquete está en la lista de **revisiones rechazadas** y ya está instalada en el nodo, su estado se indica como `INSTALLED_OTHER`. Se omite cualquier paquete que aún no esté instalado en el nodo.
+ **Bloquear**: Patch Manager no instala los paquetes de la lista de **revisiones rechazadas** bajo ninguna circunstancia. Si un paquete se instaló antes de agregarlo a la lista **Versiones rechazadas**, o si luego se instala por fuera de Patch Manager, se considera no conforme con la línea de base de revisiones y su estado se reporta como `INSTALLED_REJECTED`.
Para obtener más información sobre las acciones de los paquetes rechazados, consulte las [opciones de la lista de revisiones rechazadas en las líneas de base de revisiones personalizadas](patch-manager-windows-and-linux-differences.md#rejected-patches-diff).
1. (Opcional) En **Manage tags (Administrar etiquetas)**, aplique uno o varios pares de claves nombre/valor al a la línea de base de revisiones.
Las etiquetas son metadatos opcionales que usted asigna a un recurso. Las etiquetas permiten clasificar los recursos de diversas maneras, por ejemplo, según la finalidad, el propietario o el entorno. Por ejemplo, es posible que desee etiquetar una línea de base de revisiones para identificar el nivel de seguridad de revisiones que especifica, la familia de sistemas operativos a la que se aplica y el tipo de entorno. En este caso, puede especificar etiquetas similares a los siguientes pares de claves nombre-valor:
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. Elija **Create patch baseline** (Crear base de referencia de revisiones).
# Actualización o eliminación de una línea de base de revisiones personalizada
Puede actualizar o eliminar una línea de base de revisiones personalizada que haya creado en Patch Manager, una herramienta de AWS Systems Manager. Al actualizar una línea de base de revisiones, puede cambiar su nombre o descripción, sus reglas de aprobación y sus excepciones para revisiones aprobadas y rechazadas. También puede actualizar las etiquetas que se aplican a la línea de base de revisiones. No se puede cambiar el tipo de sistema operativo para el que se ha creado una línea de base de revisiones y no puede realizar cambios en una línea de base de revisiones predefinida que AWS proporciona.
## Actualización o eliminación de una línea de base de revisiones
Siga estos pasos para actualizar o eliminar una línea de base de revisiones.
**importante**
Tenga cuidado al eliminar una línea de base de revisiones personalizada que pueda utilizar una configuración de política de revisiones en Quick Setup.
Si utiliza una [configuración de política de revisiones](patch-manager-policies.md) en Quick Setup, las actualizaciones que realice en las líneas de base de revisiones personalizadas se sincronizan con Quick Setup cada hora.
Si se elimina una línea de base de revisiones personalizada a la que se hacía referencia en una política de revisiones, aparece un banner en la página **Configuration details** (Detalles de configuración) de Quick Setup correspondiente a la política de revisiones. El banner le informa que la política de revisiones hace referencia a una línea de base de revisiones que ya no existe y que las operaciones de aplicación de revisiones posteriores fallarán. En este caso, vuelva a la página **Configurations** (Configuraciones) de Quick Setup, seleccione la configuración de Patch Manager y elija **Actions** (Acciones), **Edit configuration** (Editar configuración). El nombre de la línea de base de revisiones eliminado aparece resaltado y debe seleccionar una nueva línea de base de revisiones para el sistema operativo afectado.
**Para actualizar o eliminar una línea de base de revisiones**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Elija la línea de base de revisiones que desea actualizar o eliminar y, a continuación, lleve a cabo alguna de las siguientes operaciones:
+ Para eliminar la línea de base de revisiones de su Cuenta de AWS, elija **Delete** (Eliminar). El sistema le pedirá que confirme sus acciones.
+ Para cambiar el nombre o la descripción de la línea de base de revisiones, las reglas de aprobación o las excepciones de revisiones, elija **Edit (Editar)**. En la página **Edit patch baseline** (Editar línea de base de revisiones), cambie los valores y las opciones que desee y, a continuación, elija **Save changes (Guardar cambios)**.
+ Para añadir, cambiar o eliminar etiquetas aplicadas a la línea de base de revisiones, elija la pestaña **Tags** (Etiquetas) y, a continuación, elija **Edit tags (Editar etiquetas)**. En la página **Edit patch baseline tags** (Editar etiquetas de línea de base de revisiones), lleve a cabo actualizaciones de las etiquetas de la línea de base de revisiones y, a continuación, elija **Save changes** (Guardar cambios).
Para obtener más información acerca de las opciones de configuración que puede realizar, consulte [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md).
# Configuración de una línea de base de revisiones existente como valor predeterminado
**importante**
Las selecciones de línea de base de revisiones predeterminadas que realice aquí no se aplicarán a las operaciones de aplicación de revisiones basadas en una política de revisiones. Las políticas de revisiones utilizan sus propias especificaciones de línea de base de revisiones. Para obtener más información sobre las políticas de revisiones, consulte [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md).
Cuando se crea una línea de base de revisiones personalizada en Patch Manager, una herramienta de AWS Systems Manager, puede establecer la base de referencia como valor predeterminado para el tipo de sistema operativo asociado tan pronto como la crea. Para obtener más información, consulte [Uso de bases de referencia de parches personalizadas](patch-manager-manage-patch-baselines.md).
También puede definir una línea de base de revisiones ya existente de como valor predeterminado para un tipo de sistema operativo.
**nota**
Los pasos que siga dependerán de si accedió por primera vez a Patch Manager antes o después del lanzamiento de las políticas de revisiones el 22 de diciembre de 2022. Si utilizó Patch Manager antes de esa fecha, puede utilizar el procedimiento de la consola. De lo contrario, utilice el procedimiento de AWS CLI. El menú **Acciones** al que se hace referencia en el procedimiento de la consola no se muestra en las regiones en las que Patch Manager no se utilizaba antes de la publicación de las políticas de revisiones.
**Para definir una línea de base de revisiones como la opción predeterminada**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Elija la pestaña **Patch baselines** (Bases de referencia de parches).
1. En la lista de bases de referencia de parches, elija el botón de una base de referencia de parches que no esté definida actualmente como la predeterminada para un tipo de sistema operativo.
La columna **Default baseline** (Base de referencia de revisiones predeterminada) indica qué líneas de base de revisiones están actualmente definidas como los valores predeterminados.
1. En el menú **Actions (Acciones)**, elija **Set default patch baseline (Definir línea de base de revisiones predeterminada)**.
**importante**
El menú **Acciones** no está disponible si no trabajó con Patch Manager en la Cuenta de AWS y la región actuales antes del 22 de diciembre de 2022. Para obtener más información, consulte la **Nota** que aparece anteriormente en este tema.
1. En el cuadro de diálogo de confirmación, elija **Set default (Definir valor predeterminado)**.
**Para definir una línea de base de revisiones como la opción predeterminada (AWS CLI)**
1. Ejecute el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-baselines.html) para ver una lista de las líneas de base de revisiones disponibles y sus ID y nombres de recursos de Amazon (ARN).
```
aws ssm describe-patch-baselines
```
1. Ejecute el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-default-patch-baseline.html) para establecer una línea de base como predeterminada para el sistema operativo al que está asociada. Reemplace *baseline-id-or-ARN* con el ID de la línea de base de revisiones personalizada o la línea de base de preferencia que se utilizará.
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--baseline-id baseline-id-or-ARN
```
A continuación, se muestra un ejemplo de configuración de una línea de base personalizada como predeterminada.
```
aws ssm register-default-patch-baseline \
--baseline-id pb-abc123cf9bEXAMPLE
```
A continuación, se muestra un ejemplo de configuración de una línea de base de preferencia administrada por AWS como predeterminada.
```
aws ssm register-default-patch-baseline \
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-0574b43a65ea646e
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--baseline-id baseline-id-or-ARN
```
A continuación, se muestra un ejemplo de configuración de una línea de base personalizada como predeterminada.
```
aws ssm register-default-patch-baseline ^
--baseline-id pb-abc123cf9bEXAMPLE
```
A continuación, se muestra un ejemplo de configuración de una línea de base de preferencia administrada por AWS como predeterminada.
```
aws ssm register-default-patch-baseline ^
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
```
------
# Visualización de parches disponibles
Patch Manager, una herramienta de AWS Systems Manager, permite que vea todos los parches disponibles para un sistema operativo especificado y, de manera opcional, una versión específica de este.
**sugerencia**
Para generar una lista de revisiones disponibles y guardarlos en un archivo, puede utilizar el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-available-patches.html) y especificar su [salida](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html) preferida.
**Para ver los parches disponibles**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Elija la pestaña **Patches** (Parches).
-o bien-
Si va a acceder a Patch Manager por primera vez en la Región de AWS actual, seleccione **Comience por la información general**, y luego la pestaña **Parches**.
**nota**
Para Windows Server, la pestaña **Revisiones** muestra las actualizaciones que están disponibles en el Servicio de actualizaciones de Windows Server (WSUS).
1. En **Operating system** (Sistema operativo), elija el sistema operativo para el que desea ver los parches disponibles, como `Windows` o `Amazon Linux`.
1. (Opcional) En **Product** (Producto), elija una versión del sistema operativo, como `WindowsServer2019` o `AmazonLinux2018.03`.
1. (Opcional) Para agregar o eliminar columnas de información para sus resultados, elija el botón de configuración (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/configure-button.png)) en la parte superior derecha de la lista **Patches** (Parches). (De forma predeterminada, la pestaña **Patches** (Parches) muestra columnas solo para algunos de los metadatos de parches disponibles).
Para obtener información acerca de los tipos de metadatos que puede agregar a la vista, consulte [Parche](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html) en la *Referencia de la API de AWS Systems Manager*.
# Creación y administración de grupos de revisiones
Si *no* utiliza políticas de revisiones en las operaciones, puede utilizar las acciones de aplicación de revisiones mediante el uso de etiquetas para agregar nodos administrados a grupos de revisiones.
**nota**
Los grupos de revisiones no se usan en operaciones de aplicación de revisiones basadas en *políticas de revisiones*. Para obtener información sobre el uso de las políticas de revisiones, consulte [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md).
La consola no admite la funcionalidad de grupos de parches para pares de cuentas y regiones que no usaban grupos de parches antes de que se publicara la compatibilidad con las políticas de parches el 22 de diciembre de 2022. La funcionalidad de grupos de parches sigue estando disponible en los pares de cuentas y regiones que empezaron a usar grupos de parches antes de esta fecha.
Para utilizar etiquetas en las operaciones de aplicación de revisiones, debe aplicar la clave de etiqueta `Patch Group` o `PatchGroup` a los nodos administrados. También debe especificar el nombre que quiere dar al grupo de revisiones como el valor de la etiqueta. Puede especificar cualquier valor de etiqueta, pero la clave de etiqueta debe ser `Patch Group` o `PatchGroup`.
Tiene que usar `PatchGroup` (sin espacio), si ha [permitido las etiquetas en los metadatos de las instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS).
Después de agrupar los nodos administrados mediante etiquetas, tiene que agregar el valor de grupo de revisiones a una base de referencia de revisiones. Al registrar el grupo de revisiones en una línea de base de revisiones, se asegura de que se instalen las revisiones correctas durante la operación de aplicación de revisiones. Para obtener más información acerca de los grupos de revisiones, consulte [Grupos de revisiones](patch-manager-patch-groups.md).
Complete las tareas de este tema para preparar los nodos administrados para la aplicación de revisiones mediante etiquetas con los nodos y la línea de base de revisiones. La tarea 1 solo es necesaria si está implementando revisiones a las instancias de Amazon EC2. La tarea 2 solo es necesaria si va a aplicar revisiones a instancias que no son de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). La tarea 3 es necesaria para todos los nodos administrados.
**sugerencia**
Además, puede agregar etiquetas a nodos administrados mediante el AWS CLI comando `[https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/add-tags-to-resource.html)` de la o la operación de API de Systems Manager ssm-agent-minimum-s3-permissions-required`[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)`.
**Topics**
+ [Tarea 1: añadir instancias EC2 a un grupo de parches mediante etiquetas](#sysman-patch-group-tagging-ec2)
+ [Tarea 2: agregar nodos administrados a un grupo de revisiones mediante etiquetas](#sysman-patch-group-tagging-managed)
+ [Tarea 3: añadir un grupo de revisiones a una línea de base de revisiones](#sysman-patch-group-patchbaseline)
## Tarea 1: añadir instancias EC2 a un grupo de parches mediante etiquetas
Puede agregar etiquetas a instancias de EC2 administradas mediante la consola de Amazon EC2 o la línea de comandos de Systems Manager. Esta tarea solo es necesaria si está aplicando revisiones a las instancias de Amazon EC2.
**importante**
Puede aplicar la etiqueta `Patch Group` (con un espacio) a una instancia de Amazon EC2 si la opción **Allow tags in instance metadata** (Permitir etiquetas en los metadatos de la instancia) no puede estar habilitada en la instancia. Al permitir etiquetas en los metadatos de la instancia, se impide que los nombres de las claves de las etiquetas contengan espacios. Si tiene [etiquetas permitidas en metadatos de instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), debe usar la clave de etiqueta `PatchGroup` (sin espacio).
**Opción 1: agregar instancias de EC2 administradas a un grupo de revisiones (consola de Systems Manager)**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Fleet Manager**.
1. En la lista **Nodos administrados**, elija el ID de una instancia de EC2 administrada que desee configurar para la aplicación de revisiones. Los ID de nodo de las instancias de EC2 comienzan con `i-`.
**nota**
Cuando se utiliza la consola de Amazon EC2 y la AWS CLI, es posible aplicar etiquetas `Key = Patch Group` o `Key = PatchGroup` a instancias que aún no están configuradas para utilizarlas con Systems Manager.
Si un nodo administrado que espera ver no aparece en la lista, consulte [Solución de problemas de disponibilidad de nodos administrados](fleet-manager-troubleshooting-managed-nodes.md) para obtener consejos de solución de problemas.
1. Seleccione la pestaña **Etiquetas** y, luego, elija **Editar**.
1. En la columna izquierda, ingrese **Patch Group** o **PatchGroup**. Si ha [permitido las etiquetas en los metadatos de las instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), debe usar `PatchGroup` (sin espacio).
1. En la columna de la derecha, ingrese un valor de etiqueta que lo identifique como nombre para este grupo de revisiones.
1. Seleccione **Save**.
1. Repita este procedimiento para agregar otras instancias de EC2 en el mismo grupo de revisiones.
**Opción 2: agregar instancias de EC2 a un grupo de revisiones (consola de Amazon EC2)**
1. Abra la [consola de Amazon EC2](https://console.aws.amazon.com/ec2/) y, a continuación, elija **Instances** (Instancias) en el panel de navegación.
1. En la lista de instancias, elija la que desea configurar para la aplicación de revisiones.
1. En el menú **Acciones**, elija **Configuración de instancia**, **Administrar etiquetas**.
1. Elija **Añadir nueva etiqueta**.
1. En **Key** (Clave), ingrese **Patch Group** o **PatchGroup**. Si ha [permitido las etiquetas en los metadatos de las instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), debe usar `PatchGroup` (sin espacio).
1. Para **Valor**, escriba un valor que sirva como nombre para este grupo de revisiones.
1. Seleccione **Save**.
1. Repita este procedimiento para añadir otras instancias en el mismo grupo de revisiones.
## Tarea 2: agregar nodos administrados a un grupo de revisiones mediante etiquetas
Siga los pasos de este tema para añadir etiquetas a los dispositivos principales AWS IoT Greengrass y a los nodos administrados activados de manera híbrida (mi-\$1) que no son de EC2. Esta tarea solo es necesaria si va a aplicar revisiones a instancias que no son de EC2 en un entorno híbrido y multinube.
**nota**
No puede agregar etiquetas para los nodos administrados que no son de EC2 mediante la consola de Amazon EC2.
**Para agregar nodos administrados que no son de EC2 a un grupo de revisiones (consola de Systems Manager)**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Fleet Manager**.
1. En la lista de **Nodos administrados**, elija el nombre del nodo administrado que desea configurar para aplicar revisiones.
**nota**
Si un nodo administrado que espera ver no aparece en la lista, consulte [Solución de problemas de disponibilidad de nodos administrados](fleet-manager-troubleshooting-managed-nodes.md) para obtener consejos de solución de problemas.
1. Seleccione la pestaña **Etiquetas** y, luego, elija **Editar**.
1. En la columna izquierda, ingrese **Patch Group** o **PatchGroup**. Si ha [permitido las etiquetas en los metadatos de las instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), debe usar `PatchGroup` (sin espacio).
1. En la columna de la derecha, ingrese un valor de etiqueta que lo identifique como nombre para este grupo de revisiones.
1. Seleccione **Save**.
1. Repita este procedimiento para agregar otros nodos administrados en el mismo grupo de revisiones.
## Tarea 3: añadir un grupo de revisiones a una línea de base de revisiones
Para asociar una base de referencia de revisiones específica a los nodos administrados, tiene que agregar el valor del grupo de revisiones a la base de referencia de revisiones. Al registrar el grupo de revisiones con una línea de base de revisiones, se asegura de que se instalen las revisiones correctos durante la operación de aplicación de revisiones. Esta tarea es necesaria si va a aplicar revisiones a instancias de EC2, a nodos administrados que no son de EC2 o a ambos.
Para obtener más información acerca de los grupos de revisiones, consulte [Grupos de revisiones](patch-manager-patch-groups.md).
**nota**
Los pasos que siga dependerán de si accedió por primera vez a Patch Manager antes o después del lanzamiento de las [políticas de revisiones](patch-manager-policies.md) el 22 de diciembre de 2022.
**Para añadir un grupo de revisiones a una línea de base de revisiones (consola de Systems Manager)**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Si accede a Patch Manager por primera vez en la Región de AWS actual y se abre la página de inicio de Patch Manager, elija **Comenzar con una descripción general**.
1. Elija la pestaña **Líneas de base de revisiones** y, luego, en la lista **Líneas de base de revisiones**, elija la línea de base de revisiones que desea configurar para su grupo de revisiones.
Si no accedió por primera vez a Patch Manager hasta después de la publicación de las políticas de revisiones, debe elegir una línea de base personalizada que haya creado.
1. Si la página de detalles del **ID de línea base** incluye un menú **Acciones**, haga lo siguiente:
+ Elija **Actions (Acciones)** y luego **Modify patch groups (Modificar grupos de revisiones)**.
+ Ingrese el *valor* de la etiqueta que ha agregado a los nodos administrados en [Tarea 2: agregar nodos administrados a un grupo de revisiones mediante etiquetas](#sysman-patch-group-tagging-managed) y, a continuación, elija **Agregar**.
Si la página de detalles del **ID de línea de base** *no* incluye un menú **Acciones**, los grupos de revisiones no se pueden configurar en la consola. En cambio, puede seguir uno de los procedimientos a continuación:
+ (Recomendado) Configure una política de revisiones en Quick Setup, una herramienta de AWS Systems Manager, para asignar una línea de base de revisiones a una o más instancias de EC2.
Para obtener más información, consulte [Uso de políticas de revisiones de Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) y [Automatizar la implementación de revisiones en toda la organización mediante una política de revisiones de Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
+ Utilice el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/register-patch-baseline-for-patch-group.html) en AWS Command Line Interface (AWS CLI) para configurar un grupo de revisiones.
# Integración de Patch Manager con AWS Security Hub CSPM
[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) proporciona una visión completa de su estado de seguridad en AWS. Security Hub CSPM recopila datos de seguridad de todas las Cuentas de AWS, los Servicios de AWS y los productos de socios terceros compatibles. Security Hub CSPM le permite comprobar su entorno con los estándares y las prácticas recomendadas del sector de la seguridad. Security Hub CSPM lo ayuda a analizar sus tendencias de seguridad y a identificar los problemas de seguridad de mayor prioridad.
Gracias a la integración entre Patch Manager, una herramienta de AWS Systems Manager, y Security Hub CSPM, puede enviar los resultados sobre los nodos no conformes de Patch Manager a Security Hub CSPM. Un resultado consiste en el registro observable de una comprobación de seguridad o de una detección relacionada con la seguridad. Después, Security Hub CSPM puede incluir esos resultados relacionados con revisiones en su análisis sobre la posición de seguridad.
La información en los siguientes temas se aplica independientemente del método o el tipo de configuración que utilice para las operaciones de aplicación de revisiones:
+ Una política de revisiones configurada en Quick Setup
+ Una opción de administración de host configurada en Quick Setup
+ Una ventana de mantenimiento para ejecutar una revisión `Scan` o una tarea `Install`
+ Una operación **Patch Now** (Aplicar revisión ahora) bajo demanda
**Contents**
+ [Cómo Patch Manager envía resultados al CSPM de Security Hub](#securityhub-integration-sending-findings)
+ [Tipos de resultados que envía Patch Manager](#securityhub-integration-finding-types)
+ [Latencia para el envío de resultados](#securityhub-integration-finding-latency)
+ [Reintento cuando Security Hub CSPM no está disponible](#securityhub-integration-retry-send)
+ [Visualización de resultados de en el CSPM de Security Hub](#securityhub-integration-view-findings)
+ [Resultado típico de Patch Manager](#securityhub-integration-finding-example)
+ [Activación y configuración de la integración](#securityhub-integration-enable)
+ [Cómo dejar de enviar resultados](#securityhub-integration-disable)
## Cómo Patch Manager envía resultados al CSPM de Security Hub
En el CSPM de Security Hub, se realiza seguimiento de los problemas de seguridad como resultados. Algunos resultados provienen de problemas detectados por otros Servicios de AWS o por socios terceros. El CSPM de Security Hub también cuenta con un conjunto de reglas que utiliza para detectar problemas de seguridad y generar resultados.
Patch Manager es una de las herramientas de Systems Manager que envía los resultados a Security Hub CSPM. Después de llevar a cabo una operación de aplicación de revisiones mediante la ejecución de un documento de SSM (`AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` o `AWS-RunPatchBaselineWithHooks`), la información de revisión se envía a Inventario o Cumplimiento, herramientas de AWS Systems Manager, o ambas. Después de que Inventory, Compliance o ambos hayan recibido los datos, Patch Manager recibe una notificación. A continuación, Patch Manager evalúa los datos para comprobar la precisión, el formato y la conformidad. Si se cumplen todas las condiciones, Patch Manager reenvía los datos a Security Hub CSPM.
El CSPM de Security Hub proporciona herramientas para administrar resultados procedentes de todos estos orígenes. Puede ver y filtrar listas de resultados y ver los detalles de una búsqueda. Para obtener más información, consulte [Visualización de resultados](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html) en la *Guía del usuario de AWS Security Hub*. También puede realizar un seguimiento del estado de una investigación de un resultado. Para obtener más información, consulte [Adopción de medidas en función de los resultados](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html) en la *Guía del usuario de AWS Security Hub*.
Todos los resultados en Security Hub CSPM usan un formato JSON estándar llamado Formato AWS Security Finding (ASFF). El ASFF incluye detalles sobre el origen del problema, los recursos afectados y el estado actual del resultado. Para obtener más información, consulte [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm) en la *Guía del usuario de AWS Security Hub*.
### Tipos de resultados que envía Patch Manager
Patch Manager envía los resultados a Security Hub CSPM mediante [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html). En ASFF, el campo `Types` proporciona el tipo de resultado. Los resultados de Patch Manager tienen el siguiente valor para `Types`:
+ Verificaciones de software y configuración/Administración de revisiones
Patch Manager envía una búsqueda por nodo administrado no conforme. El resultado se notifica con el tipo de recurso de [https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance](https://docs.aws.amazon.com//securityhub/latest/userguide/securityhub-findings-format-attributes.html#asff-resourcedetails-awsec2instance) para que los resultados puedan relacionarse con otras integraciones de Security Hub CSPM que notifican tipos de recursos de `AwsEc2Instance`. Patch Manager solo envía un resultado a Security Hub CSPM si la operación detectó que el nodo administrado no era conforme. El resultado incluye los datos del resumen de revisiones.
**nota**
Tras informar de un nodo no conforme a Security Hub CSPM, Patch Manager no envía una actualización a Security Hub CSPM cuando el nodo cumple con las normas. Puede resolver manualmente los resultados en Security Hub CSPM una vez que se hayan aplicado las revisiones necesarias al nodo administrado.
Para obtener más información acerca de las definiciones de conformidad, consulte [Valores de estado de conformidad de las revisiones](patch-manager-compliance-states.md). Para obtener más información acerca de `PatchSummary`, consulte [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html) en la *Referencia de la API de AWS Security Hub*.
### Latencia para el envío de resultados
Cuando Patch Manager crea un nuevo resultado, por lo general, se envía a Security Hub CSPM en un plazo de entre unos pocos segundos y 2 horas. La velocidad varía en función del tráfico de la Región de AWS que se esté procesando en ese momento.
### Reintento cuando Security Hub CSPM no está disponible
Si hay una interrupción del servicio, se ejecuta una función de AWS Lambda para devolver los mensajes a la cola principal una vez que el servicio vuelve a funcionar. Una vez que los mensajes se encuentran en la cola principal, la acción de reintentar es automática.
Si Security Hub CSPM no está disponible, Patch Manager reintenta enviar los resultados hasta que se reciban.
### Visualización de resultados de en el CSPM de Security Hub
Este procedimiento describe cómo ver en Security Hub CSPM los resultados sobre los nodos administrados de su flota no conformes con las revisiones.
**Revision de los resultados de Security Hub CSPM con el objetivo de comprobar el cumplimiento de las revisiones**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de AWS Security Hub CSPM en [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/).
1. En el panel de navegación, seleccione **Findings (Resultados)**.
1. Seleccione la casilla **Agregar filtros** (![\[The Search icon\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/search-icon.png)).
1. En el menú, en **Filtros**, seleccione **Nombre del producto**.
1. En el cuadro de diálogo que se abre, elija **es** en el primer campo y, a continuación, introduzca **Systems Manager Patch Manager** en el segundo campo.
1. Seleccione **Aplicar**.
1. Agregue los filtros adicionales que desee para reducir los resultados.
1. En la lista de resultados, elija el título de un resultado sobre el que desee obtener más información.
Se abre un panel en la parte derecha de la pantalla con más detalles sobre el recurso, el problema descubierto y una solución recomendada.
**importante**
En este momento, Security Hub CSPM informa que el tipo de recurso de todos los nodos administrados es `EC2 Instance`. Esto incluye servidores en las instalaciones y las máquinas virtuales (VM) que haya registrado para utilizarlas con Systems Manager.
**Clasificaciones de gravedad**
La lista de resultados para **Systems Manager Patch Manager**, incluye un informe sobre la gravedad del resultado. Los niveles de **gravedad** incluyen los siguientes, de el más bajo al más alto:
+ **INFORMATIVO**: no se encontró ningún problema.
+ **BAJO**: el problema no requiere solución.
+ **MEDIO**: el problema debe abordarse, pero no es urgente.
+ **ALTO**: el problema debe abordarse con prioridad.
+ **CRÍTICO**: el problema debe solucionarse de inmediato para evitar una escalada.
La gravedad se determina según el paquete de incumplimiento más severo de una instancia. Como puede tener varios líneas de base de revisiones con varios niveles de gravedad, se indica el nivel de severidad más alto de todos los paquetes no conformes. Por ejemplo, supongamos que tiene dos paquetes no conformes en los que la gravedad del paquete A es “crítica” y la del paquete B es “baja”. La gravedad se indicará como “crítica”.
Tenga en cuenta que el campo de gravedad se correlaciona directamente con el campo Patch Manager `Compliance`. Se trata de un campo que puede configurar para asignar a las revisiones individuales que coincidan con la regla. Como este campo `Compliance` está asignado a revisiones individuales, no se refleja en el nivel de resumen de revisiones.
**Contenido relacionado**
+ [Resultados](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html) en la *Guía del usuario de AWS Security Hub*
+ [Cumplimiento de las revisiones multicuenta con Patch Manager y Security Hub](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/) en el blog *de administración y gobernanza de AWS*
## Resultado típico de Patch Manager
Patch Manager envía los resultados a Security Hub CSPM mediante [AWS Security Finding Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html).
Aquí hay un ejemplo de un hallazgo típico de Patch Manager.
```
{
"SchemaVersion": "2018-10-08",
"Id": "arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"ProductArn": "arn:aws:securityhub:us-east-1::product/aws/ssm-patch-manager",
"GeneratorId": "d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"AwsAccountId": "111122223333",
"Types": [
"Software & Configuration Checks/Patch Management/Compliance"
],
"CreatedAt": "2021-11-11T22:05:25Z",
"UpdatedAt": "2021-11-11T22:05:25Z",
"Severity": {
"Label": "INFORMATIONAL",
"Normalized": 0
},
"Title": "Systems Manager Patch Summary - Managed Instance Non-Compliant",
"Description": "This AWS control checks whether each instance that is managed by AWS Systems Manager is in compliance with the rules of the patch baseline that applies to that instance when a compliance Scan runs.",
"Remediation": {
"Recommendation": {
"Text": "For information about bringing instances into patch compliance, see 'Remediating out-of-compliance instances (Patch Manager)'.",
"Url": "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-remediation.html"
}
},
"SourceUrl": "https://us-east-2.console.aws.amazon.com/systems-manager/fleet-manager/i-02573cafcfEXAMPLE/patch?region=us-east-2",
"ProductFields": {
"aws/securityhub/FindingId": "arn:aws:securityhub:us-east-2::product/aws/ssm-patch-manager/arn:aws:patchmanager:us-east-2:111122223333:instance/i-02573cafcfEXAMPLE/document/AWS-RunPatchBaseline/run-command/d710f5bd-04e3-47b4-82f6-df4e0EXAMPLE",
"aws/securityhub/ProductName": "Systems Manager Patch Manager",
"aws/securityhub/CompanyName": "AWS"
},
"Resources": [
{
"Type": "AwsEc2Instance",
"Id": "i-02573cafcfEXAMPLE",
"Partition": "aws",
"Region": "us-east-2"
}
],
"WorkflowState": "NEW",
"Workflow": {
"Status": "NEW"
},
"RecordState": "ACTIVE",
"PatchSummary": {
"Id": "pb-0c10e65780EXAMPLE",
"InstalledCount": 45,
"MissingCount": 2,
"FailedCount": 0,
"InstalledOtherCount": 396,
"InstalledRejectedCount": 0,
"InstalledPendingReboot": 0,
"OperationStartTime": "2021-11-11T22:05:06Z",
"OperationEndTime": "2021-11-11T22:05:25Z",
"RebootOption": "NoReboot",
"Operation": "SCAN"
}
}
```
## Activación y configuración de la integración
Para utilizar la integración de Patch Manager a Security Hub CSPM, debe activar Security Hub CSPM. Para obtener información acerca de cómo activar Security Hub CSPM, consulte la [Configuración de Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html) en la *Guía del usuario de AWS Security Hub*.
En el siguiente procedimiento, se describe cómo integrar Patch Manager y Security Hub CSPM cuando Security Hub CSPM ya está activo pero la integración de Patch Manager se encuentra desactivada. Solo es necesario completar este procedimiento si la integración se desactivó de forma manual.
**Para agregar Patch Manager a la integración de Security Hub CSPM**
1. En el panel de navegación, elija **Patch Manager**.
1. Elija la pestaña **Settings**.
-o bien-
Si va a acceder a Patch Manager por primera vez en la Región de AWS actual, seleccione **Comience por la información general**, y luego la pestaña **Configuración**.
1. En la sección **Export to Security Hub CSPM** (Exportar a Security Hub CSPM), situada a la derecha de **Los resultados de conformidad de revisiones no se exportan a Security Hub CSPM**, elija **Activar**.
## Cómo dejar de enviar resultados
Para dejar de enviar resultados a Security Hub CSPM, puede utilizar la consola de Security Hub CSPM o la API.
Para obtener más información, consulte los siguientes temas en la *Guía del usuario de AWS Security Hub*:
+ [Disabling and enabling the flow of findings from an integration (console) (Desactivación y habilitación del flujo de resultados desde una integración [consola)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [Desactivación del flujo de resultados desde una integración (API de Security Hub CSPM, AWS CLI)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)
# Trabajar con recursos Patch Manager mediante la AWS CLI
En esta sección se incluyen ejemplos de comandos de la AWS Command Line Interface (AWS CLI) que puede utilizar para llevar a cabo tareas de configuración de Patch Manager, una herramienta de AWS Systems Manager.
Para obtener un ejemplo de cómo utilizar la AWS CLI para aplicar parches a un entorno de servidor mediante una base de referencia de parches personalizada, consulte [Tutorial: implementación de revisiones en un entorno de servidores mediante la AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).
Para obtener más información acerca del uso de las tareas de la AWS CLI para AWS Systems Manager, consulte la [sección de AWS Systems Manager de la Referencia de comandos de la AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html).
**Topics**
+ [AWS CLIComandos de la para las bases de referencia de parches](#patch-baseline-cli-commands)
+ [AWS CLIComandos de la para grupos de parches](#patch-group-cli-commands)
+ [AWS CLIComandos de la para ver resúmenes y detalles de parches](#patch-details-cli-commands)
+ [AWS CLIComandos de la para escanear y aplicar revisiones a nodos administrados](#patch-operations-cli-commands)
## AWS CLIComandos de la para las bases de referencia de parches
**Topics**
+ [Creación de una base de referencia de parches](#patch-manager-cli-commands-create-patch-baseline)
+ [Creación de una base de referencia de parches con repositorios personalizados para distintas versiones del sistema operativo](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [Actualización de una base de referencia de parches](#patch-manager-cli-commands-update-patch-baseline)
+ [Cambio del nombre de una base de referencia de parches](#patch-manager-cli-commands-rename-patch-baseline)
+ [Eliminación de una base de referencia de parches](#patch-manager-cli-commands-delete-patch-baseline)
+ [Enumeración de todas las bases de referencia de parches](#patch-manager-cli-commands-describe-patch-baselines)
+ [Enumeración de todas las bases de referencia de parches proporcionadas por AWS](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [Enumeración de mis bases de referencia de parches](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [Visualización de una base de referencia de parches](#patch-manager-cli-commands-get-patch-baseline)
+ [Obtención de la base de referencia de parches predeterminada](#patch-manager-cli-commands-get-default-patch-baseline)
+ [Establecer una base de referencia de parches personalizada como predeterminada](#patch-manager-cli-commands-register-default-patch-baseline)
+ [Restablecimiento de una base de referencia de parches de AWS como la predeterminada](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [Etiquetado de una base de referencia de parches](#patch-manager-cli-commands-add-tags-to-resource)
+ [Enumeración de las etiquetas de una base de referencia de parches](#patch-manager-cli-commands-list-tags-for-resource)
+ [Eliminación de una etiqueta de una base de referencia de parches](#patch-manager-cli-commands-remove-tags-from-resource)
### Creación de una base de referencia de parches
El siguiente comando crea una línea de base de revisiones que aprueba todas las actualizaciones de seguridad críticas e importantes para Windows Server 2012 R2 5 días después de su lanzamiento. También se han especificado parches para las listas de parches aprobados y rechazados. Además, la base de referencia de parches se ha etiquetado para indicar que es para un entorno de producción.
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Windows-Server-2012R2" \
--tags "Key=Environment,Value=Production" \
--description "Windows Server 2012 R2, Important and Critical security updates" \
--approved-patches "KB2032276,MS10-048" \
--rejected-patches "KB2124261" \
--rejected-patches-action "ALLOW_AS_DEPENDENCY" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Windows-Server-2012R2" ^
--tags "Key=Environment,Value=Production" ^
--description "Windows Server 2012 R2, Important and Critical security updates" ^
--approved-patches "KB2032276,MS10-048" ^
--rejected-patches "KB2124261" ^
--rejected-patches-action "ALLOW_AS_DEPENDENCY" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Important,Critical]},{Key=CLASSIFICATION,Values=SecurityUpdates},{Key=PRODUCT,Values=WindowsServer2012R2}]},ApproveAfterDays=5}]"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Creación de una base de referencia de parches con repositorios personalizados para distintas versiones del sistema operativo
Solo se aplica a nodos administrados de Linux. El siguiente comando muestra cómo especificar el repositorio de parches que se debe utilizar para una versión determinada del sistema operativo de Amazon Linux. En este ejemplo se utiliza un repositorio de origen habilitado de forma predeterminada en Amazon Linux 2017.09, pero puede adaptarlo para otro diferente que haya configurado para un nodo administrado.
**nota**
Para ilustrar mejor este comando, que tiene mayor complejidad, utilizamos la opción `--cli-input-json` junto con otras opciones almacenadas en un archivo JSON externo.
1. Cree un archivo JSON con un nombre similar a `my-patch-repository.json` y agregue el siguiente contenido:
```
{
"Description": "My patch repository for Amazon Linux 2",
"Name": "Amazon-Linux-2",
"OperatingSystem": "AMAZON_LINUX_2",
"ApprovalRules": {
"PatchRules": [
{
"ApproveAfterDays": 7,
"EnableNonSecurity": true,
"PatchFilterGroup": {
"PatchFilters": [
{
"Key": "SEVERITY",
"Values": [
"Important",
"Critical"
]
},
{
"Key": "CLASSIFICATION",
"Values": [
"Security",
"Bugfix"
]
},
{
"Key": "PRODUCT",
"Values": [
"AmazonLinux2"
]
}
]
}
}
]
},
"Sources": [
{
"Name": "My-AL2",
"Products": [
"AmazonLinux2"
],
"Configuration": "[amzn-main] \nname=amzn-main-Base\nmirrorlist=http://repo./$awsregion./$awsdomain//$releasever/main/mirror.list //nmirrorlist_expire=300//nmetadata_expire=300 \npriority=10 \nfailovermethod=priority \nfastestmirror_enabled=0 \ngpgcheck=1 \ngpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-amazon-ga \nenabled=1 \nretries=3 \ntimeout=5\nreport_instanceid=yes"
}
]
}
```
1. En el directorio en el que almacenó el archivo, ejecute el siguiente comando:
```
aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
```
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### Actualización de una base de referencia de parches
El siguiente comando agrega dos parches como rechazados y uno como aprobado a una base de referencia de parches existente.
Para obtener información acerca de los formatos aceptados para las listas de parches aprobados y rechazados, consulte [Formatos de nombre de paquete para listas de revisiones aprobadas y rechazadas](patch-manager-approved-rejected-package-name-formats.md).
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--rejected-patches "KB2032276" "MS10-048" \
--approved-patches "KB2124261"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--rejected-patches "KB2032276" "MS10-048" ^
--approved-patches "KB2124261"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001494.035,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### Cambio del nombre de una base de referencia de parches
------
#### [ Linux & macOS ]
```
aws ssm update-patch-baseline \
--baseline-id pb-0c10e65780EXAMPLE \
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
#### [ Windows Server ]
```
aws ssm update-patch-baseline ^
--baseline-id pb-0c10e65780EXAMPLE ^
--name "Windows-Server-2012-R2-Important-and-Critical-Security-Updates"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012-R2-Important-and-Critical-Security-Updates",
"RejectedPatches":[
"KB2032276",
"MS10-048"
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1481001795.287,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
"KB2124261"
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### Eliminación de una base de referencia de parches
```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Enumeración de todas las bases de referencia de parches
```
aws ssm describe-patch-baselines
```
El sistema devuelve información similar a la siguiente.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
A continuación, se muestra otro comando que enumera todas las bases de referencia de parches de una Región de AWS.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[All]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[All]"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
},
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### Enumeración de todas las bases de referencia de parches proporcionadas por AWS
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[AWS]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[AWS]"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
]
}
```
### Enumeración de mis bases de referencia de parches
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-baselines \
--region us-east-2 \
--filters "Key=OWNER,Values=[Self]"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-baselines ^
--region us-east-2 ^
--filters "Key=OWNER,Values=[Self]"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"BaselineIdentities":[
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### Visualización de una base de referencia de parches
```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```
**nota**
Para bases de referencia de parches personalizadas, puede especificar el ID de la base de referencia de parches o el nombre de recurso de Amazon (ARN) completo. Para bases de referencia de parches proporcionadas por AWS, debe especificar el ARN completo. Por ejemplo, `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`.
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE",
"Name":"Windows-Server-2012R2",
"PatchGroups":[
"Web Servers"
],
"RejectedPatches":[
],
"GlobalFilters":{
"PatchFilters":[
]
},
"ApprovalRules":{
"PatchRules":[
{
"PatchFilterGroup":{
"PatchFilters":[
{
"Values":[
"Important",
"Critical"
],
"Key":"MSRC_SEVERITY"
},
{
"Values":[
"SecurityUpdates"
],
"Key":"CLASSIFICATION"
},
{
"Values":[
"WindowsServer2012R2"
],
"Key":"PRODUCT"
}
]
},
"ApproveAfterDays":5
}
]
},
"ModifiedDate":1480997823.81,
"CreatedDate":1480997823.81,
"ApprovedPatches":[
],
"Description":"Windows Server 2012 R2, Important and Critical security updates"
}
```
### Obtención de la base de referencia de parches predeterminada
```
aws ssm get-default-patch-baseline --region us-east-2
```
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### Establecer una base de referencia de parches personalizada como predeterminada
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Restablecimiento de una base de referencia de parches de AWS como la predeterminada
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm register-default-patch-baseline ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Etiquetado de una base de referencia de parches
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tags "Key=Project,Value=Testing"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tags "Key=Project,Value=Testing"
```
------
### Enumeración de las etiquetas de una base de referencia de parches
------
#### [ Linux & macOS ]
```
aws ssm list-tags-for-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm list-tags-for-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE"
```
------
### Eliminación de una etiqueta de una base de referencia de parches
------
#### [ Linux & macOS ]
```
aws ssm remove-tags-from-resource \
--resource-type "PatchBaseline" \
--resource-id "pb-0c10e65780EXAMPLE" \
--tag-keys "Project"
```
------
#### [ Windows Server ]
```
aws ssm remove-tags-from-resource ^
--resource-type "PatchBaseline" ^
--resource-id "pb-0c10e65780EXAMPLE" ^
--tag-keys "Project"
```
------
## AWS CLIComandos de la para grupos de parches
**Topics**
+ [Crear un grupo de parches](#patch-manager-cli-commands-create-patch-group)
+ [Registro del grupo de parches "Web Servers" con una base de referencia de parches](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [Registro del grupo de parches “Backend” con la base de referencia de parches proporcionada por AWS](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [Visualización de los registros de grupos de parches](#patch-manager-cli-commands-describe-patch-groups)
+ [Anulación del registro de un grupo de parches en una base de referencia de parches](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)
### Crear un grupo de parches
**nota**
Los grupos de revisiones no se usan en operaciones de aplicación de revisiones basadas en *políticas de revisiones*. Para obtener información sobre el uso de las políticas de revisiones, consulte [Configuraciones de políticas de revisiones en Quick Setup](patch-manager-policies.md).
Para ayudarlo a organizar las acciones de aplicación de revisiones, le recomendamos que utilice las etiquetas para agregar nodos administrados a grupos de revisiones. Los grupos de revisiones requieren el uso de la clave de etiqueta `Patch Group` o `PatchGroup`. Si ha [permitido las etiquetas en los metadatos de las instancias de EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), debe usar `PatchGroup` (sin espacio). Puede especificar cualquier valor de etiqueta, pero la clave de etiqueta debe ser `Patch Group` o `PatchGroup`. Para obtener más información acerca de los grupos de revisiones, consulte [Grupos de revisiones](patch-manager-patch-groups.md).
Después de agrupar los nodos administrados mediante etiquetas, tiene que agregar el valor de grupo de revisiones a una base de referencia de revisiones. Al registrar el grupo de revisiones en una línea de base de revisiones, se asegura de que se instalen las revisiones correctos durante la operación de aplicación de revisiones.
#### Tarea 1: añadir instancias EC2 a un grupo de parches mediante etiquetas
**nota**
Cuando se utiliza la consola de Amazon Elastic Compute Cloud (Amazon EC2) y la AWS CLI, es posible aplicar etiquetas `Key = Patch Group` o `Key = PatchGroup` a instancias que aún no están configuradas para utilizarlas con Systems Manager. Si una instancia de EC2 que espera ver en Patch Manager no aparece en la lista luego de aplicar la etiqueta `Patch Group` o `Key = PatchGroup`, consulte [Solución de problemas de disponibilidad de nodos administrados](fleet-manager-troubleshooting-managed-nodes.md) para obtener consejos de solución de problemas.
Ejecute el siguiente comando para añadir la etiqueta `PatchGroup` a una instancia de EC2.
```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```
#### Tarea 2: agregar nodos administrados a un grupo de revisiones mediante etiquetas
Ejecute el siguiente comando para agregar la etiqueta `PatchGroup` a un nodo administrado.
------
#### [ Linux & macOS ]
```
aws ssm add-tags-to-resource \
--resource-type "ManagedInstance" \
--resource-id "mi-0123456789abcdefg" \
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### [ Windows Server ]
```
aws ssm add-tags-to-resource ^
--resource-type "ManagedInstance" ^
--resource-id "mi-0123456789abcdefg" ^
--tags "Key=PatchGroup,Value=GroupValue"
```
------
#### Tarea 3: añadir un grupo de revisiones a una línea de base de revisiones
Ejecute el siguiente comando para asociar un valor de etiqueta `PatchGroup` a la base de referencia de parches especificada.
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Development"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Development"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"PatchGroup": "Development",
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### Registro del grupo de parches "Web Servers" con una base de referencia de parches
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id "pb-0c10e65780EXAMPLE" \
--patch-group "Web Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id "pb-0c10e65780EXAMPLE" ^
--patch-group "Web Servers"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"PatchGroup":"Web Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Registro del grupo de parches “Backend” con la base de referencia de parches proporcionada por AWS
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--region us-east-2 \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" \
--patch-group "Backend"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--region us-east-2 ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE" ^
--patch-group "Backend"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"PatchGroup":"Backend",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### Visualización de los registros de grupos de parches
```
aws ssm describe-patch-groups --region us-east-2
```
El sistema devuelve información similar a la siguiente.
```
{
"PatchGroupPatchBaselineMappings":[
{
"PatchGroup":"Backend",
"BaselineIdentity":{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":false,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
},
{
"PatchGroup":"Web Servers",
"BaselineIdentity":{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":true,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
}
]
}
```
### Anulación del registro de un grupo de parches en una base de referencia de parches
------
#### [ Linux & macOS ]
```
aws ssm deregister-patch-baseline-for-patch-group \
--region us-east-2 \
--patch-group "Production" \
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm deregister-patch-baseline-for-patch-group ^
--region us-east-2 ^
--patch-group "Production" ^
--baseline-id "arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"PatchGroup":"Production",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
## AWS CLIComandos de la para ver resúmenes y detalles de parches
**Topics**
+ [Obtención de todos los parches definidos por una base de referencia de parches](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [Obtención de todos los parches para AmazonLinux2018.03 que tienen una clasificación `SECURITY` y gravedad `Critical`](#patch-manager-cli-commands-describe-available-patches-linux)
+ [Obtención de todos los parches para Windows Server 2012 que tienen una gravedad MSRC `Critical`](#patch-manager-cli-commands-describe-available-patches)
+ [Obtención de todos los parches disponibles](#patch-manager-cli-commands-describe-available-patches)
+ [Obtención de estados del resumen de revisiones por nodo administrado](#patch-manager-cli-commands-describe-instance-patch-states)
+ [Obtención de detalles de conformidad de revisiones de un nodo administrado](#patch-manager-cli-commands-describe-instance-patches)
+ [Vista de los resultados de conformidad de parches (AWS CLI)](#viewing-patch-compliance-results-cli)
### Obtención de todos los parches definidos por una base de referencia de parches
**nota**
Este comando solo se admite para bases de referencia de parches de Windows Server.
------
#### [ Linux & macOS ]
```
aws ssm describe-effective-patches-for-patch-baseline \
--region us-east-2 \
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
#### [ Windows Server ]
```
aws ssm describe-effective-patches-for-patch-baseline ^
--region us-east-2 ^
--baseline-id "pb-0c10e65780EXAMPLE"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"NextToken":"--token string truncated--",
"EffectivePatches":[
{
"PatchStatus":{
"ApprovalDate":1384711200.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2876331",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system
by installing this update from Microsoft. For a complete listing of the
issues that are included in this update, see the associated Microsoft
Knowledge Base article. After you install this update, you may have to
restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 R2 Preview (KB2876331)",
"ReleaseDate":1384279200.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2876331",
"MsrcNumber":"MS13-089",
"Id":"e74ccc76-85f0-4881-a738-59e9fc9a336d"
}
},
{
"PatchStatus":{
"ApprovalDate":1428858000.0,
"DeploymentStatus":"APPROVED"
},
"Patch":{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2919355",
"ProductFamily":"Windows",
"Product":"WindowsServer2012R2",
"Vendor":"Microsoft",
"Description":"Windows Server 2012 R2 Update is a cumulative
set of security updates, critical updates and updates. You
must install Windows Server 2012 R2 Update to ensure that
your computer can continue to receive future Windows Updates,
including security updates. For a complete listing of the
issues that are included in this update, see the associated
Microsoft Knowledge Base article for more information. After
you install this item, you may have to restart your computer.",
"Classification":"SecurityUpdates",
"Title":"Windows Server 2012 R2 Update (KB2919355)",
"ReleaseDate":1428426000.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2919355",
"MsrcNumber":"MS14-018",
"Id":"8452bac0-bf53-4fbd-915d-499de08c338b"
}
}
---output truncated---
```
### Obtención de todos los parches para AmazonLinux2018.03 que tienen una clasificación `SECURITY` y gravedad `Critical`
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=AmazonLinux2018.03 Key=SEVERITY,Values=Critical
```
------
El sistema devuelve información similar a la siguiente.
```
{
"Patches": [
{
"AdvisoryIds": ["ALAS-2011-1"],
"BugzillaIds": [ "1234567" ],
"Classification": "SECURITY",
"CVEIds": [ "CVE-2011-3192"],
"Name": "zziplib",
"Epoch": "0",
"Version": "2.71",
"Release": "1.3.amzn1",
"Arch": "i686",
"Product": "AmazonLinux2018.03",
"ReleaseDate": 1590519815,
"Severity": "CRITICAL"
}
]
}
---output truncated---
```
### Obtención de todos los parches para Windows Server 2012 que tienen una gravedad MSRC `Critical`
------
#### [ Linux & macOS ]
```
aws ssm describe-available-patches \
--region us-east-2 \
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
#### [ Windows Server ]
```
aws ssm describe-available-patches ^
--region us-east-2 ^
--filters Key=PRODUCT,Values=WindowsServer2012 Key=MSRC_SEVERITY,Values=Critical
```
------
El sistema devuelve información similar a la siguiente.
```
{
"Patches":[
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2727528",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Windows Server 2012 (KB2727528)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2727528",
"MsrcNumber":"MS12-072",
"Id":"1eb507be-2040-4eeb-803d-abc55700b715"
},
{
"ContentUrl":"https://support.microsoft.com/en-us/kb/2729462",
"ProductFamily":"Windows",
"Product":"WindowsServer2012",
"Vendor":"Microsoft",
"Description":"A security issue has been identified that could
allow an unauthenticated remote attacker to compromise your
system and gain control over it. You can help protect your
system by installing this update from Microsoft. After you
install this update, you may have to restart your system.",
"Classification":"SecurityUpdates",
"Title":"Security Update for Microsoft .NET Framework 3.5 on
Windows 8 and Windows Server 2012 for x64-based Systems (KB2729462)",
"ReleaseDate":1352829600.0,
"MsrcClassification":"Critical",
"Language":"All",
"KbNumber":"KB2729462",
"MsrcNumber":"MS12-074",
"Id":"af873760-c97c-4088-ab7e-5219e120eab4"
}
---output truncated---
```
### Obtención de todos los parches disponibles
```
aws ssm describe-available-patches --region us-east-2
```
El sistema devuelve información similar a la siguiente.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074588",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues
that are included in this update, see the associated Microsoft Knowledge Base
article. After you install this update, you may have to restart your system.",
"Id": "11adea10-0701-430e-954f-9471595ae246",
"KbNumber": "KB4074588",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518548400,
"Title": "2018-02 Cumulative Update for Windows Server 2016 (1709) for x64-based
Systems (KB4074588)",
"Vendor": "Microsoft"
},
{
"Classification": "SecurityUpdates",
"ContentUrl": "https://support.microsoft.com/en-us/kb/4074590",
"Description": "A security issue has been identified in a Microsoft software
product that could affect your system. You can help protect your system by
installing this update from Microsoft. For a complete listing of the issues that are included in this update, see the associated Microsoft Knowledge Base article. After you install this update, you may have to restart your system.",
"Id": "f5f58231-ac5d-4640-ab1b-9dc8d857c265",
"KbNumber": "KB4074590",
"Language": "All",
"MsrcNumber": "",
"MsrcSeverity": "Critical",
"Product": "WindowsServer2016",
"ProductFamily": "Windows",
"ReleaseDate": 1518544805,
"Title": "2018-02 Cumulative Update for Windows Server 2016 for x64-based
Systems (KB4074590)",
"Vendor": "Microsoft"
}
---output truncated---
```
### Obtención de estados del resumen de revisiones por nodo administrado
El resumen por nodo administrado aporta el número de revisiones en los siguientes estados por nodo: “NotApplicable”, “Missing”, “Failed”, “InstalledOther” e “Installed”.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states \
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states ^
--instance-ids i-08ee91c0b17045407 i-09a618aec652973a9
```
------
El sistema devuelve información similar a la siguiente.
```
{
"InstancePatchStates":[
{
"InstanceId": "i-08ee91c0b17045407",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "6d03d6c5-f79d-41d0-8d0e-00a9aEXAMPLE",
"InstalledCount": 50,
"InstalledOtherCount": 353,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 0,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 671,
"OperationStartTime": "2020-01-24T12:37:56-08:00",
"OperationEndTime": "2020-01-24T12:37:59-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
},
{
"InstanceId": "i-09a618aec652973a9",
"PatchGroup": "",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "c7e0441b-1eae-411b-8aa7-973e6EXAMPLE",
"InstalledCount": 36,
"InstalledOtherCount": 396,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 3,
"FailedCount": 0,
"UnreportedNotApplicableCount": -1,
"NotApplicableCount": 420,
"OperationStartTime": "2020-01-24T12:37:34-08:00",
"OperationEndTime": "2020-01-24T12:37:37-08:00",
"Operation": "Scan",
"RebootOption": "NoReboot"
}
---output truncated---
```
### Obtención de detalles de conformidad de revisiones de un nodo administrado
```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```
El sistema devuelve información similar a la siguiente.
```
{
"NextToken":"--token string truncated--",
"Patches":[
{
"Title": "bind-libs.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-libs.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:24-07:00"
},
{
"Title": "bind-utils.x86_64:32:9.8.2-0.68.rc1.60.amzn1",
"KBId": "bind-utils.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:32-07:00"
},
{
"Title": "dhclient.x86_64:12:4.1.1-53.P1.28.amzn1",
"KBId": "dhclient.x86_64",
"Classification": "Security",
"Severity": "Important",
"State": "Installed",
"InstalledTime": "2019-08-26T11:05:31-07:00"
},
---output truncated---
```
### Vista de los resultados de conformidad de parches (AWS CLI)
**Para ver los resultados de conformidad de revisiones de un único nodo administrado**
Ejecute el siguiente comando en la AWS Command Line Interface (AWS CLI) para ver los resultados de conformidad de revisiones de un único nodo administrado.
```
aws ssm describe-instance-patch-states --instance-id instance-id
```
Sustituya *instance-id* por el ID del nodo administrado del que desea ver los resultados, con el formato `i-02573cafcfEXAMPLE` o `mi-0282f7c436EXAMPLE`.
El sistema devuelve información similar a la siguiente.
```
{
"InstancePatchStates": [
{
"InstanceId": "i-02573cafcfEXAMPLE",
"PatchGroup": "mypatchgroup",
"BaselineId": "pb-0c10e65780EXAMPLE",
"SnapshotId": "a3f5ff34-9bc4-4d2c-a665-4d1c1EXAMPLE",
"CriticalNonCompliantCount": 2,
"SecurityNonCompliantCount": 2,
"OtherNonCompliantCount": 1,
"InstalledCount": 123,
"InstalledOtherCount": 334,
"InstalledPendingRebootCount": 0,
"InstalledRejectedCount": 0,
"MissingCount": 1,
"FailedCount": 2,
"UnreportedNotApplicableCount": 11,
"NotApplicableCount": 2063,
"OperationStartTime": "2021-05-03T11:00:56-07:00",
"OperationEndTime": "2021-05-03T11:01:09-07:00",
"Operation": "Scan",
"LastNoRebootInstallOperationTime": "2020-06-14T12:17:41-07:00",
"RebootOption": "RebootIfNeeded"
}
]
}
```
**Para ver un resumen del recuento de revisiones para todas las instancias de EC2 de una región**
El comando `describe-instance-patch-states` permite recuperar los resultados de una única instancia administrada a la vez. Sin embargo, si se utiliza un script personalizado con el comando `describe-instance-patch-states`, se puede generar un informe más pormenorizado.
Por ejemplo, si la [herramienta de filtro jq](https://stedolan.github.io/jq/download/) está instalada en su equipo local, podría ejecutar el siguiente comando para identificar cuáles de sus instancias EC2 en una Región de AWS concreta presentan el estado de `InstalledPendingReboot`.
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region region | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
*region* representa el identificador de una Región de AWS compatible con AWS Systems Manager, como `us-east-2` para la región EE. UU. Este (Ohio). Para ver una lista de los valores de *regiones* admitidos, consulte la columna **Región** en [Puntos de conexión de servicio de Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) en la *Referencia general de Amazon Web Services*.
Por ejemplo:
```
aws ssm describe-instance-patch-states \
--instance-ids $(aws ec2 describe-instances --region us-east-2 | jq '.Reservations[].Instances[] | .InstanceId' | tr '\n|"' ' ') \
--output text --query 'InstancePatchStates[*].{Instance:InstanceId, InstalledPendingRebootCount:InstalledPendingRebootCount}'
```
El sistema devuelve información similar a la siguiente.
```
1 i-02573cafcfEXAMPLE
0 i-0471e04240EXAMPLE
3 i-07782c72faEXAMPLE
6 i-083b678d37EXAMPLE
0 i-03a530a2d4EXAMPLE
1 i-01f68df0d0EXAMPLE
0 i-0a39c0f214EXAMPLE
7 i-0903a5101eEXAMPLE
7 i-03823c2fedEXAMPLE
```
Además de `InstalledPendingRebootCount`, la lista de tipos de recuento que puede buscar incluye lo siguiente:
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`
## AWS CLIComandos de la para escanear y aplicar revisiones a nodos administrados
Una vez ejecutados los siguientes comandos para analizar la conformidad de parches o instalar parches, puede utilizar los comandos de la sección [AWS CLIComandos de la para ver resúmenes y detalles de parches](#patch-details-cli-commands) para ver la información sobre el estado y la conformidad de los parches.
**Topics**
+ [Analizar nodos administrados para comprobar la conformidad de revisiones (AWS CLI)](#patch-operations-scan)
+ [Instalación de revisiones en nodos administrados (AWS CLI)](#patch-operations-install-cli)
### Analizar nodos administrados para comprobar la conformidad de revisiones (AWS CLI)
**Para analizar nodos administrados específicos para comprobar la conformidad de revisiones**
Ejecute el siguiente comando.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
El sistema devuelve información similar a la siguiente.
```
{
"Command": {
"CommandId": "a04ed06c-8545-40f4-87c2-a0babEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974475.267,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621952275.267,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**Para analizar los nodos administrados y comprobar la conformidad de revisiones por etiqueta de grupo de revisiones**
Ejecute el siguiente comando.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
--parameters 'Operation=Scan' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Scan" ^
--timeout-seconds 600
```
------
El sistema devuelve información similar a la siguiente.
```
{
"Command": {
"CommandId": "87a448ee-8adc-44e0-b4d1-6b429EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621974983.128,
"Parameters": {
"Operation": [
"Scan"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621952783.128,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
### Instalación de revisiones en nodos administrados (AWS CLI)
**Para instalar revisiones en nodos administrados específicos**
Ejecute el siguiente comando.
**nota**
Los nodos administrados de destino se reinician según sea necesario para completar la instalación de la revisión. Para obtener más información, consulte [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key=InstanceIds,Values='i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE' \
--parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key=InstanceIds,Values="i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
El sistema devuelve información similar a la siguiente.
```
{
"Command": {
"CommandId": "5f403234-38c4-439f-a570-93623EXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975301.791,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "InstanceIds",
"Values": [
"i-02573cafcfEXAMPLE,
i-0471e04240EXAMPLE"
]
}
],
"RequestedDateTime": 1621953101.791,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
**Para instalar revisiones en nodos administrados en un grupo de revisiones específico**
Ejecute el siguiente comando.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name 'AWS-RunPatchBaseline' \
--targets Key='tag:PatchGroup',Values='Web servers' \
-parameters 'Operation=Install' \
--timeout-seconds 600
```
------
#### [ Windows Server ]
```
aws ssm send-command ^
--document-name "AWS-RunPatchBaseline" ^
--targets Key="tag:PatchGroup",Values="Web servers" ^
--parameters "Operation=Install" ^
--timeout-seconds 600
```
------
El sistema devuelve información similar a la siguiente.
```
{
"Command": {
"CommandId": "fa44b086-7d36-4ad5-ac8d-627ecEXAMPLE",
"DocumentName": "AWS-RunPatchBaseline",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": 1621975407.865,
"Parameters": {
"Operation": [
"Install"
]
},
"InstanceIds": [],
"Targets": [
{
"Key": "tag:PatchGroup",
"Values": [
"Web servers"
]
}
],
"RequestedDateTime": 1621953207.865,
"Status": "Pending",
"StatusDetails": "Pending",
"TimeoutSeconds": 600,
---output truncated---
}
}
```
# Tutoriales de AWS Systems Manager Patch Manager
Los tutoriales de esta sección muestran cómo utilizar Patch Manager, una herramienta de AWS Systems Manager, en diversos casos de aplicación de revisiones.
**Topics**
+ [Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6](patch-manager-server-patching-iPv6-tutorial.md)
+ [Tutorial: creación de una línea de base de revisiones para instalar Service Packs de Windows mediante la consola](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutorial: actualización de las dependencias de la aplicación, implementación de una revisión a un nodo administrado y realización de una comprobación de estado específica de la aplicación mediante la consola](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutorial: implementación de revisiones en un entorno de servidores mediante la AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)
# Tutorial: Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6
Patch Manager admite la aplicación de revisiones en nodos en entornos que solo tienen IPv6. Al actualizar la configuración de SSM Agent, las operaciones de aplicación de revisiones se pueden configurar para que solo realicen llamadas a los puntos de conexión del servicio IPv6.
**Cómo aplicar revisiones a un servidor en un entorno exclusivo de IPv6**
1. Asegúrese de la versión 3.3270.0 de SSM Agent o una versión posterior esté instalada en el nodo administrado.
1. En el nodo administrado, navegue hasta el archivo de configuración de SSM Agent. Encontrará el archivo `amazon-ssm-agent.json` en los siguientes directorios:
+ Linux: `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
Si `amazon-ssm-agent.json` aún no existe, copie el contenido de `amazon-ssm-agent.json.template` del mismo directorio en `amazon-ssm-agent.json`.
1. Actualice la siguiente entrada para establecer la región correcta y establezca `UseDualStackEndpoint` en `true`:
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. Reinicie el servicio de SSM Agent con el comando correspondiente de su sistema operativo:
+ Linux: `sudo systemctl restart amazon-ssm-agent`
+ Ubuntu Server mediante el uso de Snap: `sudo snap restart amazon-ssm-agent`
+ macOS: `sudo launchctl stop com.amazon.aws.ssm` seguido de `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server: `Stop-Service AmazonSSMAgent` seguido de `Start-Service AmazonSSMAgent`
Para ver la lista completa de comandos de cada sistema operativo, consulte [Verificación del estado de SSM Agent e inicio del agente](ssm-agent-status-and-restart.md).
1. Ejecute cualquier operación de aplicación de revisiones para comprobar que las operaciones de aplicación de revisiones se realicen correctamente en su entorno exclusivo para IPv6. Asegúrese de que los nodos a los que se va a aplicar la revisión estén conectados a la fuente de la revisión. Puede comprobar el resultado Run Command de la ejecución de la revisión para comprobar si hay advertencias sobre repositorios inaccesibles. Cuando aplique revisiones a un nodo que se ejecuta en un entorno exclusivo de IPv6, asegúrese de que el nodo tenga conectividad con la fuente de la revisión. Puede comprobar el resultado Run Command de la ejecución de la revisión para comprobar si hay advertencias sobre repositorios inaccesibles. En el caso de los sistemas operativos basados en DNF, es posible configurar los repositorios no disponibles para que se omitan durante la aplicación de revisiones si la opción `skip_if_unavailable` está establecida en `True` en `/etc/dnf/dnf.conf`. Los sistemas operativos basados en DNF incluyen Amazon Linux 2023, Red Hat Enterprise Linux 8 y versiones posteriores, Oracle Linux 8 y versiones posteriores, Rocky Linux, AlmaLinux y CentOS 8 y versiones posteriores. En Amazon Linux 2023, la opción `skip_if_unavailable` está establecida en `True` de forma predeterminada.
**nota**
Cuando utilice las características Install Override List o Baseline Override, asegúrese de que se pueda acceder a la URL proporcionada desde el nodo. Si la opción de configuración `UseDualStackEndpoint` de SSM Agent está establecida en `true`, se utiliza un cliente S3 de pila doble cuando se proporciona una URL de S3.
# Tutorial: creación de una línea de base de revisiones para instalar Service Packs de Windows mediante la consola
Al crear una línea de base de revisiones personalizada, puede especificar que se instalen todos, parte o solo un tipo de parche compatible.
En las líneas de base de revisiones para Windows, puede seleccionar `ServicePacks` como única opción de **clasificación** para limitar las actualizaciones de revisiones solo a Service Packs. Patch Manager, una herramienta de AWS Systems Manager, puede instalar automáticamente Service Packs siempre que la actualización esté disponible en Windows Update o Windows Server Update Services (WSUS).
Puede configurar una línea de base de revisiones para controlar si se instalan los Service Packs para todas las versiones de Windows o solo los de versiones específicas, como Windows 7 o Windows Server 2016.
Utilice el procedimiento siguiente para crear una base de referencia de revisiones personalizada que se utilizará exclusivamente para instalar todos los Service Packs en los nodos administrados de Windows.
**Para crear una línea de base de revisiones para instalar Service Packs de Windows (consola)**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Seleccione la pestaña **Bases de referencia de parches**, y luego **Crear una base de referencia de parches**.
1. En **Nombre**, escriba un nombre para la nueva línea de base de revisiones; por ejemplo, `MyWindowsServicePackPatchBaseline`.
1. (Opcional) En **Description (Descripción)**, escriba una descripción para esta línea de base de revisiones.
1. En **Operating system (Sistema operativo)**, elija `Windows`.
1. Si desea comenzar a utilizar esta línea de base de revisiones de forma predeterminada para Windows tan pronto como la cree, seleccione **Set this patch baseline as the default patch baseline for Windows Server instances (Establecer esta línea de base de revisiones como la línea de base de revisiones predeterminada para las instancias de Windows Server)**.
**nota**
Esta opción solo está disponible si accedió a Patch Manager por primera vez antes de las [políticas de parches](patch-manager-policies.md) publicadas el 22 de diciembre de 2022.
Para obtener información sobre la configuración de una línea de base de revisiones existente como la opción predeterminada, consulte [Configuración de una línea de base de revisiones existente como valor predeterminado](patch-manager-default-patch-baseline.md).
1. En la sección **Approval Rules for operating systems (Reglas de aprobación para sistemas operativos)**, use los campos para crear una o varias reglas de aprobación automática.
+ **Productos**: versiones de los sistemas operativos a las que se aplica la regla de aprobación; por ejemplo, `WindowsServer2012`. Puede elegir una, más de una o todas las versiones compatibles de Windows. La selección predeterminada es `All`.
+ **Clasificación**: elija `ServicePacks`.
+ **Gravedad**: el valor de gravedad de las revisiones a los que se aplica la regla. Para asegurarse de que todos los Service Packs están incluidos en la regla, elija `All`.
+ **Auto-approval (Aprobación automática)**: método para seleccionar revisiones para su aprobación automática.
+ **Approve patches after a specified number of days** (Aprobar las revisiones después de una cantidad determinada de días): la cantidad de días que Patch Manager debe esperar después de que se lance o actualice una revisión y antes de que se apruebe automáticamente. Puede ingresar cualquier número entero entre cero (0) y 360. En la mayoría de los casos, se recomienda no esperar más de 100 días.
+ **Approve patches released up to a specific date** (Aprobar las revisiones publicadas hasta una fecha específica): la fecha de lanzamiento de la revisión para la que Patch Manager aplica automáticamente todas las revisiones publicadas o actualizadas en esa fecha o con anterioridad a ella. Por ejemplo, si especifica el 7 de julio de 2023, no se instalarán automáticamente las revisiones publicadas o actualizadas a partir del 8 de julio de 2023.
+ (Opcional). **Informes de conformidad**: el nivel de gravedad que desea asignar a los Service Packs aprobados por la base de referencia; como `High`.
**nota**
Si especifica un nivel de notificación de conformidad y se informa el estado de cualquier revisión aprobada como `Missing`, la gravedad de la conformidad general notificada por la línea de base de revisiones será el nivel de gravedad que especificó.
1. (Opcional) En **Manage tags (Administrar etiquetas)**, aplique uno o varios pares de claves nombre/valor al a la línea de base de revisiones.
Las etiquetas son metadatos opcionales que usted asigna a un recurso. Las etiquetas permiten clasificar los recursos de diversas maneras, por ejemplo, según la finalidad, el propietario o el entorno. Para esta línea de base de revisiones dedicada a la actualización de Service Packs, puede especificar pares clave-valor como los siguientes:
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. Elija **Create patch baseline** (Crear base de referencia de revisiones).
# Tutorial: actualización de las dependencias de la aplicación, implementación de una revisión a un nodo administrado y realización de una comprobación de estado específica de la aplicación mediante la consola
En muchos casos, un nodo administrado debe reiniciarse una vez que se haya aplicado la revisión correspondiente a la última actualización de software. No obstante, el reinicio de un nodo en producción sin contar con las debidas medidas de protección puede ocasionar varios problemas, como la invocación de alarmas, el registro de datos de métrica incorrectos y la interrupción de las sincronizaciones de datos.
En este tutorial se demuestra cómo evitar este tipo de problemas a través del uso del documento de AWS Systems Manager (documento de SSM) `AWS-RunPatchBaselineWithHooks` para realizar una operación de implementación de una revisión compleja y de varios pasos que permita lograr lo siguiente:
1. impedir nuevas conexiones a la aplicación
1. instalar las actualizaciones del sistema operativo.
1. actualizar las dependencias del paquete de la aplicación
1. reiniciar el sistema
1. realizar una comprobación de estado específica de la aplicación
Para este ejemplo, se ha configurado la infraestructura de la siguiente manera:
+ Las máquinas virtuales de destino se registran como nodos administrados con Systems Manager.
+ `Iptables` se utiliza como un firewall local.
+ La aplicación alojada en los nodos administrados se ejecuta en el puerto 443.
+ La aplicación alojada en los nodos administrados es una aplicación de `nodeJS`.
+ El administrador de procesos pm2 es el encargado de administrar la aplicación alojada en los nodos administrados.
+ La aplicación ya cuenta con un punto de enlace de comprobación de estado especificado.
+ El punto de enlace de comprobación de estado de la aplicación no requiere autenticación del usuario final. El punto de enlace permite una comprobación de estado conforme a los requisitos de la organización a la hora de establecer la disponibilidad. (En sus entornos, es posible que sea suficiente con solo comprobar que la aplicación de `nodeJS` se está ejecutando y es capaz de atender las solicitudes. No obstante, en otros casos, es posible que se desee verificar también que se ha establecido una conexión con el nivel de almacenamiento en caché o el nivel de base de datos).
Los ejemplos expuestos en este tutorial son únicamente para fines ilustrativos y no se pretende su implementación como tales en entornos de producción. Asimismo, tenga en cuenta que la característica de los enlaces de ciclo de vida de Patch Manager, una herramienta de Systems Manager, con el documento `AWS-RunPatchBaselineWithHooks` puede admitir muchos otros casos. A continuación, se presentan varios ejemplos.
+ Detenga un agente de informes de métricas antes de aplicar una revisión y reiniciarlo después de que el nodo administrado se reinicie.
+ Desconecte el nodo administrado de un clúster de CRM o PCS antes de aplicar las revisiones y vuelva a adjuntarlo después de reiniciar el nodo.
+ Actualice el software de terceros (por ejemplo, Java, Tomcat, aplicaciones de Adobe, etc.) en las máquinas de Windows Server luego de aplicar las actualizaciones del sistema operativo (SO), pero antes de que el nodo administrado se reinicie.
**Para actualizar las dependencias de la aplicación, aplicar una revisión a un nodo administrado y realizar una comprobación de estado específica de la aplicación**
1. Cree un documento de SSM para su script de preinstalación con el siguiente contenido y asígnele el nombre `NodeJSAppPrePatch`. Sustituya *your\$1application* por el nombre de la aplicación.
Este script bloquea inmediatamente las nuevas solicitudes entrantes y proporciona cinco segundos para que las ya activas se completen antes de comenzar la operación de aplicación de parches. Para la opción `sleep`, especifique una cantidad de segundos mayor que la que suele tardar en completarse las solicitudes entrantes.
```
# exit on error
set -e
# set up rule to block incoming traffic
iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1
# wait for current connections to end. Set timeout appropriate to your application's latency
sleep 5
# Stop your application
pm2 stop your_application
```
Para obtener más información acerca de la creación de documentos de SSM, consulte [Crear contenido en el documento de SSM](documents-creating-content.md).
1. Cree otro documento SSM con el siguiente contenido para su script de posinstalación para actualizar las dependencias de su aplicación y asígnele el nombre `NodeJSAppPostPatch`. Sustituya */your/application/path* por la ruta de acceso a su aplicación.
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. Cree otro documento de SSM con el siguiente contenido para que su script de `onExit` recupere su aplicación y realice una comprobación de estado. Asigne un nombre a este documento de SSM `NodeJSAppOnExitPatch`. Sustituya *your\$1application* por el nombre de la aplicación.
```
# exit on error
set -e
# restart nodeJs application
pm2 start your_application
# sleep while your application starts and to allow for a crash
sleep 10
# check with pm2 to see if your application is running
pm2 pid your_application
# re-enable incoming connections
iptables -D INPUT -j DROP -p tcp --syn --destination-port
# perform health check
/usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1
```
1. Cree una asociación en State Manager, una herramienta de AWS Systems Manager para ejecutar la operación mediante los siguientes pasos:
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **State Manager** y, a continuación, elija **Create association (Crear asociación)**.
1. En **Name** (Nombre) proporcione un nombre que ayude a identificar la finalidad de la asociación.
1. En la lista **Document** (Documento), elija `AWS-RunPatchBaselineWithHooks`.
1. En **Operation** (Operación), elija **Install** (Instalar).
1. (Opcional) En **Snapshot Id**, (ID de instantánea), proporcione un valor GUID que genere de modo que le permita agilizar la operación y garantizar la consistencia. El valor GUID puede ser tan sencillo como `00000000-0000-0000-0000-111122223333`.
1. En **Pre Install Hook Doc Name** (Nombre del documento del enlace de preinstalación), ingrese `NodeJSAppPrePatch`.
1. En **Post Install Hook Doc Name** (Nombre del documento del enlace de posinstalación), ingrese `NodeJSAppPostPatch`.
1. En **On ExitHook Doc Name** (Nombre del documento del enlace de salida), ingrese `NodeJSAppOnExitPatch`.
1. En el caso de **Targets** (Destinos), especifique etiquetas, elija nodos manualmente, elija un grupo de recursos o elija todos los nodos administrados para identificar sus nodos administrados.
1. En **Specify schedule** (Especificar programación), especifique con qué frecuencia se ejecutará la asociación. En el caso de la aplicación de revisiones en el nodo administrado, la cadencia habitual suele ser una vez a la semana.
1. En la sección **Rate control** (Control de velocidad), elija las opciones para controlar cómo se ejecuta la asociación en varios nodos administrados. Asegúrese de que solo se actualiza una parte de los nodos administrados a la vez. De lo contrario, toda su flota o la mayor parte de ella podría quedar sin conexión a la vez. Para obtener más información sobre el uso de controles de velocidad, consulte [Cómo comprender los controles de frecuencia y destinos en las asociaciones de State Manager](systems-manager-state-manager-targets-and-rate-controls.md).
1. (Opcional) En **Output options (Opciones de salida)**, para guardar la salida del comando en un archivo, seleccione el cuadro **Enable writing output to S3 (Permitir la escritura de salida en S3)**. Ingrese los nombres del bucket y del prefijo (carpeta) en los cuadros.
**nota**
Los permisos de S3 que conceden la capacidad de escribir datos en un bucket de S3 son los del perfil de instancias asignado al nodo administrado, no los del usuario de IAM que realiza esta tarea. Para obtener más información, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md) o [Creación de un rol de servicio de IAM para un entorno híbrido](hybrid-multicloud-service-role.md). Además, si el bucket de S3 especificado se encuentra en una Cuenta de AWS diferente, verifique que el perfil de instancias o el rol de servicio de IAM asociado al nodo administrado tenga los permisos necesarios para escribir en ese bucket.
1. Elija **Crear asociación**.
# Tutorial: implementación de revisiones en un entorno de servidores mediante la AWS CLI
En el siguiente tutorial se describe cómo aplicar parches a un entorno de servidor mediante una base de referencia de parches predeterminada, grupos de parches y un periodo de mantenimiento.
**Antes de empezar**
+ Instalar o actualizar SSM Agent en los nodos administrados. Para aplicar revisiones a los nodos administrados de Linux, los nodos deben ejecutar la versión de SSM Agent 2.0.834.0 o posterior. Para obtener más información, consulte [Actualización de SSM Agent mediante Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Configure roles y permisos para Maintenance Windows, una herramienta de AWS Systems Manager. Para obtener más información, consulte [Configuración de Maintenance Windows](setting-up-maintenance-windows.md).
+ Si aún no lo ha hecho, instale y configure la AWS Command Line Interface (AWS CLI).
Para obtener más información, consulte [Instalación o actualización de la última versión de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Para configurar Patch Manager y aplicar revisiones a los nodos administrados (línea de comandos)**
1. Ejecute el siguiente comando para crear una base de referencia de revisiones para Windows denominada `Production-Baseline`. Esta línea de base de revisiones aprueba las revisiones para un entorno de producción siete días después de su lanzamiento. Es decir, se ha etiquetado la base de referencia de parches para indicar que es para un entorno de producción.
**nota**
El parámetro `OperatingSystem` y `PatchFilters` varían en función del sistema operativo de los nodos administrados de destino a los que se aplica la base de referencia de revisiones. Para obtener más información, consulte [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) y [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html).
------
#### [ Linux & macOS ]
```
aws ssm create-patch-baseline \
--name "Production-Baseline" \
--operating-system "WINDOWS" \
--tags "Key=Environment,Value=Production" \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \
--description "Baseline containing all updates approved for production systems"
```
------
#### [ Windows Server ]
```
aws ssm create-patch-baseline ^
--name "Production-Baseline" ^
--operating-system "WINDOWS" ^
--tags "Key=Environment,Value=Production" ^
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^
--description "Baseline containing all updates approved for production systems"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Ejecute los siguientes comandos para registrar la base de referencia de parches "Production-Baseline" para dos grupos de parches. Los grupos se denominan "Database Servers" (Servidores de base de datos) y "Front-End Servers" (Servidores front-end).
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Database Servers"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"PatchGroup":"Database Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group "Front-End Servers"
```
------
#### [ Windows Server ]
```
aws ssm register-patch-baseline-for-patch-group ^
--baseline-id pb-0c10e65780EXAMPLE ^
--patch-group "Front-End Servers"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Ejecute los siguientes comandos para crear dos períodos de mantenimiento para los servidores de producción. El primer periodo se ejecuta cada martes a las 22:00 h. El segundo período se ejecuta cada sábado a las 22:00. Además, el periodo de mantenimiento está etiquetado para indicar que es para un entorno de producción.
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Tuesdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * TUE *)" \
--duration 1 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Tuesdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * TUE *)" ^
--duration 1 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
El sistema devuelve información similar a la siguiente.
```
{
"WindowId":"mw-0c50858d01EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm create-maintenance-window \
--name "Production-Saturdays" \
--tags "Key=Environment,Value=Production" \
--schedule "cron(0 0 22 ? * SAT *)" \
--duration 2 \
--cutoff 0 \
--no-allow-unassociated-targets
```
------
#### [ Windows Server ]
```
aws ssm create-maintenance-window ^
--name "Production-Saturdays" ^
--tags "Key=Environment,Value=Production" ^
--schedule "cron(0 0 22 ? * SAT *)" ^
--duration 2 ^
--cutoff 0 ^
--no-allow-unassociated-targets
```
------
El sistema devuelve información similar a la siguiente.
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. Ejecute los siguientes comandos para registrar los grupos de parches de servidores `Database` y `Front-End` con sus respectivos periodos de mantenimiento.
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=tag:PatchGroup,Values=Database Servers" \
--owner-information "Database Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Database Servers" ^
--owner-information "Database Servers" ^
--resource-type "INSTANCE"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-target-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=tag:PatchGroup,Values=Front-End Servers" \
--owner-information "Front-End Servers" \
--resource-type "INSTANCE"
```
------
#### [ Windows Server ]
```
aws ssm register-target-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=tag:PatchGroup,Values=Front-End Servers" ^
--owner-information "Front-End Servers" ^
--resource-type "INSTANCE"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. Ejecute los siguientes comandos para registrar una tarea de aplicación de parches que instale las actualizaciones que faltan en los servidores `Database` y `Front-End` durante sus respectivos periodos de mantenimiento.
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-0c50858d01EXAMPLE \
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-0c50858d01EXAMPLE ^
--targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE"
}
```
------
#### [ Linux & macOS ]
```
aws ssm register-task-with-maintenance-window \
--window-id mw-9a8b7c6d5eEXAMPLE \
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \
--task-arn "AWS-RunPatchBaseline" \
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \
--task-type "RUN_COMMAND" \
--max-concurrency 2 \
--max-errors 1 \
--priority 1 \
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
#### [ Windows Server ]
```
aws ssm register-task-with-maintenance-window ^
--window-id mw-9a8b7c6d5eEXAMPLE ^
--targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^
--task-arn "AWS-RunPatchBaseline" ^
--service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^
--task-type "RUN_COMMAND" ^
--max-concurrency 2 ^
--max-errors 1 ^
--priority 1 ^
--task-invocation-parameters "RunCommand={Parameters={Operation=Install}}"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. Ejecute el siguiente comando para obtener el resumen de conformidad de parches de alto nivel de un grupo de parches. El resumen de conformidad de revisiones de alto nivel incluye el número de nodos administrados con revisiones en los respectivos estados de revisiones.
**nota**
Lo normal es que vea ceros para el número de nodos administrados en el resumen hasta que se ejecute la tarea de revisiones durante el primer periodo de mantenimiento.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. Ejecute el siguiente comando para obtener los estados del resumen de revisiones por nodo administrado para un grupo de revisiones. El resumen por nodo administrado incluye un número de revisiones en los respectivos estados de revisiones por nodo administrado para un grupo de revisiones.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-patch-states-for-patch-group \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-instance-patch-states-for-patch-group ^
--patch-group "Database Servers"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"InstancePatchStates": [
{
"BaselineId": "string",
"FailedCount": number,
"InstalledCount": number,
"InstalledOtherCount": number,
"InstalledPendingRebootCount": number,
"InstalledRejectedCount": number,
"InstallOverrideList": "string",
"InstanceId": "string",
"LastNoRebootInstallOperationTime": number,
"MissingCount": number,
"NotApplicableCount": number,
"Operation": "string",
"OperationEndTime": number,
"OperationStartTime": number,
"OwnerInformation": "string",
"PatchGroup": "string",
"RebootOption": "string",
"SnapshotId": "string",
"UnreportedNotApplicableCount": number
}
]
}
```
Para ver un ejemplo de otros comandos de la AWS CLI que podría utilizar para sus tareas de configuración de Patch Manager, consulte [Trabajar con recursos Patch Manager mediante la AWS CLI](patch-manager-cli-commands.md).
# Resolución de problemas de Patch Manager
Utilice la siguiente información como ayuda para solucionar problemas con Patch Manager, una herramienta de AWS Systems Manager.
**Topics**
+ [Problema: error “Invoke-PatchBaselineOperation : Access Denied” o error “Unable to download file from S3” para `baseline_overrides.json`](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [Problema: la implementación de revisiones falla sin una causa aparente y sin arrojar un mensaje de error](#race-condition-conflict)
+ [Problema: resultados de conformidad de revisiones inesperados](#patch-manager-troubleshooting-compliance)
+ [Errores al ejecutar `AWS-RunPatchBaseline` en Linux](#patch-manager-troubleshooting-linux)
+ [Errores al ejecutar `AWS-RunPatchBaseline` en Windows Server](#patch-manager-troubleshooting-windows)
+ [Errores al ejecutar `AWS-RunPatchBaseline` en macOS](#patch-manager-troubleshooting-macos)
+ [Cómo utilizar manuales de procedimientos de Automatización de AWS Support](#patch-manager-troubleshooting-using-support-runbooks)
+ [Cómo ponerse en contacto con AWS Support](#patch-manager-troubleshooting-contact-support)
## Problema: error “Invoke-PatchBaselineOperation : Access Denied” o error “Unable to download file from S3” para `baseline_overrides.json`
**Problema**: cuando se ejecutan las operaciones de implementación de revisiones especificadas en su política de revisiones, recibe un error similar al siguiente ejemplo.
------
#### [ Example error on Windows Server ]
```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```
------
#### [ Example error on Linux ]
```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```
------
**Causa**: creó una política de revisiones en Quick Setup y algunos de sus nodos gestionados ya tenían un perfil de instancia asociado (para instancias de EC2) o un rol de servicio asociado (para máquinas que no sean de EC2).
Sin embargo, como se muestra en la siguiente imagen, no seleccionó la casilla **Agregar las políticas de IAM requeridas a los perfiles de instancia existentes asociados a sus instancias**.
![\[\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
Cuando crea una política de revisiones, se crea un bucket de Amazon S3 para almacenar el archivo `baseline_overrides.json` de configuración de la política. Si no selecciona la casilla **Agregar las políticas de IAM requeridas a los perfiles de instancia existentes asociados a sus instancias** cuando crea la política, las políticas de IAM y las etiquetas de recursos que se necesitan para acceder a `baseline_overrides.json` en el bucket de S3 no se agregan automáticamente a los perfiles de instancia de IAM y roles de servicio existentes.
**Solución 1**: elimine la configuración de políticas de revisiones existente y, a continuación, cree una que la sustituya. Asegúrese de seleccionar la casilla **Agregar las políticas de IAM requeridas a los perfiles de instancia existentes asociados a sus instancias**. Esta selección aplica las políticas de IAM creadas por Quick Setup a los nodos que ya tienen un perfil de instancia o un rol de servicio asociado. (De forma predeterminada, Quick Setup agrega las políticas necesarias a las instancias y los nodos que aún *no* tienen perfiles de instancia o roles de servicio). Para obtener más información, consulte [Automatizar la aplicación de revisiones en toda la organización mediante una política de revisiones de Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
**Solución 2**: agregue manualmente los permisos y las etiquetas necesarios a cada perfil de instancia de IAM y rol de servicio de IAM que utilice con Quick Setup. Para obtener instrucciones, consulte [Permisos para el bucket de S3 de la política de revisiones](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions).
## Problema: la implementación de revisiones falla sin una causa aparente y sin arrojar un mensaje de error
**Problema**: una operación de implementación de revisiones falla sin arrojar un error.
**Causa posible**: al aplicar revisiones a los nodos administrados, la ejecución del documento puede interrumpirse y marcarse como fallida aunque las revisiones se hayan instalado de manera correcta. Esto puede ocurrir si el sistema inicia un reinicio inesperado durante la operación de aplicación de revisiones (por ejemplo, para aplicar actualizaciones al firmware o a funciones como SecureBoot). El agente de SSM no puede conservar ni reanudar el estado de ejecución del documento tras reinicios externos, por lo que la ejecución se considera fallida.
**Solución**: Para comprobar el estado de instalación de la revisión tras una ejecución fallida, ejecute una operación de `Scan` de aplicación de revisiones y, a continuación, compruebe los datos de cumplimiento del parche en Patch Manager para evaluar el estado de cumplimiento actual.
Si determina que los reinicios externos no fueron la causa del error en este escenario, recomendamos que se ponga en contacto con [AWS Support](#patch-manager-troubleshooting-contact-support).
## Problema: resultados de conformidad de revisiones inesperados
**Problema**: al revisar los detalles de conformidad de revisiones generados después de una operación de `Scan`, los resultados incluyen información que no refleja las reglas establecidas en la línea de base de revisiones. Por ejemplo, una excepción que haya agregado a la lista **Rejected patches** (Revisiones rechazadas) en una línea de base de revisiones aparece como `Missing`. O bien, las revisiones clasificadas como `Important` aparecen como faltantes, aunque la línea de base de revisiones especifique únicamente las revisiones `Critical`.
**Causa**: Patch Manager admite actualmente varios métodos de ejecución de operaciones `Scan`:
+ Una política de revisiones configurada en Quick Setup
+ Una opción de administración de host configurada en Quick Setup
+ Una ventana de mantenimiento para ejecutar una revisión `Scan` o una tarea `Install`
+ Una operación **Patch Now** (Aplicar revisión ahora) bajo demanda
Cuando se ejecuta una operación de `Scan`, sobrescribe los detalles de conformidad del análisis más reciente. Si tiene más de un método configurado para ejecutar una operación de `Scan` y estos utilizan diferentes líneas de base de revisiones con diferentes reglas, los resultados de conformidad de las revisiones variarán.
**Solución**: para evitar resultados inesperados en cuanto a la conformidad de las revisiones, se recomienda utilizar solo un método a la vez para ejecutar la operación de Patch Manager `Scan`. Para obtener más información, consulte [Identificación de la ejecución que creó los datos de conformidad de la revisión](patch-manager-compliance-data-overwrites.md).
## Errores al ejecutar `AWS-RunPatchBaseline` en Linux
**Topics**
+ [Asunto: error “No such file or directory” (No existe tal archivo o directorio)](#patch-manager-troubleshooting-linux-1)
+ [Asunto: error “another process has acquired yum lock” (otro proceso tiene el bloqueo de yum)](#patch-manager-troubleshooting-linux-2)
+ [Asunto: error “Permission denied / failed to run commands” (Permiso denegado/Error al ejecutar comandos)](#patch-manager-troubleshooting-linux-3)
+ [Asunto: error “Unable to download payload” (No se puede descargar la carga)](#patch-manager-troubleshooting-linux-4)
+ [Asunto: error “unsupported package manager and python version combination” (Combinación de administrador de paquetes y versión de python no compatible)](#patch-manager-troubleshooting-linux-5)
+ [Asunto: Patch Manager no aplica las reglas especificadas para excluir determinados paquetes](#patch-manager-troubleshooting-linux-6)
+ [Asunto: se produce un error en la aplicación de revisiones y Patch Manager notifica que la extensión de la indicación de nombre de servidor a TLS no está disponible](#patch-manager-troubleshooting-linux-7)
+ [Asunto: Patch Manager notifica “No more mirrors to try” (No más espejos para probar)](#patch-manager-troubleshooting-linux-8)
+ [Problema: la implementación de revisiones falla y arroja el mensaje “Error code returned from curl is 23”.](#patch-manager-troubleshooting-linux-9)
+ [Problema: la implementación de revisiones falla y arroja el mensaje “Error unpacking rpm package…”](#error-unpacking-rpm)
+ [Problema: la instalación de revisiones falla y arroja el mensaje “Encounter service side error when uploading the inventory”.](#inventory-upload-error)
+ [Problema: la implementación de revisiones falla y arroja el mensaje “Se encontraron errores cuando se descargaron los paquetes”.](#errors-while-downloading)
+ [Problema: la implementación de revisiones arroja un error de memoria insuficiente (OOM)](#patch-manager-troubleshooting-linux-oom)
+ [Problema: la implementación de revisiones falla y arroja el mensaje “The following signatures couldn't be verified because the public key is not available”](#public-key-unavailable)
+ [Problema: la implementación de revisiones falla y arroja el mensaje “NoMoreMirrorsRepoError”](#no-more-mirrors-repo-error)
+ [Problema: la implementación de revisiones falla y arroja el mensaje “No se puede descargar la carga”.](#payload-download-error)
+ [Problema: la implementación de revisiones falla y arroja el mensaje “install errors: dpkg: error: dpkg frontend is locked by another process”](#dpkg-frontend-locked)
+ [Problema: cuando implementa las revisiones, se produce un error del Ubuntu Server que indica “dpkg was interrupted”](#dpkg-interrupted)
+ [Problema: la utilidad del administrador de paquetes no puede resolver una dependencia del paquete](#unresolved-dependency)
+ [Problema: errores de dependencia de bloqueo de paquetes de Zypper en los nodos administrados de SLES](#patch-manager-troubleshooting-linux-zypper-locks)
+ [Problema: No se puede adquirir el bloqueo. La operación de parches está en curso.](#patch-manager-troubleshooting-linux-concurrent-lock)
### Asunto: error “No such file or directory” (No existe tal archivo o directorio)
**Problema**: cuando se ejecuta `AWS-RunPatchBaseline`, la aplicación de revisiones presenta uno de los siguientes errores.
```
IOError: [Errno 2] No such file or directory: 'patch-baseline-operations-X.XX.tar.gz'
```
```
Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.failed to run commands: exit status 155
```
```
Unable to load and extract the content of payload, abort.failed to run commands: exit status 152
```
**Causa 1**: se ejecutaban dos comandos `AWS-RunPatchBaseline` al mismo tiempo en el mismo nodo administrado. De este modo, se crea una condición de velocidad que da lugar a que no se cree `file patch-baseline-operations*` temporal ni se acceda correctamente a él.
**Causa 2**: no hay suficiente espacio de almacenamiento en el directorio `/var`.
**Solución 1**: asegúrese de que no haya ningún periodo de mantenimiento con dos o más tareas de Run Command que ejecuten `AWS-RunPatchBaseline` con el mismo nivel de prioridad y que se ejecuten en los mismos ID de destino. Si este es el caso, se debe reordenar la prioridad. Run Command es una herramienta de AWS Systems Manager.
**Solución 2**: asegúrese de que solo un periodo de mantenimiento a la vez esté ejecutando tareas de Run Command que utilicen `AWS-RunPatchBaseline` en los mismos destinos y dentro de la misma programación. En este caso, cambie la programación.
**Solución 3**: asegúrese de que solo una asociación de State Manager esté ejecutando `AWS-RunPatchBaseline` en la misma programación y se dirija a los mismos nodos administrados. State Manager es una herramienta de AWS Systems Manager.
**Solución 4**: libere espacio de almacenamiento suficiente en el directorio `/var` para los paquetes de actualización.
### Asunto: error “another process has acquired yum lock” (otro proceso tiene el bloqueo de yum)
**Problema**: cuando se ejecuta `AWS-RunPatchBaseline`, la aplicación de revisiones presenta el siguiente error.
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**Causa**: el documento `AWS-RunPatchBaseline` ha comenzado a ejecutarse en un nodo administrado que ya se ejecuta en otra operación y ha adquirido el proceso `yum` del administrador de paquetes.
**Solución**: asegúrese de que ninguna asociación de State Manager, tarea de periodo de mantenimiento u otra configuración que ejecute `AWS-RunPatchBaseline` de forma programada tenga como destino el mismo nodo administrado aproximadamente al mismo tiempo.
### Asunto: error “Permission denied / failed to run commands” (Permiso denegado/Error al ejecutar comandos)
**Problema**: cuando se ejecuta `AWS-RunPatchBaseline`, la aplicación de revisiones presenta el siguiente error.
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**Causa**: `/var/lib/amazon/` podría montarse con permisos de `noexec`. Esto supone un problema, ya que SSM Agent descarga los scripts de carga en `/var/lib/amazon/ssm` y los ejecuta desde esa ubicación.
**Solución:** asegúrese de haber configurado particiones exclusivas para `/var/log/amazon` y `/var/lib/amazon`, y que están montados con permisos de `exec`.
### Asunto: error “Unable to download payload” (No se puede descargar la carga)
**Problema**: cuando se ejecuta `AWS-RunPatchBaseline`, la aplicación de revisiones presenta el siguiente error.
```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```
**Causa**: el nodo administrado no cuenta con los permisos necesarios para obtener acceso al bucket de Amazon Simple Storage Service (Amazon S3) especificado.
**Solución**: actualice la configuración de la red para que se pueda acceder a los puntos de enlace de S3. Para obtener más información, consulte la información acerca del acceso necesario a los buckets de S3 para Patch Manager en [SSM Agent Comunicaciones de AWS con buckets de S3 administrados de](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
### Asunto: error “unsupported package manager and python version combination” (Combinación de administrador de paquetes y versión de python no compatible)
**Problema**: cuando se ejecuta `AWS-RunPatchBaseline`, la aplicación de revisiones presenta el siguiente error.
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**Causa**: no se ha instalado una versión de python3 compatible en la instancia de Debian Server o Ubuntu Server.
**Solución**: instale una versión de python3 compatible (3.0 o 3.12) en el servidor, lo que es necesario para los nodos administrados de Debian Server y Ubuntu Server.
### Asunto: Patch Manager no aplica las reglas especificadas para excluir determinados paquetes
**Problema:** ha intentado excluir determinados paquetes al especificarlos en el archivo `/etc/yum.conf`, con el formato `exclude=package-name`, pero no se excluyen durante la operación `Install` de Patch Manager.
**Causa** Patch Manager: no incluye las exclusiones especificadas en el archivo `/etc/yum.conf`.
**Solución**: para excluir paquetes específicos, cree una línea de base de revisiones personalizada y cree una regla que excluya aquellos paquetes que no desea instalar.
### Asunto: se produce un error en la aplicación de revisiones y Patch Manager notifica que la extensión de la indicación de nombre de servidor a TLS no está disponible
**Problema**: la operación de aplicación de revisiones muestra el siguiente mensaje.
```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS
certificate, which can cause validation failures. You can upgrade to a newer version of Python
to solve this.
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```
**Causa**: este mensaje no indica un error. En su lugar, aparece una advertencia de que la versión más antigua de Python distribuida con el sistema operativo no es compatible con la indicación de nombre de servidor de TLS. El script de carga de revisiones de Systems Manager muestra esta advertencia cuando se conecta a las API de AWS que son compatibles con SNI.
**Solución**: para solucionar cualquier error en la aplicación de revisiones cuando se notifica este mensaje, revise el contenido de los archivos `stdout` y `stderr`. Si no ha configurado la línea de base de revisiones para almacenar estos archivos en un bucket de S3 o en Registros de Amazon CloudWatch, puede ubicar los archivos en la siguiente ubicación en su nodo administrado de Linux.
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### Asunto: Patch Manager notifica “No more mirrors to try” (No más espejos para probar)
**Problema**: la operación de aplicación de revisiones muestra el siguiente mensaje.
```
[Errno 256] No more mirrors to try.
```
**Causa**: los repositorios configurados en el nodo administrado no funcionan correctamente. Entre las causas posibles se incluyen las siguientes:
+ La memoria caché de `yum` está dañada.
+ No se puede acceder a la URL de un repositorio debido a problemas con la red.
**Solución**: Patch Manager utiliza el administrador de paquetes predeterminado del nodo administrado para realizar la operación de aplicación de revisiones. Verifique que los repositorios se han configurado y funcionan correctamente.
### Problema: la implementación de revisiones falla y arroja el mensaje “Error code returned from curl is 23”.
**Problema**: una operación de implementación de revisiones que usa `AWS-RunPatchBaseline` falla y arroja un error similar al siguiente:
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**Causa**: la herramienta curl que se utiliza en sus sistemas carece de los permisos necesarios para escribir en el sistema de archivos. Esto puede ocurrir si la herramienta curl predeterminada del administrador de paquetes se reemplazó por una versión diferente, como una instalada con snap.
**Solución**: si la versión curl que proporciona el administrador de paquetes se desinstaló tras la instalación de una versión diferente, vuelva a instalarla.
Si necesita mantener instaladas varias versiones de curl, asegúrese de que la versión asociada al administrador de paquetes esté en el primer directorio de la variable `PATH`. Para comprobarlo, ejecute el comando `echo $PATH` para ver el orden actual de los directorios en los que se comprueban los archivos ejecutables del sistema.
### Problema: la implementación de revisiones falla y arroja el mensaje “Error unpacking rpm package…”
**Problema**: una operación de implementación de revisiones falla y arroja un error similar al siguiente:
```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```
**Causa 1**: cuando un paquete concreto está presente en varios instaladores de paquetes como `pip`, `yum` o `dnf`, pueden producirse conflictos cuando se utiliza el administrador de paquetes predeterminado.
Un ejemplo habitual es el del paquete `urllib3`, que se encuentra en `pip`, `yum` y `dnf`.
**Causa 2**: el paquete de `python-urllib3` está dañado. Esto puede suceder si los archivos del paquete se instalaron o actualizaron usando `pip` después de que el paquete `rpm` fuera instalado previamente mediante `yum` o `dnf`.
**Solución**: elimine el paquete `python-urllib3` de pip ejecutando el comando `sudo pip uninstall urllib3` y manteniendo el paquete solo en el administrador de paquetes predeterminado (`yum` o `dnf`).
### Problema: la instalación de revisiones falla y arroja el mensaje “Encounter service side error when uploading the inventory”.
**Problema**: al ejecutar el documento `AWS-RunPatchBaseline`, aparece el siguiente mensaje de error:
```
Encounter service side error when uploading the inventory
```
**Causa**: se ejecutaban dos comandos `AWS-RunPatchBaseline` al mismo tiempo en el mismo nodo administrado. Esto crea una condición de carrera al inicializar el cliente boto3 durante las operaciones de aplicación de revisiones.
**Solución**: asegúrese de que ninguna asociación de State Manager, tarea de periodo de mantenimiento u otra configuración que ejecute `AWS-RunPatchBaseline` de forma programada tenga como destino el mismo nodo administrado aproximadamente al mismo tiempo.
### Problema: la implementación de revisiones falla y arroja el mensaje “Se encontraron errores cuando se descargaron los paquetes”.
**Problema**: durante la implementación de revisiones, recibe un error similar al siguiente:
```
YumDownloadError: [u'Errors were encountered while downloading
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12]
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5]
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory',
```
**Causa**: este error puede producirse cuando no hay suficiente memoria disponible en un nodo administrado.
**Solución**: configure la memoria de intercambio o actualice la instancia a un tipo diferente para aumentar la compatibilidad con la memoria. A continuación, inicie una nueva operación de implementación de revisiones.
### Problema: la implementación de revisiones arroja un error de memoria insuficiente (OOM)
**Problema**: cuando se ejecuta `AWS-RunPatchBaseline`, la operación de implementación de revisiones falla debido a la falta de memoria en el nodo administrado. Es posible que se produzcan errores como `Cannot allocate memory`, `Killed` (del OOM Killer de Linux), o que se produzca un error inesperado en la operación. Es más probable que este error se produzca en instancias con menos de 1 GB de RAM, pero también puede afectar a las instancias con más memoria cuando hay un gran número de actualizaciones disponibles.
**Causa**: Patch Manager ejecuta las operaciones de implementación de revisiones mediante el uso del administrador de paquetes nativo del nodo administrado. La memoria necesaria durante una operación de implementación de revisiones depende de varios factores, entre ellos:
+ La cantidad de paquetes instalados y las actualizaciones disponibles en el nodo administrado.
+ El administrador de paquetes en uso y sus características de memoria.
+ La existencia de otros procesos en ejecución en el nodo administrado durante la operación de implementación de revisiones.
Los nodos administrados que tienen una gran cantidad de paquetes instalados o una gran cantidad de actualizaciones disponibles requieren más memoria durante las operaciones de implementación de revisiones. Si la memoria disponible es insuficiente, el proceso de implementación de revisiones fallará y se cerrará con un error. El sistema operativo también puede finalizar el proceso de implementación de revisiones.
**Solución**: pruebe una o varias de las siguientes opciones:
+ Programe las operaciones de implementación de revisiones durante los períodos de baja actividad de carga de trabajo en el nodo administrado, por ejemplo, mediante la implementación de períodos de mantenimiento.
+ Actualice la instancia a un tipo con más memoria.
+ Configure la memoria de intercambio en el nodo administrado. Tenga en cuenta que, en las instancias con un rendimiento de EBS limitado, el uso intensivo de intercambios puede provocar una degradación del rendimiento.
+ Revise y reduzca la cantidad de procesos que se ejecutan en el nodo administrado durante las operaciones de implementación de revisiones.
### Problema: la implementación de revisiones falla y arroja el mensaje “The following signatures couldn't be verified because the public key is not available”
**Problema**: la implementación de revisiones falla en Ubuntu Server y arroja un error similar al siguiente:
```
02/17/2022 21:08:43 root [ERROR]: W:GPG error:
http://repo.mysql.com/apt/ubuntu bionic InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```
**Causa**: la clave GNU Privacy Guard (GPG) caducó o falta.
**Solución**: actualice la clave GPG o vuelva a agregarla.
Por ejemplo, si tomamos como ejemplo el error anterior, vemos que falta la clave `467B942D3A79BD29` y es necesario agregarla. Para ello, ejecute cualquiera de los comandos siguientes:
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```
O bien, ejecute el siguiente comando para actualizar todas las claves:
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
Si el error se repite después de esto, recomendamos informar el problema a la organización que mantiene el repositorio. Hasta que haya una solución disponible, puede editar el archivo `/etc/apt/sources.list` para omitir el repositorio durante el proceso de implementación de revisiones.
Para ello, abra el archivo `sources.list` para editarlo, localice la línea del repositorio e inserte un carácter `#` al principio de la línea para comentarla. Guarde el archivo y, a continuación, ciérrelo.
### Problema: la implementación de revisiones falla y arroja el mensaje “NoMoreMirrorsRepoError”
**Problema**: recibe un error similar al siguiente:
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**Causa**: hay un error en el repositorio de origen.
**Solución**: recomendamos informar el problema a la organización que mantiene el repositorio. Hasta que se corrija el error, puede deshabilitar el repositorio a nivel del sistema operativo. Para ello, ejecute el siguiente comando y reemplace el valor *repo-name* por el nombre de su repositorio:
```
yum-config-manager --disable repo-name
```
A continuación se muestra un ejemplo.
```
yum-config-manager --disable pgdg94
```
Tras ejecutar este comando, ejecute otra operación de implementación de revisiones.
### Problema: la implementación de revisiones falla y arroja el mensaje “No se puede descargar la carga”.
**Problema**: recibe un error similar al siguiente:
```
Unable to download payload:
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed to run commands: exit status 156
```
**Causa**: la configuración del nodo administrado contiene errores o está incompleta.
**Solución**: asegúrese de que el nodo administrado esté configurado con lo siguiente:
+ Regla TCP 443 de salida en el grupo de seguridad.
+ Regla TCP 443 de salida en NACL.
+ Regla TCP 1024-65535 de ingreso en NACL.
+ NAT/IGW en la tabla de enrutamiento para proporcionar conectividad a un punto de conexión de S3. Si la instancia no tiene acceso a Internet, proporcione la conectividad con el punto de conexión de S3. Para ello, agregue un punto de conexión de puerta de enlace de S3 en la VPC e intégrelo con la tabla de enrutamiento del nodo administrado.
### Problema: la implementación de revisiones falla y arroja el mensaje “install errors: dpkg: error: dpkg frontend is locked by another process”
**Problema**: la implementación de revisiones falla y arroja un error similar al siguiente:
```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```
**Causa**: el administrador de paquetes ya está ejecutando otro proceso en un nodo administrado a nivel del sistema operativo. Si ese otro proceso tarda mucho en completarse, es posible que se agote el tiempo de espera de la operación de implementación de revisiones de Patch Manager y se produzca un error.
**Solución**: una vez finalizado el otro proceso que utiliza el administrador de paquetes, ejecute una nueva operación de implementación de revisiones.
### Problema: cuando implementa las revisiones, se produce un error del Ubuntu Server que indica “dpkg was interrupted”
**Problema**: la implementación de revisiones falla en el Ubuntu Server y arroja un error similar al siguiente:
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**Causa**: uno o más paquetes están mal configurados.
**Solución:** siga los pasos que se indican a continuación:
1. Compruebe qué paquetes están afectados y cuáles son los problemas de cada paquete ejecutando los siguientes comandos, uno por uno:
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. Corrija los paquetes que tengan problemas ejecutando el siguiente comando:
```
sudo dpkg --configure -a
```
1. Si el comando anterior no resolvió por completo el problema, ejecute el comando siguiente:
```
sudo apt --fix-broken install
```
### Problema: la utilidad del administrador de paquetes no puede resolver una dependencia del paquete
**Problema**: el administrador de paquetes nativo del nodo administrado no puede resolver una dependencia del paquete y se produce un error cuando se implementan las revisiones. El siguiente ejemplo de mensaje de error indica este tipo de error en un sistema operativo que utiliza `yum` como administrador de paquetes.
```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1,
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3',
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```
**Causa**: en los sistemas operativos Linux, Patch Manager utiliza el administrador de paquetes nativo de la máquina para ejecutar las operaciones de implementación de revisiones, como `yum`, `dnf`, `apt` y `zypper`. Las aplicaciones detectan, instalan, actualizan o eliminan automáticamente los paquetes dependientes según sea necesario. Sin embargo, algunas condiciones pueden provocar que el administrador de paquetes no pueda completar una operación de dependencia, como las siguientes:
+ Hay varios repositorios conflictivos configurados en el sistema operativo.
+ No se puede acceder a la URL de un repositorio remoto debido a problemas relacionados con la red.
+ En el repositorio se encuentra un paquete para una arquitectura incorrecta.
**Solución**: la implementación de revisiones puede fallar debido a un problema de dependencia por una amplia variedad de motivos. Por lo tanto, recomendamos que se ponga en contacto con AWS Support para obtener ayuda con la solución de problemas.
### Problema: errores de dependencia de bloqueo de paquetes de Zypper en los nodos administrados de SLES
**Problema**: cuando se ejecuta `AWS-RunPatchBaseline` con la operación `Install` en las instancias de SUSE Linux Enterprise Server, se produce un error al aplicar los parches y se producen errores de comprobación de dependencias relacionados con el bloqueo de paquetes. Podría obtener mensajes de error similares al siguiente:
```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
```
En este ejemplo, el paquete `mock-pkg-standalone` está bloqueado; puede comprobarlo si ejecuta `sudo zypper locks` y busca el nombre de este paquete en el resultado.
O puede ver entradas de registro que indican errores en la comprobación de dependencias:
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**nota**
Este problema solo se produce durante las operaciones `Install`. Las operaciones `Scan` no aplican bloqueos a los paquetes y no se ven afectadas por los bloqueos existentes.
**Causa**: este error se produce cuando los bloqueos de paquetes de Zypper impiden la instalación o actualización de los paquetes debido a conflictos de dependencia. Los bloqueos de paquetes pueden estar presentes por varias razones:
+ **Bloqueos aplicados por el cliente**: usted o el administrador del sistema bloquearon de forma manual los paquetes mediante comandos de Zypper como `zypper addlock`.
+ **Parches rechazados por el Administrador de parches**: Patch Manager bloquea automáticamente los paquetes cuando se especifican paquetes en la lista de **parches rechazados** de la línea de base de revisiones para impedir su instalación.
+ **Bloqueos residuales por operaciones interrumpidas**: en raras ocasiones, si una operación de parche se interrumpió (por ejemplo, al reiniciar el sistema) antes de que Patch Manager pueda eliminar los bloqueos temporales, es posible que los bloqueos de paquetes residuales permanezcan en el nodo administrado.
**Solución**: para resolver los problemas de bloqueo de paquetes de Zypper, siga estos pasos en función de la causa:
**Paso 1: identifique los paquetes bloqueados**
Conéctese al nodo de SLES administrado y ejecute el siguiente comando para ver todos los paquetes bloqueados actualmente:
```
sudo zypper locks
```
**Paso 2: determine el origen de los bloqueos**
+ Si los paquetes bloqueados son aquellos que usted bloqueó intencionalmente para garantizar la estabilidad del sistema, considere si es necesario que permanezcan bloqueados o si se pueden desbloquear temporalmente para parchearlos.
+ Si los paquetes bloqueados coinciden con las entradas de la lista de **parches rechazados** de la línea de base de revisiones, es probable que se trate de bloqueos residuales debidos a una interrupción de la operación del parche. Durante el funcionamiento normal, Patch Manager aplica estos bloqueos de manera temporal y los elimina automáticamente cuando finaliza la operación. Puede eliminar los paquetes de la lista de rechazados o modificar las reglas de la línea de base de revisiones.
+ Si no reconoce los paquetes bloqueados y no se bloquearon intencionalmente, es posible que se trate de bloqueos residuales de una operación de parche interrumpida anteriormente.
**Paso 3: elimine los bloqueos según convenga**
Utilice el siguiente comando para eliminar bloqueos de paquetes específicos:
```
sudo zypper removelock package-name
```
Para eliminar todos los bloqueos de paquetes (utilícelo con precaución), ejecute:
```
sudo zypper cleanlocks
```
**Paso 4: actualice la línea de base de revisiones (si corresponde)**
Si los bloqueos se debieron a parches rechazados en la línea de base de revisiones:
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Patch Manager**.
1. Seleccione la pestaña **Línea de base de revisiones**, y luego elija su línea de base de revisiones personalizada.
1. Seleccione **Acciones** y **Modificar la línea de base de revisiones**.
1. En la sección **Parches rechazados**, revise los paquetes de la lista y elimine los que deberían poder instalarse.
1. Seleccione **Save changes (Guardar cambios)**.
**Paso 5: vuelva a intentar la operación del parche**
Tras eliminar los bloqueos problemáticos y actualizar la línea de base de revisiones, si fuera necesario, vuelva a ejecutar el documento `AWS-RunPatchBaseline`.
**nota**
Cuando Patch Manager aplica bloqueos a los parches rechazados durante las operaciones `Install`, está diseñado para eliminar estos bloqueos automáticamente una vez finalizada la operación del parche. Si ve estos bloqueos cuando se ejecuta `sudo zypper locks`, significa que se interrumpió una operación de parche anterior antes de que se pudiera proceder a la limpieza. Sin embargo, si se interrumpe la operación del parche, es posible que sea necesaria una limpieza manual, tal como se describe en este procedimiento.
**Prevención**: para evitar futuros conflictos de bloqueo de Zypper:
+ Revise detenidamente la lista de parches rechazados de la línea de base de revisiones para asegurarse de que solo incluye los paquetes que realmente desea excluir.
+ Evite bloquear de forma manual los paquetes que puedan ser necesarios como dependencias para las actualizaciones de seguridad.
+ Si debe bloquear los paquetes manualmente, documente los motivos y revise los bloqueos con regularidad.
+ Asegúrese de que las operaciones del parche se completen correctamente y no se vean interrumpidas por el reinicio del sistema u otros factores.
+ Supervise las operaciones del parche hasta que se completen y evite interrumpirlas al reiniciar el sistema o realizar otras acciones que puedan impedir una limpieza adecuada de los bloqueos temporales.
### Problema: No se puede adquirir el bloqueo. La operación de parches está en curso.
**Problema**: Al ejecutar `AWS-RunPatchBaseline`, se produce un error de código 4 con los parches, y el siguiente mensaje de error.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Causa**: Este error se produce cuando se intentan ejecutar al mismo tiempo varias operaciones de parches en el mismo nodo administrado. El archivo de bloqueo impide las operaciones simultáneas de parches para evitar conflictos y garantizar la estabilidad del sistema.
**Solución**: Asegurar que las operaciones de parches no estén programadas para ejecutarse al mismo tiempo en el mismo nodo administrado. Revise las siguientes configuraciones para identificar los conflictos de programación y resolverlos:
+ **Políticas de revisión**: Revise las configuraciones de la política de parches en la Configuración Rápida para asegurarse de que no se superpongan con otras programaciones.
+ **Ventanas de mantenimiento**: Revise las asociaciones de las ventanas de mantenimiento para comprobar que varias ventanas no se dirijan a los mismos nodos administrados con tareas de aplicación de parches que se superponen.
+ **Operaciones manuales de Aplicar parche ahora**: Evite iniciar operaciones manuales de **Aplicar parche ahora** mientras se esté realizando la aplicación programada de parches.
## Errores al ejecutar `AWS-RunPatchBaseline` en Windows Server
**Topics**
+ [Asunto: pares de familia de productos y productos no coincidentes](#patch-manager-troubleshooting-product-family-mismatch)
+ [Asunto: el resultado de `AWS-RunPatchBaseline` devuelve un `HRESULT` (Windows Server)](#patch-manager-troubleshooting-hresult)
+ [Asunto: el nodo administrado no tiene acceso al catálogo de Windows Update ni a WSUS](#patch-manager-troubleshooting-instance-access)
+ [Asunto: el módulo PatchBaselineOperations de PowerShell no se puede descargar](#patch-manager-troubleshooting-module-not-downloadable)
+ [Asunto: revisiones faltantes](#patch-manager-troubleshooting-missing-patches)
+ [Problema: No se puede adquirir el bloqueo. La operación de parches está en curso.](#patch-manager-troubleshooting-windows-concurrent-lock)
### Asunto: pares de familia de productos y productos no coincidentes
**Problema**: cuando crea una línea de base de revisiones en la consola de Systems Manager, debe especificar una familia de productos y un producto. Por ejemplo, puede elegir:
+ **Product family (Familia de productos**: `Office`
**Producto**: `Office 2016`
**Causa:** si intenta crear una línea de base de revisiones con una par de producto y familia de productos que no coincide, se mostrará un mensaje de error. A continuación se indican los motivos por los que esto puede ocurrir:
+ Ha seleccionado un par de producto y familia de productos válidos, pero luego ha eliminado la selección de familia.
+ Ha seleccionado un producto de la lista secundaria **Obsolete or mismatched options (Opciones obsoletas o no coincidentes)** en lugar de seleccionar la lista secundaria **Available and matching options (Opciones disponibles y coincidentes)**.
Los elementos de la lista secundaria **Obsolete or mismatched options** (Opciones obsoletas o no coincidentes) de productos podrían haberse ingresado por error mediante un SDK o un comando `create-patch-baseline` de la AWS Command Line Interface (AWS CLI). Esto podría significar que se introdujo un error tipográfico o se asignó un producto a la familia del producto equivocado. Un producto también aparece en la lista secundaria **Obsolete or mismatched options** (Opciones obsoletas o no coincidentes) si se ha especificado para una línea de base de revisiones anterior, pero no tiene revisiones disponibles de Microsoft.
**Solución**: para evitar este problema en la consola, elija siempre opciones de las listas secundarias **Currently available options** (Opciones disponibles actualmente).
También puede ver los productos que tienen revisiones disponibles mediante el comando `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` de la AWS CLI o el comando `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)` de la API.
### Asunto: el resultado de `AWS-RunPatchBaseline` devuelve un `HRESULT` (Windows Server)
**Problema**: ha recibido un error como el siguiente.
```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when
attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80240437
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```
**Causa**: este resultado indica que las API nativas de Windows Update no han podido ejecutar las operaciones de aplicación de revisiones.
**Solución**: verifique el código `HResult` en los siguientes temas de microsoft.com para identificar los pasos de solución de problemas que permitan resolver el error:
+ [Códigos de error de Windows Update por componente](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Errores comunes y mitigación de Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### Asunto: el nodo administrado no tiene acceso al catálogo de Windows Update ni a WSUS
**Problema**: ha recibido un error como el siguiente.
```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for
PatchGroup :
BaselineId :
Baseline : null
SnapshotId :
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Scan
OperationStartTime : 1970-01-01T00:00:00.0000000Z
OperationEndTime : 1970-01-01T00:00:00.0000000Z
InstalledCount : -1
InstalledRejectedCount : -1
InstalledPendingRebootCount : -1
InstalledOtherCount : -1
FailedCount : -1
MissingCount : -1
NotApplicableCount : -1
UnreportedNotApplicableCount : -1
EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String
searchCriteria)
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58
e3\PatchWindows\_script.ps1:230 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv
oke-PatchBaselineOperation], Exception
+ FullyQualifiedErrorId : Exception Level 1:
Error Message: Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc
---Error truncated----
```
**Causa**: este error podría estar relacionado con los componentes de Windows Update, o bien con la falta de conectividad con el catálogo de Windows Update o con Windows Server Update Services (WSUS).
**Solución**: confirme que el nodo administrado tiene conectividad con el [catálogo de Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx) a través de una puerta de enlace de Internet, una puerta de enlace NAT o una instancia NAT. Si utiliza WSUS, confirme que el nodo administrado dispone de conectividad con el servidor WSUS de su entorno. Si la conectividad está disponible para el destino previsto, verifique otras causas posibles de en la documentación de Microsoft `HResult 0x80072EE2`. Esto podría significar un problema a nivel del sistema operativo.
### Asunto: el módulo PatchBaselineOperations de PowerShell no se puede descargar
**Problema**: ha recibido un error como el siguiente.
```
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------
C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\
PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1
failed to run commands: exit status 4294967295
```
**Solución**: verifique la conectividad del nodo administrado y los permisos a Amazon Simple Storage Service (Amazon S3). El rol de AWS Identity and Access Management (IAM) del nodo administrado debe utilizar los permisos mínimos citados en [SSM Agent Comunicaciones de AWS con buckets de S3 administrados de](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions). El nodo debe comunicarse con el punto de conexión de Amazon S3 a través del punto de conexión de la puerta de enlace de Amazon S3, la puerta de enlace NAT o la puerta de enlace de Internet. Para obtener más información acerca de los requisitos del punto de enlace de la VPC para AWS Systems Manager SSM Agent (SSM Agent), consulte [Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager](setup-create-vpc.md).
### Asunto: revisiones faltantes
**Problema:** `AWS-RunPatchbaseline` se ha completado correctamente, pero faltan algunos revisiones.
A continuación, se presentan algunas causas comunes y sus respectivas soluciones.
**Causa 1**: la base de referencia no es efectiva.
**Solución 1**: para comprobar si esta es la causa, utilice el siguiente procedimiento.
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. En el panel de navegación, elija **Run Command**.
1. Seleccione la pestaña **Command history** (Historial de comandos) y, a continuación, seleccione el comando cuya base de referencia desea verificar.
1. Seleccione el nodo administrado al que faltan revisiones.
1. Seleccione **Step 1 - Output** (Paso 1: Resultado) y busque el valor `BaselineId`.
1. Verifique la [configuración de la línea de base de revisiones](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) asignada, es decir, el sistema operativo, el nombre del producto, la clasificación y la gravedad de la línea de base de revisiones.
1. Vaya a [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) (Catálogo de Microsoft Update).
1. Busque los ID de los artículos de Microsoft Knowledge Base (KB) (por ejemplo, KB3216916).
1. Compruebe que el valor en **Product** (Producto) concuerde con el del nodo administrado y seleccione el **Title** (Título) correspondiente. Se abrirá una nueva ventana **Update Details** (Actualizar detalles).
1. En la pestaña **Overview** (Información general), la **classification** (clasificación) y la **MSRC severity** (gravedad de MSRC) deben concordar con la configuración de la línea de base de revisiones que encontró con anterioridad.
**Causa 2**: se reemplazó la revisión.
**Solución 2**: para verificar si esta es así, utilice el siguiente procedimiento.
1. Vaya a [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) (Catálogo de Microsoft Update).
1. Busque los ID de los artículos de Microsoft Knowledge Base (KB) (por ejemplo, KB3216916).
1. Compruebe que el valor en **Product** (Producto) concuerde con el del nodo administrado y seleccione el **Title** (Título) correspondiente. Se abrirá una nueva ventana **Update Details** (Actualizar detalles).
1. Vaya a la pestaña **Package Details** (Detalles del paquete). Busque una entrada en el encabezado **This update has been replaced by the following updates:** (Esta actualización se ha sustituido por las siguientes actualizaciones:).
**Causa 3**: la misma revisión puede tener diferentes números de KB debido a que Microsoft gestiona las actualizaciones online de WSUS y Window como canales de publicación independientes.
**Solución 3**: compruebe la elegibilidad de las revisiones. Si el paquete no está disponible en WSUS, instale la [compilación 14393.3115 del sistema operativo](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57). Si el paquete está disponible para todas las compilaciones del sistema operativo, instale las [compilaciones 18362.1256 y 18363.1256 del sistema operativo](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9).
### Problema: No se puede adquirir el bloqueo. La operación de parches está en curso.
**Problema**: Al ejecutar `AWS-RunPatchBaseline`, se produce un error de código 4 con los parches, y el siguiente mensaje de error.
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Causa**: Este error se produce cuando se intentan ejecutar al mismo tiempo varias operaciones de parches en el mismo nodo administrado. El archivo de bloqueo impide las operaciones simultáneas de parches para evitar conflictos y garantizar la estabilidad del sistema.
**Solución**: Asegurar que las operaciones de parches no estén programadas para ejecutarse al mismo tiempo en el mismo nodo administrado. Revise las siguientes configuraciones para identificar los conflictos de programación y resolverlos:
+ **Políticas de revisión**: Revise las configuraciones de la política de parches en la Configuración Rápida para asegurarse de que no se superpongan con otras programaciones.
+ **Ventanas de mantenimiento**: Revise las asociaciones de las ventanas de mantenimiento para comprobar que varias ventanas no se dirijan a los mismos nodos administrados con tareas de aplicación de parches que se superponen.
+ **Operaciones manuales de Aplicar parche ahora**: Evite iniciar operaciones manuales de **Aplicar parche ahora** mientras se esté realizando la aplicación programada de parches.
## Errores al ejecutar `AWS-RunPatchBaseline` en macOS
**Topics**
+ [Problema: No se puede adquirir el bloqueo. La operación de parches está en curso.](#patch-manager-troubleshooting-macos-concurrent-lock)
### Problema: No se puede adquirir el bloqueo. La operación de parches está en curso.
**Problema**: Al ejecutar `AWS-RunPatchBaseline`, se produce un error de código 4 con los parches, y el siguiente mensaje de error.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Causa**: Este error se produce cuando se intentan ejecutar al mismo tiempo varias operaciones de parches en el mismo nodo administrado. El archivo de bloqueo impide las operaciones simultáneas de parches para evitar conflictos y garantizar la estabilidad del sistema.
**Solución**: Asegurar que las operaciones de parches no estén programadas para ejecutarse al mismo tiempo en el mismo nodo administrado. Revise las siguientes configuraciones para identificar los conflictos de programación y resolverlos:
+ **Políticas de revisión**: Revise las configuraciones de la política de parches en la Configuración Rápida para asegurarse de que no se superpongan con otras programaciones.
+ **Ventanas de mantenimiento**: Revise las asociaciones de las ventanas de mantenimiento para comprobar que varias ventanas no se dirijan a los mismos nodos administrados con tareas de aplicación de parches que se superponen.
+ **Operaciones manuales de Aplicar parche ahora**: Evite iniciar operaciones manuales de **Aplicar parche ahora** mientras se esté realizando la aplicación programada de parches.
## Cómo utilizar manuales de procedimientos de Automatización de AWS Support
AWS Support proporciona dos manuales de procedimientos de Automatización que puede usar para solucionar determinados problemas relacionados con las revisiones.
+ `AWSSupport-TroubleshootWindowsUpdate`: el manual de procedimientos [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) se utiliza para identificar problemas que podrían causar un error en las actualizaciones de Windows Server para instancias de Windows Server de Amazon Elastic Compute Cloud (Amazon EC2).
+ `AWSSupport-TroubleshootPatchManagerLinux`: el manual de procedimientos [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) soluciona problemas comunes que pueden causar un error en las revisiones en nodos administrados basados en Linux con Patch Manager. El objetivo principal de este manual de procedimientos es identificar la causa raíz del error del comando de revisión y sugerir un plan de corrección.
**nota**
Se cobra un cargo por ejecutar manuales de procedimientos de Automatización. Para obtener más información, consulte los [precios de AWS Systems Manager para Automatización](https://aws.amazon.com/systems-manager/pricing/#Automation).
## Cómo ponerse en contacto con AWS Support
Si no encuentra soluciones a los problemas en esta sección o en los problemas de Systems Manager en [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager), y cuenta con un plan [Developer Business o Enterprise](https://aws.amazon.com/premiumsupport/plans) de Soporte, puede crear un caso de soporte técnico en [AWS Support](https://aws.amazon.com/premiumsupport/).
Antes de contactar con Soporte, recopile los siguientes elementos:
+ [Registros de SSM Agent](ssm-agent-logs.md)
+ Run CommandID de comando de , ID de periodo de mantenimiento o ID de ejecución de Automation
+ Para nodos administrados de Windows Server, recopile también lo siguiente:
+ `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` como se describe en la pestaña **Windows** de [Cómo se instalan los parches](patch-manager-installing-patches.md).
+ Registros de actualización de Windows: para Windows Server 2012 R2 y versiones anteriores, utilice `%windir%/WindowsUpdate.log`. Para Windows Server 2016 y más recientes, ejecute primero el comando [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps) de PowerShell antes de utilizar `%windir%/WindowsUpdate.log`.
+ Para nodos administrados de Linux, recopile también lo siguiente:
+ El contenido del directorio `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`