• 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). # 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.