• 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).
# Herramientas de nodos de AWS Systems Manager
AWS Systems Manager proporciona las siguientes herramientas para obtener acceso, administrar y configurar los *nodos administrados*. Un nodo administrado es cualquier máquina configurada para su uso con Systems Manager en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types).
**Topics**
+ [Conformidad de AWS Systems Manager](systems-manager-compliance.md)
+ [AWS Systems Manager Distributor](distributor.md)
+ [AWS Systems Manager Fleet Manager](fleet-manager.md)
+ [Activaciones híbridas de AWS Systems Manager](activations.md)
+ [Inventario de AWS Systems Manager](systems-manager-inventory.md)
+ [AWS Systems Manager Patch Manager](patch-manager.md)
+ [AWS Systems Manager Run Command](run-command.md)
+ [AWS Systems Manager Session Manager](session-manager.md)
+ [AWS Systems Manager State Manager](systems-manager-state.md)
# Conformidad de AWS Systems Manager
Puede utilizar Cumplimiento, una herramienta de AWS Systems Manager, para analizar la flota de nodos administrados en busca de cumplimiento de revisiones e incoherencias de configuración. Puede recopilar y agregar datos de varias Cuentas de AWS y regiones, y luego desglosarlas en recursos específicos que no sean conformes. De forma predeterminada, Cumplimiento muestra datos de cumplimiento actuales sobre la aplicación de parches en Patch Manager y de asociaciones de State Manager. (Patch Manager y State Manager también son herramientas de AWS Systems Manager). Para comenzar a utilizar Compliance, abra la [consola de Systems Manager](https://console.aws.amazon.com//systems-manager/compliance). En el panel de navegación, elija **Compliance**.
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).
Compliance ofrece los siguientes beneficios y características adicionales:
+ visualización del seguimiento de cambios y el historial de conformidad para los datos de aplicación de parches de Patch Manager y las asociaciones de State Manager mediante AWS Config
+ Personalización de Compliance para crear sus propios tipos de conformidad en función de sus requisitos empresariales o de TI.
+ Corrija problemas mediante Run Command, otra herramienta de AWS Systems Manager, State Manager o Amazon EventBridge.
+ Transferencia de datos a Amazon Athena y Amazon Quick para generar informes de toda la flota.
**Compatibilidad con EventBridge**
Esta herramienta de Systems Manager se admite como un tipo de *evento* en las reglas de Amazon EventBridge. Para obtener más información, consulte [Cómo monitorear eventos de Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md) y [Referencia: patrones y tipos de eventos de Amazon EventBridge para Systems Manager](reference-eventbridge-events.md).
**Chef InSpecIntegración de**
Systems Manager se integra a [https://www.chef.io/inspec/](https://www.chef.io/inspec/). InSpec es un marco de trabajo de tiempo de ejecución de código abierto que permite crear perfiles de lenguaje natural en GitHub o en Amazon Simple Storage Service (Amazon S3). A continuación, puede utilizar Systems Manager para ejecutar análisis de conformidad y ver cuáles nodos administrados son conformes y cuáles no. Para obtener más información, consulte [Utilización de perfiles de Chef InSpec con la conformidad de Systems Manager](integration-chef-inspec.md).
**Precios**
Compliance se ofrece sin cargo adicional. Solo pagará por los recursos de AWS que utilice.
**Topics**
+ [Introducción a Compliance](compliance-prerequisites.md)
+ [Cómo configurar permisos para Compliance](compliance-permissions.md)
+ [Cómo crear una sincronización de datos de recursos para Compliance](compliance-datasync-create.md)
+ [Detalles sobre el cumplimiento](compliance-about.md)
+ [Cómo eliminar una sincronización de datos de recursos para Compliance](systems-manager-compliance-delete-RDS.md)
+ [Solución de problemas de conformidad con EventBridge](compliance-fixing.md)
+ [Asignar metadatos de conformidad personalizados mediante la AWS CLI](compliance-custom-metadata-cli.md)
# Introducción a Compliance
Para comenzar con Cumplimiento, una herramienta de AWS Systems Manager, complete las siguientes tareas.
****
| Tarea | Para obtener más información |
| --- | --- |
| Cumplimiento funciona con los datos de revisiones en Patch Manager y las asociaciones de State Manager. (Patch Manager y State Manager también son herramientas de AWS Systems Manager). Compliance también funciona con tipos de conformidad personalizados en nodos administrados mediante Systems Manager. Verifique que haya completado los requisitos de configuración para las instancias de Amazon Elastic Compute Cloud (Amazon EC2) y las máquinas que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). | [Cómo configurar la consola unificada de Systems Manager para una organización](systems-manager-setting-up-organizations.md) |
| Actualice el rol AWS Identity and Access Management (IAM) que utilizan sus nodos administrados para restringir los permisos de Compliance. | [Cómo configurar permisos para Compliance](compliance-permissions.md) |
| Si tiene previsto monitorear la conformidad de parches, compruebe que ha configurado Patch Manager. Debe realizar las operaciones de aplicación de parches mediante Patch Manager para que Compliance pueda mostrar los datos de conformidad de parches. | [AWS Systems Manager Patch Manager](patch-manager.md) |
| Si tiene previsto monitorear la conformidad de asociación, verifique que haya creado asociaciones de State Manager. Debe crear asociaciones para que Compliance pueda mostrar los datos de conformidad de asociación. | [AWS Systems Manager State Manager](systems-manager-state.md) |
| (Opcional) Configure el sistema para ver el seguimiento de cambios y el historial de conformidad. | [Visualización del seguimiento de cambios y del historial de Configuration Compliance](compliance-about.md#compliance-history) |
| (Opcional) Cree tipos de conformidad personalizados. | [Asignar metadatos de conformidad personalizados mediante la AWS CLI](compliance-custom-metadata-cli.md) |
| (Opcional) Cree una sincronización de datos de recursos para agregar todos los datos de conformidad a un bucket de Amazon Simple Storage Service (Amazon S3) de destino. | [Cómo crear una sincronización de datos de recursos para Compliance](compliance-datasync-create.md) |
# Cómo configurar permisos para Compliance
Como práctica recomendada de seguridad, sugerimos que actualice el rol AWS Identity and Access Management (IAM) que utilizan los nodos administrados con los siguientes permisos para restringir la capacidad del nodo de utilizar la acción de la API [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html). Esta acción de API registra un tipo de conformidad junto con sus detalles en un recurso designado, como una instancia de Amazon EC2 o un nodo administrado.
Si su nodo es una instancia de Amazon EC2, debe actualizar el perfil de instancia de IAM utilizado por la instancia con los siguientes permisos. Para obtener más información sobre los perfiles de instancia para instancias EC2 administradas por Systems Manager, consulta [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md). Para otros tipos de nodos administrados, actualiza el rol de IAM utilizado por el nodo con los siguientes permisos. Para obtener más información, consulte [Actualización de los permisos de un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) en la *Guía del usuario de IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:SourceInstanceARN": "${ec2:SourceInstanceARN}"
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:PutComplianceItems"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"ssm:SourceInstanceARN": "${ssm:SourceInstanceARN}"
}
}
}
]
}
```
------
# Cómo crear una sincronización de datos de recursos para Compliance
Puede utilizar la característica sincronización de datos de recursos de AWS Systems Manager para enviar datos de conformidad de todos los nodos administrados a un bucket de Amazon Simple Storage Service (Amazon S3) de destino. Cuando crea la sincronización, puede especificar los nodos administrados de varias Cuentas de AWS, Regiones de AWS y su entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). A continuación, la sincronización de datos de recursos actualiza automáticamente los datos centralizados cuando se recopilan los nuevos datos de conformidad. Con todos los datos de conformidad almacenados en un bucket de S3 de destino, puede usar servicios como Amazon Athena y Amazon Quick para consultar y analizar los datos agregados. La configuración de la sincronización de datos de recursos para Compliance es una operación que se tiene que realizar una vez.
Utilice el siguiente procedimiento para crear una sincronización de datos de recursos para Compliance mediante la Consola de administración de AWS.
**Cómo crear y configurar un bucket de S3 para la sincronización de datos de recursos (consola)**
1. Abra la consola de Amazon S3 en [https://console.aws.amazon.com/s3](https://console.aws.amazon.com/s3/).
1. Cree un bucket para almacenar sus datos de conformidad agregados. Para obtener más información, consulte [Crear un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) en la *Guía del usuario de Amazon Simple Storage Service*. Anote el nombre de bucket y la Región de AWS donde lo creó.
1. Abra el bucket, seleccione la pestaña **Permissions (Permisos)** y, a continuación, elija **Bucket Policy (Política de bucket)**.
1. Copie y pegue la siguiente política de bucket en el editor de políticas. Reemplace amzn-s3-demo-bucke y *Account-ID* por el nombre del bucket de S3 que ha creado y un ID de Cuenta de AWS válido. Si lo desea, reemplace *Bucket-Prefix* por el nombre de un prefijo de Amazon S3 (subdirectorio). Si no ha creado un prefijo, quite *Bucket-Prefix*/ del ARN de la política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/Bucket-Prefix/*/accountid=111122223333/*"],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}
```
------
**Cómo crear una sincronización de datos de recursos**
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. Elija **Account management** (Administración de cuenta), **Resource Data Syncs** (Sincronizaciones de datos de recursos) y, a continuación, elija **Create resource data sync** (Crear sincronización de datos de recursos).
1. En el campo **Sync name** (Sincronizar nombre) ingrese el nombre de la configuración de sincronización.
1. En el campo **Bucket name** (Nombre de bucket), ingrese el nombre del bucket de Amazon S3 que ha creado al comienzo de este procedimiento.
1. (Opcional) En el campo **Prefijo de bucket**, ingrese el nombre de un prefijo de bucket de S3 (subdirectorio).
1. En el campo **Región de bucket**, elija **Esta región** si el bucket de S3 que ha creado se encuentra en la Región de AWS actual. Si el bucket se encuentra en otra Región de AWS, elija **Otra región** e ingrese el nombre de la región.
**nota**
Si la sincronización y el bucket de S3 de destino se encuentran en regiones diferentes, es posible que esté sujeto a precios de transferencia de datos. Para obtener más información, consulte [Precios de Amazon S3](https://aws.amazon.com/s3/pricing/).
1. Seleccione **Crear**.
# Detalles sobre el cumplimiento
Cumplimiento, una herramienta de AWS Systems Manager, recopila y genera informes de datos sobre el estado de aplicación de parches en Patch Manager, la aplicación de parches y las asociaciones en State Manager. (Patch Manager y State Manager también son herramientas de AWS Systems Manager). Compliance también notifica sobre los tipos de conformidad personalizados que ha especificado para los nodos administrados. En esta sección, se incluyen detalles sobre cada uno de estos tipos de conformidad y sobre cómo ver los datos de conformidad de Systems Manager. En esta sección, también se incluye información sobre cómo ver el seguimiento de cambios y el historial de cumplimiento.
**nota**
Systems Manager se integra a [https://www.chef.io/inspec/](https://www.chef.io/inspec/). InSpec es un marco de trabajo de tiempo de ejecución de código abierto que permite crear perfiles de lenguaje natural en GitHub o en Amazon Simple Storage Service (Amazon S3). A continuación, puede utilizar Systems Manager para ejecutar análisis de conformidad y ver cuáles instancias son conformes y cuáles no. Para obtener más información, consulte [Utilización de perfiles de Chef InSpec con la conformidad de Systems Manager](integration-chef-inspec.md).
## Acerca de la conformidad de parches
Después de utilizar Patch Manager para instalar los parches en las instancias, la información sobre el estado de la conformidad estará disponible inmediatamente en la consola o como respuesta a los comandos de la AWS Command Line Interface (AWS CLI) o a las operaciones de la API de Systems Manager correspondientes.
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).
## Acerca de la conformidad de las asociaciones de State Manager
Después de crear una o varias asociaciones de State Manager, la información sobre el estado de la conformidad estará disponible inmediatamente en la consola o como respuesta a los comandos de la AWS CLI o a las operaciones de la API de Systems Manager correspondientes. Para las asociaciones, Compliance muestra los estados `Compliant` o `Non-compliant` y el nivel de severidad asignados a la asociación, como, por ejemplo, `Critical` o `Medium`.
Cuando State Manager ejecuta una asociación en un nodo administrado, desencadena un proceso de agregación de cumplimiento que actualiza el estado de cumplimiento de todas las asociaciones de ese nodo. El valor `ExecutionTime` de los informes de cumplimiento representa cuando Systems Manager capturó el estado de cumplimiento, no cuándo se ejecutó la asociación en el nodo administrado. Esto significa que varias asociaciones pueden mostrar valores de `ExecutionTime` idénticos incluso si se ejecutaron en momentos diferentes. Para determinar los tiempos reales de ejecución de la asociación, consulte el historial de ejecución de la asociación mediante el comando de la AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association-execution-targets.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association-execution-targets.html) o consultando los detalles de la ejecución en la consola.
## Acerca de la conformidad personalizada
Puede asignar metadatos de conformidad a un nodo administrado. Estos metadatos se pueden agregar a otros datos de conformidad para elaborar informes de conformidad. Por ejemplo, supongamos que su negocio ejecuta las versiones 2.0, 3.0 y 4.0 del software X en sus nodos administrados. La empresa desea estandarizar la versión 4.0, lo que significa que las instancias que ejecutan las versiones 2.0 y 3.0 no son conformes. Puede utilizar la operación [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) de la API para indicar qué nodos administrados ejecutan versiones anteriores del software X. Solo puede asignar los metadatos de conformidad mediante la AWS CLI, AWS Tools for Windows PowerShell o los SDK. El siguiente comando de muestra de la CLI asigna metadatos de conformidad a una instancia administrada y especifica el tipo de conformidad en el formato requerido `Custom:`. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id i-1234567890abcdef0 \
--resource-type ManagedInstance \
--compliance-type Custom:SoftwareXCheck \
--execution-summary ExecutionTime=AnyStringToDenoteTimeOrDate \
--items Id=Version2.0,Title=SoftwareXVersion,Severity=CRITICAL,Status=NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id i-1234567890abcdef0 ^
--resource-type ManagedInstance ^
--compliance-type Custom:SoftwareXCheck ^
--execution-summary ExecutionTime=AnyStringToDenoteTimeOrDate ^
--items Id=Version2.0,Title=SoftwareXVersion,Severity=CRITICAL,Status=NON_COMPLIANT
```
------
**nota**
El parámetro `ResourceType` solo es compatible con `ManagedInstance`. Si agrega conformidad personalizada a un dispositivo de núcleo de AWS IoT Greengrass administrado, debe especificar un `ResourceType` de `ManagedInstance`.
Los administradores de conformidad pueden ver resúmenes o crear informes sobre qué nodos son conformes o no lo son. Puede asignar un máximo de 10 tipos de conformidad personalizados distintos a un nodo administrado.
Para ver un ejemplo de cómo crear un tipo de conformidad personalizada y ver los datos de conformidad, consulte [Asignar metadatos de conformidad personalizados mediante la AWS CLI](compliance-custom-metadata-cli.md).
## Visualización de los datos de conformidad actuales
En esta sección, se describe cómo ver los datos de conformidad en la consola de Systems Manager y mediante la AWS CLI. Para obtener información sobre cómo ver el seguimiento de cambios y el historial de cumplimiento de los parches y las asociaciones, consulte [Visualización del seguimiento de cambios y del historial de Configuration Compliance](#compliance-history).
**Topics**
+ [Visualización de los datos de conformidad actuales (consola)](#compliance-view-results-console)
+ [Visualización de los datos de conformidad actuales (AWS CLI)](#compliance-view-data-cli)
### Visualización de los datos de conformidad actuales (consola)
Utilice el siguiente procedimiento para ver los datos de conformidad en la consola de Systems Manager.
**Para ver los informes de conformidad actuales en la 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 **Compliance**.
1. En la sección **Compliance dashboard filtering** (Filtrado de paneles de conformidad), elija una opción para filtrar los datos de conformidad. La sección **Compliance resources summary** (Resumen de recursos de conformidad) muestra recuentos de datos de conformidad según el filtro que eligió.
1. Para obtener más información sobre un recurso, desplácese hacia abajo hasta la sección **Details overview for resources** (Información general de los detalles de los recursos) y elija el ID de un nodo administrado.
1. En la página de detalles **Instance ID** (ID de instancia) o **Name** (Nombre), elija la pestaña **Configuration compliance** (Conformidad de configuración) para ver un informe detallado de conformidad de configuración del nodo administrado.
**nota**
Para obtener información sobre cómo solucionar los problemas de conformidad, consulte [Solución de problemas de conformidad con EventBridge](compliance-fixing.md).
### Visualización de los datos de conformidad actuales (AWS CLI)
Puede ver resúmenes de los datos de conformidad para la aplicación de parches, las asociaciones y los tipos de conformidad personalizados en la AWS CLI por medio de los siguientes comandos de la AWS CLI.
[https://docs.aws.amazon.com/cli/latest/reference/ssm/list-compliance-summaries.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-compliance-summaries.html)
devuelve el recuento de resumen de los estados de asociación que son conformes y no conformes según el filtro que especifique. (API: [ListComplianceSummaries](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListComplianceSummaries.html))
[https://docs.aws.amazon.com/cli/latest/reference/ssm/list-resource-compliance-summaries.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-resource-compliance-summaries.html)
Devuelve un recuento de resumen de nivel de recurso. El resumen incluye información sobre los estados conformes y no conformes, así como recuentos detallados de gravedad de elemento de conformidad, según los criterios de filtro que especifique. (API: [ListResourceComplianceSummaries](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListResourceComplianceSummaries.html))
Puede ver los datos de conformidad adicionales para la aplicación de parches por medio de los siguientes comandos de la AWS CLI.
[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-group-state.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-group-state.html)
muestra el estado de conformidad de parches agregados de alto nivel correspondiente a un grupo de parches. (API: [DescribePatchGroupState](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchGroupState.html))
[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patch-states-for-patch-group.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-patch-states-for-patch-group.html)
devuelve el estado de parche de alto nivel de las instancias en el grupo de parches especificados. (API: [DescribeInstancePatchStatesForPatchGroup](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatchStatesForPatchGroup.html))
**nota**
Para ver una ilustración de cómo configurar la aplicación de parches y los detalles de conformidad de los parches; mediante la 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).
## Visualización del seguimiento de cambios y del historial de Configuration Compliance
Systems Manager Compliance muestra datos de conformidad *actuales* sobre la aplicación de revisiones y las asociaciones para los nodos administrados. Puede ver el seguimiento de cambios y el historial de conformidad de la aplicación de parches y las asociaciones mediante [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/). AWS Config proporciona una vista detallada de la configuración de los recursos de AWS de su Cuenta de AWS. Esto incluye cómo se relacionan los recursos entre sí y cómo se han configurado en el pasado, para que pueda ver cómo las configuraciones y las relaciones cambian a lo largo del tiempo. Para ver el seguimiento de cambios y el historial de conformidad de la aplicación de parches y las asociaciones, debe habilitar los siguientes recursos en AWS Config:
+ `SSM:PatchCompliance`
+ `SSM:AssociationCompliance`
Para obtener información sobre cómo elegir y configurar estos recursos específicos en AWS Config, consulte [Selección de los recursos que debe registrar AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html) en la *Guía del desarrollador de AWS Config*.
**nota**
Para obtener información sobre precios de AWS Config, consulte [precios](https://aws.amazon.com/config/pricing/).
# Cómo eliminar una sincronización de datos de recursos para Compliance
Si ya no desea utilizar AWS Systems Manager Compliance para ver los datos de conformidad, se recomienda que elimine las sincronizaciones de datos de recursos utilizadas para la recopilación de datos de Compliance.
**Cómo eliminar una sincronización de datos de recursos de Compliance**
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. Elija **Account management** (Administración de cuentas) y, a continuación, **Resource data sync** (Sincronizaciones de datos de recursos).
1. Elija una sincronización en la lista.
**importante**
Asegúrese de elegir la sincronización utilizada para Compliance. Systems Manager admite la sincronización de datos de recursos para varias herramientas. Si elige una sincronización incorrecta, podría interrumpir la agregación de datos para Systems Manager Explorer o Systems Manager Inventory.
1. Elija **Eliminar**.
1. Elimine el bucket de Amazon Simple Storage Service (Amazon S3) en el que se almacenaron los datos. Para obtener información acerca de cómo se elimina un bucket de S3, consulte [Eliminación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html).
# Solución de problemas de conformidad con EventBridge
Puede solucionar rápidamente los problemas de cumplimiento de revisiones y asociaciones mediante Run Command, una herramienta de AWS Systems Manager. Puede dirigirse a una instancia o a ID o etiquetas de dispositivos de núcleo de AWS IoT Greengrass y ejecutar el documento `AWS-RunPatchBaseline` o el documento `AWS-RefreshAssociation`. Si actualizar la asociación o volver a ejecutar la base de referencia de revisiones no soluciona el problema de conformidad, debe investigar sus asociaciones, bases de referencia de revisiones o configuraciones de instancias para comprender por qué las operaciones de Run Command no resolvieron el problema.
Para obtener más información sobre la aplicación de parches, consulte [AWS Systems Manager Patch Manager](patch-manager.md) y [Documento de comandos SSM para aplicar revisiones: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
Para obtener más información sobre las asociaciones, consulte [Trabajo con asociaciones en Systems Manager](state-manager-associations.md).
Para obtener más información sobre cómo ejecutar un comando, consulte [AWS Systems Manager Run Command](run-command.md).
**Especificación de Compliance como el destino de un evento de EventBridge**
También puede configurar Amazon EventBridge para que realice una acción en respuesta a los eventos de Systems Manager Compliance. Por ejemplo, si uno o varios nodos administrados no pueden instalar actualizaciones de revisiones críticas o ejecutar una asociación que instala software antivirus, puede configurar EventBridge para ejecutar el documento `AWS-RunPatchBaseline` o el documento `AWS-RefreshAssocation` cuando se produzca el evento de Compliance.
Utilice el siguiente procedimiento para configurar Compliance como el destino de un evento de EventBridge.
**Para configurar Compliance como el destino de un evento de EventBridge (consola)**
1. Abra la consola de Amazon EventBridge en [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. En el panel de navegación, seleccione **Reglas**.
1. Elija **Creación de regla**.
1. Escriba un nombre y una descripción para la regla.
Una regla no puede tener el mismo nombre que otra regla de la misma Región de AWS y del mismo bus de eventos.
1. En **Bus de eventos**, seleccione el bus de eventos que desea asociar a esta regla. Si desea que esta regla responda a eventos coincidentes procedentes de su propia Cuenta de AWS, seleccione **default** (predeterminado). Cuando un Servicio de AWS en su cuenta emite un evento, siempre va al bus de eventos predeterminado de su cuenta.
1. En **Tipo de regla**, elija **Regla con un patrón de evento**.
1. Elija **Siguiente**.
1. En **Origen del evento**, elija **Eventos de AWS o eventos de socios de EventBridge**.
1. En la sección **Event pattern** (Patrón de eventos), elija **Event pattern form** (Formulario de patrón de eventos).
1. Para **Event source** (origen de eventos), elija **AWSservices** (servicios).
1. En **AWS service** (Servicio de ), elija **Systems Manager**.
1. En el campo **Event Type** (Tipo de evento), elija **Configuration Compliance** (Compliance de configuración).
1. En **Specific detail type(s)** (Tipos de detalle específicos), elija **Configuration Compliance State Change** (Cambio de estado en la conformidad de la configuración).
1. Elija **Siguiente**.
1. En **Tipos de destino**, seleccione **Servicio de AWS**.
1. En **Select a target** (Seleccione un destino), elija **Systems Manager Run Command**.
1. En la lista **Document** (Documento), elija un documento de Systems Manager (documento de SSM) que se ejecutará cuando se invoque el objetivo. Por ejemplo, elija `AWS-RunPatchBaseline` en el caso de un evento de parche no conforme o elija `AWS-RefreshAssociation` en el caso de un evento de asociación no conforme.
1. Especifique la información del resto de los campos y los parámetros.
**nota**
Los campos y los parámetros obligatorios tienen un asterisco (\$1) junto a su nombre. Para crear un destino, debe especificar un valor para cada uno de los parámetros o campos obligatorios. Si no lo hace, el sistema crea la regla, pero esta no se ejecuta.
1. Elija **Siguiente**.
1. (Opcional) Introduzca una o varias etiquetas para la regla. Para obtener más información, consulte [Etiquetado de los recursos de Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html) en la *Guía del usuario de Amazon EventBridge*.
1. Elija **Siguiente**.
1. Revise los detalles de la regla y seleccione **Creación de regla**.
# Asignar metadatos de conformidad personalizados mediante la AWS CLI
El siguiente procedimiento lo guía a través del proceso de utilizar la AWS Command Line Interface (AWS CLI) para el llamado a la operación [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html) de la API de AWS Systems Manager para asignar los metadatos de conformidad personalizados a un recurso. También puede utilizar esta operación de la API para asignar manualmente metadatos de conformidad de revisiones o asociaciones a un nodo administrado, tal como se muestra en la siguiente explicación. Para obtener más información sobre la conformidad personalizada, consulte [Acerca de la conformidad personalizada](compliance-about.md#compliance-custom).
**Para asignar metadatos de conformidad personalizados a una instancia administrada (AWS CLI)**
1. 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).
1. Ejecute el siguiente comando para asignar metadatos de conformidad personalizados a un nodo administrado. Reemplace cada *example resource placeholder* con su propia información. El parámetro `ResourceType` solo admite un valor de `ManagedInstance`. Especifique este valor incluso si asigna metadatos de conformidad personalizados a un dispositivo de núcleo de AWS IoT Greengrass administrado.
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Custom:user-defined_string \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value \
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Custom:user-defined_string ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value ^
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
1. Repita el paso anterior para asignar metadatos de conformidad personalizados adicionales a uno o más nodos. También puede asignar manualmente los metadatos de conformidad de revisión o asociación a los nodos administrados mediante los comandos siguientes:
Metadatos de conformidad de asociación
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Association \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value \
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Association ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value ^
--items Id=user-defined_ID,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT
```
------
Metadatos de conformidad de parche
------
#### [ Linux & macOS ]
```
aws ssm put-compliance-items \
--resource-id instance_ID \
--resource-type ManagedInstance \
--compliance-type Patch \
--execution-summary ExecutionTime=user-defined_time_and/or_date_value,ExecutionId=user-defined_ID,ExecutionType=Command \
--items Id=for_example, KB12345,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT,Details="{PatchGroup=name_of_group,PatchSeverity=the_patch_severity, for example, CRITICAL}"
```
------
#### [ Windows ]
```
aws ssm put-compliance-items ^
--resource-id instance_ID ^
--resource-type ManagedInstance ^
--compliance-type Patch ^
--execution-summary ExecutionTime=user-defined_time_and/or_date_value,ExecutionId=user-defined_ID,ExecutionType=Command ^
--items Id=for_example, KB12345,Title=user-defined_title,Severity=one_or_more_comma-separated_severities:CRITICAL, MAJOR, MINOR,INFORMATIONAL, or UNSPECIFIED,Status=COMPLIANT or NON_COMPLIANT,Details="{PatchGroup=name_of_group,PatchSeverity=the_patch_severity, for example, CRITICAL}"
```
------
1. Ejecute el siguiente comando para ver una lista de los elementos de conformidad específicos de un nodo administrado. Utilice filtros para desglosar los datos de conformidad específicos.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-items \
--resource-ids instance_ID \
--resource-types ManagedInstance \
--filters one_or_more_filters
```
------
#### [ Windows ]
```
aws ssm list-compliance-items ^
--resource-ids instance_ID ^
--resource-types ManagedInstance ^
--filters one_or_more_filters
```
------
En los siguientes ejemplos se muestra cómo utilizar este comando con filtros.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-items \
--resource-ids i-02573cafcfEXAMPLE \
--resource-type ManagedInstance \
--filters Key=DocumentName,Values=AWS-RunPowerShellScript Key=Status,Values=NON_COMPLIANT,Type=NotEqual Key=Id,Values=cee20ae7-6388-488e-8be1-a88ccEXAMPLE Key=Severity,Values=UNSPECIFIED
```
------
#### [ Windows ]
```
aws ssm list-compliance-items ^
--resource-ids i-02573cafcfEXAMPLE ^
--resource-type ManagedInstance ^
--filters Key=DocumentName,Values=AWS-RunPowerShellScript Key=Status,Values=NON_COMPLIANT,Type=NotEqual Key=Id,Values=cee20ae7-6388-488e-8be1-a88ccEXAMPLE Key=Severity,Values=UNSPECIFIED
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=OverallSeverity,Values=UNSPECIFIED
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=OverallSeverity,Values=UNSPECIFIED
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=OverallSeverity,Values=UNSPECIFIED Key=ComplianceType,Values=Association Key=InstanceId,Values=i-02573cafcfEXAMPLE
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=OverallSeverity,Values=UNSPECIFIED Key=ComplianceType,Values=Association Key=InstanceId,Values=i-02573cafcfEXAMPLE
```
------
1. Ejecute el siguiente comando para ver un resumen de los estados de conformidad. Utilice filtros para desglosar los datos de conformidad específicos.
```
aws ssm list-resource-compliance-summaries --filters One or more filters.
```
En los siguientes ejemplos se muestra cómo utilizar este comando con filtros.
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=ExecutionType,Values=Command
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=ExecutionType,Values=Command
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-resource-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=OverallSeverity,Values=CRITICAL
```
------
#### [ Windows ]
```
aws ssm list-resource-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=OverallSeverity,Values=CRITICAL
```
------
1. Ejecute el siguiente comando para ver un recuento de resumen de los recursos conformes y no conformes correspondientes a un tipo de conformidad. Utilice filtros para desglosar los datos de conformidad específicos.
```
aws ssm list-compliance-summaries --filters One or more filters.
```
En los siguientes ejemplos se muestra cómo utilizar este comando con filtros.
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=PatchGroup,Values=TestGroup
```
------
#### [ Windows ]
```
aws ssm list-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=PatchGroup,Values=TestGroup
```
------
------
#### [ Linux & macOS ]
```
aws ssm list-compliance-summaries \
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=ExecutionId,Values=4adf0526-6aed-4694-97a5-14522EXAMPLE
```
------
#### [ Windows ]
```
aws ssm list-compliance-summaries ^
--filters Key=AWS:InstanceInformation.PlatformType,Values=Windows Key=ExecutionId,Values=4adf0526-6aed-4694-97a5-14522EXAMPLE
```
------
# AWS Systems Manager Distributor
Distributor, una herramienta de AWS Systems Manager, lo ayuda a empaquetar y publicar software en nodos administrados de AWS Systems Manager. Puede empaquetar y publicar su propio software o utilizar Distributor para buscar y publicar paquetes de software de agente proporcionados por AWS, como **AmazonCloudWatchAgent**, o paquetes de terceros como **Trend Micro**.La publicación de un paquete anuncia versiones específicas del documento del paquete en nodos administrados que identifica mediante ID de nodo, ID de Cuenta de AWS, etiquetas o una Región de AWS. Para comenzar a utilizar Distributor, abra la [consola de Systems Manager](https://console.aws.amazon.com//systems-manager/distributor). En el panel de navegación, elija **Distributor**.
Después de crear un paquete en Distributor, puede instalar el paquete de una de las siguientes maneras:
+ Una vez mediante [AWS Systems Manager Run Command](run-command.md)
+ De forma programada mediante [AWS Systems Manager State Manager](systems-manager-state.md)
**importante**
Los paquetes distribuidos por vendedores externos no son gestionados por AWS y son publicados por el vendedor del paquete. Le recomendamos ejercer su propia diligencia debida adicional para garantizar la conformidad de los controles de seguridad internos. La seguridad es una responsabilidad compartida entre AWS y usted. Se describe como el modelo de responsabilidad compartida. Para obtener más información, consulte el [Modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/).
## ¿Cómo puede Distributor beneficiar a mi organización?
Distributor ofrece las ventajas siguientes:
+ **Un paquete, muchas plataformas**
Al crear un paquete en Distributor, el sistema crea un documento de AWS Systems Manager (documento de SSM). Puede adjuntar archivos .zip a este documento. Al ejecutar Distributor, el sistema procesa las instrucciones del documento de SSM e instala el paquete de software en el archivo .zip de los destinos especificados. Distributor admite varios sistemas operativos, incluidos Windows, Ubuntu Server, Debian Server y Red Hat Enterprise Linux. Para obtener más información acerca de las plataformas admitidas, consulte [Plataformas de paquetes y arquitecturas admitidas](#what-is-a-package-platforms).
+ **Control de acceso de paquetes en los grupos de instancias administradas**
Puede utilizar Run Command o State Manager para controlar cuáles de los nodos administrados obtienen un paquete y qué versión de ese paquete. Run Command y State Manager son herramientas de AWS Systems Manager. Los nodos administrados se pueden agrupar por ID de instancia o dispositivo, números de Cuenta de AWS, etiquetas o Regiones de AWS. Puede utilizar las asociaciones de State Manager para ofrecer diferentes versiones de un paquete a diferentes grupos de instancias.
+ **Muchos paquetes de agente de AWS incluidos y listos para usar**
Distributor incluye muchos paquetes de agente de AWS que están listos para implementar en los nodos administrados. Busque los paquetes que publicó Distributor `Packages` en la página de lista `Amazon`. Entre los ejemplos se incluyen `AmazonCloudWatchAgent` y `AWSPVDriver`.
+ **Automatizar la implementación **
Para mantener su entorno actual, utilice State Manager para programar paquetes para la implementación automática en los nodos de destino cuando dichos nodos se lancen por primera vez.
## ¿Quién debe utilizar Distributor?
+ Cualquier cliente de AWS que desee crear paquetes de software nuevos o implementar paquetes existentes, incluidos paquetes publicados de AWS, en varios nodos administrados de Systems Manager al mismo tiempo.
+ Los desarrolladores de software que creen paquetes de software.
+ Los administradores que sean responsables de mantener los nodos administrados de Systems Manager actualizados con la versión más reciente de los paquetes de software.
## ¿Cuáles son las características de Distributor?
+ **Implementación de paquetes en las instancias de Windows y Linux**
Con Distributor, puede implementar paquetes de software en instancias de Amazon Elastic Compute Cloud (Amazon EC2) y dispositivos de núcleo de AWS IoT Greengrass para Linux y Windows Server. Para ver una lista de los tipos de sistemas operativos de instancia admitidos, consulte [Plataformas de paquetes y arquitecturas admitidas](#what-is-a-package-platforms).
**nota**
Distributor no es compatible con el sistema operativo macOS.
+ **Implementar paquetes una vez o mediante programación automatizada**
Puede elegir implementar paquetes una vez, en una programación periódica o cuando la versión del paquete predeterminado cambie a una versión diferente.
+ **Reinstale completamente los paquetes o realice actualizaciones in situ**
Para instalar una nueva versión del paquete, puede desinstalar completamente la versión actual e instalar una nueva en su lugar, o solo actualizar la versión actual con componentes nuevos y actualizados, según el *script de actualización* que proporcione. La aplicación del paquete no está disponible durante una reinstalación, pero puede permanecer disponible durante una actualización in situ. Las actualizaciones in situ son especialmente útiles para aplicaciones de supervisión de seguridad u otros casos en los que necesita evitar el tiempo de inactividad de las aplicaciones.
+ **Acceso de la consola, CLI, PowerShell y SDK a las capacidades de Distributor**
Puede trabajar con Distributor mediante la consola de Systems Manager, AWS Command Line Interface (AWS CLI), Herramientas de AWS para PowerShell o el AWS SDK de su elección.
+ **Control de acceso de IAM**
Mediante el uso de políticas (IAM) de AWS Identity and Access Management, puede controlar qué miembros de su organización pueden crear, actualizar, implementar o eliminar paquetes o versiones de paquete. Por ejemplo, es posible que desee dar permisos de administrador para implementar paquetes, pero no para cambiar paquetes o crear nuevas versiones de paquete.
+ **Compatibilidad con la capacidad de registro y la auditoría**
Puede auditar y registrar las acciones de usuarios de Distributor en su Cuenta de AWS a través de la integración con otros Servicios de AWS. Para obtener más información, consulte [Auditoría y registro de la actividad de Distributor](distributor-logging-auditing.md).
## ¿Qué es un paquete en Distributor?
Un *paquete* es una colección de recursos de software instalable o activos que incluye lo siguiente.
+ Un archivo .zip de software por plataforma de sistema operativo de destino. Cada archivo .zip debe incluir lo siguiente.
+ Un script de **install** y un script de **uninstall**. Los nodos administrados basados en Windows Server requieren scripts de PowerShell (scripts denominados `install.ps1` y `uninstall.ps1`). Los nodos administrados basados en Linux requieren scripts de shell (scripts denominados `install.sh` y `uninstall.sh`). AWS Systems Manager SSM Agent lee y lleva a cabo las instrucciones de los scripts **install** y **uninstall**.
+ Un archivo ejecutable. SSM Agent debe encontrar este archivo para instalar el paquete en los nodos administrados de destino.
+ Un archivo de manifiesto con formato JSON que describe el contenido del paquete. El manifiesto no se incluye en el archivo .zip, pero se almacena en el mismo bucket de Amazon Simple Storage Service (Amazon S3) que los archivos .zip que conforman el paquete. El manifiesto identifica la versión del paquete y asigna los archivos .zip en el paquete a atributos del nodo administrado de destino, como, por ejemplo, la versión del sistema operativo o la arquitectura. Para obtener más información sobre cómo crear el manifiesto, consulte [Paso 2: crear el manifiesto del paquete JSON](distributor-working-with-packages-create.md#packages-manifest).
Cuando elija Creación del paquete**simple** en la Distributor consola, Distributor genera la instalación y los scripts de desinstalación, resúmenes de archivo y el paquete JSON manifiesto para usted, en función del nombre de archivo del software ejecutable y las plataformas y arquitecturas de destino.
### Plataformas de paquetes y arquitecturas admitidas
Puede utilizar Distributor para publicar paquetes en las siguientes plataformas de nodos administrados de Systems Manager. Un valor de versión debe coincidir con la versión de lanzamiento exacta del sistema operativo Amazon Machine Image (AMI) de destino. Para obtener más información sobre cómo determinar esta versión, consulte el paso 4 de [Paso 2: crear el manifiesto del paquete JSON](distributor-working-with-packages-create.md#packages-manifest).
**nota**
Systems Manager no admite todos los siguientes sistemas operativos para dispositivos de núcleo de AWS IoT Greengrass. Para obtener más información, consulte [Configuración de dispositivos de núcleo de AWS IoT Greengrass](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html) en la *Guía para desarrolladores de AWS IoT Greengrass Version 2*.
| Plataforma | Valor de código en el archivo de manifiesto | Arquitectura compatible |
| --- | --- | --- |
| AlmaLinux | almalinux | x86\$164 ARM64 |
| Amazon Linux 2 y Amazon Linux 2023 | `amazon` | x86\$164 o x86 ARM64 (Amazon Linux 2 y AL2023, tipos de instancia de A1) |
| Debian Server | `debian` | x86\$164 o x86 |
| openSUSE | `opensuse` | x86\$164 |
| openSUSE Leap | `opensuseleap` | x86\$164 |
| Oracle Linux | `oracle` | x86\$164 |
| Red Hat Enterprise Linux (RHEL) | `redhat` | x86\$164 ARM64 (RHEL 7.6 y posteriores, tipos de instancias A1) |
| Rocky Linux | rocky | x86\$164 ARM64 |
| SUSE Linux Enterprise Server (SLES) | `suse` | x86\$164 |
| Ubuntu Server | `ubuntu` | x86\$164 o x86 ARM64 (Ubuntu Server 16 y posteriores, tipos de instancias A1) |
| Windows Server | `windows` | x86\$164 |
**Topics**
+ [¿Cómo puede Distributor beneficiar a mi organización?](#distributor-benefits)
+ [¿Quién debe utilizar Distributor?](#distributor-who)
+ [¿Cuáles son las características de Distributor?](#distributor-features)
+ [¿Qué es un paquete en Distributor?](#what-is-a-package)
+ [Cómo configurar Distributor](distributor-getting-started.md)
+ [Trabajo con paquetes Distributor](distributor-working-with.md)
+ [Auditoría y registro de la actividad de Distributor](distributor-logging-auditing.md)
+ [AWS Systems ManagerSolución de problemasDistributor](distributor-troubleshooting.md)
# Cómo configurar Distributor
Antes de utilizar Distributor, una herramienta de AWS Systems Manager, para crear, administrar e implementar paquetes de software, siga los pasos que se indican a continuación.
## Cómo completar los requisitos previos de Distributor
Antes de utilizar Distributor, una herramienta de AWS Systems Manager, asegúrese de que el entorno cumpla los siguientes requisitos.
**DistributorRequisitos previos de**
| Requisito | Descripción |
| --- | --- |
| SSM Agent | La versión 2.3.274.0 o posterior de AWS Systems Manager SSM Agent debe estar instalada en los nodos administrados en los que desea implementar o desde los que desea eliminar paquetes. Para instalar o actualizar SSM Agent, consulte [Uso de SSM Agent](ssm-agent.md). |
| AWS CLI | (Opcional) Para utilizar AWS Command Line Interface (AWS CLI) en lugar de la consola de Systems Manager para crear y administrar los paquetes, instale la versión más reciente de AWS CLI en el equipo local. Para obtener más información acerca de cómo instalar o actualizar la CLI, consulte [Instalación de la AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) en la *Guía del usuario de AWS Command Line Interface*. |
| Herramientas de AWS para PowerShell | (Opcional) Para utilizar Tools for PowerShell en lugar de la consola de Systems Manager para crear y administrar los paquetes, instale la versión más reciente de Tools for PowerShell en el equipo local. Para obtener más información acerca de cómo se instala o actualiza Tools for PowerShell, consulte [Instalación de AWS Tools for Windows PowerShell o AWS Tools for PowerShell Core](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html) en la *Guía del usuario de Herramientas de AWS para PowerShell*. |
**nota**
Systems Manager no admite la distribución de paquetes a nodos administrados de Oracle Linux mediante el uso de Distributor.
## Cómo verificar o crear un perfil de instancias de IAM con permisos de Distributor
De forma predeterminada, AWS Systems Manager no tiene permiso para realizar acciones en sus instancias. Para conceder acceso debe utilizar un perfil de instancias de IAM AWS Identity and Access Management. Un perfil de instancias es un contenedor que pasa información del rol de IAM a una instancia de Amazon Elastic Compute Cloud (Amazon EC2) al momento del lanzamiento. Este requisito se aplica a los permisos para todas las herramientas de Systems Manager, no solo a Distributor.
**nota**
Al configurar los dispositivos de borde para ejecutar el software AWS IoT Greengrass Core y SSM Agent, especifique un rol de servicio de IAM que permite a Systems Manager realizar acciones en él. No es necesario configurar dispositivos de borde administrados con un perfil de instancia.
Si ya utiliza otras herramientas de Systems Manager, como Run Command y State Manager, ya se ha adjuntado a las instancias un perfil de instancias con los permisos necesarios para Distributor. La forma más sencilla de garantizar que tiene permisos para realizar tareas de Distributor es asociar la política **AmazonSSMManagedInstanceCore** a su perfil de instancia. Para obtener más información, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md).
## Cómo controlar el acceso de los usuarios a los paquetes
Cuando utiliza las políticas (IAM) de AWS Identity and Access Management, puede controlar quién puede crear, implementar y administrar paquetes. También puede controlar qué operaciones de la API Run Command y State Manager pueden realizar en los nodos administrados. Igual que Distributor, Run Command y State Manager son herramientas de AWS Systems Manager.
**Formato de ARN**
Los paquetes definidos por el usuario se asocian con los Nombre de recurso de Amazon (ARN) de documento y tienen el siguiente formato.
```
arn:aws:ssm:region:account-id:document/document-name
```
A continuación se muestra un ejemplo.
```
arn:aws:ssm:us-west-1:123456789012:document/ExampleDocumentName
```
Puede utilizar un par de políticas de IAM predeterminadas proporcionadas por AWS (una para los usuarios finales y otra para los administradores) con el fin de conceder permisos para actividades de Distributor. También puede crear sus propias políticas personalizadas de IAM adecuadas para sus requisitos de permisos.
Para obtener más información acerca del uso de variables en políticas de IAM, consulte [Elementos de la política de IAM: variables](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)
Para obtener información acerca de cómo crear políticas y adjuntarlas a usuarios o grupos, consulte [Creación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) y [Adición y eliminación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) en la *Guía del usuario de IAM*.
## Cómo crear o elegir un bucket de Amazon S3 para almacenar paquetes de Distributor
Cuando crea un paquete con el flujo de trabajo **Simple** en la consola de AWS Systems Manager, elija un bucket de Amazon Simple Storage Service (Amazon S3) existente en el cual Distributor cargue su software. Distributor es una herramienta de AWS Systems Manager. En el flujo de trabajo **Avanzado**, debe cargar archivos .zip de su software o recursos en un bucket de Amazon S3 antes de comenzar. Si crea un paquete utilizando los flujos de trabajo **simple** o **avanzado** en la consola, o mediante la API, debe tener un bucket de Amazon S3 antes de comenzar a crear el paquete. Como parte del proceso de creación de paquetes, Distributor copia el software y los recursos instalables de este bucket a un almacén interno de Systems Manager. Dado que los activos se copian en un almacén interno, puede eliminar o reasignar el bucket de Amazon S3 cuando la creación del paquete ha finalizado.
Para obtener más información acerca de la creación de un bucket, consulte [Creación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) en la *Guía de introducción a Amazon Simple Storage Service*. Para obtener más información acerca de cómo ejecutar un comando de AWS CLI para crear un bucket, consulte [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html) en la *Referencia de los comandos de la AWS CLI*.
# Trabajo con paquetes Distributor
Puede utilizar la consola de AWS Systems Manager, las herramientas de línea de comandos de AWS (AWS CLI y Herramientas de AWS para PowerShell) y los AWS SDK para agregar, administrar o implementar paquetes en Distributor. Distributor es una herramienta de AWS Systems Manager. Antes de agregar un paquete a Distributor:
+ Cree y comprima los recursos instalables.
+ (Opcional) Cree un archivo de manifiesto de JSON para el paquete. Esto no es necesario para utilizar el proceso de creación de paquetes **Simple** en la consola de Distributor. La creación del paquete simple genera un archivo de manifiesto JSON para usted.
Puede utilizar la consola de AWS Systems Manager o un editor de texto o JSON para crear el archivo de manifiesto.
+ Tenga preparado un bucket de Amazon Simple Storage Service (Amazon S3) para almacenar los recursos o el software instalables. Si está utilizando el proceso de creación de paquetes **Avanzado**, cargue sus recursos al bucket de Amazon S3 antes de comenzar.
**nota**
Puede eliminar o reasignar este bucket después de finalizar la creación de su paquete, ya que Distributor mueve el contenido del paquete a un bucket de Systems Manager interno como parte del proceso de creación de paquetes.
Los paquetes publicados por AWS ya están empaquetados y preparados para implementarse. Para implementar un paquete publicado por AWS en nodos administrados, consulte [Instalar o actualizar paquetes de Distributor](distributor-working-with-packages-deploy.md).
Puede compartir paquetes de Distributor entre Cuentas de AWS. Cuando utilice un paquete compartido desde otra cuenta en comandos de AWS CLI, utilice el nombre de recurso de Amazon (ARN) del paquete en lugar del nombre del paquete.
**Topics**
+ [Ver paquetes en Distributor](distributor-view-packages.md)
+ [Cómo crear un paquete en Distributor](distributor-working-with-packages-create.md)
+ [Editar permisos del paquete Distributor en la consola](distributor-working-with-packages-ep.md)
+ [Editar etiquetas del paquete Distributor en la consola](distributor-working-with-packages-tags.md)
+ [Agregar una versión al paquete de Distributor](distributor-working-with-packages-version.md)
+ [Instalar o actualizar paquetes de Distributor](distributor-working-with-packages-deploy.md)
+ [Desinstalación de un paquete Distributor](distributor-working-with-packages-uninstall.md)
+ [Eliminar un paquete de Distributor](distributor-working-with-packages-dpkg.md)
# Ver paquetes en Distributor
Para ver los paquetes disponibles para su instalación, puede utilizar la consola de AWS Systems Manager o la herramienta de línea de comandos de AWS que prefiera. Distributor es una herramienta de AWS Systems Manager. Para acceder a Distributor, abra la consola de AWS Systems Manager y elija **Distributor** en el panel de navegación izquierdo. Verá todos los paquetes disponibles para usted.
En la siguiente sección se describe cómo ver los paquetes de Distributor mediante la herramienta de línea de comandos que prefiera.
## Ver los paquetes mediante la línea de comandos
Esta sección contiene información acerca de cómo utilizar la herramienta de línea de comandos que prefiera para ver los paquetes de Distributor con los comandos proporcionados.
------
#### [ Linux & macOS ]
**Para ver los paquetes con la AWS CLI en Linux**
+ Para ver todos los paquetes, excepto los compartidos, ejecute el siguiente comando.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package
```
+ Para ver todos los paquetes de propiedad de Amazon, ejecute el siguiente comando.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ Para ver todos los paquetes de propiedad de terceros, ejecute el siguiente comando.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ Windows ]
**Para ver los paquetes con la AWS CLI en Windows**
+ Para ver todos los paquetes, excepto los compartidos, ejecute el siguiente comando.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package
```
+ Para ver todos los paquetes de propiedad de Amazon, ejecute el siguiente comando.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ Para ver todos los paquetes de propiedad de terceros, ejecute el siguiente comando.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ PowerShell ]
**Para ver paquetes con Tools for PowerShell**
+ Para ver todos los paquetes, excepto los compartidos, ejecute el siguiente comando.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "DocumentType"
$filter.Values = "Package"
Get-SSMDocumentList `
-Filters @($filter)
```
+ Para ver todos los paquetes de propiedad de Amazon, ejecute el siguiente comando.
```
$typeFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$typeFilter.Key = "DocumentType"
$typeFilter.Values = "Package"
$ownerFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$ownerFilter.Key = "Owner"
$ownerFilter.Values = "Amazon"
Get-SSMDocumentList `
-Filters @($typeFilter,$ownerFilter)
```
+ Para ver todos los paquetes de propiedad de terceros, ejecute el siguiente comando.
```
$typeFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$typeFilter.Key = "DocumentType"
$typeFilter.Values = "Package"
$ownerFilter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$ownerFilter.Key = "Owner"
$ownerFilter.Values = "ThirdParty"
Get-SSMDocumentList `
-Filters @($typeFilter,$ownerFilter)
```
------
# Cómo crear un paquete en Distributor
Para crear un paquete, prepare su software o activos instalables, un archivo por plataforma de sistema operativo. Se requiere al menos un archivo para crear un paquete.
A veces distintas plataformas pueden utilizar el mismo archivo, pero todos los archivos que asocie a su paquete deben incluirse en la sección `Files` del manifiesto. Si está creando un paquete utilizando el flujo de trabajo simple en la consola, el manifiesto se genera para usted. El número máximo de archivos que se pueden asociar a un único documento es 20. El tamaño máximo de cada archivo es de 1 GB. Para obtener más información acerca de las plataformas admitidas, consulte [Plataformas de paquetes y arquitecturas admitidas](distributor.md#what-is-a-package-platforms).
Al crear un paquete, el sistema crea un nuevo [documento de SSM](documents.md). Este documento le permite implementar el paquete en nodos administrados.
Solo para fines de demostración, hay un paquete de ejemplo, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), que puede descargar desde nuestro sitio web. El paquete de ejemplo incluye un manifiesto JSON previamente completado y tres archivos.zip que contienen instaladores para PowerShell v7.0.0. Los scripts de instalación y desinstalación no contienen comandos válidos. Aunque debe comprimir cada software instalable y scripts en un archivo .zip para crear un paquete en el flujo de trabajo **Avanzado**, no debe comprimir los recursos instalables en el flujo de trabajo **Simple**.
**Topics**
+ [Cómo crear un paquete mediante el flujo de trabajo simple](#distributor-working-with-packages-create-simple)
+ [Cómo crear un paquete mediante el flujo de trabajo avanzado](#distributor-working-with-packages-create-adv)
## Cómo crear un paquete mediante el flujo de trabajo simple
Esta sección describe cómo crear un paquete en Distributor mediante la elección del flujo de trabajo de creación de paquete **Simple** en la consola de Distributor. Distributor es una herramienta de AWS Systems Manager. Para crear un paquete, prepare los archivos de los recursos instalables, un archivo por plataforma de sistema operativo. Se requiere al menos un archivo para crear un paquete. El proceso de creación de paquetes **simple** genera scripts de instalación y desinstalación, resúmenes de archivos y un manifiesto con formato JSON para usted. El flujo de trabajo **Simple** gestiona el proceso de cargar y comprimir sus archivos instalables, así como el proceso de crear un nuevo paquete y un [documento SSM](documents.md) asociado. Para obtener más información acerca de las plataformas admitidas, consulte [Plataformas de paquetes y arquitecturas admitidas](distributor.md#what-is-a-package-platforms).
Cuando se utiliza el método simple para crear un paquete, Distributor crea scripts `install` y `uninstall` en su nombre. Sin embargo, al crear un paquete para una actualización in-situ, debe proporcionar su propio contenido de script de `update` en la pestaña **Update script (Script de actualización)**. Cuando agrega comandos de entrada para un script de `update`, Distributor incluye este script en el paquete .zip que crea para usted, junto con los scripts `install` y `uninstall`.
**nota**
Utilice la opción de actualización `In-place` para agregar archivos nuevos o actualizados a una instalación de paquete existente sin desconectar la aplicación asociada.
**Cómo crear un paquete mediante el flujo de trabajo simple**
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 **Distributor**.
1. En la página de Distributor inicio, elija **Crear paquete y**, a continuación, haga clic en **Simple**.
1. En la página **Añadir paquete**, escriba un nombre para su paquete. Los nombres de paquete solo pueden incluir letras, números, puntos, guiones y guiones bajos. El nombre debe ser lo suficientemente genérico como para aplicarse a todas las versiones de los archivos adjuntos del paquete, pero lo suficientemente concreto como para identificar la finalidad del paquete.
1. (Opcional) En **Version Name (Nombre de la versión)**, escriba un nombre de versión. Los nombres de las versiones pueden tener un máximo de 512 caracteres y no pueden contener caracteres especiales.
1. En **Location (Ubicación)**, seleccione un bucket mediante el nombre y el prefijo del bucket o mediante la dirección URL del bucket.
1. En **Cargar software**, elija **Agregar software**, y luego busque los archivos de software instalables con las extensiones `.rpm`, `.msi` o `.deb`. Si el nombre del archivo contiene espacios, se produce un error en la carga. Puede cargar más de un archivo de software en una única acción.
1. Para la **plataforma de destino**, verifique que la plataforma del sistema operativo de destino que se muestra para cada archivo instalable sea correcta. Si el sistema operativo que se muestra no es correcto, seleccione el sistema operativo correcto en la lista desplegable.
En el flujo de trabajo de creación de paquetes **simple**, debido a que carga cada archivo instalable solo una vez, se requieren pasos adicionales para dar una orden Distributor a un único archivo en múltiples sistemas operativos. Por ejemplo, si carga un archivo de software instalable denominado `Logtool_v1.1.1.rpm`, debe cambiar algunos valores predeterminados en el flujo de trabajo **Simple** para dirigir al mismo software en las versiones compatibles de los sistemas operativos Amazon Linux y Ubuntu Server. Al apuntar a varias plataformas, realice una de las siguientes acciones.
+ Utilice el flujo de trabajo **avanzado** en su lugar, comprima cada archivo instalable en un archivo .zip antes de comenzar y cree manualmente el manifiesto para que un archivo instalable pueda ser dirigido a múltiples plataformas o versiones de sistemas operativos. Para obtener más información, consulte [Cómo crear un paquete mediante el flujo de trabajo avanzado](#distributor-working-with-packages-create-adv).
+ Edite manualmente el archivo de manifiesto en el flujo de trabajo **simple** para que su archivo .zip esté dirigido a múltiples plataformas o versiones del sistema operativo. Para obtener más información acerca de cómo hacerlo, consulte el final del paso 4 en [Paso 2: crear el manifiesto del paquete JSON](#packages-manifest).
1. En **Platform version** (Versión de la plataforma), verifique que la versión de la plataforma del sistema operativo que se muestra sea **\$1any**, una versión de lanzamiento principal seguida de una comodín (7.\$1) o la versión exacta de lanzamiento del sistema operativo a la que desea que se aplique su software. Para obtener más información sobre cómo especificar una versión de plataforma del sistema operativo, consulte el paso 4 en [Paso 2: crear el manifiesto del paquete JSON](#packages-manifest).
1. En **Architecture** (Arquitectura), elija la arquitectura de procesador correcta para cada archivo instalable de la lista desplegable. Para obtener más información acerca de las arquitecturas de procesadores compatibles, consulte [Plataformas de paquetes y arquitecturas admitidas](distributor.md#what-is-a-package-platforms).
1. (Opcional) Expanda los **scripts** y revise los scripts que Distributor genera para su software instalable.
1. (Opcional) Para proporcionar un script de actualización para su uso con actualizaciones in situ, expanda **Scripts**, elija la pestaña **Update script (Script de actualización)** e introduzca los comandos de script de actualización.
Systems Manager no genera scripts de actualización en su nombre.
1. Para añadir más archivos de software instalable, seleccione **Añadir software**. De no ser así, vaya al siguiente paso.
1. (Opcional) Expanda el **manifiesto**, y revise el manifiesto del paquete JSON que Distributor genera para su software instalable. Si cambió alguna información sobre su software desde que comenzó este procedimiento, como la versión de plataforma o la plataforma de destino, elija **Generar manifiesto** para mostrar el manifiesto actualizado del paquete.
Puede editar el manifiesto manualmente si desea dirigir un software instalable en más de un sistema operativo, como se describe en el paso 8. Para obtener más información sobre cómo editar el manifiesto, consulte [Paso 2: crear el manifiesto del paquete JSON](#packages-manifest).
1. Elija **Create package (Crear paquete)**.
Espere que Distributor termine de cargar su software y crear el paquete. Distributor muestra el estado de carga para cada archivo instalable. En función del número y el tamaño de los paquetes que se agregan, esto puede tardar unos minutos. Distributor automáticamente le redirige a la página **Detalles del paquete** para el nuevo paquete, pero puede elegir abrir esta página usted mismo después de que el software se haya cargado. La página **Detalles del paquete** no muestra toda la información sobre el paquete hasta que Distributor termine el proceso de creación de paquete. Para detener el proceso de carga y creación del paquete, seleccione **Cancelar**.
Si Distributor no puede cargar cualquiera de los archivos de instalación de software, muestra un mensaje de **Upload failed** (Carga fallida). Para volver a intentar la carga, elija **Reintentar carga**. Para obtener más información acerca de cómo solucionar errores en la creación de paquetes, consulte [AWS Systems ManagerSolución de problemasDistributor](distributor-troubleshooting.md).
## Cómo crear un paquete mediante el flujo de trabajo avanzado
En esta sección podrá descubrir cómo los usuarios avanzados pueden crear un paquete en Distributor después de cargar recursos instalables comprimidos con scripts de instalación y desinstalación, así como un archivo de manifiesto JSON, en un bucket de Amazon S3.
Para crear un paquete, prepare los archivos .zip de los recursos instalables, un archivo .zip por plataforma de sistema operativo. Se requiere al menos un archivo .zip para crear un paquete. A continuación, cree un manifiesto JSON. El manifiesto incluye indicadores a los archivos de código del paquete. Cuando tenga sus archivos de código necesarios agregados a una carpeta o un directorio y el manifiesto se haya rellenado con los valores correctos, cargue el paquete en un bucket de S3.
Hay disponible un paquete de ejemplo, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), para su descarga desde nuestro sitio web. El paquete de ejemplo incluye un manifiesto JSON completo y tres archivos .zip.
**Topics**
+ [Paso 1: crear los archivos ZIP](#packages-zip)
+ [Paso 2: crear el manifiesto del paquete JSON](#packages-manifest)
+ [Paso 3: cargar el paquete y el manifiesto en un bucket de Amazon S3](#packages-upload-s3)
+ [Paso 4: añadir un paquete a Distributor](#distributor-working-with-packages-add)
### Paso 1: crear los archivos ZIP
La base del paquete es al menos un archivo .zip P de recursos instalables o software. Un paquete incluye un archivo .zip por sistema operativo que desee admitir, a menos que un archivo .zip se pueda instalar en varios sistemas operativos. Por ejemplo, las versiones compatibles de las instancias de Red Hat Enterprise Linux y Amazon Linux normalmente pueden ejecutar los mismos archivos ejecutables .RPM, por lo que debe adjuntar un único archivo .zip en el paquete para admitir ambos sistemas operativos.
**Archivos requeridos**
Se requieren los elementos siguientes en cada archivo .zip:
+ Un script de **install** y un script de **uninstall**. Los nodos administrados basados en Windows Server requieren scripts de PowerShell (scripts denominados `install.ps1` y `uninstall.ps1`). Los nodos administrados basados en Linux requieren scripts de shell (scripts denominados `install.sh` y `uninstall.sh`). SSM Agent ejecuta las instrucciones de los scripts **install** y **uninstall**.
Por ejemplo, los scripts de instalación podrían ejecutar un instalador (como .rpm o .msi), podrían copiar archivos o establecer opciones de configuración.
+ Un archivo ejecutable, paquetes de instalador (.rpm, .deb, .msi, etc.) y otros scripts o archivos de configuración.
**Archivos opcionales**
El siguiente elemento es opcional en cada archivo .zip:
+ Un script **update**. Proporcionar un script de actualización le permite utilizar la opción `In-place update` para instalar un paquete. Si desea agregar archivos nuevos o actualizados a una instalación de paquete existente, la opción `In-place update` no desconecta la aplicación de paquete mientras se realiza la actualización. Los nodos administrados basados en Windows Server requieren un script de PowerShell (script denominado `update.ps1`). Los nodos administrados basados en Linux requieren un script de shell (script denominado `update.sh`). SSM Agent ejecuta las instrucciones del script **update**.
Para obtener más información acerca de la instalación o actualización de paquetes, consulte [Instalar o actualizar paquetes de Distributor](distributor-working-with-packages-deploy.md).
Para ver ejemplos de archivos .zip, incluidos los scripts de muestra **install** y **uninstall**, descargue el paquete de ejemplo, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip).
### Paso 2: crear el manifiesto del paquete JSON
Después de preparar y comprimir sus archivos instalables, cree un manifiesto JSON. Lo siguiente es una plantilla. Las partes de la plantilla de manifiesto se describen en el procedimiento que se describe en esta sección. Puede utilizar un editor de JSON para crear este manifiesto en un archivo independiente. Si lo prefiere, puede crear el manifiesto en la consola de AWS Systems Manager cuando cree un paquete.
```
{
"schemaVersion": "2.0",
"version": "your-version",
"publisher": "optional-publisher-name",
"packages": {
"platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-1.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-2.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-3.zip"
}
}
}
},
"files": {
".zip-file-name-1.zip": {
"checksums": {
"sha256": "checksum"
}
},
".zip-file-name-2.zip": {
"checksums": {
"sha256": "checksum"
}
}
}
}
```
**Cómo crear un manifiesto del paquete JSON**
1. Añada la versión de esquema al manifiesto. En esta versión, la versión de esquema es siempre `2.0`.
```
{ "schemaVersion": "2.0",
```
1. Añada una versión del paquete definido por el usuario al manifiesto. También es el valor de **Version name (Nombre de versión)** que ha especificado al agregar el paquete a Distributor. Pasa a formar parte del documento de AWS Systems Manager que crea Distributor al agregar el paquete. También proporciona este valor como una entrada en el documento `AWS-ConfigureAWSPackage` para instalar una versión del paquete que no sea la última. Un valor `version` puede contener letras, números, guiones bajos, guiones y puntos, y tener un máximo de 128 caracteres de longitud. Le recomendamos que utilice una versión del paquete en lenguaje natural para facilitarle a usted y a los demás administradores la especificación de las versiones de paquete exactas durante la implementación. A continuación se muestra un ejemplo.
```
"version": "1.0.1",
```
1. (Opcional). Añada un nombre de editor. A continuación se muestra un ejemplo.
```
"publisher": "MyOrganization",
```
1. Añada paquetes. En la sección `"packages"` se describen las plataformas, las versiones de lanzamiento y las arquitecturas compatibles con los archivos .zip en el paquete. Para obtener más información, consulte [Plataformas de paquetes y arquitecturas admitidas](distributor.md#what-is-a-package-platforms).
El valor *platform-version* puede ser el valor de comodín `_any`. Utilícelo para indicar que un archivo .zip admite cualquier versión de la plataforma. También puede especificar una versión de lanzamiento principal seguida de un comodín para que se admitan todas las versiones secundarias, como la 7.\$1. Si elige especificar un valor de *platform-version* para una versión específica del sistema operativo, asegúrese de que coincida con la versión de lanzamiento exacta del sistema operativo AMI de destino. A continuación, se muestran los recursos sugeridos para obtener el valor correcto del sistema operativo.
+ En nodos administrados basados en Windows Server, la versión de lanzamiento está disponible como datos de Windows Management Instrumentation (WMI). Puede ejecutar el siguiente comando del símbolo del sistema para obtener información de la versión y, a continuación, analizar los resultados de `version`.
```
wmic OS get /format:list
```
+ En un nodo administrado basado en Linux, obtenga la versión escaneando en primer lugar la versión del sistema operativo (el siguiente comando). Busque el valor de `VERSION_ID`.
```
cat /etc/os-release
```
Si esto no da los resultados que necesita, ejecute el siguiente comando para obtener información de la versión LSB del archivo `/etc/lsb-release` y busque el valor de `DISTRIB_RELEASE`.
```
lsb_release -a
```
Si estos métodos fallan, normalmente puede encontrar la versión según la distribución. Por ejemplo, en Debian Server, puede examinar el archivo `/etc/debian_version` o, en Red Hat Enterprise Linux, el archivo `/etc/redhat-release`.
```
hostnamectl
```
```
"packages": {
"platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-1.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-2.zip"
}
}
},
"another-platform": {
"platform-version": {
"architecture": {
"file": ".zip-file-name-3.zip"
}
}
}
}
```
A continuación se muestra un ejemplo. En este ejemplo, la plataforma del sistema operativo es `amazon`, la versión de lanzamiento compatible es `2016.09`, la arquitectura es `x86_64` y el archivo .zip que es compatible con esta plataforma es `test.zip`.
```
{
"amazon": {
"2016.09": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
Puede añadir el valor de comodín `_any` para indicar que el paquete es compatible con todas las versiones del elemento principal. Por ejemplo, para indicar que el paquete es compatible con cualquier versión de lanzamiento de Amazon Linux, la instrucción del paquete será parecida a la que se muestra a continuación. Puede utilizar el comodín `_any` en los niveles de arquitectura o versión para admitir todas las versiones de una plataforma o todas las arquitecturas de una versión, o todas las versiones y todas las arquitecturas de una plataforma.
```
{
"amazon": {
"_any": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
En el siguiente ejemplo se agrega `_any` para mostrar que el primer paquete, `data1.zip`, es compatible con todas las arquitecturas de Amazon Linux 2016.09. El segundo paquete, `data2.zip`, es compatible con todas las versiones de Amazon Linux, pero solo para los nodos administrados con la arquitectura `x86_64`. Las versiones `2023.8` y `_any` son entradas bajo `amazon`. Hay una plataforma (Amazon Linux), pero diferentes versiones, arquitecturas y archivos .zip asociados admitidos.
```
{
"amazon": {
"2023.8": {
"_any": {
"file": "data1.zip"
}
},
"_any": {
"x86_64": {
"file": "data2.zip"
}
}
}
}
```
Puede hacer referencia a un archivo .zip más de una vez en la sección `"packages"` del manifiesto, si el archivo .zip es compatible con más de una plataforma. Por ejemplo, si tiene un archivo .zip que admite versiones Red Hat Enterprise Linux 8.x y Amazon Linux, tendría dos entradas en la sección `"packages"` apuntando al mismo archivo .zip, como se muestra en el siguiente ejemplo.
```
{
"amazon": {
"2023.8.20250715 ": {
"x86_64": {
"file": "test.zip"
}
}
},
"redhat": {
"8.*": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
1. Añada la lista de archivos .zip que forman parte de este paquete en el paso 4. Cada entrada de archivo requiere el nombre de archivo y el valor hash de la suma de comprobación `sha256`. Los valores de suma de comprobación en el manifiesto deben coincidir con el valor hash `sha256` en los recursos comprimidos para evitar que se produzca un error en la instalación de paquetes.
Para obtener la suma de comprobación exacta de su instalables, puede ejecutar los siguientes comandos. En Linux, ejecute `shasum -a 256 file-name.zip` o `openssl dgst -sha256 file-name.zip`. En Windows, ejecute el cmdlet `Get-FileHash -Path path-to-.zip-file` en [PowerShell](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-6).
La sección `"files"` del manifiesto incluye una referencia a cada uno de los archivos .zip del paquete.
```
"files": {
"test-agent-x86.deb.zip": {
"checksums": {
"sha256": "EXAMPLE2706223c7616ca9fb28863a233b38e5a23a8c326bb4ae241dcEXAMPLE"
}
},
"test-agent-x86_64.deb.zip": {
"checksums": {
"sha256": "EXAMPLE572a745844618c491045f25ee6aae8a66307ea9bff0e9d1052EXAMPLE"
}
},
"test-agent-x86_64.nano.zip": {
"checksums": {
"sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
}
},
"test-agent-rhel8-x86.nano.zip": {
"checksums": {
"sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
}
},
"test-agent-x86.msi.zip": {
"checksums": {
"sha256": "EXAMPLE12a4abb10315aa6b8a7384cc9b5ca8ad8e9ced8ef1bf0e5478EXAMPLE"
}
},
"test-agent-x86_64.msi.zip": {
"checksums": {
"sha256": "EXAMPLE63ccb86e830b63dfef46995af6b32b3c52ce72241b5e80c995EXAMPLE"
}
},
"test-agent-rhel8-x86.rpm.zip": {
"checksums": {
"sha256": "EXAMPLE13df60aa3219bf117638167e5bae0a55467e947a363fff0a51EXAMPLE"
}
}
}
```
1. Una vez que haya añadido la información del paquete, guarde y cierre el archivo de manifiesto.
A continuación se muestra un ejemplo de un manifiesto completado. En este ejemplo, tiene un archivo .zip, `NewPackage_LINUX.zip`, que admite más de una plataforma, pero al que se hace referencia en la sección `"files"` solo una vez.
```
{
"schemaVersion": "2.0",
"version": "1.7.1",
"publisher": "Amazon Web Services",
"packages": {
"windows": {
"_any": {
"x86_64": {
"file": "NewPackage_WINDOWS.zip"
}
}
},
"amazon": {
"_any": {
"x86_64": {
"file": "NewPackage_LINUX.zip"
}
}
},
"ubuntu": {
"_any": {
"x86_64": {
"file": "NewPackage_LINUX.zip"
}
}
}
},
"files": {
"NewPackage_WINDOWS.zip": {
"checksums": {
"sha256": "EXAMPLEc2c706013cf8c68163459678f7f6daa9489cd3f91d52799331EXAMPLE"
}
},
"NewPackage_LINUX.zip": {
"checksums": {
"sha256": "EXAMPLE2b8b9ed71e86f39f5946e837df0d38aacdd38955b4b18ffa6fEXAMPLE"
}
}
}
}
```
#### Ejemplo de paquete
Hay disponible un paquete de ejemplo, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), para su descarga desde nuestro sitio web. El paquete de ejemplo incluye un manifiesto JSON completo y tres archivos .zip.
### Paso 3: cargar el paquete y el manifiesto en un bucket de Amazon S3
Prepare el paquete; para ello, copie o transfiera todos los archivos .zip a una carpeta o un directorio. Un paquete válido requiere el manifiesto que creó en [Paso 2: crear el manifiesto del paquete JSON](#packages-manifest) y todos los archivos .zip identificados en la lista del archivo de manifiesto.
**Cómo cargar el paquete y el manifiesto en Amazon S3**
1. Copie o mueva todos los archivos de almacenamiento .zip que ha especificado en el manifiesto a una carpeta o un directorio. No comprima la carpeta ni el directorio al que mueve los archivos del archivo.zip y el archivo de manifiesto.
1. Cree un bucket o elija uno existente. Para obtener más información, consulte [Creación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) en la *Guía de introducción a Amazon Simple Storage Service*. Para obtener más información acerca de cómo ejecutar un comando de AWS CLI para crear un bucket, consulte [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html) en la *Referencia de los comandos de la AWS CLI*.
1. Cargar la carpeta o el directorio en el bucket. Para obtener más información, consulte [Cargar un objeto en un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PuttingAnObjectInABucket.html) en la *Guía de introducción a Amazon Simple Storage Service*. Si planea pegar el manifiesto JSON en la consola AWS Systems Manager, no cargue el manifiesto. Para obtener más información acerca de cómo ejecutar un comando de AWS CLI para cargar los archivos en un bucket, consulte [https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html) en la *Referencia de los comandos de la AWS CLI*.
1. En la página de inicio del bucket, elija la carpeta o el directorio que se ha cargado. Si cargó sus archivos a una subcarpeta en un bucket, asegúrese de anotar la subcarpeta (también conocido como un *prefijo*). Necesita el prefijo para agregar el paquete a Distributor.
### Paso 4: añadir un paquete a Distributor
Puede utilizar la consola de AWS Systems Manager, las herramientas de línea de comandos de AWS (AWS CLI y Herramientas de AWS para PowerShell) o los AWS SDK para agregar un nuevo paquete a Distributor. Cuando agrega un paquete, se agrega un nuevo [documento de SSM](documents.md). El documento le permite implementar el paquete en nodos administrados.
**Topics**
+ [Cómo agregar un destino mediante la consola](#create-pkg-console)
+ [Cómo agregar un paquete mediante la AWS CLI](#create-pkg-cli)
#### Cómo agregar un destino mediante la consola
Puede utilizar la consola de AWS Systems Manager para crear un paquete. Tenga listo el nombre del bucket al que se ha cargado el paquete en [Paso 3: cargar el paquete y el manifiesto en un bucket de Amazon S3](#packages-upload-s3).
**Cómo añadir un paquete a Distributor (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 **Distributor**.
1. En la página de Distributor inicio, elija **Crear paquete y**, a continuación, haga clic en **Avanzado**.
1. En la página **Añadir paquete**, escriba un nombre para su paquete. Los nombres de paquete solo pueden incluir letras, números, puntos, guiones y guiones bajos. El nombre debe ser lo suficientemente genérico como para aplicarse a todas las versiones de los archivos adjuntos del paquete, pero lo suficientemente concreto como para identificar la finalidad del paquete.
1. En **Version name (Nombre de versión)**, escriba el valor exacto de la entrada `version` en su archivo de manifiesto.
1. En **S3 bucket name (Nombre del bucket de S3)**, seleccione el nombre del bucket al que se ha cargado sus archivos .zip y manifiesto en [Paso 3: cargar el paquete y el manifiesto en un bucket de Amazon S3](#packages-upload-s3).
1. En **S3 key prefix (Prefijo de clave de S3)**, escriba la subcarpeta del bucket en el que están almacenados el manifiesto y sus archivos .zip.
1. En **Manifest** (Manifiesto), elija **Extract from package** (Extraer del paquete) para utilizar un manifiesto que ha cargado al bucket de Amazon S3 con sus archivos .zip.
(Opcional) Si no subió su manifiesto JSON al bucket de Amazon S3 donde almacenó sus archivos .zip, elija **New manifest** (Nuevo manifiesto). Puede crear o pegar todo el manifiesto en el campo de edición de JSON. Para obtener más información sobre cómo crear el manifiesto JSON, consulte [Paso 2: crear el manifiesto del paquete JSON](#packages-manifest).
1. Cuando haya terminado con el manifiesto, elija **Crear paquete**.
1. Espere a que Distributor cree el paquete desde su archivos .zip y manifiesto. En función del número y el tamaño de los paquetes que se añaden, esto puede tardar unos minutos. Distributor automáticamente le redirige a la página de**detalles del paquete** pero puede elegir abrir esta página por usted mismo después de que el software se haya cargado. La página **Detalles del paquete** no muestra toda la información sobre el paquete hasta que Distributor termine el proceso de creación de paquete. Para detener el proceso de carga y creación del paquete, seleccione **Cancelar**.
#### Cómo agregar un paquete mediante la AWS CLI
Puede utilizar la AWS CLI para crear un paquete. Tenga la URL lista desde el bucket en el que haya cargado el paquete en [Paso 3: cargar el paquete y el manifiesto en un bucket de Amazon S3](#packages-upload-s3).
**Cómo agregar un paquete a Amazon S3 mediante la AWS CLI**
1. Para usar la AWS CLI para crear un paquete, ejecute el siguiente comando, reemplazando *package-name* por el nombre del paquete y *path to manifest-file* por la ruta del archivo de manifiesto JSON. amzn-s3-demo-bucket es la URL del bucket Amazon S3 donde está almacenado todo el paquete. Al ejecutar el comando **create-document** en Distributor, debe especificar el valor `Package` para `--document-type`.
Si no agregó el archivo de manifiesto al bucket de Amazon S3, el valor del parámetro `--content` es la ruta del archivo al archivo de manifiesto JSON.
```
aws ssm create-document \
--name "package-name" \
--content file://path-to-manifest-file \
--attachments Key="SourceUrl",Values="amzn-s3-demo-bucket" \
--version-name version-value-from-manifest \
--document-type Package
```
A continuación se muestra un ejemplo.
```
aws ssm create-document \
--name "ExamplePackage" \
--content file://path-to-manifest-file \
--attachments Key="SourceUrl",Values="https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage" \
--version-name 1.0.1 \
--document-type Package
```
1. Compruebe que el paquete se añadió y que muestra el manifiesto de paquete mediante la ejecución del siguiente comando, sustituyendo *package-name* por el nombre de su paquete. Para obtener una versión específica del documento (no la misma que la versión de un paquete), puede agregar el parámetro `--document-version`.
```
aws ssm get-document \
--name "package-name"
```
Para obtener más información acerca de otras opciones que puede utilizar con el comando **create-document**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html) en la sección sobre AWS Systems Manager de la *Referencia de comandos de la AWS CLI*. Para obtener más información sobre otras opciones que puede usar con el comando **get-document**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html).
# Editar permisos del paquete Distributor en la consola
Una vez que haya agregado un paquete a Distributor, una herramienta de AWS Systems Manager, puede editar los permisos del paquete en la consola de Systems Manager. Puede agregar otras Cuentas de AWS a unos permisos de paquete. Los paquetes solo se pueden compartir con otras cuentas en la misma Región de AWS. No se admite el uso compartido entre regiones. De forma predeterminada, los paquetes se establecen en **Private** (Privado), lo que significa que solo quienes tienen acceso a la Cuenta de AWS del creador del paquete pueden ver la información del paquete y actualizar o eliminar el paquete. Si los permisos de **Private (Privado)** son aceptables, puede omitir este procedimiento.
**nota**
Puede actualizar los permisos de los paquetes que se comparten con 20 cuentas o menos.
**Para editar permisos del paquete mediante la 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 **Distributor**.
1. En la página **Packages (Paquetes)**, elija el paquete del que desea editar los permisos.
1. En la pestaña **Packages details (Detalles del paquete)**, elija **Edit permisos (Editar permisos)** para cambiar los permisos.
1. En **Edit permissions (Editar permisos)**, elija **Shared with specific accounts (Compartido con cuentas específicas)**.
1. En **Shared with specific accounts** (Compartido con cuentas específicas), agregue números de Cuenta de AWS, uno a la vez. Cuando haya terminado, elija **Save**.
# Editar etiquetas del paquete Distributor en la consola
Una vez que haya agregado un paquete a Distributor, una herramienta de AWS Systems Manager, puede editar las etiquetas del paquete en la consola de Systems Manager. Estas etiquetas se aplican al paquete y no están conectadas a etiquetas en los nodos administrados en los que desea implementar el paquete. Las etiquetas son pares de claves y valores que distinguen entre mayúsculas y minúsculas y que permiten agrupar y filtrar los paquetes por criterios que son pertinentes para la organización. Si no desea agregar etiquetas, está listo para instalar el paquete o agregar una nueva versión.
**Para editar etiquetas del paquete en la 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 **Distributor**.
1. En la página **Packages (Paquetes)**, elija el paquete del que desea editar las etiquetas.
1. En la pestaña **Package details (Detalles del paquete)**, en **Tags (Etiquetas)**, elija **Edit (Editar)**.
1. En **Add tags** (Agregar etiquetas), ingrese una clave de etiqueta o un par de clave de etiqueta y valor, y luego elija **Add** (Agregar). Repita si desea añadir varias etiquetas. Para eliminar etiquetas, elija **X** en la etiqueta de la parte inferior de la ventana.
1. Cuando haya terminado de agregar etiquetas a su paquete, elija **Save** (Guardar).
# Agregar una versión al paquete de Distributor
Para agregar una versión del paquete, [cree un paquete](distributor-working-with-packages-create.md) y, a continuación, utilice Distributor para agregar una versión del paquete mediante la incorporación de una entrada en el documento de AWS Systems Manager (SSM) que ya existe para las versiones anteriores. Distributor es una herramientas de AWS Systems Manager. Para ahorrar tiempo, actualice el manifiesto de una versión anterior del paquete, cambie el valor de la entrada `version` en el manifiesto (por ejemplo, de `Test_1.0` a `Test_2.0`) y guárdelo como el manifiesto de la nueva versión. El flujo de trabajo simple **Añadir versión** en la Distributor consola actualiza el archivo de manifiesto por usted.
Una nueva versión del paquete puede:
+ Sustituya al menos uno de los archivos instalables asociados a la versión actual.
+ Añada nuevos archivos instalables para admitir plataformas adicionales.
+ Elimine archivos para cesar la compatibilidad con plataformas específicas.
Una versión más reciente puede utilizar el mismo bucket de Amazon Simple Storage Service (Amazon S3), pero debe tener una URL con otro nombre de archivo mostrado al final. Puede utilizar la consola de Systems Manager o la AWS Command Line Interface (AWS CLI) para agregar la nueva versión. Cargar un archivo instalable con el nombre exacto de un archivo instalable existente en el bucket de Amazon S3 sobrescribe el archivo existente. No se copian archivos instalables de la versión anterior a la nueva versión; debe cargar archivos instalables de la versión anterior para que formen parte de una nueva versión. Una vez que Distributor haya terminado de crear su nueva versión del paquete, puede eliminar o reutilizar el bucket de Amazon S3, ya que Distributor copia su software en un bucket de Systems Manager interno como parte del proceso de control de versiones.
**nota**
Cada paquete está limitado a un máximo de 25 versiones. Puede eliminar las versiones que ya no sean necesarias.
**Topics**
+ [Añadir una versión del paquete mediante la consola](#add-pkg-version)
+ [Añadir una versión del paquete mediante la AWS CLI](#add-pkg-version-cli)
## Añadir una versión del paquete mediante la consola
Antes de realizar estos pasos, siga las instrucciones de [Cómo crear un paquete en Distributor](distributor-working-with-packages-create.md) para crear un nuevo paquete de la versión. A continuación, utilice la consola de Systems Manager para agregar una nueva versión del paquete a Distributor.
### Añadir una versión de paquete mediante el flujo de trabajo simple
Para añadir una versión del paquete mediante el flujo de trabajo **Simple**, prepare archivos instalables actualizados o añade archivos instalables para admitir más plataformas y arquitecturas. A continuación, utiliceDistributor para cargar archivos instalables nuevos y actualizados y añada una versión del paquete. El flujo de trabajo simplificado **Añadir versión** en la Distributor consola actualiza el archivo de manifiesto y documento de SSM asociados por usted.
**Para añadir una versión de paquete mediante el flujo de trabajo simple**
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 **Distributor**.
1. En la página de inicio de Distributor, elija el paquete en el que desee añadir otra versión.
1. En la página **Añadir versión**, seleccione **simple**.
1. En **Version Name (Nombre de la versión)**, escriba un nombre de versión. El nombre de la versión para la nueva versión debe ser diferente de los nombres de versiones anteriores. Los nombres de las versiones pueden tener un máximo de 512 caracteres y no pueden contener caracteres especiales.
1. Para **nombre de bucket de S3**, elija un bucket de S3 existente de la lista. Este puede ser el mismo bucket que utilizó para almacenar archivos instalables para versiones anteriores, pero los nombres de los archivos instalables deben ser diferentes para evitar sobrescribir los archivos instalables existentes en el bucket.
1. En **S3 key prefix (Prefijo de clave de S3)**, escriba la subcarpeta del bucket donde se almacenan sus recursos instalables.
1. En **Upload software** (Cargar software), diríjase a los archivos de software instalable que desea adjuntar a la nueva versión. Los archivos instalables de versiones existentes no se copian automáticamente a una nueva versión; debe cargar cualquier archivo instalable de versiones anteriores del paquete si desea que alguno de los mismos archivos instalables forme parte de la nueva versión. Puede cargar más de un archivo de software en una única acción.
1. Para la **plataforma de destino**, verifique que la plataforma del sistema operativo de destino que se muestra para cada archivo instalable sea correcta. Si el sistema operativo que se muestra no es correcto, seleccione el sistema operativo correcto en la lista desplegable.
En el flujo de trabajo **simple**, ya que carga cada archivo una sola vez, se requieren pasos adicionales para dirigirse a un único archivo en varios sistemas operativos. Por ejemplo, si carga un archivo de software instalable denominado `Logtool_v1.1.1.rpm`, debe cambiar algunos valores predeterminados en el flujo de trabajo **Simple** para indicarle a Distributor que se dirija al mismo software en los sistemas operativos Amazon Linux y Ubuntu Server. Puede elegir una de las opciones siguientes para evitar esta limitación.
+ Utilice el flujo de trabajo **avanzado** en su lugar, comprima cada archivo instalable en un archivo .zip antes de comenzar, y cree manualmente el manifiesto para que un archivo instalable pueda ser dirigido a varias plataformas o versiones del sistema operativo. Para obtener más información, consulte [Añadir una versión de paquete mediante el flujo de trabajo avanzado](#add-pkg-version-adv).
+ Edite manualmente el archivo de manifiesto en el flujo de trabajo **simple** para que su archivo .zip esté dirigido a múltiples plataformas o versiones del sistema operativo. Para obtener más información acerca de cómo hacerlo, consulte el final del paso 4 en [Paso 2: crear el manifiesto del paquete JSON](distributor-working-with-packages-create.md#packages-manifest).
1. En **Versión de la plataforma**, verifique que la versión de la plataforma del sistema operativo que se muestra sea **\$1any**, una versión de lanzamiento principal seguida de una comodín (8.\$1) o la versión exacta de lanzamiento del sistema operativo a la que desea que se aplique su software. Para obtener más información sobre cómo especificar una versión de la plataforma, consulte el paso 4 en [Paso 2: crear el manifiesto del paquete JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Para **Arquitectura**, elija la arquitectura de procesador correcta para cada archivo instalable de la lista desplegable. Para obtener más información acerca de las arquitecturas compatibles, consulte [Plataformas de paquetes y arquitecturas admitidas](distributor.md#what-is-a-package-platforms).
1. (Opcional) Expanda los **scripts** y revise los scripts de instalación y desinstalación que Distributor genera para su software instalable.
1. Para añadir más archivos de software instalable a la nueva versión, seleccione **Añadir software**. De no ser así, vaya al siguiente paso.
1. (Opcional) Expanda el **manifiesto**, y revise el manifiesto del paquete JSON que Distributor genera para su software instalable. Si cambió cualquier información sobre su software instalable desde que comenzó este procedimiento, como la versión de plataforma o la plataforma de destino, elija **Generar manifiesto** para mostrar el manifiesto actualizado del paquete.
Puede editar el manifiesto manualmente si desea dirigirlo a un software instalable en más de un sistema operativo, como se describe en el paso 9. Para obtener más información sobre cómo editar el manifiesto, consulte [Paso 2: crear el manifiesto del paquete JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Cuando haya terminado de añadir software y revisar la plataforma de destino, la versión y los datos de arquitectura, seleccione **Añadir versión**.
1. Espere Distributor para terminar la carga de su software y crear la nueva versión del paquete. Distributor muestra el estado de carga para cada archivo instalable. En función del número y el tamaño de los paquetes que se agreguen, esto puede tardar unos minutos. Distributor automáticamente le redirige a la página de **detalles del paquete**,pero puede elegir abrir esta página por sí mismo después de que el software se hayan cargado. La página **Detalles del paquete** no muestra toda la información sobre el paquete hasta que Distributor termina de crear la nueva versión del paquete. Para detener la versión del paquete de carga y creación, elija **Detener carga**.
1. Si Distributor no puede cargar cualquiera de los archivos de instalación de software, muestra un mensaje de **Upload failed** (Carga fallida). Para volver a intentar la carga, elija **Reintentar carga**. Para obtener más información sobre cómo solucionar errores de creación de versión del paquete, consulte [AWS Systems ManagerSolución de problemasDistributor](distributor-troubleshooting.md).
1. Cuando Distributor haya terminado de crear la nueva versión del paquete, en la página de **Detalles del paquete**, en la pestaña **Versiones**, vea la nueva versión en la lista de versiones de paquete disponibles. Establezca una versión predeterminada del paquete; para ello, elija una versión y, a continuación, elija **Set default version (Establecer versión predeterminada)**.
Si no establece una versión predeterminada, la versión del paquete más reciente es la versión predeterminada.
### Añadir una versión de paquete mediante el flujo de trabajo avanzado
Para añadir una versión del paquete, [cree un paquete](distributor-working-with-packages-create.md), y después use Distributor para añadir una versión del paquete incorporando una entrada en el documento SSM que ya existe para las versiones anteriores. Para ahorrar tiempo, actualice el manifiesto de una versión anterior del paquete, cambie el valor de la entrada `version` en el manifiesto (por ejemplo, de `Test_1.0` a `Test_2.0`) y guárdelo como el manifiesto de la nueva versión. Debe tener un manifiesto actualizada para añadir una nueva versión del paquete utilizando el flujo de trabajo **avanzado**.
**Para añadir una versión de paquete mediante el flujo de trabajo avanzado**
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 **Distributor**.
1. En la página de Distributor inicio, elija el paquete a la que desea añadir otra versión y, a continuación, elija **Añadir versión**.
1. En **Version name (Nombre de versión)**, escriba el valor exacto que se encuentra en la entrada `version` en su archivo de manifiesto.
1. Para **nombre de bucket de S3**, elija un bucket de S3 existente de la lista. Este puede ser el mismo bucket que utilizó para almacenar archivos instalables para versiones anteriores, pero los nombres de los archivos instalables deben ser diferentes para evitar sobrescribir los archivos instalables existentes en el bucket.
1. En **S3 key prefix (Prefijo de clave de S3)**, escriba la subcarpeta del bucket donde se almacenan sus recursos instalables.
1. En **Manifest (Manifiesto)**, elija **Extract from package (Extraer del paquete)** para utilizar un manifiesto que cargó al bucket de S3 con sus archivos .zip.
(Opcional) Si no cargó el manifiesto JSON revisado al bucket de Amazon S3 donde guardó los archivos .zip, elija **New manifest** (Nuevo manifiesto). Puede crear o pegar todo el manifiesto en el campo de edición de JSON. Para obtener más información sobre cómo crear el manifiesto JSON, consulte [Paso 2: crear el manifiesto del paquete JSON](distributor-working-with-packages-create.md#packages-manifest).
1. Cuando haya terminado con el manifiesto, seleccione **Agregar versión del paquete**.
1. En la página **Details (Detalles)** del paquete, en la pestaña **Versions (Versiones)**, vea la nueva versión en la lista de versiones de paquete disponibles. Establezca una versión predeterminada del paquete; para ello, elija una versión y, a continuación, elija **Set default version (Establecer versión predeterminada)**.
Si no establece una versión predeterminada, la versión del paquete más reciente es la versión predeterminada.
## Añadir una versión del paquete mediante la AWS CLI
Puede utilizar la AWS CLI para añadir una nueva versión del paquete a Distributor. Antes de ejecutar estos comandos, debe crear una nueva versión del paquete y cargarlo en S3, tal y como se describe al principio de este tema.
**Para añadir una versión de paquete mediante la AWS CLI**
1. Ejecute el siguiente comando para editar el documento de AWS Systems Manager con una entrada para una nueva versión del paquete. Sustituya *document-name* por el nombre de su documento. Sustituya *amzn-s3-demo-bucket* con la URL del manifiesto JSON que copió en [Paso 3: cargar el paquete y el manifiesto en un bucket de Amazon S3](distributor-working-with-packages-create.md#packages-upload-s3). *S3-bucket-URL-of-package* es la URL del bucket de Amazon S3 donde se almacena el paquete completo. Sustituya *version-name-from-updated-manifest* por el valor de `version` en el manifiesto. Establezca el parámetro `--document-version` en `$LATEST` para que el documento asociado a esta versión del paquete sea la versión más reciente del documento.
```
aws ssm update-document \
--name "document-name" \
--content "S3-bucket-URL-to-manifest-file" \
--attachments Key="SourceUrl",Values="amzn-s3-demo-bucket" \
--version-name version-name-from-updated-manifest \
--document-version $LATEST
```
A continuación se muestra un ejemplo.
```
aws ssm update-document \
--name ExamplePackage \
--content "https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage/manifest.json" \
--attachments Key="SourceUrl",Values="https://s3.amazonaws.com/amzn-s3-demo-bucket/ExamplePackage" \
--version-name 1.1.1 \
--document-version $LATEST
```
1. Ejecute el siguiente comando para verificar que el paquete se ha actualizado y muestra el manifiesto de paquete. Sustituya *package-name* por el nombre de su paquete y, si lo desea, *document-version* por el número de versión del documento (no coincide con la versión del paquete) que actualizó. Si esta versión del paquete está asociada a la versión más reciente del documento, puede especificar `$LATEST` para el valor del parámetro `--document-version` opcional.
```
aws ssm get-document \
--name "package-name" \
--document-version "document-version"
```
Para obtener más información acerca de otras opciones que puede utilizar con el comando **update-document**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html) en la sección sobre AWS Systems Manager de la *Referencia de comandos de la AWS CLI*.
# Instalar o actualizar paquetes de Distributor
Puede implementar paquetes en los nodos administrados de AWS Systems Manager mediante Distributor, una herramienta de AWS Systems Manager. Para implementar los paquetes, utilice la Consola de administración de AWS o AWS Command Line Interface (AWS CLI). Puede implementar una versión de un paquete en cada comando. Puede instalar nuevos paquetes o actualizar las instalaciones existentes. Puede elegir implementar una versión específica o elegir implementar siempre la versión más reciente de un paquete para implementación. Le recomendamos utilizar State Manager, una herramienta de AWS Systems Manager, para instalar paquetes. Utilice State Manager para asegurarse de que los nodos administrados siempre ejecutan la versión más actualizada del paquete.
**importante**
Los paquetes que instale mediante Distribuidor se deben desinstalar únicamente mediante Distribuidor. De lo contrario, Systems Manager podría seguir registrando la aplicación como `INSTALLED` y provocar otros resultados imprevistos.
| Preference | AWS Systems ManagerAcción de | Más información |
| --- | --- | --- |
| Instale o actualice un paquete inmediatamente. | Run Command | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| Instale o actualice un paquete de manera programada, de forma que la instalación siempre incluya la versión predeterminada. | State Manager | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| Instale un paquete automáticamente en nodos administrados nuevos que tengan una etiqueta específica o un conjunto de etiquetas. Por ejemplo, instale el agente de Amazon CloudWatch en nuevas instancias. | State Manager | Una forma de hacerlo es aplicar etiquetas a nodos administrados nuevos y, a continuación, especificar las etiquetas como destinos en su asociación State Manager. State Manager instala automáticamente el paquete de una asociación en los nodos administrados que tienen etiquetas coincidentes. 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). |
**Topics**
+ [Instalación o actualización de un paquete una vez mediante la consola](#distributor-deploy-pkg-console)
+ [Programación de una instalación o actualización de un paquete mediante la consola](#distributor-deploy-sm-pkg-console)
+ [Instalación de un paquete una vez mediante la AWS CLI](#distributor-deploy-pkg-cli)
+ [Actualización de un paquete una vez mediante la AWS CLI](#distributor-update-pkg-cli)
+ [Programación de la instalación de un paquete mediante la AWS CLI](#distributor-smdeploy-pkg-cli)
+ [Programación de una actualización de paquete mediante la AWS CLI](#distributor-smupdate-pkg-cli)
## Instalación o actualización de un paquete una vez mediante la consola
Puede utilizar la consola AWS Systems Manager para instalar o actualizar un paquete una vez. Al configurar una instalación única, Distributor utiliza [AWS Systems Manager Run Command](run-command.md), una herramienta de AWS Systems Manager, para llevar a cabo la instalación.
**Para instalar o actualizar un paquete una vez mediante la 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 **Distributor**.
1. En la página de inicio de Distributor, elija el paquete que desee instalar.
1. Elija **Instalar una vez**.
Este comando abre Run Command con el documento de Command `AWS-ConfigureAWSPackage` y el paquete de Distributor ya seleccionado.
1. En **Versión del documento**, seleccione la versión del documento `AWS-ConfigureAWSPackage` que desea ejecutar.
1. En **Acción**, elija **Instalar**.
1. En **Installation type**, seleccione una de las siguientes opciones:
+ **Desinstalar y reinstalar**: el paquete se desinstala por completo y, a continuación, se vuelve a instalar. La aplicación no estará disponible hasta que se complete la reinstalación.
+ **In-place update**: solo se agregan archivos nuevos o modificados a la instalación existente según las instrucciones que proporcione en un script `update`. La aplicación permanece disponible durante todo el proceso de actualización. Esta opción no es compatible con los paquetes publicados de AWS, excepto el paquete de `AWSEC2Launch-Agent`.
1. En **Nombre**, compruebe que se ha introducido el nombre del paquete que ha seleccionado.
1. (Opcional) En **Versión**, escriba el valor de nombre de versión del paquete. Si deja este campo en blanco, Run Command instala la versión predeterminada que ha seleccionado en Distributor.
1. En la sección **Destinos**, para elegir los nodos administrados en los que desea ejecutar esta operación, especifique las etiquetas, seleccione las instancias o los dispositivos manualmente o especifique un grupo de recursos.
**nota**
Si no ve un nodo administrado en la lista, consulte [Solución de problemas de disponibilidad de nodos administrados](fleet-manager-troubleshooting-managed-nodes.md).
1. En **Otros parámetros**:
+ En **Comentario**, ingrese la información acerca de este comando.
+ En **Tiempo de espera (segundos)**, especifique el número de segundos que tiene que esperar el sistema antes de indicar que se ha producido un error en la ejecución del comando general.
1. En **Control de velocidad**:
+ En **Simultaneidad**, especifique un número o un porcentaje de los destinos en los que desea ejecutar el comando al mismo tiempo.
**nota**
Si seleccionó los destinos mediante la especificación de etiquetas o grupos de recursos y no está seguro de cuántos nodos administrados tienen destino, limite el número de destinos que puede ejecutar el documento al mismo tiempo. Para ello, especifique un porcentaje.
+ En **Umbral de error**, especifique cuándo desea parar la ejecución del comando en los demás destinos después de que haya fallado en un número o un porcentaje de los nodos administrados. Por ejemplo, si especifica tres errores, Systems Manager dejará de enviar el comando cuando se reciba el cuarto error. Los nodos administrados que estén procesando el comando todavía pueden enviar errores.
1. (Opcional) En **Opciones de salida**, para guardar la salida del comando en un archivo, seleccione el cuadro **Write command output to an S3 bucket**. 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 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 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, 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. En la sección **Notificaciones de SNS**, seleccione la casilla de verificación **Habilitar notificaciones de SNS** si desea recibir notificaciones sobre el estado de ejecución de los comandos.
Para obtener más información acerca de la configuración de las notificaciones de Amazon SNS para Run Command, consulte [Cómo monitorear los cambios de estado de Systems Manager mediante las notificaciones de Amazon SNS](monitoring-sns-notifications.md).
1. Cuando esté listo para instalar el paquete, elija **Ejecutar**.
1. El área **Estado del comando** informa del progreso de la ejecución. Si el comando sigue en curso, elija el icono de actualización en la esquina superior izquierda de la consola hasta que la columna **Estado General** o **Estado detallado** muestre **Correcto** o **Error**.
1. En el área **Destinos y salidas**, elija el botón situado junto a un nombre de nodo administrado y, a continuación, elija **Ver resultado**.
La página de salida de comandos muestra los resultados de la ejecución de comandos.
1. (Opcional) Si elige escribir la salida del comando en un bucket de Amazon S3, elija **Amazon S3** para ver los datos del registro de salida.
## Programación de una instalación o actualización de un paquete mediante la consola
Puede utilizar la consola de AWS Systems Manager para programar la instalación o actualización de un paquete. Al planificar la instalación o actualización de un paquete, Distributor usa [AWS Systems Manager State Manager](systems-manager-state.md) para instalar o actualizar.
**Para programar una instalación de paquete mediante la 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 **Distributor**.
1. En la página de inicio de Distributor, elija el paquete que desee instalar o actualizar.
1. En **Paquete**, elija **Instalar de manera programada**.
Este comando abre State Manager en una nueva asociación que se crea automáticamente.
1. En **Nombre**, escriba un nombre (por ejemplo, **Deploy-test-agent-package**). Esto es opcional, pero recomendable. No se permiten espacios en el nombre.
1. En la lista **Documento**, el nombre del documento `AWS-ConfigureAWSPackage` ya está seleccionado.
1. En **Acción**, compruebe que se ha seleccionado **Instalar**.
1. En **Installation type**, seleccione una de las siguientes opciones:
+ **Desinstalar y reinstalar**: el paquete se desinstala por completo y, a continuación, se vuelve a instalar. La aplicación no estará disponible hasta que se complete la reinstalación.
+ **In-place update**: solo se agregan archivos nuevos o modificados a la instalación existente según las instrucciones que proporcione en un script `update`. La aplicación permanece disponible durante todo el proceso de actualización.
1. En **Nombre**, compruebe que se ha introducido el nombre del paquete.
1. En **Versión**, si desea instalar una versión del paquete que no sea la versión más reciente publicada, introduzca el identificador de versión.
1. En **Destinos**, elija **Selecting all managed instances in this account**, **Especificación de etiquetas** o **Selección manual de la instancia**. Si selecciona como destino recursos mediante el uso de etiquetas, introduzca una clave de etiqueta y un valor de etiqueta en los campos correspondientes.
**nota**
Para elegir dispositivos de núcleo administrados de AWS IoT Greengrass, elija **Selecting all managed instances in this account** o **Selección manual de la instancia**.
1. En **Especificar programación**, seleccione **Según la programación** para ejecutar la asociación según un programa habitual o **Sin programación** para ejecutar la asociación una vez. Para obtener más información sobre estas opciones, consulte [Trabajo con asociaciones en Systems Manager](state-manager-associations.md). Utilice los controles para crear un programa de `cron` o rate para la asociación.
1. Elija **Crear asociación**.
1. En la página **Asociación** pulse el botón situado junto a la asociación que ha creado y, a continuación, elija **Aplicar asociación ahora**.
State Manager crea y ejecuta inmediatamente la asociación en los destinos especificados. Para obtener más información acerca de los resultados de las asociaciones en ejecución, consulte [Trabajo con asociaciones en Systems Manager](state-manager-associations.md) en esta guía.
Para obtener más información sobre cómo trabajar con las opciones en **Opciones avanzadas**, **Control de velocidad** y **Opciones de salida**, consulte [Trabajo con asociaciones en Systems Manager](state-manager-associations.md).
## Instalación de un paquete una vez mediante la AWS CLI
Puede ejecutar **send-command** en la AWS CLI para instalar un paquete de Distributor una vez. Si el paquete ya está instalado, la aplicación se desconectará mientras se desinstala el paquete y se instala la nueva versión en su lugar.
**Para instalar un paquete una vez mediante la AWS CLI**
+ Ejecute el siguiente comando en la : AWS CLI.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
**nota**
El comportamiento predeterminado para `installationType` es `Uninstall and reinstall`. Puede omitir `"installationType":["Uninstall and reinstall"]` de este comando cuando instale un paquete completo.
A continuación se muestra un ejemplo.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-00000000000000" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["ExamplePackage"]}'
```
Para obtener más información acerca de otras opciones que puede utilizar con el comando **send-command**, 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 sección sobre AWS Systems Manager de la *Referencia de comandos de la AWS CLI*.
## Actualización de un paquete una vez mediante la AWS CLI
Puede ejecutar **send-command** en la AWS CLI para actualizar un paquete de Distributor sin desconectar la aplicación asociada. Solo se reemplazan los archivos nuevos o actualizados del paquete.
**Para actualizar un paquete una vez mediante la AWS CLI**
+ Ejecute el siguiente comando en la : AWS CLI.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
**nota**
Cuando agregue archivos nuevos o modificados, debe incluir `"installationType":["In-place update"]` en el comando.
A continuación se muestra un ejemplo.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["ExamplePackage"]}'
```
Para obtener más información acerca de otras opciones que puede utilizar con el comando **send-command**, 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 sección sobre AWS Systems Manager de la *Referencia de comandos de la AWS CLI*.
## Programación de la instalación de un paquete mediante la AWS CLI
Puede ejecutar **create-association** en la AWS CLI para instalar un paquete de Distributor de forma programada. El valor de `--name`, el nombre del documento, es siempre `AWS-ConfigureAWSPackage`. El comando siguiente utiliza la clave `InstanceIds` para especificar los nodos administrados de destino. Si el paquete ya está instalado, la aplicación se desconectará mientras se desinstala el paquete y se instala la nueva versión en su lugar.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"instance-ID1\",\"instance-ID2\"]}]
```
**nota**
El comportamiento predeterminado para `installationType` es `Uninstall and reinstall`. Puede omitir `"installationType":["Uninstall and reinstall"]` de este comando cuando instale un paquete completo.
A continuación se muestra un ejemplo.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["Test-ConfigureAWSPackage"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"i-02573cafcfEXAMPLE\",\"i-0471e04240EXAMPLE\"]}]
```
Para obtener más información acerca de otras opciones que puede utilizar con el comando **create-association**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) en la sección sobre AWS Systems Manager de la *Referencia de comandos de la AWS CLI*.
## Programación de una actualización de paquete mediante la AWS CLI
Puede ejecutar **create-association** en la AWS CLI para actualizar un paquete de Distributor de forma programada sin desconectar la aplicación asociada. Solo se reemplazan los archivos nuevos o actualizados del paquete. El valor de `--name`, el nombre del documento, es siempre `AWS-ConfigureAWSPackage`. El comando siguiente utiliza la clave `InstanceIds` para especificar las instancias de destino.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"instance-ID1\",\"instance-ID2\"]}]
```
**nota**
Cuando agregue archivos nuevos o modificados, debe incluir `"installationType":["In-place update"]` en el comando.
A continuación se muestra un ejemplo.
```
aws ssm create-association \
--name "AWS-ConfigureAWSPackage" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["Test-ConfigureAWSPackage"]}' \
--targets [{\"Key\":\"InstanceIds\",\"Values\":[\"i-02573cafcfEXAMPLE\",\"i-0471e04240EXAMPLE\"]}]
```
Para obtener más información acerca de otras opciones que puede utilizar con el comando **create-association**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) en la sección sobre AWS Systems Manager de la *Referencia de comandos de la AWS CLI*.
# Desinstalación de un paquete Distributor
Puede utilizar la Consola de administración de AWS o la AWS Command Line Interface (AWS CLI) para desinstalar los paquetes de Distributor de sus nodos administrados de AWS Systems Manager mediante el uso de Run Command. Distributor y Run Command son herramientas de AWS Systems Manager. En esta versión, puede desinstalar una versión de un paquete en cada comando. Puede desinstalar una versión específica o la versión predeterminada.
**importante**
Los paquetes que instale mediante Distribuidor se deben desinstalar únicamente mediante Distribuidor. De lo contrario, Systems Manager podría seguir registrando la aplicación como `INSTALLED` y provocar otros resultados imprevistos.
**Topics**
+ [Desinstalación de un paquete mediante la consola](#distributor-pkg-uninstall-console)
+ [Desinstalación de un paquete mediante la AWS CLI](#distributor-pkg-uninstall-cli)
## Desinstalación de un paquete mediante la consola
Puede utilizar Run Command en la consola de Systems Manager para desinstalar un paquete una vez. Distributor utiliza [AWS Systems Manager Run Command](run-command.md) para desinstalar paquetes.
**Para desinstalar un paquete mediante la 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. En la página de inicio de Run Command, elija **Run command (Ejecutar comando)**..
1. Elija el documento de comando `AWS-ConfigureAWSPackage`.
1. Desde **Action (Acción)**, elija **Uninstall (Desinstalar)**.
1. Para **Name (Nombre)**, escriba el nombre del paquete que desea desinstalar.
1. En **Targets** (Destinos), elija el modo en el que desea dirigirse a los nodos administrados. Puede especificar una clave de etiqueta y valores compartidos por los destinos. Para especificar destinos, también puede elegir atributos, como un ID, una plataforma y la versión de SSM Agent.
1. Puede utilizar las opciones avanzadas para agregar comentarios acerca de la operación, cambiar los valores de **Concurrency** (Simultaneidad) y **Error threshold** (Límite de error) en **Rate control** (Control de velocidad), especificar las opciones de salida o configurar las notificaciones de Amazon Simple Notification Service (Amazon SNS). Para obtener más información, consulte [Ejecución de comandos desde la consola](https://docs.aws.amazon.com/systems-manager/latest/userguide/rc-console.html) en esta guía.
1. Cuando esté listo para desinstalar el paquete, elija **Run** (Ejecutar) y, a continuación, seleccione **View results** (Ver resultados).
1. En la lista de comandos, elija el comando `AWS-ConfigureAWSPackage` que ha ejecutado. Si el comando todavía está en curso, elija el icono de actualización de la esquina superior derecha de la consola.
1. Cuando la columna **Estado** muestre **Correcto** o **Error**, elija la pestaña **Salida**.
1. Elija **View output (Ver salida)**. La página de salida de comandos muestra los resultados de la ejecución de comandos.
## Desinstalación de un paquete mediante la AWS CLI
Puede utilizar la AWS CLI para desinstalar un paquete de Distributor de sus nodos administrados mediante Run Command.
**Para desinstalar un paquete mediante la AWS CLI**
+ Ejecute el siguiente comando en la : AWS CLI.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "instance-IDs" \
--parameters '{"action":["Uninstall"],"name":["package-name (in same account) or package-ARN (shared from different account)"]}'
```
A continuación se muestra un ejemplo.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Uninstall"],"name":["Test-ConfigureAWSPackage"]}'
```
Para obtener más información acerca de otras opciones que puede utilizar con el comando **send-command**, 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 sección sobre AWS Systems Manager de la *Referencia de comandos de la AWS CLI*.
# Eliminar un paquete de Distributor
En esta sección se describe cómo eliminar un paquete. No es posible eliminar la versión de un paquete, solo todo el paquete.
## Eliminar un paquete mediante la consola
Puede utilizar la consola de AWS Systems Manager para eliminar un paquete o una versión del paquete de Distributor, una herramienta de AWS Systems Manager. Si elimina un paquete, eliminará todas las versiones de un paquete de Distributor.
**Para eliminar un paquete mediante la 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 **Distributor**.
1. En la página de inicio de **Distributor**, seleccione el paquete que desee eliminar.
1. En la página de detalles del paquete, elija **Delete package (Eliminar paquete)**.
1. Cuando se le pida que confirme la eliminación, elija **Delete package** (Eliminar paquete).
## Eliminación de una versión del paquete mediante la consola
Puede utilizar la consola de Systems Manager para eliminar una versión del paquete de Distributor.
**Para eliminar una versión de paquete mediante la 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 **Distributor**.
1. En la página de inicio de **Distributor**, elija el paquete cuya versión desee eliminar.
1. En la página de versiones del paquete, elija la versión que desea eliminar y haga clic en **Delete version (Eliminar versión)**.
1. Cuando le pidan que confirme la eliminación, elija **Delete package version** (Eliminar versión del paquete).
## Eliminación de un paquete mediante la línea de comandos
Puede utilizar la herramienta de línea de comandos que prefiera para eliminar un paquete de Distributor.
------
#### [ Linux & macOS ]
**Para eliminar un paquete mediante la AWS CLI**
1. Ejecute el siguiente comando para enumerar los documentos de paquetes específicos. En los resultados de este comando, busque el paquete que desea eliminar.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
1. Ejecute el siguiente comando para eliminar un paquete. Sustituya *package-name* por el nombre del paquete.
```
aws ssm delete-document \
--name "package-name"
```
1. Vuelva a ejecutar el comando **list-documents** para comprobar que el paquete se ha eliminado. El paquete que ha eliminado no debería incluirse en la lista.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
------
#### [ Windows ]
**Para eliminar un paquete mediante la AWS CLI**
1. Ejecute el siguiente comando para enumerar los documentos de paquetes específicos. En los resultados de este comando, busque el paquete que desea eliminar.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
1. Ejecute el siguiente comando para eliminar un paquete. Sustituya *package-name* por el nombre del paquete.
```
aws ssm delete-document ^
--name "package-name"
```
1. Vuelva a ejecutar el comando **list-documents** para comprobar que el paquete se ha eliminado. El paquete que ha eliminado no debería incluirse en la lista.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
------
#### [ PowerShell ]
**Para eliminar un paquete mediante Tools for PowerShell**
1. Ejecute el siguiente comando para enumerar los documentos de paquetes específicos. En los resultados de este comando, busque el paquete que desea eliminar.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
1. Ejecute el siguiente comando para eliminar un paquete. Sustituya *package-name* por el nombre del paquete.
```
Remove-SSMDocument `
-Name "package-name"
```
1. Vuelva a ejecutar el comando **Get-SSMDocumentList** para comprobar que el paquete se ha eliminado. El paquete que ha eliminado no debería incluirse en la lista.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
------
## Eliminación de una versión del paquete mediante la línea de comandos
Puede utilizar la herramienta de línea de comandos que prefiera para eliminar una versión del paquete de Distributor.
------
#### [ Linux & macOS ]
**Para eliminar una versión de paquete mediante la AWS CLI**
1. Ejecute el siguiente comando para mostrar las versiones del paquete. En los resultados, busque la versión del paquete que desea eliminar.
```
aws ssm list-document-versions \
--name "package-name"
```
1. Ejecute el siguiente comando para eliminar una versión del paquete. Reemplace *package-name* por el nombre del paquete y *version* por el número de versión.
```
aws ssm delete-document \
--name "package-name" \
--document-version version
```
1. Ejecute el comando **list-document-versions** para comprobar que la versión del paquete se ha eliminado. La versión del paquete que eliminó ya no debería encontrarse.
```
aws ssm list-document-versions \
--name "package-name"
```
------
#### [ Windows ]
**Para eliminar una versión de paquete mediante la AWS CLI**
1. Ejecute el siguiente comando para mostrar las versiones del paquete. En los resultados, busque la versión del paquete que desea eliminar.
```
aws ssm list-document-versions ^
--name "package-name"
```
1. Ejecute el siguiente comando para eliminar una versión del paquete. Reemplace *package-name* por el nombre del paquete y *version* por el número de versión.
```
aws ssm delete-document ^
--name "package-name" ^
--document-version version
```
1. Ejecute el comando **list-document-versions** para comprobar que la versión del paquete se ha eliminado. La versión del paquete que eliminó ya no debería encontrarse.
```
aws ssm list-document-versions ^
--name "package-name"
```
------
#### [ PowerShell ]
**Para eliminar una versión del paquete mediante Tools for PowerShell**
1. Ejecute el siguiente comando para mostrar las versiones del paquete. En los resultados, busque la versión del paquete que desea eliminar.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
1. Ejecute el siguiente comando para eliminar una versión del paquete. Reemplace *package-name* por el nombre del paquete y *version* por el número de versión.
```
Remove-SSMDocument `
-Name "package-name" `
-DocumentVersion version
```
1. Ejecute el comando **Get-SSMDocumentVersionList** para comprobar que la versión del paquete se ha eliminado. La versión del paquete que eliminó ya no debería encontrarse.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
------
Para obtener más información acerca de otras opciones que puede utilizar con el comando **list-documents**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html) en la sección sobre AWS Systems Manager de la *Referencia de comandos de la AWS CLI*. Para obtener más información sobre otras opciones que puede usar con el comando **delete-document**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html).
# Auditoría y registro de la actividad de Distributor
Puede utilizar AWS CloudTrail para auditar la actividad relacionada con Distributor, una herramienta de AWS Systems Manager. Para obtener más información acerca de cómo auditar y registrar opciones de Systems Manager, consulte [Registro y monitorización en AWS Systems Manager](monitoring.md).
## Audite la actividad de Distributor mediante el uso de CloudTrail
CloudTrail captura las llamadas a las API realizadas en la consola de AWS Systems Manager, la AWS Command Line Interface (AWS CLI) y el SDK de Systems Manager. La información puede consultarse en la consola de CloudTrail o almacenarse en un bucket de Amazon Simple Storage Service (Amazon S3). Se utiliza un bucket para todos los registros de CloudTrail de su cuenta.
Los registros de acciones de Run Command y State Manager muestran la actividad de creación de documentos, instalación de paquetes y desinstalación de paquetes. Run Command y State Manager son herramientas de AWS Systems Manager. Para obtener más información acerca de cómo ver y utilizar los registros de CloudTrail de la actividad de Systems Manager, consulte [Registro de llamadas a la API de AWS Systems Manager con AWS CloudTrail](monitoring-cloudtrail-logs.md).
# AWS Systems ManagerSolución de problemasDistributor
La siguiente información puede ayudarlo a solucionar problemas que pueden ocurrir cuando utiliza Distributor, una herramienta de AWS Systems Manager.
**Topics**
+ [Instalación de paquete incorrecto con el mismo nombre](#distributor-tshoot-1)
+ [Error: no se pudo recuperar el manifiesto: no se pudo encontrar la versión más reciente del paquete](#distributor-tshoot-2)
+ [Error: no se pudo recuperar el manifiesto: excepción de validación](#distributor-tshoot-3)
+ [El paquete no es compatible (falta la acción de instalación del paquete)](#distributor-tshoot-4)
+ [Error: Error al descargar el manifiesto: el documento con el nombre no existe](#distributor-tshoot-5)
+ [Carga fallida.](#distributor-tshoot-6)
+ [Error: No se pudo encontrar la plataforma: no se encontró ningún manifiesto para la plataforma: Oracle, versión 8.9, arquitectura x86\$164](#distributor-tshoot-7)
## Instalación de paquete incorrecto con el mismo nombre
**Problema:** ha instalado un paquete, pero Distributor ha instalado un paquete diferente en su lugar.
**Causa:** durante la instalación, Systems Manager encuentra paquetes publicados por AWS como resultados antes que los paquetes externos definidos por el usuario. Si el nombre del paquete definido por el usuario es el mismo que un nombre de paquete publicado por AWS, el paquete de AWS se instala en lugar de su paquete.
**Solución:** para evitar este problema, asigne al paquete un nombre algo diferente del nombre de un paquete publicado por AWS.
## Error: no se pudo recuperar el manifiesto: no se pudo encontrar la versión más reciente del paquete
**Problema:** ha recibido un error como el siguiente.
```
Failed to retrieve manifest: ResourceNotFoundException: Could not find the latest version of package
arn:aws:ssm:::package/package-name status code: 400, request id: guid
```
**Causa:** está utilizando una versión de SSM Agent con Distributor anterior a la versión 2.3.274.0.
**Solución:** actualice la versión de SSM Agent a la versión 2.3.274.0 o una versión 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) o [Tutorial: actualización automática de SSM Agent con AWS CLI](state-manager-update-ssm-agent-cli.md).
## Error: no se pudo recuperar el manifiesto: excepción de validación
**Problema:** ha recibido un error como el siguiente.
```
Failed to retrieve manifest: ValidationException: 1 validation error detected: Value 'documentArn'
at 'packageName' failed to satisfy constraint: Member must satisfy regular expression pattern:
arn:aws:ssm:region-id:account-id:package/package-name
```
**Causa:** está utilizando una versión de SSM Agent con Distributor anterior a la versión 2.3.274.0.
**Solución:** actualice la versión de SSM Agent a la versión 2.3.274.0 o una versión 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) o [Tutorial: actualización automática de SSM Agent con AWS CLI](state-manager-update-ssm-agent-cli.md).
## El paquete no es compatible (falta la acción de instalación del paquete)
**Problema:** ha recibido un error como el siguiente.
```
Package is not supported (package is missing install action)
```
**Causa:** la estructura del directorio del paquete es incorrecta.
**Solución:** no comprima un directorio principal que contenga el software y los scripts necesarios. En su lugar, cree un archivo de `.zip` con todos los contenidos requeridos directamente en la ruta absoluta. Para comprobar que el archivo de `.zip` se creó correctamente, descomprima el directorio de la plataforma destino y revise la estructura del directorio. Por ejemplo, la ruta absoluta del script de instalación debe ser `/ExamplePackage_targetPlatform/install.sh`.
## Error: Error al descargar el manifiesto: el documento con el nombre no existe
**Problema**: ha recibido un error como el siguiente.
```
Failed to download manifest - failed to retrieve package document description: InvalidDocument: Document with name filename does not exist.
```
**Causa 1:** Distributor no puede encontrar el paquete por el nombre del paquete al compartir un paquete de Distributor de otra cuenta.
**Solución 1:** cuando comparta un paquete de otra cuenta, utilice el Nombre de recurso de Amazon (ARN) completo del paquete y no solo el nombre.
**Causa 2:** cuando utiliza una VPC, no ha proporcionado el perfil de instancia de IAM con acceso al bucket de S3 administrado de AWS que contiene el documento `AWS-ConfigureAWSPackage` para la Región de AWS de destino.
**Solución 2:** asegúrese de que el perfil de instancia de IAM proporcione a SSM Agent acceso al bucket de S3 administrado de AWS que contiene el documento `AWS-ConfigureAWSPackage` para la Región de AWS de destino, como se explica en [SSM Agent Comunicaciones de AWS con buckets de S3 administrados de](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
## Carga fallida.
**Problema**: ha recibido un error como el siguiente.
```
Upload failed. At least one of your files was not successfully uploaded to your S3 bucket.
```
**Causa:** el nombre del paquete de software incluye un espacio. Por ejemplo, `Hello World.msi` no se podría cargar.
## Error: No se pudo encontrar la plataforma: no se encontró ningún manifiesto para la plataforma: Oracle, versión 8.9, arquitectura x86\$164
**Problema**: ha recibido un error como el siguiente.
```
Failed to find platform: no manifest found for platform: oracle, version 8.9, architecture x86_64
```
**Causa:** el error significa que el manifiesto del paquete JSON no tiene ninguna definición para esa plataforma, en este caso, Oracle Linux.
**Solución:** descargue el paquete que desee distribuir del sitio web de [Deep Security Software de Trend Micro](https://help.deepsecurity.trendmicro.com/software.html). Cree un paquete de software `.rpm` mediante [Cómo crear un paquete mediante el flujo de trabajo simple](distributor-working-with-packages-create.md#distributor-working-with-packages-create-simple). Establezca los siguientes valores para el paquete y complete la carga del paquete de software con Distributor:
```
Platform version: _any
Target platform: oracle
Architecture: x86_64
```
# AWS Systems Manager Fleet Manager
Fleet Manager, una herramienta de AWS Systems Manager, es una experiencia de interfaz de usuario (UI) unificada que lo ayuda a administrar de forma remota los nodos que se ejecutan en AWS o en las instalaciones. Con Fleet Manager, puede ver el estado y el rendimiento de toda la flota de servidores desde una sola consola. También puede recopilar datos de nodos individuales para realizar tareas comunes de solución de problemas y administración desde la consola. Esto incluye la conexión a instancias de Windows mediante el protocolo de escritorio remoto (RDP), la visualización del contenido de carpetas y archivos, la administración del registro de Windows, la administración de usuarios del sistema operativo y más.
Para comenzar a utilizar Fleet Manager, abra la [consola de Systems Manager](https://console.aws.amazon.com/systems-manager/fleet-manager). En el panel de navegación, elija **Fleet Manager**.
## ¿Quién debe utilizar Fleet Manager?
Cualquier cliente de AWS que desee tener una forma centralizada de administrar su flota de nodos debería utilizar Fleet Manager.
## ¿Cómo puede Fleet Manager beneficiar a mi organización?
Fleet Manager ofrece las ventajas siguientes:
+ Realice una variedad de tareas comunes de administración de sistemas sin tener que conectarse de manera manual a los nodos administrados.
+ Administre nodos que se ejecutan en varias plataformas desde una única consola unificada.
+ Administre nodos que ejecutan diferentes sistemas operativos desde una única consola unificada.
+ Mejore la eficiencia de la administración de los sistemas.
## ¿Cuáles son las características de Fleet Manager?
Estas son algunas de las características clave de Fleet Manager:
+ **Acceso al portal de la base de conocimientos de Red Hat**
Acceda a datos binarios, recursos compartidos de conocimientos y foros de discusión en el portal de la base de conocimientos de Red Hat a través de las instancias de Red Hat Enterprise Linux (RHEL).
+ **Estado de nodos administrados**
Vea qué instancias administradas están `running` (ejecutándose) y cuáles están `stopped` (detenidas). Para obtener más información acerca de las instancias detenidas, consulte [Detención e inicio de una instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html) en la *Guía del usuario de Amazon EC2*. Para dispositivos de núcleo de AWS IoT Greengrass, puede ver cuáles están `online`, `offline` o muestran el estado de `Connection lost`.
**nota**
Si detuvo la instancia administrada antes del 12 de julio de 2021, no mostrará el marcador `stopped`. Para mostrar el marcador, inicie y detenga la instancia.
+ **Ver la información de la instancia**
Vea información sobre los datos de carpetas y archivos almacenados en los volúmenes adjuntados en las instancias administradas, los datos de rendimiento sobre las instancias en tiempo real y los datos de registro almacenados en las instancias.
+ **View edge device information** (Ver información de dispositivo de borde)
Vea el nombre del objeto del dispositivo de AWS IoT Greengrass, el estado del ping y la versión de SSM Agent, y mucho más.
+ **Administración de cuentas y registro**
Administre las cuentas de usuario del sistema operativo (SO) en las instancias y el registro en las instancias de Windows.
+ **Controlar el acceso a las características**
Controle el acceso a las características de Fleet Manager mediante políticas de AWS Identity and Access Management (IAM). Con estas políticas, puede controlar qué usuarios o grupos de la organización pueden utilizar varias características de Fleet Manager y qué nodos administrados pueden administrar.
**Topics**
+ [¿Quién debe utilizar Fleet Manager?](#fleet-who)
+ [¿Cómo puede Fleet Manager beneficiar a mi organización?](#fleet-benefits)
+ [¿Cuáles son las características de Fleet Manager?](#fleet-features)
+ [Configuración de Fleet Manager](setting-up-fleet-manager.md)
+ [Trabajo con nodos administrados](fleet-manager-managed-nodes.md)
+ [Administración automática de instancias EC2 con la configuración de administración de hosts predeterminada](fleet-manager-default-host-management-configuration.md)
+ [Conéctese a una instancia administrada de Windows Server mediante Remote Desktop](fleet-manager-remote-desktop-connections.md)
+ [Administración de volúmenes de Amazon EBS en instancias administradas](fleet-manager-manage-amazon-ebs-volumes.md)
+ [Acceso al portal de la base de conocimientos de Red Hat](fleet-manager-red-hat-knowledge-base-access.md)
+ [Solución de problemas de disponibilidad de nodos administrados](fleet-manager-troubleshooting-managed-nodes.md)
# Configuración de Fleet Manager
Antes de que los usuarios de su Cuenta de AWS puedan utilizar Fleet Manager, una herramienta de AWS Systems Manager, para supervisar y administrar los nodos administrados, es preciso que se les concedan los permisos necesarios. Además, para que cualquier instancia de Amazon Elastic Compute Cloud (Amazon EC2); los dispositivos de núcleo de AWS IoT Greengrass; y los servidores en las instalaciones, dispositivos de la periferia y máquinas virtuales (VM) sean monitoreadas y administradas mediante Fleet Manager, deben ser *nodos administrados* de Systems Manager. Un nodo administrado es cualquier máquina configurada para su uso con Systems Manager en entornos [híbridos y multinube](operating-systems-and-machine-types.md#supported-machine-types).
Esto significa que los nodos deben cumplir ciertos requisitos previos y configurarse con el agente de AWS Systems Manager (SSM Agent).
Según el tipo de máquina, consulte uno de los siguientes temas para asegurarse de que sus máquinas cumplen los requisitos de los nodos administrados.
+ Instancias de Amazon EC2: [Administrar instancias de EC2 con Systems Manager](systems-manager-setting-up-ec2.md)
**sugerencia**
También puede utilizar Quick Setup, una herramienta de AWS Systems Manager, para ayudarlo a configurar rápidamente las instancias de Amazon EC2 como instancias administradas en una cuenta individual. Si la empresa u organización utiliza AWS Organizations, también puede configurar instancias en varias unidades organizativas y Regiones de AWS. Para obtener más información acerca del uso de Quick Setup para configurar instancias administradas, consulte [Instalar la administración de host de Amazon EC2 mediante Quick Setup](quick-setup-host-management.md).
+ Servidores en las instalaciones y de otros tipos en la nube: [Administrador de nodos en entornos híbridos y multinube con Systems Manager](systems-manager-hybrid-multicloud.md)
+ Dispositivos AWS IoT Greengrass (de la periferia): [Administración de dispositivos periféricos con Systems Manager](systems-manager-setting-up-edge-devices.md)
**Topics**
+ [Control del acceso a Fleet Manager](configuring-fleet-manager-permissions.md)
# Control del acceso a Fleet Manager
Para utilizar Fleet Manager, una herramienta de AWS Systems Manager, su usuario o rol de AWS Identity and Access Management (IAM) debe tener los permisos necesarios. Puede crear una política de IAM que proporcione acceso a todas las características de Fleet Manager o modificar su política para conceder acceso a las características que elija. A continuación, conceda estos permisos a los usuarios o identidades en su cuenta.
**Tarea 1: crear políticas de IAM para definir los permisos de acceso**
Siga uno de los métodos que se proporcionan en el siguiente tópico de la *Guía del usuario de IAM* para crear un IAM y conceder acceso a Fleet Manager a las identidades (usuarios, roles o grupos de usuarios):
+ [Defina los permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)
Puede utilizar uno de los ejemplos de políticas que se indican a continuación o modificarlas según los permisos que desee conceder. Proporcionamos políticas de ejemplo para el acceso completo a Fleet Manager y el acceso de solo lectura.
**Tarea 2: asociar las políticas de IAM a los usuarios para conceder permisos**
Una vez que haya creado la política o las políticas de IAM que definen los permisos de acceso a Fleet Manager, use uno de los siguientes procedimientos de la *Guía del usuario de IAM* para conceder estos permisos a las identidades de su cuenta:
+ [Adición de permisos de identidad de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)
+ [Adición de permisos de identidad de IAM (AWS CLI)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-cli)
+ [Adición de permisos de identidad de IAM (API de AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-api)
**Topics**
+ [Ejemplo de política para el acceso de administrador de Fleet Manager](#admin-policy-sample)
+ [Ejemplo de política para el acceso de solo lectura de Fleet Manager](#read-only-policy-sample)
## Ejemplo de política para el acceso de administrador de Fleet Manager
La siguiente política proporciona permisos para todas las características de Fleet Manager. Esto significa que un usuario puede crear y eliminar usuarios y grupos locales, modificar la membresía a un grupo para cualquier grupo local y modificar claves o valores del registro Windows Server. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:CreateTags",
"ec2:DeleteTags",
"ec2:DescribeInstances",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Sid": "General",
"Effect": "Allow",
"Action": [
"ssm:AddTagsToResource",
"ssm:DescribeInstanceAssociationsStatus",
"ssm:DescribeInstancePatches",
"ssm:DescribeInstancePatchStates",
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetServiceSetting",
"ssm:GetInventorySchema",
"ssm:ListComplianceItems",
"ssm:ListInventoryEntries",
"ssm:ListTagsForResource",
"ssm:ListCommandInvocations",
"ssm:ListAssociations",
"ssm:RemoveTagsFromResource"
],
"Resource": "*"
},
{
"Sid": "DefaultHostManagement",
"Effect": "Allow",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
},
{
"Sid": "SendCommand",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:SendCommand",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*:111122223333:document/SSM-SessionManagerRunShell",
"arn:aws:ssm:*:*:document/AWS-PasswordReset",
"arn:aws:ssm:*:*:document/AWSFleetManager-AddUsersToGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-CopyFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateDirectory",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateGroup",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateUser",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateUserInteractive",
"arn:aws:ssm:*:*:document/AWSFleetManager-CreateWindowsRegistryKey",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteGroup",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteUser",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteWindowsRegistryKey",
"arn:aws:ssm:*:*:document/AWSFleetManager-DeleteWindowsRegistryValue",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetDiskInformation",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileSystemContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetPerformanceCounters",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetProcessDetails",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetUsers",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsEvents",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsRegistryContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-MountVolume",
"arn:aws:ssm:*:*:document/AWSFleetManager-MoveFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-RemoveUsersFromGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-RenameFileSystemItem",
"arn:aws:ssm:*:*:document/AWSFleetManager-SetWindowsRegistryValue",
"arn:aws:ssm:*:*:document/AWSFleetManager-StartProcess",
"arn:aws:ssm:*:*:document/AWSFleetManager-TerminateProcess"
]
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
}
]
}
```
------
## Ejemplo de política para el acceso de solo lectura de Fleet Manager
La siguiente política proporciona permisos para características de Fleet Manager de solo lectura. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeTags"
],
"Resource": "*"
},
{
"Sid": "General",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceAssociationsStatus",
"ssm:DescribeInstancePatches",
"ssm:DescribeInstancePatchStates",
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetServiceSetting",
"ssm:GetInventorySchema",
"ssm:ListComplianceItems",
"ssm:ListInventoryEntries",
"ssm:ListTagsForResource",
"ssm:ListCommandInvocations",
"ssm:ListAssociations"
],
"Resource": "*"
},
{
"Sid": "SendCommand",
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:SendCommand",
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*:111122223333:document/SSM-SessionManagerRunShell",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetDiskInformation",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetFileSystemContent",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetGroups",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetPerformanceCounters",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetProcessDetails",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetUsers",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsEvents",
"arn:aws:ssm:*:*:document/AWSFleetManager-GetWindowsRegistryContent"
]
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
}
]
}
```
------
# Trabajo con nodos administrados
Un *nodo administrado* es cualquier máquina configurada para AWS Systems Manager. Puede configurar los siguientes tipos de máquinas como nodos administrados:
+ Instancias de Amazon Elastic Compute Cloud (Amazon EC2)
+ Servidores en sus propias instalaciones (servidores en las instalaciones)
+ Dispositivos de núcleo de AWS IoT Greengrass
+ Dispositivos de AWS IoT y periféricos que no sean de AWS
+ Máquinas virtuales (VM), incluidas las VM de otros entornos de nube
En la consola de Systems Manager, toda máquina que tenga el prefijo “mi-” se configuró como un nodo administrado mediante una [*activación híbrida*](activations.md). Los dispositivos de borde muestran el nombre del objeto de AWS IoT.
**nota**
La única característica compatible con las instancias de macOS es la vista del sistema de archivos.
**Acerca de los niveles de instancias de Systems Manager**
AWS Systems Manager ofrece un nivel de instancias estándares y un nivel de instancias avanzadas. Ambos admiten nodos administrados en su entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). El nivel de instancias estándar le permite registrar un máximo de 1000 máquinas por Cuenta de AWS por Región de AWS. Si tiene que registrar más de 1000 máquinas en una única cuenta y región, utilice el nivel de instancias avanzadas. Puede crear tantos nodos administrados como desee en el nivel de instancias avanzadas. Todos los nodos administrados configurados para Systems Manager tienen un precio de pago por uso. Para obtener más información acerca de la habilitación del nivel de instancias avanzadas, consulte [Activación del nivel de instancias avanzadas](fleet-manager-enable-advanced-instances-tier.md). Para obtener más información sobre los precios, consulte [Precios de AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
Tenga en cuenta la siguiente información adicional acerca del nivel de instancias estándar y el nivel de instancias avanzadas:
+ Las instancias avanzadas también permiten conectar a los nodos que no son de EC2 a un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) mediante AWS Systems Manager Session Manager. Session Manager proporciona acceso a las instancias mediante el intérprete de comandos interactivo. Para obtener más información, consulte [AWS Systems Manager Session Manager](session-manager.md).
+ La cuota de instancias estándar también se aplica a las instancias EC2 que utilizan una activación local de Systems Manager (que no es un escenario común).
+ Para aplicar revisiones a las aplicaciones publicadas por Microsoft en instancias locales de máquinas virtuales, active el nivel de instancias avanzadas. El uso del nivel de instancias avanzadas conlleva un cargo. No hay ningún cargo adicional por usar revisiones en las aplicaciones publicadas por Microsoft en instancias de Amazon Elastic Compute Cloud (Amazon EC2). Para obtener más información, consulte [Revisiones de aplicaciones publicadas por Microsoft en Windows Server](patch-manager-patching-windows-applications.md).
**Mostrar nodos administrados**
Si no ve los nodos administrados que se muestran en la consola, haga lo siguiente:
1. Verifique que la consola esté abierta en la Región de AWS en la que creó los nodos administrados. Puede cambiar Regiones utilizando la lista en la parte superior, que se encuentra en la esquina superior derecha de la consola.
1. Compruebe que los pasos de configuración para los nodos administrados cumplan los requisitos de Systems Manager. Para obtener más información, consulta [Configuración de nodos administrados para AWS Systems Manager](systems-manager-setting-up-nodes.md).
1. En el caso de las máquinas que no son de EC2, compruebe que completó el proceso de activación híbrida. Para obtener más información, consulte [Administrador de nodos en entornos híbridos y multinube con Systems Manager](systems-manager-hybrid-multicloud.md).
Tenga en cuenta la siguiente información adicional:
+ La consola de Fleet Manager no muestra los nodos de Amazon EC2 que se terminaron.
+ Systems Manager requiere referencias de tiempo precisas para realizar operaciones en las máquinas. Si no se establecen correctamente la fecha y la hora de los nodos administrados, es posible que las máquinas no coincidan con la fecha de la firma de las solicitudes de la API. Para obtener más información, consulte [Casos de uso y prácticas recomendadas](systems-manager-best-practices.md).
+ Al crear o editar etiquetas, el sistema puede tardar hasta una hora en mostrar los cambios en el filtro de tabla.
+ Cuando el estado de un nodo administrado sea `Connection Lost` durante al menos 30 días, es posible que el nodo deje de aparecer en la lista de la consola de Fleet Manager. Para que vuelva a aparecer en la lista, se debe resolver el problema que haya provocado la pérdida de conexión. Para obtener sugerencias acerca de la solución de problemas, consulte [Solución de problemas de disponibilidad de nodos administrados](fleet-manager-troubleshooting-managed-nodes.md).
**Verificar la compatibilidad de Systems Manager en un nodo administrado**
AWS Config proporciona reglas administradas de AWS, que son reglas personalizables y predefinidas que AWS Config utiliza para evaluar si las configuraciones de recursos de AWS se ajustan a las prácticas recomendadas. AWS Config se incluye la regla [ec2-instance-managed-by-systems-manager](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html). Esta regla verifica si las instancias de Amazon EC2 de su cuenta se administran mediante Systems Manager. Para obtener más información, consulte [Reglas administradas de AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html).
**Aumento de la posición de seguridad en nodos administrados**
Para obtener información acerca de cómo aumentar la posición de seguridad frente a comandos de nivel raíz no autorizados en los nodos administrados, consulte [Restricción del acceso a los comandos de nivel raíz con SSM Agent](ssm-agent-restrict-root-level-commands.md).
**Anular el registro de nodos administrados**
Puede anular el registro de los nodos administrados en cualquier momento. Por ejemplo, si administra varios nodos con el mismo rol de AWS Identity and Access Management (IAM) y nota cualquier tipo de comportamiento malicioso, puede anular el registro de cualquier número de equipos en cualquier momento. (Para volver a registrar la misma máquina, debe utilizar un código de activación híbrida y un ID de activación diferentes a los utilizados anteriormente para registrarla). Para obtener información acerca de cómo anular el registro de los nodos administrados, consulte [Anulación del registro de nodos administrados en un entorno híbrido y multinube](fleet-manager-deregister-hybrid-nodes.md).
**Topics**
+ [Configuración de los niveles de instancias](fleet-manager-configure-instance-tiers.md)
+ [Restablecimiento de contraseñas en nodos administrados](fleet-manager-reset-password.md)
+ [Anulación del registro de nodos administrados en un entorno híbrido y multinube](fleet-manager-deregister-hybrid-nodes.md)
+ [Utilizar Fleet Manager para trabajar con sistemas de archivos del sistema operativo](fleet-manager-file-system-management.md)
+ [Monitoreo del rendimiento de nodos administrados](fleet-manager-monitoring-node-performance.md)
+ [Trabajo con procesos](fleet-manager-manage-processes.md)
+ [Visualización de registros en nodos administrados](fleet-manager-view-node-logs.md)
+ [Utilizar Fleet Manager para administrar cuentas de usuario y grupos del sistema operativo en nodos administrados](fleet-manager-manage-os-user-accounts.md)
+ [Administración del registro de Windows en nodos administrados](fleet-manager-manage-windows-registry.md)
# Configuración de los niveles de instancias
En este tema se describen las situaciones en las que debe activar el nivel de instancias avanzadas.
AWS Systems Manager ofrece un nivel de instancias estándar y un nivel de instancias avanzadas para las máquinas que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types).
Puede registrar hasta 1000 [nodos activados de manera híbrida](activations.md) estándar por cada cuenta por Región de AWS sin costo adicional. Sin embargo, para registrar más de 1000 nodos híbridos es necesario activar el nivel de instancias avanzadas. El uso del nivel de instancias avanzadas conlleva un cargo. Para más información, consulte [Precios de AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
Incluso con menos de 1000 nodos activados de manera híbrida y registrados, otros dos escenarios requieren el nivel de instancias avanzadas:
+ Quiere usar Session Manager para conectarse a nodos que no son de EC2.
+ Desea aplicar revisiones a aplicaciones (no a sistemas operativos) lanzadas por Microsoft en nodos que no sean de EC2.
**nota**
No hay ningún cargo por usar revisiones en las aplicaciones lanzadas por Microsoft en instancias de Amazon EC2.
## Escenarios detallados de instancias avanzadas
La siguiente información proporciona detalles sobre los tres escenarios en los que debe activar el nivel de instancias avanzadas.
Escenario 1: registro de más de 1000 nodos activados de manera híbrida
Con el nivel de instancias estándar, puede registrar un máximo de 1000 nodos que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) por Región de AWS en una cuenta específica sin cargo adicional. Si tiene que registrar más de 1000 nodos que no sean de EC2 en una región, debe utilizar el nivel de instancias avanzadas. A continuación, puede activar tantas máquinas para su entorno híbrido y multinube como desee. Las instancias avanzadas se cobran en función del número de nodos avanzados activados como nodos administrados de Systems Manager y de las horas en que se ejecutan esos nodos.
Todos los nodos administrados de Systems Manager que utilicen el proceso de activación descrito en [Creación de una activación híbrida para registrar nodos con Systems Manager](hybrid-activation-managed-nodes.md) están por lo tanto sujetos a cargos si se superan los 1000 nodos locales en una región en una cuenta específica.
También puede activar instancias de Amazon Elastic Compute Cloud (Amazon EC2) mediante las activaciones híbridas de Systems Manager y trabajar con ellas como instancias que no son de EC2, por ejemplo, para hacer pruebas. Estos también se considerarían nodos híbridos. Este no es un escenario común.
Escenario 2: Aplicación de revisiones a aplicaciones lanzadas por Microsoft en nodos activados de forma híbrida
El nivel de instancias avanzadas también es obligatorio si desea aplicar revisiones a aplicaciones lanzadas por Microsoft en nodos que no sean de EC2 en un entorno híbrido y multinube. Si activa el nivel de instancias avanzadas para aplicar revisiones a aplicaciones de Microsoft en nodos que no sean de EC2, se cobrarán cargos por todos los nodos en las instalaciones, incluso si tiene menos de 1000.
No hay ningún cargo adicional por usar revisiones en las aplicaciones publicadas por Microsoft en instancias de Amazon Elastic Compute Cloud (Amazon EC2). Para obtener más información, consulte [Revisiones de aplicaciones publicadas por Microsoft en Windows Server](patch-manager-patching-windows-applications.md).
Escenario 3: Conexión a nodos activados de forma híbrida mediante Session Manager
Session Manager proporciona acceso de shell interactivo a las instancias. Para conectarse a nodos administrados activados de manera híbrida mediante Session Manager, primero debe activar el nivel de instancias avanzadas. A continuación, se cobran cargos por todos los nodos activados de forma híbrida, incluso si tiene menos de 1000.
**Resumen: ¿cuándo es necesario el nivel de instancias avanzadas?**
Use la siguiente tabla para ver cuándo tiene que usar el nivel de instancias avanzadas y en qué situaciones se aplican cargos adicionales.
****
| Escenario | ¿Se necesita un nivel de instancias avanzado? | ¿Se aplican cargos adicionales? |
| --- | --- | --- |
| El número de nodos activados de forma híbrida de mi región en una cuenta específica supera los 1000. | Sí | Sí |
| Quiero usar Patch Manager para aplicar revisiones a aplicaciones lanzadas por Microsoft en cualquier número de nodos activados de forma híbrida, incluso menos de 1000. | Sí | Sí |
| Quiero usar Session Manager para conectarme a cualquier número de nodos activados de forma híbrida, incluso menos de 1000. | Sí | Sí |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/fleet-manager-configure-instance-tiers.html) | No | No |
**Topics**
+ [Escenarios detallados de instancias avanzadas](#systems-manager-managed-instances-tier-scenarios)
+ [Activación del nivel de instancias avanzadas](fleet-manager-enable-advanced-instances-tier.md)
+ [Cómo revertir de la capa de instancias avanzadas a la capa de instancias estándar](fleet-manager-revert-to-standard-tier.md)
# Activación del nivel de instancias avanzadas
AWS Systems Manager ofrece un nivel de instancias estándar y un nivel de instancias avanzadas para las máquinas que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). El nivel de instancias estándar le permite registrar un máximo de 1000 máquinas activadas de forma híbrida por Cuenta de AWS por Región de AWS. También se requiere el nivel de instancias avanzadas para usar Patch Manager a fin de aplicar revisiones a aplicaciones lanzadas por Microsoft en nodos que no sean de EC2 y para conectarse a los mismos mediante Session Manager. Para obtener más información, consulte [Activación del nivel de instancias avanzadas](#fleet-manager-enable-advanced-instances-tier).
En esta sección se describe cómo configurar el entorno híbrido y multinube para utilizar el nivel de instancias avanzadas.
**Antes de empezar**
Revise la información sobre precios sobre el uso de instancias avanzadas. Las instancias avanzadas están disponibles según su uso. Para obtener más información, consulte [Precios de AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
## Configuración de permisos para activar el nivel de instancias avanzadas
Compruebe que tiene permiso en AWS Identity and Access Management (IAM) para cambiar su entorno desde el nivel de instancias estándar al nivel de instancias avanzadas. Para ello, debe tener la política de `AdministratorAccess` IAM adjunta al usuario, grupo o rol, o bien debe tener permiso para cambiar la configuración del servicio de nivel de activación de Systems Manager. La configuración del nivel de activación utiliza las siguientes operaciones de la API:
+ [GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html)
+ [UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html)
+ [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html)
Utilice el siguiente procedimiento para agregar una política de IAM en línea a una cuenta de usuario. Esta política le permite a un usuario ver la configuración actual del nivel de la instancia administrada. Esta política también le permite al usuario cambiar o restablecer la configuración actual en la Cuenta de AWS y la Región de AWS especificada.
1. Inicie sesión en la Consola de administración de AWS y abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación, seleccione **Usuarios**.
1. En la lista, seleccione el nombre del usuario en el que incorporar una política.
1. Elija la pestaña **Permisos**.
1. En la parte derecha de la página, en **Permission policies (Políticas de permisos)**, elija **Add inline policy (Añadir política insertada)**.
1. Seleccione la pestaña **JSON**.
1. Reemplace el contenido predeterminado por lo siguiente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/activation-tier"
}
]
}
```
------
1. Elija **Revisar política**.
1. En la página **Review Policy (Revisar política)**, en **Name (Nombre)**, escriba un nombre para la política insertada. Por ejemplo: **Managed-Instances-Tier**.
1. Elija **Crear política**.
Los administradores pueden especificar permiso de solo lectura al asignar la siguiente política insertada al usuario.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "*"
}
]
}
```
------
Para obtener más información acerca de la creación y la edición de políticas de IAM, consulte [Creación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.
## Activación del nivel de instancias avanzadas (consola)
En el siguiente procedimiento, se muestra cómo utilizar la consola de Systems Manager para cambiar *todos* los nodos que no son de EC2 que se agregaron mediante la activación de instancias administradas, en la Cuenta de AWS y la Región de AWS especificadas, para que utilicen el nivel de instancias avanzadas.
**Antes de empezar**
Verifique que la consola esté abierta en la Región de AWS en la que ha creado las instancias administradas. Puede cambiar Regiones utilizando la lista en la parte superior, que se encuentra en la esquina superior derecha de la consola.
Verifique que haya completado los requisitos de configuración para las instancias de Amazon Elastic Compute Cloud (Amazon EC2) y las máquinas que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). Para obtener más información, consulte [Configuración de nodos administrados para AWS Systems Manager](systems-manager-setting-up-nodes.md).
**importante**
El siguiente procedimiento describe cómo cambiar una configuración de nivel de cuenta. Este cambio se traduce en cargos que se facturan a su cuenta.
**Para habilitar el nivel de instancias avanzadas (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 **Fleet Manager**.
1. Elija **Configuración** y, a continuación, elija **Cambiar la configuración de la capa de instancia**.
1. Revise la información del cuadro de diálogo sobre el cambio de la configuración de la cuenta.
1. Si la aprueba, elija la opción que desee aceptar y, a continuación, elija **Cambiar configuración**.
El sistema puede tardar varios minutos en completar el proceso de trasladar todas las instancias de la capa de instancias estándar a la capa de instancias avanzadas.
**nota**
Para obtener información sobre cómo volver a cambiar al nivel de instancias estándar, consulte [Cómo revertir de la capa de instancias avanzadas a la capa de instancias estándar](fleet-manager-revert-to-standard-tier.md).
## Activación del nivel de instancias avanzadas (AWS CLI)
En el siguiente procedimiento, se muestra cómo utilizar la AWS Command Line Interface para cambiar *todos* los servidores locales y las máquinas virtuales que se agregaron mediante la activación de instancias administradas, en la Cuenta de AWS y la Región de AWS especificadas, para que utilicen el nivel de instancias avanzadas.
**importante**
El siguiente procedimiento describe cómo cambiar una configuración de nivel de cuenta. Este cambio se traduce en cargos que se facturan a su cuenta.
**Para activar el nivel de instancias avanzadas mediante la AWS CLI**
1. Abra la AWS CLI y ejecute el siguiente comando. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier \
--setting-value advanced
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier ^
--setting-value advanced
```
------
No se obtienen resultados si el comando se ejecuta satisfactoriamente.
1. Ejecute el siguiente comando para ver la configuración del servicio actual para nodos administrados en la Cuenta de AWS y la Región de AWS actuales.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
El comando devuelve información similar a la siguiente.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/activation-tier",
"SettingValue": "advanced",
"LastModifiedDate": 1555603376.138,
"LastModifiedUser": "arn:aws:sts::123456789012:assumed-role/Administrator/User_1",
"ARN": "arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier",
"Status": "PendingUpdate"
}
}
```
## Activación del nivel de instancias avanzadas (PowerShell)
En el siguiente procedimiento, se muestra cómo utilizar la AWS Tools for Windows PowerShell para cambiar *todos* los servidores locales y las máquinas virtuales que se agregaron mediante la activación de instancias administradas, en la Cuenta de AWS y la Región de AWS especificadas, para que utilicen el nivel de instancias avanzadas.
**importante**
El siguiente procedimiento describe cómo cambiar una configuración de nivel de cuenta. Este cambio se traduce en cargos que se facturan a su cuenta.
**Para activar el nivel de instancias avanzadas con PowerShell**
1. Abra AWS Tools for Windows PowerShell y ejecute el siguiente comando. Reemplace cada *example resource placeholder* con su propia información.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "advanced"
```
No se obtienen resultados si el comando se ejecuta satisfactoriamente.
1. Ejecute el siguiente comando para ver la configuración del servicio actual para nodos administrados en la Cuenta de AWS y la Región de AWS actuales.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
El comando devuelve información similar a la siguiente.
```
ARN:arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier
LastModifiedDate : 4/18/2019 4:02:56 PM
LastModifiedUser : arn:aws:sts::123456789012:assumed-role/Administrator/User_1
SettingId : /ssm/managed-instance/activation-tier
SettingValue : advanced
Status : PendingUpdate
```
El sistema puede tardar varios minutos en completar el proceso de trasladar todos los nodos del nivel de instancias estándar al nivel de instancias avanzadas.
**nota**
Para obtener información sobre cómo volver a cambiar al nivel de instancias estándar, consulte [Cómo revertir de la capa de instancias avanzadas a la capa de instancias estándar](fleet-manager-revert-to-standard-tier.md).
# Cómo revertir de la capa de instancias avanzadas a la capa de instancias estándar
En esta sección se describe cómo cambiar los nodos activados de manera híbrida que se ejecutan en el nivel de instancias avanzadas al nivel de instancias estándar. Esta configuración se aplica a todos los nodos activados de manera híbrida de una Cuenta de AWS y una única Región de AWS.
**Antes de empezar**
Revise los siguientes detalles importantes.
**nota**
No puede volver al nivel de instancia estándar si está ejecutando más de 1000 nodos activados de manera híbrida en la cuenta y en la región. Primero debe anular el registro de nodos hasta que tenga 1000 o menos. Esto también se aplica a las instancias de Amazon Elastic Compute Cloud (Amazon EC2) que utilizan una activación híbrida de Systems Manager (lo que no es una situación común). Para obtener más información, consulte [Anulación del registro de nodos administrados en un entorno híbrido y multinube](fleet-manager-deregister-hybrid-nodes.md).
Después de revertir, no podrá utilizar Session Manager, una herramienta de AWS Systems Manager, para acceder de forma interactiva a los nodos activados de manera híbrida.
Después de revertir, no podrá utilizar Patch Manager, una herramienta de AWS Systems Manager, para revisar las aplicaciones lanzadas por Microsoft en nodos activados de manera híbrida.
El proceso de revertir todos los nodos activados de manera híbrida al nivel de instancias estándar puede tardar 30 minutos o más en completarse.
En esta sección se describe cómo revertir todos los nodos activados de manera híbrida de una Cuenta de AWS y Región de AWS desde el nivel de instancias avanzadas al nivel de instancias estándar.
## Reversión a la capa de instancias estándar (consola)
En el procedimiento siguiente se muestra cómo utilizar la consola de Systems Manager para cambiar todos los nodos activados de manera híbrida en el entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) para utilizar el nivel de instancias estándar de la Cuenta de AWS y la Región de AWS especificadas.
**Para revertir al nivel de instancias estándar (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 **Fleet Manager**.
1. Seleccione el menú desplegable **Account settings** (Configuración de la cuenta) y elija **Instance tier settings** (Configuración del nivel de instancias).
1. Elija **Change account setting (Cambiar la configuración de la cuenta)**.
1. Revise la información en la ventana emergente sobre cómo cambiar la configuración de la cuenta y, a continuación, si está de acuerdo, elija la opción para aceptar y continuar.
## Reversión a la capa de instancias estándar (AWS CLI)
En el procedimiento siguiente se muestra cómo utilizar AWS Command Line Interface para cambiar todos los nodos activados de manera híbrida en el entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) para utilizar el nivel de instancias estándar de la Cuenta de AWS y la Región de AWS especificadas.
**Para revertir al nivel de instancias estándar utilizando la AWS CLI**
1. Abra la AWS CLI y ejecute el siguiente comando. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier \
--setting-value standard
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier ^
--setting-value standard
```
------
No se obtienen resultados si el comando se ejecuta satisfactoriamente.
1. Ejecute el siguiente comando 30 minutos más tarde para ver la configuración de instancias administradas en la Cuenta de AWS y la Región de AWS actuales.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier
```
------
El comando devuelve información similar a la siguiente.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/activation-tier",
"SettingValue": "standard",
"LastModifiedDate": 1555603376.138,
"LastModifiedUser": "System",
"ARN": "arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier",
"Status": "Default"
}
}
```
El estado cambia a *Default (Predeterminado)* una vez aprobada la solicitud.
## Reversión a la capa de instancias estándar (PowerShell)
En el procedimiento siguiente se muestra cómo utilizar AWS Tools for Windows PowerShell para cambiar todos los nodos activados de manera híbrida en el entorno híbrido y multinube para utilizar el nivel de instancias estándar de la Cuenta de AWS y la Región de AWS especificadas.
**Para revertir al nivel de instancias estándar mediante PowerShell**
1. Abra AWS Tools for Windows PowerShell y ejecute el siguiente comando.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "standard"
```
No se obtienen resultados si el comando se ejecuta satisfactoriamente.
1. Ejecute el siguiente comando 30 minutos más tarde para ver la configuración de instancias administradas en la Cuenta de AWS y la Región de AWS actuales.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
El comando devuelve información similar a la siguiente.
```
ARN: arn:aws:ssm:us-east-2:123456789012:servicesetting/ssm/managed-instance/activation-tier
LastModifiedDate : 4/18/2019 4:02:56 PM
LastModifiedUser : System
SettingId : /ssm/managed-instance/activation-tier
SettingValue : standard
Status : Default
```
El estado cambia a *Default (Predeterminado)* una vez aprobada la solicitud.
# Restablecimiento de contraseñas en nodos administrados
Puede restablecer la contraseña para cualquier usuario en un nodo administrado. Esto incluye instancias de Amazon Elastic Compute Cloud (Amazon EC2), servidores de núcleo de AWS IoT Greengrass, servidores locales, dispositivos de borde y máquinas virtuales administradas por AWS Systems Manager. La función de restablecimiento de contraseña se basa en Session Manager, una herramienta de AWS Systems Manager. Puede utilizar esta funcionalidad para conectarse a los nodos administrados sin abrir los puertos de entrada, mantener hosts bastión ni administrar claves SSH.
El restablecimiento de contraseña resulta útil cuando un usuario ha olvidado una contraseña, o cuando desea actualizar rápidamente una contraseña sin realizar una conexión RDP o SSH al nodo administrado.
**Requisitos previos**
Antes de que pueda restablecer la contraseña en un nodo administrado, deben cumplirse los siguientes requisitos:
+ El nodo administrado en el que desee cambiar una contraseña debe ser un nodo administrado de Systems Manager. Además, la versión 2.3.668.0 de SSM Agent o una versión posterior debe estar instalada en el nodo administrado. Para obtener información acerca cómo instalar o actualizar SSM Agent, consulte [Uso de SSM Agent](ssm-agent.md).
+ La funcionalidad de restablecimiento de contraseñas utiliza la configuración de Session Manager, la cual está establecida de forma que su cuenta se conecte al nodo administrado. Por lo tanto, los requisitos previos para utilizar Session Manager deben haberse completado en su cuenta en la Región de AWS actual. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md).
**nota**
La compatibilidad de Session Manager con nodos en las instalaciones se proporciona solo para el nivel de instancias avanzadas. Para obtener más información, consulte [Activación del nivel de instancias avanzadas](fleet-manager-enable-advanced-instances-tier.md).
+ El usuario AWS que está cambiando la contraseña debe tener el permiso `ssm:SendCommand` para el nodo administrado. Para obtener más información, consulte [Restricción de acceso de Run Command basado en etiquetas](run-command-setting-up.md#tag-based-access).
**Restricción del acceso**
Puede limitar la capacidad de un usuario para restablecer contraseñas para nodos administrados específicos. Esto se hace mediante políticas basadas en la identidad para la operación Session Manager de `ssm:StartSession` con el documento `AWS-PasswordReset` de SSM. Para obtener más información, consulte [Control del acceso de las sesiones de usuario a las instancias](session-manager-getting-started-restrict-access.md).
**Cifrado de datos**
Active el cifrado completo de AWS Key Management Service (AWS KMS) para los datos de Session Manager a fin de utilizar la opción de restablecimiento de contraseña de los nodos administrados. Para obtener más información, consulte [Activación del cifrado de datos de sesión con claves de KMS (consola)](session-preferences-enable-encryption.md).
## Restablecer una contraseña en un nodo administrado
Puede restablecer una contraseña en un nodo administrado de Systems Manager mediante la consola **Fleet Manager** de Systems Manager o AWS Command Line Interface (AWS CLI).
**Para cambiar la contraseña en un nodo administrado (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 **Fleet Manager**.
1. Elija el botón situado al lado del nodo que necesita una nueva contraseña.
1. Seleccione **Acciones de instancia, Restablecer la contraseña**.
1. En el campo **User name** (Nombre de usuario), ingrese el nombre del usuario para el que va a cambiar la contraseña. Este puede ser cualquier nombre de usuario con una cuenta en el nodo.
1. Elija **Enviar**.
1. Siga las instrucciones en la ventana de comandos **Introducir nueva contraseña** para especificar la nueva contraseña.
**nota**
Si la versión de SSM Agent en el nodo administrado no admite restablecimientos de contraseñas, se le pedirá que instale una versión compatible con Run Command, una herramienta de AWS Systems Manager.
**Para restablecer la contraseña en un nodo administrado (AWS CLI)**
1. Para restablecer la contraseña de un usuario en un nodo administrado, ejecute el siguiente comando. Reemplace cada *example resource placeholder* con su propia información.
**nota**
Para utilizar la AWS CLI para restablecer una contraseña, el complemento Session Manager debe estar instalado en su equipo local. Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md).
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name "AWS-PasswordReset" \
--parameters '{"username": ["user-name"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name "AWS-PasswordReset" ^
--parameters username="user-name"
```
------
1. Siga las instrucciones en la ventana de comandos **Introducir nueva contraseña** para especificar la nueva contraseña.
## Solucionar problemas de restablecimiento de contraseña en nodos administrados
Muchos problemas de restablecimiento de contraseña pueden resolverse; para ello, asegúrese de que ha completado los [requisitos previos de restablecimiento de contraseña](#pw-reset-prereqs). Para otros problemas, utilice la siguiente información para ayudarle a solucionar problemas para restablecer la contraseña.
**Topics**
+ [Nodo administrado no disponible](#password-reset-troubleshooting-instances)
+ [SSM Agent no actualizada (consola)](#password-reset-troubleshooting-ssmagent-console)
+ [No se proporcionan las opciones de restablecimiento de contraseña (). (AWS CLI)](#password-reset-troubleshooting-ssmagent-cli)
+ [No hay autorización para ejecutar `ssm:SendCommand`](#password-reset-troubleshooting-sendcommand)
+ [Session ManagerMensaje de error](#password-reset-troubleshooting-session-manager)
### Nodo administrado no disponible
**Problema**: desea restablecer la contraseña de un nodo administrado en la página de la consola de **Instancias administradas**, pero el nodo no se encuentra en la lista.
+ **Solución**: el nodo administrado al que desea conectarse podría no estar configurado para Systems Manager. Para utilizar una instancia de EC2 con Systems Manager, el perfil de instancias de AWS Identity and Access Management (IAM) que concede permiso a Systems Manager para realizar acciones en sus instancias debe estar adjuntado a la instancia. Para obtener información, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md).
Para utilizar una máquina que no es de EC2 con Systems Manager, debe crear un rol de servicio de IAM que le conceda permiso a Systems Manager para realizar acciones en los nodos administrados. Para obtener más información, consulte [Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube](hybrid-multicloud-service-role.md). (Solo se ofrece compatibilidad de Session Manager con servidores locales y máquinas virtuales para el nivel de instancias avanzadas. Para obtener más información, consulte [Activación del nivel de instancias avanzadas](fleet-manager-enable-advanced-instances-tier.md).)
### SSM Agent no actualizada (consola)
**Problema**: un mensaje informa que la versión de SSM Agent no admite la función de restablecimiento de contraseñas.
+ **Solución**: se requiere la versión 2.3.668.0 o una versión posterior de SSM Agent para realizar restablecimientos de contraseñas. En la consola, puede actualizar el agente en el nodo administrado al elegir **Update SSM Agent** (Actualizar SSM Agente).
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.
### No se proporcionan las opciones de restablecimiento de contraseña (). (AWS CLI)
**Problema**: puede conectarse correctamente a un nodo administrado mediante el comando AWS CLI `[https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)`. Ha especificado el documento de SSM `AWS-PasswordReset` y ha proporcionado un nombre de usuario válido, pero no se muestran las instrucciones para cambiar la contraseña.
+ **Solución**: la versión de SSM Agent en el nodo administrado no está actualizada. Es necesaria la versión 2.3.668.0 o una versión posterior para realizar restablecimientos de contraseña.
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.
### No hay autorización para ejecutar `ssm:SendCommand`
**Problema**: intenta conectarse a un nodo administrado para cambiar la contraseña, pero recibe un mensaje de error que indica que no cuenta con la autorización para ejecutar `ssm:SendCommand` en el nodo administrado.
+ **Solución**: la política de IAM debe incluir un permiso para ejecutar el comando `ssm:SendCommand`. Para obtener más información, consulte [Restricción de acceso de Run Command basado en etiquetas](run-command-setting-up.md#tag-based-access).
### Session ManagerMensaje de error
**Problema**: recibe un mensaje de error relacionado con Session Manager.
+ **Solución**: el soporte para restablecer la contraseña requiere que Session Manager esté configurado correctamente. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md) y [Resolución de problemas de Session Manager](session-manager-troubleshooting.md).
# Anulación del registro de nodos administrados en un entorno híbrido y multinube
Si ya no desea administrar un servidor local, un dispositivo de borde o una máquina virtual mediante AWS Systems Manager, puede anular el registro. Anular el registro de un nodo activado de manera híbrida lo elimina de la lista de nodos administrados en Systems Manager. AWS Systems Manager El agente (SSM Agent) que se está ejecutando en el nodo activado de manera híbrida no podrá actualizar su token de autorización porque ya no está registrado. SSM Agent hiberna y reduce su frecuencia de ping a Systems Manager en la nube a una vez por hora. Systems Manager almacena el historial de comandos de un nodo administrado con el registro anulado durante 30 días.
**nota**
Puede volver a registrar un servidor en las instalaciones, un dispositivo periférico o una máquina virtual con el mismo código e ID de activación siempre que no haya alcanzado el límite de instancias para el código e ID de activación designados. Puede verificar el límite de instancias en la consola; para ello, elija **Herramientas de nodo** y seleccione **Activaciones híbridas**. Si el valor de las **Instancias registradas** es inferior al **Límite de registro**, puede volver a registrar una máquina con el mismo código de activación e ID. Si es mayor, debe usar un código de activación y un ID diferentes.
El procedimiento siguiente describe cómo anular el registro de un nodo activado de manera híbrida mediante la consola de Systems Manager. Para obtener información acerca de cómo hacer esto mediante la AWS Command Line Interface, consulte [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html).
Para obtener información relacionada, consulte los siguientes temas:
+ [Anulación del registro y nuevo registro de un nodo administrado (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister) (Linux)
+ [Anulación del registro y nuevo registro de un nodo administrado (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister) (Windows Server)
**Anulación del registro de un nodo activado de manera híbrida (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 **Fleet Manager**.
1. Seleccione la casilla de verificación situada junto al nodo administrado cuyo registro desea anular.
1. Seleccione **Acciones de nodos, Herramientas, Anular el registro de este nodo administrado**.
1. Revise la información del cuadro de diálogo **Anular el registro de este nodo administrado**. Si está de acuerdo, seleccione **Anular registro**.
# Utilizar Fleet Manager para trabajar con sistemas de archivos del sistema operativo
Puede utilizar Fleet Manager, una herramienta de AWS Systems Manager, para trabajar con el sistema de archivos en los nodos administrados. Al utilizar Fleet Manager, puede visualizar la información sobre los datos de archivos y de directorios almacenados en los volúmenes adjuntados a los nodos administrados. Por ejemplo, puede ver el nombre, el tamaño, la extensión, el propietario y los permisos de sus directorios y archivos. Se puede obtener una vista previa de hasta 10 000 líneas de datos de archivo como texto desde la consola de Fleet Manager. También puede utilizar esta característica para `tail` (poner en cola) archivos. Cuando se utiliza `tail` para ver los datos del archivo, las últimas 10 líneas del archivo se muestran al inicio. A medida que se escriben nuevas líneas de datos en el archivo, la vista se actualiza en tiempo real. Como resultado, puede revisar los datos de registro desde la consola, lo que puede mejorar la eficiencia de la solución de problemas y la administración de sistemas. Además, puede crear directorios y copiar, cortar, pegar, cambiar el nombre o eliminar archivos y directorios.
Se recomienda que cree copias de seguridad con regularidad o que tome instantáneas de los volúmenes de Amazon Elastic Block Store (Amazon EBS) adjuntados a los nodos administrados. Al copiar, cortar o pegar archivos, se sustituyen los archivos y directorios existentes en la ruta de destino con el mismo nombre que los archivos o directorios nuevos. Pueden producirse problemas graves si reemplaza o modifica los archivos y directorios del sistema. AWS no garantiza que estos problemas se puedan resolver. Modifique los archivos del sistema bajo su propia responsabilidad. El usuario es responsable de todos los cambios en los archivos y directorios, y de asegurarse de tener copias de seguridad. No se puede deshacer la eliminación o la sustitución de archivos y directorios.
**nota**
Fleet Manager utiliza Session Manager, una herramienta de AWS Systems Manager, para obtener vistas previas de texto y archivos `tail`. Para las instancias de Amazon Elastic Compute Cloud (Amazon EC2), el perfil de instancias adjuntado a las instancias administradas debe proporcionar permisos para que Session Manager utilice esta característica. Para obtener más información acerca de cómo agregar permisos de Session Manager al perfil de instancias, consulte [Adición de permisos de Session Manager a un rol de IAM existente](getting-started-add-permissions-to-existing-profile.md).
**Topics**
+ [Utilizar Fleet Manager para visualizar el sistema de archivos del sistema operativo](fleet-manager-viewing-file-system.md)
+ [Utilizar Fleet Manager para obtener una vista previa de los archivos del sistema operativo](fleet-manager-preview-os-files.md)
+ [Utilizar Fleet Manager para seguir archivos del sistema operativo](fleet-manager-tailing-os-files.md)
+ [Utilizar Fleet Manager para copiar, cortar y pegar archivos o directorios del sistema operativo](fleet-manager-move-files-or-directories.md)
+ [Utilizar Fleet Manager para cambiar el nombre de archivos y directorios del sistema operativo](fleet-manager-renaming-files-and-directories.md)
+ [Utilizar Fleet Manager para eliminar archivos y directorios del sistema operativo](fleet-manager-deleting-files-and-directories.md)
+ [Utilizar Fleet Manager para crear directorios del sistema operativo](fleet-manager-creating-directories.md)
+ [Utilizar Fleet Manager para cortar, copiar y pegar directorios del sistema operativo](fleet-manager-managing-directories.md)
# Utilizar Fleet Manager para visualizar el sistema de archivos del sistema operativo
Se puede utilizar Fleet Manager para visualizar el sistema de archivos del sistema operativo en un nodo administrado de Systems Manager.
**Para utilizar Fleet Manager para visualizar el sistema de archivos del sistema operativo**
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. Seleccione el enlace del nodo administrado con el sistema de archivos que desea ver.
1. Elija **Herramientas, Sistema de archivos**.
# Utilizar Fleet Manager para obtener una vista previa de los archivos del sistema operativo
Puede utilizar Fleet Manager para obtener una vista previa de los archivos de texto en un sistema operativo.
**Para utilizar Fleet Manager para obtener vistas previas de texto de archivos**
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. Seleccione el enlace del nodo administrado con los archivos de los que desea obtener una vista previa.
1. Elija **Herramientas, Sistema de archivos**.
1. Seleccione el **File name** (Nombre de archivo) del directorio que contiene el archivo que desea previsualizar.
1. Elija el botón situado al lado del archivo cuyo contenido desea previsualizar.
1. Elija **Acciones, Obtener vista previa como texto**.
# Utilizar Fleet Manager para seguir archivos del sistema operativo
Puede utilizar Fleet Manager para seguir un archivo en un nodo administrado.
**Para seguir archivos del sistema operativo con Fleet 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. Seleccione el enlace del nodo administrado con los archivos que desea poner en cola.
1. Elija **Herramientas, Sistema de archivos**.
1. Seleccione el **File name** (Nombre de archivo) del directorio que contiene el archivo que desea poner en cola.
1. Elija el botón situado al lado del archivo cuyo contenido desea poner en cola.
1. Elija **Acciones, Obtener final de archivos**.
# Utilizar Fleet Manager para copiar, cortar y pegar archivos o directorios del sistema operativo
Se puede utilizar Fleet Manager para copiar, cortar y pegar archivos del sistema operativo en un nodo administrado.
**Para utilizar Fleet Manager para copiar o cortar y pegar archivos o directorios**
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. Seleccione el enlace del nodo administrado con los archivos que desea copiar, cortar o pegar.
1. Elija **Herramientas, Sistema de archivos**.
1. Para copiar o cortar un archivo, seleccione la opción **File name** (Nombre del archivo) del directorio que contiene el archivo que desea copiar o cortar. Para copiar o cortar un directorio, elija el botón situado junto al directorio que desea copiar o cortar y, a continuación, proceda al paso 8.
1. Elija el botón situado al lado del archivo cuyo contenido desea copiar o cortar.
1. En el menú **Actions** (Acciones), elija **Copy** (Copiar) o **Cut** (Cortar).
1. En la vista **File system** (Sistema de archivos), elija el botón que aparece junto al directorio en el que desea pegar el archivo.
1. En el menú **Actions** (Acciones), elija **Paste** (Pegar).
# Utilizar Fleet Manager para cambiar el nombre de archivos y directorios del sistema operativo
Puede utilizar Fleet Manager para cambiar el nombre de archivos y directorios en un nodo administrado de la cuenta.
**Para cambiar el nombre de los archivos o directorios con Fleet 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. Seleccione el enlace del nodo administrado con los archivos o directorios que desea renombrar.
1. Elija **Herramientas, Sistema de archivos**.
1. Para cambiar el nombre de un archivo, seleccione el **File name** (Nombre del archivo) del directorio que contiene el archivo que desea cambiar el nombre. Para cambiar el nombre de un directorio, elija el botón situado junto al directorio al que desea cambiar el nombre y, a continuación, continúe con el paso 8.
1. Elija el botón situado al lado del archivo cuyo contenido desea cambiarle el nombre
1. Selecciona **Acciones, Cambiar nombre**.
1. En **Nombre del archivo**, escriba el nombre nuevo del archivo y seleccione **Cambiar nombre**.
# Utilizar Fleet Manager para eliminar archivos y directorios del sistema operativo
Puede utilizar Fleet Manager para eliminar archivos y directorios en un nodo administrado de la cuenta.
**Para utilizar Fleet Manager para eliminar archivos o directorios**
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. Seleccione el enlace del nodo administrado con los archivos o directorios que desea eliminar.
1. Elija **Herramientas, Sistema de archivos**.
1. Para eliminar un archivo, seleccione la **File name** (Nombre del archivo) del directorio que contiene el archivo que desea eliminar. Para eliminar un directorio, elija el botón que aparece junto al directorio que desea eliminar y, a continuación, vaya al paso 7.
1. Elija el botón situado al lado del archivo cuyo contenido desea eliminar.
1. Elija **Acciones, Eliminar**.
# Utilizar Fleet Manager para crear directorios del sistema operativo
Puede utilizar Fleet Manager para crear directorios en un nodo administrado de la cuenta.
**Para utilizar Fleet Manager para crear un directorio**
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. Seleccione el enlace del nodo administrado en el que desea crear un directorio.
1. Elija **Herramientas, Sistema de archivos**.
1. Seleccione el **File name** (Nombre del archivo) del directorio en el que desea crear un nuevo directorio.
1. Seleccione **Create directory** (Crear directorio).
1. En el campo **Nombre del directorio**, escriba el nombre del directorio nuevo y seleccione **Crear directorio**.
# Utilizar Fleet Manager para cortar, copiar y pegar directorios del sistema operativo
Puede utilizar Fleet Manager para cortar, copiar y pegar directorios en un nodo administrado en la cuenta.
**Para utilizar Fleet Manager para copiar o cortar y pegar directorios**
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. Seleccione el enlace del nodo administrado con los archivos que desea copiar, cortar o pegar.
1. Elija **Herramientas, Sistema de archivos**.
1. Elija el botón situado junto al directorio que desea copiar o cortar y, a continuación, proceda al paso 8.
1. En el menú **Actions** (Acciones), elija **Copy** (Copiar) o **Cut** (Cortar).
1. En la vista **File system** (Sistema de archivos), elija el botón que aparece junto al directorio en el que desea pegar el archivo.
1. En el menú **Actions** (Acciones), elija **Paste** (Pegar).
# Monitoreo del rendimiento de nodos administrados
Puede utilizar Fleet Manager, una herramienta de AWS Systems Manager, para ver los datos de rendimiento de los nodos administrados en tiempo real. Los datos de rendimiento se recuperan de los contadores de rendimiento.
Los siguientes contadores de rendimiento están disponibles en Fleet Manager:
+ Utilización de la CPU
+ Utilización de entrada/salida (E/S) del disco
+ Tráfico de red
+ Uso de memoria
**nota**
Fleet Manager utiliza Session Manager, una herramienta de AWS Systems Manager, para recuperar datos de rendimiento. Para las instancias de Amazon Elastic Compute Cloud (Amazon EC2), el perfil de instancias adjuntado a las instancias administradas debe proporcionar permisos para que Session Manager utilice esta característica. Para obtener más información acerca de cómo agregar permisos de Session Manager al perfil de instancias, consulte [Adición de permisos de Session Manager a un rol de IAM existente](getting-started-add-permissions-to-existing-profile.md).
**Para ver los datos de rendimiento con Fleet 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. Elija el botón situado junto al nodo administrado cuyo rendimiento desea monitorear.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Contadores de rendimiento**.
# Trabajo con procesos
Puede utilizar Fleet Manager, una herramienta de AWS Systems Manager, para trabajar con procesos en los nodos administrados. Mediante el uso de Fleet Manager, puede ver la información de los procesos. Por ejemplo, puede ver la utilización de la CPU y el uso de memoria de los procesos, además de sus controladores y subprocesos. Con Fleet Manager, puede iniciar y terminar procesos desde la consola.
**nota**
Fleet Manager utiliza Session Manager, una herramienta de AWS Systems Manager, para recuperar los datos del proceso. Para las instancias de Amazon Elastic Compute Cloud (Amazon EC2), el perfil de instancias adjuntado a las instancias administradas debe proporcionar permisos para que Session Manager utilice esta característica. Para obtener más información acerca de cómo agregar permisos de Session Manager al perfil de instancias, consulte [Adición de permisos de Session Manager a un rol de IAM existente](getting-started-add-permissions-to-existing-profile.md).
**Topics**
+ [Utilizar Fleet Manager para visualizar los detalles sobre los procesos del sistema operativo](fleet-manager-view-process-details.md)
+ [Utilizar Fleet Manager para iniciar un proceso del sistema operativo en un nodo administrado](fleet-manager-start-process.md)
+ [Utilizar Fleet Manager para terminar un proceso del sistema operativo](fleet-manager-terminate-process.md)
# Utilizar Fleet Manager para visualizar los detalles sobre los procesos del sistema operativo
Puede utilizar Fleet Manager para visualizar los detalles sobre los procesos en los nodos administrados.
**Para ver los detalles de los procesos con Fleet 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. Seleccione el enlace del nodo cuyos procesos desea visualizar.
1. Elija **Herramientas, Procesos**.
# Utilizar Fleet Manager para iniciar un proceso del sistema operativo en un nodo administrado
Puede utilizar Fleet Manager para iniciar un proceso en un nodo administrado.
**Para iniciar un proceso con Fleet 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. Seleccione el enlace del nodo administrado en el que desea iniciar un proceso.
1. Elija **Herramientas, Procesos**.
1. Seleccione **Start new process** (Iniciar un proceso nuevo).
1. En el campo **Nombre del proceso o ruta completa**, escriba el nombre del proceso o la ruta completa del ejecutable.
1. (Opcional) En el campo **Directorio de trabajo**, ingrese la ruta del directorio en la que desea que se ejecute el proceso.
# Utilizar Fleet Manager para terminar un proceso del sistema operativo
**Para utilizar Fleet Manager para terminar un proceso del sistema operativo**
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. Seleccione el enlace del nodo administrado en el que desea iniciar un proceso.
1. Elija **Herramientas, Procesos**.
1. Seleccione el botón situado junto al proceso que desea terminar.
1. Elija **Acciones, Terminar proceso** o **Acciones, Terminar árbol de procesos**.
**nota**
Terminar un árbol de procesos también finaliza todos los procesos y aplicaciones que utilizan ese proceso.
# Visualización de registros en nodos administrados
Puede utilizar Fleet Manager, una herramienta de AWS Systems Manager, para ver los datos de registro almacenados en los nodos administrados. En los nodos administrados de Windows, puede ver los registros de eventos de Windows y copiar sus detalles desde la consola. Para ayudarlo a buscar eventos, filtre los registros de eventos de Windows por **Event level** (Nivel de evento), **Event ID** (ID de evento), **Event source** (Origen del evento), y **Time created** (Hora creada). También puede ver otros datos de registro mediante el procedimiento para ver el sistema de archivos. Para obtener más información acerca de cómo ver el sistema de archivos con Fleet Manager, consulte [Utilizar Fleet Manager para trabajar con sistemas de archivos del sistema operativo](fleet-manager-file-system-management.md).
**Para ver los registros de eventos de Windows con Fleet 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. Elija el botón situado junto al nodo administrado cuyos registros de eventos desea ver.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Registros de eventos de Windows**.
1. Elija la opción de **Log name** (Nombre de registro) que contiene los eventos que desea ver.
1. Elija el botón situado al lado de **Log name** (Nombre de registro) que desea ver y, a continuación, seleccione **View eventos** (Ver eventos).
1. Elija el botón situado al lado del evento que desea ver y, a continuación, seleccione **View event details** (Ver detalles del evento).
1. (Opcional) Seleccione **Copy as JSON** (Copiar como JSON) para copiar los detalles del evento en el portapapeles.
# Utilizar Fleet Manager para administrar cuentas de usuario y grupos del sistema operativo en nodos administrados
Puede utilizar Fleet Manager, una herramienta de AWS Systems Manager, para administrar las cuentas de usuario y los grupos del sistema operativo (SO) de los nodos administrados. Por ejemplo, puede crear y eliminar usuarios y grupos. Además, puede ver detalles como, por ejemplo, pertenencia a grupos, roles de usuario y estado.
**importante**
Fleet Manager utiliza Run Command y Session Manager, herramientas de AWS Systems Manager, para diversas operaciones de administración de usuarios. Como resultado, un usuario podría conceder permisos a una cuenta de usuario del sistema operativo que no podría conceder de otro modo. Esto es porque el agente de AWS Systems Manager (SSM Agent) se ejecuta en las instancias de Amazon Elastic Compute Cloud (Amazon EC2) mediante permisos raíz (Linux) o permisos SYSTEM (Windows Server). Para obtener más información sobre cómo restringir el acceso a los comandos de nivel de raíz mediante SSM Agent, consulte [Restricción del acceso a los comandos de nivel raíz con SSM Agent](ssm-agent-restrict-root-level-commands.md). Para restringir el acceso a esta característica, recomendamos crear políticas de AWS Identity and Access Management (IAM) para los usuarios que solo permiten el acceso a las acciones que defina. Para obtener más información acerca de la creación de políticas de IAM para Fleet Manager, consulte [Control del acceso a Fleet Manager](configuring-fleet-manager-permissions.md).
**Topics**
+ [Utilizar Fleet Manager para crear un usuario o grupo del sistema operativo](manage-os-user-accounts-create.md)
+ [Utilizar Fleet Manager para actualizar la pertenencia a un usuario o grupo](manage-os-user-accounts-update.md)
+ [Utilizar Fleet Manager para eliminar un usuario o grupo de sistema operativo](manage-os-user-accounts-delete.md)
# Utilizar Fleet Manager para crear un usuario o grupo del sistema operativo
**nota**
Fleet Manager utiliza Session Manager para establecer contraseñas para nuevos usuarios. Para las instancias de Amazon EC2, el perfil de instancias adjuntado a las instancias administradas debe proporcionar permisos para que Session Manager utilice esta característica. Para obtener más información acerca de cómo agregar permisos de Session Manager al perfil de instancias, consulte [Adición de permisos de Session Manager a un rol de IAM existente](getting-started-add-permissions-to-existing-profile.md).
En lugar de conectarse directamente a un servidor para crear una cuenta de usuario o grupo, puede utilizar la consola de Fleet Manager para realizar las mismas tareas.
**Para utilizar Fleet Manager para crear una cuenta de usuario del sistema operativo**
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. Elija el botón situado junto al nodo administrado en el que desea crear un nuevo usuario.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Usuarios y grupos**.
1. Elija la pestaña **Users** (Usuarios) y, a continuación, elija **Create user** (Crear usuario).
1. Ingrese un valor para la propiedad **Name** (Nombre) del nuevo usuario.
1. (Recomendado) Seleccione la casilla de verificación situada junto a **Set password** (Establecer la contraseña). Al final del procedimiento, se le pedirá que especifique una contraseña para el nuevo usuario.
1. Seleccione **Create user** (Crear usuario). Si seleccionó la casilla de verificación para crear una contraseña para el nuevo usuario, se le pedirá que ingrese un valor para la contraseña y seleccione **Done** (Hecho). Si la contraseña especificada no cumple los requisitos especificados por las políticas locales o de dominio del nodo administrado, se devuelve un error.
**Para utilizar Fleet Manager para crear un grupo del sistema operativo**
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. Elija el botón situado junto al nodo administrado en el que desea crear un nuevo grupo.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Usuarios y grupos**.
1. Elija la pestaña **Groups (Grupos)** y, a continuación, elija **Create group (Crear grupo)**.
1. Ingrese un valor para la propiedad **Name** (Nombre) del nuevo grupo.
1. (Opcional) Ingrese un valor para la propiedad **Description** (Descripción) del nuevo grupo.
1. (Opcional) Seleccione los usuarios que desea agregar a la propiedad **Group members** (Miembros del grupo) para el nuevo grupo.
1. Seleccione **Create group** (Crear grupo).
# Utilizar Fleet Manager para actualizar la pertenencia a un usuario o grupo
En lugar de conectarse directamente a un servidor para actualizar una cuenta de usuario o grupo, puede utilizar la consola de Fleet Manager para realizar las mismas tareas.
**Para utilizar Fleet Manager para agregar una cuenta de usuario del sistema operativo a un nuevo grupo**
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. Elija el botón situado junto al nodo administrado en el que existe la cuenta de usuario que desea actualizar.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Usuarios y grupos**.
1. Elija la pestaña **Users**.
1. Elija el botón situado al lado del usuario que desea actualizar.
1. Elija **Acciones, Agregar usuario al grupo**.
1. Elija el grupo al que desea agregar el usuario en **Add to group** (Agregar al grupo).
1. Seleccione **Add user to group** (Agregar usuario al grupo).
**Para utilizar Fleet Manager para editar la pertenencia a un grupo del sistema operativo**
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. Elija el botón situado junto al nodo administrado en el que existe el grupo que desea actualizar.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Usuarios y grupos**.
1. Seleccione la pestaña **Groups** (Grupos).
1. Elija el botón situado al lado del grupo que desea actualizar.
1. Elija **Acciones, Modificar grupo**.
1. Elija los usuarios que desea agregar o eliminar en **Group members** (Miembros del grupo).
1. Seleccione **Modify group** (Modificar grupo).
# Utilizar Fleet Manager para eliminar un usuario o grupo de sistema operativo
En lugar de conectarse directamente a un servidor para eliminar una cuenta de usuario o grupo, puede utilizar la consola de Fleet Manager para realizar las mismas tareas.
**Para utilizar Fleet Manager para eliminar una cuenta de usuario del sistema operativo**
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. Elija el botón situado junto al nodo administrado en el que existe la cuenta de usuario que desea eliminar.
1. Elija **Ver detalles**.
1. Elija **Usuarios y grupos**.
1. Elija la pestaña **Users**.
1. Elija el botón situado al lado del usuario que desea eliminar.
1. Elija **Acciones, Eliminar usuario local**.
**Utilizar Fleet Manager para eliminar un grupo del sistema operativo**
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. Elija el botón situado junto al nodo administrado en el que existe el grupo que desea eliminar.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Usuarios y grupos**.
1. Elija la pestaña **Groups** (Grupos).
1. Elija el botón situado al lado del grupo que desea actualizar.
1. Elija **Acciones, Eliminar grupo local**.
# Administración del registro de Windows en nodos administrados
Puede utilizar Fleet Manager, una herramienta de AWS Systems Manager, para administrar el registro en los nodos administrados de Windows Server. Desde la consola de Fleet Manager puede crear, copiar, actualizar y eliminar entradas y valores del registro.
**importante**
Recomendamos crear una copia de seguridad del registro o tomar una instantánea del volumen raíz de Amazon Elastic Block Store (Amazon EBS) adjuntado al nodo administrado antes de modificar el registro. Pueden producirse problemas graves si modifica el registro de manera incorrecta. Estos problemas pueden requerir que vuelva a instalar el sistema operativo o que restaure el volumen raíz del nodo desde una instantánea. AWS no garantiza que estos problemas puedan ser resueltos. Modifique el registro por su cuenta y riesgo. Usted es responsable de todos los cambios en el registro y de asegurarse de tener copias de seguridad.
## Creación de una clave o entrada del registro de Windows
**Para crear una clave del registro de Windows con Fleet 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. Elija el botón situado junto al nodo administrado en el que desea crear una clave de registro.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Registro de Windows**.
1. Elija el hive en el que desea crear una nueva clave de registro seleccionando la opción **Registry name** (Nombre de registro).
1. Elija **Crear, Crear clave del registro**.
1. Elija el botón situado al lado de la entrada de registro en la que desea crear una nueva clave.
1. Elija **Create registry key** (Crear clave del registro).
1. Ingrese un valor para la propiedad **Name** (Nombre) de la nueva clave de registro y seleccione **Submit** (Enviar).
**Para crear una entrada de registro de Windows con Fleet 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. Elija el botón situado al lado de la instancia en la que desea crear una entrada de registro.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Registro de Windows**.
1. Elija el hive y la clave de registro siguiente en la que desea crear una nueva entrada de registro seleccionando la propiedad **Registry name** (Nombre de registro).
1. Elija **Crear, Crear entrada del registro**.
1. Ingrese un valor en **Name** (Nombre) para el registro nuevo.
1. Elija la característica **Type** (Tipo) de valor que desea crear para la entrada de registro. Para obtener más información acerca de los tipos de valores de registro, consulte [Tipos de valores de registro](https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-value-types).
1. Ingrese un valor para la propiedad **Valor** (Valor) de la nueva entrada de registro.
## Actualización de una entrada de registro de Windows
**Para actualizar una entrada de registro de Windows con Fleet 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. Elija el botón situado junto al nodo administrado en el que desea actualizar una entrada del registro.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Registro de Windows**.
1. Elija el hive y la clave de registro siguiente que desea actualizar seleccionando la casilla de **Registry name** (Nombre de registro).
1. Elija el botón situado al lado de la entrada de registro que desea actualizar.
1. Elija **Acciones, Actualizar entrada de registro**.
1. Ingrese el nuevo valor para **Value** (Valor) de la entrada del registro.
1. Elija **Actualizar**.
## Eliminación de una entrada o clave de registro de Windows
**Para eliminar una clave de registro de Windows con Fleet 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. Elija el botón situado junto al nodo administrado en el que desea eliminar una clave de registro.
1. Elija **Herramientas, Registro de Windows**.
1. Seleccione el hive y la clave de registro posterior que desea eliminar seleccionando la casilla de **Registry name** (Nombre de registro).
1. Elija el botón situado al lado de la clave de registro que desea eliminar.
1. Elija **Acciones, Eliminar clave de registro**.
**Para eliminar una entrada de registro de Windows con Fleet 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. Elija el botón situado junto al nodo administrado en el que desea eliminar una entrada de registro.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Registro de Windows**.
1. Elija el hive y la clave de registro siguiente que contiene la entrada que desea eliminar seleccionando la casilla de **Registry name** (Nombre de registro).
1. Elija el botón situado al lado de la entrada de registro que desea eliminar.
1. Elija **Acciones, Eliminar entrada de registro**.
# Administración automática de instancias EC2 con la configuración de administración de hosts predeterminada
La configuración predeterminada de la administración de hosts permite que AWS Systems Manager administre las instancias de Amazon EC2 de forma automática como *instancias administradas*. Una instancia administrada es una instancia EC2 configurada para usarla con Systems Manager.
Los beneficios de administrar sus instancias con Systems Manager incluyen los siguientes:
+ Conéctese a sus instancias de EC2 de forma segura mediante Session Manager.
+ Realice escaneos de revisiones automatizados mediante Patch Manager.
+ Consulte información detallada sobre sus instancias mediante Systems Manager Inventory.
+ Realice un seguimiento y administre las instancias mediante Fleet Manager.
+ Mantenga SSM Agent actualizado automáticamente.
*Fleet Manager, Inventario, Patch Manager y Session Manager son herramientas de Systems Manager.*
Si usa la configuración de administración de host predeterminada, puede administrar las instancias de EC2 sin tener que crear manualmente un perfil de instancia de AWS Identity and Access Management (IAM). En su lugar, la configuración predeterminada de la administración de hosts crea y aplica un rol de IAM predeterminado para garantizar que Systems Manager tenga los permisos de administración de todas las instancias de la Cuenta de AWS y la Región de AWS en la que está activado.
Si los permisos proporcionados no son suficientes para su caso de uso, también puede agregar políticas al rol de IAM predeterminado creado en la configuración de administración de host predeterminada. Como alternativa, si no necesita permisos para todas las capacidades proporcionadas por el rol de IAM predeterminado, puede crear sus propias políticas y roles personalizados. Cualquier cambio realizado en el rol de IAM que elija para la configuración de administración de host predeterminada se aplica a todas las instancias de Amazon EC2 administradas en la región y la cuenta.
Para obtener más información acerca de la política que usa la configuración de administración de host predeterminada, consulte [Política administrada por AWS: AmazonSSMManagedEC2InstanceDefaultPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSSMManagedEC2InstanceDefaultPolicy).
**Implementación del acceso a los privilegios mínimos**
Los procedimientos de este tema están pensados para que solo los realicen los administradores. Por lo tanto, recomendamos implementar el *acceso con privilegio mínimo* para evitar que los usuarios no administrativos configuren o modifiquen la configuración de administración de host predeterminada. Para ver ejemplos de políticas que restringen el acceso a la configuración de administración de host predeterminada, consulte [Ejemplos de políticas de privilegio mínimo para la configuración de administración de host predeterminada](#least-privilege-examples) más adelante en este tema.
**importante**
El registro de la información de las instancias registradas con la configuración predeterminada de la administración de hosts almacena la información de registro localmente en los directorios `var/lib/amazon/ssm` o `C:\ProgramData\Amazon`. Si se eliminan estos directorios o sus archivos, la instancia no podrá adquirir las credenciales necesarias para conectarse a Systems Manager mediante la Configuración de la administración de hosts predeterminada. En estos casos, debe utilizar un perfil de instancia IAM para brindar los permisos necesarios a la instancia, o bien volver a crearla.
**Topics**
+ [Requisitos previos](#dhmc-prerequisites)
+ [Activación de la configuración de la administración de hosts predeterminada](#dhmc-activate)
+ [Desactivación de la configuración predeterminada de la administración de hosts](#dhmc-deactivate)
+ [Ejemplos de políticas de privilegio mínimo para la configuración de administración de host predeterminada](#least-privilege-examples)
## Requisitos previos
Para utilizar la configuración predeterminada de la administración de hosts en la Región de AWS y la Cuenta de AWS donde se active la característica, se deben cumplir los siguientes requisitos.
+ La instancia que se vaya a administrar debe usar Instance Metadata Service versión 2 (IMDSv2).
La configuración de administración de host predeterminada no admite la versión 1 del servicio de metadatos de instancias. Para obtener información sobre la transición a IMDSv2, consulte [Transición al uso de Servicio de metadatos de instancia versión 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) en la *Guía del usuario de Amazon EC2*.
+ Se debe instalar la versión 3.2.582.0 o alguna versión posterior de SSM Agent en la instancia para ser administrada.
Para obtener información sobre cómo comprobar la versión de SSM Agent instalada en la instancia, consulte [Verificación del número de versión de SSM Agent](ssm-agent-get-version.md).
Para obtener información sobre cómo actualizar SSM Agent, consulte [Actualización automática de SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console).
+ Usted, como administrador que realiza las tareas de este tema, debe tener permisos para las operaciones de las API [GetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html), [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html) y [UpdateServicesetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html). Además, debe tener permisos `iam:PassRole` para el rol de IAM `AWSSystemsManagerDefaultEC2InstanceManagementRole`. La siguiente política de ejemplo concede estos permisos. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting",
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ssm.amazonaws.com"
]
}
}
}
]
}
```
------
+ Si ya existe un perfil de instancia de IAM asociado a una instancia de EC2 que hay que administrar con Systems Manager, debe quitarle todos los permisos que permitan la operación `ssm:UpdateInstanceInformation`. SSM Agent intenta usar permisos de perfil de instancia antes de emplear los permisos de la Configuración de la administración de hosts predeterminada. Si permite la operación `ssm:UpdateInstanceInformation` en los perfiles de instancia de IAM, la instancia no utilizará los permisos de la configuración de administración de host predeterminada.
## Activación de la configuración de la administración de hosts predeterminada
Puede activar la configuración predeterminada de la administración de hosts desde la consola de Fleet Manager o al utilizar la AWS Command Line Interface o AWS Tools for Windows PowerShell.
Debe activar, una por una, las configuraciones predeterminadas de la administración de hosts en cada región en donde quiera que las instancias de Amazon EC2 se administren mediante esta configuración.
Tras activar la configuración predeterminada de la administración de hosts, es posible que las instancias tarden 30 minutos en utilizar las credenciales del rol que seleccione en el paso 5 del procedimiento que se detalla a continuación.
**Activación de la configuración de administración de host predeterminada (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 **Fleet Manager**.
1. Elija **Administración de cuenta, Configuración de la administración de host predeterminada**.
1. Active **Habilitar configuración de administración de host predeterminada**.
1. Elija el rol de AWS Identity and Access Management (IAM) que se utiliza para habilitar las herramientas de Systems Manager en sus instancias. Recomendamos utilizar el rol predeterminado que proporciona la configuración de administración de host predeterminada. Contiene el conjunto mínimo de permisos necesarios para administrar sus instancias de Amazon EC2 mediante Systems Manager. Si prefiere utilizar un rol personalizado, la política de confianza del rol debe permitir que Systems Manager sea una entidad de confianza.
1. Elija **Configurar** para completar la configuración.
**Activación de la configuración de administración de host predeterminada (línea de comandos)**
1. Cree un archivo JSON en su equipo local que contenga la siguiente política de relaciones de confianza.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
]
}
```
------
1. Abra la AWS CLI o las Herramientas para Windows PowerShell y ejecute uno de los siguientes comandos, según el tipo de sistema operativo de su máquina local, a fin de crear un rol de servicio en su cuenta. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws iam create-role \
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole \
--path /service-role/ \
--assume-role-policy-document file://trust-policy.json
```
------
#### [ Windows ]
```
aws iam create-role ^
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole ^
--path /service-role/ ^
--assume-role-policy-document file://trust-policy.json
```
------
#### [ PowerShell ]
```
New-IAMRole `
-RoleName "AWSSystemsManagerDefaultEC2InstanceManagementRole" `
-Path "/service-role/" `
-AssumeRolePolicyDocument "file://trust-policy.json"
```
------
1. Ejecute el siguiente comando para adjuntar la política administrada `AmazonSSMManagedEC2InstanceDefaultPolicy` al rol recientemente creado. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy \
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ Windows ]
```
aws iam attach-role-policy ^
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy ^
--role-name AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ PowerShell ]
```
Register-IAMRolePolicy `
-PolicyArn "arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy" `
-RoleName "AWSSystemsManagerDefaultEC2InstanceManagementRole"
```
------
1. Abra la AWS CLI o Herramientas para Windows PowerShell y ejecute el siguiente comando. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws ssm update-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role \
--setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ Windows ]
```
aws ssm update-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role ^
--setting-value service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole
```
------
#### [ PowerShell ]
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role" `
-SettingValue "service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole"
```
------
No se obtienen resultados si el comando se ejecuta satisfactoriamente.
1. Ejecute el siguiente comando a fin de ver la configuración del servicio actual para la configuración de administración de host predeterminada en la Cuenta de AWS y la Región de AWS actuales.
------
#### [ Linux & macOS ]
```
aws ssm get-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ Windows ]
```
aws ssm get-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ PowerShell ]
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
```
------
El comando devuelve información similar a la siguiente.
```
{
"ServiceSetting": {
"SettingId": "/ssm/managed-instance/default-ec2-instance-management-role",
"SettingValue": "service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"LastModifiedDate": "2022-11-28T08:21:03.576000-08:00",
"LastModifiedUser": "System",
"ARN": "arn:aws:ssm:us-east-2:-123456789012:servicesetting/ssm/managed-instance/default-ec2-instance-management-role",
"Status": "Custom"
}
}
```
## Desactivación de la configuración predeterminada de la administración de hosts
Puede desactivar la configuración predeterminada de la administración de hosts desde la consola de Fleet Manager o al utilizar la AWS Command Line Interface o AWS Tools for Windows PowerShell.
Debe desactivar, una por una, las configuraciones predeterminadas de la administración de hosts en cada región en donde ya no quiere que las instancias de Amazon EC2 se administren mediante esta configuración. Si se desactiva en una región, no se desactiva en todas las regiones.
Si desactiva la configuración de administración de host predeterminada y no ha adjuntado un perfil de instancia a sus instancias de Amazon EC2 que permita el acceso a Systems Manager, este último dejará de administrarlas.
**Desactivación de la configuración de administración de host predeterminada (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 **Fleet Manager**.
1. Elija **Administración de cuenta, Configuración de la administración de host predeterminada**.
1. Desactive **Habilitar configuración de administración de host predeterminada**.
1. Elija **Configurar** para deshabilitar la configuración de administración de host predeterminada.
**Desactivación de la configuración de administración de host predeterminada (línea de comandos)**
+ Abra la AWS CLI o Herramientas para Windows PowerShell y ejecute el siguiente comando. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws ssm reset-service-setting \
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ Windows ]
```
aws ssm reset-service-setting ^
--setting-id arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role
```
------
#### [ PowerShell ]
```
Reset-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:account-id:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
```
------
## Ejemplos de políticas de privilegio mínimo para la configuración de administración de host predeterminada
Los siguientes ejemplos de políticas muestran cómo evitar que los miembros de su organización realicen cambios en la configuración de administración de host predeterminada de su cuenta.
### Política de control de servicios para AWS Organizations
La siguiente política demuestra cómo evitar que los miembros no administrativos de AWS Organizations actualicen la configuración de administración de host predeterminada. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:ResetServiceSetting"
],
"Resource": "arn:aws:ssm:*:*:servicesetting/ssm/managed-instance/default-ec2-instance-management-role",
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
},
{
"Effect": "Deny",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::*:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ssm.amazonaws.com"
},
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
},
{
"Effect": "Deny",
"Resource": "arn:aws:iam::*:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole"
],
"Condition": {
"StringNotEqualsIgnoreCase": {
"aws:PrincipalTag/job-function": [
"administrator"
]
}
}
}
]
}
```
------
### Política para entidades principales de IAM
La siguiente política demuestra cómo evitar que sus grupos, funciones o usuarios de IAM en AWS Organizations actualicen su configuración de administración de host predeterminada. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ssm:UpdateServiceSetting",
"ssm:ResetServiceSetting"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:servicesetting/ssm/managed-instance/default-ec2-instance-management-role"
},
{
"Effect": "Deny",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::111122223333:role/service-role/AWSSystemsManagerDefaultEC2InstanceManagementRole"
}
]
}
```
------
# Conéctese a una instancia administrada de Windows Server mediante Remote Desktop
Puede utilizar Fleet Manager, una herramienta de AWS Systems Manager, para conectarse a sus instancias de Amazon Elastic Compute Cloud (Amazon EC2) de Windows Server mediante el Remote Desktop Protocol (RDP). Fleet Manager El escritorio remoto, que cuenta con tecnología [Amazon DCV](https://docs.aws.amazon.com/dcv/latest/adminguide/what-is-dcv.html), brinda una conectividad segura a las instancias de Windows Server directamente desde la consola de Systems Manager. Puede tener hasta cuatro conexiones simultáneas en una sola ventana del navegador.
La API de escritorio remoto Fleet Manager se denomina AWS Systems Manager GUI Connect. Para obtener información sobre el uso de la API GUI Connect de Systems Manager, consulte la *[Referencia de la API de AWS Systems Manager GUI Connect](https://docs.aws.amazon.com/ssm-guiconnect/latest/APIReference)*.
Actualmente, solo puede utilizar el escritorio remoto con instancias que ejecuten Windows Server 2012 RTM o versiones posteriores. El escritorio remoto solo admite entradas en idioma inglés.
Fleet Manager Remote Desktop es un servicio exclusivo de consola y no admite conexiones de línea de comandos a las instancias administradas. Para conectarte a una instancia administrada de Windows Server a través de un intérprete de comandos, puede usar Session Manager, otra herramienta de AWS Systems Manager. Para obtener más información, consulte [AWS Systems Manager Session Manager](session-manager.md).
**nota**
La duración de una conexión RDP no se determina por la duración de sus credenciales AWS Identity and Access Management (IAM). En su lugar, la conexión se mantiene hasta que se alcance la duración máxima de la conexión o el límite de tiempo de inactividad, lo que ocurra primero. Para obtener más información, consulte [Duración y simultaneidad de la conexión remota](#rdp-duration-concurrency).
Para obtener más información sobre la configuración de los permisos de (IAM) AWS Identity and Access Management para permitir que las instancias interactúen con Systems Manager, consulte [Configurar permisos de instancia para Systems Manager](setup-instance-permissions.md).
**Topics**
+ [Configuración del entorno](#rdp-prerequisites)
+ [Configuración de los permisos de IAM para escritorio remoto](#rdp-iam-policy-examples)
+ [Autenticación de conexiones del escritorio remoto](#rdp-authentication)
+ [Duración y simultaneidad de la conexión remota](#rdp-duration-concurrency)
+ [Gestión de atributos de AWS IAM Identity Center de Systems Manager GUI Connect](#iam-identity-center-attribute-handling)
+ [Conexión a un nodo administrado mediante escritorio remoto](#rdp-connect-to-node)
+ [Ver información sobre las conexiones actuales y completadas](#list-connections)
## Configuración del entorno
Antes de utilizar el escritorio remoto, asegúrese de que el entorno cumple los siguientes requisitos:
+ **Configuración de nodos administrados**
Asegúrese de que las instancias de Amazon EC2 estén configuradas como [nodos administrados](fleet-manager-managed-nodes.md) en Systems Manager.
+ **SSM Agent Versión mínima de**
Verifique que los nodos ejecuten la versión 3.0.222.0 o versiones posteriores de SSM Agent. Para obtener información sobre cómo comprobar la versión de agente que se está ejecutando en un nodo, consulte [Verificación del número de versión de SSM Agent](ssm-agent-get-version.md). Para obtener información acerca cómo instalar o actualizar SSM Agent, consulte [Uso de SSM Agent](ssm-agent.md).
+ **Configuración del puerto de RDP**
Para aceptar conexiones remotas, el servicio Remote Desktop Services de los nodos de Windows Server debe utilizar el puerto de RDP 3389 predeterminado. Esta es la configuración predeterminada en Amazon Machine Images (AMIs) que proporciona AWS. No es necesario abrir de manera explícita ningún puerto de entrada para utilizar el escritorio remoto.
+ **PSReadLine Versión del módulo para la funcionalidad del teclado**
Para asegurarse de que el teclado funciona correctamente en PowerShell, verifique que los nodos que ejecutan Windows Server 2022 tengan instalada la versión 2.2.2 o versiones posteriores del módulo PSReadLine. Si están ejecutando una versión anterior, puede instalar la versión necesaria mediante los siguientes comandos.
```
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
```
Una vez instalado el proveedor de paquetes NuGet, ejecute el siguiente comando.
```
Install-Module `
-Name PSReadLine `
-Repository PSGallery `
-MinimumVersion 2.2.2 -Force
```
+ **Configuración del administrador de sesiones**
Para poder utilizar el escritorio remoto, debe completar los requisitos previos de la configuración del administrador de sesiones. Cuando se conecta a una instancia mediante el escritorio remoto, se aplican todas las preferencias de sesión que haya definido para la Cuenta de AWS y la Región de AWS. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md).
**nota**
Si registra la actividad del administrador de sesiones mediante Amazon Simple Storage Service (Amazon S3), las conexiones del escritorio remoto generarán el siguiente error en `bucket_name/Port/stderr`. Se espera que aparezca este error, pero se puede omitir sin problemas.
```
Setting up data channel with id SESSION_ID failed: failed to create websocket for datachannel with error: CreateDataChannel failed with no output or error: createDataChannel request failed: unexpected response from the service
Session is already terminated
```
## Configuración de los permisos de IAM para escritorio remoto
Además de los permisos de IAM necesarios para Systems Manager y Session Manager, el usuario o rol que utilice debe tener permisos para iniciar conexiones.
**Permisos para iniciar conexiones**
Para establecer conexiones RDP con instancias de EC2 en la consola, se necesitan los siguientes permisos:
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
**Permisos para enumerar las conexiones**
Para ver listas de conexiones en la consola, se necesita el siguiente permiso:
`ssm-guiconnect:ListConnections`
A continuación, se muestran ejemplos de políticas de IAM que puede adjuntar a un usuario o un rol para permitir distintos tipos de interacción con el escritorio remoto. Reemplace cada *example resource placeholder* con su propia información.
### Política estándar para conectarse a instancias de EC2
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}"
]
}
}
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*",
"arn:aws:ssm:*::document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
### Política de conexión a instancias de EC2 con etiquetas específicas
**nota**
En la siguiente política de IAM, la sección `SSMStartSession` requiere un nombre de recurso de Amazon (ARN) para la acción `ssm:StartSession`. Como se muestra, el ARN que especifique *no* requiere un ID de Cuenta de AWS. Si especifica un ID de cuenta, Fleet Manager devuelve un `AccessDeniedException`.
La sección `AccessTaggedInstances`, que se encuentra en la parte inferior de la política de ejemplo, también requiere los ARN para `ssm:StartSession`. Para esos ARN, debe especificar los ID de Cuenta de AWS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:*::document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "AccessTaggedInstances",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*",
"arn:aws:ssm:*:111122223333:managed-instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag key": [
"tag value"
]
}
}
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
### Política para que los usuarios de AWS IAM Identity Center se conecten a instancias de EC2
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSO",
"Effect": "Allow",
"Action": [
"sso:ListDirectoryAssociations*",
"identitystore:DescribeUser"
],
"Resource": "*"
},
{
"Sid": "EC2",
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:GetPasswordData"
],
"Resource": "*"
},
{
"Sid": "SSM",
"Effect": "Allow",
"Action": [
"ssm:DescribeInstanceProperties",
"ssm:GetCommandInvocation",
"ssm:GetInventorySchema"
],
"Resource": "*"
},
{
"Sid": "TerminateSession",
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userName}"
]
}
}
},
{
"Sid": "SSMStartSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:managed-instance/*",
"arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession"
],
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": "ssm-guiconnect.amazonaws.com"
}
}
},
{
"Sid": "SSMSendCommand",
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:managed-instance/*",
"arn:aws:ssm:*:*:document/AWSSSO-CreateSSOUser"
]
},
{
"Sid": "GuiConnect",
"Effect": "Allow",
"Action": [
"ssm-guiconnect:CancelConnection",
"ssm-guiconnect:GetConnection",
"ssm-guiconnect:StartConnection",
"ssm-guiconnect:ListConnections"
],
"Resource": "*"
}
]
}
```
------
## Autenticación de conexiones del escritorio remoto
Cuando se establece una conexión remota, puede autenticarse mediante las credenciales de Windows o el par de claves de Amazon EC2 (archivo `.pem`) que está asociado a la instancia. Para obtener información sobre cómo usar los pares de claves, consulte [Pares de claves de Amazon EC2 e instancias de Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*.
De forma alternativa, si está autenticado en la Consola de administración de AWS con AWS IAM Identity Center, puede conectarse a las instancias sin proporcionar credenciales adicionales. Si desea ver un ejemplo de política para permitir la autenticación de conexiones remotas mediante IAM Identity Center, consulte [Configuración de los permisos de IAM para escritorio remoto](#rdp-iam-policy-examples).
**Antes de empezar**
Tenga en cuenta las siguientes condiciones para utilizar la autenticación de IAM Identity Center antes de comenzar a conectarse mediante Remote Desktop.
+ El escritorio remoto admite la autenticación de IAM Identity Center para nodos en la misma Región de AWS donde se habilitó IAM Identity Center.
+ El escritorio remoto admite nombres de usuario de IAM Identity Center que tengan hasta 16 caracteres.
+ El escritorio remoto admite nombres de usuario de IAM Identity Center compuestos por caracteres alfanuméricos y los siguientes caracteres especiales: `.` `-` o `_` .
**importante**
Las conexiones no se realizarán correctamente para los nombres de usuario de IAM Identity Center que contengan los siguientes caracteres: `+` `=` `,`
IAM Identity Center admite estos caracteres en los nombres de usuario, pero las conexiones de RDP de Fleet Manager no lo hace.
Además, si un nombre de usuario del Centro de Identidad de IAM contiene uno o más símbolos `@`, Fleet Manager ignora el primer símbolo `@` y todos los caracteres que le siguen, independientemente de que `@` introduzca o no la parte de dominio de una dirección de correo electrónico. Por ejemplo, en el caso del nombre de usuario del Centro de Identidad de IAM `diego_ramirez@example.com`, la parte `@example.com` se ignora y el nombre de usuario para Fleet Manager pasa a ser `diego_ramirez`. Para `diego_r@mirez@example.com`, Fleet Manager ignora `@mirez@example.com` y el nombre de usuario para Fleet Manager pasa a ser `diego_r`.
+ Cuando se autentica una conexión mediante IAM Identity Center, el escritorio remoto crea un usuario de Windows local en el grupo de administradores locales de la instancia. Este usuario persiste una vez finalizada la conexión remota.
+ El escritorio remoto no permite la autenticación de IAM Identity Center para nodos que son controladores de dominio de Microsoft Active Directory.
+ Si bien el escritorio remoto permite utilizar la autenticación de IAM Identity Center para los nodos *unidos* a un dominio de Active Directory, no se recomienda hacerlo. Este método de autenticación concede permisos administrativos a usuarios que pueden anular los permisos más restrictivos concedidos por el dominio.
**Regiones compatibles con la autenticación de IAM Identity Center**
Las siguientes Regiones de AWS son compatibles con conexiones de Remote Desktop que utilicen la autenticación de IAM Identity Center:
+ 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)
+ África (Ciudad del Cabo) (af-south-1)
+ Asia-Pacífico (Hong Kong) (ap-east-1)
+ Asia-Pacífico (Mumbai) (ap-south-1)
+ Asia-Pacífico (Tokio) (ap-northeast-1)
+ Asia-Pacífico (Seúl) (ap-northeast-2)
+ Asia Pacific (Osaka) (ap-northeast-3)
+ Asia-Pacífico (Singapur) (ap-southeast-1)
+ Asia-Pacífico (Sídney) (ap-southeast-2)
+ Asia-Pacífico (Yakarta) (ap-southeast-3)
+ Canadá (centro) (ca-central-1)
+ Europa (Fráncfort) (eu-central-1)
+ Europa (Estocolmo) (eu-north-1)
+ Europa (Irlanda) (eu-west-1)
+ Europa (Londres) (eu-west-2)
+ Europa (París) (eu-west-3)
+ Israel (Tel Aviv) (il-central-1)
+ América del Sur (São Paulo) (sa-east-1)
+ UE (Milán) (eu-south-1)
+ Medio Oriente (Baréin) (me-south-1)
+ AWS GovCloud (EE. UU. Este) (us-gov-east-1)
+ AWS GovCloud (EE. UU. Oeste) (us-gov-west-1)
## Duración y simultaneidad de la conexión remota
Las siguientes condiciones se aplican a las conexiones activas del escritorio remoto:
+ **Duración de la conexión**
Una conexión al escritorio remoto dura 60 minutos de forma predeterminada. Para evitar que una conexión se desconecte, puede elegir **Renovar sesión** antes de que se desconecte para restablecer el temporizador de duración.
+ **Tiempo de espera de la conexión**
Una conexión del escritorio remoto se desconecta después de haber estado inactiva durante más de 10 minutos.
+ **Conexiones persistentes**
Después de conectarse a un Windows Server con Escritorio remoto, la conexión se mantiene hasta que se alcance la duración máxima de la conexión (60 minutos) o el límite de tiempo de espera de inactividad (10 minutos). La duración de la conexión no se determina por la duración de sus credenciales AWS Identity and Access Management (IAM). La conexión se mantiene después de que caduquen las credenciales de IAM si no se alcanzan los límites de duración de la conexión. Cuando utilice Escritorio remoto, debe salir de la página del navegador para finalizar la conexión luego de que caduquen sus credenciales de IAM.
+ **Conexiones simultáneas**
De forma predeterminada, puede tener un máximo de 5 conexiones del escritorio remoto activas a la vez para la misma Cuenta de AWS y la misma Región de AWS. Para solicitar un aumento de cuota de servicio de hasta 50 conexiones simultáneas, consulte [Solicitud de aumento de cuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) en la *Guía del usuario de Service Quotas*.
**nota**
La licencia estándar de Windows Server permite dos conexiones RDP simultáneas. Para admitir más conexiones, debe adquirir licencias de acceso de cliente (CAL) adicionales de Microsoft o licencias de Microsoft Remote Desktop Services de AWS. Para obtener más información acerca de las licencias complementarias, consulte los siguientes temas:
[Licencias de acceso de cliente y licencias de administración](https://www.microsoft.com/en-us/licensing/product-licensing/client-access-license) en el sitio web de Microsoft
[Utilice las suscripciones basadas en usuarios de License Manager para los productos de software compatibles](https://docs.aws.amazon.com/license-manager/latest/userguide/user-based-subscriptions.html) en la *Guía del usuario de License Manager*
## Gestión de atributos de AWS IAM Identity Center de Systems Manager GUI Connect
Systems Manager GUI Connect es la API que admite conexiones de Fleet Manager a instancias EC2 mediante RDP. Los siguientes datos de usuario del IAM Identity Center se retienen después de cerrar una conexión:
+ `username`
Systems Manager GUI Connect cifra este atributo de identidad en reposo mediante una Clave administrada de AWS de forma predeterminada. Las claves administradas por el cliente no se admiten para cifrar este atributo en Systems Manager GUI Connect. Si elimina un usuario de su instancia de IAM Identity Center, Systems Manager GUI Connect sigue reteniendo el atributo de `username` asociado a ese usuario durante 7 años, tras lo cual se eliminará. Estos datos se retienen para respaldar los eventos de auditoría, como la lista del historial de conexiones de GUI Connect de Systems Manager. Los datos no se pueden eliminar de forma manual.
## Conexión a un nodo administrado mediante escritorio remoto
**Soporte para copiar/pegar texto en el navegador**
Con los navegadores Google Chrome y Microsoft Edge, puede copiar y pegar texto desde un nodo administrado a su equipo local y desde su equipo local a un nodo administrado al que esté conectado.
Con el navegador Mozilla Firefox, solo puede copiar y pegar texto desde un nodo administrado a su equipo local. No se admite la copia desde el equipo local al nodo administrado.
**Para conectarse a un nodo administrado mediante el escritorio remoto de Fleet 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. Haga clic en el nodo al que desea conectarse. Puede seleccionar la casilla de verificación o el nombre del nodo.
1. En el menú **Acciones de nodos**, elija **Conectar con escritorio remoto**.
1. Elija el **Tipo de autenticación** preferido. Si selecciona **Credenciales de usuario**, ingrese el nombre de usuario y la contraseña de una cuenta de usuario de Windows en el nodo al que se está conectando. Si elige **Par de claves**, puede proporcionar la autenticación mediante uno de los siguientes métodos:
1. Elija **Examinar equipo local** si desea seleccionar la clave PEM asociada a la instancia desde su sistema de archivos local.
-o bien-
1. Elija **Pegar el contenido del par de claves** si desea copiar el contenido del archivo PEM y pegarlo en el campo proporcionado.
1. Seleccione **Conectar**.
1. Para elegir la resolución de pantalla de preferencia, en el menú **Acciones**, elija **Resoluciones** y, luego, seleccione una de las siguientes opciones:
+ **Ajuste automático**
+ **1920 x 1080**
+ **1400 x 900**
+ **1366 x 768**
+ **800 x 600**
La opción **Adaptar automáticamente** establece la resolución en función del tamaño de pantalla detectado.
## Ver información sobre las conexiones actuales y completadas
Puede utilizar la sección Fleet Manager de la consola de Systems Manager para ver información sobre las conexiones RDP que se han establecido en la cuenta. Puede utilizar un conjunto de filtros para limitar la lista de conexiones que aparecen a un intervalo de tiempo, una instancia específica, el usuario que estableció las conexiones y las conexiones de un estado específico. Además, la consola ofrece pestañas que muestran información sobre todas las conexiones actualmente activas y todas las conexiones anteriores.
**Para ver información sobre las conexiones actuales y completadas**
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. Seleccione **Administración de cuentas, Establecer conexión con el escritorio remoto**.
1. Elija una de las siguientes pestañas:
+ **Conexiones activas**
+ **Historial de conexiones**
1. Para reducir aún más la lista de resultados de conexiones que aparecen, especifique uno o varios filtros en la casilla de búsqueda (![\[\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/search-icon.png)). También puede ingresar un término de búsqueda de texto libre.
# Administración de volúmenes de Amazon EBS en instancias administradas
[Amazon Elastic Block Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) (Amazon EBS) proporciona volúmenes de almacenamiento por bloques para su uso con instancias de Amazon Elastic Compute Cloud (EC2). Los volúmenes de EBS se comportan como dispositivos de bloques sin formatear. Puede montar estos volúmenes como dispositivos en sus instancias.
Puede utilizar Fleet Manager, una herramienta de AWS Systems Manager, para administrar los volúmenes de Amazon EBS en las instancias administradas. Por ejemplo, puede inicializar un volumen de EBS, dar formato a una partición y montar el volumen para que esté disponible para su uso.
**nota**
En la actualidad, Fleet Manager solo admite la administración de volúmenes de Amazon EBS para instancias de Windows Server.
## Visualización de los detalles del volumen de EBS
**Para ver los detalles del volumen de EBS con Fleet 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. Elija el botón situado junto a la instancia administrada de la que desea ver los detalles del volumen de EBS.
1. Elija **Ver detalles**.
1. Elija **Herramientas, Volúmenes de EBS**.
1. Para ver los detalles de un volumen de EBS, elija su ID en la columna **ID de volumen**.
## Inicialización y formato de un volumen de EBS
**Para inicializar un volumen de EBS y darle formato con Fleet 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. Elija el botón situado junto a la instancia administrada de la que desea inicializar, dar formato y montar el volumen de EBS. Solo puede inicializar un volumen de EBS si su disco está vacío.
1. Elija **Ver detalles**.
1. En el menú **Herramientas**, elija **Volúmenes de EBS**.
1. Elija el botón situado junto al volumen de EBS que desea inicializar y dar formato.
1. Seleccione **Inicializar y dar formato**.
1. En **Estilo de partición**, elija el que desee usar para el volumen de EBS.
1. (Opcional) Elija una **letra de unidad** para la partición.
1. (Opcional) Escriba un **nombre de partición** para identificarla.
1. Elija el **sistema de archivos** que se utilizará para organizar los archivos y los datos almacenados en la partición.
1. Elija **Confirmar** para poner el volumen de EBS a disposición para su uso. No puede cambiar la configuración de la partición de la Consola de administración de AWS después de confirmarla. Sin embargo, puede usar SSH o RDP para iniciar sesión en la instancia y cambiar la configuración de la partición.
# Acceso al portal de la base de conocimientos de Red Hat
Puede usar Fleet Manager, una herramienta de AWS Systems Manager, para acceder al portal de la base de conocimientos si es cliente de Red Hat. Se lo considera cliente de Red Hat si ejecuta instancias de Red Hat Enterprise Linux (RHEL) o utiliza servicios de RHEL en AWS. El portal de la base de conocimientos incluye datos binarios y recursos compartidos de conocimientos y foros de discusión para soporte comunitario que solo están disponibles para clientes con licencia de Red Hat.
Además de los permisos de AWS Identity and Access Management (IAM) requeridos para Systems Manager y Fleet Manager, el usuario o el rol que usa para acceder a la consola debe permitir la acción `rhelkb:GetRhelURL` para acceder al portal de la base de conocimientos.
**Para acceder al portal de la base de conocimientos de Red Hat**
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. Elija la instancia de RHEL que desea utilizar para conectarse al portal de la base de conocimientos de Red Hat.
1. Seleccione **Administración de cuenta**, **Acceder a la base de conocimientos de Red Hat** para abrir la página de la base de conocimientos de Red Hat.
Si utiliza RHEL en AWS para ejecutar cargas de trabajo de RHEL totalmente compatibles, también puede acceder a la base de conocimientos de Red Hat a través del sitio web de Red Hat con sus credenciales de AWS.
# Solución de problemas de disponibilidad de nodos administrados
Para varias herramientas de AWS Systems Manager, como Run Command, Distributor y Session Manager, puede elegir seleccionar de forma manual los nodos administrados en los que desea ejecutar la operación. En estos casos, después de especificar que desea elegir los nodos de forma manual, se muestra una lista de los nodos administrados donde puede ejecutar la operación.
Este tema proporciona información para ayudarlo a diagnosticar por qué un nodo administrado *que ha confirmado que se está ejecutando* no está incluido en las listas de nodos administrados de Systems Manager.
Para que Systems Manager administre un nodo y dicho nodo esté disponible en las listas de nodos administrados, debe cumplir tres requisitos:
+ SSM Agent debe estar instalado y ejecutándose en el nodo con un sistema operativo compatible.
**nota**
Algunas Amazon Machine Images (AMIs) administradas de AWS están configuradas para lanzar instancias con [SSM Agent](ssm-agent.md) preinstalado. (También puede configurar una AMI personalizada para la preinstalación de SSM Agent.) Para obtener más información, consulte [Búsqueda de AMIs con SSM Agent preinstalado](ami-preinstalled-agent.md).
+ Para las instancias de Amazon Elastic Compute Cloud (Amazon EC2), debe adjuntar un perfil de instancias de AWS Identity and Access Management (IAM) a la instancia. El perfil de instancias permite que la instancia se comunique con el servicio de Systems Manager. Si no asigna un perfil de instancias a la instancia, lo registra mediante una [activación híbrida](activations.md), lo que no es un escenario común.
+ SSM Agent debe poder conectarse a un punto de enlace de Systems Manager para registrarse en el servicio. A partir de entonces, el nodo administrado debe estar disponible para el servicio, lo que se confirma mediante el envío de una señal cada cinco minutos para verificar el estado de la instancia.
+ Cuando el estado de un nodo administrado sea `Connection Lost` durante al menos 30 días, es posible que el nodo deje de aparecer en la lista de la consola de Fleet Manager. Para que vuelva a aparecer en la lista, se debe resolver el problema que haya provocado la pérdida de conexión.
Después de verificar que se está ejecutando un nodo administrado, puede utilizar el siguiente comando para verificar si SSM Agent se ha registrado correctamente con el servicio de Systems Manager. Este comando no devuelve resultados hasta que se haya realizado un registro correcto.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-associations-status \
--instance-id instance-id
```
------
#### [ Windows ]
```
aws ssm describe-instance-associations-status ^
--instance-id instance-id
```
------
#### [ PowerShell ]
```
Get-SSMInstanceAssociationsStatus `
-InstanceId instance-id
```
------
Si el registro se realizó correctamente y el nodo administrado ahora está disponible para las operaciones de Systems Manager, el comando devuelve resultados similares a los siguientes.
```
{
"InstanceAssociationStatusInfos": [
{
"AssociationId": "fa262de1-6150-4a90-8f53-d7eb5EXAMPLE",
"Name": "AWS-GatherSoftwareInventory",
"DocumentVersion": "1",
"AssociationVersion": "1",
"InstanceId": "i-02573cafcfEXAMPLE",
"Status": "Pending",
"DetailedStatus": "Associated"
},
{
"AssociationId": "f9ec7a0f-6104-4273-8975-82e34EXAMPLE",
"Name": "AWS-RunPatchBaseline",
"DocumentVersion": "1",
"AssociationVersion": "1",
"InstanceId": "i-02573cafcfEXAMPLE",
"Status": "Queued",
"AssociationName": "SystemAssociationForScanningPatches"
}
]
}
```
Si el registro aún no se ha completado o no se ejecuta de manera correcta, el comando devuelve resultados similares a los siguientes:
```
{
"InstanceAssociationStatusInfos": []
}
```
Si el comando no devuelve resultados después de 5 minutos, utilice la siguiente información para que lo ayude a solucionar problemas con los nodos administrados.
**Topics**
+ [Solución 1: comprobar que el SSM Agent está instalado y ejecutándose en el nodo administrado](#instances-missing-solution-1)
+ [Solución 2: comprobar que se ha especificado un perfil de instancias de IAM para la instancia (solo instancias de EC2)](#instances-missing-solution-2)
+ [Solución 3: verificar la conectividad de los puntos de enlace de servicio](#instances-missing-solution-3)
+ [Solución 4: verificar la compatibilidad con el sistema operativo de destino](#instances-missing-solution-4)
+ [Solución 5: verificar que está trabajando en la misma Región de AWS que la instancia de Amazon EC2](#instances-missing-solution-5)
+ [Solución 6: comprobar la configuración del proxy que aplicó a SSM Agent en el nodo administrado](#instances-missing-solution-6)
+ [Solución 7: instalar un certificado TLS en instancias administradas](#hybrid-tls-certificate)
+ [Solución de problemas de disponibilidad de nodos administrados mediante `ssm-cli`](troubleshooting-managed-nodes-using-ssm-cli.md)
## Solución 1: comprobar que el SSM Agent está instalado y ejecutándose en el nodo administrado
Asegúrese de que la versión más reciente de SSM Agent está instalada y ejecutándose en el nodo administrado.
Para determinar si SSM Agent está instalado y ejecutándose en un nodo administrado, consulte [Verificación del estado de SSM Agent e inicio del agente](ssm-agent-status-and-restart.md).
Para instalar o reinstalar SSM Agent en un nodo administrado, consulte los siguientes temas:
+ [Instalación y desinstalación manual de SSM Agent en instancias de EC2 para Linux](manually-install-ssm-agent-linux.md)
+ [Cómo instalar SSM Agent en nodos de Linux híbridos](hybrid-multicloud-ssm-agent-install-linux.md)
+ [Cómo instalar y desinstalar de forma manual SSM Agent en instancias de EC2 para Windows Server](manually-install-ssm-agent-windows.md)
+ [Cómo instalar SSM Agent en nodos de Windows híbridos](hybrid-multicloud-ssm-agent-install-windows.md)
## Solución 2: comprobar que se ha especificado un perfil de instancias de IAM para la instancia (solo instancias de EC2)
Para instancias de Amazon Elastic Compute Cloud (Amazon EC2), compruebe que la instancia está configurada con un perfil de instancias de AWS Identity and Access Management (IAM) que permite que la instancia se comunique con la API de Systems Manager. Verifique también que su usuario tenga una política de confianza de IAM que le permita comunicarse con la API de Systems Manager.
**nota**
Los servidores locales, los dispositivos de borde y las máquinas virtuales utilizan un rol de servicio de IAM en lugar de un perfil de instancias. Para obtener más información, consulte [Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube](hybrid-multicloud-service-role.md).
**Para determinar si un perfil de instancias con los permisos necesarios está adjuntado a una instancia de EC2**
1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. En el panel de navegación, seleccione **Instances (Instancias)**.
1. Elija la instancia que desea verificar para un perfil de instancias.
1. En la pestaña **Descripción** en el panel inferior, busque **Rol de IAM** y elija el nombre del rol.
1. En la página **Resumen** del rol para el perfil de instancia, en la pestaña **Permisos**, asegúrese de que `AmazonSSMManagedInstanceCore` se encuentre en la lista de **Políticas de permisos**.
Si, en su lugar, se utiliza una política personalizada, asegúrese de que proporcione los mismos permisos que `AmazonSSMManagedInstanceCore`.
[Abra `AmazonSSMManagedInstanceCore` en la consola](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore$jsonEditor)
Para obtener información sobre otras políticas que se pueden asociar a un perfil de instancia para Systems Manager, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md).
## Solución 3: verificar la conectividad de los puntos de enlace de servicio
Compruebe que la instancia tenga conectividad con los puntos de enlace de servicio de Systems Manager. Esta conectividad se proporciona creando y configurando puntos de enlace de la VPC para Systems Manager, o permitiendo el tráfico saliente HTTPS (puerto 443) a los puntos de enlace de servicio.
Para las instancias de Amazon EC2, el punto de conexión de servicio de Systems Manager para la Región de AWS se utiliza para registrar la instancia si la configuración de la nube privada virtual (VPC) permite el tráfico saliente. Sin embargo, si la configuración de la VPC en la que se lanzó la instancia no permite el tráfico saliente y no puede cambiar esta configuración para permitir la conectividad con los puntos de enlace de servicio públicos, configure los puntos de enlace de interfaz para la VPC.
Para obtener más información, consulte [Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager](setup-create-vpc.md).
## Solución 4: verificar la compatibilidad con el sistema operativo de destino
Compruebe que la operación que eligió se pueda ejecutar en el tipo de nodo administrado que espera ver en la lista. Algunas operaciones de Systems Manager solo pueden dirigirse a instancias de Windows o a instancias de Linux. Por ejemplo, los documentos de Systems Manager (SSM) `AWS-InstallPowerShellModule` y `AWS-ConfigureCloudWatch` solo se puede ejecutar en las instancias de Windows. En la página **Ejecutar un comando**, si elige cualquiera de estos documentos y selecciona **Elegir instancias manualmente**, solo se muestran las instancias de Windows que están disponibles para su selección.
## Solución 5: verificar que está trabajando en la misma Región de AWS que la instancia de Amazon EC2
Las instancias de Amazon EC2 se crean y están disponibles en Regiones de AWS específicas, como la Región Este de EE. UU. (Ohio) (us-east-2) o la Región Europa (Irlanda) (eu-west-1). Asegúrese de que trabaja en la misma Región de AWS que la instancia de Amazon EC2 con la que desea trabajar. Para obtener más información, consulte [Elegir una región](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html#select-region) en la *Introducción a la Consola de administración de AWS*.
## Solución 6: comprobar la configuración del proxy que aplicó a SSM Agent en el nodo administrado
Verifique que la configuración del proxy que aplicó a SSM Agent en el nodo administrado sea correcta. Si la configuración del proxy es incorrecta, el nodo no puede conectarse a los puntos de conexión de servicio requeridos o es posible que Systems Manager identifique incorrectamente el sistema operativo del nodo administrado. Para obtener más información, consulte [Configuración de SSM Agent para utilizar un proxy en nodos de Linux](configure-proxy-ssm-agent.md) y [Configurar el SSM Agent para usar un proxy para las instancias de Windows Server](configure-proxy-ssm-agent-windows.md).
## Solución 7: instalar un certificado TLS en instancias administradas
Se debe instalar un certificado de Seguridad de la capa de transporte (TLS) en cada instancia administrada que utiliza con AWS Systems Manager. Los Servicios de AWS utilizan estos certificados para cifrar llamadas a otros Servicios de AWS.
Un certificado TLS ya está instalado de forma predeterminada en cada instancia de Amazon EC2 creada a partir de una Amazon Machine Image (AMI). La mayoría de los sistemas operativos modernos incluyen el certificado TLS necesario de las entidades de certificación (CA) de Amazon Trust Services en su almacén de confianza.
Para comprobar si el certificado requerido está instalado en la instancia, ejecute el comando siguiente basado en el sistema operativo de la instancia. Asegúrese de sustituir la parte de la *región* de la URL con la Región de AWS en la que se encuentra la instancia administrada.
------
#### [ Linux & macOS ]
```
curl -L https://ssm.region.amazonaws.com
```
------
#### [ Windows ]
```
Invoke-WebRequest -Uri https://ssm.region.amazonaws.com
```
------
El comando debe devolver un error `UnknownOperationException`. Si en su lugar recibe un mensaje de error SSL/TLS, es posible que el certificado requerido no esté instalado.
Si descubre que los certificados de CA de Amazon Trust Services necesarios no están instalados en sus sistemas operativos principales, en las instancias creadas a partir de AMIs que no han sido suministradas por Amazon o en sus propios servidores locales y máquinas virtuales, debe instalar y permitir un certificado de [Amazon Trust Services](https://www.amazontrust.com/repository/) o usar AWS Certificate Manager (ACM) para crear y administrar certificados para un servicio integrado compatible.
Todas las instancias administradas deben tener instalado uno de los siguientes certificados Transport Layer Security (TLS).
+ Amazon Root CA 1
+ Starfield Services Root Certificate Authority - G2
+ Starfield Class 2 Certificate Authority
Para obtener información sobre ACM, consulte la *[Guía del usuario de AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/)*.
Si los certificados de su entorno informático se administran por medio de un objeto de política de grupo (GPO), es posible que tenga que configurar la política de grupo para que incluya uno de estos certificados.
Para obtener más información acerca de los certificados Root y Starfield de Amazon, consulte la publicación del blog [How to Prepare for AWS’s Move to Its Own Certificate Authority](https://aws.amazon.com/blogs/security/how-to-prepare-for-aws-move-to-its-own-certificate-authority/).
# Solución de problemas de disponibilidad de nodos administrados mediante `ssm-cli`
La `ssm-cli` es una herramienta de la línea de comandos independiente incluida en la instalación de SSM Agent. Al instalar SSM Agent 3.1.501.0 o una versión posterior en un equipo, puede ejecutar comandos `ssm-cli` en ese equipo. El resultado de estos comandos lo ayuda a determinar si el equipo cumple con los requisitos mínimos para que AWS Systems Manager administre una instancia de Amazon EC2 o un equipo que no sea de EC2 y que, por lo tanto, se agregue a listas de nodos administrados de Systems Manager. (La versión 3.1.501.0 de SSM Agent se publicó en noviembre de 2021).
**Requisitos mínimos**
Para que AWS Systems Manager administre una instancia de Amazon EC2 o un equipo que no sea de EC2, y que estos estén disponibles en listas de nodos administrados, se deben cumplir tres requisitos principales:
+ SSM Agent debe estar instalado y ejecutándose en un equipo con un [sistema operativo compatible](operating-systems-and-machine-types.md#prereqs-operating-systems).
Algunas Amazon Machine Images (AMIs) administradas de AWS para EC2 están configuradas para lanzar instancias con [SSM Agent](ssm-agent.md) preinstalado. (También puede configurar una AMI personalizada para la preinstalación de SSM Agent.) Para obtener más información, consulte [Búsqueda de AMIs con SSM Agent preinstalado](ami-preinstalled-agent.md).
+ Debe asociarse al equipo un perfil de instancia de AWS Identity and Access Management (IAM) (para instancias de EC2) o un rol de servicio de IAM (para equipos que no sean de EC2) que proporcione los permisos necesarios para comunicarse con el servicio de Systems Manager.
+ SSM Agent debe poder conectarse a un punto de conexión de Systems Manager para registrarse en el servicio. A partir de entonces, el nodo administrado debe estar disponible para el servicio, lo que se confirma mediante el envío de una señal cada cinco minutos para verificar el estado del nodo administrado.
**Comandos preconfigurados en `ssm-cli`**
Se incluyen comandos preconfigurados que recopilan la información necesaria para ayudarlo a diagnosticar por qué un equipo que ha confirmado que se está ejecutando no está incluido en las listas de nodos administrados de Systems Manager. Estos comandos se ejecutan cuando se especifica la opción `get-diagnostics`.
En el equipo, ejecute el siguiente comando para utilizar `ssm-cli` como ayuda para solucionar problemas de disponibilidad del nodo administrado.
------
#### [ Linux & macOS ]
```
ssm-cli get-diagnostics --output table
```
------
#### [ Windows ]
En equipos de Windows Server, debe dirigirse al directorio `C:\Program Files\Amazon\SSM` antes de ejecutar el comando.
```
ssm-cli.exe get-diagnostics --output table
```
------
#### [ PowerShell ]
En equipos de Windows Server, debe dirigirse al directorio `C:\Program Files\Amazon\SSM` antes de ejecutar el comando.
```
.\ssm-cli.exe get-diagnostics --output table
```
------
El comando devuelve el resultado en formato de tabla similar al siguiente.
**nota**
Las comprobaciones de conectividad a los puntos de conexión `ssmmessages`, `s3`, `kms`, `logs` y `monitoring` son para características opcionales adicionales, tales como Session Manager, que pueden registrarse en Amazon Simple Storage Service (Amazon S3) o los Registros de Amazon CloudWatch, y utilizar el cifrado de AWS Key Management Service (AWS KMS).
------
#### [ Linux & macOS ]
```
[root@instance]# ssm-cli get-diagnostics --output table
┌───────────────────────────────────────┬─────────┬───────────────────────────────────────────────────────────────────────┐
│ Check │ Status │ Note │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ EC2 IMDS │ Success │ IMDS is accessible and has instance id i-0123456789abcdefa in Region │
│ │ │ us-east-2 │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Hybrid instance registration │ Skipped │ Instance does not have hybrid registration │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssm endpoint │ Success │ ssm.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ec2messages endpoint │ Success │ ec2messages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssmmessages endpoint │ Success │ ssmmessages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to s3 endpoint │ Success │ s3.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to kms endpoint │ Success │ kms.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to logs endpoint │ Success │ logs.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Connectivity to monitoring endpoint │ Success │ monitoring.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ AWS Credentials │ Success │ Credentials are for │
│ │ │ arn:aws:sts::123456789012:assumed-role/Fullaccess/i-0123456789abcdefa │
│ │ │ and will expire at 2021-08-17 18:47:49 +0000 UTC │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Agent service │ Success │ Agent service is running and is running as expected user │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ Proxy configuration │ Skipped │ No proxy configuration detected │
├───────────────────────────────────────┼─────────┼───────────────────────────────────────────────────────────────────────┤
│ SSM Agent version │ Success │ SSM Agent version is 3.0.1209.0, latest available agent version is │
│ │ │ 3.1.192.0 │
└───────────────────────────────────────┴─────────┴───────────────────────────────────────────────────────────────────────┘
```
------
#### [ Windows Server and PowerShell ]
```
PS C:\Program Files\Amazon\SSM> .\ssm-cli.exe get-diagnostics --output table
┌───────────────────────────────────────┬─────────┬─────────────────────────────────────────────────────────────────────┐
│ Check │ Status │ Note │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ EC2 IMDS │ Success │ IMDS is accessible and has instance id i-0123456789EXAMPLE in │
│ │ │ Region us-east-2 │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Hybrid instance registration │ Skipped │ Instance does not have hybrid registration │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssm endpoint │ Success │ ssm.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ec2messages endpoint │ Success │ ec2messages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to ssmmessages endpoint │ Success │ ssmmessages.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to s3 endpoint │ Success │ s3.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to kms endpoint │ Success │ kms.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to logs endpoint │ Success │ logs.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Connectivity to monitoring endpoint │ Success │ monitoring.us-east-2.amazonaws.com is reachable │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ AWS Credentials │ Success │ Credentials are for │
│ │ │ arn:aws:sts::123456789012:assumed-role/SSM-Role/i-123abc45EXAMPLE │
│ │ │ and will expire at 2021-09-02 13:24:42 +0000 UTC │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Agent service │ Success │ Agent service is running and is running as expected user │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Proxy configuration │ Skipped │ No proxy configuration detected │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ Windows sysprep image state │ Success │ Windows image state value is at desired value IMAGE_STATE_COMPLETE │
├───────────────────────────────────────┼─────────┼─────────────────────────────────────────────────────────────────────┤
│ SSM Agent version │ Success │ SSM Agent version is 3.2.815.0, latest agent version in us-east-2 │
│ │ │ is 3.2.985.0 │
└───────────────────────────────────────┴─────────┴─────────────────────────────────────────────────────────────────────┘
```
------
En la siguiente tabla se proporcionan detalles adicionales para cada una de las verificaciones realizadas por `ssm-cli`.
**`ssm-cli`Verificaciones de diagnóstico de**
| Check | Details |
| --- | --- |
| Servicio de metadatos de la instancia de Amazon EC2 | Indica si el nodo administrado puede acceder al servicio de metadatos. Una prueba fallida indica un problema de conectividad con http://169.254.169.254, que puede deberse a configuraciones de firewall y proxy de la ruta local, el proxy o el sistema operativo (SO). |
| Registro de instancias híbridas | Indica si SSM Agent está registrado mediante una activación híbrida. |
| Conectividad al punto de conexión ssm | Indica si el nodo puede acceder a los puntos de conexión de servicio de Systems Manager en el puerto TCP 443. Una prueba fallida indica problemas de conectividad con https://ssm.region.amazonaws.com en función de la Región de AWS donde se encuentra el nodo. Los problemas de conectividad se pueden deber a la configuración de la VPC, incluidos grupos de seguridad, listas de control de acceso a la red, tablas de enrutamiento o firewalls y proxies del SO. |
| Conectividad al punto de conexión ec2messages | Indica si el nodo puede acceder a los puntos de conexión de servicio de Systems Manager en el puerto TCP 443. Una prueba fallida indica problemas de conectividad con https://ec2messages.region.amazonaws.com en función de la Región de AWS donde se encuentra el nodo. Los problemas de conectividad se pueden deber a la configuración de la VPC, incluidos grupos de seguridad, listas de control de acceso a la red, tablas de enrutamiento o firewalls y proxies del SO. |
| Conectividad al punto de conexión ssmmessages | Indica si el nodo puede acceder a los puntos de conexión de servicio de Systems Manager en el puerto TCP 443. Una prueba fallida indica problemas de conectividad con https://ssmmessages.region.amazonaws.com en función de la Región de AWS donde se encuentra el nodo. Los problemas de conectividad se pueden deber a la configuración de la VPC, incluidos grupos de seguridad, listas de control de acceso a la red, tablas de enrutamiento o firewalls y proxies del SO. |
| Conectividad al punto de conexión s3 | Indica si el nodo puede acceder al punto de conexión de servicio de Amazon Simple Storage Service en el puerto TCP 443. Una prueba fallida indica problemas de conectividad con https://s3.region.amazonaws.com en función de la Región de AWS donde se encuentra el nodo. No es necesaria la conectividad a este punto de conexión para que un nodo aparezca en la lista de nodos administrados. |
| Conectividad al punto de conexión kms | Indica si el nodo puede acceder al punto de conexión de servicio de AWS Key Management Service en el puerto TCP 443. Una prueba fallida indica problemas de conectividad con `https://kms.region.amazonaws.com` en función de la Región de AWS donde se encuentra el nodo. No es necesaria la conectividad a este punto de conexión para que un nodo aparezca en la lista de nodos administrados. |
| Conectividad al punto de conexión logs | Indica si el nodo puede acceder al punto de conexión de servicio de Registros de Amazon CloudWatch en el puerto TCP 443. Una prueba fallida indica problemas de conectividad con https://logs.region.amazonaws.com en función de la Región de AWS donde se encuentra el nodo. No es necesaria la conectividad a este punto de conexión para que un nodo aparezca en la lista de nodos administrados. |
| Conectividad al punto de conexión monitoring | Indica si el nodo puede acceder al punto de conexión de servicio de Amazon CloudWatch en el puerto TCP 443. Una prueba fallida indica problemas de conectividad con https://monitoring.region.amazonaws.com en función de la Región de AWS donde se encuentra el nodo. No es necesaria la conectividad a este punto de conexión para que un nodo aparezca en la lista de nodos administrados. |
| AWSCredenciales de | Indica si SSM Agent tiene las credenciales necesarias en función del perfil de instancia de IAM (para instancias de EC2) o el rol de servicio de IAM (para equipos que no sean de EC2) asociadas al equipo. Una prueba fallida indica que no hay un perfil de instancia de IAM o un rol de servicio de IAM asociado al equipo o que no contiene los permisos necesarios para Systems Manager. |
| Servicio de agente | Indica si el servicio de SSM Agent se está ejecutando y si se ejecuta como raíz para Linux o macOS, o como SYSTEM para Windows Server. Una prueba fallida indica que el servicio de SSM Agent no se está ejecutando o no se ejecuta como raíz o SYSTEM. |
| Configuración del proxy | Indica si SSM Agent está configurado para utilizar un proxy. |
| Estado de imagen de Sysprep (solo Windows) | Indica el estado de Sysprep en el nodo. SSM Agent no iniciará en el nodo si el estado de Sysprep es un valor distinto a IMAGE\$1STATE\$1COMPLETE. |
| SSM AgentVersión | Indica si está instalada la versión más reciente disponible de SSM Agent. |
# Activaciones híbridas de AWS Systems Manager
Para configurar máquinas que no son de EC2 para su uso con AWS Systems Manager en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types), debe crear una *activación híbrida*. Los tipos de máquinas que no son de EC2 y que se admiten como nodos administrados son los siguientes:
+ Servidores en sus propias instalaciones (servidores en las instalaciones)
+ Dispositivos de núcleo de AWS IoT Greengrass
+ Dispositivos de AWS IoT y periféricos que no sean de AWS
+ Máquinas virtuales (VM), incluidas las VM de otros entornos de nube
Cuando ejecuta el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html) para iniciar un proceso de activación híbrida, recibe un código de activación y un ID en la respuesta del comando. A continuación, debe incluir el código y el ID de activación junto con el comando para instalar SSM Agent en la máquina, tal y como se describe en el paso 3 de [Instalar SSM Agent en nodos de Linux híbridos](hybrid-multicloud-ssm-agent-install-linux.md) y el paso 4 de [Instalación de SSM Agent en nodos híbridos de Windows Server](hybrid-multicloud-ssm-agent-install-windows.md).
Este proceso de activación se aplica a todos los tipos de máquinas que no son de EC2, *excepto* a los dispositivos de AWS IoT Greengrass principales. Para obtener información acerca de cómo configurar dispositivos de núcleo de AWS IoT Greengrass para Systems Manager, consulte [Administración de dispositivos periféricos con Systems Manager](systems-manager-setting-up-edge-devices.md).
**nota**
Por el momento, no se proporciona soporte para máquinas con macOS que no sean de EC2.
**Acerca de los niveles de instancias de Systems Manager**
AWS Systems Manager ofrece un nivel de instancias estándares y un nivel de instancias avanzadas. Ambos admiten nodos administrados en su entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). El nivel de instancias estándar le permite registrar un máximo de 1000 máquinas por Cuenta de AWS por Región de AWS. Si tiene que registrar más de 1000 máquinas en una única cuenta y región, utilice el nivel de instancias avanzadas. Puede crear tantos nodos administrados como desee en el nivel de instancias avanzadas. Todos los nodos administrados configurados para Systems Manager tienen un precio de pago por uso. Para obtener más información acerca de la habilitación del nivel de instancias avanzadas, consulte [Activación del nivel de instancias avanzadas](fleet-manager-enable-advanced-instances-tier.md). Para obtener más información sobre los precios, consulte [Precios de AWS Systems Manager](https://aws.amazon.com/systems-manager/pricing/).
Tenga en cuenta la siguiente información adicional acerca del nivel de instancias estándar y el nivel de instancias avanzadas:
+ Las instancias avanzadas también permiten conectar a los nodos que no son de EC2 a un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) mediante AWS Systems Manager Session Manager. Session Manager proporciona acceso a las instancias mediante el intérprete de comandos interactivo. Para obtener más información, consulte [AWS Systems Manager Session Manager](session-manager.md).
+ La cuota de instancias estándar también se aplica a las instancias EC2 que utilizan una activación local de Systems Manager (que no es un escenario común).
+ Para aplicar revisiones a las aplicaciones publicadas por Microsoft en instancias locales de máquinas virtuales, active el nivel de instancias avanzadas. El uso del nivel de instancias avanzadas conlleva un cargo. No hay ningún cargo adicional por usar revisiones en las aplicaciones publicadas por Microsoft en instancias de Amazon Elastic Compute Cloud (Amazon EC2). Para obtener más información, consulte [Revisiones de aplicaciones publicadas por Microsoft en Windows Server](patch-manager-patching-windows-applications.md).
# Inventario de AWS Systems Manager
AWS Systems Manager Inventory ofrece visibilidad en su entorno informático de AWS. Puede utilizar Inventory para recopilar *metadatos* de los nodos administrados. Puede almacenar estos metadatos en un bucket de Amazon Simple Storage Service (Amazon S3) central y, a continuación, utilizar las herramientas integradas para consultar los datos y determinar rápidamente qué nodos ejecutan el software y las configuraciones requeridas por la política de software, así como los nodos que deben actualizarse. Puede configurar Inventory en todos los nodos administrados mediante un procedimiento de un solo clic. También puede configurar y ver los datos de inventario de varias Regiones de AWS y Cuentas de AWS cuando utiliza Amazon Athena. Para comenzar a utilizar Inventory, abra la [consola de Systems Manager](https://console.aws.amazon.com//systems-manager/inventory). En el panel de navegación, elija **Inventory**.
Si los tipos de metadatos preconfigurados recopilados por Systems Manager Inventory no se adaptan a sus necesidades, puede crear un inventario personalizado. Un inventario personalizado es simplemente un archivo JSON con información proporcionada y agregada por usted al nodo administrado en un directorio específico. Cuando Systems Manager Inventory recopila datos, captura estos datos de inventario personalizados. Por ejemplo, si ejecuta un gran centro de datos, puede especificar la ubicación de bastidor de cada servidor como un inventario personalizado. Una vez hecho esto, podrá ver los datos del espacio del bastidor al visualizar otros datos de inventario.
**importante**
Systems Manager Inventory *solo* recopila metadatos de los nodos administrados. Inventory no tiene acceso a información o datos privados.
En la siguiente tabla, se muestran los tipos de datos que puede recopilar con Systems Manager Inventory. La tabla también describe las diferentes ofertas para dirigirse a nodos y los intervalos de recopilación que puede especificar.
****
| Configuración | Detalles |
| --- | --- |
| Tipos de metadatos | Puede configurar Inventory para que recopile los siguientes tipos de datos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/systems-manager-inventory.html) Para ver una lista de todos los metadatos que Inventory ha recopilado, consulte [Metadatos recopilados por Inventory](inventory-schema.md). |
| Nodos a los que dirigirse | Puede elegir inventariar todos los nodos administrados de la Cuenta de AWS, seleccionar nodos individualmente o dirigirse a grupos de nodos mediante etiquetas. Para obtener más información sobre cómo recopilar datos de inventario de todos los nodos administrados, consulte [Inventario de todos los nodos administrados de la Cuenta de AWS](inventory-collection.md#inventory-management-inventory-all). |
| Cuándo recopilar la información | Puede especificar un intervalo de recopilación en términos de minutos, horas y días. El intervalo de recopilación más corto es cada 30 minutos. |
**nota**
Dependiendo de la cantidad de datos recopilados, el sistema puede tardar varios minutos para informar de los datos a la salida especificada. Después de haber recopilado la información, los datos se envían a través de un canal HTTPS seguro a un almacén de AWS de texto sin formato que solo es accesible desde su Cuenta de AWS.
Puede ver los datos en la consola de Systems Manager, en la página **Inventory**, que incluye diferentes tarjetas predefinidas para ayudarlo a consultar los datos.
![\[Tarjetas de Systems Manager Inventory en la consola de Systems Manager.\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-cards.png)
**nota**
Las tarjetas de Inventory filtran automáticamente las instancias administradas de Amazon EC2 con los estados *Terminated* (Terminado) y *Stopped* (Detenido). Para los nodos administrados locales y de dispositivos de núcleo de AWS IoT Greengrass, las tarjetas de Inventory filtran automáticamente los nodos con el estado *Terminated* (Terminado).
Si crea una sincronización de datos de recursos para sincronizar y almacenar todos los datos en un solo bucket de Amazon S3, puede desglosar los datos en la página **Inventory Detailed View** (Vista detallada de inventario). Para obtener más información, consulte [Consulta de datos de Inventory de varias regiones y cuentas](systems-manager-inventory-query.md).
**Compatibilidad con EventBridge**
Esta herramienta de Systems Manager se admite como un tipo de *evento* en las reglas de Amazon EventBridge. Para obtener más información, consulte [Cómo monitorear eventos de Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md) y [Referencia: patrones y tipos de eventos de Amazon EventBridge para Systems Manager](reference-eventbridge-events.md).
**Topics**
+ [Más información acerca de Systems Manager Inventory](inventory-about.md)
+ [Configuración de Systems Manager Inventory](systems-manager-inventory-setting-up.md)
+ [Configuración de la recopilación de inventario](inventory-collection.md)
+ [Consulta de datos de Inventory de varias regiones y cuentas](systems-manager-inventory-query.md)
+ [Consulta de una recopilación de inventario mediante filtros](inventory-query-filters.md)
+ [Agregación de datos de Inventory](inventory-aggregate.md)
+ [Uso del inventario personalizado](inventory-custom.md)
+ [Visualización del seguimiento de cambios y del historial de Inventory](inventory-history.md)
+ [Cómo detener la recopilación de datos y eliminación de datos de inventario](systems-manager-inventory-delete.md)
+ [Asignación de metadatos de inventarios personalizados a un nodo administrado](inventory-custom-metadata.md)
+ [Uso de la AWS CLI para configurar la recopilación de datos de inventario](inventory-collection-cli.md)
+ [Explicación: cómo utilizar la sincronización de datos de recursos para agregar datos de inventario](inventory-resource-data-sync.md)
+ [Solución de problemas con Systems Manager Inventory](syman-inventory-troubleshooting.md)
# Más información acerca de Systems Manager Inventory
Al configurar AWS Systems Manager Inventory, debe especificar el tipo de metadatos que se van a recopilar, los nodos administrados de los que deben recopilarse los metadatos y una programación de recopilación de metadatos. Estas configuraciones se guardan con la Cuenta de AWS como una asociación de AWS Systems Manager State Manager. Una asociación no es más que una configuración.
**nota**
Inventory solo recopila metadatos. No recopila los datos personales o privados.
**Topics**
+ [Metadatos recopilados por Inventory](inventory-schema.md)
+ [Uso del inventario de archivos y del registro de Windows](inventory-file-and-registry.md)
# Metadatos recopilados por Inventory
En el siguiente ejemplo se muestra la lista completa de los metadatos que cada complemento de AWS Systems Manager Inventory recopila.
```
{
"typeName": "AWS:InstanceInformation",
"version": "1.0",
"attributes":[
{ "name": "AgentType", "dataType" : "STRING"},
{ "name": "AgentVersion", "dataType" : "STRING"},
{ "name": "ComputerName", "dataType" : "STRING"},
{ "name": "InstanceId", "dataType" : "STRING"},
{ "name": "IpAddress", "dataType" : "STRING"},
{ "name": "PlatformName", "dataType" : "STRING"},
{ "name": "PlatformType", "dataType" : "STRING"},
{ "name": "PlatformVersion", "dataType" : "STRING"},
{ "name": "ResourceType", "dataType" : "STRING"},
{ "name": "AgentStatus", "dataType" : "STRING"},
{ "name": "InstanceStatus", "dataType" : "STRING"}
]
},
{
"typeName" : "AWS:Application",
"version": "1.1",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "Release", "dataType": "STRING"},
{ "name": "Epoch", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"},
{ "name": "Summary", "dataType": "STRING"},
{ "name": "PackageId", "dataType": "STRING"}
]
},
{
"typeName" : "AWS:File",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Size", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "FileVersion", "dataType": "STRING"},
{ "name": "InstalledDate", "dataType": "STRING"},
{ "name": "ModificationTime", "dataType": "STRING"},
{ "name": "LastAccessTime", "dataType": "STRING"},
{ "name": "ProductName", "dataType": "STRING"},
{ "name": "InstalledDir", "dataType": "STRING"},
{ "name": "ProductLanguage", "dataType": "STRING"},
{ "name": "CompanyName", "dataType": "STRING"},
{ "name": "ProductVersion", "dataType": "STRING"}
]
},
{
"typeName": "AWS:AWSComponent",
"version": "1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "ApplicationType", "dataType": "STRING"},
{ "name": "Publisher", "dataType": "STRING"},
{ "name": "Version", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "Architecture", "dataType": "STRING"},
{ "name": "URL", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsUpdate",
"version":"1.0",
"attributes":[
{ "name": "HotFixId", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstalledBy", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Network",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "SubnetMask", "dataType": "STRING"},
{ "name": "Gateway", "dataType": "STRING"},
{ "name": "DHCPServer", "dataType": "STRING"},
{ "name": "DNSServer", "dataType": "STRING"},
{ "name": "MacAddress", "dataType": "STRING"},
{ "name": "IPV4", "dataType": "STRING"},
{ "name": "IPV6", "dataType": "STRING"}
]
},
{
"typeName": "AWS:PatchSummary",
"version":"1.0",
"attributes":[
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "BaselineId", "dataType": "STRING"},
{ "name": "SnapshotId", "dataType": "STRING"},
{ "name": "OwnerInformation", "dataType": "STRING"},
{ "name": "InstalledCount", "dataType": "NUMBER"},
{ "name": "InstalledPendingRebootCount", "dataType": "NUMBER"},
{ "name": "InstalledOtherCount", "dataType": "NUMBER"},
{ "name": "InstalledRejectedCount", "dataType": "NUMBER"},
{ "name": "NotApplicableCount", "dataType": "NUMBER"},
{ "name": "UnreportedNotApplicableCount", "dataType": "NUMBER"},
{ "name": "MissingCount", "dataType": "NUMBER"},
{ "name": "FailedCount", "dataType": "NUMBER"},
{ "name": "OperationType", "dataType": "STRING"},
{ "name": "OperationStartTime", "dataType": "STRING"},
{ "name": "OperationEndTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING"},
{ "name": "RebootOption", "dataType": "STRING"},
{ "name": "LastNoRebootInstallOperationTime", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING", "isOptional": "true"},
{ "name": "NonCompliantSeverity", "dataType": "STRING", "isOptional": "true"},
{ "name": "SecurityNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "CriticalNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"},
{ "name": "OtherNonCompliantCount", "dataType": "NUMBER", "isOptional": "true"}
]
},
{
"typeName": "AWS:PatchCompliance",
"version":"1.0",
"attributes":[
{ "name": "Title", "dataType": "STRING"},
{ "name": "KBId", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "State", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ComplianceItem",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionId", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionType", "dataType": "STRING", "isContext": "true"},
{ "name": "ExecutionTime", "dataType": "STRING", "isContext": "true"},
{ "name": "Id", "dataType": "STRING"},
{ "name": "Title", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "Severity", "dataType": "STRING"},
{ "name": "DocumentName", "dataType": "STRING"},
{ "name": "DocumentVersion", "dataType": "STRING"},
{ "name": "Classification", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "PatchSeverity", "dataType": "STRING"},
{ "name": "PatchState", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "InstalledTime", "dataType": "STRING"},
{ "name": "InstallOverrideList", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedText", "dataType": "STRING", "isOptional": "true"},
{ "name": "DetailedLink", "dataType": "STRING", "isOptional": "true"},
{ "name": "CVEIds", "dataType": "STRING", "isOptional": "true"}
]
},
{
"typeName": "AWS:ComplianceSummary",
"version":"1.0",
"attributes":[
{ "name": "ComplianceType", "dataType": "STRING"},
{ "name": "PatchGroup", "dataType": "STRING"},
{ "name": "PatchBaselineId", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "OverallSeverity", "dataType": "STRING"},
{ "name": "ExecutionId", "dataType": "STRING"},
{ "name": "ExecutionType", "dataType": "STRING"},
{ "name": "ExecutionTime", "dataType": "STRING"},
{ "name": "CompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "CompliantHighCount", "dataType": "NUMBER"},
{ "name": "CompliantMediumCount", "dataType": "NUMBER"},
{ "name": "CompliantLowCount", "dataType": "NUMBER"},
{ "name": "CompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "CompliantUnspecifiedCount", "dataType": "NUMBER"},
{ "name": "NonCompliantCriticalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantHighCount", "dataType": "NUMBER"},
{ "name": "NonCompliantMediumCount", "dataType": "NUMBER"},
{ "name": "NonCompliantLowCount", "dataType": "NUMBER"},
{ "name": "NonCompliantInformationalCount", "dataType": "NUMBER"},
{ "name": "NonCompliantUnspecifiedCount", "dataType": "NUMBER"}
]
},
{
"typeName": "AWS:InstanceDetailedInformation",
"version":"1.0",
"attributes":[
{ "name": "CPUModel", "dataType": "STRING"},
{ "name": "CPUCores", "dataType": "NUMBER"},
{ "name": "CPUs", "dataType": "NUMBER"},
{ "name": "CPUSpeedMHz", "dataType": "NUMBER"},
{ "name": "CPUSockets", "dataType": "NUMBER"},
{ "name": "CPUHyperThreadEnabled", "dataType": "STRING"},
{ "name": "OSServicePack", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Service",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "ServiceType", "dataType": "STRING"},
{ "name": "Status", "dataType": "STRING"},
{ "name": "DependentServices", "dataType": "STRING"},
{ "name": "ServicesDependedOn", "dataType": "STRING"},
{ "name": "StartType", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRegistry",
"version":"1.0",
"attributes":[
{ "name": "KeyPath", "dataType": "STRING"},
{ "name": "ValueName", "dataType": "STRING"},
{ "name": "ValueType", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:WindowsRole",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "DisplayName", "dataType": "STRING"},
{ "name": "Path", "dataType": "STRING"},
{ "name": "FeatureType", "dataType": "STRING"},
{ "name": "DependsOn", "dataType": "STRING"},
{ "name": "Description", "dataType": "STRING"},
{ "name": "Installed", "dataType": "STRING"},
{ "name": "InstalledState", "dataType": "STRING"},
{ "name": "SubFeatures", "dataType": "STRING"},
{ "name": "ServerComponentDescriptor", "dataType": "STRING"},
{ "name": "Parent", "dataType": "STRING"}
]
},
{
"typeName": "AWS:Tag",
"version":"1.0",
"attributes":[
{ "name": "Key", "dataType": "STRING"},
{ "name": "Value", "dataType": "STRING"}
]
},
{
"typeName": "AWS:ResourceGroup",
"version":"1.0",
"attributes":[
{ "name": "Name", "dataType": "STRING"},
{ "name": "Arn", "dataType": "STRING"}
]
},
{
"typeName": "AWS:BillingInfo",
"version": "1.0",
"attributes": [
{ "name": "BillingProductId", "dataType": "STRING"}
]
}
```
**nota**
Para `"typeName": "AWS:InstanceInformation"`, `InstanceStatus` puede ser uno de los siguientes: Activo, Conexión perdida, Detenido, Terminado.
Con el lanzamiento de la versión 2.5, RPM Package Manager sustituye el atributo Serial por Epoch. El atributo Epoch es un entero de incremento monotónico como Serial. Cuando se realiza el inventario mediante el tipo `AWS:Application`, un valor mayor de Epoch significa una versión más reciente. Si los valores de Epoch son los mismos o están en blanco, utilice el valor del atributo Version o Release para determinar la versión más reciente.
Algunos metadatos no están disponibles en las instancias de Linux. En concreto, en el caso de “typeName”: “AWS:Network”, los siguientes tipos de metadatos aún no son compatibles con las instancias de Linux. SON compatibles con Windows.
\$1 "name": "SubnetMask", "dataType": "STRING"\$1,
\$1 "name": "DHCPServer", "dataType": "STRING"\$1,
\$1 "name": "DHCPServer", "dataType": "STRING"\$1,
\$1 "name": "Gateway", "dataType": "STRING"\$1,
# Uso del inventario de archivos y del registro de Windows
AWS Systems Manager Inventory le permite buscar archivos en los sistemas operativos Windows Server, Linux y macOS, y realizar un inventario de estos. Asimismo puede realizar búsquedas en el registro de Windows e inventariarlo.
**Archivos**: puede recopilar información de los metadatos de los archivos, como los nombres de los archivos, la hora en que se crearon, la hora de la última modificación y del último acceso y los tamaños de los archivos, por solo citar algunos ejemplos. Para comenzar a recopilar el inventario de archivos, debe especificar una ruta de archivo donde desee realizar el inventario, uno o varios patrones que definan los tipos de archivos que desee inventariar y si la ruta debe atravesarse recursivamente. Systems Manager realiza inventarios de todos los metadatos de los archivos de la ruta especificada que coinciden con el patrón. El inventario de archivos utiliza la entrada de parámetro siguiente.
```
{
"Path": string,
"Pattern": array[string],
"Recursive": true,
"DirScanLimit" : number // Optional
}
```
+ **Ruta**: la ruta del directorio donde desee inventariar los archivos. En el caso de Windows puede utilizar variables de entorno como `%PROGRAMFILES% ` siempre y cuando la variable se asocie a una única ruta de directorio. Por ejemplo, si utiliza la variable %PATH% que está asociada a varias rutas de directorio, Inventory genera un error.
+ **Patrón**: matriz de patrones para identificar archivos.
+ **Recursivo**: valor booleano que indica si Inventory debe atravesar recursivamente los directorios.
+ **DirScanLimit**: valor opcional que especifica cuántos directorios deben examinarse. Use este parámetro para minimizar el impacto en el rendimiento de los nodos administrados. Inventory examina un máximo de 5.000 directorios.
**nota**
Inventory recopila metadatos para un máximo de 500 archivos en todas las rutas especificadas.
A continuación, mostramos algunos ejemplos de cómo especificar los parámetros al realizar un inventario de archivos.
+ En Linux y macOS, recopile metadatos de los archivos .sh en el directorio `/home/ec2-user` y excluya todos los subdirectorios.
```
[{"Path":"/home/ec2-user","Pattern":["*.sh", "*.sh"],"Recursive":false}]
```
+ En Windows recopile metadatos de todos los archivos ".exe" de la carpeta Archivos de programa e incluya los subdirectorios de forma recursiva.
```
[{"Path":"C:\Program Files","Pattern":["*.exe"],"Recursive":true}]
```
+ En Windows recopile metadatos de patrones de log específicos.
```
[{"Path":"C:\ProgramData\Amazon","Pattern":["*amazon*.log"],"Recursive":true}]
```
+ Limite el número de directorios cuando ejecute una recopilación recursiva.
```
[{"Path":"C:\Users","Pattern":["*.ps1"],"Recursive":true, "DirScanLimit": 1000}]
```
**Registro de Windows**: puede recopilar claves y valores de registro de Windows. Puede elegir una ruta de clave y recopilar todas las claves y valores recursivamente. También puede recopilar una clave de registro específica y su valor para una ruta específica. El inventario recopila la ruta de clave, el nombre, el tipo y el valor.
```
{
"Path": string,
"Recursive": true,
"ValueNames": array[string] // optional
}
```
+ **Ruta**: la ruta de acceso a la clave de registro.
+ **Recursivo**: valor booleano que indica si Inventory debe atravesar recursivamente las rutas de registro.
+ **ValueNames**: matriz de nombres de valores para realizar un inventario de claves de registro. Si utiliza este parámetro, Systems Manager solo inventariará los nombres de valor especificados para la ruta especificada.
**nota**
Inventory recopila un máximo de 250 valores de clave de registro para todas las rutas especificadas.
A continuación, mostramos algunos ejemplos de cómo especificar los parámetros al realizar un inventario del registro de Windows.
+ Recopile todas las claves y los valores de una ruta específica de forma recursiva.
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon","Recursive": true}]
```
+ Recopile todas las claves y los valores de una ruta específica (la búsqueda recursiva está desactivada).
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Intel\PSIS\PSIS_DECODER", "Recursive": false}]
```
+ Recopile una clave específica utilizando la opción `ValueNames`.
```
{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\MachineImage","ValueNames":["AMIName"]}
```
# Configuración de Systems Manager Inventory
Antes de utilizar AWS Systems Manager Inventory para recopilar metadatos sobre las aplicaciones, los servicios y los componentes de AWS, entre otros, que se ejecutan en los nodos administrados, se recomienda configurar la sincronización de los datos de recursos para centralizar el almacenamiento de los datos de inventario en un único bucket de Amazon Simple Storage Service (Amazon S3). También le recomendamos que configure el monitoreo de eventos de inventario con Amazon EventBridge. Estos procesos facilitan la visualización y la administración de la recopilación y los datos de inventario.
**Topics**
+ [Cómo crear una sincronización de datos de recursos para Inventory](inventory-create-resource-data-sync.md)
+ [Uso de EventBridge para monitorear eventos de Inventory](systems-manager-inventory-setting-up-eventbridge.md)
# Cómo crear una sincronización de datos de recursos para Inventory
En este tema se describe cómo configurar y configurar la sincronización de datos de recursos para AWS Systems Manager Inventory. Para obtener información acerca de la sincronización de datos de recursos para Systems Manager Explorer, consulte [Configuración de Systems Manager Explorer para mostrar datos de varias cuentas y regiones](Explorer-resource-data-sync.md).
## Acerca de la sincronización de datos de recursos
Puede utilizar la sincronización de datos de recursos de Systems Manager para enviar datos de inventario recopilados de todos los nodos administrados a un solo bucket de Amazon Simple Storage Service (Amazon S3). A continuación, la sincronización de datos de recursos actualiza automáticamente los datos centralizados cuando se recopilan los nuevos datos de inventario. Con todos los datos de inventario almacenados en un bucket de Amazon S3 de destino, puede usar servicios como Amazon Athena y Amazon Quick para consultar y analizar los datos agregados.
Por ejemplo, digamos que ha configurado inventario para recopilar datos sobre el sistema operativo (SO) y las aplicaciones que se ejecutan en una flota de 150 nodos administrados. Algunos de estos nodos se encuentran en un centro de datos en las instalaciones y otros se ejecutan en Amazon Elastic Compute Cloud (Amazon EC2) en varias Regiones de AWS. Si *no* ha configurado la sincronización de datos de recursos, tendrá que reunir manualmente la recopilación de datos de inventario para cada nodo administrado o tendrá que crear scripts que recopilen esta información. Después tendrá que portar los datos a una aplicación para poder ejecutar consultas y analizarlas.
Con la sincronización de datos de recursos se lleva a cabo una única operación que sincroniza todos los datos de inventario de todos los nodos administrados. Después de haber creado correctamente la sincronización, Systems Manager crea una base de referencia de todos los datos de inventario y la guarda en el bucket de Amazon S3 de destino. Cuando se recopilen nuevos datos de inventario, Systems Manager actualizará automáticamente los datos en el bucket de Amazon S3. A continuación, puede transferir los datos a Amazon Athena y Amazon Quick de forma rápida y rentable.
En el diagrama 1, se muestra cómo la sincronización de datos de recursos agrega los datos de inventario de Amazon EC2 y otros tipos de equipos en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) a un bucket de Amazon S3 de destino. Dicho diagrama muestra también cómo funciona la sincronización de datos de recursos con varias Cuentas de AWS y Regiones de AWS.
**Diagrama 1: sincronización de datos de recursos con varias Cuentas de AWS y Regiones de AWS**
![\[Arquitectura de la sincronización de datos de recursos de Systems Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-resource-data-sync-updated.png)
Si elimina un nodo administrado, la sincronización de datos de recursos conserva el archivo de inventario del nodo eliminado. En el caso de los nodos en ejecución, la sincronización de datos de recursos, sin embargo, sobrescribe automáticamente los archivos de inventario antiguos cuando se crean y escriben archivos nuevos en el bucket de Amazon S3. Si desea realizar un seguimiento de los cambios de inventario con el paso del tiempo, puede utilizar el servicio AWS Config para realizar un seguimiento del tipo de recurso `SSM:ManagedInstanceInventory`. Para obtener más información, consulte [Introducción a AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html).
Utilice los procedimientos de esta sección para crear una sincronización de datos de recursos para Inventory mediante las consolas de Amazon S3 y AWS Systems Manager. También puede utilizar AWS CloudFormation para crear o eliminar una sincronización de datos de recursos. Para utilizar CloudFormation, agregue el recurso [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-resourcedatasync.html) a la plantilla de CloudFormation. Para obtener información, consulte uno de los siguientes recursos de documentación:
+ [AWS CloudFormation resource for resource data sync in AWS Systems Manager](https://aws.amazon.com/blogs/mt/aws-cloudformation-resource-for-resource-data-sync-in-aws-systems-manager/) (blog)
+ [Uso de plantillas de AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html) en la *Guía del usuario de AWS CloudFormation*
**nota**
Puede utilizar AWS Key Management Service (AWS KMS) para cifrar los datos de inventario en el bucket de Amazon S3. Si desea ver un ejemplo de cómo crear una sincronización cifrada con la AWS Command Line Interface (AWS CLI) y cómo trabajar con los datos centralizados en Amazon Athena y Amazon Quick, consulte [Explicación: cómo utilizar la sincronización de datos de recursos para agregar datos de inventario](inventory-resource-data-sync.md).
## Antes de empezar
Antes de crear una sincronización de datos de recursos, utilice el siguiente procedimiento para crear un bucket de Amazon S3 central para almacenar datos de inventario agregados. El procedimiento describe cómo asignar una política de bucket que permite a Systems Manager escribir datos de inventario en el bucket desde varias cuentas. Si ya tiene un bucket de Amazon S3 que desea utilizar para agregar datos de inventario para la sincronización de datos de recursos, debe configurar el bucket para que utilice la política en el siguiente procedimiento.
**nota**
Systems Manager Inventory no puede agregar datos a un bucket de Amazon S3 especificado si ese bucket está configurado para utilizar Object Lock. Compruebe que el bucket de Amazon S3 que cree o elija para la sincronización de datos de recursos no esté configurado para utilizar Object Lock de Amazon S3. Para obtener más información, consulte [Cómo funciona Bloqueo de objetos de S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html) en la *Guía del usuario de Amazon Simple Storage Service*.
**Cómo crear y configurar un bucket de Amazon S3 para la sincronización de datos de recursos**
1. Abra la consola de Amazon S3 en [https://console.aws.amazon.com/s3](https://console.aws.amazon.com/s3/).
1. Cree un bucket para almacenar los datos de Inventory agregados. Para obtener más información, consulte [Crear un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) en la *Guía del usuario de Amazon Simple Storage Service*. Anote el nombre de bucket y la Región de AWS donde lo creó.
1. Elija la pestaña **Permisos** y, a continuación, elija **Política de bucket**.
1. Copie y pegue la siguiente política de bucket en el editor de políticas. Sustituya *amzn-s3-demo-bucket* por el nombre del bucket de S3 que ha creado. Sustituya *account\$1ID\$1number* por un número de ID de Cuenta de AWS válido.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=111122223333/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=444455556666/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=123456789012/*",
"arn:aws:s3:::amzn-s3-demo-bucket/*/accountid=777788889999/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:111122223333:resource-data-sync/*"
}
}
}
]
}
```
------
1. Guarde los cambios.
## Cómo crear una sincronización de datos de recursos para Inventory
Utilice el siguiente procedimiento para crear una sincronización de datos de recursos para Systems Manager Inventory mediante la consola de Systems Manager. Para obtener información acerca de cómo crear una sincronización de datos de recursos utilizando la AWS CLI, consulte [Uso de la AWS CLI para configurar la recopilación de datos de inventario](inventory-collection-cli.md).
**Cómo crear una sincronización de datos de recursos**
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 el menú **Administración de cuentas**, elija **Sincronización de datos de recursos**.
1. Elija **Crear sincronización de datos de recursos**.
1. En el campo **Nombre de la sincronización** ingrese el nombre de la configuración de sincronización.
1. En el campo **Nombre del bucket**, ingrese el nombre del bucket de Amazon S3 que creó con el procedimiento **Para crear y configurar un bucket de Amazon S3 para la sincronización de datos de recursos**.
1. (Opcional) En el campo **Prefijo del bucket**, ingrese el nombre de un prefijo de bucket de Amazon S3 (subdirectorio).
1. En el campo **Región del bucket**, elija **This region** si el bucket de Amazon S3 que ha creado se encuentra en la Región de AWS actual. Si el bucket se encuentra en otra Región de AWS, elija **Otra región** e ingrese el nombre de la región.
**nota**
Si la sincronización y el bucket de Amazon S3 de destino se encuentran en regiones diferentes, es posible que esté sujeto a precios de transferencia de datos. Para obtener más información, consulte [Precios de Amazon S3](https://aws.amazon.com/s3/pricing/).
1. (Opcional) En el campo **ARN de la clave del KMS**, escriba o pegue un ARN de clave de KMS para cifrar los datos de inventario de Amazon S3.
1. Seleccione **Crear**.
Para sincronizar los datos de inventario de varias Regiones de AWS, debe crear una sincronización de datos de recursos en *cada* región. Repita este procedimiento en cada Región de AWS en la que desea recopilar los datos de inventario y enviarlos al bucket de Amazon S3 central. Cuando cree la sincronización en cada región, especifique el bucket de Amazon S3 central en el campo **Nombre del bucket**. A continuación, utilice la opción **Región del bucket** para elegir la región en la que ha creado el bucket de Amazon S3 central, tal y como se muestra en la siguiente captura de pantalla. La próxima vez que la asociación se ejecute para recopilar los datos de inventario, Systems Manager almacenará los datos en el bucket de Amazon S3 central.
![\[Sincronización de datos de recursos de Systems Manager desde varias Regiones de AWS\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-rds-multiple-regions.png)
## Cómo crear una sincronización de datos de recursos de inventario para cuentas definidas en AWS Organizations
Puede sincronizar los datos de inventario de Cuentas de AWS definidas en AWS Organizations a un bucket de Amazon S3 central. Después de completar los siguientes procedimientos, los datos de inventario se sincronizan con prefijos de clave *individuales* de Amazon S3 en el bucket central. Cada prefijo de clave representa un ID de Cuenta de AWS diferente.
**Antes de empezar**
Antes de comenzar, compruebe que ha preparado y configurado Cuentas de AWS en AWS Organizations. Para obtener más información, consulte [ en la *Guía del usuario de AWS Organizations*](https://docs.aws.amazon.com/organizations/latest/userguide/rgs_getting-started.html).
Además, tenga en cuenta que debe crear la sincronización de datos de recursos basada en la organización para cada Región de AWS y Cuenta de AWS definida en AWS Organizations.
### Cómo crear un bucket de Amazon S3 central
Utilice el siguiente procedimiento para crear un bucket de Amazon S3 central para almacenar datos de inventario agregados. El procedimiento describe cómo asignar una política de bucket que permite a Systems Manager escribir datos de inventario en el bucket desde el ID de cuenta de AWS Organizations. Si ya tiene un bucket de Amazon S3 que desea utilizar para agregar datos de inventario para la sincronización de datos de recursos, debe configurar el bucket para que utilice la política en el siguiente procedimiento.
**Cómo crear y configurar un bucket de Amazon S3 para la sincronización de datos de recursos para varias cuentas definidas en AWS Organizations**
1. Abra la consola de Amazon S3 en [https://console.aws.amazon.com/s3](https://console.aws.amazon.com/s3/).
1. Cree un bucket para almacenar los datos de inventario agregados. Para obtener más información, consulte [Crear un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) en la *Guía del usuario de Amazon Simple Storage Service*. Anote el nombre de bucket y la Región de AWS donde lo creó.
1. Elija la pestaña **Permisos** y, a continuación, elija **Política de bucket**.
1. Copie y pegue la siguiente política de bucket en el editor de políticas. Sustituya *amzn-s3-demo-bucket *y *organization-id* por el nombre del bucket de Amazon S3 que ha creado y un ID de cuenta de AWS Organizations válido.
Si lo desea, reemplace *bucket-prefix* por el nombre de un prefijo de Amazon S3 (subdirectorio). Si no ha creado ningún prefijo, quite *bucket-prefix/* del ARN de la siguiente política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SSMBucketPermissionsCheck",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceOrgID": "organization-id"
}
}
},
{
"Sid": " SSMBucketDeliveryTagging",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObjectTagging",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=*/*"
]
}
]
}
```
------
### Cómo crear una sincronización de datos de recursos de inventario para cuentas definidas en AWS Organizations
En el siguiente procedimiento se describe cómo utilizar la AWS CLI para crear una sincronización de datos de recursos para cuentas definidas en AWS Organizations. Debe utilizar la AWS CLI para realizar esta tarea. También debe realizar este procedimiento para cada Región de AWS y Cuenta de AWS definida en AWS Organizations.
**Cómo crear una sincronización de datos de recursos para una cuenta definida en AWS Organizations (AWS CLI)**
1. 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).
1. Ejecute el siguiente comando para comprobar que no dispone de ninguna otra sincronización de datos de recursos *basada en AWS Organizations*. Puede tener varias sincronizaciones estándar, incluidas varias sincronizaciones estándar y una sincronización basada en organizaciones. Pero, solo puede disponer de una sincronización de datos de recursos basada en la organización.
```
aws ssm list-resource-data-sync
```
Si el comando regresa otra sincronización de datos de recursos basada en organizaciones, debe eliminarla o elegir no crear una nueva.
1. Ejecute el siguiente comando para crear una sincronización de datos de recursos para una cuenta definida en AWS Organizations. Para amzn-s3-demo-bucket, especifique el nombre del bucket de Amazon S3 creado anteriormente en este tema. Si ha creado un prefijo (subdirectorio) para el bucket, especifique esta información para *prefix-name*.
```
aws ssm create-resource-data-sync --sync-name name --s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix-name,SyncFormat=JsonSerDe,Region=Región de AWS, for example us-east-2,DestinationDataSharing={DestinationDataSharingType=Organization}"
```
1. Repita los pasos 2 y 3 para cada Región de AWS y Cuenta de AWS en el que desee sincronizar datos con el bucket de Amazon S3 central.
### Cómo administrar sincronizaciones de datos de recursos
Cada Cuenta de AWS puede tener 5 sincronizaciones de datos de recursos por Región de AWS. Puede utilizar la consola de AWS Systems Manager Fleet Manager para administrar las sincronizaciones de datos de recursos.
**Cómo visualizar las sincronizaciones de datos de recursos**
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 el menú desplegable **Administración de cuenta**, elija **Sincronizaciones de datos de recursos**.
1. Seleccione una sincronización de datos de recursos de la tabla y luego, elija **Ver detalles** para ver la información de la sincronización de datos de recursos.
**Cómo eliminar una sincronización de datos de recursos**
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 el menú desplegable **Administración de cuenta**, elija **Sincronizaciones de datos de recursos**.
1. Seleccione una sincronización de datos de recursos de la tabla y luego, elija **Eliminar**.
# Uso de EventBridge para monitorear eventos de Inventory
Puede configurar una regla en Amazon EventBridge para crear un evento en respuesta a cambios de estado de recursos de AWS Systems Manager Inventory. EventBridge admite eventos para los siguientes cambios de estado de Inventory. Todos los eventos se envían en la medida de lo posible.
**Tipo de inventario personalizado eliminado para una instancia específica**: si se configura una regla para monitorear este evento, EventBridge crea un evento cuando se elimina un tipo de inventario personalizado en un nodo administrado específico. EventBridge envía un evento por nodo por tipo de inventario personalizado. A continuación, se muestra un patrón de eventos de ejemplo.
```
{
"timestampMillis": 1610042981103,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:09:41 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "succeeded",
"action": "delete",
"resource-type": "managed-instance",
"resource-id": "i-12345678",
"action-reason": "",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**Evento de tipo de inventario personalizado eliminado para todas las instancias**: si se configura una regla para monitorear este evento, EventBridge crea un evento cuando se elimina un tipo de inventario personalizado para todos los nodos administrados. A continuación, se muestra un patrón de eventos de ejemplo.
```
{
"timestampMillis": 1610042904712,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:08:24 PM",
"resources": [
],
"body": {
"action-status": "succeeded",
"action": "delete-summary",
"resource-type": "managed-instance",
"resource-id": "",
"action-reason": "The delete for type name Custom:SomeCustomInventoryType was completed. The deletion summary is: {\"totalCount\":1,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.1\",\"count\":1,\"remainingCount\":0}]}",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
**Llamada [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) con evento de versión de esquema anterior**: si se configura una regla para monitorear este evento, EventBridge crea un evento cuando se realiza una llamada PutInventory que utiliza una versión de esquema inferior al esquema actual. Este evento se aplica a todos los tipos de inventario. A continuación, se muestra un patrón de eventos de ejemplo.
```
{
"timestampMillis": 1610042629548,
"source": "SSM",
"account": "123456789012",
"type": "INVENTORY_RESOURCE_STATE_CHANGE",
"startTime": "Jan 7, 2021 6:03:49 PM",
"resources": [
{
"arn": "arn:aws:ssm:us-east-1:123456789012:managed-instance/i-12345678"
}
],
"body": {
"action-status": "failed",
"action": "put",
"resource-type": "managed-instance",
"resource-id": "i-01f017c1b2efbe2bc",
"action-reason": "The inventory item with type name Custom:MyCustomInventoryType was sent with a disabled schema verison 1.0. You must send a version greater than 1.0",
"type-name": "Custom:MyCustomInventoryType"
}
}
```
Para obtener información acerca de cómo configurar EventBridge para monitorear estos eventos, consulte [Configuración de EventBridge para eventos de Systems Manager](monitoring-systems-manager-events.md).
# Configuración de la recopilación de inventario
Esta sección describe cómo configurar la recopilación de AWS Systems Manager Inventory en uno o varios nodos administrados mediante la consola de Systems Manager. Si desea ver un ejemplo de cómo configurar la recopilación de inventario mediante la AWS Command Line Interface (AWS CLI), consulte [Uso de la AWS CLI para configurar la recopilación de datos de inventario](inventory-collection-cli.md).
Cuando configure la recopilación de Inventory, comience creando una asociación de AWS Systems Manager State Manager. Systems Manager recopila los datos de inventario cuando se ejecuta la asociación. Si no crea la asociación en primer lugar e intenta invocar el complemento `aws:softwareInventory` mediante, por ejemplo, el uso de AWS Systems Manager Run Command , el sistema regresará el siguiente error: `The aws:softwareInventory plugin can only be invoked via ssm-associate.`
**nota**
Tenga en cuenta el siguiente comportamiento si crea varias asociaciones de inventario para un nodo administrado:
A cada nodo se le puede asignar una asociación de inventario que se dirija a *todos* los nodos (--targets "Key=InstanceIds,Values=\$1").
A cada nodo también se le puede asignar una asociación específica que utilice pares clave-valor de etiqueta o un grupo de recursos de AWS.
Si a un nodo se le asignan varias asociaciones de inventario, el estado muestra *Omitido* para la asociación que no se ha ejecutado. La asociación que se ha ejecutado más recientemente muestra el estado real de la asociación de inventario.
Si a un nodo se le asignan varias asociaciones de inventario y cada una utiliza un par clave-valor de etiqueta, esas asociaciones de inventario no se ejecutan en el nodo debido al conflicto de etiqueta. La asociación sigue ejecutándose en nodos que no tienen el conflicto clave-valor de etiqueta.
**Antes de empezar**
Complete las siguientes tareas antes de configurar la recopilación de inventario.
+ Actualice AWS Systems Manager SSM Agent en los nodos que desee inventariar. Si ejecuta la versión más reciente del SSM Agent, se asegurará de poder recopilar metadatos de todos los tipos de inventario admitidos. Para obtener información acerca de cómo actualizar el SSM Agent mediante State Manager, consulte [Tutorial: actualización automática de SSM Agent con AWS CLI](state-manager-update-ssm-agent-cli.md).
+ Verifique que haya completado los requisitos de configuración para las instancias de Amazon Elastic Compute Cloud (Amazon EC2) y las máquinas que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types). Para obtener más información, consulte [Configuración de nodos administrados para AWS Systems Manager](systems-manager-setting-up-nodes.md).
+ Para los nodos de Microsoft Windows Server, compruebe que el nodo administrado está configurado con Windows PowerShell 3.0 (o posterior). SSM Agent utiliza el cmdlet `ConvertTo-Json` en PowerShell para convertir los datos de inventario de la actualización de Windows al formato requerido.
+ (Opcional) Cree una sincronización de datos de recursos para almacenar de forma centralizada los datos de inventario en un bucket de Amazon S3. A continuación, la sincronización de datos de recursos actualiza automáticamente los datos centralizados cuando se recopilan nuevos datos de inventario. Para obtener más información, consulte [Explicación: cómo utilizar la sincronización de datos de recursos para agregar datos de inventario](inventory-resource-data-sync.md).
+ (Opcional) Cree un archivo JSON para recopilar el inventario personalizado. Para obtener más información, consulte [Uso del inventario personalizado](inventory-custom.md).
## Inventario de todos los nodos administrados de la Cuenta de AWS
Puede inventariar fácilmente todos los nodos administrados de la Cuenta de AWS mediante la creación de una asociación de inventario global. Una asociación de inventario global realiza las siguientes acciones:
+ Aplica automáticamente la configuración de inventario global (la asociación) a todos los nodos administrados existentes en la Cuenta de AWS. Los nodos administrados que ya tienen una asociación de inventario se omiten cuando se aplica y ejecuta la asociación de inventario global. Si un nodo se omite, en el mensaje de estado detallado aparece `Overridden By Explicit Inventory Association`. Estos nodos se omiten en la asociación global, pero siguen aportando datos sobre el inventario cuando se ejecuta la asignación de inventario asignada.
+ Agrega automáticamente a la asociación de inventario global los nuevos nodos creados en la Cuenta de AWS.
**nota**
Si un nodo administrado está configurado para la asociación de inventario global y se asigna una asociación específica a dicho nodo, Systems Manager Inventory deja de dar prioridad a la asociación global y aplica la asociación específica.
Las asociaciones de inventario globales están disponibles en la versión 2.0.790.0 y versiones posteriores del SSM Agent. Para obtener más información sobre cómo actualizar el SSM Agent en los nodos, consulte [Actualización de SSM Agent mediante Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
### Configuración de la recopilación de inventario con un solo clic (consola)
Utilice el siguiente procedimiento para configurar Systems Manager Inventory para todos los nodos administrados en la Cuenta de AWS y en una única Región de AWS.
**Para configurar todos los nodos administrados en la región actual para Systems Manager Inventory**
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 **Inventory**.
1. En la tarjeta **Instancias administradas con el inventario habilitado**, elija **Click here to enable inventory on all instances**.
![\[Activación de Systems Manager Inventory en todos los nodos administrados.\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-one-click-1.png)
Si se realiza correctamente, la consola muestra el siguiente mensaje.
![\[Activación de Systems Manager Inventory en todos los nodos administrados.\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-one-click-2.png)
En función del número de nodos administrados en la cuenta, es posible que la asociación de inventario global tarde varios minutos en aplicarse. Espere unos minutos y actualice la página. Compruebe que el gráfico cambia para reflejar que el inventario está configurado en todos los nodos administrados.
### Configuración de la recopilación mediante el uso de la consola
En esta sección, se incluye información acerca de cómo configurar Systems Manager Inventory para recopilar metadatos de los nodos administrados mediante la consola de Systems Manager. Puede recopilar rápidamente los metadatos de todos los nodos de una Cuenta de AWS específica (y de los futuros nodos que se creen en esa cuenta) o, si lo prefiere, puede recopilar los datos de inventario de manera selectiva mediante el uso de etiquetas o de ID de nodos.
**nota**
Antes de completar este procedimiento, compruebe si ya existe una asociación de inventario global. Si ya existe una asociación de inventario global, cada vez que lance una instancia nueva, se le aplicará la asociación y se creará un inventario de la instancia nueva.
**Para configurar la recopilación de inventario**
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 **Inventory**.
1. Elija **Setup Inventory**.
1. En la sección **Destinos**, identifique los nodos en los que desea ejecutar esta operación. Para ello, seleccione una de las opciones siguientes.
+ **Selecting all managed instances in this account**: esta opción selecciona todos los nodos administrados para los que no existe ninguna asociación de inventario. Si elige esta opción, los nodos que ya tengan asociaciones de inventario se omitirán durante la recopilación del inventario y aparecerán con el estado **Omitido** en los resultados del inventario. Para obtener más información, consulte [Inventario de todos los nodos administrados de la Cuenta de AWS](#inventory-management-inventory-all).
+ **Especificación de una etiqueta**: utilice esta opción para especificar una sola etiqueta para identificar los nodos de la cuenta de los que desea recopilar el inventario. Si utiliza una etiqueta, todos los nodos que se creen en el futuro con la misma etiqueta también se incluirán en el inventario. Si hay una asociación de inventario existente en todos los nodos y se utiliza una etiqueta para seleccionar nodos específicos como destino de un inventario distinto, se invalidará la pertenencia del nodo en el grupo de destino **All managed instances**. Los nodos administrados con la etiqueta especificada se omitirán en las recopilaciones de inventario que se realicen en **All managed instances** en el futuro.
+ **Selección manual de instancias**: utilice esta opción para elegir determinados nodos administrados de la cuenta. Si se eligen explícitamente nodos concretos a través de esta opción, se invalidan las asociaciones de inventario del destino **All managed instances**. El nodo se omitirá en las recopilaciones de inventario que se realicen en **All managed instances** en el futuro.
**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. En la sección **Schedule**, elija la frecuencia con la que desea que el sistema recopile los metadatos de inventario de los nodos.
1. En la sección **Parámetros**, utilice las listas para activar o desactivar los diferentes tipos de recopilación de inventario. Para obtener más información acerca de cómo recopilar el inventario de archivos y del registro de Windows, consulte [Uso del inventario de archivos y del registro de Windows](inventory-file-and-registry.md).
1. En la sección **Avanzado**, seleccione **Sync inventory execution logs to an Amazon S3 bucket** si desea almacenar el estado de ejecución de la asociación en un bucket de Amazon S3.
1. Elija **Setup Inventory**. Systems Manager crea una asociación de State Manager y ejecuta inmediatamente Inventory en los nodos.
1. En el panel de navegación, elija **State Manager**. Compruebe que se haya creado una nueva asociación que utilice el documento `AWS-GatherSoftwareInventory`. La programación de asociación utiliza una expresión rate. Además, verifique que el campo **Estado** muestre **Correcto**. Si eligió la opción **Sync inventory execution logs to an Amazon S3 bucket**, podrá ver los datos de registro en Amazon S3 después de unos minutos. Si desea ver los datos de inventario de un nodo específico, elija **Instancias administradas** en el panel de navegación.
1. Elija un nodo y, a continuación, elija **Ver detalles**.
1. En la página de detalles del nodo, elija **Inventory**. Utilice las listas **Inventory type** para filtrar el inventario.
# Consulta de datos de Inventory de varias regiones y cuentas
AWS Systems Manager Inventory se integra a Amazon Athena para ayudarlo a consultar los datos de inventario de varias Regiones de AWS y Cuentas de AWS. La integración de Athena utiliza la sincronización de datos de recursos, de modo que podrá visualizar los datos de inventario de todos los nodos administrados en la página **Detail View** (Vista de detalles) en la consola de AWS Systems Manager.
**importante**
Esta característica utiliza AWS Glue para rastrear los datos del bucket de Amazon Simple Storage Service (Amazon S3) y Amazon Athena para consultar los datos. En función de la cantidad de datos que haya consultado y rastreado, puede se le apliquen cargos por el uso de estos servicios. Con AWS Glue, paga una tarifa por hora, que se factura por segundo, por los rastreadores (detección de datos) y los trabajos de ETL (procesamiento y carga de datos). Con Athena, se le cobra en función del volumen de datos escaneados por cada consulta. Lo animamos a que consulte las directrices de precios de estos servicios antes de utilizar la integración de Amazon Athena a Systems Manager Inventory. Para obtener más información, consulte [Precios de Amazon Athena](https://aws.amazon.com/athena/pricing/) y [Precios de AWS Glue](https://aws.amazon.com/glue/pricing/).
Puede ver los datos de inventario en la página **Detailed View** (Vista detallada) en todas las Regiones de AWS en las que Amazon Athena está disponible. Para ver una lista de las regiones admitidas, consulte [Puntos de conexión de Amazon Athena](https://docs.aws.amazon.com/general/latest/gr/athena.html#athena_region) en la *Referencia general de Amazon Web Services*.
**Antes de empezar**
La integración de Athena utiliza la sincronización de datos de recursos. Debe preparar y configurar la sincronización de datos de recursos para utilizar esta característica. Para obtener más información, consulte [Explicación: cómo utilizar la sincronización de datos de recursos para agregar datos de inventario](inventory-resource-data-sync.md).
Además, tenga en cuenta que la página **Detailed View** (Vista detallada) muestra los datos de inventario del *propietario* del bucket de Amazon S3 central que utiliza la sincronización de datos de recursos. Si no es el propietario del bucket de Amazon S3 central, no verá los datos de inventario en la página **Detailed View** (Vista detallada).
## Configuración del acceso
Antes de que pueda consultar y visualizar los datos de varias cuentas y regiones en la página **Vista detallada** en la consola de Systems Manager, debe configurar su entidad de IAM con permiso para ver los datos.
Si los datos de inventario se almacenan en un bucket de Amazon S3 que utiliza cifrado de AWS Key Management Service (AWS KMS), también configure la entidad de IAM y el rol de servicio `Amazon-GlueServiceRoleForSSM` para el cifrado de AWS KMS.
**Topics**
+ [Configuración de la entidad de IAM para acceder a la página Vista detallada](#systems-manager-inventory-query-iam-user)
+ [(Opcional) Configuración de permisos para ver datos cifrados de AWS KMS](#systems-manager-inventory-query-kms)
### Configuración de la entidad de IAM para acceder a la página Vista detallada
A continuación se describen los permisos mínimos necesarios para ver los datos del inventario en la página **Vista Detallada**.
La política administrada `AWSQuicksightAthenaAccess`
El siguiente `PassRole` y bloque de permisos necesarios adicionales
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGlue",
"Effect": "Allow",
"Action": [
"glue:GetCrawler",
"glue:GetCrawlers",
"glue:GetTables",
"glue:StartCrawler",
"glue:CreateCrawler"
],
"Resource": "*"
},
{
"Sid": "iamPassRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"arn:aws:iam::111122223333:role/SSMInventoryGlueRole",
"arn:aws:iam::111122223333:role/SSMInventoryServiceRole"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "glue.amazonaws.com"
}
}
},
{
"Sid": "iamRoleCreation",
"Effect": "Allow",
"Action": [
"iam:CreateRole",
"iam:AttachRolePolicy"
],
"Resource": "arn:aws:iam::111122223333:role/*"
},
{
"Sid": "iamPolicyCreation",
"Effect": "Allow",
"Action": "iam:CreatePolicy",
"Resource": "arn:aws:iam::111122223333:policy/*"
}
]
}
```
------
(Opcional) Si el bucket de Amazon S3 que se utiliza para almacenar datos de inventario está cifrado con AWS KMS, también agregue el siguiente bloque a la política.
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
Para dar acceso, agregue permisos a los usuarios, grupos o roles:
+ Usuarios y grupos en AWS IAM Identity Center:
Cree un conjunto de permisos. Siga las instrucciones de [Creación de un conjunto de permisos](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) en la *Guía del usuario de AWS IAM Identity Center*.
+ Usuarios gestionados en IAM a través de un proveedor de identidades:
Cree un rol para la federación de identidades. Siga las instrucciones descritas en [Creación de un rol para un proveedor de identidad de terceros (federación)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) en la *Guía del usuario de IAM*.
+ Usuarios de IAM:
+ Cree un rol que el usuario pueda aceptar. Siga las instrucciones descritas en [Creación de un rol para un usuario de IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) en la *Guía del usuario de IAM*.
+ (No recomendado) Adjunte una política directamente a un usuario o agregue un usuario a un grupo de usuarios. Siga las instrucciones descritas en [Adición de permisos a un usuario (consola)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) de la *Guía del usuario de IAM*.
### (Opcional) Configuración de permisos para ver datos cifrados de AWS KMS
Si el bucket de Amazon S3 que se utiliza para almacenar datos de inventario está cifrado con AWS Key Management Service (AWS KMS), configure su entidad de IAM y el rol **Amazon-GlueServiceRoleForSSM** con permisos `kms:Decrypt` para la clave de AWS KMS.
**Antes de empezar**
Para proporcionar los permisos `kms:Decrypt` de la clave AWS KMS, agregue el siguiente bloque de políticas a su entidad de IAM:
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
Si aún no lo ha hecho, complete ese procedimiento y agregue los permisos de `kms:Decrypt` para la clave de AWS KMS.
Utilice el siguiente procedimiento para configurar el rol **Amazon-GlueServiceRoleForSSM** con los permisos de `kms:Decrypt` para la clave de AWS KMS.
**Para configurar el rol **Amazon-GlueServiceRoleForSSM** con los permisos de `kms:Decrypt`**
1. Abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación, elija **Roles** y, a continuación, utilice el campo de búsqueda para ubicar el rol **Amazon-GlueServiceRoleForSSM**. Se abre la página **Resumen**.
1. Utilice el campo de búsqueda para buscar el rol **Amazon-GlueServiceRoleForSSM**. Elija el nombre del rol. Se abre la página **Resumen**.
1. Elija el nombre del rol. Se abre la página **Resumen**.
1. Elija **Agregar política insertada**. Se abre la página **Crear política**.
1. Seleccione la pestaña **JSON**.
1. Elimine el texto JSON existente en el editor y, a continuación, copie y pegue la siguiente política en el editor de JSON.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:111122223333:key/key_ARN"
]
}
]
}
```
------
1. Elija **Revisar la política**
1. En la página **Revisar política**, escriba un nombre en el campo **Nombre**.
1. Elija **Create Policy (Crear política)**.
## Consulta de datos en la página Detailed Inventory View (Vista de inventario detallado)
Utilice el siguiente procedimiento para ver los datos de inventario de varias Regiones de AWS y Cuentas de AWS en la página **Detailed View** (Vista detallada) de Systems Manager Inventory.
**importante**
La página **Detailed View** (Vista detallada) de Inventory solo está disponible en las Regiones de AWS que ofrece Amazon Athena. Si las siguientes pestañas no se muestran en la página de Systems Manager Inventory, significa que Athena no está disponible en la región y que no puede utilizar la **Detailed View** (Vista detallada) para consultar datos.
![\[Visualización de Inventario con las pestañas Panel | Vista detallada | Configuración\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
**Para ver los datos de inventario de varias regiones y cuentas en la consola de AWS 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 **Inventory**.
1. Elija la pestaña **Detailed View (Vista detallada)**.
![\[Acceso a la página de vista detallada de AWS Systems Manager Inventory\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-detailed-view.png)
1. Seleccione la sincronización de datos de recursos para la que desea consultar datos.
![\[Visualización de los datos de inventario en la consola de AWS Systems Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-display-data.png)
1. En la lista **Inventory Type (Tipo de inventario)**, seleccione el tipo de datos de inventario que desea consultar y, a continuación, pulse Enter.
![\[Elección de un tipo de inventario en la consola de AWS Systems Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-type.png)
1. Para filtrar los datos, elija la barra Filtro y, a continuación, elija una opción de filtro.
![\[Filtro de los datos de inventario en la consola de AWS Systems Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-filter.png)
Puede utilizar el botón **Export to CSV (Exportar a CSV)** para ver el conjunto de consultas actual en una aplicación de hoja de cálculo como Microsoft Excel. También puede utilizar los botones **Query History** (Historial de consultas) y **Run Advanced Queries** (Ejecutar consultas avanzadas) para ver detalles sobre el historial e interactuar con sus datos en Amazon Athena.
### Edición de la programación del rastreador de AWS Glue
AWS Glue rastrea los datos de inventario en el bucket de Amazon S3 central dos veces al día y de forma predeterminada. Si cambia con frecuencia los tipos de datos que se recopilarán en los nodos, es posible que desee rastrear los datos con mayor frecuencia, tal y como se describe en el siguiente procedimiento.
**importante**
Con AWS Glue, paga una tarifa por hora por Cuenta de AWS, que se factura por segundo, por los rastreadores (detección de datos) y los trabajos de ETL (procesamiento y carga de datos). Antes de cambiar la programación del rastreador, consulte la página de [precios de AWS Glue](https://aws.amazon.com/glue/pricing/)
**Para cambiar la programación del rastreador de datos de inventario**
1. Abra la consola de AWS Glue en [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. En el panel de navegación, elija **Crawlers (Rastreadores)**.
1. En la lista de rastreadores, elija la opción que aparece junto al rastreador de datos de Systems Manager Inventory. El nombre del rastreador utiliza el formato siguiente:
`AWSSystemsManager-s3-bucket-name-Region-account_ID`
1. Elija **Acción** y, a continuación, seleccione **Edit crawler (Editar rastreador)**.
1. En el panel de navegación, seleccione **Schedule (Programación)**.
1. En el campo **Expresión Cron**, especifique una nueva programación mediante un formato Cron. Para obtener más información acerca del formato Cron, consulte [Programaciones basadas en tiempo para trabajos y rastreadores](https://docs.aws.amazon.com/glue/latest/dg/monitor-data-warehouse-schedule.html) en la *Guía para desarrolladores de AWS Glue*.
**importante**
Puede detener el rastreador para dejar de incurrir en gastos de AWS Glue. Si pone en pausa el rastreador o si cambia la frecuencia de tal forma que los datos se rastreen con menos frecuencia, **Detailed View** (Vista detallada) de Inventory podría mostrar datos que no están actualizados.
# Consulta de una recopilación de inventario mediante filtros
Después de recopilar datos de inventario, puede utilizar las características de filtro de AWS Systems Manager para consultar una lista de nodos administrados que cumplan determinados criterios de filtro.
**Para consultar nodos en función de filtros de inventario**
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 **Inventory**.
1. En la sección **Filter by resource groups, tags or inventory types** elija el cuadro de filtro. Aparecerá una lista de filtros predefinidos.
1. Elija un atributo que servirá de filtro. Por ejemplo, elija `AWS:Application`. Si el sistema se lo solicita, elija un atributo secundario como filtro. Por ejemplo, elija `AWS:Application.Name`.
1. Elija un delimitador en la lista. Por ejemplo, elija **Begin with**. Aparecerá un cuadro de texto en el filtro.
1. Ingrese un valor en el cuadro de texto. Por ejemplo, ingrese *Amazon* (SSM Agent se llama *Amazon SSM Agent*).
1. Pulse Enter. El sistema devuelve una lista de nodos administrados que contienen el nombre de una aplicación que comienza por la palabra *Amazon*.
**nota**
Puede combinar varios filtros para limitar la búsqueda.
# Agregación de datos de Inventory
Después de configurar los nodos administrados de AWS Systems Manager Inventory, puede ver los totales agregados de los datos de Inventory. Por ejemplo, supongamos que ha configurado decenas o cientos de nodos administrados para que recopilen el tipo de inventario `AWS:Application`. La información de esta sección le permite ver un recuento exacto del número de nodos que están configurados para recopilar estos datos.
También puede ver detalles específicos de inventario si efectúa la agregación por un tipo de datos. Por ejemplo, el tipo de inventario `AWS:InstanceInformation` recopila información de la plataforma del sistema operativo con el tipo de datos `Platform`. Al agregar datos según el tipo de datos `Platform`, puede ver rápidamente el número de nodos en los que se ejecuta Windows Server, en los que se ejecuta Linux y en los que se ejecuta macOS.
En los procedimientos de esta sección, se describe cómo ver los totales agregados de datos de inventario mediante la AWS Command Line Interface (AWS CLI). También puede ver los recuentos agregados preconfigurados en la consola de AWS Systems Manager, en la página **Inventario**. Estos paneles preconfigurados se denominan *Inventory Insights (Información de inventario)* y ofrecen la solución a los problemas de configuración de Inventory con un solo clic.
Tenga en cuenta los siguientes detalles importantes sobre los recuentos de agregación de los datos de inventario:
+ Si termina un nodo administrado que está configurado para recopilar datos de inventario, Systems Manager conserva los datos durante 30 días y, luego, los elimina. Para los nodos en ejecución, los sistemas eliminan los datos de inventario con más de 30 días de antigüedad. Si necesita almacenar datos de inventario durante más de 30 días, puede usar AWS Config para registrar el historial o para realizar una consulta periódica y cargar los datos en un bucket de Amazon Simple Storage Service (Amazon S3).
+ Si un nodo se había configurado previamente para informar sobre un tipo de datos de inventario específico, por ejemplo, `AWS:Network` y, más adelante, se cambia la configuración para dejar de recopilar ese tipo de datos, los totales de agregación siguen mostrando los datos `AWS:Network` hasta que se termine el nodo y hayan pasado 30 días.
Para obtener información sobre cómo configurar y recopilar rápidamente los datos de inventario de todos los nodos en una Cuenta de AWS específica (y de los futuros nodos que podrían crearse en dicha cuenta), consulte [Inventario de todos los nodos administrados de la Cuenta de AWS](inventory-collection.md#inventory-management-inventory-all).
**Topics**
+ [Agregación de datos de Inventory para ver recuentos de nodos que recopilen determinados tipos de datos](#inventory-aggregate-type)
+ [Agregación de datos de Inventory mediante grupos para ver qué nodos están configurados o no para recopilar un tipo de inventario](#inventory-aggregate-groups)
## Agregación de datos de Inventory para ver recuentos de nodos que recopilen determinados tipos de datos
Puede utilizar la operación [GetInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetInventory.html) de la API de AWS Systems Manager para ver los totales agregados de nodos que recopilan uno o varios tipos de inventario y tipos de datos. Por ejemplo, el tipo de inventario `AWS:InstanceInformation` le permite ver el total de sistemas operativos mediante la operación GetInventory de la API con el tipo de datos `AWS:InstanceInformation.PlatformType`. A continuación, se muestra un ejemplo de comando de la AWS CLI y su resultado.
```
aws ssm get-inventory --aggregators "Expression=AWS:InstanceInformation.PlatformType"
```
El sistema devuelve información similar a la siguiente.
```
{
"Entities":[
{
"Data":{
"AWS:InstanceInformation":{
"Content":[
{
"Count":"7",
"PlatformType":"windows"
},
{
"Count":"5",
"PlatformType":"linux"
}
]
}
}
}
]
}
```
**Introducción**
Determine los tipos de inventario y los tipos de datos cuyos recuentos desea ver. Puede ver una lista de los tipos de inventario y de datos que admiten la agregación mediante la ejecución del siguiente comando en la AWS CLI.
```
aws ssm get-inventory-schema --aggregator
```
El comando devuelve una lista JSON de tipos de inventario y tipos de datos que admiten la agregación. El campo **TypeName** muestra los tipos de inventario admitidos. Y el campo **Name** muestra cada tipo de datos. Por ejemplo, en la siguiente lista, el tipo de inventario `AWS:Application` incluye tipos de datos para `Name` y `Version`.
```
{
"Schemas": [
{
"TypeName": "AWS:Application",
"Version": "1.1",
"DisplayName": "Application",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "Version"
}
]
},
{
"TypeName": "AWS:InstanceInformation",
"Version": "1.0",
"DisplayName": "Platform",
"Attributes": [
{
"DataType": "STRING",
"Name": "PlatformName"
},
{
"DataType": "STRING",
"Name": "PlatformType"
},
{
"DataType": "STRING",
"Name": "PlatformVersion"
}
]
},
{
"TypeName": "AWS:ResourceGroup",
"Version": "1.0",
"DisplayName": "ResourceGroup",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
}
]
},
{
"TypeName": "AWS:Service",
"Version": "1.0",
"DisplayName": "Service",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "ServiceType"
},
{
"DataType": "STRING",
"Name": "Status"
},
{
"DataType": "STRING",
"Name": "StartType"
}
]
},
{
"TypeName": "AWS:WindowsRole",
"Version": "1.0",
"DisplayName": "WindowsRole",
"Attributes": [
{
"DataType": "STRING",
"Name": "Name"
},
{
"DataType": "STRING",
"Name": "DisplayName"
},
{
"DataType": "STRING",
"Name": "FeatureType"
},
{
"DataType": "STRING",
"Name": "Installed"
}
]
}
]
}
```
Puede agregar datos para cualquiera de los tipos de inventario indicados mediante un comando con la sintaxis siguiente.
```
aws ssm get-inventory --aggregators "Expression=InventoryType.DataType"
```
Estos son algunos ejemplos.
**Ejemplo 1**
En este ejemplo, se calcula el total de los roles de Windows que utilizan los nodos.
```
aws ssm get-inventory --aggregators "Expression=AWS:WindowsRole.Name"
```
**Ejemplo 2**
En este ejemplo, se calcula el total de las aplicaciones instaladas en los nodos.
```
aws ssm get-inventory --aggregators "Expression=AWS:Application.Name"
```
**Combinación de varios agregadores**
También puede combinar varios tipos de inventario y tipos de datos en un mismo comando para entender mejor los datos. Estos son algunos ejemplos.
**Ejemplo 1**
En este ejemplo, se calcula el total de los tipos de sistemas operativos que utilizan los nodos. También devuelve el nombre específico de los sistemas operativos.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:InstanceInformation.PlatformType", "Aggregators":[{"Expression": "AWS:InstanceInformation.PlatformName"}]}]'
```
**Ejemplo 2**
En este ejemplo, se calcula el total de las aplicaciones que se ejecutan en los nodos y la versión específica de cada aplicación.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:Application.Name", "Aggregators":[{"Expression": "AWS:Application.Version"}]}]'
```
Si lo prefiere, puede crear una expresión de agregación con uno o varios tipos de inventario y tipos de datos en un archivo JSON y llamar al archivo desde la AWS CLI. El JSON del archivo debe utilizar la sintaxis siguiente.
```
[
{
"Expression": "string",
"Aggregators": [
{
"Expression": "string"
}
]
}
]
```
Debe guardar el archivo con la extensión .json.
A continuación se muestra un ejemplo que utiliza varios tipos de inventario y tipos de datos.
```
[
{
"Expression": "AWS:Application.Name",
"Aggregators": [
{
"Expression": "AWS:Application.Version",
"Aggregators": [
{
"Expression": "AWS:InstanceInformation.PlatformType"
}
]
}
]
}
]
```
Utilice el siguiente comando para llamar al archivo desde la AWS CLI.
```
aws ssm get-inventory --aggregators file://file_name.json
```
El comando devuelve información similar a la siguiente.
```
{"Entities":
[
{"Data":
{"AWS:Application":
{"Content":
[
{"Count": "3",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "audit-libs"},
{"Count": "4",
"PlatformType": "windows",
"Version": "6.2.8",
"Name": "microsoft office"},
{"Count": "2",
"PlatformType": "windows",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "1",
"PlatformType": "linux",
"Version": "2.6.5",
"Name": "chrome"},
{"Count": "2",
"PlatformType": "linux",
"Version": "6.3",
"Name": "authconfig"}
]
}
},
"ResourceType": "ManagedInstance"}
]
}
```
## Agregación de datos de Inventory mediante grupos para ver qué nodos están configurados o no para recopilar un tipo de inventario
Los grupos en Systems Manager Inventory le permiten ver rápidamente el número de nodos administrados que están o que no están configurados para recopilar uno o varios tipos de inventarios. Con los grupos, debe especificar uno o varios tipos de inventario y un filtro que utiliza el operador `exists`.
Por ejemplo, suponga que tiene cuatro nodos administrados configurados para recopilar los siguientes tipos de inventario:
+ Nodo 1: `AWS:Application`
+ Nodo 2: `AWS:File`
+ Nodo 3: `AWS:Application`, `AWS:File`
+ Nodo 4: `AWS:Network`
Puede ejecutar el siguiente comando desde la AWS CLI para ver cuántos nodos están configurados para recopilar los tipos `AWS:Application` y `AWS:File inventory`. La respuesta también devuelve el número de nodos que no están configurados para recopilar ambos tipos de inventario.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationAndFile,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists},{Key=TypeName,Values=[AWS:File],Type=Exists}]}]'
```
La respuesta del comando muestra que solo hay un nodo administrado configurado para recopilar los tipos de inventario `AWS:Application` y `AWS:File`.
```
{
"Entities":[
{
"Data":{
"ApplicationAndFile":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
**nota**
Los grupos no devuelven recuentos para los tipos de datos. Además, no se pueden desglosar los resultados para ver los ID de los nodos que están o que no están configurados para recopilar el tipo de inventario.
Si lo prefiere, puede crear una expresión de agregación con uno o varios tipos de inventario en un archivo JSON y llamar al archivo desde la AWS CLI. El JSON del archivo debe utilizar la sintaxis siguiente:
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Name",
"Filters":[
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
},
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Debe guardar el archivo con la extensión .json.
Utilice el siguiente comando para llamar al archivo desde la AWS CLI.
```
aws ssm get-inventory --cli-input-json file://file_name.json
```
**Ejemplos adicionales**
Los siguientes ejemplos muestran cómo agregar datos de inventario para ver los nodos administrados que están o que no están configurados para recopilar los tipos de inventario especificados. Estos ejemplos utilizan la AWS CLI. Cada ejemplo incluye un comando completo con filtros que puede ejecutar desde la línea de comandos y un ejemplo de archivo input.json por si prefiere introducir la información en un archivo.
**Ejemplo 1**
En este ejemplo, se calcula el número de nodos que están o que no están configurados para recopilar los tipos de inventario `AWS:Application` o `AWS:File`.
Ejecute el siguiente comando desde la AWS CLI.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationORFile,Filters=[{Key=TypeName,Values=[AWS:Application, AWS:File],Type=Exists}]}]'
```
Si prefiere utilizar un archivo, copie y pegue el siguiente ejemplo en un archivo y guárdelo como input.json.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"ApplicationORFile",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application",
"AWS:File"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Ejecute el siguiente comando desde la AWS CLI.
```
aws ssm get-inventory --cli-input-json file://input.json
```
El comando devuelve información similar a la siguiente.
```
{
"Entities":[
{
"Data":{
"ApplicationORFile":{
"Content":[
{
"notMatchingCount":"1"
},
{
"matchingCount":"3"
}
]
}
}
}
]
}
```
**Ejemplo 2**
En este ejemplo, se calcula el número de nodos que están o que no están configurados para recopilar los tipos de inventario `AWS:Application`, `AWS:File` y `AWS:Network`.
Ejecute el siguiente comando desde la AWS CLI.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=Application,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists}]}, {Name=File,Filters=[{Key=TypeName,Values=[AWS:File],Type=Exists}]}, {Name=Network,Filters=[{Key=TypeName,Values=[AWS:Network],Type=Exists}]}]'
```
Si prefiere utilizar un archivo, copie y pegue el siguiente ejemplo en un archivo y guárdelo como input.json.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Application",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application"
],
"Type":"Exists"
}
]
},
{
"Name":"File",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:File"
],
"Type":"Exists"
}
]
},
{
"Name":"Network",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Network"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Ejecute el siguiente comando desde la AWS CLI.
```
aws ssm get-inventory --cli-input-json file://input.json
```
El comando devuelve información similar a la siguiente.
```
{
"Entities":[
{
"Data":{
"Application":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"File":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"Network":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
# Uso del inventario personalizado
Puede asignar los metadatos que desee a los nodos mediante la creación de un *inventario personalizado* de AWS Systems Manager Inventory. Por ejemplo, supongamos que administra un gran número de servidores en bastidores en su centro de datos y que estos servidores se han configurado como nodos administrados de Systems Manager. En la actualidad, guarda información sobre la ubicación de los bastidores de servidores en una hoja de cálculo. Con el inventario personalizado, puede especificar la ubicación de bastidor de cada nodo como metadatos en el nodo. Cuando recopila el inventario mediante Systems Manager, se recopilan los metadatos con otros metadatos de inventario. A continuación, puede transferir todos los metadatos de inventario a un bucket de Amazon S3 central mediante la [sincronización de datos de recursos](inventory-resource-data-sync.html) y consultar los datos.
**nota**
Systems Manager admite un máximo de 20 tipos de inventario personalizados por Cuenta de AWS.
Para asignar el inventario personalizado a un nodo, puede utilizar la operación [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) de la API de Systems Manager tal y como se describe en [Asignación de metadatos de inventarios personalizados a un nodo administrado](inventory-custom-metadata.md). O bien, puede crear un archivo JSON de inventario personalizado y cargarlo en el nodo. En esta sección se describe cómo crear el archivo JSON.
En el siguiente ejemplo, el archivo JSON con inventario personalizado especifica la información de bastidor en relación con un servidor local. Este ejemplo especifica un tipo de datos de inventario personalizado (`"TypeName": "Custom:RackInformation"`), con varias entradas en `Content` que describen los datos.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:RackInformation",
"Content": {
"Location": "US-EAST-02.CMH.RACK1",
"InstalledTime": "2016-01-01T01:01:01Z",
"vendor": "DELL",
"Zone" : "BJS12",
"TimeZone": "UTC-8"
}
}
```
También puede especificar entradas diferentes en la sección `Content`, tal y como se muestra en el siguiente ejemplo.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:PuppetModuleInfo",
"Content": [{
"Name": "puppetlabs/aws",
"Version": "1.0"
},
{
"Name": "puppetlabs/dsc",
"Version": "2.0"
}
]
}
```
El esquema JSON del inventario personalizado requiere las secciones `SchemaVersion`, `TypeName` y `Content`, pero puede definir la información en dichas secciones.
```
{
"SchemaVersion": "user_defined",
"TypeName": "Custom:user_defined",
"Content": {
"user_defined_attribute1": "user_defined_value1",
"user_defined_attribute2": "user_defined_value2",
"user_defined_attribute3": "user_defined_value3",
"user_defined_attribute4": "user_defined_value4"
}
}
```
El valor de encabezado `TypeName` se limita a 100 caracteres. Además, el valor `TypeName` debe empezar por la palabra en mayúscula `Custom`. Por ejemplo, `Custom:PuppetModuleInfo`. Por lo tanto, los siguientes ejemplos darían lugar a una excepción: `CUSTOM:PuppetModuleInfo`, `custom:PuppetModuleInfo`.
La sección `Content` incluye atributos y *datos*. Esos elementos no distinguen entre mayúsculas y minúsculas. No obstante, si define un atributo (por ejemplo: “`Vendor`“: “DELL”), deberá hacer referencia a este atributo de forma coherente en los archivos de inventario personalizado. Si especifica “`Vendor`”: “DELL” (utilizando una “P” mayúscula en `vendor`) en un archivo y, a continuación, especifica “`vendor`”: “DELL” (con una “p” en minúscula en `vendor`) en otro archivo, el sistema devolverá un error.
**nota**
Debe guardar el archivo con una extensión `.json` y el inventario que defina debe incluir únicamente valores de cadena.
Después de crear el archivo, debe guardarlo en el nodo. La tabla siguiente muestra la ubicación en la que deben guardarse los archivos JSON del inventario personalizado en el nodo.
****
| Sistema operativo | Ruta |
| --- | --- |
| Linux | /var/lib/amazon/ssm/*node-id*/inventory/custom |
| macOS | `/opt/aws/ssm/data/node-id/inventory/custom` |
| Windows Server | %SystemDrive%\$1ProgramData\$1Amazon\$1SSM\$1InstanceData\$1*node-id*\$1inventory\$1custom |
Si desea ver un ejemplo de cómo utilizar el inventario personalizado, consulte [Get Disk Utilization of Your Fleet Using EC2 Systems Manager Custom Inventory Types](https://aws.amazon.com/blogs/mt/get-disk-utilization-of-your-fleet-using-ec2-systems-manager-custom-inventory-types/).
## Eliminación de un inventario personalizado
Puede utilizar la operación [DeleteInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeleteInventory.html) de la API para eliminar un tipo de inventario personalizado y los datos asociados a él. Para eliminar todos los datos de un tipo de inventario, tiene que llamar al comando delete-inventory mediante la AWS Command Line Interface (AWS CLI). Para eliminar un tipo de inventario personalizado, tiene que llamar al comando delete-inventory con `SchemaDeleteOption`.
**nota**
Un tipo de inventario también se denomina un esquema de inventario.
El parámetro `SchemaDeleteOption` incluye las siguientes opciones:
+ **DeleteSchema**: esta opción elimina el tipo personalizado especificado y todos los datos asociados con él. Puede volver a crear el esquema más tarde, si lo desea.
+ **DisableSchema**: si elige esta opción, el sistema desactivará la versión actual, eliminará todos sus datos y omitirá todos los nuevos datos si la versión es anterior o igual a la versión desactivada. Puede volver a habilitar este tipo de inventario si llama a la acción [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) para una versión posterior a la versión desactivada.
**Para eliminar o desactivar un inventario personalizado mediante la AWS CLI**
1. 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).
1. Ejecute el siguiente comando para utilizar la opción `dry-run` con el fin de ver qué datos se eliminarán del sistema. Este comando no elimina ningún dato.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --dry-run
```
El sistema devuelve información similar a la siguiente.
```
{
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
Para obtener información acerca del resumen de eliminaciones del inventario, consulte [Explicación del resumen de eliminaciones del inventario](#delete-custom-inventory-summary).
1. Ejecute el siguiente comando para eliminar todos los datos de un tipo de inventario personalizado.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name"
```
**nota**
El resultado de este comando no muestra el progreso de la eliminación. Por este motivo, TotalCount y Remaining Count siguen siendo iguales, ya que el sistema no ha eliminado nada todavía. Puede utilizar el comando describe-inventory-deletions para mostrar el progreso de la eliminación, tal y como se describe más adelante en este tema.
El sistema devuelve información similar a la siguiente.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"custom_type_name"
}
```
El sistema elimina todos los datos del tipo de inventario personalizado especificado del servicio Systems Manager Inventory.
1. Ejecute el siguiente comando. El comando realiza las siguientes acciones para la versión actual del tipo de inventario: desactiva la versión actual, elimina todos los datos correspondientes a ella y omite todos los datos nuevos si la versión es inferior o igual a la versión desactivada.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DisableSchema"
```
El sistema devuelve información similar a la siguiente.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
Puede ver un tipo de inventario desactivado mediante el siguiente comando.
```
aws ssm get-inventory-schema --type-name Custom:custom_type_name
```
1. Ejecute el siguiente comando para eliminar un tipo de inventario.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DeleteSchema"
```
El sistema elimina el esquema y todos los datos de inventario del tipo personalizado especificado.
El sistema devuelve información similar a la siguiente.
```
{
"DeletionId":"system_generated_deletion_ID",
"DeletionSummary":{
"RemainingCount":3,
"SummaryItems":[
{
"Count":2,
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1,
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"Custom:custom_type_name"
}
```
### Visualización del estado de eliminación
Puede verificar el estado de una operación de eliminación mediante el comando `describe-inventory-deletions` de la AWS CLI. Puede especificar un ID de eliminación para ver el estado de una operación de eliminación específica. Asimismo, puede omitir el ID de eliminación para ver una lista de todas las eliminaciones ejecutadas en los últimos 30 días.
****
1. Ejecute el siguiente comando para ver el estado de una operación de eliminación. El sistema devolvió el ID de eliminación en el resumen de eliminaciones del inventario.
```
aws ssm describe-inventory-deletions --deletion-id system_generated_deletion_ID
```
El sistema devuelve el estado más reciente. Puede que la operación de eliminación no haya terminado todavía. El sistema devuelve información similar a la siguiente.
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 1,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 1,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "InProgress",
"LastStatusMessage": "The Delete is in progress",
"LastStatusUpdateTime": 1521744844,
"TypeName": "Custom:custom_type_name"}
]
}
```
Si la operación de eliminación se realiza correctamente, `LastStatusMessage` indica: Deletion is successful.
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"}
]
}
```
1. Ejecute el siguiente comando para ver una lista de todas las eliminaciones realizadas en los últimos 30 días.
```
aws ssm describe-inventory-deletions --max-results a number
```
```
{"InventoryDeletions":
[
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521682552,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521682852,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521744844,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521745253,
"TypeName": "Custom:custom_type_name"},
{"DeletionId": "system_generated_deletion_ID",
"DeletionStartTime": 1521680145,
"DeletionSummary":
{"RemainingCount": 0,
"SummaryItems":
[
{"Count": 1,
"RemainingCount": 0,
"Version": "1.0"}
],
"TotalCount": 1},
"LastStatus": "Complete",
"LastStatusMessage": "Deletion is successful",
"LastStatusUpdateTime": 1521680471,
"TypeName": "Custom:custom_type_name"}
],
"NextToken": "next-token"
```
### Explicación del resumen de eliminaciones del inventario
Para ayudarle a comprender el contenido del resumen de eliminaciones del inventario, considere el siguiente ejemplo. Un usuario asignó el inventario Custom:RackSpace a tres nodos. Los artículos de inventario 1 y 2 utilizan la versión 1.0 del tipo personalizado ("SchemaVersion":"1.0"). El artículo de inventario 3 utiliza la versión 2.0 del tipo personalizado ("SchemaVersion":"2.0").
Inventario personalizado RackSpace 1
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567890",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
Inventario personalizado RackSpace 2
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567891",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
Inventario personalizado RackSpace 3
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567892",
"SchemaVersion":"2.0" "Content":[
{
content of custom type omitted
}
]
}
```
El usuario ejecuta el siguiente comando para obtener una vista previa de los datos que se eliminarán.
```
aws ssm delete-inventory --type-name "Custom:RackSpace" --dry-run
```
El sistema devuelve información similar a la siguiente.
```
{
"DeletionId":"1111-2222-333-444-66666",
"DeletionSummary":{
"RemainingCount":3,
"TotalCount":3,
TotalCount and RemainingCount are the number of items that would be deleted if this was not a dry run. These numbers are the same because the system didn't delete anything.
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0. Neither item was deleted.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 1.0. This item was not deleted.
"RemainingCount":1,
"Version":"2.0"
}
],
},
"TypeName":"Custom:RackSpace"
}
```
El usuario ejecuta el siguiente comando para eliminar el inventario Custom:RackSpace.
**nota**
El resultado de este comando no muestra el progreso de la eliminación. Por este motivo, `TotalCount` y `RemainingCount` siguen siendo iguales, ya que el sistema no ha eliminado nada todavía. Puede utilizar el comando `describe-inventory-deletions` para mostrar el progreso de la eliminación.
```
aws ssm delete-inventory --type-name "Custom:RackSpace"
```
El sistema devuelve información similar a la siguiente.
```
{
"DeletionId":"1111-2222-333-444-7777777",
"DeletionSummary":{
"RemainingCount":3, There are three items to delete
"SummaryItems":[
{
"Count":2, The system found two items that use SchemaVersion 1.0.
"RemainingCount":2,
"Version":"1.0"
},
{
"Count":1, The system found one item that uses SchemaVersion 2.0.
"RemainingCount":1,
"Version":"2.0"
}
],
"TotalCount":3
},
"TypeName":"RackSpace"
}
```
### Visualización de acciones de eliminación de inventario en EventBridge
Puede configurar Amazon EventBridge para que cree un evento cada vez que un usuario elimine un inventario personalizado. EventBridge ofrece tres tipos de eventos para las operaciones de eliminación de inventarios personalizados:
+ **Acción de eliminación de una instancia**: indica si el inventario personalizado de un nodo administrado específico se ha eliminado correctamente o no.
+ **Resumen de la acción de eliminación**: muestra un resumen de la acción de eliminación.
+ **Advertencia de tipo de inventario personalizado desactivado**: se genera un evento de advertencia si un usuario llama a la operación [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) de la API para una versión de tipo de inventario personalizado que se desactivó anteriormente.
A continuación, se muestran ejemplos de cada evento.
**Acción de eliminación de una instancia**
```
{
"version":"0",
"id":"998c9cde-56c0-b38b-707f-0411b3ff9d11",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:24:34Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0a5feb270fc3f0b97"
],
"detail":{
"action-status":"succeeded",
"action":"delete",
"resource-type":"managed-instance",
"resource-id":"i-0a5feb270fc3f0b97",
"action-reason":"",
"type-name":"Custom:MyInfo"
}
}
```
**Resumen de la acción de eliminación**
```
{
"version":"0",
"id":"83898300-f576-5181-7a67-fb3e45e4fad4",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:28:25Z",
"region":"us-east-1",
"resources":[
],
"detail":{
"action-status":"succeeded",
"action":"delete-summary",
"resource-type":"managed-instance",
"resource-id":"",
"action-reason":"The delete for type name Custom:MyInfo was completed. The deletion summary is: {\"totalCount\":2,\"remainingCount\":0,\"summaryItems\":[{\"version\":\"1.0\",\"count\":2,\"remainingCount\":0}]}",
"type-name":"Custom:MyInfo"
}
}
```
**Advertencia de tipo de inventario personalizado desactivado**
```
{
"version":"0",
"id":"49c1855c-9c57-b5d7-8518-b64aeeef5e4a",
"detail-type":"Inventory Resource State Change",
"source":"aws.ssm",
"account":"478678815555",
"time":"2018-05-24T22:46:58Z",
"region":"us-east-1",
"resources":[
"arn:aws:ssm:us-east-1:478678815555:managed-instance/i-0ee2d86a2cfc371f6"
],
"detail":{
"action-status":"failed",
"action":"put",
"resource-type":"managed-instance",
"resource-id":"i-0ee2d86a2cfc371f6",
"action-reason":"The inventory item with type name Custom:MyInfo was sent with a disabled schema version 1.0. You must send a version greater than 1.0",
"type-name":"Custom:MyInfo"
}
}
```
Utilice el siguiente procedimiento para crear una regla de EventBridge para las operaciones de eliminación de inventarios personalizados. En este procedimiento se muestra cómo crear una regla que envíe notificaciones de las operaciones de eliminación de inventarios personalizados a un tema de Amazon SNS. Antes de comenzar, compruebe que tiene un tema de Amazon SNS o cree uno nuevo. Para obtener más información, consulte [Introducción](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html) en la *Guía para desarrolladores de Amazon Simple Notification Service*.
**Para configurar EventBridge para la eliminación de operaciones de inventario**
1. Abra la consola de Amazon EventBridge en [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. En el panel de navegación, seleccione **Reglas**.
1. Elija **Creación de regla**.
1. Escriba un nombre y una descripción para la regla.
Una regla no puede tener el mismo nombre que otra regla de la misma región y del mismo bus de eventos.
1. En **Bus de eventos**, seleccione el bus de eventos que desea asociar a esta regla. Si desea que esta regla responda a eventos coincidentes procedentes de su propia Cuenta de AWS, seleccione **default** (predeterminado). Cuando un Servicio de AWS en su cuenta emite un evento, siempre va al bus de eventos predeterminado de su cuenta.
1. En **Tipo de regla**, elija **Regla con un patrón de evento**.
1. Elija **Siguiente**.
1. En **Origen del evento**, elija **Eventos de AWS o eventos de socios de EventBridge**.
1. En la sección **Event pattern** (Patrón de eventos), elija **Event pattern form** (Formulario de patrón de eventos).
1. Para **Event source** (origen de eventos), elija **AWSservices** (servicios).
1. En **AWS service** (Servicio de ), elija **Systems Manager**.
1. Para **Event type** (Tipo de evento), elija **Inventory** (Inventario).
1. En **Specific detail type(s)** (Tipos de detalles específicos), elija **Inventory Resource State Change** (Cambio de estado de recursos de inventario).
1. Elija **Siguiente**.
1. En **Target types** (Tipos de destino), elija **AWS service**.
1. En **Select a target** (Seleccione un destino), elija **SNS topic** (Tema de SNS) y, a continuación, elija el tema en **Topic** (Tema).
1. En la sección **Additional settings** (Ajustes adicionales), en **Configure target input** (Configurar entrada de destino), verifique que **Matched event** (Evento coincidente) está seleccionado.
1. Elija **Siguiente**.
1. (Opcional) Introduzca una o varias etiquetas para la regla. Para obtener más información, consulte [Etiquetado de los recursos de Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html) en la *Guía del usuario de Amazon EventBridge*.
1. Elija **Siguiente**.
1. Revise los detalles de la regla y seleccione **Creación de regla**.
# Visualización del seguimiento de cambios y del historial de Inventory
Puede ver el historial de AWS Systems Manager Inventory y el seguimiento de cambios de todos los nodos administrados mediante [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/). AWS Config proporciona una vista detallada de la configuración de los recursos de AWS en su Cuenta de AWS. Esto incluye cómo se relacionan los recursos entre sí y cómo se han configurado en el pasado, para que pueda ver cómo las configuraciones y las relaciones cambian a lo largo del tiempo. Para ver el seguimiento de cambios y el historial de inventario, debe activar los siguientes recursos en AWS Config:
+ SSM:ManagedInstanceInventory
+ SSM:PatchCompliance
+ SSM:AssociationCompliance
+ SSM:FileData
**nota**
Tenga en cuenta los siguientes detalles importantes acerca del historial y el seguimiento de cambios de Inventory:
Si usa AWS Config para realizar un seguimiento de los cambios en el sistema, debe configurar Systems Manager Inventory para recopilar los metadatos `AWS:File` y, así, poder ver los cambios de archivos en AWS Config (`SSM:FileData`). Si no lo hace, AWS Config no realizará un seguimiento de los cambios de archivos en el sistema.
Cuando activa SSM:PatchCompliance y SSM:AssociationCompliance, puede ver el seguimiento de cambios y el historial de la aplicación de parches de Systems Manager Patch Manager y de la conformidad de las asociaciones de Systems Manage State Manager. Para obtener más información sobre la administración de la conformidad para estos recursos, consulte [Detalles sobre el cumplimiento](compliance-about.md).
En el siguiente procedimiento, se describe cómo activar el registro del seguimiento de cambios y el historial de inventario en AWS Config mediante la AWS Command Line Interface (AWS CLI). Para obtener más información acerca de cómo elegir y configurar estos recursos en AWS Config, consulte [Selección de los recursos que debe registrar AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html) en la *Guía para desarrolladores de AWS Config*. Para obtener información sobre precios de AWS Config, consulte [precios](https://aws.amazon.com/config/pricing/).
**Antes de empezar**
AWS Config requiere permisos de AWS Identity and Access Management (IAM) para obtener los detalles de configuración de los recursos de Systems Manager. En el siguiente procedimiento, debe especificar el nombre de recurso de Amazon (ARN) de un rol de IAM que concede permisos a AWS Config para los recursos de Systems Manager. Puede adjuntar la política administrada `AWS_ConfigRole` al rol de IAM que va a asignar a AWS Config. Para obtener más información acerca de este rol, consulte [Política administrada de AWS: AWS\$1Configrole](https://docs.aws.amazon.com/config/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AWS_ConfigRole) en la *Guía para desarrolladores de AWS Config*. Para obtener información acerca de cómo crear un rol de IAM y asignar la política administrada por `AWS_ConfigRole` a ese rol, consulte [Creación de un rol para delegar permisos a un servicio de Servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) en la *Guía del usuario de IAM*.
**Para activar el registro del seguimiento de cambios y el historial de inventario en AWS Config**
1. 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).
1. Copie y pegue la siguiente muestra de JSON en un archivo de texto sencillo y guárdelo como recordingGroup.json.
```
{
"allSupported":false,
"includeGlobalResourceTypes":false,
"resourceTypes":[
"AWS::SSM::AssociationCompliance",
"AWS::SSM::PatchCompliance",
"AWS::SSM::ManagedInstanceInventory",
"AWS::SSM::FileData"
]
}
```
1. Ejecute el siguiente comando para cargar el archivo recordingGroup.json en AWS Config.
```
aws configservice put-configuration-recorder --configuration-recorder name=myRecorder,roleARN=arn:aws:iam::123456789012:role/myConfigRole --recording-group file://recordingGroup.json
```
1. Ejecute el siguiente comando para empezar a registrar el seguimiento de cambios y el historial de inventario.
```
aws configservice start-configuration-recorder --configuration-recorder-name myRecorder
```
Después de configurar el historial y el seguimiento de cambios, puede desglosar el historial para ver un nodo administrado específico mediante el botón **AWS Config** en la consola de Systems Manager. Puede acceder al botón **AWS Config** desde la página **Instancias administradas** o **Inventario**. En función del tamaño del monitor, es posible que tenga que desplazarse a la parte derecha de la página para ver el botón.
# Cómo detener la recopilación de datos y eliminación de datos de inventario
Si ya no desea utilizar AWS Systems Manager Inventory para ver metadatos sobre los recursos de AWS, puede detener la recopilación de datos y eliminar los datos que ya se han recopilado. Esta sección incluye la siguiente información.
**Topics**
+ [Cómo detener la recopilación de datos](#systems-manager-inventory-delete-association)
+ [Cómo eliminar una sincronización de datos de recursos de inventario](#systems-manager-inventory-delete-RDS)
## Cómo detener la recopilación de datos
Cuando configura inicialmente Systems Manager para recopilar datos de inventario, el sistema crea una asociación de State Manager que define la programación y los recursos a partir de los cuales recopilar metadatos. Puede detener la recopilación de datos si elimina cualquier asociaciones de State Manager que utilice el documento `AWS-GatherSoftwareInventory`.
**Cómo eliminar una asociación de inventario**
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**.
1. Elija una asociación que utilice el documento `AWS-GatherSoftwareInventory` y, a continuación, elija **Delete** (Eliminar).
1. Repita el paso tres para cualquier asociación restante que utilice el documento `AWS-GatherSoftwareInventory`.
## Cómo eliminar una sincronización de datos de recursos de inventario
Si ya no desea utilizar AWS Systems Manager Inventory para ver metadatos sobre los recursos de AWS, se recomienda que elimine las sincronizaciones de datos de recursos que se utilizan para la recopilación de datos de inventario.
**Cómo eliminar una sincronización de datos de recursos de inventario**
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 **Inventory**.
1. Elija **Resource Data Syncs** (Sincronización de datos de recursos).
1. En la lista, elija un nombre.
**importante**
Asegúrese de elegir la sincronización utilizada para el inventario. Systems Manager admite la sincronización de datos de recursos para varias herramientas. Si elige una sincronización incorrecta, podría interrumpir la agregación de datos para Systems Managero Explorer o Systems Manager Compliance.
1. Elija **Delete** (Eliminar)
1. Repita estos pasos para cualquier sincronización de datos de recursos restante que desee eliminar.
1. Elimine el bucket de Amazon Simple Storage Service (Amazon S3) en el que se almacenaron los datos. Para obtener información acerca de cómo se elimina un bucket de Amazon S3, consulte [Deleting a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html) (Eliminación de un bucket).
# Asignación de metadatos de inventarios personalizados a un nodo administrado
El siguiente procedimiento presenta el proceso de utilizar la operación [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html) de la API de AWS Systems Manager para asignar los metadatos de inventarios personalizados a un nodo administrado. En este ejemplo se asigna información de ubicación de bastidores a un nodo. Para obtener más información acerca del inventario personalizado, consulte [Uso del inventario personalizado](inventory-custom.md).
**Para asignar metadatos de inventarios personalizados a un nodo**
1. 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).
1. Ejecute el siguiente comando para asignar la información acerca de la ubicación de bastidores a un nodo.
**Linux**
```
aws ssm put-inventory --instance-id "ID" --items '[{"CaptureTime": "2016-08-22T10:01:01Z", "TypeName": "Custom:RackInfo", "Content":[{"RackLocation": "Bay B/Row C/Rack D/Shelf E"}], "SchemaVersion": "1.0"}]'
```
**Windows**
```
aws ssm put-inventory --instance-id "ID" --items "TypeName=Custom:RackInfo,SchemaVersion=1.0,CaptureTime=2021-05-22T10:01:01Z,Content=[{RackLocation='Bay B/Row C/Rack D/Shelf F'}]"
```
1. Ejecute el siguiente comando para ver las entradas de inventario personalizado para este nodo.
```
aws ssm list-inventory-entries --instance-id ID --type-name "Custom:RackInfo"
```
El sistema devuelve información similar a la siguiente.
```
{
"InstanceId": "ID",
"TypeName": "Custom:RackInfo",
"Entries": [
{
"RackLocation": "Bay B/Row C/Rack D/Shelf E"
}
],
"SchemaVersion": "1.0",
"CaptureTime": "2016-08-22T10:01:01Z"
}
```
1. Ejecute el siguiente comando para ver el esquema de inventario personalizado.
```
aws ssm get-inventory-schema --type-name Custom:RackInfo
```
El sistema devuelve información similar a la siguiente.
```
{
"Schemas": [
{
"TypeName": "Custom:RackInfo",
"Version": "1.0",
"Attributes": [
{
"DataType": "STRING",
"Name": "RackLocation"
}
]
}
]
}
```
# Uso de la AWS CLI para configurar la recopilación de datos de inventario
En los siguientes procedimientos se presenta el proceso de configuración de AWS Systems Manager Inventory para la recopilación de metadatos desde los nodos administrados. Cuando configure la recopilación de inventario, empiece creando una asociación de Systems Manager State Manager. Systems Manager recopila los datos de inventario cuando se ejecuta la asociación. Si no crea la asociación en primer lugar e intenta invocar el complemento `aws:softwareInventory` mediante, por ejemplo, el uso de Systems Manager Run Command, el sistema regresará el siguiente error:
`The aws:softwareInventory plugin can only be invoked via ssm-associate`.
**nota**
Un nodo solo puede tener una única asociación a inventario configurada a la vez. Si configura un nodo con dos o más asociaciones a inventario, la asociación no funciona y no se recopilan los datos de inventario.
## Configuración rápida de todos los nodos administrados para Inventory (CLI)
Puede configurar rápidamente todos los nodos administrados en la Cuenta de AWS y en la región actual para la recopilación de datos de inventario. Esto se conoce como creación de una asociación de inventario global. Para crear una asociación de inventario global mediante la AWS CLI, utilice la opción comodín del valor `instanceIds`, tal y como se muestra en el siguiente procedimiento:
**Para configurar el inventario para todos los nodos administrados en la Cuenta de AWS y en la región actual (CLI)**
1. 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).
1. Ejecute el siguiente comando.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name AWS-GatherSoftwareInventory \
--targets Key=InstanceIds,Values=* \
--schedule-expression "rate(1 day)" \
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name AWS-GatherSoftwareInventory ^
--targets Key=InstanceIds,Values=* ^
--schedule-expression "rate(1 day)" ^
--parameters applications=Enabled,awsComponents=Enabled,customInventory=Enabled,instanceDetailedInformation=Enabled,networkConfig=Enabled,services=Enabled,windowsRoles=Enabled,windowsUpdates=Enabled
```
------
**nota**
Este comando no permite que Inventory recopile metadatos para los archivos o el registro de Windows. Para inventariar estos tipos de datos, utilice el siguiente procedimiento.
## Configuración manual de Inventory en los nodos administrados (CLI)
Utilice el siguiente procedimiento para configurar manualmente AWS Systems Manager Inventory en los nodos administrados mediante ID o etiquetas de nodo.
**Para configurar manualmente los nodos administrados para Inventory (CLI)**
1. 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).
1. Ejecute el siguiente comando para crear una asociación de State Manager que ejecute Systems Manager Inventory en el nodo. Reemplace cada *example resource placeholder* con su propia información. Este comando configura que el servicio se ejecute cada seis horas y que se recopilen los metadatos de configuración de la red, de Windows Update y de las aplicaciones de un nodo.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=an_instance_ID" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=an_instance_ID" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"region_ID, for example us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
El sistema devuelve información similar a la siguiente.
```
{
"AssociationDescription": {
"ScheduleExpression": "rate(240 minutes)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "Test",
"OutputS3BucketName": "Test bucket",
"OutputS3Region": "us-east-2"
}
},
"Name": "The name you specified",
"Parameters": {
"applications": [
"Enabled"
],
"networkConfig": [
"Enabled"
],
"windowsUpdates": [
"Enabled"
]
},
"Overview": {
"Status": "Pending",
"DetailedStatus": "Creating"
},
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "$DEFAULT",
"LastUpdateAssociationDate": 1480544990.06,
"Date": 1480544990.06,
"Targets": [
{
"Values": [
"i-02573cafcfEXAMPLE"
],
"Key": "InstanceIds"
}
]
}
}
```
Puede dirigirse a grandes grupos de nodos de destino mediante el parámetro `Targets` con etiquetas de EC2. Consulte el siguiente ejemplo.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=tag:Environment,Values=Production" \
--schedule-expression "rate(240 minutes)" \
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" \
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=tag:Environment,Values=Production" ^
--schedule-expression "rate(240 minutes)" ^
--output-location "{ \"S3Location\": { \"OutputS3Region\": \"us-east-2\", \"OutputS3BucketName\": \"amzn-s3-demo-bucket\", \"OutputS3KeyPrefix\": \"Test\" } }" ^
--parameters "networkConfig=Enabled,windowsUpdates=Enabled,applications=Enabled"
```
------
También puede realizar un inventario de claves de archivos y del registro de Windows en un nodo de Windows Server mediante los tipos de inventario `files` y `windowsRegistry` con expresiones. Para obtener más información acerca de estos tipos de inventario, consulte [Uso del inventario de archivos y del registro de Windows](inventory-file-and-registry.md).
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name "AWS-GatherSoftwareInventory" \
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" \
--schedule-expression "rate(240 minutes)" \
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' \
--profile dev-pdx
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name "AWS-GatherSoftwareInventory" ^
--targets "Key=instanceids,Values=i-0704358e3a3da9eb1" ^
--schedule-expression "rate(240 minutes)" ^
--parameters '{"files":["[{\"Path\": \"C:\\Program Files\", \"Pattern\": [\"*.exe\"], \"Recursive\": true}]"], "windowsRegistry": ["[{\"Path\":\"HKEY_LOCAL_MACHINE\\Software\\Amazon\", \"Recursive\":true}]"]}' ^
--profile dev-pdx
```
------
1. Ejecute el siguiente comando para ver el estado de la asociación.
```
aws ssm describe-instance-associations-status --instance-id an_instance_ID
```
El sistema devuelve información similar a la siguiente.
```
{
"InstanceAssociationStatusInfos": [
{
"Status": "Pending",
"DetailedStatus": "Associated",
"Name": "reInvent2016PolicyDocumentTest",
"InstanceId": "i-1a2b3c4d5e6f7g",
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "1"
}
]
}
```
# Explicación: cómo utilizar la sincronización de datos de recursos para agregar datos de inventario
La siguiente explicación describe cómo crear una configuración de sincronización de datos de recursos para AWS Systems Manager Inventory con la AWS Command Line Interface (AWS CLI). Una sincronización de datos de recursos transfiere automáticamente los datos de inventario de todos los nodos administrados a un bucket de Amazon Simple Storage Service (Amazon S3) central. La sincronización actualiza automáticamente los datos del bucket de Amazon S3 central siempre que se detectan nuevos datos de inventario.
En esta explicación también se describe cómo utilizar Amazon Athena y Amazon Quick para consultar y analizar los datos agregados. Para obtener información acerca de cómo crear una sincronización de datos de recursos mediante Systems Manager en la Consola de administración de AWS, consulte [Explicación: cómo utilizar la sincronización de datos de recursos para agregar datos de inventario](#inventory-resource-data-sync). Para obtener información sobre la consulta de inventario desde varias Regiones de AWS y cuentas mediante Systems Manager en la Consola de administración de AWS, consulte [Consulta de datos de Inventory de varias regiones y cuentas](systems-manager-inventory-query.md).
**nota**
Este tutorial incluye información sobre cómo cifrar la sincronización mediante AWS Key Management Service (AWS KMS). Inventory no recopila los datos privados, específicos del usuario ni información confidencial, por lo que el cifrado es opcional. Para obtener más información acerca de AWS KMS, consulte [Guía para desarrolladores de AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/).
**Antes de empezar**
Revise o complete las siguientes tareas antes de comenzar la explicación en esta sección:
+ Recopile datos de inventario de los nodos administrados. A efectos de las secciones de Amazon Athena y Amazon Quick en esta explicación, se recomienda que recopile los datos de la aplicación. Para obtener más información acerca de cómo se recopilan los datos de inventario, consulte [Configuración de la recopilación de inventario](inventory-collection.md) o [Uso de la AWS CLI para configurar la recopilación de datos de inventario](inventory-collection-cli.md).
+ (Opcional) Si los datos de inventario se almacenan en un bucket de Amazon Simple Storage Service (Amazon S3) que utiliza el cifrado de AWS Key Management Service (AWS KMS), también configure la cuenta de IAM y el rol de servicio de `Amazon-GlueServiceRoleForSSM` para el cifrado de AWS KMS. Si no configura su cuenta de IAM y este rol, Systems Manager muestra `Cannot load Glue tables` cuando elige la pestaña **Vista detallada** en la consola. Para obtener más información, consulte [(Opcional) Configuración de permisos para ver datos cifrados de AWS KMS](systems-manager-inventory-query.md#systems-manager-inventory-query-kms).
+ (Opcional) Si desea cifrar la sincronización de datos de recursos mediante AWS KMS, cree una clave nueva que incluya la siguiente política o actualice una clave existente y agréguele esta política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "ssm-access-policy",
"Statement": [
{
"Sid": "ssm-access-policy-statement",
"Action": [
"kms:GenerateDataKey"
],
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Resource": "arn:aws:kms:us-east-1:123456789012:key/KMS_key_id",
"Condition": {
"StringLike": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:ssm:*:123456789012:resource-data-sync/*"
}
}
}
]
}
```
------
**Cómo crear una sincronización de datos de recursos para Inventory**
1. Abra la consola de Amazon S3 en [https://console.aws.amazon.com/s3](https://console.aws.amazon.com/s3/).
1. Cree un bucket para almacenar los datos de inventario agregados. Para obtener más información, consulte [Creación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) en la *Guía del usuario de Amazon Simple Storage Service*. Anote el nombre de bucket y la Región de AWS donde lo creó.
1. Después de crear el bucket, seleccione la pestaña **Permisos** y, a continuación, elija **Política de bucket**.
1. Copie y pegue la siguiente política de bucket en el editor de políticas. Reemplace amzn-s3-demo-bucket y *account-id* por el nombre del bucket de Amazon S3 que ha creado y un ID de Cuenta de AWS válido. Al agregar varias cuentas, agrega una cadena de condición adicional y un ARN para cada cuenta. Elimine los marcadores de posición adicionales del ejemplo al añadir una cuenta. Si lo desea, reemplace *bucket-prefix* por el nombre de un prefijo de Amazon S3 (subdirectorio). Si no ha creado un prefijo, quite *bucket-prefix/* del ARN de la política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": " SSMBucketDelivery",
"Effect": "Allow",
"Principal": {
"Service": "ssm.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/bucket-prefix/*/accountid=111122223333/*"
],
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": [
"111122223333",
"444455556666",
"123456789012",
"777788889999"
]
},
"ArnLike": {
"aws:SourceArn": [
"arn:aws:ssm:*:111122223333:resource-data-sync/*",
"arn:aws:ssm:*:444455556666:resource-data-sync/*",
"arn:aws:ssm:*:123456789012:resource-data-sync/*",
"arn:aws:ssm:*:777788889999:resource-data-sync/*"
]
}
}
}
]
}
```
------
1. (Opcional) Si desea cifrar la sincronización, debe agregar las siguientes condiciones a la política del paso anterior. Agréguelas en la sección `StringEquals`.
```
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
```
A continuación se muestra un ejemplo:
```
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control",
"aws:SourceAccount": "account-id",
"s3:x-amz-server-side-encryption":"aws:kms",
"s3:x-amz-server-side-encryption-aws-kms-key-id":"arn:aws:kms:region:account_ID:key/KMS_key_ID"
}
```
1. 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).
1. (Opcional) Si desea cifrar la sincronización, ejecute el siguiente comando para comprobar que la política del bucket esté implementando el requisito de clave de AWS KMS. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ \
--sse aws:kms \
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" \
--region region, for example, us-east-2
```
------
#### [ Windows ]
```
aws s3 cp ./A_file_in_the_bucket s3://amzn-s3-demo-bucket/prefix/ ^
--sse aws:kms ^
--sse-kms-key-id "arn:aws:kms:region:account_ID:key/KMS_key_id" ^
--region region, for example, us-east-2
```
------
1. Ejecute el siguiente comando para crear una configuración de sincronización de datos de recursos con el bucket de Amazon S3 que ha creado al inicio de este procedimiento. Este comando crea una sincronización de la Región de AWS en la que ha iniciado sesión.
**nota**
Si la sincronización y el bucket de Amazon S3 de destino se encuentran en regiones diferentes, es posible que esté sujeto a precios de transferencia de datos. Para obtener más información, consulte [Precios de Amazon S3](https://aws.amazon.com/s3/pricing/).
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name a_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name a_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,Region=bucket_region"
```
------
Puede utilizar el parámetro `region` para especificar si debe crearse la configuración de la sincronización. En el siguiente ejemplo, los datos de inventario de la región us-west-1 se sincronizarán en el bucket de Amazon S3 en la región us-west-2.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name InventoryDataWest \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2"
--region us-west-1
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name InventoryDataWest ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=HybridEnv,SyncFormat=JsonSerDe,Region=us-west-2" ^ --region us-west-1
```
------
(Opcional) Si desea cifrar la sincronización mediante AWS KMS, ejecute el siguiente comando para crear la sincronización. Si cifra la sincronización, la clave de AWS KMS y el bucket de Amazon S3 deben estar en la misma región.
------
#### [ Linux & macOS ]
```
aws ssm create-resource-data-sync \
--sync-name sync_name \
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" \
--region region
```
------
#### [ Windows ]
```
aws ssm create-resource-data-sync ^
--sync-name sync_name ^
--s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix_name, if_specified,SyncFormat=JsonSerDe,AWSKMSKeyARN=arn:aws:kms:region:account_ID:key/KMS_key_ID,Region=bucket_region" ^
--region region
```
------
1. Ejecute el siguiente comando para ver el estado de la configuración de la sincronización.
```
aws ssm list-resource-data-sync
```
Si ha creado la configuración de la sincronización en una región distinta, debe especificar el parámetro `region` tal y como se muestra en el siguiente ejemplo.
```
aws ssm list-resource-data-sync --region us-west-1
```
1. Después de haber creado correctamente la configuración de la sincronización, examine el bucket de destino en Amazon S3. Los datos de inventario deberían aparecer en unos minutos.
**Cómo utilizar los datos en Amazon Athena**
En la siguiente sección se describe cómo ver y consultar los datos en Amazon Athena. Antes de comenzar, le recomendamos que conozca Athena. Para obtener más información, consulte [¿Qué es Amazon Athena?](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) y [Uso de datos](https://docs.aws.amazon.com/athena/latest/ug/work-with-data.html) en la *Guía del usuario de Amazon Athena*.
**Cómo ver y consultar los datos en Amazon Athena**
1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home).
1. Copie y pegue la siguiente instrucción en el editor de consultas y, a continuación, elija **Ejecutar consulta**.
```
CREATE DATABASE ssminventory
```
El sistema crea una base de datos denominada ssminventory.
1. Copie y pegue la siguiente instrucción en el editor de consultas y, a continuación, elija **Ejecutar consulta**. Reemplace amzn-s3-demo-bucket y *bucket\$1prefix* por el nombre y el prefijo del destino de Amazon S3.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Application (
Name string,
ResourceId string,
ApplicationType string,
Publisher string,
Version string,
InstalledTime string,
Architecture string,
URL string,
Summary string,
PackageId string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket_prefix/AWS:Application/'
```
1. Copie y pegue la siguiente instrucción en el editor de consultas y, a continuación, elija **Ejecutar consulta**.
```
MSCK REPAIR TABLE ssminventory.AWS_Application
```
El sistema particiona la tabla.
**nota**
Si crea sincronizaciones de datos de recursos de otras Regiones de AWS o Cuentas de AWS, deberá ejecutar este comando de nuevo para actualizar las particiones. Es posible que también deba actualizar la política del bucket de Amazon S3.
1. Para realizar una vista previa de los datos, elija el icono de visualización que aparece junto a la tabla `AWS_Application`.
![\[Icono de vista previa de datos en Amazon Athena.\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/sysman-inventory-resource-data-sync-walk.png)
1. Copie y pegue la siguiente instrucción en el editor de consultas y, a continuación, elija **Ejecutar consulta**.
```
SELECT a.name, a.version, count( a.version) frequency
from aws_application a where
a.name = 'aws-cfn-bootstrap'
group by a.name, a.version
order by frequency desc
```
La consulta regresa un recuento de diferentes versiones de `aws-cfn-bootstrap`, que es una aplicación de AWS presente en instancias de Amazon Elastic Compute Cloud (Amazon EC2) para Linux, macOS y Windows Server.
1. Copie y pegue una por una las siguientes instrucciones en el editor de consultas, reemplace amzn-s3-demo-bucket y *bucket-prefix* por los datos de Amazon S3 y, a continuación, seleccione **Ejecutar consulta**. Estas instrucciones configuran otras tablas de inventario en Athena.
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_AWSComponent (
`ResourceId` string,
`Name` string,
`ApplicationType` string,
`Publisher` string,
`Version` string,
`InstalledTime` string,
`Architecture` string,
`URL` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:AWSComponent/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_AWSComponent
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_WindowsUpdate (
`ResourceId` string,
`HotFixId` string,
`Description` string,
`InstalledTime` string,
`InstalledBy` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:WindowsUpdate/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_WindowsUpdate
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_InstanceInformation (
`AgentType` string,
`AgentVersion` string,
`ComputerName` string,
`IamRole` string,
`InstanceId` string,
`IpAddress` string,
`PlatformName` string,
`PlatformType` string,
`PlatformVersion` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:InstanceInformation/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_InstanceInformation
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_Network (
`ResourceId` string,
`Name` string,
`SubnetMask` string,
`Gateway` string,
`DHCPServer` string,
`DNSServer` string,
`MacAddress` string,
`IPV4` string,
`IPV6` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:Network/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_Network
```
```
CREATE EXTERNAL TABLE IF NOT EXISTS ssminventory.AWS_PatchSummary (
`ResourceId` string,
`PatchGroup` string,
`BaselineId` string,
`SnapshotId` string,
`OwnerInformation` string,
`InstalledCount` int,
`InstalledOtherCount` int,
`NotApplicableCount` int,
`MissingCount` int,
`FailedCount` int,
`OperationType` string,
`OperationStartTime` string,
`OperationEndTime` string
)
PARTITIONED BY (AccountId string, Region string, ResourceType string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = '1'
) LOCATION 's3://amzn-s3-demo-bucket/bucket-prefix/AWS:PatchSummary/'
```
```
MSCK REPAIR TABLE ssminventory.AWS_PatchSummary
```
**Cómo utilizar los datos en Amazon Quick**
En la siguiente sección se proporciona información general con enlaces para crear una visualización en Amazon Quick.
**Cómo crear una visualización en Amazon Quick**
1. Regístrese en [Amazon Quick](https://quicksight.aws/) y, a continuación, inicie sesión en la consola de Quick.
1. Cree un conjunto de datos a partir de la tabla `AWS_Application` y de cualquier otra tabla que haya creado. Para obtener más información, consulte [Creación de un conjunto de datos con datos de Amazon Athena](https://docs.aws.amazon.com/quicksuite/latest/userguide/create-a-data-set-athena.html) en la *Guía del usuario de Amazon Quick*.
1. Combine las tablas. Por ejemplo, puede combinar la columna `instanceid` de `AWS_InstanceInformation` porque coincide con la columna `resourceid` en otras tablas de inventario. Para obtener más información sobre cómo unir tablas, consulte [Unión de datos](https://docs.aws.amazon.com/quicksuite/latest/userguide/joining-data.html) en la *Guía del usuario de Amazon Quick*.
1. Cree una visualización. Para obtener más información, consulte [Análisis e informes: visualización de datos en Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/working-with-visuals.html) en la *Guía del usuario de Amazon Quick*.
# Solución de problemas con Systems Manager Inventory
Este tema contiene información acerca de cómo solucionar errores o problemas comunes de AWS Systems Manager Inventory. Si tiene problemas para ver los nodos en Systems Manager, consulte [Solución de problemas de disponibilidad de nodos administrados](fleet-manager-troubleshooting-managed-nodes.md).
**Topics**
+ [No se admiten varias aplicaciones de todas las asociaciones con el documento “`AWS-GatherSoftwareInventory`”](#systems-manager-inventory-troubleshooting-multiple)
+ [El estado de ejecución del inventario nunca sale de pendiente](#inventory-troubleshooting-pending)
+ [El documento `AWS-ListWindowsInventory` no se ejecuta](#inventory-troubleshooting-ListWindowsInventory)
+ [La consola no muestra Inventario con las pestañas Panel \$1 Vista detallada \$1 Configuración](#inventory-troubleshooting-tabs)
+ [UnsupportedAgent](#inventory-troubleshooting-unsupported-agent)
+ [Omitido](#inventory-troubleshooting-skipped)
+ [Failed](#inventory-troubleshooting-failed)
+ [Error de cumplimiento del inventario de una instancia de Amazon EC2](#inventory-troubleshooting-ec2-compliance)
+ [El objeto de bucket de S3 contiene datos antiguos](#systems-manager-inventory-troubleshooting-s3)
## No se admiten varias aplicaciones de todas las asociaciones con el documento “`AWS-GatherSoftwareInventory`”
Un error `Multiple apply all associations with document 'AWS-GatherSoftwareInventory' are not supported` significa que una o varias Regiones de AWS donde está intentando configurar una asociación de Inventory *para todos los nodos* ya están configuradas con una asociación de inventario para todos los nodos. Si es necesario, puede eliminar la asociación de inventario existente para todos los nodos y, a continuación, crear una nueva. Para ver las asociaciones de inventario existentes, elija **State Manager** en la consola de Systems Manager y, a continuación, busque las asociaciones que utilizan el documento de SSM `AWS-GatherSoftwareInventory`. Si la asociación de inventario existente para todos los nodos se creó en varias regiones y desea crear una nueva, debe eliminar la asociación existente de cada región donde haya una.
## El estado de ejecución del inventario nunca sale de pendiente
Hay dos razones por las que la recopilación de inventario nunca sale del estado `Pending`:
+ No hay nodos en la seleccionada Región de AWS:
Si crea una asociación de inventario global mediante Systems Manager Quick Setup, el estado de la asociación de inventario (documento `AWS-GatherSoftwareInventory`) muestra `Pending` si no hay nodos disponibles en la región seleccionada.****
+ Permisos insuficientes:
Una asociación de inventario muestra `Pending` si uno o más nodos no tienen permiso para ejecutar Systems Manager Inventory. Compruebe que el perfil de instancias de AWS Identity and Access Management (IAM) incluye la política administrada **AmazonSSMManagedInstanceCore**. Para obtener información acerca de cómo agregar esta política a un perfil de instancias, consulte [Configuración alternativa para permisos de instancia de EC2](setup-instance-permissions.md#instance-profile-add-permissions).
Como mínimo, el perfil de instancias debe tener los siguientes permisos de IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation",
"ssm:GetDocument",
"ssm:DescribeDocument"
],
"Resource": "*"
}
]
}
```
------
## El documento `AWS-ListWindowsInventory` no se ejecuta
El documento `AWS-ListWindowsInventory` está obsoleto. No utilice este documento para recopilar el inventario. En su lugar, utilice uno de los procesos que se describen en [Configuración de la recopilación de inventario](inventory-collection.md).
## La consola no muestra Inventario con las pestañas Panel \$1 Vista detallada \$1 Configuración
La página **Vista detallada** de Inventory solo está disponible en la Regiones de AWS que ofrece Amazon Athena. Si las siguientes pestañas no se muestran en la página de Inventory, significa que Athena no está disponible en la región y que no puede utilizar la **Vista detallada** para consultar datos.
![\[Visualización de Inventario con las pestañas Panel | Vista detallada | Configuración\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
## UnsupportedAgent
Si el estado detallado de una asociación de inventario es **UnsupportedAgent** y el valor de **Estado de la asociación** es **Error**, la versión de AWS Systems Manager SSM Agent del nodo administrado no es correcta. Para crear una asociación de inventario global (un inventario de todos los nodos de la Cuenta de AWS), debe utilizar, por ejemplo, la versión 2.0.790.0 de SSM Agent u otra versión posterior. En la página **Instancias administradas**, en la sección **Versión del agente**, puede ver la versión del agente que se ejecuta en cada nodo. Para obtener más información sobre cómo actualizar el SSM Agent en los nodos, consulte [Actualización de SSM Agent mediante Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
## Omitido
Si el estado de la asociación de inventario de un nodo muestra **Omitido**, esto significa que una asociación de inventario de mayor prioridad ya se está ejecutando en ese nodo. Systems Manager sigue un orden de prioridad específico cuando se pueden aplicar varias asociaciones de inventario al mismo nodo administrado.
### Orden de prioridad de asociación de inventario
Systems Manager aplica las asociaciones de inventario en el siguiente orden de prioridad:
1. **Asociaciones de inventario de Quick Setup**: asociaciones creadas con Quick Setup y la consola unificada. Estas asociaciones tienen nombres que comienzan por `AWS-QuickSetup-SSM-CollectInventory-` y se dirigen a todos los nodos administrados.
1. **Asociaciones de inventario explícitas**: asociaciones que se dirigen a nodos administrados específicos mediante:
+ ID de instancia
+ Pares clave-valor de etiqueta
+ Grupos de recursos de AWS
1. **Asociaciones de inventario global**: asociaciones que se dirigen a todos los nodos administrados (con `--targets "Key=InstanceIds,Values=*"`) pero que **no** se crearon a través de Quick Setup.
### Escenarios habituales
**Escenario 1: la asociación de Quick Setup anula la asociación explícita**
+ Tienes una asociación de inventario de Quick Setup dirigida a todas las instancias
+ Puede crear una asociación manual dirigida a nodos administrados específicos por etiqueta
+ Resultado: la asociación manual muestra `Skipped` con un estado detallado `OverriddenByExplicitInventoryAssociation`
+ La asociación Quick Setup sigue recopilando el inventario de todas las instancias
**Escenario 2: la asociación explícita anula la asociación global**
+ Tienes una asociación de inventario global dirigida a todas las instancias (no creada por Quick Setup)
+ Crear una asociación para instancias de destino específicas
+ Resultado: la asociación global muestra `Skipped` para las instancias de destino específicas
+ La asociación explícita se ejecuta en las instancias de destino
### Pasos de resolución
**Si quiere usar su propia asociación de inventario en lugar de Quick Setup:**
1. **Identifique asociaciones de Quick Setup**: en la consola de Systems Manager, vaya a State Manager y busque asociaciones cuyos nombres comiencen por `AWS-QuickSetup-SSM-CollectInventory-`.
1. **Elimine la configuración de Quick Setup**:
+ Vaya a Quick Setup en la consola de Systems Manager.
+ Busque su configuración de recopilación de inventario.
+ Elimina la configuración de Quick Setup (esto elimina la asociación de inventario asociada).
**nota**
No es necesario eliminar manualmente la asociación creada por Quick Setup.
1. **Compruebe que la asociación se ejecute**: tras eliminar la configuración de Quick Setup, su asociación de inventario explícita debería empezar a ejecutarse correctamente.
**Si quiere modificar el comportamiento existente:**
+ Para ver todas las asociaciones de inventario existentes, elija **State Manager** en la consola de Systems Manager y, a continuación, busque las asociaciones que utilizan el documento de SSM `AWS-GatherSoftwareInventory`.
+ Recuerde que cada nodo administrado solo puede tener una asociación de inventario activa a la vez.
**importante**
Los datos de inventario se siguen recopilando de los nodos omitidos cuando se ejecuta la asociación de inventario asignada (de mayor prioridad).
Las asociaciones de inventario de Quick Setup tienen prioridad sobre todos los demás tipos, incluso aquellas con destinos explícitos.
El mensaje de estado detallado `OverriddenByExplicitInventoryAssociation` aparece cuando una asociación es sustituida por una de mayor prioridad, independientemente del tipo de asociación.
## Failed
Si el estado de la asociación de inventario de un nodo es **Error**, podría significar que el nodo tiene varias asociaciones de inventario asignadas. Un nodo solo puede tener una asociación de inventario asignada a la vez. Las asociaciones de inventario utilizan el documento `AWS-GatherSoftwareInventory` de AWS Systems Manager (documento de SSM). Puede ejecutar el siguiente comando mediante la AWS Command Line Interface (AWS CLI) para ver una lista de las asociaciones de un nodo.
```
aws ssm describe-instance-associations-status --instance-id instance-ID
```
## Error de cumplimiento del inventario de una instancia de Amazon EC2
Se puede producir un error de cumplimiento del inventario de una instancia de Amazon Elastic Compute Cloud (Amazon EC2) si se asignan varias asociaciones de inventario a la instancia.
Para resolver este problema, elimine una o más asociaciones de inventario asignadas a la instancia. Para obtener más información, consulte [Eliminación de una asociación](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html).
**nota**
Tenga en cuenta el siguiente comportamiento si crea varias asociaciones de inventario para un nodo administrado:
A cada nodo se le puede asignar una asociación de inventario que se dirija a *todos* los nodos (--targets "Key=InstanceIds,Values=\$1").
A cada nodo también se le puede asignar una asociación específica que utilice pares clave-valor de etiqueta o un grupo de recursos de AWS.
Si a un nodo se le asignan varias asociaciones de inventario, el estado muestra *Omitido* para la asociación que no se ha ejecutado. La asociación que se ha ejecutado más recientemente muestra el estado real de la asociación de inventario.
Si a un nodo se le asignan varias asociaciones de inventario y cada una utiliza un par clave-valor de etiqueta, esas asociaciones de inventario no se ejecutan en el nodo debido al conflicto de etiqueta. La asociación sigue ejecutándose en nodos que no tienen el conflicto clave-valor de etiqueta.
## El objeto de bucket de S3 contiene datos antiguos
Los datos del objeto de bucket de Amazon S3 se actualizan cuando la asociación del inventario se realiza correctamente y se descubren datos nuevos. El objeto de bucket de Amazon S3 se actualiza para cada nodo cuando la asociación se ejecuta y se produce un error, pero los datos del objeto no se actualizan en este caso. Los datos del objeto de bucket de Amazon S3 se actualizarán únicamente cuando la asociación se ejecute correctamente. Cuando se produzca un error en la asociación del inventario, verá datos antiguos en el objeto de bucket de Amazon S3.
# 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`
# AWS Systems Manager Run Command
Con Run Command, una herramienta de AWS Systems Manager, puede administrar de forma remota y segura la configuración de los nodos administrados. Un *nodo administrado* es cualquier instancia de Amazon Elastic Compute Cloud (Amazon EC2) o cualquier máquina que no sea de EC2, en su entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types), que se haya configurado para Systems Manager. Run Command permite automatizar las tareas administrativas comunes y realizar cambios de configuración de una sola vez a escala. Puede utilizar Run Command desde la Consola de administración de AWS, la AWS Command Line Interface (AWS CLI), AWS Tools for Windows PowerShell o los AWS SDK. Run Command se ofrece sin costo adicional. Para comenzar a utilizar Run Command, abra la [consola de Systems Manager](https://console.aws.amazon.com//systems-manager/run-command). En el panel de navegación, elija **Run Command**.
Los administradores utilizan Run Command instalar o arrancar aplicaciones, crear una canalización de implementación, capturar archivos de registros cuando se elimina una instancia de un grupo de escalado automático, unir instancias a un dominio de Windows, y más.
La API de Run Command sigue un modelo de consistencia final debido a la naturaleza distribuida del sistema que admite la API. Esto significa que el resultado de ejecutar un comando de API que afecte a los recursos que tiene podría no estar inmediatamente visible para todos los comandos posteriores que ejecute. Debe tenérselo en cuenta cuando se ejecute un comando de API que siga inmediatamente a un comando de API anterior.
**Introducción**
En la siguiente tabla, se incluye información para ayudarlo a comenzar a utilizar Run Command.
****
| Topic | Details |
| --- | --- |
| [Configuración de nodos administrados para AWS Systems Manager](systems-manager-setting-up-nodes.md) | Verifique que haya completado los requisitos de configuración para las instancias de Amazon Elastic Compute Cloud (Amazon EC2) y las máquinas que no sean de EC2 en un entorno [híbrido y multinube.](operating-systems-and-machine-types.md#supported-machine-types) |
| [Administrador de nodos en entornos híbridos y multinube con Systems Manager](systems-manager-hybrid-multicloud.md) | (Opcional) Registre los servidores locales y las máquinas virtuales en AWS para poder administrarlos con Run Command. |
| [Administración de dispositivos periféricos con Systems Manager](systems-manager-setting-up-edge-devices.md) | (Opcional) Configure dispositivos de borde para que pueda administrarlos mediante Run Command. |
| [Ejecución de comandos en nodos administrados](running-commands.md) | Obtenga información sobre cómo ejecutar un comando que se dirige a uno o varios nodos administrados mediante la Consola de administración de AWS. |
| [Tutoriales de Run Command](run-command-walkthroughs.md) | Aprenda cómo ejecutar comandos mediante Tools for Windows PowerShell o la AWS CLI. |
**Compatibilidad con EventBridge**
Esta herramienta de Systems Manager se admite como un tipo de *evento* y un tipo de *destino* en las reglas de Amazon EventBridge. Para obtener más información, consulte [Cómo monitorear eventos de Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md) y [Referencia: patrones y tipos de eventos de Amazon EventBridge para Systems Manager](reference-eventbridge-events.md).
**Más información**
+ [Remotely Run Command on an EC2 Instance (10 minute tutorial)](https://aws.amazon.com/getting-started/hands-on/remotely-run-commands-ec2-instance-systems-manager/) (Uso remoto de Run Command en una instancia de EC2 [tutorial de 10 minutos])
+ [Service Quotas de Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html#limits_ssm) en la *Referencia general de Amazon Web Services*
+ [AWS Systems Manager Referencia de la API de](https://docs.aws.amazon.com/systems-manager/latest/APIReference/)
**Topics**
+ [Cómo configurar Run Command](run-command-setting-up.md)
+ [Ejecución de comandos en nodos administrados](running-commands.md)
+ [Uso de códigos de salida en los comandos](run-command-handle-exit-status.md)
+ [Descripción de los estados del comando](monitor-commands.md)
+ [Tutoriales de Run Command](run-command-walkthroughs.md)
+ [Solución de problemas Systems Manager Run Command](troubleshooting-remote-commands.md)
# Cómo configurar Run Command
Antes de poder administrar nodos con Run Command, una herramienta de AWS Systems Manager, debe configurar una política de AWS Identity and Access Management (IAM) para todos los usuarios que vayan a ejecutar comandos. Si utiliza alguna clave de condición global para la acción `SendCommand` en sus políticas de IAM, debe incluir la clave de condición `aws:ViaAWSService` y establecer el valor booleano en `true`. A continuación se muestra un ejemplo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/YourDocument"
],
"Condition": {
"StringEquals": {
"aws:SourceVpce": [
"vpce-1234567890abcdef0"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/YourDocument"
],
"Condition": {
"Bool": {
"aws:ViaAWSService": "true"
}
}
}
]
}
```
------
También debe configurar los nodos para Systems Manager. Para obtener más información, consulte [Configuración de nodos administrados para AWS Systems Manager](systems-manager-setting-up-nodes.md).
Le recomendamos completar las siguientes tareas de configuración opcionales para ayudar a minimizar la posición de seguridad y la gestión diaria de los nodos administrados.
Monitoreo de la ejecución de comandos con Amazon EventBridge
Puede utilizar EventBridge para registrar los cambios de estado de la ejecución de comandos. Tiene la opción de crear una regla que se ejecute siempre que haya una transición de estado o cuando haya una transición a uno o varios estados de interés. También puede especificar Run Command como una acción de destino cuando se produce un evento de EventBridge. Para obtener más información, consulte [Configuración de EventBridge para eventos de Systems Manager](monitoring-systems-manager-events.md).
Monitoreo de la ejecución de comandos con los Registros de Amazon CloudWatch
Puede configurar Run Command para que envíe periódicamente todos los resultados y los registros de errores de los comandos a un grupo de registros de Amazon CloudWatch. Puede monitorizar estos registros de salida prácticamente en tiempo real, buscar frases, valores o patrones específicos y crear alarmas en función de la búsqueda. Para obtener más información, consulte [Configuración de Registros de Amazon CloudWatch para Run Command](sysman-rc-setting-up-cwlogs.md).
Restrinja el acceso de Run Command a nodos administrados específicos
Puede restringir la capacidad de un usuario para ejecutar comandos en nodos administrados mediante AWS Identity and Access Management (IAM). En concreto, puede crear una política de IAM con la condición de que el usuario solo pueda ejecutar comandos en nodos administrados que estén etiquetados con etiquetas específicas. Para obtener más información, consulte [Restricción de acceso de Run Command basado en etiquetas](#tag-based-access).
## Restricción de acceso de Run Command basado en etiquetas
En esta sección se describe cómo restringir la capacidad de un usuario para ejecutar comandos en nodos administrados especificando una condición de etiqueta en una política de IAM. Los nodos administrados incluyen instancias de Amazon EC2 y nodos que no son de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) configurado para Systems Manager. Aunque la información no se presenta explícitamente, también puede restringir el acceso a dispositivos de núcleo administrados de AWS IoT Greengrass. Para comenzar, debe etiquetar los dispositivos de AWS IoT Greengrass. Para obtener más información, consulte [Etiquetar los recursos de AWS IoT Greengrass Version 2](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) en la *Guía para desarrolladores de AWS IoT Greengrass Version 2*.
Puede restringir la ejecución de comandos a determinados nodos administrados mediante la creación de una política de IAM que incluya la condición de que el usuario solo pueda ejecutar comandos en los nodos que tengan determinadas etiquetas. En el ejemplo siguiente, el usuario tiene permitido utilizar Run Command (`Effect: Allow, Action: ssm:SendCommand`) mediante cualquier documento de SSM (`Resource: arn:aws:ssm:*:*:document/*`) en cualquier nodo (`Resource: arn:aws:ec2:*:*:instance/*`) con la condición de que el nodo sea un servidor web de finanzas (`ssm:resourceTag/Finance: WebServer`). Si el usuario envía un comando a un nodo que no está etiquetado o que tiene una etiqueta que no es `Finance: WebServer`, los resultados de la ejecución mostrarán `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:*:*:document/*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ec2:*:*:instance/*"
],
"Condition":{
"StringLike":{
"ssm:resourceTag/Finance":[
"WebServers"
]
}
}
}
]
}
```
------
Puede crear políticas de IAM que permitan al usuario ejecutar comandos en los nodos administrados etiquetados con varias etiquetas. La siguiente política permite al usuario ejecutar comandos en nodos administrados que tienen dos etiquetas. Si un usuario envía un comando a un nodo que no está etiquetado con estas dos etiquetas, los resultados de la ejecución mostrarán `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key1":[
"tag_value1"
],
"ssm:resourceTag/tag_key2":[
"tag_value2"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:us-west-1::document/AWS-*",
"arn:aws:ssm:us-east-2::document/AWS-*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:UpdateInstanceInformation",
"ssm:ListCommands",
"ssm:ListCommandInvocations",
"ssm:GetDocument"
],
"Resource":"*"
}
]
}
```
------
También puede crear políticas de IAM que permitan al usuario ejecutar comandos en varios grupos de nodos administrados etiquetados. La siguiente política de ejemplo permite al usuario ejecutar comandos en uno de los grupos de nodos etiquetados o en ambos grupos.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key1":[
"tag_value1"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag_key2":[
"tag_value2"
]
}
}
},
{
"Effect":"Allow",
"Action":[
"ssm:SendCommand"
],
"Resource":[
"arn:aws:ssm:us-west-1::document/AWS-*",
"arn:aws:ssm:us-east-2::document/AWS-*"
]
},
{
"Effect":"Allow",
"Action":[
"ssm:UpdateInstanceInformation",
"ssm:ListCommands",
"ssm:ListCommandInvocations",
"ssm:GetDocument"
],
"Resource":"*"
}
]
}
```
------
Para obtener más información acerca de la creación de políticas de IAM, consulte [Políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) en la *Guía del usuario de IAM*. Para obtener más información acerca del etiquetado de nodos administrados, consulte [Editor de etiquetas](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) en la *Guía del usuario de Grupos de recursos de AWS*.
# Ejecución de comandos en nodos administrados
Esta sección contiene información sobre cómo enviar comandos desde la consola de AWS Systems Manager a nodos administrados. La sección también incluye información acerca de cómo cancelar un comando.
Tenga en cuenta que siisu nodo está configurado con la opción de montaje `noexec` para el directorio var, Run Command no podrá ejecutar correctamente los comandos.
**importante**
Cuando ejecute un comando con Run Command, no incluya información confidencial como texto sin formato, por ejemplo, contraseñas, datos de configuración u otros secretos. Toda la actividad de la API de Systems Manager de la cuenta se registra en un bucket de S3, para registros de AWS CloudTrail. Esto significa que cualquier usuario con acceso al bucket de S3 puede ver los valores en texto sin formato de esos secretos. Por este motivo, le recomendamos crear y utilizar parámetros `SecureString` para cifrar la información confidencial que utiliza en las operaciones de Systems Manager.
Para obtener más información, consulte [Restringir el acceso a los parámetros de Parameter Store mediante políticas de IAM](sysman-paramstore-access.md).
**Retención del historial de ejecución**
El historial de cada comando está disponible durante un máximo de 30 días. Además, puede almacenar una copia de todos los archivos de registro en Amazon Simple Storage Service o disponer de un registro de auditoría de todas las llamadas de API en AWS CloudTrail.
**Información relacionada**
Para obtener más información acerca de cómo enviar comandos con otras herramientas, consulte los siguientes temas:
+ [Tutorial: uso de la AWS Tools for Windows PowerShell con Run Command](walkthrough-powershell.md) o consulte los ejemplos de la [sección de AWS Systems Manager de Referencia de Cmdlet de Herramientas de AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/reference/items/AWS_Systems_Manager_cmdlets.html).
+ [Tutorial: uso de la AWS CLI con Run Command](walkthrough-cli.md) o los ejemplos de la [Referencia de la CLI de SSM](https://docs.aws.amazon.com/cli/latest/reference/ssm/)
**Topics**
+ [Ejecución de comandos desde la consola](running-commands-console.md)
+ [Ejecución de comandos mediante una versión de documento específica](run-command-version.md)
+ [Ejecución de comandos a escala](send-commands-multiple.md)
+ [Cancelación de un comando](cancel-run-command.md)
# Ejecución de comandos desde la consola
Puede utilizar Run Command, una herramienta de AWS Systems Manager, desde la Consola de administración de AWS para configurar nodos administrados sin tener que iniciar sesión en ellos. En este tema, se incluye un ejemplo en el que se muestra cómo [actualizar SSM Agent](run-command-tutorial-update-software.md#rc-console-agentexample) en un nodo administrado utilizando Run Command.
**Antes de empezar**
Antes de enviar un comando con Run Command, verifique que los nodos administrados cumplan los [requisitos de configuración](systems-manager-setting-up-nodes.md) de Systems Manager.
**Para enviar un comando con Run Command**
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 un documento de Systems Manager.
1. En la sección **Command Parameters**, especifique los valores de los parámetros obligatorios.
1. En la sección **Targets** (Destinos), para elegir los nodos administrados en los que desea ejecutar esta operación, especifique las etiquetas, seleccione las instancias o los dispositivos de borde manualmente o especifique un grupo de recursos.
**sugerencia**
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. En **Otros parámetros**:
+ En **Comentario**, ingrese la información acerca de este comando.
+ En **Tiempo de espera (segundos)**, especifique el número de segundos que tiene que esperar el sistema antes de indicar que se ha producido un error en la ejecución del comando general.
1. En **Rate control** (Control de velocidad):
+ En **Concurrency** (Simultaneidad), especifique un número o un porcentaje de los nodos administrados en los que desea ejecutar el comando al mismo tiempo.
**nota**
Si seleccionó los destinos mediante la especificación de etiquetas aplicadas a nodos administrados o de grupos de recursos de AWS y no está seguro de cuántos nodos administrados tienen destino, limite el número de destinos que puede ejecutar el documento al mismo tiempo. Para ello, especifique un porcentaje.
+ En **Error threshold** (Umbral de errores), especifique cuándo desea parar la ejecución del comando en los demás nodos administrados después de que haya fallado en un número o un porcentaje de los nodos. Por ejemplo, si especifica tres errores, Systems Manager dejará de enviar el comando cuando se reciba el cuarto error. Los nodos administrados que estén procesando el comando todavía pueden enviar errores.
1. (Opcional) Elija una alarma de CloudWatch que desee aplicar al comando para fines de monitoreo. Para adjuntar una alarma de CloudWatch a su comando, la entidad principal de IAM que lo ejecute debe tener permiso para la acción `iam:createServiceLinkedRole`. Para obtener más información sobre las alarmas de CloudWatch, consulte [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Tenga en cuenta que si la alarma se activa, no se ejecutará ninguna invocación de comando pendiente.
1. (Opcional) En **Opciones de salida**, para guardar la salida del comando en un archivo, seleccione el cuadro **Write command output to an S3 bucket**. 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 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 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, 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. En la sección **Notificaciones de SNS**, seleccione la casilla de verificación **Habilitar notificaciones de SNS** si desea recibir notificaciones sobre el estado de ejecución de los comandos.
Para obtener más información acerca de la configuración de las notificaciones de Amazon SNS para Run Command, consulte [Cómo monitorear los cambios de estado de Systems Manager mediante las notificaciones de Amazon SNS](monitoring-sns-notifications.md).
1. Seleccione **Ejecutar**.
Para obtener más información acerca de la cancelación de un comando, consulte [Cancelación de un comando](cancel-run-command.md).
## Volver a ejecutar comandos
Systems Manager incluye dos opciones que lo ayudarán a volver a ejecutar un comando desde la página de **Run Command** en la consola de Systems Manager.
+ **Rerun** (Volver a ejecutar): este botón le permite ejecutar el mismo comando sin realizarle cambios.
+ **Copy to new (Copiar en nuevo)**: este botón copia la configuración de un comando en un comando nuevo y le ofrece la opción de editar esa configuración antes de ejecutarlo.
**Para volver a ejecutar un comando**
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 el comando que desea volver a ejecutar. Puede volver a ejecutar un comando inmediatamente después de ejecutarlo desde la página de detalles del comando. O bien, puede elegir un comando que haya ejecutado anteriormente en la pestaña **Command history** (Historial de comandos).
1. Elija **Rerun (Volver a ejecutar)** para ejecutar el mismo comando sin realizar ningún cambio o elija **Copy to new (Copiar en nuevo)** para editar la configuración del comando antes de ejecutarlo.
# Ejecución de comandos mediante una versión de documento específica
Puede utilizar el parámetro document-version para especificar la versión de un documento de AWS Systems Manager que se va a usar cuando se ejecute el comando. Puede especificar una de las opciones siguientes para este parámetro:
+ \$1DEFAULT
+ \$1LATEST
+ Número de versión
Lleve a cabo el siguiente procedimiento para ejecutar un comando utilizando el parámetro de versión del documento.
------
#### [ Linux ]
**Para ejecutar comandos mediante la AWS CLI en equipos locales con Linux**
1. 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).
1. Enumerar todos los documentos disponibles
Este comando enumera todos los documentos disponibles para su cuenta en función de los permisos de AWS Identity and Access Management (IAM).
```
aws ssm list-documents
```
1. Ejecute el siguiente comando para ver las diferentes versiones de un documento. Reemplace el *nombre del documento* con su propia información.
```
aws ssm list-document-versions \
--name "document name"
```
1. Utilice el siguiente comando para ejecutar un comando que utilice una versión del documento de SSM. Reemplace cada *example resource placeholder* con su propia información.
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--parameters commands="echo Hello" \
--instance-ids instance-ID \
--document-version '$LATEST'
```
------
#### [ Windows ]
**Para ejecutar comandos mediante la AWS CLI en equipos locales con Windows**
1. 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).
1. Enumerar todos los documentos disponibles
Este comando enumera todos los documentos disponibles para su cuenta en función de los permisos de AWS Identity and Access Management (IAM).
```
aws ssm list-documents
```
1. Ejecute el siguiente comando para ver las diferentes versiones de un documento. Reemplace el *nombre del documento* con su propia información.
```
aws ssm list-document-versions ^
--name "document name"
```
1. Utilice el siguiente comando para ejecutar un comando que utilice una versión del documento de SSM. Reemplace cada *example resource placeholder* con su propia información.
```
aws ssm send-command ^
--document-name "AWS-RunShellScript" ^
--parameters commands="echo Hello" ^
--instance-ids instance-ID ^
--document-version "$LATEST"
```
------
#### [ PowerShell ]
**Para ejecutar comandos con Tools for PowerShell**
1. Instale y configure Herramientas de AWS para PowerShell (Herramientas para Windows PowerShell), si aún no lo ha hecho.
Para obtener más información, consulte [Instalación de Herramientas de AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Enumerar todos los documentos disponibles
Este comando enumera todos los documentos disponibles para su cuenta en función de los permisos de AWS Identity and Access Management (IAM).
```
Get-SSMDocumentList
```
1. Ejecute el siguiente comando para ver las diferentes versiones de un documento. Reemplace el *nombre del documento* con su propia información.
```
Get-SSMDocumentVersionList `
-Name "document name"
```
1. Utilice el siguiente comando para ejecutar un comando que utilice una versión del documento de SSM. Reemplace cada *example resource placeholder* con su propia información.
```
Send-SSMCommand `
-DocumentName "AWS-RunShellScript" `
-Parameter @{commands = "echo helloWorld"} `
-InstanceIds "instance-ID" `
-DocumentVersion $LATEST
```
------
# Ejecución de comandos a escala
Puede utilizar Run Command, una herramienta de AWS Systems Manager, para ejecutar comandos en una flota de nodos administrados mediante `targets`. El parámetro `targets` acepta una combinación de `Key,Value` basada en las etiquetas que haya especificado en los nodos administrados. Al ejecutar el comando, el sistema localiza e intenta ejecutar dicho comando en todos los nodos administrados que coinciden con las etiquetas especificadas. Para obtener más información sobre el etiquetado de instancias administradas consulte, [Etiquetado de recursos de AWS](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-editor.html) en la *Guía del usuario de Etiquetado de recursos de AWS*. Para obtener más información acerca del etiquetado de dispositivos IoT administrados, consulte [Etiquetado de recursos de AWS IoT Greengrass Version 2](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) en la *Guía para desarrolladores de AWS IoT Greengrass Version 2*.
También puede utilizar el parámetro `targets` para dirigirse a una lista de ID de nodos administrados específicos, tal y como se describe en la sección siguiente.
Para controlar la forma en que los comandos ejecutan cientos o miles de nodos administrados, Run Command también incluye parámetros con el fin de restringir cuántos nodos puede procesar una solicitud simultáneamente y qué cantidad de errores puede generar un comando antes de finalizar.
**Topics**
+ [Indicar destino de varios nodos administrados](#send-commands-targeting)
+ [Cómo utilizar controles de velocidad](#send-commands-rate)
## Indicar destino de varios nodos administrados
Puede ejecutar un comando y dirigirse a nodos administrados especificando etiquetas, nombres de grupos de recursos de AWS o ID de nodos administrados.
En los siguientes ejemplos, se muestra el formato de comandos cuando se utiliza Run Command desde la AWS Command Line Interface (AWS CLI ). Reemplace cada *example resource placeholder* con su propia información. Los ejemplos de comandos de esta sección se truncan con `[...]`.
**Ejemplo 1: dirigirse a etiquetas**
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:tag-name,Values=tag-value \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:tag-name,Values=tag-value ^
[...]
```
------
**Ejemplo 2: dirigirse a un grupo de recursos de AWS por nombre**
Puede especificar un máximo de un nombre de grupo de recursos por comando. Al crear un grupo de recursos, le recomendamos que incluya `AWS::SSM:ManagedInstance` y `AWS::EC2::Instance` como tipos de recursos en sus criterios de creación de grupo.
**nota**
Con el fin de enviar comandos que tengan como destino un grupo de recursos, debe haber recibido los permisos de AWS Identity and Access Management (IAM) para mostrar o ver los recursos que pertenecen a ese grupo. Para obtener más información, consulte la sección [Configuración de permisos](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions) en la *Guía del usuario de Grupos de recursos de AWS*.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=resource-groups:Name,Values=resource-group-name \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=resource-groups:Name,Values=resource-group-name ^
[...]
```
------
**Ejemplo 3: dirigirse a un grupo de recursos de AWS por tipo de recurso**
Puede especificar un máximo de cinco tipos de grupos de recursos por comando. Al crear un grupo de recursos, le recomendamos que incluya `AWS::SSM:ManagedInstance` y `AWS::EC2::Instance` como tipos de recursos en sus criterios de creación de grupo.
**nota**
Con el fin de enviar comandos que tienen como destino un grupo de recursos, se le deben haber concedido los permisos de IAM para mostrar o ver los recursos que pertenecen a ese grupo. Para obtener más información, consulte la sección [Configuración de permisos](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions) en la *Guía del usuario de Grupos de recursos de AWS*.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=resource-groups:ResourceTypeFilters,Values=resource-type-1,resource-type-2 \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=resource-groups:ResourceTypeFilters,Values=resource-type-1,resource-type-2 ^
[...]
```
------
**Ejemplo 4: dirigirse a ID de instancias**
En los siguientes ejemplos, se muestra cómo dirigirse a nodos administrados mediante la clave de `instanceids` con el parámetro `targets`. Puede utilizar esta clave para dirigirse a dispositivos de núcleo de AWS IoT Greengrass administrados porque a cada dispositivo se le asigna un mi-*Id\$1number*. Puede ver los ID de los dispositivos en Fleet Manager, una herramienta de AWS Systems Manager.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=instanceids,Values=instance-ID-1,instance-ID-2,instance-ID-3 \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=instanceids,Values=instance-ID-1,instance-ID-2,instance-ID-3 ^
[...]
```
------
Si ha etiquetado nodos administrados para diferentes entornos utilizando una `Key` denominada `Environment` y `Values` de `Development`, `Test`, `Pre-production` y `Production`, podría enviar un comando a todos los nodos administrados que se encuentren en *uno* de estos entornos mediante el uso del parámetro `targets` con la siguiente sintaxis.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Environment,Values=Development \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
------
Podría dirigirse a nodos administrados adicionales en otros entornos agregando elementos a la lista `Values`. Separe los elementos mediante comas.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Environment,Values=Development,Test,Pre-production \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Environment,Values=Development,Test,Pre-production ^
[...]
```
------
**Variación**: refinado de los destinos con varios criterios `Key`
Puede refinar el número de destinos para el comando incluyendo varios criterios `Key`. Si incluye más de un criterio de `Key`, el sistema se dirige a los nodos administrados que cumplen *todos* los criterios. El siguiente comando se dirige a todos los nodos administrados etiquetados para el Departamento de Finanzas *y* etiquetados para el rol de servidor de base de datos.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Finance Key=tag:ServerRole,Values=Database ^
[...]
```
------
**Variación **: uso de varios criterios `Key` y `Value`
Profundizando en el ejemplo anterior, puede dirigirse a varios departamentos y diversas roles de servidor mediante la inclusión de elementos adicionales en el criterio `Values`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database ^
[...]
```
------
**Variación**: dirigirse a nodos administrados etiquetados mediante varios criterios de `Values`
Si etiquetó nodos administrados para diferentes entornos utilizando una `Key` denominada `Department` y `Values` de `Sales` y `Finance`, podría enviar un comando a todos los nodos administrados de estos entornos mediante el uso del parámetro `targets` con la siguiente sintaxis.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values=Sales,Finance \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values=Sales,Finance ^
[...]
```
------
Puede especificar un máximo de cinco claves y cinco valores para cada clave.
Si una clave de etiqueta (el nombre de la etiqueta) o un valor de etiqueta incluye espacios, deberá encerrar la clave de etiqueta o el valor entre comillas, como se muestra en los siguientes ejemplos.
**Ejemplo**: espacios en la etiqueta `Value`
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:OS,Values="Windows Server 2016" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:OS,Values="Windows Server 2016" ^
[...]
```
------
**Ejemplo**: espacios en la clave y `Value` de una `tag`
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key="tag:Operating System",Values="Windows Server 2016" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key="tag:Operating System",Values="Windows Server 2016" ^
[...]
```
------
**Ejemplo**: espacios en un elemento de una lista de `Values`
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--targets Key=tag:Department,Values="Sales","Finance","Systems Mgmt" \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--targets Key=tag:Department,Values="Sales","Finance","Systems Mgmt" ^
[...]
```
------
## Cómo utilizar controles de velocidad
Puede controlar la velocidad a la que se envían los comandos a los nodos administrados de un grupo mediante *controles de simultaneidad * y *controles de error*.
**Topics**
+ [Uso de controles de simultaneidad](#send-commands-velocity)
+ [Uso de controles de error](#send-commands-maxerrors)
### Uso de controles de simultaneidad
Puede controlar el número de nodos administrados que ejecutan el comando al mismo tiempo mediante el parámetro `max-concurrency` (las opciones de **Concurrency** [Simultaneidad] de la página **Run a command** [Ejecutar un comando]). Puede especificar un número absoluto de nodos administrados, por ejemplo, **10**, o un porcentaje del destino definido, por ejemplo, **10%**. El sistema de colas entrega el comando a un único nodo y espera hasta que el sistema confirme la invocación inicial antes de enviar el comando a dos nodos más. El sistema envía comandos de forma exponencial a más nodos hasta que alcanza el valor de `max-concurrency`. El valor predeterminado del valor de `max-concurrency` es 50. Los siguientes ejemplos le muestran cómo especificar valores para el parámetro `max-concurrency`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 10 \
--targets Key=tag:Environment,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 10% \
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 10 ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 10% ^
--targets Key=tag:Department,Values=Finance,Marketing Key=tag:ServerRole,Values=WebServer,Database ^
[...]
```
------
### Uso de controles de error
También puede controlar la ejecución de un comando para cientos o miles de nodos administrado al configurar un límite de error mediante los parámetros `max-errors` (el campo **Error threshold** [Umbral de error] de la página **Run a command** [Ejecutar un comando]). El parámetro especifica la cantidad de errores que están permitidos antes de que el sistema detenga el envío del comando a nodos administrados adicionales. Puede especificar un número absoluto de errores, por ejemplo, **10**, o un porcentaje del destino definido, por ejemplo, **10%**. Si especifica **3**, por ejemplo, el sistema dejará de enviar el comando cuando se reciba el cuarto error. Si especifica **0**, el sistema dejará de enviar el comando a otros nodos administrados tras el primer resultado de error que se devuelva. Si envía un comando a 50 nodos administrados y configura `max-errors` en un **10%**, el sistema dejará de enviar el comando a otros nodos cuando se reciba el sexto error.
Las invocaciones que ya están ejecutando un comando cuando se alcanza el `max-errors` tienen permiso para completarse, pero algunas de estas invocaciones también pueden producir errores. Si necesita asegurarse de que no habrá más de `max-errors` invocaciones erróneas, establezca `max-concurrency` en **1**, de modo que las invocaciones continuarán de una en una. El valor predeterminado para max-errors es 0. Los siguientes ejemplos le muestran cómo especificar valores para el parámetro `max-errors`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name document-name \
--max-errors 10 \
--targets Key=tag:Database,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-errors 10% \
--targets Key=tag:Environment,Values=Development \
[...]
```
```
aws ssm send-command \
--document-name document-name \
--max-concurrency 1 \
--max-errors 1 \
--targets Key=tag:Environment,Values=Production \
[...]
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name document-name ^
--max-errors 10 ^
--targets Key=tag:Database,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-errors 10% ^
--targets Key=tag:Environment,Values=Development ^
[...]
```
```
aws ssm send-command ^
--document-name document-name ^
--max-concurrency 1 ^
--max-errors 1 ^
--targets Key=tag:Environment,Values=Production ^
[...]
```
------
# Cancelación de un comando
Puede intentar cancelar un comando siempre y cuando el servicio muestre que está en estado pendiente o en ejecución. Sin embargo, incluso si un comando todavía tiene alguno de estos estados, no se puede garantizar que el comando se cancelerá y el proceso subyacente se detendrá.
**Para cancelar un comando con la 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. Seleccione la invocación del comando que desea cancelar.
1. Elija **Cancel Command**.
**Para cancelar un comando con la AWS CLI**
Ejecute el siguiente comando de la . Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws ssm cancel-command \
--command-id "command-ID" \
--instance-ids "instance-ID"
```
------
#### [ Windows ]
```
aws ssm cancel-command ^
--command-id "command-ID" ^
--instance-ids "instance-ID"
```
------
Para obtener más información acerca del estado de un comando cancelado, consulte [Descripción de los estados del comando](monitor-commands.md).
# Uso de códigos de salida en los comandos
En algunos casos, es posible que necesite administrar cómo se gestionan los comandos mediante el uso de códigos de salida.
## Especificación de códigos de salida en los comandos
Con Run Command, una herramienta de AWS Systems Manager, puede especificar códigos de salida para determinar cómo se gestionan los comandos. De forma predeterminada, el código de salida del último comando ejecutado en un script se registra como el código de salida de todo el script. Suponga, por ejemplo, que tiene un scripts que contiene tres comandos. El primero da un error, pero los demás se ejecutan correctamente. Como el comando final se ejecutó correctamente, el estado de la ejecución se registra como `succeeded`.
**Scripts de shell**
Para que todo el script produzca un error en el primer error del comando, puede incluir una declaración condicional de intérprete para salir del script si algún comando anterior al último produce un error. Utilice el siguiente enfoque.
```
if [ $? != 0 ]
then
exit
fi
```
En el ejemplo siguiente, se produce un error en todo el script si se produce un error en el primer comando.
```
cd /test
if [ $? != 0 ]
then
echo "Failed"
exit 1
fi
date
```
**Scripts de PowerShell**
PowerShell requiere que llame explícitamente a `exit` en sus scripts para que Run Command capture correctamente el código de salida.
```
if ($?) {}
else {exit }
exit
```
A continuación se muestra un ejemplo:
```
cd C:\
if ($?) {echo "Success"}
else {exit 1}
date
```
# Gestión de reinicios al ejecutar comandos
Si utiliza Run Command, una herramienta de AWS Systems Manager, para ejecutar scripts que reinician nodos administrados, le recomendamos que especifique un código de salida en el script. Si intenta utilizar algún otro mecanismo para reiniciar un nodo desde un script, el estado de ejecución de ese script podría no actualizarse correctamente, aunque el reinicio sea el último paso del script. Para los nodos administrados de Windows, especifique `exit 3010` en el script. Para los nodos administrados de Linux y macOS, especifique `exit 194`. El código de salida indica al agente AWS Systems Manager (SSM Agent) que reinicie el nodo administrado y, a continuación, cuando esa operación haya finalizado, reinicie el script. Antes de comenzar el reinicio, el SSM Agent informará al servicio Systems Manager en la nube que la comunicación se va a interrumpir mientras se reinicia el servidor.
**nota**
El script de reinicio no puede formar parte de un complemento `aws:runDocument`. Si un documento contiene el script de reinicio y otro documento intenta ejecutarlo a través del complemento `aws:runDocument`, SSM Agent devuelve un error.
**Creación de scripts idempotentes**
Al desarrollar scripts que se utilizan para reiniciar nodos administrados, es importante que se asegure de que estos sean idempotentes para que, una vez finalizado el reinicio, la ejecución de los scripts continúe en el punto en que se encontraban anteriormente. Los scripts idempotentes administran el estado y validan si la acción se ha realizado o no. Esto impide que un paso se ejecute varias veces cuando solo está diseñado para ejecutarse una vez.
A continuación, se muestra un ejemplo resumido de un script idempotente que reinicia el nodo administrado varias veces.
```
$name = Get current computer name
If ($name –ne $desiredName)
{
Rename computer
exit 3010
}
$domain = Get current domain name
If ($domain –ne $desiredDomain)
{
Join domain
exit 3010
}
If (desired package not installed)
{
Install package
exit 3010
}
```
**Ejemplos**
En los ejemplos de scripts siguientes, se utilizan códigos de salida para reiniciar nodos administrados. En el ejemplo de Linux, se instalan actualizaciones de paquetes en Amazon Linux y, a continuación, se reinicia el nodo. En el ejemplo de Windows Server, se instala Telnet-Client en el nodo y a continuación se reinicia.
------
#### [ Amazon Linux 2 ]
```
#!/bin/bash
yum -y update
needs-restarting -r
if [ $? -eq 1 ]
then
exit 194
else
exit 0
fi
```
------
#### [ Windows ]
```
$telnet = Get-WindowsFeature -Name Telnet-Client
if (-not $telnet.Installed)
{
# Install Telnet and then send a reboot request to SSM Agent.
Install-WindowsFeature -Name "Telnet-Client"
exit 3010
}
```
------
# Descripción de los estados del comando
Run Command, una herramienta de AWS Systems Manager, ofrece información detallada sobre los diferentes estados que experimenta un comando durante el procesamiento y para cada nodo administrado que procesó el comando. Puede monitorear los estados del comando con los siguientes métodos:
+ Seleccione el icono **Refresh** (actualizar) en la pestaña **Commands** (comandos) de la interfaz de la consola de Run Command.
+ Llame a [list-commands](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-commands.html) o [list-command-invocations](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-command-invocations.html) con la AWS Command Line Interface (AWS CLI). O llame a [Get-SSMCommand](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommand.html) o [Get-SSMCommandInvocation](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommandInvocation.html) con AWS Tools for Windows PowerShell.
+ Configure Amazon EventBridge para que responda a los cambios de estado.
+ Configure Amazon Simple Notification Service (Amazon SNS) para enviar notificaciones de todos los cambios de estado o de estados específicos, como `Failed` o `TimedOut`.
## Run Commandestado
Run Command notifica los detalles de estado de tres áreas: complementos, invocaciones y un estado general del comando. Un *complemento* es un bloque de ejecución de códigos definido en el documento de SSM del comando. Para obtener más información acerca de los complementos, consulte [Referencia de complementos del documento de comandos](documents-command-ssm-plugin-reference.md).
Al enviar un comando para varios nodos administrados al mismo tiempo, cada copia del comando dirigida a cada nodo es una *invocación de comandos*. Por ejemplo, si utiliza el documento `AWS-RunShellScript` y envía un comando `ifconfig` a 20 instancias de Linux, dicho comando tendrá 20 invocaciones. Cada invocación de comandos notifica el estado individualmente. Los complementos para una invocación de comandos determinada también notifican el estado de forma individual.
Por último, Run Command contiene un estado agregado del comando para todos los complementos y las invocaciones. El estado agregado del comando puede ser diferente del estado notificado por los complementos o las invocaciones, como se describe en las siguientes tablas.
**nota**
Si ejecuta comandos para un gran número de nodos administrados utilizando los parámetros `max-concurrency` o `max-errors`, el estado del comando refleja las limitaciones impuestas por esos parámetros, tal y como se describe en las siguientes tablas. Para obtener más información sobre estos parámetros, consulte [Ejecución de comandos a escala](send-commands-multiple.md).
**Estado detallado de los complementos y las invocaciones de comandos**
| Status | Details |
| --- | --- |
| Pending (Pendiente) | El comando aún no se ha enviado al nodo administrado o no ha sido recibido por el SSM Agent. Si el agente no recibe el comando antes de que pase el tiempo que es igual a la suma del parámetro Timeout (seconds) (Tiempo de espera [en segundos]) y del parámetro Execution timeout (Tiempo de espera de ejecución), el estado cambia a Delivery Timed Out. |
| InProgress | Systems Manager está intentando enviar el comando al nodo administrado, o el comando fue recibido por SSM Agent y ha comenzado a ejecutarse en la instancia. En función del resultado de todos los complementos del comando, el estado cambiará a Success, Failed, Delivery Timed Out o Execution Timed Out. Excepción: si el agente no está en ejecución o no está disponible en el nodo, el estado del comando permanece en In Progress hasta que el agente está disponible de nuevo o hasta que se alcanza el límite de tiempo de espera de ejecución. A continuación, el estado cambiará a un estado terminal. |
| Delayed | El sistema intentó enviar el comando al nodo administrado, pero no se envió correctamente. El sistema volverá a intentarlo. |
| Success | Este estado se devuelve en diversas condiciones. Este estado no significa que el comando se procesó en el nodo. Por ejemplo, el comando puede recibirlo SSM Agent en el nodo administrado y devolver un código de salida igual a cero como resultado de que la política ExecutionPolicy de PowerShell impide la ejecución del comando. Se trata de un estado terminal. Las condiciones que provocan que un comando devuelva el estado Success son las siguientes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/monitor-commands.html) Son de aplicación las mismas condiciones al dirigirse a grupos de recursos. Para solucionar los problemas con los errores u obtener más información acerca de la ejecución del comando, envíe un comando que administre los errores o las excepciones devolviendo códigos de salida adecuados (códigos de salida que no sean cero para los errores del comando). |
| DeliveryTimedOut | El comando no se entregó al nodo administrado antes de que se agotara el tiempo de espera total. Los tiempos de espera totales no cuentan para el límite de max-errors del comando principal, pero sí contribuyen a que el estado del comando principal sea Success, Incomplete o Delivery Timed Out. Se trata de un estado terminal. |
| ExecutionTimedOut | La automatización de comandos se inició en el nodo administrado, pero el comando no se completó antes de que se agotara el tiempo de espera de la ejecución. Agotar los tiempos de espera de las ejecuciones cuenta como un error, que enviará una respuesta distinta de cero, y Systems Manager dejará de intentar ejecutar la automatización de comandos e informará de un estado de error. |
| Failed | El comando no se ejecutó correctamente en el nodo administrado. Para un complemento, esto indica que el código de resultado no era cero. Para una invocación de comando, esto indica que el código de resultado de uno o más complementos no era cero. Los errores de invocación cuentan para el max-errors límite del comando principal. Se trata de un estado terminal. |
| Cancelado | El comando se canceló antes de completarse. Se trata de un estado terminal. |
| Undeliverable | El comando no se puede entregar al nodo administrado. Puede que no exista el nodo o que no responda. Las invocaciones no disponibles para entrega no cuentan para el límite de max-errors del comando principal, pero sí contribuyen a que el estado del comando principal sea Success o Incomplete. Por ejemplo, si todas las invocaciones de un comando tienen el estado Undeliverable, el estado del comando que se devuelve es Failed. Sin embargo, si un comando tiene cinco invocaciones, cuatro de las cuales devuelven el estado Undeliverable y una devuelve el estado Success, el estado del comando principal será Success. Se trata de un estado terminal. |
| Terminado | El comando principal supera su max-errors límite y el sistema ha cancelado las posteriores invocaciones de comandos. Se trata de un estado terminal. |
| InvalidPlatform | El comando se envió a un nodo administrado que no coincidía con las plataformas necesarias especificadas por el documento seleccionado. Invalid Platform no cuenta para el límite de máximo de errores del comando principal, pero sí contribuye a que el estado del comando principal sea Success (Correcto) o Failed (Fallido). Por ejemplo, si todas las invocaciones de un comando tienen el estado Invalid Platform, el estado del comando que se devuelve es Failed. Sin embargo, si un comando tiene cinco invocaciones, cuatro de las cuales devuelven el estado Invalid Platform y una devuelve el estado Success, el estado del comando principal será Success. Se trata de un estado terminal. |
| AccessDenied | El usuario o el rol de AWS Identity and Access Management (IAM) que inicia el comando no tiene acceso al nodo administrado de destino. Access Denied no cuenta para el límite de max-errors del comando principal, pero sí contribuye a que el estado del comando principal sea Success o Failed. Por ejemplo, si todas las invocaciones de un comando tienen el estado Access Denied, el estado del comando que se devuelve es Failed. Sin embargo, si un comando tiene cinco invocaciones, cuatro de las cuales devuelven el estado Access Denied y una devuelve el estado Success, el estado del comando principal será Success. Se trata de un estado terminal. |
**Estado detallado de un comando**
| Status | Details |
| --- | --- |
| Pending (Pendiente) | Los agentes de los nodos administrados todavía no reciben el comando. |
| InProgress | El comando se ha enviado al menos a un nodo administrado, pero no ha alcanzado un estado definitivo en ninguno de los nodos. |
| Delayed | El sistema intentó enviar el comando al nodo, pero no se envió correctamente. El sistema volverá a intentarlo. |
| Success | El comando llegó al SSM Agent de todos los nodos administrados especificados o de destino y devolvió el código de salida cero. Todas las invocaciones de comandos han alcanzado un estado terminal y no se alcanzó el valor de max-errors. Este estado no significa que el comando se haya procesado correctamente en todos los nodos administrados especificados o de destino. Se trata de un estado terminal. Para solucionar los problemas con los errores u obtener más información acerca de la ejecución del comando, envíe un comando que administre los errores o las excepciones devolviendo códigos de salida adecuados (códigos de salida que no sean cero para los errores del comando). |
| DeliveryTimedOut | El comando no se entregó al nodo administrado antes de que se agotara el tiempo de espera total. El valor de max-errors o más invocaciones de comandos muestra el estado Delivery Timed Out. Se trata de un estado terminal. |
| Failed | El comando no se ejecutó correctamente en el nodo administrado. El valor de `max-errors` o más invocaciones de comandos muestra el estado `Failed`. Se trata de un estado terminal. |
| Incomplete | El comando se intentó en todos los nodos administrados y una o más de las invocaciones no tiene el valor Success. Sin embargo, no se ha producido error en suficientes invocaciones para que el estado sea Failed. Se trata de un estado terminal. |
| Cancelado | El comando se canceló antes de completarse. Se trata de un estado terminal. |
| RateExceeded | El número de nodos administrados de destino del comando ha superado la cuota de cuenta para las invocaciones pendientes. El sistema ha cancelado el comando antes de ejecutarlo en ningún nodo. Se trata de un estado terminal. |
| AccessDenied | El usuario o el rol que inicia el comando no tiene acceso al grupo de recursos de destino. AccessDenied no cuenta para el límite de max-errors del comando principal, pero sí contribuye a que el estado del comando principal sea Success o Failed. (Por ejemplo, si todas las invocaciones de un comando tienen el estado AccessDenied, entonces el estado del comando que se devuelve es Failed. Sin embargo, si un comando tiene 5 invocaciones, 4 de las cuales devuelven el estado AccessDenied y 1 devuelve el estado Success, entonces el estado del comando principal será Success). Se trata de un estado terminal. |
| No hay instancias en la etiqueta | El grupo de recursos o el valor del par de claves de etiqueta seleccionado por el comando no coincide con ningún nodo administrado. Se trata de un estado terminal. |
## Descripción de los valores de tiempo de espera de los comandos
Systems Manager aplica los siguientes valores de tiempo de espera cuando ejecuta comandos.
**Tiempo de espera total**
En la consola de Systems Manager, especifique el valor del tiempo de espera en el campo **Timeout (seconds)** (Tiempo de espera [segundos]). Después de enviar un comando, Run Command verifica si el comando ha vencido o no. Si un comando alcanza el límite de vencimiento del comando (tiempo de espera total), cambia su estado a `DeliveryTimedOut` para todas las invocaciones que tienen el estado `InProgress`, `Pending` o `Delayed`.
![\[Campo Timeout (seconds) (Tiempo de espera [en segundos]) de la consola de Systems Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/run-command-delivery-time-out-time-out-seconds.png)
En un nivel más técnico, el tiempo de espera total —**Timeout (seconds)** (Tiempo de espera [segundos])— es una combinación de dos valores de tiempo de espera, como se muestra aquí:
`Total timeout = "Timeout(seconds)" from the console + "timeoutSeconds": "{{ executionTimeout }}" from your SSM document`
Por ejemplo, el valor predeterminado de **Timeout (seconds)** (Tiempo de espera [en segundos]) en la consola de Systems Manager es de 600 segundos. Si ejecuta un comando mediante el documento `AWS-RunShellScript` de SSM, el valor predeterminado de **"timeoutSeconds": "\$1\$1 executionTimeout \$1\$1"** es de 3600 segundos, como se muestra en el siguiente ejemplo de documento:
```
"executionTimeout": {
"type": "String",
"default": "3600",
"runtimeConfig": {
"aws:runShellScript": {
"properties": [
{
"timeoutSeconds": "{{ executionTimeout }}"
```
Esto significa que el comando se ejecuta durante 4200 segundos (70 minutos) antes de que el sistema establezca el estado del comando como `DeliveryTimedOut`.
**Tiempo de espera de la ejecución**
En la consola de Systems Manager, especifique el valor del tiempo de espera de la ejecución en el campo **Execution Timeout** (Tiempo de espera de ejecución), si está disponible. No todos los documentos de SSM requieren que especifique un tiempo de espera de ejecución. El campo **Execution Timeout** (Tiempo de espera hasta ejecución) solo se muestra cuando se ha definido un parámetro de entrada correspondiente en el documento de SSM. Si se especifica, el comando debe completarse dentro de este período de tiempo.
**nota**
Run Command se basa en la respuesta terminal del documento del SSM Agent para determinar si el comando se entregó al agente o no. SSM Agent debe enviar una señal de `ExecutionTimedOut` para que una invocación o un comando se marquen como `ExecutionTimedOut`.
![\[Campo Execution Timeout (Tiempo de espera de ejecución) de la consola de Systems Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/run-command-execution-timeout-console.png)
**Tiempo de espera de ejecución predeterminado**
Si un documento de SSM no requiere que especifique explícitamente un valor de tiempo de espera de ejecución, entonces Systems Manager aplica el tiempo de espera de ejecución de codificación rígida predeterminado.
**Cómo informa Systems Manager los tiempos de espera**
Si Systems Manager recibe una respuesta de `execution timeout` del SSM Agent de un destino, Systems Manager marca la invocación del comando como `executionTimeout`.
Si Run Command no recibe una respuesta de terminal del documento de SSM Agent, la invocación del comando se marca como `deliveryTimeout`.
Para determinar el estado del tiempo de espera en un destino, SSM Agent combina todos los parámetros y el contenido del documento de SSM para calcular el `executionTimeout`. Cuando SSM Agent determina que se ha agotado el tiempo de espera para un comando, se envía `executionTimeout` al servicio.
El valor predeterminado de **Timeout (seconds)** (Tiempo de espera [en segundos]) es de 3600 segundos. El valor predeterminado de **Execution Timeout** (Tiempo de espera de ejecución) también es de 3600 segundos. Por lo tanto, el tiempo de espera predeterminado total de un comando es de 7200 segundos.
**nota**
SSM Agent procesa el `executionTimeout` de manera diferente según el tipo de documento de SSM y la versión de este último.
# Tutoriales de Run Command
En los tutoriales de esta sección, se muestra cómo ejecutar comandos con Run Command, una herramienta de AWS Systems Manager, mediante la AWS Command Line Interface (AWS CLI) o AWS Tools for Windows PowerShell.
**Topics**
+ [Actualización del software mediante Run Command](run-command-tutorial-update-software.md)
+ [Tutorial: uso de la AWS CLI con Run Command](walkthrough-cli.md)
+ [Tutorial: uso de la AWS Tools for Windows PowerShell con Run Command](walkthrough-powershell.md)
También puede ver comandos de muestra en las siguientes referencias.
+ [Referencia de la AWS CLI de Systems Manager](https://docs.aws.amazon.com/cli/latest/reference/ssm/)
+ [AWS Tools for Windows PowerShell - AWS Systems Manager](https://docs.aws.amazon.com/powershell/latest/reference/items/SimpleSystemsManagement_cmdlets.html)
# Actualización del software mediante Run Command
En los siguientes procedimientos se describe cómo actualizar el software en los nodos administrados.
## Actualización de SSM Agent mediante Run Command
En el siguiente procedimiento, se describe cómo actualizar el SSM Agent que se ejecuta en los nodos administrados. Puede actualizar a la versión más reciente de SSM Agent o volver a una versión anterior. Cuando se ejecuta el comando, el sistema descarga la versión de AWS, la instala y, a continuación, desinstala la versión que existía antes de ejecutar el comando. Si se produce un error durante este proceso, el sistema vuelve a la versión del servidor anterior a la ejecución del comando y el estado del comando mostrará que el comando ha tenido un error.
**nota**
Si una instancia ejecuta la versión 13.0 (Ventura) o posterior de macOS, la instancia debe tener la versión 3.1.941.0 de SSM Agent o superior para ejecutar el documento de AWS-UpdateSSMAgent. Si la instancia ejecuta una versión de SSM Agent anterior a la 3.1.941.0, puede actualizar SSM Agent para ejecutar el documento de AWS-UpdateSSMAgent si ejecuta los comandos `brew update` y `brew upgrade amazon-ssm-agent`.
Si desea recibir notificaciones sobre actualizaciones de SSM Agent, suscríbase a la página de [SSM Agent Release Notes](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) en GitHub.
**Para actualizar el SSM Agent con Run Command**
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 **`AWS-UpdateSSMAgent`**.
1. En la sección **Command Parameters**, especifique los valores de los parámetros siguientes, si así lo desea:
1. (Opcional) En **Version** (Versión), escriba la versión del SSM Agent que se va a instalar. Puede instalar [versiones anteriores](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) del agente. Si no especifica ninguna versión, el servicio instalará la más reciente.
1. (Opcional). En **Allow Downgrade (Permitir versiones anteriores)**, elija **true** para instalar una versión anterior del SSM Agent. Si elige esta opción, debe especificar el número de la versión [anterior](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md). Elija **false** para instalar solo la versión más reciente del servicio.
1. En la sección **Targets** (Destinos), para elegir los nodos administrados en los que desea ejecutar esta operación, especifique las etiquetas, seleccione las instancias o los dispositivos de borde manualmente o especifique un grupo de recursos.
**sugerencia**
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. En **Otros parámetros**:
+ En **Comentario**, ingrese la información acerca de este comando.
+ En **Tiempo de espera (segundos)**, especifique el número de segundos que tiene que esperar el sistema antes de indicar que se ha producido un error en la ejecución del comando general.
1. En **Rate control** (Control de velocidad):
+ En **Concurrency** (Simultaneidad), especifique un número o un porcentaje de los nodos administrados en los que desea ejecutar el comando al mismo tiempo.
**nota**
Si seleccionó los destinos mediante la especificación de etiquetas aplicadas a nodos administrados o de grupos de recursos de AWS y no está seguro de cuántos nodos administrados tienen destino, limite el número de destinos que puede ejecutar el documento al mismo tiempo. Para ello, especifique un porcentaje.
+ En **Error threshold** (Umbral de errores), especifique cuándo desea parar la ejecución del comando en los demás nodos administrados después de que haya fallado en un número o un porcentaje de los nodos. Por ejemplo, si especifica tres errores, Systems Manager dejará de enviar el comando cuando se reciba el cuarto error. Los nodos administrados que estén procesando el comando todavía pueden enviar errores.
1. (Opcional) En **Opciones de salida**, para guardar la salida del comando en un archivo, seleccione el cuadro **Write command output to an S3 bucket**. 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 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 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, 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. En la sección **Notificaciones de SNS**, seleccione la casilla de verificación **Habilitar notificaciones de SNS** si desea recibir notificaciones sobre el estado de ejecución de los comandos.
Para obtener más información acerca de la configuración de las notificaciones de Amazon SNS para Run Command, consulte [Cómo monitorear los cambios de estado de Systems Manager mediante las notificaciones de Amazon SNS](monitoring-sns-notifications.md).
1. Seleccione **Ejecutar**.
## Actualización de PowerShell con Run Command
En el siguiente procedimiento, se describe cómo actualizar PowerShell a la versión 5.1 en los nodos administrados de Windows Server 2012 y 2012 R2. El script proporcionado en este procedimiento descarga la actualización de Windows Management Framework (WMF) versión 5.1 e inicia la instalación de la actualización. El nodo se reinicia durante este proceso debido a que es necesario cuando se instala WMF 5.1. La descarga y la instalación de la actualización tardan aproximadamente cinco minutos en completarse.
**Para actualizar PowerShell con Run Command**
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 **`AWS-RunPowerShellScript`**.
1. En la sección **Commands** (Comandos), pegue los siguientes comandos para el sistema operativo.
------
#### [ Windows Server 2012 R2 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839516" -OutFile "Win8.1AndW2K12R2-KB3191564-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('Win8.1AndW2K12R2-KB3191564-x64.msu', '/quiet')
```
------
#### [ Windows Server 2012 ]
```
Set-Location -Path "C:\Windows\Temp"
Invoke-WebRequest "https://go.microsoft.com/fwlink/?linkid=839513" -OutFile "W2K12-KB3191565-x64.msu"
Start-Process -FilePath "$env:systemroot\system32\wusa.exe" -Verb RunAs -ArgumentList ('W2K12-KB3191565-x64.msu', '/quiet')
```
------
1. En la sección **Targets** (Destinos), para elegir los nodos administrados en los que desea ejecutar esta operación, especifique las etiquetas, seleccione las instancias o los dispositivos de borde manualmente o especifique un grupo de recursos.
**sugerencia**
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. En **Otros parámetros**:
+ En **Comentario**, ingrese la información acerca de este comando.
+ En **Tiempo de espera (segundos)**, especifique el número de segundos que tiene que esperar el sistema antes de indicar que se ha producido un error en la ejecución del comando general.
1. En **Rate control** (Control de velocidad):
+ En **Concurrency** (Simultaneidad), especifique un número o un porcentaje de los nodos administrados en los que desea ejecutar el comando al mismo tiempo.
**nota**
Si seleccionó los destinos mediante la especificación de etiquetas aplicadas a nodos administrados o de grupos de recursos de AWS y no está seguro de cuántos nodos administrados tienen destino, limite el número de destinos que puede ejecutar el documento al mismo tiempo. Para ello, especifique un porcentaje.
+ En **Error threshold** (Umbral de errores), especifique cuándo desea parar la ejecución del comando en los demás nodos administrados después de que haya fallado en un número o un porcentaje de los nodos. Por ejemplo, si especifica tres errores, Systems Manager dejará de enviar el comando cuando se reciba el cuarto error. Los nodos administrados que estén procesando el comando todavía pueden enviar errores.
1. (Opcional) En **Opciones de salida**, para guardar la salida del comando en un archivo, seleccione el cuadro **Write command output to an S3 bucket**. 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 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 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, 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. En la sección **Notificaciones de SNS**, seleccione la casilla de verificación **Habilitar notificaciones de SNS** si desea recibir notificaciones sobre el estado de ejecución de los comandos.
Para obtener más información acerca de la configuración de las notificaciones de Amazon SNS para Run Command, consulte [Cómo monitorear los cambios de estado de Systems Manager mediante las notificaciones de Amazon SNS](monitoring-sns-notifications.md).
1. Seleccione **Ejecutar**.
Una vez reiniciado el nodo administrado y finalizada la instalación de la actualización, conéctese al nodo para confirmar que PowerShell se actualizó de forma correcta a la versión 5.1. Para verificar la versión de PowerShell en el nodo, abra PowerShell e ingrese `$PSVersionTable`. El valor de `PSVersion` en la tabla de salida mostrará 5.1 si la actualización se realizó de manera correcta.
Si el valor de `PSVersion` no es 5.1, por ejemplo, 3.0 o 4.0, revise los registros de **Setup** (Configuración) en el lector de eventos de **Windows Logs** (Registros de Windows). Estos registros indicarán por qué falló la instalación de la actualización.
# Tutorial: uso de la AWS CLI con Run Command
El siguiente ejemplo de explicación muestra cómo utilizar la AWS Command Line Interface (AWS CLI) para ver información acerca de los comandos y los parámetros de los comandos, de cómo ejecutar comandos y de cómo consultar el estado de dichos comandos.
**importante**
Solo los administradores de confianza deben utilizar los documentos de AWS Systems Manager preconfigurados que se muestran en este tema. Los comandos o los scripts especificados en los documentos de Systems Manager se ejecutan con permisos administrativos en los nodos administrados. Si un usuario tiene permiso para ejecutar cualquiera de los documentos de Systems Manager predefinidos (cualquier documento que empiece por `AWS-`), dicho usuario también tendrá acceso de administrador al nodo. Para todos los demás usuarios, debe crear documentos restrictivos y compartirlos con los usuarios específicos.
**Topics**
+ [Paso 1: introducción](#walkthrough-cli-settings)
+ [Paso 2: ejecutar scripts de shell para ver los detalles de los recursos](#walkthrough-cli-run-scripts)
+ [Paso 3: enviar comandos simples utilizando el documento `AWS-RunShellScript`](#walkthrough-cli-example-1)
+ [Paso 4: ejecutar una secuencia de comandos simple de Python mediante Run Command](#walkthrough-cli-example-2)
+ [Paso 5: ejecutar un script de Bash utilizando Run Command](#walkthrough-cli-example-3)
## Paso 1: introducción
Debe tener permisos de administrador en el nodo administrado que desea configurar o se le deben haber otorgado los permisos adecuados en AWS Identity and Access Management (IAM). También debe tener en cuenta que en este ejemplo se utiliza la región EE. UU. Este (Ohio) (us-east-2). Run Command está disponible en las Regiones de AWS que se indican en [Puntos de enlace 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*. Para obtener más información, consulte [Configuración de nodos administrados para AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Para ejecutar comandos utilizando la AWS CLI**
1. 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).
1. Enumere todos los documentos disponibles.
Este comando enumera todos los documentos disponibles para su cuenta en función de los permisos de IAM.
```
aws ssm list-documents
```
1. Verifique si un nodo administrado está listo para recibir comandos.
La salida del siguiente comando muestra si los nodos administrados están en línea.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-information \
--output text --query "InstanceInformationList[*]"
```
------
#### [ Windows ]
```
aws ssm describe-instance-information ^
--output text --query "InstanceInformationList[*]"
```
------
1. Ejecute el siguiente comando para ver los detalles sobre un nodo administrado en particular.
**nota**
Para ejecutar los comandos de esta explicación, debe sustituir los ID de la instancia y del comando. Para dispositivos de núcleo de AWS IoT Greengrass administrados, utilice el mi-*ID\$1number* para el ID de instancia. El ID de comando se devuelve como respuesta a **send-command**. Los ID de instancia están disponibles en Fleet Manager, una herramienta de AWS Systems Manager.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-information \
--instance-information-filter-list key=InstanceIds,valueSet=instance-ID
```
------
#### [ Windows ]
```
aws ssm describe-instance-information ^
--instance-information-filter-list key=InstanceIds,valueSet=instance-ID
```
------
## Paso 2: ejecutar scripts de shell para ver los detalles de los recursos
Si utiliza Run Command y el documento `AWS-RunShellScript`, puede ejecutar cualquier comando o script en un nodo administrado como si hubiera iniciado sesión de manera local.
**Ver la descripción y los parámetros disponibles**
Ejecute el siguiente comando para ver una descripción del documento JSON de Systems Manager.
------
#### [ Linux & macOS ]
```
aws ssm describe-document \
--name "AWS-RunShellScript" \
--query "[Document.Name,Document.Description]"
```
------
#### [ Windows ]
```
aws ssm describe-document ^
--name "AWS-RunShellScript" ^
--query "[Document.Name,Document.Description]"
```
------
Ejecute el siguiente comando para ver los parámetros disponibles y los detalles sobre esos parámetros.
------
#### [ Linux & macOS ]
```
aws ssm describe-document \
--name "AWS-RunShellScript" \
--query "Document.Parameters[*]"
```
------
#### [ Windows ]
```
aws ssm describe-document ^
--name "AWS-RunShellScript" ^
--query "Document.Parameters[*]"
```
------
## Paso 3: enviar comandos simples utilizando el documento `AWS-RunShellScript`
Ejecute el siguiente comando para obtener la información de la dirección IP de un nodo administrado de Linux.
Si se dirige a un nodo administrado de Windows Server, cambie el `document-name` a `AWS-RunPowerShellScript` y cambie el `command` de `ifconfig` a `ipconfig`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "IP config" \
--parameters commands=ifconfig \
--output text
```
------
#### [ Windows ]
```
aws ssm send-command ^
--instance-ids "instance-ID" ^
--document-name "AWS-RunShellScript" ^
--comment "IP config" ^
--parameters commands=ifconfig ^
--output text
```
------
**Obtener información de comandos con datos de respuesta**
El comando siguiente utiliza el ID de comando que ha devuelto el comando anterior para obtener los detalles y los datos de respuesta de la ejecución de comandos. El sistema devuelve los datos de respuesta si el comando se completó. Si la ejecución del comando muestra `"Pending"` o `"InProgress"`, ejecute este comando de nuevo para ver los datos de respuesta.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--command-id $sh-command-id \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--command-id $sh-command-id ^
--details
```
------
**Identificar usuario**
El siguiente comando muestra el usuario predeterminado que ejecuta los comandos.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux managed node" \
--parameters commands=whoami \
--output text \
--query "Command.CommandId")
```
------
**Obtener el estado del comando**
El comando siguiente utiliza el ID de comando para obtener el estado de la ejecución del comando en el nodo administrado. Este ejemplo utiliza el ID de comando devuelto en el comando anterior.
------
#### [ Linux & macOS ]
```
aws ssm list-commands \
--command-id "command-ID"
```
------
#### [ Windows ]
```
aws ssm list-commands ^
--command-id "command-ID"
```
------
**Obtener los detalles del comando**
El comando siguiente utiliza el ID de comando del comando anterior para obtener el estado de la ejecución del comando nodo por nodo.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--command-id "command-ID" \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--command-id "command-ID" ^
--details
```
------
**Obtención de información de comando con los datos de respuesta de un nodo administrado concreto**
El siguiente comando devuelve la salida de la solicitud original `aws ssm send-command` para un nodo administrado concreto.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--instance-id instance-ID \
--command-id "command-ID" \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--instance-id instance-ID ^
--command-id "command-ID" ^
--details
```
------
**Mostrar versión de Python**
El siguiente comando devuelve la versión de Python que se ejecuta en un nodo.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux Instances" \
--parameters commands='python -V' \
--output text --query "Command.CommandId") \
sh -c 'aws ssm list-command-invocations \
--command-id "$sh_command_id" \
--details \
--query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}"'
```
------
## Paso 4: ejecutar una secuencia de comandos simple de Python mediante Run Command
El siguiente comando ejecuta un simple script de Python “Hello World” mediante Run Command.
------
#### [ Linux & macOS ]
```
sh_command_id=$(aws ssm send-command \
--instance-ids "instance-ID" \
--document-name "AWS-RunShellScript" \
--comment "Demo run shell script on Linux Instances" \
--parameters '{"commands":["#!/usr/bin/python","print \"Hello World from python\""]}' \
--output text \
--query "Command.CommandId") \
sh -c 'aws ssm list-command-invocations \
--command-id "$sh_command_id" \
--details \
--query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}"'
```
------
## Paso 5: ejecutar un script de Bash utilizando Run Command
En los ejemplos de esta sección, se muestra cómo ejecutar el siguiente script de bash utilizando Run Command.
Para ver ejemplos de cómo utilizar Run Command para ejecutar scripts almacenados en ubicaciones remotas, consulte [Ejecución de scripts desde Amazon S3](integration-s3.md) y [Ejecución de scripts desde GitHub](integration-remote-scripts.md).
```
#!/bin/bash
yum -y update
yum install -y ruby
cd /home/ec2-user
curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install
chmod +x ./install
./install auto
```
Este script instala el agente de AWS CodeDeploy en Amazon Linux y en las instancias de Red Hat Enterprise Linux (RHEL), tal como se describe en [Crear una instancia de Amazon EC2 para CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/instances-ec2-create.html) en la *Guía del usuario de AWS CodeDeploy*.
El script instala el agente de CodeDeploy desde un bucket de S3 administrado por AWS en la región Este de EE. UU. (Ohio) (us-east-2), `aws-codedeploy-us-east-2`.
**Ejecución de un script de bash en un comando de la AWS CLI**
En el ejemplo siguiente, se muestra cómo incluir el script de bash en un comando de la CLI mediante la opción `--parameters`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets '[{"Key":"InstanceIds","Values":["instance-id"]}]' \
--parameters '{"commands":["#!/bin/bash","yum -y update","yum install -y ruby","cd /home/ec2-user","curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install","chmod +x ./install","./install auto"]}'
```
------
**Ejecutar un script de bash en un archivo JSON**
En el ejemplo siguiente, el contenido del script de bash se almacena en un archivo JSON y el archivo se incluye en el comando mediante la opción `--cli-input-json`.
------
#### [ Linux & macOS ]
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--targets "Key=InstanceIds,Values=instance-id" \
--cli-input-json file://installCodeDeployAgent.json
```
------
#### [ Windows ]
```
aws ssm send-command ^
--document-name "AWS-RunShellScript" ^
--targets "Key=InstanceIds,Values=instance-id" ^
--cli-input-json file://installCodeDeployAgent.json
```
------
El contenido del archivo `installCodeDeployAgent.json` al que se hace referencia se muestra en el ejemplo siguiente.
```
{
"Parameters": {
"commands": [
"#!/bin/bash",
"yum -y update",
"yum install -y ruby",
"cd /home/ec2-user",
"curl -O https://aws-codedeploy-us-east-2.s3.amazonaws.com/latest/install",
"chmod +x ./install",
"./install auto"
]
}
}
```
# Tutorial: uso de la AWS Tools for Windows PowerShell con Run Command
Los siguientes ejemplos muestran cómo utilizar AWS Tools for Windows PowerShell para ver información sobre los comandos y los parámetros de comando, cómo ejecutar comandos y cómo consultar el estado de dichos comandos. Este tutorial incluye un ejemplo para cada uno de los documentos de AWS Systems Manager predefinidos.
**importante**
Solo los administradores de confianza deben tener permiso para utilizar los documentos preconfigurados de Systems Manager que se muestran en este tema. Los comandos o los scripts especificados en los documentos de Systems Manager se ejecutan con permisos administrativos en los nodos administrados. Si un usuario tiene permiso para ejecutar cualquiera de los documentos de Systems Manager predefinidos (cualquier documento que empiece con AWS), dicho usuario también tendrá acceso de administrador al nodo. Para todos los demás usuarios, debe crear documentos restrictivos y compartirlos con los usuarios específicos.
**Topics**
+ [Configurar las opciones de la sesión de AWS Tools for Windows PowerShell](#walkthrough-powershell-settings)
+ [Enumerar todos los documentos disponibles](#walkthrough-powershell-all-documents)
+ [Ejecutar comandos o scripts de PowerShell](#walkthrough-powershell-run-script)
+ [Instalar una aplicación utilizando el documento `AWS-InstallApplication`](#walkthrough-powershell-install-application)
+ [Instalar un módulo de PowerShell utilizando el documento JSON `AWS-InstallPowerShellModule`](#walkthrough-powershell-install-module)
+ [Unión de un nodo administrado a un dominio utilizando el documento JSON `AWS-JoinDirectoryServiceDomain`](#walkthrough-powershell-domain-join)
+ [Enviar métricas de Windows a los Registros de Amazon CloudWatch mediante el documento `AWS-ConfigureCloudWatch`](#walkthrough-powershell-windows-metrics)
+ [Activar o desactivar la actualización automática de Windows con el documento `AWS-ConfigureWindowsUpdate`](#walkthrough-powershell-enable-windows-update)
+ [Administrar las actualizaciones de Windows mediante Run Command](#walkthough-powershell-windows-updates)
## Configurar las opciones de la sesión de AWS Tools for Windows PowerShell
**Especificar sus credenciales**
Abra **Tools for Windows PowerShell** en su equipo local y ejecute el siguiente comando para especificar sus credenciales. Debe tener permisos de administrador en los nodos administrados que desea configurar o se le deben haber otorgado los permisos adecuados en AWS Identity and Access Management (IAM). Para obtener más información, consulte [Configuración de nodos administrados para AWS Systems Manager](systems-manager-setting-up-nodes.md).
```
Set-AWSCredentials –AccessKey key-name –SecretKey key-name
```
**Establezca una predeterminada. Región de AWS**
Ejecute el siguiente comando para establecer la región de la sesión de PowerShell. En el ejemplo, se utiliza la región Este de EE. UU. (Ohio) (us-east-2). Run Command está disponible en las Regiones de AWS que se indican 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*.
```
Set-DefaultAWSRegion `
-Region us-east-2
```
## Enumerar todos los documentos disponibles
Este comando enumera todos los documentos disponibles para su cuenta.
```
Get-SSMDocumentList
```
## Ejecutar comandos o scripts de PowerShell
Si utiliza Run Command y el documento `AWS-RunPowerShell`, puede ejecutar cualquier comando o script en un nodo administrado como si hubiera iniciado sesión de manera local. Puede emitir comandos o ingresar una ruta a un script local para ejecutar el comando.
**nota**
Para obtener información acerca de cómo reiniciar los nodos administrados cuando se utiliza Run Command para llamar a scripts, consulte [Gestión de reinicios al ejecutar comandos](send-commands-reboot.md).
**Ver la descripción y los parámetros disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript"
```
**Ver más información sobre los parámetros**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript" | Select -ExpandProperty Parameters
```
### Enviar comandos utilizando el documento `AWS-RunPowerShellScript`
El siguiente comando muestra el contenido del directorio `"C:\Users"` y el contenido del directorio `"C:\"` en dos nodos administrados.
```
$runPSCommand = Send-SSMCommand `
-InstanceIds @("instance-ID-1", "instance-ID-2") `
-DocumentName "AWS-RunPowerShellScript" `
-Comment "Demo AWS-RunPowerShellScript with two instances" `
-Parameter @{'commands'=@('dir C:\Users', 'dir C:\')}
```
**Obtener los detalles de la solicitud del comando**
El comando siguiente utiliza el `CommandId` para obtener el estado de la ejecución del comando en ambos nodos administrados. Este ejemplo utiliza el `CommandId` devuelto en el comando anterior.
```
Get-SSMCommand `
-CommandId $runPSCommand.CommandId
```
El estado del comando en este ejemplo puede ser Success, Pending o InProgress.
**Obtención de información de comandos por nodo administrado**
El comando siguiente utiliza el `CommandId` del comando anterior para obtener el estado de la ejecución del comando nodo por nodo.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId
```
**Obtención de información de comando con los datos de respuesta de un nodo administrado concreto**
El siguiente comando devuelve la salida del `Send-SSMCommand` original para un nodo administrado concreto.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### Cancelar un comando
El siguiente comando cancela el comando `Send-SSMCommand` para el documento `AWS-RunPowerShellScript`.
```
$cancelCommand = Send-SSMCommand `
-InstanceIds @("instance-ID-1","instance-ID-2") `
-DocumentName "AWS-RunPowerShellScript" `
-Comment "Demo AWS-RunPowerShellScript with two instances" `
-Parameter @{'commands'='Start-Sleep –Seconds 120; dir C:\'}
Stop-SSMCommand -CommandId $cancelCommand.CommandId
```
**Comprobar el estado del comando**
El comando siguiente comprueba el estado del comando `Cancel`.
```
Get-SSMCommand `
-CommandId $cancelCommand.CommandId
```
## Instalar una aplicación utilizando el documento `AWS-InstallApplication`
Si utiliza Run Command y el documento `AWS-InstallApplication`, puede instalar, reparar o desinstalar aplicaciones en nodos administrados. El comando requiere la ruta o dirección de un MSI.
**nota**
Para obtener información acerca de cómo reiniciar los nodos administrados cuando se utiliza Run Command para llamar a scripts, consulte [Gestión de reinicios al ejecutar comandos](send-commands-reboot.md).
**Ver la descripción y los parámetros disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication"
```
**Ver más información sobre los parámetros**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication" | Select -ExpandProperty Parameters
```
### Enviar comandos utilizando el documento `AWS-InstallApplication`
El siguiente comando instala una versión de Python en el nodo administrado en modo desatendido y registra la salida en un archivo de texto local de la unidad `C:`.
```
$installAppCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallApplication" `
-Parameter @{'source'='https://www.python.org/ftp/python/2.7.9/python-2.7.9.msi'; 'parameters'='/norestart /quiet /log c:\pythoninstall.txt'}
```
**Obtención de información de comandos por nodo administrado**
El comando siguiente utiliza el `CommandId` para obtener el estado de la ejecución del comando.
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true
```
**Obtención de información de comando con los datos de respuesta de un nodo administrado concreto**
El siguiente comando devuelve el resultado de la instalación de Python.
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
## Instalar un módulo de PowerShell utilizando el documento JSON `AWS-InstallPowerShellModule`
Puede utilizar Run Command para instalar módulos de PowerShell en nodos administrados. Para obtener más información acerca de los módulos de PowerShell, consulte [Módulos de Windows PowerShell](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_modules?view=powershell-6).
**Ver la descripción y los parámetros disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule"
```
**Ver más información sobre los parámetros**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule" | Select -ExpandProperty Parameters
```
### Instalar un módulo de PowerShell
El siguiente comando descarga el archivo EZOut.zip, lo instala y, a continuación, ejecuta un comando adicional para instalar el visor de XPS. Por último, la salida de este comando se carga en un bucket de S3 denominado “amzn-s3-demo-bucket”.
```
$installPSCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallPowerShellModule" `
-Parameter @{'source'='https://gallery.technet.microsoft.com/EZOut-33ae0fb7/file/110351/1/EZOut.zip';'commands'=@('Add-WindowsFeature -name XPS-Viewer -restart')} `
-OutputS3BucketName amzn-s3-demo-bucket
```
**Obtención de información de comandos por nodo administrado**
El comando siguiente utiliza el `CommandId` para obtener el estado de la ejecución del comando.
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true
```
**Obtención de información de comandos con los datos de respuesta del nodo administrado**
El siguiente comando devuelve el resultado del comando `Send-SSMCommand` original para el `CommandId` especificado.
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## Unión de un nodo administrado a un dominio utilizando el documento JSON `AWS-JoinDirectoryServiceDomain`
Si utiliza Run Command, puede unir rápidamente un nodo administrado a un dominio de AWS Directory Service. Antes de ejecutar este comando, [cree un directorio](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html). También le recomendamos obtener más información acerca de Directory Service. Para obtener más información, consulte la [Guía de administración de AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/).
Solo puede unir un nodo administrado a un dominio. No se puede eliminar un nodo de un dominio.
**nota**
Para obtener información acerca de los nodos administrados cuando se utiliza Run Command para llamar a scripts, consulte [Gestión de reinicios al ejecutar comandos](send-commands-reboot.md).
**Ver la descripción y los parámetros disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain"
```
**Ver más información sobre los parámetros**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain" | Select -ExpandProperty Parameters
```
### Unión de un nodo administrado a un dominio
El siguiente comando une un nodo administrado con el dominio Directory Service dado y carga cualquier salida generada en el bucket de ejemplo de Amazon Simple Storage Service (Amazon S3).
```
$domainJoinCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-JoinDirectoryServiceDomain" `
-Parameter @{'directoryId'='d-example01'; 'directoryName'='ssm.example.com'; 'dnsIpAddresses'=@('192.168.10.195', '192.168.20.97')} `
-OutputS3BucketName amzn-s3-demo-bucket
```
**Obtención de información de comandos por nodo administrado**
El comando siguiente utiliza el `CommandId` para obtener el estado de la ejecución del comando.
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true
```
**Obtención de información de comandos con los datos de respuesta del nodo administrado**
Este comando devuelve la salida del comando `Send-SSMCommand` original para el `CommandId` especificado.
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## Enviar métricas de Windows a los Registros de Amazon CloudWatch mediante el documento `AWS-ConfigureCloudWatch`
Puede enviar mensajes de Windows Server en los registros de aplicación, sistema, seguridad y Seguimiento de eventos para Windows (ETW) a los Registros de Amazon CloudWatch. Cuando se permite el registro por primera vez, Systems Manager envía todos los registros generados en un plazo de un (1) minuto a partir del momento en que empieza a cargar registros para los registros de aplicación, sistema, seguridad y ETW. No se incluyen los registros que se produjeron antes de este tiempo. Si desactiva el registro y después vuelve a activarlo, Systems Manager envía registros desde el momento en que dejó de hacerlo. En el caso de cualquier archivo de registros personalizado y registro de Internet Information Services (IIS), Systems Manager lee los archivos de registros desde el principio. Además, Systems Manager también puede enviar datos del contador de rendimiento a los Registros de CloudWatch.
Si con anterioridad activó la integración de CloudWatch en EC2Config, la configuración de Systems Manager anulará cualquier configuración almacenada de forma local en el nodo administrado en el archivo `C:\Program Files\Amazon\EC2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json`. Para obtener información sobre cómo se utiliza EC2Config para administrar los contadores de rendimiento y los registros en un solo nodo administrado, consulte [Recopilación de métricas y registros de instancias de Amazon EC2 y servidores locales con el agente de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) en la *Guía del usuario de Amazon CloudWatch*.
**Ver la descripción y los parámetros disponibles**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch"
```
**Ver más información sobre los parámetros**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch" | Select -ExpandProperty Parameters
```
### Enviar registros de aplicación a CloudWatch
El siguiente comando configura el nodo administrado y mueve los registros de aplicaciones de Windows a CloudWatch.
```
$cloudWatchCommand = Send-SSMCommand `
-InstanceID instance-ID `
-DocumentName "AWS-ConfigureCloudWatch" `
-Parameter @{'properties'='{"engineConfiguration": {"PollInterval":"00:00:15", "Components":[{"Id":"ApplicationEventLog", "FullName":"AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"LogName":"Application", "Levels":"7"}},{"Id":"CloudWatch", "FullName":"AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch", "Parameters":{"Region":"region", "LogGroup":"my-log-group", "LogStream":"instance-id"}}], "Flows":{"Flows":["ApplicationEventLog,CloudWatch"]}}}'}
```
**Obtención de información de comandos por nodo administrado**
El comando siguiente utiliza el `CommandId` para obtener el estado de la ejecución del comando.
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true
```
**Obtención de información de comando con los datos de respuesta de un nodo administrado concreto**
El siguiente comando devuelve los resultados de la configuración de Amazon CloudWatch.
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### Enviar contadores de rendimiento a CloudWatch utilizando el documento `AWS-ConfigureCloudWatch`
El siguiente comando de demostración carga contadores de desempeño en CloudWatch. Para obtener más información, consulte la *[Guía del usuario de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)*.
```
$cloudWatchMetricsCommand = Send-SSMCommand `
-InstanceID instance-ID `
-DocumentName "AWS-ConfigureCloudWatch" `
-Parameter @{'properties'='{"engineConfiguration": {"PollInterval":"00:00:15", "Components":[{"Id":"PerformanceCounter", "FullName":"AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"CategoryName":"Memory", "CounterName":"Available MBytes", "InstanceName":"", "MetricName":"AvailableMemory", "Unit":"Megabytes","DimensionName":"", "DimensionValue":""}},{"Id":"CloudWatch", "FullName":"AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch", "Parameters":{"AccessKey":"", "SecretKey":"","Region":"region", "NameSpace":"Windows-Default"}}], "Flows":{"Flows":["PerformanceCounter,CloudWatch"]}}}'}
```
## Activar o desactivar la actualización automática de Windows con el documento `AWS-ConfigureWindowsUpdate`
Si utiliza Run Command y el documento `AWS-ConfigureWindowsUpdate`, puede activar o desactivar las actualizaciones automáticas de Windows en los nodos administrados de Windows Server. Este comando configura el agente de Windows Update para que descargue e instale las actualizaciones de Windows el día y a la hora que usted especifique. Si una actualización requiere un reinicio, el nodo administrado se reiniciará automáticamente 15 minutos después de haber instalado las actualizaciones. Con este comando también puede configurar Windows Update para que verifique si hay actualizaciones, pero sin instalarlas. El documento `AWS-ConfigureWindowsUpdate` cuenta con soporte oficial en las versiones de Windows Server 2012 y posteriores.
**Ver la descripción y los parámetros disponibles**
```
Get-SSMDocumentDescription `
–Name "AWS-ConfigureWindowsUpdate"
```
**Ver más información sobre los parámetros**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureWindowsUpdate" | Select -ExpandProperty Parameters
```
### Activar la actualización automática de Windows
El siguiente comando configura Windows Update para que descargue e instale las actualizaciones automáticamente todos los días a las 10:00 h.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='InstallUpdatesAutomatically'; 'scheduledInstallDay'='Daily'; 'scheduledInstallTime'='22:00'}
```
**Ver el estado del comando para permitir la actualización automática de Windows**
El comando siguiente utiliza el `CommandId` para obtener el estado de la ejecución del comando para permitir la actualización automática de Windows.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
### Desactivar la actualización automática de Windows
El comando siguiente reduce el nivel de notificación de Windows Update para que el sistema verifique si hay actualizaciones, pero no actualice automáticamente el nodo administrado.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='NeverCheckForUpdates'}
```
**Ver el estado del comando para desactivar la actualización automática de Windows**
El comando siguiente utiliza el `CommandId` para obtener el estado de la ejecución del comando para desactivar la actualización automática de Windows.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
## Administrar las actualizaciones de Windows mediante Run Command
Mediante el uso de Run Command y el documento `AWS-InstallWindowsUpdates`, puede administrar actualizaciones para nodos administrados de Windows Server. Este comando busca o instala las actualizaciones que faltan en los nodos administrados y, de forma opcional, se reinicia después de la instalación. También puede especificar las clasificaciones y los niveles de gravedad adecuados para las actualizaciones que se van a instalar en su entorno.
**nota**
Para obtener información acerca de cómo reiniciar los nodos administrados cuando se utiliza Run Command para llamar a scripts, consulte [Gestión de reinicios al ejecutar comandos](send-commands-reboot.md).
Los siguientes ejemplos muestran cómo realizar las tareas de administración de Windows Update especificadas.
### Buscar todas las actualizaciones de Windows que faltan
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Scan'}
```
### Instalar actualizaciones de Windows específicas
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'IncludeKbs'='kb-ID-1,kb-ID-2,kb-ID-3';'AllowReboot'='True'}
```
### Instalar las actualizaciones importantes de Windows que faltan
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'SeverityLevels'='Important';'AllowReboot'='True'}
```
### Instalar las actualizaciones de Windows que faltan con exclusiones específicas
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'ExcludeKbs'='kb-ID-1,kb-ID-2';'AllowReboot'='True'}
```
# Solución de problemas Systems Manager Run Command
Run Command, una herramienta de AWS Systems Manager, proporciona detalles de estado con la ejecución de cada comando. Para obtener más información acerca de los detalles de los estados del comando, consulte [Descripción de los estados del comando](monitor-commands.md). También puede utilizar la información de este tema como ayuda para solucionar problemas con Run Command.
**Topics**
+ [Faltan algunos de los nodos administrados](#where-are-instances)
+ [Un paso de mi script produjo un error, pero el estado general es “correcto”](#ts-exit-codes)
+ [SSM Agent no se ejecuta correctamente.](#ts-ssmagent-linux)
## Faltan algunos de los nodos administrados
En la página **Run a command** (Ejecutar un comando), después de elegir el documento de SSM que se va a ejecutar y de seleccionar **Manually selecting instances** (Seleccionar instancias manualmente) en la sección **Targets** (Destinos), se muestra una lista de los nodos administrados que puede elegir para ejecutar el comando.
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.
Después de crear, activar o reiniciar un nodo administrado, instale Run Command en un nodo o adjunte un perfil de instancias de AWS Identity and Access Management (IAM) a un nodo. Pueden pasar algunos minutos hasta que el nodo administrado aparezca en la lista.
## Un paso de mi script produjo un error, pero el estado general es “correcto”
Mediante el uso de Run Command, puede definir cómo los scripts manejan los códigos de salida. De forma predeterminada, el código de salida del último comando ejecutado en un script se registra como el código de salida de todo el script. Sin embargo, puede incluir una instrucción condicional para salir del script si algún comando anterior al final produce un error. Para obtener más información y ejemplos, consulte [Especificación de códigos de salida en los comandos](run-command-handle-exit-status.md#command-exit-codes).
## SSM Agent no se ejecuta correctamente.
Si tiene dificultades cuando ejecute comandos con Run Command, es posible que haya algún problema con SSM Agent. Para obtener más información acerca de cómo investigar problemas con SSM Agent, consulte [Resolución de problemas de SSM Agent](troubleshooting-ssm-agent.md).
# AWS Systems Manager Session Manager
Session Manager es una herramienta de AWS Systems Manager completamente administrada. Con Session Manager, puede administrar las instancias de Amazon Elastic Compute Cloud (Amazon EC2), los dispositivos periféricos, los servidores en las instalaciones y las máquinas virtuales (VM). Puede utilizar un intérprete de comandos interactivo basado en navegador con un solo clic o la AWS Command Line Interface (AWS CLI). Session Manager proporciona una administración de nodos segura sin la necesidad de abrir los puertos de entrada, mantener hosts bastión ni administrar claves SSH. Session Manager también permite el cumplimiento con las políticas corporativas que requieren acceso controlado a nodos administrados, prácticas de seguridad estrictas y registros con detalles del acceso a los nodos, a la vez que ofrecen a los usuarios finales un acceso multiplataforma sencillo con un solo clic a los nodos administrados. Para comenzar a utilizar Session Manager, abra la [consola de Systems Manager](https://console.aws.amazon.com/systems-manager/session-manager). En el panel de navegación, elija **Session Manager**.
## ¿Cómo puede Session Manager beneficiar a mi organización?
Session Manager ofrece las ventajas siguientes:
+ **Control centralizado del acceso a los nodos administrados mediante políticas de IAM**
Los administradores disponen de un solo lugar para conceder y denegar el acceso a los nodos administrados. Si utiliza solo políticas de AWS Identity and Access Management (IAM), puede controlar qué usuarios individuales o grupos de la organización pueden utilizar Session Manager y a qué nodos administrados pueden acceder.
+ **Sin puertos de entrada abiertos y sin necesidad de administrar hosts bastión o claves SSH**
Dejar abiertos los puertos SSH de entrada y los puertos PowerShell remotos en los nodos administrados aumenta enormemente el riesgo de que las entidades ejecuten comandos no autorizados o maliciosos en los nodos administrados. Session Manager ayuda a mejorar la posición de seguridad y permite cerrar estos puertos entrantes, por lo que no tendrá que realizar tareas de administración de claves y certificados SSH, hosts bastión y cajas de conexiones.
+ **Acceso con un solo clic a los nodos administrados desde la consola y la CLI**
Si usa la consola de AWS Systems Manager o de Amazon EC2, podrá iniciar una sesión con un solo clic. Con la AWS CLI, también puede iniciar una sesión que ejecute un único comando o una secuencia de comandos. Dado que los permisos a nodos administrados se proporcionan a través de las políticas de IAM en lugar de con claves SSH u otros mecanismos, el tiempo de conexión se reduce significativamente.
+ **Conexión a instancias de Amazon EC2 y a nodos administrados que no sean de EC2 en entornos [híbridos y multinube](operating-systems-and-machine-types.md#supported-machine-types)**
Puede conectarse a instancias de Amazon Elastic Compute Cloud (Amazon EC2) y a nodos que no sean de EC2 en su entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types).
Para conectarse a nodos que no sean de EC2 con Session Manager, primero debe activar el nivel de instancias avanzadas. **El uso del nivel de instancias avanzadas conlleva un cargo.** No obstante, no se generan cargos adicionales por la conexión a instancias de EC2 mediante Session Manager. Para obtener más información, consulte [Configuración de los niveles de instancias](fleet-manager-configure-instance-tiers.md).
+ **Enrutamiento de puertos**
Redirija cualquier puerto dentro del nodo administrado a un puerto local de un cliente. Después, conéctese al puerto local y obtenga acceso a la aplicación de servidor que se está ejecutando dentro del nodo.
+ **Compatibilidad entre plataformas para Windows, Linux y macOS**
Session Manager proporciona compatibilidad con Windows, Linux y macOS desde una sola herramienta. Por ejemplo, no es necesario utilizar un cliente de SSH para los nodos administrados de Linux ni de macOS, ni tampoco una conexión de RDP para los nodos administrados de Windows Server.
+ **Registro de la actividad de la sesión**
Para cumplir los requisitos de seguridad y operativos de la organización, es posible que tenga que proporcionar un registro de las conexiones realizadas en los nodos administrados y los comandos que se ejecutaron en ellos. También puede recibir notificaciones cuando un usuario de su organización comienza o finaliza la actividad de sesiones.
Las capacidades de registro se proporcionan a través de la integración a los siguientes Servicios de AWS:
+ **AWS CloudTrail**: AWS CloudTrail recopila información acerca de las llamadas a la API de Session Manager realizadas en su Cuenta de AWS y la escribe en archivos de registros que se almacenan en un bucket de Amazon Simple Storage Service (Amazon S3) que usted especifique. Se utiliza un bucket para todos los registros de CloudTrail de su cuenta. Para obtener más información, consulte [Registro de llamadas a la API de AWS Systems Manager con AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **Amazon Simple Storage Service**: puede elegir almacenar los datos de registro de las sesiones en un bucket de Amazon S3 que prefiera con fines de depuración y solución de problemas. Los datos de registro se pueden enviar al bucket de Amazon S3 con o sin cifrado mediante su AWS KMS key. Para obtener más información, consulte [Registro de los datos de la sesión con Amazon S3 (consola)](session-manager-logging-s3.md).
+ **Registros de Amazon CloudWatch**: Registros de CloudWatch le permite acceder a los archivos de registros de diversos Servicios de AWS, supervisarlos y almacenarlos. Puede enviar los datos de registro de las sesiones a un grupo de registros de los Registros de CloudWatch con fines de depuración y solución de problemas. Los datos de registro se pueden enviar al grupo de registros con o sin cifrado de AWS KMS usando su clave de KMS. Para obtener más información, consulte [Registro de los datos de la sesión con los Registros de Amazon CloudWatch (consola)](session-manager-logging-cloudwatch-logs.md).
+ **Amazon EventBridge** y **Amazon Simple Notification Service**: EventBridge le permite configurar reglas para detectar cuándo se producen cambios en los recursos de AWS que especifique. Puede crear una regla para detectar cuándo un usuario de su organización inicia o detiene una sesión y, luego, recibir una notificación a través de Amazon SNS (por ejemplo, un mensaje de texto o de email) sobre el evento. También puede configurar un evento de CloudWatch para iniciar otras respuestas. Para obtener más información, consulte [Supervisión de la actividad de la sesión con Amazon EventBridge (consola)](session-manager-auditing.md#session-manager-auditing-eventbridge-events).
**nota**
El registro no está disponible para las sesiones de Session Manager que se conectan a través del reenvío de puertos o de SSH. Esto se debe a que SSH cifra todos los datos de la sesión dentro de la conexión TLS segura establecida entre los puntos de conexión AWS CLI y Session Manager, y Session Manager solo funciona como túnel para las conexiones de SSH.
## ¿Quién debe utilizar Session Manager?
+ Cualquier cliente de AWS que quiera mejorar su posición de seguridad, reducir los costos operativos mediante la centralización del control de accesos de los nodos administrados y reducir el acceso de entrada de los nodos.
+ Expertos en seguridad de la información que deseen monitorear y realizar un seguimiento de la actividad de los nodos administrados y del acceso a ellos, cerrar los puertos de entrada de los nodos administrados o permitir las conexiones a nodos administrados que no tengan una dirección IP pública.
+ Administradores que deseen conceder y revocar acceso desde un solo lugar y que deseen proporcionar una solución a los usuarios para los nodos administrados de Linux, macOS y Windows Server.
+ Usuarios que deseen conectarse a un nodo administrado con un solo clic desde el navegador o la AWS CLI sin tener que proporcionar claves de SSH.
## ¿Cuáles son las características principales de Session Manager?
+ **Compatibilidad con nodos administrados de Windows Server, Linux y macOS**
Session Manager le permite establecer conexiones seguras con las instancias de Amazon Elastic Compute Cloud (EC2), los dispositivos periféricos, los servidores en las instalaciones y las máquinas virtuales (VM). Para ver una lista de los tipos de sistemas operativos admitidos, consulte [Configuración de Session Manager](session-manager-getting-started.md).
**nota**
Session ManagerLa compatibilidad de con máquinas locales se proporciona solo para el nivel de instancias avanzadas. Para obtener más información, consulte [Activación del nivel de instancias avanzadas](fleet-manager-enable-advanced-instances-tier.md).
+ **Acceso de la consola, la CLI y el SDK a las funcionalidades de Session Manager**
Puede trabajar con Session Manager de las siguientes formas:
La **consola de AWS Systems Manager** incluye el acceso a todas las capacidades de Session Manager, tanto para los administradores como para los usuarios finales. Puede llevar a cabo cualquier tarea relacionada con las sesiones por medio de la consola de Systems Manager.
La consola de Amazon EC2 proporciona a los usuarios finales la posibilidad de conectarse a instancias de EC2 para las cuales se les han concedido permisos de sesión.
La **AWS CLI** incluye acceso a las funcionalidades de Session Manager para usuarios finales. Puede comenzar una sesión, ver una lista de sesiones y terminar una sesión de forma permanente a través de la AWS CLI.
**nota**
Si desea utilizar la AWS CLI para ejecutar comandos de sesión, debe utilizar la versión 1.16.12 (o una posterior) de la CLI y tener instalado el complemento de Session Manager en su equipo local. Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md). Para ver el complemento en GitHub, consulte [session-manager-plugin](https://github.com/aws/session-manager-plugin).
+ **Control de acceso de IAM**
Mediante el uso de políticas de IAM, puede controlar qué miembros de la organización pueden iniciar sesiones en nodos administrados y a qué nodos pueden acceder. También puede proporcionar acceso temporal a los nodos administrados. Por ejemplo, es posible que desee ofrecer a un ingeniero de guardia (o un grupo de ingenieros de guardia) el acceso a servidores de producción solo para la duración de su turno.
+ **Compatibilidad de registro**
Session Manager proporciona opciones para los historiales de las sesiones de registro en su Cuenta de AWS a través de la integración a una serie de otros Servicios de AWS. Para obtener más información, consulte [Registro de la actividad de la sesión](session-manager-auditing.md) y [Habilitar y deshabilitar el registro de la sesión](session-manager-logging.md).
+ **Perfiles configurables de shell**
Session Manager le ofrece opciones para configurar preferencias dentro de las sesiones. Estos perfiles personalizables le permiten definir preferencias, como las preferencias de shell, las variables de entorno, los directorios de trabajo y la ejecución de varios comandos cuando se inicia una sesión.
+ **Compatibilidad con el cifrado de datos clave del cliente**
Puede configurar Session Manager para que cifre los registros de datos de las sesiones que se envían a un bucket de Amazon Simple Storage Service (Amazon S3) o se transmiten a un grupo de Registros de CloudWatch. También puede configurar Session Manager para cifrar aún más los datos transmitidos entre equipos del cliente y los nodos administrados durante las sesiones. Para obtener información, consulte [Habilitar y deshabilitar el registro de la sesión](session-manager-logging.md) y [Configurar preferencias de sesión](session-manager-getting-started-configure-preferences.md).
+ **AWS PrivateLink Compatibilidad de para nodos administrados sin direcciones IP públicas**
También puede configurar los puntos de conexión de VPC para Systems Manager mediante AWS PrivateLink para asegurar aún más las sesiones. AWS PrivateLink limita todo el tráfico de red entre los nodos administrados, Systems Manager y Amazon EC2 a la red de Amazon. Para obtener más información, consulte [Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager](setup-create-vpc.md).
+ **Tunelización**
En una sesión, utilice un documento de AWS Systems Manager (SSM) de tipo sesión para tunelizar el tráfico, como http o un protocolo personalizado, entre un puerto local en un equipo cliente y un puerto remoto en un nodo administrado.
+ **Comandos interactivos**
Cree un documento SSM de tipo sesión que utilice una sesión para ejecutar de forma interactiva un único comando, lo que le ofrece una forma de administrar lo que los usuarios pueden hacer en un nodo administrado.
## ¿Qué es una sesión?
Una sesión es una conexión a un nodo administrado efectuada con Session Manager. Las sesiones se basan en un canal de comunicación bidireccional seguro entre el cliente (usted) y el nodo administrado remoto que transmite elementos de entrada y salida para los comandos. El tráfico entre un cliente y un nodo administrado se cifra con TLS 1.2, y las solicitudes para crear la conexión se firman con Sigv4. Esta comunicación bidireccional permite el acceso interactivo de bash y PowerShell a los nodos administrados. También puede utilizar una clave de AWS Key Management Service (AWS KMS) para cifrar aún más los datos, más allá del cifrado TLS predeterminado.
Por ejemplo, digamos que John es un ingeniero de guardia en su departamento de TI. Este recibe la notificación de un problema que le exige conectarse remotamente a un nodo administrado, como, por ejemplo, un error que requiere la solución de problemas o una directiva para cambiar una opción de configuración sencilla en un nodo. Mediante la consola de AWS Systems Manager, la consola de Amazon EC2 o la AWS CLI, John inicia una sesión que lo conecta al nodo administrado, ejecuta comandos en el nodo necesarios para completar la tarea y, a continuación, termina la sesión.
Cuando John envía ese primer comando para iniciar la sesión, el servicio Session Manager autentica su ID, verifica los permisos concedidos por una política de IAM, comprueba las opciones de configuración (como, por ejemplo, comprobando los límites permitidos para las sesiones) y envía un mensaje a SSM Agent para abrir la conexión bidireccional. Una vez establecida la conexión y después de que John escribe el siguiente comando, la salida del comando de SSM Agent se carga en este canal de comunicación y se envía a su máquina local.
**Topics**
+ [¿Cómo puede Session Manager beneficiar a mi organización?](#session-manager-benefits)
+ [¿Quién debe utilizar Session Manager?](#session-manager-who)
+ [¿Cuáles son las características principales de Session Manager?](#session-manager-features)
+ [¿Qué es una sesión?](#what-is-a-session)
+ [Configuración de Session Manager](session-manager-getting-started.md)
+ [Uso de Session Manager](session-manager-working-with.md)
+ [Registro de la actividad de la sesión](session-manager-auditing.md)
+ [Habilitar y deshabilitar el registro de la sesión](session-manager-logging.md)
+ [Esquema del documento de Session](session-manager-schema.md)
+ [Resolución de problemas de Session Manager](session-manager-troubleshooting.md)
# Configuración de Session Manager
Antes de usar AWS Systems Manager Session Manager para conectarse a los nodos administrados de la cuenta, realice los pasos en los siguientes temas.
**Topics**
+ [Paso 1: completar los requisitos previos de Session Manager](session-manager-prerequisites.md)
+ [Paso 2: verificación o agregación de permisos de instancia para Session Manager](session-manager-getting-started-instance-profile.md)
+ [Paso 3: controlar el acceso de la sesión a los nodos administrados](session-manager-getting-started-restrict-access.md)
+ [Paso 4: configurar las preferencias de sesión](session-manager-getting-started-configure-preferences.md)
+ [Paso 5: (Opcional) Restringir el acceso a los comandos de una sesión](session-manager-restrict-command-access.md)
+ [Paso 6: (Opcional) Utilizar AWS PrivateLink para configurar un punto de enlace de la VPC para Session Manager](session-manager-getting-started-privatelink.md)
+ [Paso 7: (Opcional) Activar o desactivar los permisos administrativos de la cuenta ssm-user](session-manager-getting-started-ssm-user-permissions.md)
+ [Paso 8: (Opcional) Permitir y controlar permisos para conexiones de SSH mediante Session Manager](session-manager-getting-started-enable-ssh-connections.md)
# Paso 1: completar los requisitos previos de Session Manager
Antes de utilizar Session Manager, asegúrese de que el entorno cumple los siguientes requisitos.
**Session ManagerRequisitos previos de**
| Requisito | Descripción |
| --- | --- |
| Sistemas operativos compatibles | Session Manager admite la conexión a instancias de Amazon Elastic Compute Cloud (Amazon EC2) y a equipos que no son de EC2 en su entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) que utilizan el nivel de *instancias avanzadas*. Session Manager es compatible con las siguientes versiones de los sistemas operativos: Session Manager admite instancias de EC2, dispositivos periféricos, servidores en las instalaciones y máquinas virtuales (VM) en su entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types) que utilizan el nivel de *instancias avanzadas*. Para obtener más información acerca de las instancias avanzadas, consulte [Configuración de los niveles de instancias](fleet-manager-configure-instance-tiers.md). **Linux y **macOS**** Session Manager es compatible con todas las versiones de Linux y macOS que admite AWS Systems Manager. Para obtener más información, consulte [Sistemas operativos y tipos de equipos compatibles](operating-systems-and-machine-types.md). ** Windows ** Session Manager admite Windows Server 2012 y versiones posteriores. Microsoft Windows Server 2016 Nano no es compatible. |
| SSM Agent | Como mínimo, debe estar instalada la versión 2.3.68.0 de AWS Systems Manager SSM Agent o una posterior en los nodos administrados a los que desee conectarse a través de sesiones. Para utilizar la opción de cifrar los datos de la sesión con una clave creada en AWS Key Management Service (AWS KMS), el nodo administrado debe tener instalada la versión 2.3.539.0 de SSM Agent o una posterior. Para utilizar perfiles de shell en una sesión, el nodo administrado debe tener instalada la versión 3.0.161.0 de SSM Agent o una posterior. Para iniciar una sesión de SSH o de reenvío de puertos de Session Manager, el nodo administrado debe tener instalada la versión 3.0.222.0 de SSM Agent o una posterior. Para transmitir datos de la sesión mediante los Registros de Amazon CloudWatch, el nodo administrado debe tener instalada la versión 3.0.284.0 de SSM Agent o una posterior. Para obtener información acerca de cómo determinar el número de versión que se ejecuta en una instancia, consulte [Verificación del número de versión de SSM Agent](ssm-agent-get-version.md). Para obtener más información acerca de la instalación manual o la actualización automática de SSM Agent, consulte [Uso de SSM Agent](ssm-agent.md). Acerca de la cuenta ssm-user A partir de la versión 2.3.50.0 de SSM Agent, el agente crea una cuenta de usuario en el nodo administrado, con permisos raíz o de administrador, denominada `ssm-user`. (En las versiones anteriores a la 2.3.612.0, la cuenta se crea cuando SSM Agent se inicia o se reinicia. En la versión 2.3.612.0 y posteriores, la cuenta `ssm-user` se crea la primera vez que se inicia una sesión en el nodo administrado). Las sesiones se lanzan con las credenciales administrativas de esta cuenta de usuario. Para obtener más información acerca de cómo restringir el control administrativo para esta cuenta, consulte [Activación o desactivación de los permisos administrativos de la cuenta ssm-user](session-manager-getting-started-ssm-user-permissions.md). ssm-user en controladores de dominio de Windows Server A partir de la versión 2.3.612.0 de SSM Agent, la cuenta `ssm-user` no se crea automáticamente en los nodos administrados que se utilizan como controladores de dominio de Windows Server. Para utilizar Session Manager en un equipo Windows Server que se utiliza como un controlador de dominio, debe crear la cuenta `ssm-user` de forma manual si ella aún no está presente y asignar permisos de administrador de dominio al usuario. En Windows Server, SSM Agent establece una nueva contraseña para la cuenta `ssm-user` cada vez que se inicia una sesión, por lo que no es necesario especificar ninguna contraseña cuando se crea la cuenta. |
| Conectividad a puntos de enlace | Los nodos administrados a los que se conecta también deben permitir el tráfico saliente HTTPS (puerto 443) a los siguientes puntos de conexión: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/session-manager-prerequisites.html) Para obtener más información, consulte los temas siguientes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/session-manager-prerequisites.html) Alternativamente, puede conectarse a los puntos de enlace necesarios mediante los puntos de enlace de la interfaz. Para obtener más información, consulte [Paso 6: (Opcional) Utilizar AWS PrivateLink para configurar un punto de enlace de la VPC para Session Manager](session-manager-getting-started-privatelink.md). |
| AWS CLI | (Opcional) Si utiliza la AWS Command Line Interface (AWS CLI) para iniciar sus sesiones (en lugar de utilizar la consola de AWS Systems Manager o la consola de Amazon EC2), su equipo local debe tener instalada la versión 1.16.12 de la CLI o una posterior. Puede llamar a `aws --version` para comprobar la versión. Si necesita instalar o actualizar la CLI, consulte [Instalación de la AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) en la Guía del usuario de AWS Command Line Interface. 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. Además, si desea utilizar la CLI para administrar los nodos con Session Manager, debe instalar primero el complemento de Session Manager en su equipo local. Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md). |
| Activación del nivel de instancias avanzadas (entornos [híbridos y multinube](operating-systems-and-machine-types.md#supported-machine-types)) | Para conectarse a equipos que no son de EC2 mediante Session Manager, debe activar el nivel de instancias avanzadas en la Cuenta de AWS y la Región de AWS donde crea activaciones híbridas para registrar equipos que no son de EC2 como nodos administrados. El uso del nivel de instancias avanzadas conlleva un cargo. Para obtener más información acerca del nivel de instancias avanzadas, consulte [Configuración de los niveles de instancias](fleet-manager-configure-instance-tiers.md). |
| Verificación de los permisos de rol de servicio de IAM (entornos [híbridos y multinube](operating-systems-and-machine-types.md#supported-machine-types)) | Los nodos activados de manera híbrida utilizan el rol de servicio de AWS Identity and Access Management (IAM) especificado en la activación híbrida para comunicarse con las operaciones de la API de Systems Manager. Este rol de servicio debe contener los permisos necesarios para conectarse a los equipos [híbridos y multinube](operating-systems-and-machine-types.md#supported-machine-types) mediante Session Manager. Si el rol de servicio contiene la política administrada por AWS `AmazonSSMManagedInstanceCore`, ya se habrán proporcionado los permisos necesarios para Session Manager. Si descubre que el rol de servicio no contiene los permisos necesarios, debe anular el registro de la instancia administrada y registrarla con una nueva activación híbrida que utilice un rol de servicio de IAM con los permisos necesarios. Para obtener más información acerca de cómo se anula el registro de las instancias administradas, consulte [Anulación del registro de nodos administrados en un entorno híbrido y multinube](fleet-manager-deregister-hybrid-nodes.md). Para obtener más información sobre la creación de políticas de IAM con permisos de Session Manager, consulte [Paso 2: verificar o agregar permisos de instancia para Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-instance-profile.html). |
# Paso 2: verificación o agregación de permisos de instancia para Session Manager
De forma predeterminada, AWS Systems Manager no tiene permiso para realizar acciones en sus instancias. Puede proporcionar permisos de instancia a nivel de cuenta mediante un rol de AWS Identity and Access Management (IAM) o a nivel de instancia mediante un perfil de instancia. Si su caso de uso lo permite, le recomendamos que conceda el acceso a nivel de cuenta mediante la configuración de administración de host predeterminada. Si ya completó la configuración de administración de host predeterminada para su cuenta mediante la política `AmazonSSMManagedEC2InstanceDefaultPolicy`, puede continuar con el siguiente paso. Para obtener más información sobre la configuración de administración de host predeterminada, consulte [Administración automática de instancias EC2 con la configuración de administración de hosts predeterminada](fleet-manager-default-host-management-configuration.md).
Como alternativa, puede usar perfiles de instancia para proporcionar los permisos necesarios a sus instancias. Un perfil de instancias pasa un rol de IAM a una instancia de Amazon EC2. Puede adjuntar un perfil de instancias de IAM a una instancia de Amazon EC2 en el momento de lanzarla, o bien, adjuntarlo a una instancia ya lanzada anteriormente. Para obtener más información, consulte [Uso de perfiles de instancia](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-usingrole-instanceprofile.html).
Para servidores en las instalaciones o máquinas virtuales, los permisos los proporciona el rol de servicio de IAM asociado a la activación híbrida utilizada para registrar los servidores en las instalaciones y las máquinas virtuales con Systems Manager. Los servidores locales y las máquinas virtuales no utilizan perfiles de instancia.
Si ya utiliza otras herramientas de Systems Manager, como Run Command o Parameter Store, es posible que ya se haya adjuntado a las instancias de Amazon EC2 un perfil de instancias con los permisos básicos necesarios para Session Manager. Si un perfil de instancias que contiene la política administrada por AWS `AmazonSSMManagedInstanceCore` ya se ha adjuntado a las instancias, los permisos necesarios para Session Manager ya se habrán proporcionado. Esto también aplica si el rol de servicio de IAM utilizado en la activación híbrida contiene la política administrada `AmazonSSMManagedInstanceCore`.
Sin embargo, en algunos casos, es posible que tenga que modificar los permisos asociados al perfil de instancia. Por ejemplo, si desea proporcionar un conjunto más limitado de permisos de instancia, si ha creado una política personalizada para su perfil de instancias o si desea utilizar el cifrado de Amazon Simple Storage Service (Amazon S3) o las opciones de cifrado de AWS Key Management Service (AWS KMS) para proteger los datos de la sesión. En estos casos, realice una de las siguientes operaciones para permitir que se realicen acciones de Session Manager en las instancias:
+ **Inserción de permisos de acciones de Session Manager en un rol de IAM personalizado**
Con el fin de agregar permisos para las acciones de Session Manager a un rol de IAM existente que no se base en la política predeterminada proporcionada por AWS `AmazonSSMManagedInstanceCore`, siga los pasos que se indican en [Adición de permisos de Session Manager a un rol de IAM existente](getting-started-add-permissions-to-existing-profile.md).
+ **Creación de un rol de IAM personalizado solo con permisos de Session Manager**
Para crear un rol de IAM que contenga permisos solo para las acciones de Session Manager, siga los pasos que se indican en [Creación de un rol de IAM personalizado para Session Manager](getting-started-create-iam-instance-profile.md).
+ **Creación y uso de un nuevo rol de IAM con permisos para todas las acciones de Systems Manager**
Para crear un rol de IAM para instancias administradas de Systems Manager que utilice una política predeterminada suministrada por AWS que conceda todos los permisos de Systems Manager, siga los pasos que se indican en [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md).
**Topics**
+ [Adición de permisos de Session Manager a un rol de IAM existente](getting-started-add-permissions-to-existing-profile.md)
+ [Creación de un rol de IAM personalizado para Session Manager](getting-started-create-iam-instance-profile.md)
# Adición de permisos de Session Manager a un rol de IAM existente
Utilice el siguiente procedimiento para agregar permisos de Session Manager a un rol de AWS Identity and Access Management (IAM) existente. Si agrega permisos a un rol existente, puede mejorar la seguridad de su entorno de computación sin tener que utilizar la política `AmazonSSMManagedInstanceCore` de AWS para los permisos de instancia.
**nota**
Tenga en cuenta la siguiente información:
Este procedimiento supone que el rol existente ya incluye otros permisos `ssm` de Systems Manager para las acciones a las que desea permitir el acceso. Esta política sola no es suficiente para utilizar Session Manager.
El siguiente ejemplo de política incluye una acción `s3:GetEncryptionConfiguration`. Esta acción es necesaria si elige la opción **Ejecutar cifrado de registros de S3** en las preferencias de registro de Session Manager.
Si se elimina el permiso `ssmmessages:OpenControlChannel` de las políticas asociadas a su perfil de instancia de IAM o al rol de servicio de IAM, el SSM Agent del nodo administrado pierde la conectividad con el servicio de Systems Manager en la nube. No obstante, después de que se elimina el permiso, puede pasar hasta 1 hora hasta que la conexión finaliza. Es el mismo comportamiento que cuando se elimina el rol de instancia de IAM o el rol de servicio de IAM.
**Para agregar permisos de Session Manager a un rol existente (consola)**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Seleccione **Roles** en el panel de navegación.
1. Elija el nombre del rol al que le va a agregar los permisos.
1. Elija la pestaña **Permisos**.
1. Elija **Agregar permisos** y, a continuación, seleccione **Crear política insertada**.
1. Seleccione la pestaña **JSON**.
1. Reemplace la política predeterminada por el siguiente contenido. Reemplace *key-name* por el nombre de recurso de Amazon (ARN) de la clave de AWS Key Management Service (AWS KMS key) que desee utilizar.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
Para obtener más información acerca de cómo utilizar una clave de KMS para cifrar los datos de la sesión, consulte [Activación del cifrado de datos de sesión con claves de KMS (consola)](session-preferences-enable-encryption.md).
Si no va a usar el cifrado de AWS KMS para los datos de la sesión, puede eliminar el siguiente contenido de la política.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. Elija **Siguiente: etiquetas**.
1. (Opcional) Para agregar etiquetas, elija **Add tag** (Agregar etiqueta) e ingrese las etiquetas preferidas para la política.
1. Elija **Siguiente: Revisar**.
1. En la página **Review Policy (Revisar política)**, en **Name (Nombre)**, escriba un nombre para la política insertada, como **SessionManagerPermissions**.
1. (Opcional) En **Descripción**, escriba una descripción para la política.
Elija **Crear política**.
Para obtener información acerca de las acciones `ssmmessages`, consulte [Referencia: ec2messages, ssmmessages y otras operaciones de la API](systems-manager-setting-up-messageAPIs.md).
# Creación de un rol de IAM personalizado para Session Manager
Puede crear un rol de AWS Identity and Access Management (IAM) que conceda a Session Manager el permiso para realizar acciones en las instancias administradas de Amazon EC2. Además, puede incluir una política para conceder los permisos necesarios para los registros de la sesión que se enviarán a Amazon Simple Storage Service (Amazon S3) y a los Registros de Amazon CloudWatch.
Después de crear el rol de IAM, para obtener información sobre cómo adjuntar el rol a una instancia, consulte [Adjuntar o reemplazar un perfil de instancia](https://aws.amazon.com/premiumsupport/knowledge-center/attach-replace-ec2-instance-profile/) en el sitio web de AWS re:Post. Para obtener más información sobre los roles y los perfiles de instancia de IAM, consulte [Uso de perfiles de instancia](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) en la *Guía del usuario de IAM* y [Roles de IAM para Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) en la *Guía del usuario de instancias de Linux de Amazon Elastic Compute Cloud*. Para obtener más información sobre cómo crear un rol de servicio de IAM para equipos locales, consulte [Creación del rol de servicio de IAM requerido para Systems Manager en entornos híbridos y multinube](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-multicloud-service-role.html).
**Topics**
+ [Creación de un rol de IAM con permisos mínimos de Session Manager (consola)](#create-iam-instance-profile-ssn-only)
+ [Creación de un rol de IAM con permisos para Session Manager, Amazon S3 y los Registros de CloudWatch (consola)](#create-iam-instance-profile-ssn-logging)
## Creación de un rol de IAM con permisos mínimos de Session Manager (consola)
Utilice el siguiente procedimiento para crear un rol de IAM personalizado con una política que proporcione permisos solo para acciones de Session Manager en las instancias.
**Para crear un perfil de instancia con permisos mínimos de Session Manager (consola)**
1. Inicie sesión en Consola de administración de AWS y abra la consola IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación, seleccione **Políticas** y, a continuación, **Crear política**. (Si aparece el botón **Get Started** [Comenzar], elíjalo y, a continuación, elija **Create Policy** [Crear política]).
1. Seleccione la pestaña **JSON**.
1. Reemplace el contenido predeterminado por la siguiente política. Para cifrar los datos de la sesión mediante AWS Key Management Service (AWS KMS), reemplace *key-name* por el nombre de recurso de Amazon (ARN) de AWS KMS key que desea utilizar.
**nota**
Si se elimina el permiso `ssmmessages:OpenControlChannel` de las políticas asociadas a su perfil de instancia de IAM o al rol de servicio de IAM, el SSM Agent del nodo administrado pierde la conectividad con el servicio de Systems Manager en la nube. No obstante, después de que se elimina el permiso, puede pasar hasta 1 hora hasta que la conexión finaliza. Es el mismo comportamiento que cuando se elimina el rol de instancia de IAM o el rol de servicio de IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:UpdateInstanceInformation",
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
Para obtener más información acerca de cómo utilizar una clave de KMS para cifrar los datos de la sesión, consulte [Activación del cifrado de datos de sesión con claves de KMS (consola)](session-preferences-enable-encryption.md).
Si no va a usar el cifrado de AWS KMS para los datos de la sesión, puede eliminar el siguiente contenido de la política.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. Elija **Siguiente: etiquetas**.
1. (Opcional) Para agregar etiquetas, elija **Add tag** (Agregar etiqueta) e ingrese las etiquetas preferidas para la política.
1. Elija **Siguiente: Revisar**.
1. En la página **Review Policy (Revisar política)**, en **Name (Nombre)**, escriba un nombre para la política insertada, como **SessionManagerPermissions**.
1. (Opcional) En **Descripción**, escriba una descripción para la política.
1. Elija **Crear política**.
1. En el panel de navegación, seleccione **Roles** y luego seleccione **Crear rol**.
1. En la página **Create role** (Crear un rol), elija **AWS service** (Servicio de ), y en **Use case** (Caso de uso) elija **EC2**.
1. Elija **Siguiente**.
1. En la página **Add permissions** (Agregar permisos), seleccione la casilla de verificación situada a la izquierda del nombre de la política que acaba de crear, como **SessionManagerPermissions**.
1. Elija **Siguiente**.
1. En la página **Name, review, and create** (Asignar nombre, revisar y crear), en **Role name** (Nombre de rol), ingrese un nombre para el rol de IAM, como **MySessionManagerRole**.
1. (Opcional) En **Role description (Descripción del rol)**, escriba una descripción para el perfil de instancia.
1. (Opcional) Para agregar etiquetas, elija **Add tag** (Agregar etiqueta) e ingrese las etiquetas preferidas para el rol.
Elija **Creación de rol**.
Para obtener información acerca de las acciones `ssmmessages`, consulte [Referencia: ec2messages, ssmmessages y otras operaciones de la API](systems-manager-setting-up-messageAPIs.md).
## Creación de un rol de IAM con permisos para Session Manager, Amazon S3 y los Registros de CloudWatch (consola)
Utilice el siguiente procedimiento para crear un rol de IAM personalizado con una política que proporcione permisos para acciones de Session Manager en las instancias. La política también proporciona los permisos necesarios para que los registros de la sesión se almacenen en buckets de Amazon Simple Storage Service (Amazon S3) y en grupos de registros de los Registros de Amazon CloudWatch.
**importante**
Para enviar registros de sesión a un bucket de Amazon S3 que pertenezca a otra Cuenta de AWS, debe agregar el permiso `s3:PutObjectAcl` a la política de rol de IAM. Además, debe asegurarse de que la política de bucket conceda acceso entre cuentas al rol de IAM utilizado por la cuenta propietaria para conceder permisos de Systems Manager para instancias administradas. Si el bucket utiliza el cifrado de Key Management Service (KMS), la política de KMS del bucket también debe conceder este acceso entre cuentas. Para obtener más información sobre cómo configurar permisos de bucket entre cuentas en Amazon S3, consulte [Concesión de permisos de bucket entre cuentas](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) en la *Guía del usuario de Amazon Simple Storage Service*. Si no se agregan estos permisos entre cuentas, la cuenta que posee el bucket de Amazon S3 no podrá acceder a los registros de salida de la sesión.
Para obtener información acerca de cómo especificar preferencias para almacenar los registros de sesiones, consulte [Habilitar y deshabilitar el registro de la sesión](session-manager-logging.md).
**Para crear un rol de IAM con permisos para Session Manager, Amazon S3 y los Registros de CloudWatch (consola)**
1. Inicie sesión en Consola de administración de AWS y abra la consola IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. En el panel de navegación, seleccione **Políticas** y, a continuación, **Crear política**. (Si aparece el botón **Get Started** [Comenzar], elíjalo y, a continuación, elija **Create Policy** [Crear política]).
1. Seleccione la pestaña **JSON**.
1. Reemplace el contenido predeterminado por la siguiente política. Reemplace cada *example resource placeholder* por su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel",
"ssm:UpdateInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/s3-prefix/*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetEncryptionConfiguration"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
},
{
"Effect": "Allow",
"Action": "kms:GenerateDataKey",
"Resource": "*"
}
]
}
```
------
1. Elija **Siguiente: etiquetas**.
1. (Opcional) Para agregar etiquetas, elija **Add tag** (Agregar etiqueta) e ingrese las etiquetas preferidas para la política.
1. Elija **Siguiente: Revisar**.
1. En la página **Review Policy (Revisar política)**, en **Name (Nombre)**, escriba un nombre para la política insertada, como **SessionManagerPermissions**.
1. (Opcional) En **Descripción**, escriba una descripción para la política.
1. Elija **Crear política**.
1. En el panel de navegación, seleccione **Roles** y luego seleccione **Crear rol**.
1. En la página **Create role** (Crear un rol), elija **AWS service** (Servicio de ), y en **Use case** (Caso de uso) elija **EC2**.
1. Elija **Siguiente**.
1. En la página **Add permissions** (Agregar permisos), seleccione la casilla de verificación situada a la izquierda del nombre de la política que acaba de crear, como **SessionManagerPermissions**.
1. Elija **Siguiente**.
1. En la página **Name, review, and create** (Asignar nombre, revisar y crear), en **Role name** (Nombre de rol), ingrese un nombre para el rol de IAM, como **MySessionManagerRole**.
1. (Opcional) En **Role description** (Descripción del rol), ingrese una descripción para el rol.
1. (Opcional) Para agregar etiquetas, elija **Add tag** (Agregar etiqueta) e ingrese las etiquetas preferidas para el rol.
1. Elija **Creación de rol**.
# Paso 3: controlar el acceso de la sesión a los nodos administrados
Puede conceder o revocar el acceso a Session Manager de los nodos administrados mediante políticas de AWS Identity and Access Management (IAM). Puede crear una política y adjuntarla a un grupo o usuario de IAM que especifique a qué nodos administrados se puede conectar el grupo o el usuario. También puede especificar las operaciones de la API de Session Manager que el usuario o los grupos pueden realizar en esos nodos administrados.
Para ayudarlo a empezar a utilizar las políticas de permisos de IAM para Session Manager, creamos ejemplos de políticas para un usuario final y un usuario administrador. Puede utilizar estas políticas solo con cambios pequeños. O utilícelas como guía para crear políticas de IAM personalizadas. Para obtener más información, consulte [Ejemplos de políticas de IAM para Session Manager](getting-started-restrict-access-quickstart.md). Para obtener información acerca de cómo crear políticas de IAM y adjuntarlas a usuarios o grupos, consulte [Creación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) y [Adición y eliminación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) en la *Guía del usuario de IAM*.
**Acerca de los formatos de ARN de ID de sesión**
Cuando cree una política de IAM para el acceso a Session Manager, especifique un ID de sesión como parte del nombre de recurso de Amazon (ARN). El ID de la sesión incluye el nombre de usuario como variable. Para ayudar a ilustrarlo, este es el formato de un ARN de Session Manager y un ejemplo:
```
arn:aws:ssm:region-id:account-id:session/session-id
```
Por ejemplo:
```
arn:aws:ssm:us-east-2:123456789012:session/JohnDoe-1a2b3c4d5eEXAMPLE
```
Para obtener más información acerca del uso de variables en políticas de IAM, consulte [Elementos de la política de IAM: variables](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html).
**Topics**
+ [Inicio de una sesión de intérprete de comandos predeterminada mediante la especificación del documento de sesión predeterminado en las políticas de IAM](getting-started-default-session-document.md)
+ [Inicio de una sesión con un documento mediante la especificación de los documentos de sesión en las políticas de IAM](getting-started-specify-session-document.md)
+ [Ejemplos de políticas de IAM para Session Manager](getting-started-restrict-access-quickstart.md)
+ [Políticas de IAM de ejemplo adicionales para Session Manager](getting-started-restrict-access-examples.md)
# Inicio de una sesión de intérprete de comandos predeterminada mediante la especificación del documento de sesión predeterminado en las políticas de IAM
Cuando configura Session Manager para su Cuenta de AWS o cambia las preferencias de sesión en la consola de Systems Manager, el sistema crea un documento de sesión SSM llamado `SSM-SessionManagerRunShell`. Es el documento de sesión predeterminado. Session Manager utiliza este documento para almacenar las preferencias de sesión, que incluyen información como la siguiente:
+ Una ubicación en la que desee guardar los datos de la sesión, como un bucket de Amazon Simple Storage Service (Amazon S3) o un grupo de registro de Registros de Amazon CloudWatch.
+ Un ID de clave de AWS Key Management Service (AWS KMS) para cifrar los datos de la sesión.
+ Si se permite el soporte Ejecutar como para las sesiones.
A continuación, se incluye un ejemplo de la información incluida en el documento de preferencias de sesión denominado `SSM-SessionManagerRunShell`.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyCWLogGroup",
"cloudWatchEncryptionEnabled": false,
"kmsKeyId": "1a2b3c4d",
"runAsEnabled": true,
"runAsDefaultUser": "RunAsUser"
}
}
```
De forma predeterminada, Session Manager utiliza el documento de sesión predeterminado cuando un usuario inicia una sesión desde la Consola de administración de AWS. Esto se aplica a Fleet Manager o Session Manager en la consola de Systems Manager o a EC2 Connect en la consola de Amazon EC2. Además, Session Manager utiliza el documento de sesión predeterminado cuando un usuario inicia una sesión mediante un comando de la AWS CLI, como el siguiente:
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
Para iniciar una sesión de intérprete de comandos predeterminada, debe especificar el documento de la sesión predeterminada en la política de IAM, tal como se muestra en el siguiente ejemplo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnableSSMSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/instance-id",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"*"
]
}
]
}
```
------
# Inicio de una sesión con un documento mediante la especificación de los documentos de sesión en las políticas de IAM
Si utiliza el comando de la AWS CLI [start-session](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) con el documento de sesión predeterminado, puede omitir el nombre del documento. El sistema llama de manera automática al documento de sesión `SSM-SessionManagerRunShell`.
En los demás casos, debe especificar un valor para el parámetro `document-name`. Cuando un usuario especifica el nombre de un documento de sesión en un comando, el sistema comprueba su política de IAM para verificar que tiene permiso para acceder al documento. Si no tiene permiso, se produce un error en la solicitud de conexión. Los siguientes ejemplos incluyen el parámetro `document-name` con el documento de sesión `AWS-StartPortForwardingSession`.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"], "localPortNumber":["56789"]}'
```
Para ver un ejemplo acerca de cómo se especifica un documento de sesión de Session Manager en una política de IAM, consulte [Políticas de usuarios finales de inicio rápido de Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
**nota**
Para iniciar una sesión con SSH, los pasos de configuración deben completarse en el nodo administrado de destino *y* en la máquina local del usuario. Para obtener información, consulte [(Opcional) Permitir y controlar permisos para conexiones de SSH mediante Session Manager](session-manager-getting-started-enable-ssh-connections.md).
# Ejemplos de políticas de IAM para Session Manager
Utilice las muestras de esta sección para que lo ayuden a crear políticas de AWS Identity and Access Management (IAM) que proporcionen los permisos que se necesitan más a menudo para acceder a Session Manager.
**nota**
También puede utilizar una política de AWS KMS key para controlar qué entidades de IAM (usuarios o roles) y Cuentas de AWS tienen acceso a su clave de KMS. Para obtener información, consulte [Información general sobre la administración del acceso a sus recursos de AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) y [Uso de 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*.
**Topics**
+ [Políticas de usuarios finales de inicio rápido de Session Manager](#restrict-access-quickstart-end-user)
+ [Política de administradores de inicio rápido para Session Manager](#restrict-access-quickstart-admin)
## Políticas de usuarios finales de inicio rápido de Session Manager
Utilice los siguientes ejemplos para crear políticas de usuario final de IAM para Session Manager.
Puede crear una política que permita a los usuarios iniciar sesiones únicamente desde la consola de Session Manager, la AWS Command Line Interface (AWS CLI), la consola de Amazon Elastic Compute Cloud (Amazon EC2) o desde las tres.
Estas políticas proporcionan a los usuarios finales la capacidad de iniciar una sesión en un nodo administrado particular y de terminar solo sus propias sesiones. Consulte [Políticas de IAM de ejemplo adicionales para Session Manager](getting-started-restrict-access-examples.md) para ver ejemplos de personalizaciones recomendadas para aplicar en la política.
En las siguientes políticas de ejemplo, reemplace cada *example resource placeholder* por su propia información.
Elija una de las siguientes pestañas para ver la política de ejemplo correspondiente al rango de acceso a la sesión que desea proporcionar.
------
#### [ Administrador de sesiones and Fleet Manager ]
Utilice este ejemplo de política para brindar a los usuarios la capacidad de iniciar y continuar sesiones solo desde las consolas Session Manager y Fleet Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
------
#### [ Amazon EC2 ]
Utilice este ejemplo de política para brindar a los usuarios la capacidad de iniciar y continuar sesiones solo desde la consola de Amazon EC2. Esta política no proporciona todos los permisos necesarios para iniciar sesiones desde la consola de Session Manager y la AWS CLI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
```
------
------
#### [ AWS CLI ]
Utilice este ejemplo de política para brindar a los usuarios la capacidad de iniciar y continuar sesiones solo desde AWS CLI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/key-name"
}
]
}
```
------
------
**nota**
`SSM-SessionManagerRunShell` es el nombre predeterminado del documento de SSM que Session Manager crea para almacenar sus preferencias de configuración de la sesión. En cambio, puede crear un documento de Session personalizado y especificarlo en esta política. También puede especificar el documento proporcionado por AWS `AWS-StartSSHSession` para los usuarios que inician sesiones mediante SSH. Para obtener más información acerca de los pasos de configuración necesarios para admitir sesiones mediante SSH, consulte [(Opcional) Permitir y controlar permisos para conexiones de SSH a través de Session Manager](session-manager-getting-started-enable-ssh-connections.md).
El permiso `kms:GenerateDataKey` le permite crear una clave de cifrado de datos que se utilizará para cifrar los datos de la sesión. Si va a usar el cifrado de AWS Key Management Service (AWS KMS) para los datos de la sesión, sustituya *key-name* por el nombre de recurso de Amazon (ARN) de la clave de KMS que desee utilizar, con el formato `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE`. Si no va a usar el cifrado de claves de KMS para sus datos de sesión, elimine el siguiente contenido de la política.
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "key-name"
}
```
Para obtener más información acerca del uso de AWS KMS para cifrar los datos de la sesión, consulte [Activación del cifrado de datos de sesión con claves de KMS (consola)](session-preferences-enable-encryption.md).
El permiso para [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html) es necesario para los casos en que un usuario intente iniciar una sesión desde la consola Amazon EC2, pero primero debe actualizar SSM Agent a la versión mínima requerida para Session Manager. Run Command se utiliza para enviar un comando a la instancia para actualizar el agente.
## Política de administradores de inicio rápido para Session Manager
Utilice los siguientes ejemplos para crear políticas de administrador de IAM para Session Manager.
Estas políticas proporcionan a los administradores la capacidad de iniciar una sesión en los nodos administrados que están etiquetados con `Key=Finance,Value=WebServers`, el permiso para crear, actualizar y eliminar las preferencias de los usuarios y el permiso para terminar únicamente sus propias sesiones. Consulte [Políticas de IAM de ejemplo adicionales para Session Manager](getting-started-restrict-access-examples.md) para ver ejemplos de personalizaciones recomendadas para aplicar en la política.
Puede crear una política que permita a los administradores realizar estas tareas únicamente desde la consola de Session Manager, la AWS CLI, la consola de Amazon EC2 o desde las tres.
En las siguientes políticas de ejemplo, reemplace cada *example resource placeholder* por su propia información.
Elija una de las siguientes pestañas para ver el ejemplo de política para el escenario de acceso que desea admitir.
------
#### [ Administrador de sesiones and CLI ]
Utilice este ejemplo de política para brindar a los administradores la capacidad de llevar a cabo las tareas relacionadas con la sesión solo desde la consola de Session Manager y la AWS CLI. Esta política no proporciona todos los permisos necesarios para realizar las tareas relacionadas con la sesión desde la consola de Amazon EC2.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/Finance": [
"WebServers"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:GetDocument",
"ssm:StartSession"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:OpenDataChannel"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
#### [ Amazon EC2 ]
Utilice este ejemplo de política para brindar a los administradores la capacidad de llevar a cabo tareas relacionadas con la sesión solo desde la consola de Amazon EC2. Esta política no proporciona todos los permisos necesarios para realizar tareas relacionadas con la sesión desde la consola de Session Manager y la AWS CLI.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag-key": [
"tag-value"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
#### [ Administrador de sesiones, CLI, and Amazon EC2 ]
Utilice este ejemplo de política para brindar a los administradores la capacidad de llevar a cabo tareas relacionadas con la sesión desde la consola de Session Manager, la AWS CLI y la consola de Amazon EC2.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession",
"ssm:SendCommand"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/tag-key": [
"tag-value"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:DescribeSessions",
"ssm:GetConnectionStatus",
"ssm:DescribeInstanceInformation",
"ssm:DescribeInstanceProperties",
"ec2:DescribeInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:CreateDocument",
"ssm:UpdateDocument",
"ssm:GetDocument",
"ssm:StartSession"
],
"Resource": "arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
}
]
}
```
------
------
**nota**
El permiso para [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html) es necesario en aquellos casos en los que un usuario intenta iniciar una sesión desde la consola de Amazon EC2, pero antes se debe enviar un comando para actualizar SSM Agent.
# Políticas de IAM de ejemplo adicionales para Session Manager
Consulte los siguientes ejemplos de políticas para crear una política de AWS Identity and Access Management (IAM) personalizada para todos los escenarios de acceso de usuarios a Session Manager que desee admitir.
**Topics**
+ [Ejemplo 1: conceder acceso a documentos en la consola](#grant-access-documents-console-example)
+ [Ejemplo 2: restringir el acceso a nodos administrados específicos](#restrict-access-example-instances)
+ [Ejemplo 3: restringir el acceso en función de etiquetas](#restrict-access-example-instance-tags)
+ [Ejemplo 4: permitir a un usuario finalizar solo las sesiones que inició](#restrict-access-example-user-sessions)
+ [Ejemplo 5: permitir acceso completo (administrativo) a todas las sesiones](#restrict-access-example-full-access)
## Ejemplo 1: conceder acceso a documentos en la consola
Puede permitir que los usuarios especifiquen un documento personalizado cuando inician una sesión mediante la consola del administrador de sesiones. El siguiente ejemplo de política de IAM concede permiso para acceder a documentos con nombres que comiencen con **SessionDocument-** en la Región de AWS y la Cuenta de AWS especificadas.
Para utilizar esta política, reemplace cada *example-resource-placeholder* con su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:ListDocuments"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SessionDocument-*"
]
}
]
}
```
------
**nota**
La consola del administrador de sesiones solo admite documentos de sesión que tienen un `sessionType` de `Standard_Stream`, los cuales se utilizan para definir las preferencias de sesión. Para obtener más información, consulte [Esquema del documento de Session](session-manager-schema.md).
## Ejemplo 2: restringir el acceso a nodos administrados específicos
Puede crear una política de IAM que defina a qué nodos administrados puede conectarse un usuario mediante Administrador de sesiones. Por ejemplo, la siguiente política otorga al usuario el permiso para iniciar, finalizar y reanudar sus sesiones en tres nodos específicos. La política impide que el usuario se conecte a nodos distintos de los especificados.
**nota**
Para los usuarios federados, consulte [Ejemplo 4: permitir a un usuario finalizar solo las sesiones que inició](#restrict-access-example-user-sessions).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/i-1234567890EXAMPLE",
"arn:aws:ec2:us-east-1:111122223333:instance/i-abcdefghijEXAMPLE",
"arn:aws:ec2:us-east-1:111122223333:instance/i-0e9d8c7b6aEXAMPLE",
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
------
## Ejemplo 3: restringir el acceso en función de etiquetas
Puede restringir el acceso a nodos administrados en función de etiquetas específicas. En el siguiente ejemplo, el usuario tiene permitido iniciar y reanudar sesiones (`Effect: Allow, Action: ssm:StartSession, ssm:ResumeSession`) en cualquier nodo administrado (`Resource: arn:aws:ec2:region:987654321098:instance/*`) con la condición de que el nodo sea un servidor web de finanzas (`ssm:resourceTag/Finance: WebServer`). Si el usuario envía un comando a un nodo administrado que no está etiquetado o que tiene alguna etiqueta que no sea `Finance: WebServer`, el resultado del comando incluirá `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/*"
],
"Condition": {
"StringLike": {
"ssm:resourceTag/Finance": [
"WebServers"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession",
"ssm:ResumeSession"
],
"Resource": [
"arn:aws:ssm:*:*:session/${aws:userid}-*"
]
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
Puede crear políticas de IAM que permitan al usuario iniciar sesiones en los nodos administrados que tengan varias etiquetas. La siguiente política permite al usuario iniciar sesiones en nodos administrados que tengan las dos etiquetas especificadas aplicadas. Si un usuario envía un comando a un nodo administrado que no está etiquetado con estas dos etiquetas, el resultado del comando incluirá `AccessDenied`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:StartSession"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/tag-key1":[
"tag-value1"
],
"ssm:resourceTag/tag-key2":[
"tag-value2"
]
}
}
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
Para obtener más información acerca de la creación de políticas de IAM, consulte [Políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) en la *Guía del usuario de IAM*. Para obtener más información sobre el etiquetado de nodos administrados, 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* (el contenido se aplica a los nodos administrados de Windows y Linux). Para obtener más información acerca de cómo aumentar su posición de seguridad frente a comandos de nivel raíz no autorizados en los nodos administrados, consulte [Restricción del acceso a los comandos de nivel raíz con SSM Agent](ssm-agent-restrict-root-level-commands.md)
## Ejemplo 4: permitir a un usuario finalizar solo las sesiones que inició
Session Manager proporciona dos métodos para controlar qué sesiones tiene permitido finalizar un usuario federado en su Cuenta de AWS.
+ Utilice la variable `{aws:userid}` en una política de permisos de AWS Identity and Access Management (IAM). Los usuarios federados solo pueden finalizar las sesiones que iniciaron. Para los usuarios no federados, utilice el Método 1. Para los usuarios federados, utilice el Método 2.
+ Utilice las etiquetas proporcionadas por AWS en una política de permisos de IAM. En la política, incluya una condición que permita a los usuarios terminar solo las sesiones marcadas con etiquetas específicas proporcionadas por AWS. Este método funciona para todas las cuentas, incluidas las que utilizan ID federados para otorgar acceso a AWS.
### Método 1: conceder privilegios TerminateSession usando la variable `{aws:username}`
La siguiente política de IAM permite al usuario ver los ID de todas las sesiones de su cuenta. Sin embargo, los usuarios solo pueden interactuar con los nodos administrados a través de las sesiones que iniciaron. Un usuario con la siguiente política asignada no puede conectarse a las sesiones de otros usuarios ni terminarlas. La política utiliza la variable `{aws:username}` para lograrlo.
**nota**
Este método no funciona para las cuentas que otorgan acceso a AWS con ID federados.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:DescribeSessions"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Action": [
"ssm:TerminateSession"
],
"Effect": "Allow",
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
```
------
### Método 2: otorgar privilegios de TerminateSession mediante etiquetas proporcionadas por AWS
Puede controlar qué sesiones puede finalizar un usuario si incluye variables de claves de etiqueta condicionales en una política de IAM. La condición especifica que el usuario solo puede finalizar las sesiones etiquetadas con una o ambas de estas variables de clave de etiqueta específicas y un valor especificado.
Cuando un usuario de su Cuenta de AWS inicia una sesión, Session Manager aplica dos etiquetas de recurso a la sesión. La primera etiqueta de recurso es `aws:ssmmessages:target-id`, con la que se especifica el ID del destino que el usuario puede finalizar. La otra etiqueta de recurso es `aws:ssmmessages:session-id`, con un valor en el formato `role-id:caller-specified-role-name`.
**nota**
Session Manager no admite etiquetas personalizadas para esta política de control de acceso de IAM. Debe utilizar las etiquetas de recursos proporcionadas por AWS que se describen a continuación.
** `aws:ssmmessages:target-id` **
Con esta clave de etiqueta, el ID del nodo administrado se incluye como valor en la política. En el siguiente bloque de política, la instrucción de condición permite al usuario terminar solo el nodo i-02573cafcfEXAMPLE.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:target-id": [
"i-02573cafcfEXAMPLE"
]
}
}
}
]
}
```
Si el usuario intenta finalizar una sesión para la que no se le ha concedido este permiso `TerminateSession`, recibirá un error `AccessDeniedException`.
** `aws:ssmmessages:session-id` **
Esta clave de etiqueta incluye una variable para el ID de sesión como valor en la solicitud para iniciar una sesión.
En el ejemplo siguiente se muestra una política para los casos en los que el tipo de intermediario es `User`. El valor que proporciona para `aws:ssmmessages:session-id` es el ID del usuario. En este ejemplo, `AIDIODR4TAW7CSEXAMPLE` representa el ID de un usuario de su Cuenta de AWS. Para recuperar el ID de un usuario de su Cuenta de AWS, utilice el comando `get-user` de IAM. Para obtener información, consulte [get-user](https://docs.aws.amazon.com/IAM/latest/UserGuide/get-user.html) en la sección AWS Identity and Access Management de la *Guía del usuario de IAM*.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"AIDIODR4TAW7CSEXAMPLE"
]
}
}
}
]
}
```
En el ejemplo siguiente se muestra una política para los casos en los que el tipo de intermediario es `AssumedRole`. Puede utilizar la variable `{aws:userid}` en el valor de `aws:ssmmessages:session-id`. También puede codificar de forma rígida un ID de rol para el valor de `aws:ssmmessages:session-id`. Si codifica un ID de rol, debe proporcionar el valor en el formato `role-id:caller-specified-role-name`. Por ejemplo, `AIDIODR4TAW7CSEXAMPLE:MyRole`.
Para que se apliquen las etiquetas del sistema, el ID de rol que proporcione solo puede contener los siguientes caracteres: letras Unicode, 0-9, espacio `_`, `.`, `:`, `/`, `=`, `+`, `-`, `@` y `\`.
Para recuperar el ID de un rol de su Cuenta de AWS, utilice el comando `get-caller-identity`. Para obtener información, consulte [get-caller-identity](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html) en la Referencia de comandos de la AWS CLI.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}*"
]
}
}
}
]
}
```
Si un usuario intenta finalizar una sesión para la que no se le ha concedido este permiso `TerminateSession`, recibirá un error `AccessDeniedException`.
**`aws:ssmmessages:target-id`** y **`aws:ssmmessages:session-id`**
También puede crear políticas de IAM que permitan al usuario terminar sesiones marcadas con ambas etiquetas del sistema, como se muestra en este ejemplo.
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ssm:TerminateSession"
],
"Resource":"*",
"Condition":{
"StringLike":{
"ssm:resourceTag/aws:ssmmessages:target-id":[
"i-02573cafcfEXAMPLE"
],
"ssm:resourceTag/aws:ssmmessages:session-id":[
"${aws:userid}*"
]
}
}
}
]
}
```
## Ejemplo 5: permitir acceso completo (administrativo) a todas las sesiones
La siguiente política de IAM permite a un usuario interactuar totalmente con todos los nodos administrados y sesiones creadas por todos los usuarios de todos los nodos. Debe ser concedida únicamente a un administrador que necesita un control completo sobre las actividades de Session Manager de la organización.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:StartSession",
"ssm:TerminateSession",
"ssm:ResumeSession",
"ssm:DescribeSessions",
"ssm:GetConnectionStatus"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
------
# Paso 4: configurar las preferencias de sesión
Los usuarios a los que se les hayan concedido permisos administrativos en su política de AWS Identity and Access Management (IAM) pueden configurar las preferencias de sesión, incluidas las siguientes:
+ Active Ejecutar como soporte para nodos administrados de Linux. Esto permite iniciar sesiones con las credenciales de un usuario especificado del sistema operativo en lugar de con las credenciales de una cuenta `ssm-user` generada por el sistema que AWS Systems Manager Session Manager puede crear en un nodo administrado.
+ Configure Session Manager para que utilice el cifrado de AWS KMS key para proporcionar protección adicional a los datos transmitidos entre los equipos del clientes y los nodos administrados.
+ Configure Session Manager para crear y enviar los registros del historial de sesiones a un bucket de Amazon Simple Storage Service (Amazon S3) o a un grupo de registros de los Registros de Amazon CloudWatch. Los datos de registro almacenados pueden utilizarse para informar sobre conexiones de sesiones realizadas en los nodos administrados y los comandos ejecutados durante las sesiones.
+ Configure los tiempos de espera de sesión. Puede utilizar esta configuración para especificar cuándo terminar una sesión después de un periodo de inactividad.
+ Configure Session Manager para que utilice perfiles de shell configurables. Estos perfiles personalizables le permiten definir preferencias dentro de las sesiones, como las preferencias de shell, las variables de entorno, los directorios de trabajo y la ejecución de varios comandos cuando se inicia una sesión.
Para obtener más información acerca de los permisos necesarios para configurar Session Manager, consulte [Concesión o denegación de permisos de usuario para actualizar preferencias de Session Manager](preference-setting-permissions.md).
**Topics**
+ [Concesión o denegación de permisos de usuario para actualizar preferencias de Session Manager](preference-setting-permissions.md)
+ [Especificación de un valor de tiempo de espera de sesión inactiva](session-preferences-timeout.md)
+ [Especificar la duración máxima de la sesión](session-preferences-max-timeout.md)
+ [Permiso de perfiles de shell configurables](session-preferences-shell-config.md)
+ [Activación del soporte Ejecutar como para nodos administrados de Linux y macOS](session-preferences-run-as.md)
+ [Activación del cifrado de datos de sesión con claves de KMS (consola)](session-preferences-enable-encryption.md)
+ [Creación de un documento de preferencias de Session Manager (línea de comandos)](getting-started-create-preferences-cli.md)
+ [Actualizar preferencias de Session Manager (línea de comandos)](getting-started-configure-preferences-cli.md)
Para obtener más información acerca de cómo utilizar la consola de Systems Manager para configurar opciones para el registro de los datos de las sesiones, consulte los siguientes temas:
+ [Registro de los datos de la sesión con Amazon S3 (consola)](session-manager-logging-s3.md)
+ [Streaming de los datos de la sesión con los Registros de Amazon CloudWatch (consola)](session-manager-logging-cwl-streaming.md)
+ [Registro de los datos de la sesión con los Registros de Amazon CloudWatch (consola)](session-manager-logging-cloudwatch-logs.md)
# Concesión o denegación de permisos de usuario para actualizar preferencias de Session Manager
Las preferencias de la cuenta se almacenan como documentos de AWS Systems Manager (SSM) para cada Región de AWS. Antes de que un usuario pueda actualizar las preferencias de cuenta para las sesiones de su cuenta, es preciso que se le concedan los permisos necesarios para obtener acceso al tipo de documento de SSM donde se almacenan estas preferencias. Estos permisos se conceden por medio de políticas de AWS Identity and Access Management (IAM).
**Política de administradores para permitir la creación y actualización de preferencias**
Un administrador puede tener la siguiente política para crear y actualizar las preferencias en cualquier momento. La siguiente política otorga permisos para acceder al documento `SSM-SessionManagerRunShell` de la cuenta 123456789012 en la región us-east-2 y actualizarlo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Allow",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
**Política de usuarios para evitar que se actualicen las preferencias**
Utilice la siguiente política para impedir que los usuarios finales de su cuenta actualicen o anulen las preferencias de Session Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:CreateDocument",
"ssm:GetDocument",
"ssm:UpdateDocument",
"ssm:DeleteDocument"
],
"Effect": "Deny",
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SSM-SessionManagerRunShell"
]
}
]
}
```
------
# Especificación de un valor de tiempo de espera de sesión inactiva
Session Manager, una herramienta de AWS Systems Manager, le permite especificar la cantidad de tiempo que permitirá al usuario estar inactivo antes de que una sesión termine. De forma predeterminada, el tiempo de espera de las sesiones finaliza después de 20 minutos de inactividad. Puede modificar esta configuración para especificar que la sesión termine después de entre 1 y 60 minutos de inactividad. Algunas agencias profesionales de seguridad informática recomiendan configurar los tiempos de espera de sesión inactiva en un máximo de 15 minutos.
El temporizador de tiempo de espera de la sesión inactiva se restablece cuando Session Manager recibe entradas del lado del cliente. Estas entradas incluyen, entre otros:
+ Entrada de teclado en el terminal
+ Eventos de cambio de tamaño de la ventana del navegador o del terminal
+ Reconexión de sesión (ResumeSession), que puede producirse debido a interrupciones de la red, administración de pestañas del navegador o desconexiones de WebSocket
Dado que estos eventos restablecen el temporizador de inactividad, cabe la posibilidad de que una sesión permanezca activa por más tiempo que el tiempo de espera configurado, incluso si no hay comandos directos del terminal.
Si sus requisitos de seguridad exigen límites estrictos de duración de la sesión, independientemente de la actividad, utilice la configuración *Duración máxima de la sesión* además del tiempo de espera de inactividad. Para obtener más información, consulte [Especificar la duración máxima de la sesión](session-preferences-max-timeout.md).
**Para permitir el tiempo de espera de sesión inactiva (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 **Session Manager**.
1. Elija la pestaña **Preferences (Preferencias)** y, a continuación, **Edit (Editar)**.
1. Especifique la cantidad de tiempo que permitirá que el usuario esté inactivo antes de que finalice la sesión en el campo **minutes** (minutos) dentro de **Idle session timeout** (Tiempo de espera de sesión inactiva).
1. Seleccione **Save**.
# Especificar la duración máxima de la sesión
Session Manager, una herramienta de AWS Systems Manager, le permite determinar la duración máxima de una sesión antes de que finalice. De forma predeterminada, las sesiones no tienen una duración máxima. El valor que defina para la duración máxima de la sesión debe estar entre 1 y 1440 minutos.
**Para especificar la duración máxima de la sesión (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 **Session Manager**.
1. Elija la pestaña **Preferences (Preferencias)** y, a continuación, **Edit (Editar)**.
1. Seleccione la casilla de verificación situada junto a **Enable maximum session duration** (Habilitación de la duración máxima de la sesión).
1. Especifique la duración máxima de la sesión antes de que finalice en el campo **minutes** (minutos) en **Maximum session duration** (Duración máxima de la sesión).
1. Seleccione **Save**.
# Permiso de perfiles de shell configurables
De forma predeterminada, las sesiones en las instancias de EC2 para Linux se inician mediante el shell Bourne (sh). Sin embargo, es posible que prefiera utilizar otro shell, como bash. Cuando permite perfiles de shell configurables, puede personalizar las preferencias dentro de las sesiones, como preferencias de shell, variables de entorno, directorios de trabajo y ejecutar varios comandos cuando se inicia una sesión.
**importante**
Systems Manager no verifica los comandos ni los scripts del perfil de shell antes de ejecutarlos para ver qué cambios realizarían en una instancia. Para restringir la capacidad de un usuario de modificar los comandos o los scripts ingresados en su perfil de shell, se recomienda lo siguiente:
Cree un documento personalizado de tipo sesión para sus usuarios y roles de AWS Identity and Access Management (IAM). A continuación, modifique la política de IAM para estos usuarios y roles, de modo que la operación `StartSession` de la API solo pueda utilizar el documento de tipo sesión que creó para ellos. Para obtener más información, consulte [Creación de un documento de preferencias de Session Manager (línea de comandos)](getting-started-create-preferences-cli.md) y [Políticas de usuarios finales de inicio rápido de Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
Modifique la política de IAM de los usuarios y los roles de IAM para denegar el acceso a la operación `UpdateDocument` de la API para el recurso del documento de tipo sesión que cree. Esto permite a los usuarios y los roles usar el documento que creó para sus preferencias de sesión, sin permitirles modificar ninguna de las configuraciones.
**Para activar perfiles de shell configurables**
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 **Session Manager**.
1. Elija la pestaña **Preferences (Preferencias)** y, a continuación, **Edit (Editar)**.
1. Especifique las variables de entorno, las preferencias de shell o los comandos que desee ejecutar cuando se inicie la sesión en los campos de los sistemas operativos aplicables.
1. Seleccione **Save**.
A continuación, se muestran algunos comandos de ejemplo que se pueden agregar a su perfil de shell.
Cambie al shell bash y al directorio /usr en las instancias de Linux.
```
exec /bin/bash
cd /usr
```
Muestre una marca de tiempo y un mensaje de bienvenida al inicio de una sesión.
------
#### [ Linux & macOS ]
```
timestamp=$(date '+%Y-%m-%dT%H:%M:%SZ')
user=$(whoami)
echo $timestamp && echo "Welcome $user"'!'
echo "You have logged in to a production instance. Note that all session activity is being logged."
```
------
#### [ Windows ]
```
$timestamp = (Get-Date).ToString("yyyy-MM-ddTH:mm:ssZ")
$splitName = (whoami).Split("\")
$user = $splitName[1]
Write-Host $timestamp
Write-Host "Welcome $user!"
Write-Host "You have logged in to a production instance. Note that all session activity is being logged."
```
------
Vea la actividad dinámica del sistema al inicio de una sesión.
------
#### [ Linux & macOS ]
```
top
```
------
#### [ Windows ]
```
while ($true) { Get-Process | Sort-Object -Descending CPU | Select-Object -First 30; `
Start-Sleep -Seconds 2; cls
Write-Host "Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName";
Write-Host "------- ------ ----- ----- ----- ------ -- -----------"}
```
------
# Activación del soporte Ejecutar como para nodos administrados de Linux y macOS
De forma predeterminada, Session Manager autentica las conexiones con las credenciales de la cuenta `ssm-user` generada por el sistema que se crea en un nodo administrado. (En los equipos Linux y macOS, la cuenta se agrega a `/etc/sudoers/`). Si lo desea, puede autenticar las sesiones con las credenciales de una cuenta de usuario del sistema operativo (SO) o un usuario de dominio para instancias unidas a un Active Directory. En este caso, Session Manager comprueba que la cuenta del sistema operativo que especificó existe en el nodo o en el dominio antes de iniciar la sesión. Si intenta iniciar una sesión con una cuenta del sistema operativo que no existe en el nodo ni en el dominio, se produce un error en la conexión.
**nota**
Administrador de sesiones no admite el uso de una cuenta de usuario `root` de un sistema operativo para autenticar las conexiones. En el caso de las sesiones que se autentican mediante una cuenta de usuario del sistema operativo, es posible que no se apliquen las políticas de directorio y nivel de sistema del nodo, como las restricciones de inicio de sesión o las restricciones de uso de los recursos del sistema.
**Funcionamiento**
Si activa Ejecutar como soporte para las sesiones, el sistema verifica los permisos de acceso tal como se indica a continuación:
1. Para el usuario que está iniciando la sesión, ¿se ha etiquetado su entidad de IAM (usuario o rol) con `SSMSessionRunAs = os user account name`?
En caso afirmativo, ¿existe el nombre de usuario del sistema operativo en el nodo administrado? En caso afirmativo, inicie la sesión. Si no es así, no permita que se inicie una sesión.
Si la entidad de IAM *no* se ha etiquetado con `SSMSessionRunAs = os user account name`, continúe con el paso 2.
1. Si la entidad de IAM no se ha etiquetado con `SSMSessionRunAs = os user account name`, ¿se ha especificado un nombre de usuario del sistema operativo en las preferencias de la Cuenta de AWS de Session Manager?
En caso afirmativo, ¿existe el nombre de usuario del sistema operativo en el nodo administrado? En caso afirmativo, inicie la sesión. Si no es así, no permita que se inicie una sesión.
**nota**
Al activar el soporte Ejecutar como, se impide que Administrador de sesiones inicie sesiones con la cuenta `ssm-user` en un nodo administrado. Esto significa que si Session Manager no se puede conectar mediante la cuenta de usuario del sistema operativo especificada, no se recurre a la conexión mediante el método predeterminado.
Si activa Ejecutar como sin especificar una cuenta de sistema operativo ni etiquetar una entidad de IAM y no ha especificado ninguna cuenta de sistema operativo en las preferencias de Administrador de sesiones, se produce un error en los intentos de conexión a la sesión.
**Para activar el soporte Ejecutar como para nodos administrados de Linux y 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 **Session Manager**.
1. Elija la pestaña **Preferences (Preferencias)** y, a continuación, **Edit (Editar)**.
1. Seleccione la casilla de verificación situada junto a **Activar soporte Ejecutar como para instancias de Linux**.
1. Realice una de las siguientes acciones:
+ **Opción 1**: en el campo **Nombre de usuario del sistema operativo**, ingrese el nombre de la cuenta de usuario del sistema operativo que desea usar para iniciar sesiones. Con esta opción, el mismo usuario del sistema operativo ejecuta todas las sesiones para todos los usuarios de su Cuenta de AWS que se conectan mediante Session Manager.
+ **Opción 2** (recomendada): elija el enlace **Abrir la consola de IAM**. En el panel de navegación, seleccione **Usuarios** o **Roles**. Elija la entidad (usuario o rol) a la que añadir etiquetas y, a continuación, elija la pestaña **Tags**. Escriba `SSMSessionRunAs` para el nombre de la clave. Ingrese el nombre de una cuenta de usuario del sistema operativo para el valor clave. Seleccione **Save changes (Guardar cambios)**.
Con esta opción, puede especificar usuarios de sistema operativo únicos para diferentes entidades de IAM, si así lo desea. Para obtener más información acerca del etiquetado de entidades (usuarios o roles) de IAM, consulte [Etiquetado de recursos de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) en la *Guía del usuario de IAM*.
A continuación se muestra un ejemplo.
![\[Captura de pantalla de la especificación de etiquetas para el permiso Ejecutar como de Session Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/ssn-run-as-tags.png)
1. Seleccione **Save**.
# Activación del cifrado de datos de sesión con claves de KMS (consola)
Utilice AWS Key Management Service (AWS KMS) para crear y administrar las claves de cifrado. Con AWS KMS, puede controlar el uso del cifrado en una amplia gama de Servicios de AWS y en sus aplicaciones. Puede especificar que los datos de la sesión transmitidos entre los nodos administrados y los equipos locales de los usuarios en la Cuenta de AWS se cifren con cifrado de claves de KMS. (Esto se suma al cifrado TLS 1.2/1.3 que AWS ya proporciona de forma predeterminada). Para cifrar los datos de la sesión Session Manager, cree una clave KMS *simétrica* mediante AWS KMS.
El cifrado de AWS KMS está disponible para `Standard_Stream`, `InteractiveCommands` y los tipos de sesión de `NonInteractiveCommands`. Para utilizar la opción de cifrar los datos de la sesión con una clave creada en AWS KMS, el nodo administrado debe tener instalada la versión 2.3.539.0 de AWS Systems Manager SSM Agent o una posterior.
**nota**
Debe permitir el cifrado de AWS KMS con el fin de restablecer las contraseñas en los nodos administrados desde la consola de AWS Systems Manager. Para obtener más información, consulte [Restablecer una contraseña en un nodo administrado](fleet-manager-reset-password.md#managed-instance-reset-a-password).
Puede utilizar una clave que haya creado en su Cuenta de AWS. También puede utilizar una clave que se haya creado en una diferente Cuenta de AWS. El creador de la clave de una Cuenta de AWS diferente debe proporcionarle los permisos necesarios para usar la clave.
Después de activar el cifrado con clave de KMS para los datos de la sesión, tanto los usuarios que inicien sesiones como los nodos administrados a los que se conecten deberán tener permiso para utilizar la clave. Usted proporciona el permiso para utilizar la clave de KMS con Session Manager a través de las políticas de AWS Identity and Access Management (IAM). Para obtener información, consulte los siguientes temas:
+ Agregar permisos de AWS KMS para los usuarios de su cuenta: [Ejemplos de políticas de IAM para Session Manager](getting-started-restrict-access-quickstart.md).
+ Agregar permisos de AWS KMS para los nodos administrados de la cuenta: [Paso 2: verificación o agregación de permisos de instancia para Session Manager](session-manager-getting-started-instance-profile.md).
Para obtener más información acerca de cómo crear y administrar las claves de KMS, consulte la [https://docs.aws.amazon.com/kms/latest/developerguide/](https://docs.aws.amazon.com/kms/latest/developerguide/).
Para obtener más información acerca de cómo utilizar la AWS CLI para activar el cifrado de datos de sesión en su cuenta con claves de KMS, consulte [Creación de un documento de preferencias de Session Manager (línea de comandos)](getting-started-create-preferences-cli.md) o [Actualizar preferencias de Session Manager (línea de comandos)](getting-started-configure-preferences-cli.md).
**nota**
Se aplica un cargo por utilizar claves de KMS. Para obtener información, consulte [Precios de AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
**Para activar el cifrado de datos de sesión con claves de KMS (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 **Session Manager**.
1. Elija la pestaña **Preferences (Preferencias)** y, a continuación, **Edit (Editar)**.
1. Seleccione la casilla de verificación situada junto a **Enable KMS encryption** (Habilitar cifrado de KMS).
1. Realice una de las siguientes acciones:
+ Elija el botón que se encuentra junto a **Select a KMS key in my current account** (Seleccione una clave de KMS en la cuenta actual) y, a continuación, seleccione una de las claves de la lista.
-o bien-
Elija el botón junto a **Enter a KMS key alias or KMS key ARN (Introducir un alias de clave de KMS o un ARN de clave de KMS)**. Ingrese de forma manual un alias de clave de KMS para una clave creada en su cuenta actual o ingrese el nombre de recurso de Amazon (ARN) de la clave perteneciente a otra cuenta. A continuación se muestran algunos ejemplos:
+ Alias de clave: `alias/my-kms-key-alias`
+ ARN de clave: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE`
-o bien-
Elija **Create new key** (Crear nueva clave) para crear una nueva clave de KMS en su cuenta. Después de crear la clave nueva, vuelva a la pestaña **Preferences (Preferencias)** y seleccione la clave para el cifrado de los datos de la sesión en su cuenta.
Para obtener más información acerca de cómo compartir claves, consulte [Permiso para que las Cuentas de AWS externas accedan a una clave](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html#key-policy-modifying-external-accounts) en la *Guía para desarrolladores de AWS Key Management Service*.
1. Seleccione **Save**.
# Creación de un documento de preferencias de Session Manager (línea de comandos)
Utilice el siguiente procedimiento para crear documentos SSM que definan las preferencias para las sesiones de AWS Systems Manager Session Manager. Puede utilizar el documento para configurar las opciones de sesión, incluidos el cifrado de datos, la duración de la sesión y el registro. Por ejemplo, puede especificar si desea almacenar datos de registro de sesión en un bucket de Amazon Simple Storage Service (Amazon S3) o en un grupo de registro de Registros de Amazon CloudWatch. Puede crear documentos que definan las preferencias generales para todas las sesiones de una Cuenta de AWS y una Región de AWS, o que definan las preferencias para las sesiones individuales.
**nota**
Además, puede configurar las preferencias generales de la sesión mediante la consola del administrador de sesiones.
Los documentos utilizados para configurar las preferencias del administrador de sesiones deben tener un `sessionType` de `Standard_Stream`. Para obtener más información sobre los documentos de sesiones, consulte [Esquema del documento de Session](session-manager-schema.md).
Para obtener información sobre el uso de la línea de comandos para actualizar las preferencias de Session Manager existentes, consulte [Actualizar preferencias de Session Manager (línea de comandos)](getting-started-configure-preferences-cli.md).
Para ver un ejemplo de cómo se crean las preferencias de sesión mediante CloudFormation, consulte [Creación de un documento de Systems Manager para preferencias de Session Manager](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-document.html#aws-resource-ssm-document--examples) en la *Guía del usuario de AWS CloudFormation*.
**nota**
Este procedimiento describe cómo crear documentos para establecer las preferencias de Session Manager a nivel de Cuenta de AWS. Para crear documentos que se utilizarán para establecer las preferencias a nivel de sesión, especifique un valor distinto de `SSM-SessionManagerRunShell` para las entradas de comandos relacionadas con el nombre del archivo.
Para utilizar el documento para establecer las preferencias de las sesiones iniciadas desde AWS Command Line Interface (AWS CLI), proporcione el nombre del documento como el valor del parámetro `--document-name`. Para establecer las preferencias de las sesiones iniciadas desde la consola del administrador de sesiones, puede escribir el nombre del documento o seleccionarlo de una lista.
**Para crear preferencias de Session Manager (línea de comandos)**
1. Cree un archivo JSON en su equipo local con un nombre similar a `SessionManagerRunShell.json` y, a continuación, péguele el siguiente contenido.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "",
"runAsEnabled": false,
"runAsDefaultUser": "",
"idleSessionTimeout": "",
"maxSessionDuration": "",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
También puede pasar valores a sus preferencias de sesión usando parámetros en lugar de codificar de forma rígida los valores, como se muestra en el siguiente ejemplo.
```
{
"schemaVersion":"1.0",
"description":"Session Document Parameter Example JSON Template",
"sessionType":"Standard_Stream",
"parameters":{
"s3BucketName":{
"type":"String",
"default":""
},
"s3KeyPrefix":{
"type":"String",
"default":""
},
"s3EncryptionEnabled":{
"type":"Boolean",
"default":"false"
},
"cloudWatchLogGroupName":{
"type":"String",
"default":""
},
"cloudWatchEncryptionEnabled":{
"type":"Boolean",
"default":"false"
}
},
"inputs":{
"s3BucketName":"{{s3BucketName}}",
"s3KeyPrefix":"{{s3KeyPrefix}}",
"s3EncryptionEnabled":"{{s3EncryptionEnabled}}",
"cloudWatchLogGroupName":"{{cloudWatchLogGroupName}}",
"cloudWatchEncryptionEnabled":"{{cloudWatchEncryptionEnabled}}",
"kmsKeyId":""
}
}
```
1. Especifique a dónde quiere enviar los datos de la sesión. Puede especificar el nombre de un bucket de S3 (con un prefijo opcional) o el nombre de un grupo de registros de los Registros de CloudWatch. Si desea cifrar aún más los datos entre el cliente local y los nodos administrados, proporcione la clave de KMS para utilizarla para el cifrado. A continuación se muestra un ejemplo.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyLogGroupName",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "MyKMSKeyID",
"runAsEnabled": true,
"runAsDefaultUser": "MyDefaultRunAsUser",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "MyCommands",
"linux": "MyCommands"
}
}
}
```
**nota**
Si no desea cifrar los datos de registro de la sesión, cambie `true` por `false` en `s3EncryptionEnabled`.
Si no va a enviar registros a un bucket de Amazon S3 ni a un grupo de registros de los Registros de CloudWatch, si no desea cifrar los datos de sesión activa ni desea activar Ejecutar como soporte para las sesiones de su cuenta, puede eliminar las líneas de esas opciones. Asegúrese de que la última línea de la sección `inputs` no termine con una coma.
Si agrega un ID de clave de KMS para cifrar los datos de la sesión, tanto los usuarios que inician sesiones como los nodos administrados a los que se conectan deben tener permiso para utilizar la clave. Usted proporciona el permiso para utilizar la clave de KMS con Session Manager a través de las políticas de IAM. Para obtener información, consulte los siguientes temas:
Agregar permisos de AWS KMS para los usuarios de su cuenta: [Ejemplos de políticas de IAM para Session Manager](getting-started-restrict-access-quickstart.md)
Agregar permisos de AWS KMS para los nodos administrados de la cuenta: [Paso 2: verificación o agregación de permisos de instancia para Session Manager](session-manager-getting-started-instance-profile.md)
1. Guarde el archivo.
1. En el directorio en el que creó el archivo JSON, ejecute el siguiente comando.
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--name SSM-SessionManagerRunShell \
--content "file://SessionManagerRunShell.json" \
--document-type "Session" \
--document-format JSON
```
------
#### [ Windows ]
```
aws ssm create-document ^
--name SSM-SessionManagerRunShell ^
--content "file://SessionManagerRunShell.json" ^
--document-type "Session" ^
--document-format JSON
```
------
#### [ PowerShell ]
```
New-SSMDocument `
-Name "SSM-SessionManagerRunShell" `
-Content (Get-Content -Raw SessionManagerRunShell.json) `
-DocumentType "Session" `
-DocumentFormat JSON
```
------
Si se ejecuta correctamente, el comando devolverá información similar a la siguiente.
```
{
"DocumentDescription": {
"Status": "Creating",
"Hash": "ce4fd0a2ab9b0fae759004ba603174c3ec2231f21a81db8690a33eb66EXAMPLE",
"Name": "SSM-SessionManagerRunShell",
"Tags": [],
"DocumentType": "Session",
"PlatformTypes": [
"Windows",
"Linux"
],
"DocumentVersion": "1",
"HashType": "Sha256",
"CreatedDate": 1547750660.918,
"Owner": "111122223333",
"SchemaVersion": "1.0",
"DefaultVersion": "1",
"DocumentFormat": "JSON",
"LatestVersion": "1"
}
}
```
# Actualizar preferencias de Session Manager (línea de comandos)
El siguiente procedimiento describe cómo utilizar su herramienta de línea de comandos preferida para realizar cambios en las preferencias de AWS Systems Manager Session Manager para su Cuenta de AWS en la Región de AWS seleccionada. Use las preferencias de Session Manager para especificar opciones para registrar los datos de la sesión en un bucket de Amazon Simple Storage Service (Amazon S3) o en un grupo de registros de Amazon CloudWatch Logs. También puede utilizar las preferencias de Session Manager para cifrar los datos de la sesión.
**Para actualizar las preferencias de Session Manager (línea de comandos)**
1. Cree un archivo JSON en su equipo local con un nombre similar a `SessionManagerRunShell.json` y, a continuación, péguele el siguiente contenido.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "",
"runAsEnabled": true,
"runAsDefaultUser": "",
"idleSessionTimeout": "",
"maxSessionDuration": "",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
1. Especifique a dónde quiere enviar los datos de la sesión. Puede especificar el nombre de un bucket de S3 (con un prefijo opcional) o el nombre de un grupo de registros de los Registros de CloudWatch. Si desea cifrar aún más los datos entre el cliente local y los nodos administrados, proporcione la AWS KMS key para utilizarla para el cifrado. A continuación se muestra un ejemplo.
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "amzn-s3-demo-bucket",
"s3KeyPrefix": "MyS3Prefix",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "MyLogGroupName",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": false,
"kmsKeyId": "MyKMSKeyID",
"runAsEnabled": true,
"runAsDefaultUser": "MyDefaultRunAsUser",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "MyCommands",
"linux": "MyCommands"
}
}
}
```
**nota**
Si no desea cifrar los datos de registro de la sesión, cambie `true` por `false` en `s3EncryptionEnabled`.
Si no va a enviar registros a un bucket de Amazon S3 ni a un grupo de registros de los Registros de CloudWatch, si no desea cifrar los datos de sesión activa ni desea activar Ejecutar como soporte para las sesiones de su cuenta, puede eliminar las líneas de esas opciones. Asegúrese de que la última línea de la sección `inputs` no termine con una coma.
Si agrega un ID de clave de KMS para cifrar los datos de la sesión, tanto los usuarios que inician sesiones como los nodos administrados a los que se conectan deben tener permiso para utilizar la clave. Usted proporciona el permiso para utilizar la clave de KMS con Session Manager a través de las políticas de AWS Identity and Access Management (IAM). Para obtener información, consulte los siguientes temas:
Agregar permisos de AWS KMS para los usuarios de su cuenta: [Ejemplos de políticas de IAM para Session Manager](getting-started-restrict-access-quickstart.md).
Agregar permisos de AWS KMS para los nodos administrados de la cuenta: [Paso 2: verificación o agregación de permisos de instancia para Session Manager](session-manager-getting-started-instance-profile.md).
1. Guarde el archivo.
1. En el directorio en el que creó el archivo JSON, ejecute el siguiente comando.
------
#### [ Linux & macOS ]
```
aws ssm update-document \
--name "SSM-SessionManagerRunShell" \
--content "file://SessionManagerRunShell.json" \
--document-version "\$LATEST"
```
------
#### [ Windows ]
```
aws ssm update-document ^
--name "SSM-SessionManagerRunShell" ^
--content "file://SessionManagerRunShell.json" ^
--document-version "$LATEST"
```
------
#### [ PowerShell ]
```
Update-SSMDocument `
-Name "SSM-SessionManagerRunShell" `
-Content (Get-Content -Raw SessionManagerRunShell.json) `
-DocumentVersion '$LATEST'
```
------
Si se ejecuta correctamente, el comando devolverá información similar a la siguiente.
```
{
"DocumentDescription": {
"Status": "Updating",
"Hash": "ce4fd0a2ab9b0fae759004ba603174c3ec2231f21a81db8690a33eb66EXAMPLE",
"Name": "SSM-SessionManagerRunShell",
"Tags": [],
"DocumentType": "Session",
"PlatformTypes": [
"Windows",
"Linux"
],
"DocumentVersion": "2",
"HashType": "Sha256",
"CreatedDate": 1537206341.565,
"Owner": "111122223333",
"SchemaVersion": "1.0",
"DefaultVersion": "1",
"DocumentFormat": "JSON",
"LatestVersion": "2"
}
}
```
# Paso 5: (Opcional) Restringir el acceso a los comandos de una sesión
Puede restringir los comandos que un usuario puede ejecutar en una sesión de AWS Systems Manager Session Manager mediante un documento personalizado de tipo `Session` de AWS Systems Manager (SSM). En el documento, debe definir el comando que se ejecuta cuando el usuario inicia una sesión y los parámetros que el usuario puede proporcionar al comando. El valor del documento de `Session` `schemaVersion` debe ser 1.0 y su `sessionType` debe ser `InteractiveCommands`. Luego, puede crear políticas de AWS Identity and Access Management (IAM) que permitan a los usuarios acceder solo a los documentos de `Session` que usted defina. Para obtener más información acerca del uso de las políticas de IAM para restringir el acceso a los comandos de una sesión, consulte [Ejemplos de políticas de IAM para comandos interactivos](#interactive-command-policy-examples).
Los documentos con el `sessionType` de `InteractiveCommands` solo se admiten para sesiones iniciadas desde AWS Command Line Interface (AWS CLI). El usuario brinda el nombre del documento personalizado como valor del parámetro `--document-name` y proporciona cualquier valor de parámetro de comando mediante la opción `--parameters`. Para obtener más información sobre la ejecución de comandos interactivos, consulte [Inicio de una sesión (comandos interactivos y no interactivos)](session-manager-working-with-sessions-start.md#sessions-start-interactive-commands).
Utilice el siguiente procedimiento para crear un documento personalizado de SSM de tipo `Session` que defina el comando que el usuario tiene permitido ejecutar.
## Restringir el acceso a los comandos de una sesión (consola)
**Para restringir los comandos que un usuario puede ejecutar en una sesión de Session Manager (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 **Documentos**.
1. Elija **Create command or session (Crear comando o sesión)**.
1. En **Name** (Nombre), ingrese un nombre descriptivo para el documento.
1. En **Document type (Tipo de documento)**, elija **Session document (Documento Session)**.
1. Escriba el contenido del documento para definir el comando que un usuario puede ejecutar en una sesión de Session Manager utilizando JSON o YAML, tal y como se muestra en el siguiente ejemplo.
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
1. Elija **Create document** (Crear documento).
## Restringir el acceso a los comandos de una sesión (línea de comandos)
**Antes de empezar**
Si aún no lo ha hecho, instale y configure la AWS Command Line Interface (AWS CLI) o las Herramientas de AWS para PowerShell. Para obtener 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) e [Instalación de Herramientas de AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
**Para restringir los comandos que un usuario puede ejecutar en una sesión de Session Manager (línea de comandos)**
1. Cree un archivo JSON o YAML con el contenido del documento que defina el comando que un usuario puede ejecutar en una sesión de Session Manager, tal y como se muestra en el siguiente ejemplo.
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
1. Ejecute los siguientes comandos para crear un documento de SSM en el que se defina el comando que el usuario puede ejecutar en una sesión de Session Manager.
------
#### [ Linux & macOS ]
```
aws ssm create-document \
--content file://path/to/file/documentContent.json \
--name "exampleAllowedSessionDocument" \
--document-type "Session"
```
------
#### [ Windows ]
```
aws ssm create-document ^
--content file://C:\path\to\file\documentContent.json ^
--name "exampleAllowedSessionDocument" ^
--document-type "Session"
```
------
#### [ PowerShell ]
```
$json = Get-Content -Path "C:\path\to\file\documentContent.json" | Out-String
New-SSMDocument `
-Content $json `
-Name "exampleAllowedSessionDocument" `
-DocumentType "Session"
```
------
## Parámetros de comandos interactivos y la AWS CLI
Hay una variedad de formas en las que puede proporcionar parámetros de comandos interactivos cuando utiliza la AWS CLI. Según el sistema operativo (SO) del equipo cliente que utilice para conectarse a nodos administrados con la AWS CLI, la sintaxis que proporcione para los comandos que contengan caracteres especiales o de escape puede diferir. En los siguientes ejemplos, se muestran algunas de las diferentes formas de proporcionar parámetros de comando cuando se utiliza la AWS CLI y cómo manejar los caracteres especiales o de escape.
Los parámetros almacenados en Parameter Store se pueden referenciar en la AWS CLI para obtener los parámetros de comandos, como se muestra en el siguiente ejemplo.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["{{ssm:mycommand}}"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["{{ssm:mycommand}}"]}'
```
------
En el siguiente ejemplo, se muestra cómo puede utilizar una sintaxis abreviada con la AWS CLI para pasar parámetros.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters command="ifconfig"
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters command="ipconfig"
```
------
También puede proporcionar parámetros en JSON, tal como se muestra en el siguiente ejemplo.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["ifconfig"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["ipconfig"]}'
```
------
Los parámetros también se pueden almacenar en un archivo JSON y proporcionarse a la AWS CLI, como se muestra en el siguiente ejemplo. Para obtener más información acerca del uso de los parámetros de la AWS CLI desde un archivo, consulte [Carga de los parámetros de la AWS CLI desde un archivo](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-file.html) en la *Guía del usuario de la AWS Command Line Interface*.
```
{
"command": [
"my command"
]
}
```
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters file://complete/path/to/file/parameters.json
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters file://complete/path/to/file/parameters.json
```
------
También puede generar un esqueleto de la AWS CLI desde un archivo JSON de entrada, tal como se muestra en el siguiente ejemplo. Para obtener más información acerca de la generación de esqueletos de la AWS CLI desde archivos JSON de entrada, consulte [Generación del esqueleto de la AWS CLI y de los parámetros de entrada desde un archivo de entrada JSON o YAML](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-skeleton.html) en la *Guía del usuario de la AWS Command Line Interface*.
```
{
"Target": "instance-id",
"DocumentName": "MyInteractiveCommandDocument",
"Parameters": {
"command": [
"my command"
]
}
}
```
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--cli-input-json file://complete/path/to/file/parameters.json
```
------
#### [ Windows ]
```
aws ssm start-session ^
--cli-input-json file://complete/path/to/file/parameters.json
```
------
Para los caracteres de escape que se encuentran entre comillas, debe agregar barras inversas adicionales a los caracteres de escape, como se muestra en el siguiente ejemplo.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name MyInteractiveCommandDocument \
--parameters '{"command":["printf \"abc\\\\tdef\""]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name MyInteractiveCommandDocument ^
--parameters '{"command":["printf \"abc\\\\tdef\""]}'
```
------
Para obtener más información acerca de cómo utilizar comillas con parámetros de comando en la AWS CLI, consulte [Uso de comillas con cadenas en la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-quoting-strings.html) en la *Guía del usuario de la AWS Command Line Interface*.
## Ejemplos de políticas de IAM para comandos interactivos
Puede crear políticas de IAM que permitan a los usuarios acceder solo a los documentos de `Session` que usted defina. De este modo, restringirá los comandos que puede ejecutar un usuario en una sesión de Session Manager a solo aquellos comandos que estén especificados en los documentos personalizados de tipo `Session` de SSM.
**Permitir que un usuario ejecute un comando interactivo en un solo nodo administrado**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/i-02573cafcfEXAMPLE",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
**Permitir que un usuario ejecute un comando interactivo en todos los nodos administrados**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/*",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
**Permitir que un usuario ejecute varios comandos interactivos en todos los nodos administrados**
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":"ssm:StartSession",
"Resource":[
"arn:aws:ec2:us-east-1:444455556666:instance/*",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document",
"arn:aws:ssm:us-east-1:444455556666:document/allowed-session-document-2"
]
},
{
"Effect": "Allow",
"Action": ["ssmmessages:OpenDataChannel"],
"Resource": ["arn:aws:ssm:*:*:session/${aws:userid}-*"]
}
]
}
```
# Paso 6: (Opcional) Utilizar AWS PrivateLink para configurar un punto de enlace de la VPC para Session Manager
Puede mejorar aún más la posición de seguridad de los nodos administrados configurando AWS Systems Manager para que use un punto de conexión de la nube virtual privada (VPC) de interfaz. Los puntos de enlace de interfaz tienen la tecnología de AWS PrivateLink que le permite acceder de forma privada a las API de Amazon Elastic Compute Cloud (Amazon EC2) y Systems Manager mediante el uso de direcciones IP privadas.
AWS PrivateLink restringe todo el tráfico de red entre los nodos administrados, Systems Manager y Amazon EC2 a la red de Amazon. (Los nodos administrados no tienen acceso a Internet). Asimismo, no necesita una gateway de Internet ni un dispositivo NAT ni una gateway privada virtual.
Para obtener información sobre cómo crear un punto de conexión de VPC, consulte [Mejora de la seguridad de las instancias de EC2 mediante puntos de conexión de VPC para Systems Manager](setup-create-vpc.md).
La alternativa a usar un punto de conexión de VPC es permitir el acceso a Internet saliente en los nodos administrados. En este caso, los nodos administrados también deben permitir el tráfico saliente HTTPS (puerto 443) a los siguientes puntos de conexión:
+ `ec2messages.region.amazonaws.com`
+ `ssm.region.amazonaws.com`
+ `ssmmessages.region.amazonaws.com`
Systems Manager utiliza el último de estos puntos de enlace, `ssmmessages.region.amazonaws.com`, para realizar llamadas desde SSM Agent hacia el servicio Session Manager en la nube.
Para utilizar características opcionales como cifrado de AWS Key Management Service (AWS KMS), streaming de registros a Amazon CloudWatch Logs (CloudWatch Logs) y envío de registros a Amazon Simple Storage Service (Amazon S3), debe permitir el tráfico saliente HTTPS (puerto 443) a los siguientes puntos de conexión:
+ `kms.region.amazonaws.com`
+ `logs.region.amazonaws.com`
+ `s3.region.amazonaws.com`
Para obtener más información acerca de los puntos de enlace requeridos para Systems Manager, consulte [Referencia: ec2messages, ssmmessages y otras operaciones de la API](systems-manager-setting-up-messageAPIs.md).
# Paso 7: (Opcional) Activar o desactivar los permisos administrativos de la cuenta ssm-user
A partir de la versión 2.3.50.0 de AWS Systems Manager SSM Agent, el agente crea una cuenta de usuario local llamada `ssm-user` y la agrega a `/etc/sudoers` (Linux y macOS) o al grupo de administradores (Windows). En las versiones anteriores a la 2.3.612.0 del agente, la cuenta se crea la primera vez que SSM Agent se inicia o reinicia después de la instalación. En la versión 2.3.612.0 y posteriores, la cuenta `ssm-user` se crea la primera vez que se inicia una sesión en un nodo. Este `ssm-user` es el usuario predeterminado del sistema operativo (SO) cuando se inicia una sesión de AWS Systems Manager Session Manager. La versión 2.3.612.0 de SSM Agent se lanzó el 8 de mayo de 2019.
Si desea impedir que los usuarios de Session Manager ejecuten comandos administrativos en un nodo, puede actualizar los permisos de las cuentas `ssm-user`. También puede restaurar estos permisos después de que se hayan eliminado.
**Topics**
+ [Administración de permisos de cuentas ssm-user sudo en Linux y macOS](#ssm-user-permissions-linux)
+ [Administración de los permisos de las cuentas de administrador ssm-user en Windows Server](#ssm-user-permissions-windows)
## Administración de permisos de cuentas ssm-user sudo en Linux y macOS
Utilice uno de los siguientes procedimientos para activar o desactivar los permisos sudo de las cuentas ssm-user en nodos administrados de Linux y macOS.
**Use Run Command para modificar permisos sudo de ssm-user (consola)**
+ Utilice el procedimiento en [Ejecución de comandos desde la consola](running-commands-console.md) con los siguientes valores:
+ En **Command document (Documento Command)**, elija `AWS-RunShellScript`.
+ Para eliminar el acceso sudo, en el área **Command parameters** (Parámetros de comandos), pegue lo siguiente en el cuadro **Commands** (Comandos).
```
cd /etc/sudoers.d
echo "#User rules for ssm-user" > ssm-agent-users
```
-o bien-
Para restaurar el acceso sudo, en el área **Command parameters** (Parámetros de comandos), pegue lo siguiente en el cuadro **Commands** (Comandos).
```
cd /etc/sudoers.d
echo "ssm-user ALL=(ALL) NOPASSWD:ALL" > ssm-agent-users
```
**Uso de la línea de comandos para modificar permisos sudo de ssm-user (AWS CLI)**
1. Conéctese al nodo administrado y ejecute el siguiente comando.
```
sudo -s
```
1. Cambie el directorio de trabajo con el siguiente comando.
```
cd /etc/sudoers.d
```
1. Abra el archivo con el nombre `ssm-agent-users` para editarlo.
1. Para eliminar el acceso sudo, elimine la siguiente línea.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
-o bien-
Para restaurar el acceso sudo, agregue la siguiente línea.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
1. Guarde el archivo.
## Administración de los permisos de las cuentas de administrador ssm-user en Windows Server
Utilice uno de los siguientes procedimientos para activar o desactivar los permisos de administrador de las cuentas ssm-user en los nodos administrados de Windows Server.
**Uso de Run Command para modificar los permisos de administrador (consola)**
+ Utilice el procedimiento en [Ejecución de comandos desde la consola](running-commands-console.md) con los siguientes valores:
En **Command document (Documento Command)**, elija `AWS-RunPowerShellScript`.
Para eliminar el acceso administrativo, en el área **Command parameters** (Parámetros de comandos), pegue lo siguiente en el cuadro **Commands** (Comandos).
```
net localgroup "Administrators" "ssm-user" /delete
```
-o bien-
Para restaurar el acceso administrativo, en el área **Command parameters** (Parámetros de comandos), pegue lo siguiente en el cuadro **Commands** (Comandos).
```
net localgroup "Administrators" "ssm-user" /add
```
**Uso de la ventana de PowerShell o del símbolo del sistema para modificar los permisos de administrador**
1. Conéctese al nodo administrado y abra la ventana de PowerShell o del símbolo del sistema.
1. Para eliminar el acceso administrativo, ejecute el siguiente comando.
```
net localgroup "Administrators" "ssm-user" /delete
```
-o bien-
Para restaurar el acceso administrativo, ejecute el siguiente comando.
```
net localgroup "Administrators" "ssm-user" /add
```
**Uso de la consola de Windows para modificar los permisos de administrador**
1. Conéctese al nodo administrado y abra la ventana de PowerShell o del símbolo del sistema.
1. En la línea de comandos, ejecute `lusrmgr.msc` para abrir la consola **Local Users and Groups (Grupos y usuarios locales)**.
1. Abra el directorio **Usuarios** y, a continuación, **ssm-user**.
1. En la pestaña **Member Of (Miembro de)**, realice una de las siguientes acciones:
+ Para eliminar el acceso administrativo, seleccione **Administradores** y, a continuación, seleccione **Quitar**.
-o bien-
Para restaurar el acceso administrativo, ingrese **Administrators** en el cuadro de texto y, a continuación, elija **Add** (Agregar).
1. Seleccione **Aceptar**.
# Paso 8: (Opcional) Permitir y controlar permisos para conexiones de SSH mediante Session Manager
Puede permitir que los usuarios de la Cuenta de AWS utilicen la AWS Command Line Interface (AWS CLI) para establecer conexiones de Secure Shell (SSH) a los nodos administrados usando AWS Systems Manager Session Manager. Los usuarios que se conectan usando SSH también pueden copiar archivos entre sus máquinas locales y nodos administrados usando el protocolo de copia segura (SCP). Puede usar esta funcionalidad para conectarse a nodos administrados sin abrir puertos de entrada o mantener hosts de bastión.
Cuando establece conexiones SSH a través deSession Manager, AWS CLI y SSM Agent crean conexiones WebSocket seguras a través de TLS a los puntos de conexión de Session Manager. La sesión SSH se ejecuta dentro de este túnel cifrado, lo que proporciona una capa adicional de seguridad sin necesidad de abrir los puertos de entrada en los nodos administrados.
Después de permitir las conexiones de SSH, puede utilizar las políticas de AWS Identity and Access Management (IAM) a fin de permitir o denegar explícitamente las conexiones de SSH mediante Session Manager a usuarios, grupos o roles.
**nota**
El registro no está disponible para las sesiones de Session Manager que se conectan a través del reenvío de puertos o de SSH. Esto se debe a que SSH cifra todos los datos de la sesión dentro de la conexión TLS segura establecida entre los puntos de conexión AWS CLI y Session Manager, y Session Manager solo funciona como túnel para las conexiones de SSH.
**Topics**
+ [Permitir las conexiones de SSH para Session Manager](#ssh-connections-enable)
+ [Control de los permisos de usuario para las conexiones de SSH mediante Session Manager](#ssh-connections-permissions)
## Permitir las conexiones de SSH para Session Manager
Siga los siguientes pasos para permitir las conexiones de SSH mediante Session Manager en un nodo administrado.
**Para permitir las conexiones de SSH para Session Manager**
1. En el nodo administrado en el que desea permitir las conexiones de SSH, realice el siguiente procedimiento:
+ Asegúrese de que se está ejecutando SSH en el nodo administrado. (Puede cerrar los puertos de entrada del nodo).
+ Asegúrese de la versión 2.3.672.0 de SSM Agent o una versión posterior esté instalada en el nodo administrado.
Para obtener información sobre cómo instalar o actualizar el SSM Agent en un nodo administrado, consulte los siguientes temas:
+ [Cómo instalar y desinstalar de forma manual SSM Agent en instancias de EC2 para Windows Server](manually-install-ssm-agent-windows.md).
+ [Instalación y desinstalación manual de SSM Agent en instancias de EC2 para Linux](manually-install-ssm-agent-linux.md)
+ [Instalación y desinstalación manual de SSM Agent en instancias de EC2 para macOS](manually-install-ssm-agent-macos.md)
+ [Cómo instalar SSM Agent en nodos de Windows híbridos](hybrid-multicloud-ssm-agent-install-windows.md)
+ [Cómo instalar SSM Agent en nodos de Linux híbridos](hybrid-multicloud-ssm-agent-install-linux.md)
**nota**
Para utilizar Session Manager con servidores en las instalaciones, dispositivos periféricos y máquinas virtuales (VM) que activó como nodos administrados, debe utilizar el nivel de instancias avanzadas. Para obtener más información acerca de las instancias avanzadas, consulte [Configuración de los niveles de instancias](fleet-manager-configure-instance-tiers.md).
1. En la máquina local desde la que desea conectarse a un nodo administrado utilizando SSH, haga lo siguiente:
+ Asegúrese de que la versión 1.1.23.0 o posterior del complemento Session Manager está instalada.
Para obtener más información sobre la Session Manager instalación del plugin, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md).
+ Actualice el archivo de configuración de SSH para permitir la ejecución de un comando de proxy que inicie una sesión de Session Manager y transfiera todos los datos a través de la conexión.
**Linux y macOS**
**sugerencia**
El archivo de configuración de SSH suele estar en `~/.ssh/config`.
Agregue lo siguiente al archivo de configuración en el equipo local.
```
# SSH over Session Manager
Host i-* mi-*
ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
User ec2-user
```
** Windows **
**sugerencia**
El archivo de configuración de SSH suele estar en `C:\Users\\.ssh\config`.
Agregue lo siguiente al archivo de configuración en el equipo local.
```
# SSH over Session Manager
Host i-* mi-*
ProxyCommand C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p"
```
+ Cree o verifique que tiene un certificado Privacy Enhanced Mail (un archivo PEM) o, al menos, una clave pública, que se utilizará a la hora de establecer conexiones a los nodos administrados. Debe ser una clave que ya esté asociada al nodo administrado. Se deben configurar los permisos del archivo de clave privada para que solo usted pueda leerlo. Puede utilizar el siguiente comando para configurar los permisos del archivo de clave privada para que solo usted pueda leerlo.
```
chmod 400 .pem
```
Por ejemplo, para una instancia de Amazon Elastic Compute Cloud (Amazon EC2), el archivo de par de claves que creó o seleccionó cuando creó la instancia. (Debe especificar la ruta al certificado o a la clave como parte del comando para iniciar una sesión. Para obtener más información acerca de cómo iniciar una sesión mediante SSH, consulte ). [Inicio de una sesión (SSH)](session-manager-working-with-sessions-start.md#sessions-start-ssh).)
## Control de los permisos de usuario para las conexiones de SSH mediante Session Manager
Después de habilitar las conexiones de SSH mediante Session Manager en un nodo administrado, puede utilizar las políticas de IAM para permitir o denegar la capacidad de establecer conexiones de SSH a usuarios, grupos o roles a través de Session Manager.
**Uso de políticas de IAM para permitir las conexiones de SSH a través de Session Manager**
+ Utilice una de las siguientes opciones:
+ **Opción 1**: abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
En el panel de navegación, elija **Policies (Políticas)** y actualice la política de permisos del usuario o rol al que desea permitir que inicie conexiones SSH a través de Session Manager.
Por ejemplo, agregue el siguiente elemento a la política de inicio rápido que creó en . [Políticas de usuarios finales de inicio rápido de Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user). Reemplace cada *example resource placeholder* por su propia información.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ec2:us-east-1:111122223333:instance/instance-id",
"arn:aws:ssm:*:*:document/AWS-StartSSHSession"
]
},
{
"Effect": "Allow",
"Action": "ssmmessages:OpenDataChannel",
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
}
]
}
```
------
+ **Opción 2**: adjunte una política insertada a una política de usuario mediante la Consola de administración de AWS, la AWS CLI o la API de AWS.
Uso del método que elija para adjuntar la declaración de política en la **Opción 1** a la política para un usuario, grupo o rol de AWS.
Para obtener información, consulte [Agregagado y eliminación de permisos de identidad de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) en la *Guía del usuario de IAM*.
**Uso de una política de IAM para denegar las conexiones de SSH mediante Session Manager**
+ Utilice una de las siguientes opciones:
+ **Opción 1**: abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). En el panel de navegación, elija **Policies (Políticas)**, y, a continuación, actualice la política de permisos de forma que el usuario o el rol no puedan iniciar sesiones de Session Manager.
Por ejemplo, agregue el siguiente elemento a la política de inicio rápido que creó en [Políticas de usuarios finales de inicio rápido de Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ssm:StartSession",
"Resource": "arn:aws:ssm:*:*:document/AWS-StartSSHSession"
},
{
"Effect": "Allow",
"Action": "ssmmessages:OpenDataChannel",
"Resource": "arn:aws:ssm:*:*:session/${aws:userid}-*"
}
]
}
```
------
+ **Opción 2**: adjunte una política insertada a una política de usuario mediante la Consola de administración de AWS, la AWS CLI o la API de AWS.
Uso del método que elija para adjuntar la declaración de política en la **Opción 1** a la política para un usuario, grupo o rol de AWS.
Para obtener información, consulte [Agregagado y eliminación de permisos de identidad de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) en la *Guía del usuario de IAM*.
# Uso de Session Manager
Puede utilizar la consola de AWS Systems Manager, la consola de Amazon Elastic Compute Cloud (Amazon EC2) o la AWS Command Line Interface (AWS CLI) para iniciar sesiones que lo conecten a los nodos administrados a los que el administrador del sistema le ha otorgado acceso mediante políticas de AWS Identity and Access Management (IAM). En función de sus permisos, también puede ver información sobre las sesiones, reanudar las sesiones inactivas cuyo tiempo de espera no haya finalizado y terminar las sesiones. Una vez que se establece una sesión, no se ve afectada por la duración de la sesión del rol de IAM. Para obtener información acerca de cómo limitar la duración de la sesión con Session Manager, consulte [Especificación de un valor de tiempo de espera de sesión inactiva](session-preferences-timeout.md) y [Especificar la duración máxima de la sesión](session-preferences-max-timeout.md).
Para obtener más información acerca de las sesiones, consulte [¿Qué es una sesión?](session-manager.md#what-is-a-session).
**Topics**
+ [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md)
+ [Inicio de una sesión](session-manager-working-with-sessions-start.md)
+ [Finalización de una sesión](session-manager-working-with-sessions-end.md)
+ [Visualización del historial de sesiones](session-manager-working-with-view-history.md)
# Instalación del complemento de Session Manager para la AWS CLI
Para iniciar sesiones de Session Manager con los nodos administrados mediante AWS Command Line Interface (AWS CLI), debe instalar el *complemento de Session Manager* en su equipo local. Puede instalar el complemento en versiones compatibles de Microsoft Windows Server, macOS, Linux y Ubuntu Server.
**nota**
La versión 1.16.12 o una posterior de la AWS CLI debe estar instalada en su equipo local para poder utilizar el complemento de Session Manager. Para obtener más información, consulte [Instalación o actualización de la versión de AWS Command Line Interface más reciente](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Topics**
+ [Session ManagerÚltima versión del complemento de e historial de versiones](plugin-version-history.md)
+ [Instalación del complemento de Session Manager en Windows](install-plugin-windows.md)
+ [Instalación del complemento de Session Manager en macOS](install-plugin-macos-overview.md)
+ [Cómo instalar el complemento de Session Manager en Linux](install-plugin-linux-overview.md)
+ [Verificación de la instalación del complemento de Session Manager](install-plugin-verify.md)
+ [El complemento Session Manager en GitHub](plugin-github.md)
+ [(Opcional) Activación del registro del complemento de Session Manager](install-plugin-configure-logs.md)
# Session ManagerÚltima versión del complemento de e historial de versiones
El equipo local debe ejecutar una versión compatible del complemento de Session Manager. En la actualidad, la versión más antigua compatible es la 1.1.17.0. Si ejecuta una versión anterior, es posible que las operaciones de Session Manager no se efectúen de manera correcta.
Para ver si tiene la versión más reciente, ejecute el siguiente comando en la AWS CLI.
**nota**
El comando devuelve los resultados únicamente si el complemento se encuentra en el directorio de instalación predeterminado de su sistema operativo. También puede comprobar la versión en el contenido del archivo `VERSION` en el directorio en el que ha instalado el complemento.
```
session-manager-plugin --version
```
En la siguiente tabla se muestran todas las versiones del complemento de Session Manager, así como las características y las mejoras incluidas en cada versión.
**importante**
Le recomendamos que utilice siempre la versión más reciente. La versión más reciente incluye mejoras que mejoran la experiencia de uso del complemento.
| Versión | Fecha de lanzamiento | Details |
| --- | --- | --- |
| 1.2.792.0 | 17 de marzo de 2026 | **Corrección de errores**: se ha añadido soporte de teclado internacional para Windows. |
| 1.2.779.0 | 12 de febrero de 2026 | **Mejora**: Se actualizó la versión Go a la 1.25 en Dockerfile. **Corrección de error**: Se agregaron líneas shebang a los scripts de paquetes de Debian. |
| 1.2.764.0 | 19 de noviembre de 2025 | **Mejora**: se ha agregado soporte para la firma de solicitudes de OpenDataChannel. **Corrección de errores**: se corrigen los problemas de checkstyle para la compatibilidad con la versión más reciente de Go. |
| 1.2.707.0 | 6 de febrero de 2025 | **Mejora**: se actualizó la versión Go a la 1.23 en el Dockerfile. Se actualizó el paso de configuración de la versión en el archivo README. |
| 1.2.694.0 | 20 de noviembre de 2024 | **Corrección de error**: se anuló el cambio que agregaba credenciales a las solicitudes de OpenDataChannel. |
| 1.2.688.0 | 6 de noviembre de 2024 | **Esta versión quedó obsoleta el 20/11/2024.** **Mejoras**:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/plugin-version-history.html) |
| 1.2.677.0 | 10 de octubre de 2024 | **Mejora**: se ha agregado compatibilidad para pasar la versión del complemento con las solicitudes de OpenDataChannel. |
| 1.2.650.0 | 2 de julio de 2024 | **Mejora**: se actualizó aws-sdk-go a la versión 1.54.10.**Corrección de errores**: se han reformulado los comentarios para la verificación de gofmt. |
| 1.2.633.0 | 30 de mayo de 2024 | Mejora: Se ha actualizado el Dockerfile para que utilice una imagen de Amazon Elastic Container Registry (Amazon ECR). |
| 1.2.553.0 | 10 de enero de 2024 | Mejora: se actualizaron aws-sdk-go y los paquetes dependientes de Golang. |
| 1.2.536.0 | 4 de diciembre de 2023 | Mejora: se agregó soporte para pasar una respuesta de la API [StartSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html) como variable de entorno al complemento Session Manager. |
| 1.2.497.0 | 1 de agosto de 2023 | Mejora: se actualizó el Go SDK a la versión 1.44.302. |
| 1.2.463.0 | 15 de marzo de 2023 | Mejora: se agregó la compatibilidad con Mac with Apple silicon para Apple Mac (M1) en el instalador agregado y firmado de macOS. |
| 1.2.398.0 | 14 de octubre de 2022 | Mejora: es compatible con la versión 1.17 de Golang. Actualice el ejecutor de complementos del administrador de sesiones predeterminado para macOS si desea usar python3. Actualice la ruta de importación de SSMCLI al complemento del administrador de sesiones. |
| 1.2.339.0 | 16 de junio de 2022 | Corrección de error: corrección del tiempo de espera de sesión inactiva para las sesiones de puertos. |
| 1.2.331.0 | 27 de mayo de 2022 | Corrección de error: corrección del cierre prematuro de las sesiones de puertos cuando el servidor local no se conecta antes de que se agote el tiempo de espera. |
| 1.2.323.0 | 19 de mayo de 2022 | Corrección de error: desactivación de mantenimiento de conexión de smux para utilizar la función de tiempo de espera de sesión inactiva. |
| 1.2.312.0 | 31 de marzo de 2022 | Mejora: admite más tipos de carga de mensajes de salida. |
| 1.2.295.0 | 12 de enero de 2022 | Solución de errores: sesiones que dejan de responder porque el cliente reenvía datos de flujo cuando el agente queda inactivo y registros incorrectos para mensajes de start\$1publication y pause\$1publication. |
| 1.2.279.0 | 27 de octubre de 2021 | Mejora: empaquetado zip para la plataforma Windows. |
| 1.2.245.0 | 19 de agosto de 2021 | Mejora: Actualice aws-sdk-go a la versión más reciente (v1.40.17) para admitir el AWS IAM Identity Center. |
| 1.2.234.0 | 26 de julio de 2021 | Corrección de errores: gestione el escenario de sesión abruptamente terminada en el tipo de sesión interactiva. |
| 1.2.205.0 | 10 de junio de 2021 | Mejora: se agregó compatibilidad con el instalador firmado de macOS. |
| 1.2.54.0 | 29 de enero de 2021 | Mejora: se agregó compatibilidad con la ejecución de sesiones en modo de ejecución NonInteractiveCommands. |
| 1.2.30.0 | 24 de noviembre de 2020 | **Mejora**: se mejoró el rendimiento general (solo en las sesiones de reenvío de puertos). |
| 1.2.7.0 | 15 de octubre de 2020 | **Mejora**: se redujo la latencia y se mejoró el rendimiento general (solo en las sesiones de reenvío de puertos). |
| 1.1.61.0 | 17 de abril de 2020 | **Mejora**: ahora ARM es compatible con Linux y Ubuntu Server. |
| 1.1.54.0 | 6 de enero de 2020 | **Corrección de errores**: gestione el escenario de condición de carrera de paquetes que se descartan cuando el complemento de Session Manager no está listo. |
| 1.1.50.0 | 19 de noviembre de 2019 | **Mejora**: se ha añadido soporte para reenviar un puerto a un socket Unix local. |
| 1.1.35.0 | 7 de noviembre de 2019 | **Mejora**: (Solo sesiones de reenvío de puertos) Enviar un comando TerminateSession a SSM Agent cuando el usuario local presione `Ctrl+C`. |
| 1.1.33.0 | 26 de septiembre de 2019 | Mejora: (solo sesiones de reenvío de puertos) Envíe una señal de desconexión al servidor cuando el cliente interrumpa la conexión TCP. |
| 1.1.31.0 | 6 de septiembre de 2019 | Mejora: actualización para mantener abierta la sesión de enrutamiento de puertos hasta que el servidor remoto cierre la conexión. |
| 1.1.26.0 | 30 de julio de 2019 | **Mejora**: actualización para limitar la velocidad de transferencia de datos durante una sesión. |
| 1.1.23.0 | 9 de julio de 2019 | **Mejora**: se agregó compatibilidad con la ejecución de sesiones de SSH mediante Session Manager. |
| 1.1.17.0 | 4 de abril de 2019 | **Mejora**: se ha añadido soporte para cifrar aún más los datos de la sesión utilizando AWS Key Management Service (AWS KMS). |
| 1.0.37.0 | 20 de septiembre de 2018 | **Mejora**: corrección de errores para la versión de Windows. |
| 1.0.0.0 | 11 de septiembre de 2018 | Versión inicial del complemento de Session Manager. |
# Instalación del complemento de Session Manager en Windows
Puede instalar el complemento de Session Manager en Windows Vista o una versión posterior con el instalador independiente.
Cuando se hayan publicado las actualizaciones, deberá repetir el proceso de instalación para obtener la versión más reciente del complemento de Session Manager.
**nota**
Observe la siguiente información.
El instalador del complemento de Session Manager necesita derechos de administrador para instalar el complemento.
Para obtener mejores resultados, le recomendamos iniciar las sesiones en los clientes de Windows utilizando Windows PowerShell , versión 5 o una posterior. También puede utilizar el intérprete de comandos en Windows 10. El complemento de Session Manager solo es compatible con PowerShell y el intérprete de comandos. Es posible que las herramientas de línea de comandos de terceros no sean compatibles con el complemento.
**Para instalar el complemento de Session Manager con el instalador EXE**
1. Descargue el instalador mediante la siguiente dirección URL.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPluginSetup.exe
```
También puede descargar una versión comprimida del instalador utilizando la siguiente URL.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPlugin.zip
```
1. Ejecute el instalador descargado y siga las instrucciones que aparecen en la pantalla. Si descargó la versión comprimida del instalador, primero debe descomprimir el instalador.
Deje el cuadro de ubicación de la instalación en blanco para instalar el complemento en el directorio predeterminado.
+ `%PROGRAMFILES%\Amazon\SessionManagerPlugin\bin\`
1. Compruebe que la instalación se ha realizado correctamente. Para obtener más información, consulte [Verificación de la instalación del complemento de Session Manager](install-plugin-verify.md).
**nota**
Si Windows no puede encontrar el ejecutable, es posible que tenga que volver a abrir el símbolo del sistema o añadir el directorio de instalación a su variable de entorno `PATH` manualmente. Para obtener información, consulte el tema sobre solución de problemas [Complemento de Session Manager no agregado de manera automática a la ruta de la línea de comandos (Windows)](session-manager-troubleshooting.md#windows-plugin-env-var-not-set).
# Instalación del complemento de Session Manager en macOS
Elija uno de los siguientes temas para instalar el complemento de Session Manager en macOS.
**nota**
El instalador firmado es un archivo `.pkg` firmado. El instalador agrupado utiliza un archivo `.zip`. Después de descomprimir el archivo, puede utilizar el binario para instalar el complemento.
## Instalación del complemento de Session Manager en macOS con el instalador firmado
En esta sección se describe cómo instalar el complemento de Session Manager en macOS con el instalador firmado.
**Para instalar el complemento de Session Manager con el instalador firmado (macOS)**
1. Descargue el instalador firmado.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
#### [ Mac con silicona de Apple ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
1. Ejecute los comandos de instalación. Si el comando falla, verifique que la carpeta `/usr/local/bin` exista. Si no es así, créela y vuelva a ejecutar el comando.
```
sudo installer -pkg session-manager-plugin.pkg -target /
sudo ln -s /usr/local/sessionmanagerplugin/bin/session-manager-plugin /usr/local/bin/session-manager-plugin
```
1. Compruebe que la instalación se ha realizado correctamente. Para obtener más información, consulte [Verificación de la instalación del complemento de Session Manager](install-plugin-verify.md).
## Instalación del complemento de Session Manager en macOS
En esta sección se describe cómo instalar el complemento de Session Manager en macOS con el instalador incluido.
**importante**
Tenga en cuenta la siguiente información importante.
De forma predeterminada, el instalador requiere acceso sudo para ejecutarse, ya que el script instala el complemento en el directorio del sistema `/usr/local/sessionmanagerplugin`. Si no quiere instalar el complemento mediante sudo, actualice manualmente el script del instalador para instalar el complemento en un directorio que no requiera acceso sudo.
El instalador empaquetado no admite la instalación en rutas que contienen espacios.
**Para instalar el complemento de Session Manager con el instalador empaquetado (macOS)**
1. Descargue el instalador empaquetado.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
#### [ Mac con silicona de Apple ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
1. Descomprima el paquete.
```
unzip sessionmanager-bundle.zip
```
1. Ejecute el comando de instalación.
```
sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
**nota**
El complemento requiere Python 3.10 o una versión posterior. El script de instalación se ejecuta en la versión de Python predeterminada del sistema. Si tiene instalada una versión alternativa de Python y desea utilizarla para instalar el complemento de Session Manager, ejecute el script de instalación de esa versión mediante una ruta absoluta al ejecutable de Python. A continuación se muestra un ejemplo.
```
sudo /usr/local/bin/python3.11 sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
El instalador instala el complemento de Session Manager en `/usr/local/sessionmanagerplugin` y crea el symlink `session-manager-plugin` en el directorio `/usr/local/bin`. De este modo, no es necesario especificar el directorio de instalación en la variable `$PATH` del usuario.
Para ver una explicación de las opciones `-i` y `-b`, use la opción `-h`.
```
./sessionmanager-bundle/install -h
```
1. Compruebe que la instalación se ha realizado correctamente. Para obtener más información, consulte [Verificación de la instalación del complemento de Session Manager](install-plugin-verify.md).
**nota**
Para desinstalar el complemento, ejecute los dos siguientes comandos en el orden que aparecen.
```
sudo rm -rf /usr/local/sessionmanagerplugin
```
```
sudo rm /usr/local/bin/session-manager-plugin
```
# Cómo instalar el complemento de Session Manager en Linux
En esta sección, se incluye información sobre la verificación de la firma del paquete del instalador del complemento de Session Manager y la instalación del complemento en las siguientes distribuciones de Linux:
+ Amazon Linux 2
+ AL2023
+ RHEL
+ Debian Server
+ Ubuntu Server
**Topics**
+ [Verificación de la firma del complemento de Session Manager](install-plugin-linux-verify-signature.md)
+ [Instalar el complemento Session Manager en Amazon Linux 2, Amazon Linux 2023 y las distribuciones de Red Hat Enterprise Linux](install-plugin-linux.md)
+ [Instale el complemento Session Manager en Debian Server y Ubuntu Server](install-plugin-debian-and-ubuntu.md)
# Verificación de la firma del complemento de Session Manager
Los paquetes de instaladores RPM y Debian del complemento de Session Manager para instancias de Linux están firmados criptográficamente. Puede usar la clave pública para verificar que el binario y el paquete del complemento sean originales y que no se hayan modificado. Si hay algún tipo de daño o alteración en el archivo, se produce un error en la verificación. Puede verificar la firma del paquete del instalador mediante la herramienta GNU Privacy Guard (GPG). La siguiente información es para las versiones del complemento de Session Manager 1.2.707.0 o posteriores.
Complete los siguientes pasos para verificar la firma del paquete del instalador del complemento de Session Manager.
**Topics**
+ [Paso 1: descargue el paquete del instalador del complemento de Session Manager](#install-plugin-linux-verify-signature-installer-packages)
+ [Paso 2: descargue el archivo de firma asociado](#install-plugin-linux-verify-signature-packages)
+ [Paso 3: instale la herramienta GPG](#install-plugin-linux-verify-signature-packages-gpg)
+ [Paso 4: verifique el paquete del instalador del complemento de Session Manager en un servidor Linux](#install-plugin-linux-verify-signature-packages)
## Paso 1: descargue el paquete del instalador del complemento de Session Manager
Descargue el paquete del instalador del complemento de Session Manager que quiere verificar.
**Amazon Linux 2, AL2023 y los paquetes RPM de RHEL**
------
#### [ x86\$164 ]
```
curl -o "session-manager-plugin.rpm" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm"
```
------
#### [ ARM64 ]
```
curl -o "session-manager-plugin.rpm" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm"
```
------
**Paquetes Deb de Debian Server y Ubuntu Server**
------
#### [ x86\$164 ]
```
curl -o "session-manager-plugin.deb" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb"
```
------
#### [ ARM64 ]
```
curl -o "session-manager-plugin.deb" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb"
```
------
## Paso 2: descargue el archivo de firma asociado
Después de descargar el paquete del instalador, descargue el archivo de firma asociado para la verificación del paquete. Para proporcionar un nivel adicional de protección contra la copia o el uso no autorizados del archivo binario del complemento de Session Manager incluido en el paquete, también ofrecemos firmas binarias, que puede usar para validar archivos binarios individuales. Puede optar por usar estas firmas binarias en función de sus necesidades de seguridad.
**Amazon Linux 2, AL2023 y paquetes de firma de RHEL**
------
#### [ x86\$164 ]
Paquete:
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm.sig"
```
Binario:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
Paquete:
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm.sig"
```
Binario:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.sig"
```
------
**Paquetes de firma Deb de Debian Server y Ubuntu Server**
------
#### [ x86\$164 ]
Paquete:
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb.sig"
```
Binario:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
Paquete:
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb.sig"
```
Binario:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.sig"
```
------
## Paso 3: instale la herramienta GPG
Para verificar la firma del complemento de Session Manager, debe tener la herramienta GNU Privacy Guard (GPG) instalada en el sistema. El proceso de verificación requiere el uso de la versión 2.1 o posterior de GPG. Para comprobar su versión de GPG, ejecute el siguiente comando:
```
gpg --version
```
Si su versión de GPG es anterior a la 2.1, actualícela antes de continuar con el proceso de verificación. En la mayoría de los sistemas, puede actualizar la herramienta GPG con su administrador de paquetes. Por ejemplo, en versiones compatibles de Amazon Linux y RHEL, puede usar los siguientes comandos:
```
sudo yum update
sudo yum install gnupg2
```
En sistemas Ubuntu Server y Debian Server compatibles, puede usar los siguientes comandos:
```
sudo apt-get update
sudo apt-get install gnupg2
```
Asegúrese de tener la versión de GPG requerida antes de continuar con el proceso de verificación.
## Paso 4: verifique el paquete del instalador del complemento de Session Manager en un servidor Linux
Use el siguiente procedimiento para verificar el paquete del instalador del complemento de Session Manager en un servidor Linux.
**nota**
Amazon Linux 2 no es compatible con la versión 2.1 o superior de la herramienta GPG. Si el siguiente procedimiento no funciona en las instancias de Amazon Linux 2, verifique la firma en una plataforma diferente antes de instalarla en las instancias de Amazon Linux 2.
1. Copie la siguiente clave pública y guárdela en un archivo denominado “session-manager-plugin.gpg”.
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mFIEZ5ERQxMIKoZIzj0DAQcCAwQjuZy+IjFoYg57sLTGhF3aZLBaGpzB+gY6j7Ix
P7NqbpXyjVj8a+dy79gSd64OEaMxUb7vw/jug+CfRXwVGRMNtIBBV1MgU1NNIFNl
c3Npb24gTWFuYWdlciA8c2Vzc2lvbi1tYW5hZ2VyLXBsdWdpbi1zaWduZXJAYW1h
em9uLmNvbT4gKEFXUyBTeXN0ZW1zIE1hbmFnZXIgU2Vzc2lvbiBNYW5hZ2VyIFBs
dWdpbiBMaW51eCBTaWduZXIgS2V5KYkBAAQQEwgAqAUCZ5ERQ4EcQVdTIFNTTSBT
ZXNzaW9uIE1hbmFnZXIgPHNlc3Npb24tbWFuYWdlci1wbHVnaW4tc2lnbmVyQGFt
YXpvbi5jb20+IChBV1MgU3lzdGVtcyBNYW5hZ2VyIFNlc3Npb24gTWFuYWdlciBQ
bHVnaW4gTGludXggU2lnbmVyIEtleSkWIQR5WWNxJM4JOtUB1HosTUr/b2dX7gIe
AwIbAwIVCAAKCRAsTUr/b2dX7rO1AQCa1kig3lQ78W/QHGU76uHx3XAyv0tfpE9U
oQBCIwFLSgEA3PDHt3lZ+s6m9JLGJsy+Cp5ZFzpiF6RgluR/2gA861M=
=2DQm
-----END PGP PUBLIC KEY BLOCK-----
```
1. Importe la clave pública en su llavero. El valor de clave devuelto debe ser `2C4D4AFF6F6757EE`.
```
$ gpg --import session-manager-plugin.gpg
gpg: key 2C4D4AFF6F6757EE: public key "AWS SSM Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)" imported
gpg: Total number processed: 1
gpg: imported: 1
```
1. Ejecute el siguiente comando para verificar la huella digital.
```
gpg --fingerprint 2C4D4AFF6F6757EE
```
La huella digital del resultado del comando debe coincidir con lo siguiente.
```
7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
```
```
pub nistp256 2025-01-22 [SC]
7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
uid [ unknown] AWS SSM Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)
```
Si la huella digital no coincide, no instale el complemento. Póngase en contacto con AWS Support.
1. Verifique la firma del paquete del instalador. Reemplace *signature-filename* y *downloaded-plugin-filename* por los valores que especificó cuando descargó el archivo de firma y session-manager-plugin, como se muestra en la tabla que figura más arriba en este tema.
```
gpg --verify signature-filename downloaded-plugin-filename
```
Por ejemplo, para la arquitectura x86\$164 en Amazon Linux 2, el comando es el siguiente:
```
gpg --verify session-manager-plugin.rpm.sig session-manager-plugin.rpm
```
Este comando devuelve un resultado similar al siguiente.
```
gpg: Signature made Mon Feb 3 20:08:32 2025 UTC gpg: using ECDSA key 2C4D4AFF6F6757EE
gpg: Good signature from "AWS Systems Manager Session Manager (AWS Systems Manager Session Manager Plugin Linux Signer Key)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7959 6371 24CE 093A D501 D47A 2C4D 4AFF 6F67 57EE
```
Si el resultado incluye la expresión `BAD signature`, compruebe si ha realizado el procedimiento correctamente. Si sigue recibiendo esta respuesta, comuníquese con AWS Support y no instale el paquete. El mensaje de advertencia sobre la confianza no significa que la firma no sea válida, sino que no se ha verificado la clave pública. Una clave solo es de confianza si la ha firmado usted o alguien en quien confíe. Si el resultado incluye la frase `Can't check signature: No public key`, verifique que haya descargado la versión 1.2.707.0 o posterior del complemento de Session Manager.
# Instalar el complemento Session Manager en Amazon Linux 2, Amazon Linux 2023 y las distribuciones de Red Hat Enterprise Linux
Siga el siguiente procedimiento para instalar el complemento Session Manager en Amazon Linux 2, Amazon Linux 2023 (AL2023) y las distribuciones de RHEL.
1. Descargue el paquete RPM del complemento de Session Manager.
------
#### [ x86\$164 ]
En Amazon Linux 2 y RHEL 7, ejecute el siguiente comando:
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
En AL2023 y RHEL 8 y 9, ejecute el siguiente comando:
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
------
#### [ ARM64 ]
En Amazon Linux 2 y RHEL 7, ejecute el siguiente comando:
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
En AL2023 y RHEL 8 y 9, ejecute el siguiente comando:
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
------
1. Compruebe que la instalación se ha realizado correctamente. Para obtener más información, consulte [Verificación de la instalación del complemento de Session Manager](install-plugin-verify.md).
**nota**
Si quiere desinstalar el complemento, ejecute `sudo yum erase session-manager-plugin -y`
# Instale el complemento Session Manager en Debian Server y Ubuntu Server
1. Descargue el paquete deb del complemento de Session Manager.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
```
------
#### [ ARM64 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb" -o "session-manager-plugin.deb"
```
------
1. Ejecute el comando de instalación.
```
sudo dpkg -i session-manager-plugin.deb
```
1. Compruebe que la instalación se ha realizado correctamente. Para obtener más información, consulte [Verificación de la instalación del complemento de Session Manager](install-plugin-verify.md).
**nota**
Si alguna vez desea desinstalar el complemento, ejecute `sudo dpkg -r session-manager-plugin`
# Verificación de la instalación del complemento de Session Manager
Ejecute los siguientes comandos para verificar que el complemento de Session Manager se instaló correctamente.
```
session-manager-plugin
```
Si la instalación se realizó de forma correcta, se devuelve el siguiente mensaje.
```
The Session Manager plugin is installed successfully. Use the AWS CLI to start a session.
```
También puede probar la instalación ejecutando el comando [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) en la [AWS Command Line Interface](https://aws.amazon.com/cli/) (AWS CLI). En el siguiente comando, reemplace *instance-id* por su propia información.
```
aws ssm start-session --target instance-id
```
Este comando solo funcionará si ha instalado y configurado la AWS CLI, y si el administrador de Session Manager le ha concedido los permisos de IAM necesarios para acceder al nodo administrado de destino con Session Manager.
# El complemento Session Manager en GitHub
El código fuente del complemento Session Manager está disponible en [https://github.com/aws/session-manager-plugin](https://github.com/aws/session-manager-plugin) para que pueda adaptar el complemento a sus necesidades. Le recomendamos enviar [solicitudes de inserción](https://github.com/aws/session-manager-plugin/blob/mainline/CONTRIBUTING.md) para los cambios que le gustaría que incluyamos. No obstante, Amazon Web Services no admite la ejecución de copias modificadas de este software.
# (Opcional) Activación del registro del complemento de Session Manager
El complemento de Session Manager incluye una opción para permitir el registro de las sesiones que ejecute. De forma predeterminada, el registro está desactivado.
Si permite el registro, el complemento de Session Manager creará archivos de registros para la actividad de la aplicación (`session-manager-plugin.log`) y los errores (`errors.log`) en su equipo local.
**Topics**
+ [Activación del registro del complemento de Session Manager (Windows)](#configure-logs-windows)
+ [Habilitación del registro del complemento de Session Manager (Linux y macOS)](#configure-logs-linux)
## Activación del registro del complemento de Session Manager (Windows)
1. Localice el archivo `seelog.xml.template` del complemento.
La ubicación predeterminada es `C:\Program Files\Amazon\SessionManagerPlugin\seelog.xml.template`.
1. Cambie el nombre del archivo a `seelog.xml`.
1. Abra el archivo y cambie `minlevel="off"` a `minlevel="info"` o `minlevel="debug"`.
**nota**
De forma predeterminada, las entradas de registro sobre la apertura de un canal de datos y la reconexión de sesiones se registran en el nivel **DE INFORMACIÓN**. Las entradas de flujos de datos (paquetes y confirmación) se registran en el nivel **DE DEPURACIÓN**.
1. Cambie otras opciones de configuración que desea modificar. Entre las opciones que se pueden cambiar se encuentran las siguientes:
+ **Nivel de depuración**: puede cambiar el nivel de depuración de `formatid="fmtinfo"` a `formatid="fmtdebug"`.
+ **Opciones de archivos de registro**: puede realizar cambios en las opciones de archivos de registro, como la ubicación en la que se almacenan los registros, con la excepción de los nombres de los archivos de registro.
**importante**
No cambie los nombres de los archivos, si no, el registro no funcionará correctamente.
```
```
1. Guarde el archivo.
## Habilitación del registro del complemento de Session Manager (Linux y macOS)
1. Localice el archivo `seelog.xml.template` del complemento.
La ubicación predeterminada es `/usr/local/sessionmanagerplugin/seelog.xml.template`.
1. Cambie el nombre del archivo a `seelog.xml`.
1. Abra el archivo y cambie `minlevel="off"` a `minlevel="info"` o `minlevel="debug"`.
**nota**
De forma predeterminada, las entradas de registro sobre la apertura de canales de datos y la reconexión de sesiones se registran en el nivel **DE INFORMACIÓN**. Las entradas de flujos de datos (paquetes y confirmación) se registran en el nivel **DE DEPURACIÓN**.
1. Cambie otras opciones de configuración que desea modificar. Entre las opciones que se pueden cambiar se encuentran las siguientes:
+ **Nivel de depuración**: puede cambiar el nivel de depuración de `formatid="fmtinfo"` a `outputs formatid="fmtdebug"`.
+ **Opciones de archivos de registro**: puede realizar cambios en las opciones de archivos de registro, como la ubicación en la que se almacenan los registros, con la excepción de los nombres de los archivos de registro.
**importante**
No cambie los nombres de los archivos, si no, el registro no funcionará correctamente.
```
```
**importante**
Si utiliza el directorio predeterminado especificado para almacenar registros, debe ejecutar comandos de sesión usando **sudo** o proporcionar el directorio donde el complemento instaló todos los permisos de lectura y escritura. Para eludir estas restricciones, cambie la ubicación donde se almacenan los registros.
1. Guarde el archivo.
# Inicio de una sesión
Puede utilizar la consola de AWS Systems Manager, la consola de Amazon Elastic Compute Cloud (Amazon EC2), la AWS Command Line Interface (AWS CLI) o SSH para iniciar una sesión.
**Topics**
+ [Inicio de una sesión (consola de Systems Manager)](#start-sys-console)
+ [Inicio de una sesión (consola de Amazon EC2)](#start-ec2-console)
+ [Inicio de una sesión (AWS CLI)](#sessions-start-cli)
+ [Inicio de una sesión (SSH)](#sessions-start-ssh)
+ [Inicio de una sesión (enrutamiento de puertos)](#sessions-start-port-forwarding)
+ [Inicio de una sesión (reenvío de puertos a host remoto)](#sessions-remote-port-forwarding)
+ [Inicio de una sesión (comandos interactivos y no interactivos)](#sessions-start-interactive-commands)
## Inicio de una sesión (consola de Systems Manager)
Puede utilizar la consola de AWS Systems Manager para iniciar una sesión con un nodo administrado en la cuenta.
**nota**
Antes de iniciar una sesión, asegúrese de haber completado los pasos de configuración de Session Manager. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md).
**Para iniciar una sesión (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 **Session Manager**.
1. Haga clic en **Start session (Iniciar sesión)**.
1. (Opcional) Ingrese una descripción de la sesión en el campo **Motivo de la sesión**.
1. En **Instancias de destino**, elija el botón de opción situado a la izquierda del nodo administrado al que desea conectarse.
Si el nodo que desea no está en la lista o si selecciona un nodo y recibe un error de configuración, consulte [Nodo administrado no disponible o no configurado para Session Manager](session-manager-troubleshooting.md#session-manager-troubleshooting-instances) para seguir los pasos de solución de problemas.
1. Seleccione **Iniciar sesión** para iniciar la sesión de forma inmediata.
-o bien-
Elija **Siguiente** para ver las opciones de sesión.
1. (Opcional) En **Documento de sesión**, seleccione el documento que desea ejecutar cuando se inicie la sesión. Si el documento admite parámetros de tiempo de ejecución, puede introducir uno o más valores separados por comas en cada campo de parámetro.
1. Elija **Siguiente**.
1. Haga clic en **Start session (Iniciar sesión)**.
Una vez establecida la conexión, puede ejecutar comandos bash (Linux y macOS) o comandos PowerShell (Windows), tal como lo haría con cualquier otro tipo de conexión.
**importante**
Si desea permitir a los usuarios especificar un documento al iniciar las sesiones en la consola de Session Manager, tenga en cuenta lo siguiente:
Debe conceder a los usuarios los permisos `ssm:GetDocument` y `ssm:ListDocuments` en su política de IAM. Para obtener más información, consulte [Conceder acceso a documentos de sesión personalizados en la consola](getting-started-restrict-access-examples.md#grant-access-documents-console-example).
La consola solo admite los documentos de Session que tengan el `sessionType` definido como `Standard_Stream`. Para obtener más información, consulte [Esquema del documento de Session](session-manager-schema.md).
## Inicio de una sesión (consola de Amazon EC2)
Puede utilizar la consola de Amazon Elastic Compute Cloud (Amazon EC2) para iniciar una sesión con una instancia de su cuenta.
**nota**
Si recibe un mensaje de error que indica que no está autorizado para llevar a cabo una o más acciones de Systems Manager (`ssm:command-name`), debe contactar con su administrador para recibir ayuda. El administrador es la persona que le proporcionó las credenciales de inicio de sesión. Pídale a esa persona que actualice las políticas de modo que le permitan iniciar sesiones desde la consola de Amazon EC2. Si es administrador, consulte [Ejemplos de políticas de IAM para Session Manager](getting-started-restrict-access-quickstart.md) para obtener más información.
**Para iniciar una sesión (consola de Amazon EC2)**
1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. En el panel de navegación, seleccione **Instances** (Instancia[s]).
1. Seleccione la instancia y elija **Connect (Conectar)**.
1. Para **Connection Method (Método de conexión)**, seleccione **Session Manager**.
1. Elija **Conectar**.
Una vez establecida la conexión, puede ejecutar comandos bash (Linux y macOS) o comandos PowerShell (Windows), tal como lo haría con cualquier otro tipo de conexión.
## Inicio de una sesión (AWS CLI)
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).
Antes de iniciar una sesión, asegúrese de haber completado los pasos de configuración de Session Manager. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md).
Para utilizar la AWS CLI para ejecutar comandos de sesión, el complemento de Session Manager también debe estar instalado en su equipo local. Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md).
Para iniciar una sesión mediante la AWS CLI, ejecute el siguiente comando y reemplace *instance-id* por su propia información.
```
aws ssm start-session \
--target instance-id
```
Para obtener más información sobre otras opciones que puede utilizar con el comando **start-session**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) en la sección de AWS Systems Manager en la Referencia de comandos de la AWS CLI.
## Inicio de una sesión (SSH)
Para iniciar una sesión de SSH de Session Manager, la versión 2.3.672.0 o una versión posterior de SSM Agent debe estar instalada en el nodo administrado.
**Requisitos de conexión de SSH**
Tome nota de los siguientes requisitos y limitaciones de las conexiones de sesión mediante SSH con Session Manager:
+ El nodo administrado de destino debe estar configurado para admitir conexiones SSH. Para obtener más información, consulte [(Opcional) Habilitación y control de permisos para conexiones de SSH mediante Session Manager](session-manager-getting-started-enable-ssh-connections.md).
+ Debe conectarse utilizando la cuenta del nodo administrado asociada al certificado Privacy Enhanced Mail (PEM), no la cuenta `ssm-user` que se utiliza para otros tipos de conexiones de sesión. Por ejemplo, en las instancias de EC2 de Linux y macOS, el usuario predeterminado es `ec2-user`. Para obtener información sobre cómo identificar al usuario predeterminado de cada tipo de instancia, consulte [Obtención de información sobre una instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connection-prereqs.html#connection-prereqs-get-info-about-instance) en la *Guía del usuario de Amazon EC2*.
+ El registro no está disponible para las sesiones de Session Manager que se conectan a través del reenvío de puertos o de SSH. Esto se debe a que SSH cifra todos los datos de la sesión dentro de la conexión TLS segura establecida entre los puntos de conexión AWS CLI y Session Manager, y Session Manager solo funciona como túnel para las conexiones de SSH.
**nota**
Antes de iniciar una sesión, asegúrese de haber completado los pasos de configuración de Session Manager. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md).
Para iniciar una sesión con SSH, ejecute el siguiente comando. Reemplace cada *example resource placeholder* por su propia información.
```
ssh -i /path/my-key-pair.pem username@instance-id
```
**sugerencia**
Cuando inicia una sesión con SSH, puede copiar archivos locales al nodo administrado de destino con el siguiente formato de comando.
```
scp -i /path/my-key-pair.pem /path/ExampleFile.txt username@instance-id:~
```
Para obtener más información sobre otras opciones que puede utilizar con el comando **start-session**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) en la sección de AWS Systems Manager en la Referencia de comandos de la AWS CLI.
## Inicio de una sesión (enrutamiento de puertos)
Para iniciar una sesión de reenvío de puertos de Session Manager, el nodo administrado debe tener instalada la versión 2.3.672.0 de SSM Agent o una posterior.
**nota**
Antes de iniciar una sesión, asegúrese de haber completado los pasos de configuración de Session Manager. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md).
Para utilizar la AWS CLI para ejecutar comandos de sesión, debe instalar el complemento de Session Manager en su equipo local. Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md).
Según el sistema operativo y la herramienta de línea de comandos, la colocación de comillas puede variar, y es posible que se requieran caracteres de escape.
Para iniciar una sesión de reenvío de puertos, ejecute el siguiente comando desde la CLI. Reemplace cada *example resource placeholder* por su propia información.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"], "localPortNumber":["56789"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name AWS-StartPortForwardingSession ^
--parameters portNumber="3389",localPortNumber="56789"
```
------
El valor `portNumber` representa el puerto remoto del nodo administrado al que desea que se redirija el tráfico de la sesión. Por ejemplo, puede especificar el puerto `3389` para conectarse a un nodo de Windows mediante el protocolo de escritorio remoto (RDP). Si no especifica el parámetro `portNumber`, Session Manager utiliza `80` como el valor predeterminado.
`localPortNumber` es el puerto del equipo local donde comienza el tráfico, por ejemplo `56789`. Este valor es lo que se ingresa cuando se conecta a un nodo administrado mediante un cliente. Por ejemplo, **localhost:56789**.
Para obtener más información sobre otras opciones que puede utilizar con el comando **start-session**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) en la sección de AWS Systems Manager en la Referencia de comandos de la AWS CLI.
Para obtener más información acerca de las sesiones de reenvío de puertos, consulte [Port Forwarding Using AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/) (Reenvío de puertos mediante Session Manager de Systems Manager) en el *Blog de noticias de AWS*.
## Inicio de una sesión (reenvío de puertos a host remoto)
Para iniciar una sesión de reenvío de puertos de Session Manager a un host remoto, el nodo administrado debe tener instalada la versión 3.1.1374.0 o posterior de SSM Agent. No se requiere que Systems Manager administre el host remoto.
**nota**
Antes de iniciar una sesión, asegúrese de haber completado los pasos de configuración de Session Manager. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md).
Para utilizar la AWS CLI para ejecutar comandos de sesión, debe instalar el complemento de Session Manager en su equipo local. Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md).
Según el sistema operativo y la herramienta de línea de comandos, la colocación de comillas puede variar, y es posible que se requieran caracteres de escape.
Para iniciar una sesión de reenvío de puertos, ejecute el siguiente comando desde la AWS CLI. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["mydb.example.us-east-2.rds.amazonaws.com"],"portNumber":["3306"], "localPortNumber":["3306"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name AWS-StartPortForwardingSessionToRemoteHost ^
--parameters host="mydb.example.us-east-2.rds.amazonaws.com",portNumber="3306",localPortNumber="3306"
```
------
El valor `host` representa el nombre de host o la dirección IP del host remoto al que desea conectarse. Se siguen aplicando los requisitos generales de conectividad y resolución de nombres entre el nodo administrado y el host remoto.
El valor `portNumber` representa el puerto remoto del nodo administrado al que desea que se redirija el tráfico de la sesión. Por ejemplo, puede especificar el puerto `3389` para conectarse a un nodo de Windows mediante el protocolo de escritorio remoto (RDP). Si no especifica el parámetro `portNumber`, Session Manager utiliza `80` como el valor predeterminado.
`localPortNumber` es el puerto del equipo local donde comienza el tráfico, por ejemplo `56789`. Este valor es lo que se ingresa cuando se conecta a un nodo administrado mediante un cliente. Por ejemplo, **localhost:56789**.
Para obtener más información sobre otras opciones que puede utilizar con el comando **start-session**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) en la sección de AWS Systems Manager en la Referencia de comandos de la AWS CLI.
### Iniciar una sesión con una tarea de Amazon ECS
Session Manager permite iniciar una sesión de reenvío de puertos con una tarea dentro de un clúster de Amazon Elastic Container Service (Amazon ECS). Para ello, habilite ECS Exec. Para obtener más información sobre Amazon ECS, consulte [Supervisión de los contenedores de Amazon ECS con ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) en la *Guía para desarrolladores de Amazon Elastic Container Service*.
También debe actualizar el rol de tarea en IAM para incluir los siguientes permisos:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}
]
}
```
------
Para iniciar una sesión de reenvío de puertos con una tarea de Amazon ECS, ejecute el siguiente comando desde la AWS CLI. Reemplace cada *example resource placeholder* con su propia información.
**nota**
Elimine los símbolos < y > del parámetro `target`. Estos símbolos se proporcionan únicamente para que el lector los aclare.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target ecs:__ \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["URL"],"portNumber":["port_number"], "localPortNumber":["port_number"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target ecs:__ ^
--document-name AWS-StartPortForwardingSessionToRemoteHost ^
--parameters host="URL",portNumber="port_number",localPortNumber="port_number"
```
------
## Inicio de una sesión (comandos interactivos y no interactivos)
Antes de iniciar una sesión, asegúrese de haber completado los pasos de configuración de Session Manager. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md).
Para utilizar la AWS CLI para ejecutar comandos de sesión, el complemento de Session Manager también debe estar instalado en su equipo local. Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md).
Para iniciar una sesión de comandos interactivos, ejecute el siguiente comando. Reemplace cada *example resource placeholder* por su propia información.
------
#### [ Linux & macOS ]
```
aws ssm start-session \
--target instance-id \
--document-name CustomCommandSessionDocument \
--parameters '{"logpath":["/var/log/amazon/ssm/amazon-ssm-agent.log"]}'
```
------
#### [ Windows ]
```
aws ssm start-session ^
--target instance-id ^
--document-name CustomCommandSessionDocument ^
--parameters logpath="/var/log/amazon/ssm/amazon-ssm-agent.log"
```
------
Para obtener más información sobre otras opciones que puede utilizar con el comando **start-session**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) en la sección de AWS Systems Manager en la Referencia de comandos de la AWS CLI.
**Más información**
+ [Uso del reenvío de puertos en AWS Systems Manager Session Manager para conectarse a hosts remotos](https://aws.amazon.com/blogs/mt/use-port-forwarding-in-aws-systems-manager-session-manager-to-connect-to-remote-hosts/)
+ [Reenvío de puertos de instancias Amazon EC2 con AWS Systems Manager](https://aws.amazon.com/blogs/mt/amazon-ec2-instance-port-forwarding-with-aws-systems-manager/)
+ [Administre los recursos de AWS administrados de Microsoft AD con el reenvío de puertos Session Manager](https://aws.amazon.com/blogs/mt/manage-aws-managed-microsoft-ad-resources-with-session-manager-port-forwarding/)
+ [Port Forwarding Using AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/) en el *Blog de noticias de AWS*.
# Finalización de una sesión
Puede utilizar la consola de AWS Systems Manager o la AWS Command Line Interface (AWS CLI) para terminar una sesión que haya iniciado en la cuenta. Si toca en el botón **Terminar** de una sesión en la consola o llama a la acción de la API [TerminateSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TerminateSession.html) por medio de la AWS CLI, Session Manager finaliza permanentemente la sesión y cierra la conexión de datos entre el cliente Session Manager y SSM Agent en el nodo administrado. No puede reanudar una sesión terminada.
Si no hay actividad del usuario en una sesión abierta durante 20 minutos, el estado de inactividad acciona un tiempo de espera. Session Manager no llama a `TerminateSession`,pero sí cierra el canal subyacente. No puede reanudar una sesión cerrada debido a un tiempo de espera de inactividad.
Recomendamos siempre cerrar una sesión de forma explícita con el comando `terminate-session`, cuando se utilice el AWS CLI, o el botón **Finalizar** cuando se utilice la consola. (Los botones **Finalizar** se encuentran tanto en la ventana de la sesión como en la página principal de la consola Session Manager). Si solo cierra un navegador o una ventana de comandos, la sesión permanecerá como **Activa** en la consola durante 30 días. Cuando no cierra una sesión de forma explícita o cuando la sesión termina por inactividad, todos los procesos que estaban en ejecución en el nodo administrado en ese momento seguirán ejecutándose.
**Topics**
+ [Finalización de una sesión (consola)](#stop-sys-console)
+ [Finalización de una sesión (AWS CLI)](#stop-cli)
## Finalización de una sesión (consola)
Puede utilizar la consola de AWS Systems Manager para terminar una sesión en la cuenta.
**Para terminar una sesión (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 **Session Manager**.
1. En **Sessions (Sesiones)**, elija la opción que aparece a la izquierda de la sesión que desea terminar.
1. Elija **Finalizar**.
## Finalización de una sesión (AWS CLI)
Para terminar una sesión con la AWS CLI, ejecute el siguiente comando. Reemplace *session-id* por su propia información.
```
aws ssm terminate-session \
--session-id session-id
```
Para obtener más información sobre el comando **terminate-session**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html) en la sección AWS Systems Manager de la Referencia de comando de la AWS CLI.
# Visualización del historial de sesiones
Puede usar la consola de AWS Systems Manager o la AWS Command Line Interface (AWS CLI) para ver información acerca de las sesiones de su cuenta. En la consola, puede ver los detalles de la sesión, como los siguientes:
+ El ID de la sesión
+ Qué usuario se ha conectado a un nodo administrado a través de una sesión
+ El ID del nodo administrado
+ Cuándo la sesión comenzó y terminó
+ El estado de la sesión
+ la ubicación especificada para almacenar los registros de la sesión (si está habilitado)
Al usar la AWS CLI, puede ver una lista de sesiones de su cuenta, pero no los detalles adicionales que están disponibles en la consola.
Para obtener más información acerca del historial de sesiones de registro, consulte [Habilitar y deshabilitar el registro de la sesión](session-manager-logging.md).
**Topics**
+ [Visualización del historial de sesiones (consola)](#view-console)
+ [Visualización del historial de sesiones (AWS CLI)](#view-history-cli)
## Visualización del historial de sesiones (consola)
Puede usar la consola de AWS Systems Manager para ver los detalles de las sesiones de su cuenta.
**Para ver el historial de sesiones (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 **Session Manager**.
1. Elija la pestaña **Session history (Historial de sesiones)**.
-o bien-
Si la página principal de Session Manager se abre primero, elija **Configurar preferencias** y, a continuación, elija la pestaña **Historial de sesiones**.
## Visualización del historial de sesiones (AWS CLI)
Para ver una lista de las sesiones de su cuenta con la AWS CLI, ejecute el siguiente comando.
```
aws ssm describe-sessions \
--state History
```
**nota**
Este comando solo devuelve los resultados de las conexiones a destinos iniciados mediante Session Manager. No muestra las conexiones realizadas a través de otros medios, como el Protocolo de escritorio remoto (RDP) o el Protocolo de shell seguro (SSH).
Para obtener más información sobre otras opciones que puede utilizar con el comando **describe-sessions**, consulte [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html) en la sección sobre AWS Systems Manager de la Referencia de comandos de la AWS CLI.
# Registro de la actividad de la sesión
Además de proporcionar información acerca de las sesiones actuales y completadas en la consola de Systems Manager, el Session Manager proporciona la posibilidad de registrar la actividad de las sesiones en la Cuenta de AWS con AWS CloudTrail.
CloudTrail registra las llamadas a la API de la sesión realizadas a través de la consola de Systems Manager, la AWS Command Line Interface (AWS CLI) y el SDK de Systems Manager. Puede ver la información en la consola de CloudTrail o almacenarla en un bucket de Amazon Simple Storage Service (Amazon S3) especificado. Se utiliza un bucket de Amazon S3 para todos los registros de CloudTrail de su cuenta. Para obtener más información, consulte [Registro de llamadas a la API de AWS Systems Manager con AWS CloudTrail](monitoring-cloudtrail-logs.md).
**nota**
Para llevar a cabo un análisis periódico e histórico de sus archivos de registro, considere la posibilidad de consultar los registros de CloudTrail mediante [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) o una tabla que usted mantenga. Para obtener más información, consulte [Consulta de registros de AWS CloudTrail](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html) en la *Guía del usuario de AWS CloudTrail*.
## Supervisión de la actividad de la sesión con Amazon EventBridge (consola)
Con EventBridge, puede configurar reglas para detectar cuándo se producen cambios en los recursos de AWS. Puede crear una regla para detectar cuándo un usuario de su organización inicia o termina una sesión y, a continuación, por ejemplo, recibir una notificación a través de Amazon SNS sobre el evento.
La compatibilidad de EventBridge con Session Manager se basa en los registros de las operaciones de la API que CloudTrail registró. (Puede usar la integración de CloudTrail a EventBridge para responder a la mayoría de los eventos de AWS Systems Manager). Las acciones que se llevan a cabo dentro de una sesión, como un comando `exit`, que no hacen una llamada a la API no son detectadas por EventBridge.
En los siguientes pasos se describe cómo iniciar las notificaciones a través de Amazon Simple Notification Service (Amazon SNS) cuando se produce un evento de la API de Session Manager, como **StartSession**.
**Para supervisar la actividad de la sesión con Amazon EventBridge (consola)**
1. Cree un tema de Amazon SNS que se utilice para enviar notificaciones cuando se produzca un evento de Session Manager del que desea realizar un seguimiento.
Para obtener más información, consulte [Creación de un tema](https://docs.aws.amazon.com/sns/latest/dg/CreateTopic.html) en la *Guía para desarrolladores de Amazon Simple Notification Service*.
1. Cree una regla de EventBridge para invocar el destino de Amazon SNS para el tipo de evento de Session Manager del que desea realizar un seguimiento.
Para obtener más información sobre cómo crear la regla, consulte [Creating Amazon EventBridge rules that react to events](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) en la *Guía del usuario de Amazon EventBridge*.
Cuando siga los pasos para crear la regla, realice las siguientes selecciones:
+ En **AWS service** (Servicio de ), elija **Systems Manager**.
+ En **Tipo de evento**, elija **Llamada a la API de AWS con CloudTrail**.
+ Elija **Specific operation(s) (Operaciones específicas)** y, a continuación, introduzca los comandos de Session Manager (uno a uno) para recibir notificaciones. También puede elegir **StartSession**, **ResumeSession** y **TerminateSession**. (EventBridge no admite los comandos `Get*`, ` List*` ni `Describe*`).
+ Para **Seleccione un destino**, elija **Tema de SNS**. En **Topic** (Tema), seleccione el nombre del tema de Amazon SNS que creó en el paso 1.
Para obtener más información, consulte la *[Guía del usuario de Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/)* y la *[Guía de introducción a Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/gsg/)*.
# Habilitar y deshabilitar el registro de la sesión
El registro de sesiones registra la información sobre las sesiones actuales y finalizadas en la consola de Systems Manager. También se pueden registrar los detalles sobre los comandos que se ejecutan durante las sesiones en su Cuenta de AWS. Registrarse en la sesión le permite hacer lo siguiente:
+ Crear y almacenar los registros de sesión para fines de archivado.
+ Generar un informe que muestre los detalles de cada conexión realizada en los nodos administrados mediante Session Manager en los últimos 30 días.
+ Genere notificaciones del registro de la sesión en su Cuenta de AWS, como las notificaciones de Amazon Simple Notification Service (Amazon SNS).
+ Iniciar otra acción automáticamente en un recurso de AWS como resultado de las acciones realizadas durante una sesión, como la ejecución de una función de AWS Lambda, el inicio de una canalización de AWS CodePipeline o la ejecución de un documento de AWS Systems Manager Run Command.
**importante**
Tenga en cuenta los siguientes requisitos y limitaciones de Session Manager:
Session Manager registra los comandos que usted ingresa y sus resultados durante una sesión, en función de sus preferencias de sesión. Para evitar que la información confidencial, como las contraseñas, se vean en los registros de sesión, recomendamos utilizar los siguientes comandos al ingresar información confidencial durante una sesión.
```
stty -echo; read passwd; stty echo;
```
```
$Passwd = Read-Host -AsSecureString
```
Si utiliza Windows Server 2012 o versiones anteriores, los datos de sus registros podrían no tener el formato óptimo. Recomendamos que utilice Windows Server 2012 R2 y posterior para contar con formatos de registro óptimo.
Si utiliza nodos administrados de Linux o macOS, asegúrese de que la utilidad de pantalla esté instalada. Si no lo está, los datos de registro podrían truncarse. En Amazon Linux 2, AL2023 y Ubuntu Server, la utilidad de pantalla se instala de forma predeterminada. Para instalar la pantalla de forma manual, en función de la versión de Linux que utilice, ejecute `sudo yum install screen` o `sudo apt-get install screen`.
El registro no está disponible para las sesiones de Session Manager que se conectan a través del reenvío de puertos o de SSH. Esto se debe a que SSH cifra todos los datos de la sesión dentro de la conexión TLS segura establecida entre los puntos de conexión AWS CLI y Session Manager, y Session Manager solo funciona como túnel para las conexiones de SSH.
Para obtener más información acerca de los permisos necesarios para utilizar Amazon S3 o los Registros de Amazon CloudWatch para registrar los datos de la sesión, consulte [Creación de un rol de IAM con permisos para Session Manager, Amazon S3 y los Registros de CloudWatch (consola)](getting-started-create-iam-instance-profile.md#create-iam-instance-profile-ssn-logging).
Consulte los siguientes temas para obtener más información acerca de las opciones de registro de Session Manager.
**Topics**
+ [Streaming de los datos de la sesión con los Registros de Amazon CloudWatch (consola)](session-manager-logging-cwl-streaming.md)
+ [Registro de los datos de la sesión con Amazon S3 (consola)](session-manager-logging-s3.md)
+ [Registro de los datos de la sesión con los Registros de Amazon CloudWatch (consola)](session-manager-logging-cloudwatch-logs.md)
+ [Configuración del registro de sesiones en disco](session-manager-logging-disk.md)
+ [Ajuste del tiempo de almacenamiento del archivo de registro temporal de Session Manager en el disco](session-manager-logging-disk-retention.md)
+ [Inhabilitación del registro de Session Manager en Registros de CloudWatch y Amazon S3](session-manager-enable-and-disable-logging.md)
# Streaming de los datos de la sesión con los Registros de Amazon CloudWatch (consola)
Puede enviar un flujo continuo de registros de datos de sesión a los Registros de Amazon CloudWatch. Los detalles esenciales, como los comandos que un usuario ha ejecutado en una sesión, el ID del usuario que ejecutó los comandos y las marcas de tiempo para el momento en que los datos de sesión se transmiten a los Registros de CloudWatch, se incluyen cuando se efectúa el streaming de los datos de la sesión. Con el streaming de los datos de la sesión, los registros tienen formato JSON para ayudarlo a integrarse a sus soluciones de registro existentes. El streaming de los datos de la sesión no es compatible con los comandos interactivos.
**nota**
Para transmitir los datos de la sesión desde los nodos administrados de Windows Server, debe tener instalado PowerShell 5.1 o una versión posterior. De forma predeterminada, Windows Server 2016 y las versiones posteriores tienen instalada la versión requerida de PowerShell. Sin embargo, Windows Server 2012 y 2012 R2 no tienen instalada de forma predeterminada la versión requerida de PowerShell. Si aún no ha actualizado PowerShell en los nodos administrados de Windows Server 2012 o 2012 R2, puede hacerlo mediante Run Command. Para obtener información sobre cómo actualizar PowerShell con Run Command, consulte [Actualización de PowerShell con Run Command](run-command-tutorial-update-software.md#rc-console-pwshexample).
**importante**
Si tiene la configuración de política **PowerShell Transcription** (Transcripción de PowerShell) establecida en los nodos administrados de Windows Server, no podrá transmitir los datos de la sesión.
**Para transmitir los datos de la sesión con los Registros de Amazon CloudWatch (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 **Session Manager**.
1. Elija la pestaña **Preferences (Preferencias)** y, a continuación, **Edit (Editar)**.
1. En **CloudWatch logging** (Registro de CloudWatch), seleccione la casilla de verificación ubicada junto a **Enable** (Habilitar).
1. Elija la opción de **Stream session logs** (Transmitir registros de sesiones).
1. (Recomendado) Seleccione la casilla de verificación situada junto a **Allow only encrypted CloudWatch log groups** (Permitir solo los grupos de registros cifrados de CloudWatch). Con esta opción activada, los datos de registro se cifran con la clave de cifrado del lado del servidor especificado para el grupo de registros. Si no desea cifrar los datos de registro que se envían a los Registros de CloudWatch, desactive la casilla de verificación. También debe desactivar la casilla de verificación si no se permite el cifrado en el grupo de registros.
1. En **CloudWatch logs** (Registros de CloudWatch), para especificar el grupo de registros de los Registros de CloudWatch existente en su Cuenta de AWS en el que se cargarán los registros de la sesión, seleccione una de las siguientes opciones:
+ Ingrese el nombre de un grupo de registros en el cuadro de texto que ya se haya creado en su cuenta para almacenar los datos de registro de las sesiones.
+ **Browse log groups** (Buscar grupos de registros): seleccione un grupo de registros que ya se haya creado en su cuenta para almacenar los datos de registro de las sesiones.
1. Seleccione **Save**.
# Registro de los datos de la sesión con Amazon S3 (consola)
Puede elegir almacenar los datos de registro de las sesiones en un bucket de Amazon Simple Storage Service (Amazon S3) especificado con fines de depuración y solución de problemas. La opción predeterminada es para los registros que se van a enviar a un bucket cifrado de Amazon S3. El cifrado se realiza con la clave especificada para el bucket, ya sea una AWS KMS key o una clave de cifrado del lado del servidor (SSE) de Amazon S3 (AES-256).
**importante**
Si utiliza buckets de estilo de alojamiento virtual con Capa de conexión segura (SSL), el certificado comodín de SSL solo se asociará con los buckets que no contengan puntos. Para solucionar esto, use HTTP o escriba su propia lógica de verificación de certificado. Cuando use buckets de tipo de alojamiento virtual, le recomendamos no utilizar puntos (“.”) en los nombres de los buckets.
**Cifrado de buckets de Amazon S3**
Para poder enviar los registros a su bucket de Amazon S3 con cifrado, el cifrado debe estar permitido en el bucket. Para obtener más información acerca del cifrado de buckets de Amazon S3, consulte [Cifrado predeterminado de Amazon S3 para los buckets de S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html).
**Clave administrada por el cliente**
Si utiliza una clave de KMS que administra usted mismo para cifrar el bucket, el perfil de instancias de IAM adjunto a sus instancias debe tener permisos explícitos para leer la clave. Si utiliza una Clave administrada de AWS, la instancia no requiere este permiso explícito. Para obtener más información acerca de cómo proporcionar al perfil de instancias acceso para utilizar la clave, consulte [Permiso del uso de la clave a los usuarios](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) en la *Guía para desarrolladores de AWS Key Management Service*.
Siga estos pasos para configurar Session Manager para que almacene los registros de las sesiones en un bucket de Amazon S3.
**nota**
También puede utilizar la AWS CLI para especificar o cambiar el bucket de Amazon S3 al que se enviarán los datos de la sesión. Para obtener más información, consulte [Actualizar preferencias de Session Manager (línea de comandos)](getting-started-configure-preferences-cli.md).
**Cómo registrar los datos de la sesión con Amazon S3 (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 **Session Manager**.
1. Elija la pestaña **Preferences (Preferencias)** y, a continuación, **Edit (Editar)**.
1. Marque la casilla de verificación situada junto a **Enable** (Habilitar) en **S3 logging** (Registro de S3).
1. (Recomendado) Seleccione la casilla de verificación situada junto a **Allow only encrypted S3 buckets** (Permitir solo buckets cifrados de S3). Con esta opción activada, los datos de registro se cifran con la clave de cifrado del lado del servidor especificada para el bucket. Si no desea cifrar los datos de registro que se envían a Amazon S3, desactive la casilla de verificación. También debe desactivar la casilla de verificación si no se permite el cifrado en el bucket de S3.
1. En **S3 bucket name (Nombre del bucket de S3)**, realice alguna de las siguientes operaciones:
**nota**
Cuando use buckets de tipo de alojamiento virtual, le recomendamos no utilizar puntos (“.”) en los nombres de los buckets. Para obtener más información acerca de las convenciones de nomenclatura de buckets de Amazon S3, consulte [Restricciones y limitaciones de los buckets](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules) en la *Guía del usuario de Amazon Simple Storage Service*.
+ **Choose a bucket name from the list** (Elegir un nombre de bucket de la lista): seleccione un bucket de Amazon S3 que ya se haya creado en su cuenta para almacenar los datos de registro de las sesiones.
+ **Enter a bucket name in the text box** (Ingresar el nombre de un bucket en el cuadro de texto): escriba el nombre de un bucket de Amazon S3 que ya se haya creado en su cuenta para almacenar los datos de registro de las sesiones.
1. (Opcional) En **S3 key prefix (Prefijo de clave de S3)**, escriba el nombre de una carpeta nueva o existente para almacenar registros en el bucket seleccionado.
1. Seleccione **Save**.
Para obtener más información acerca de cómo se trabaja con Amazon S3 y buckets de Amazon S3, consulte la *[Guía del usuario de Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)* y la *[Guía del usuario de Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)*.
# Registro de los datos de la sesión con los Registros de Amazon CloudWatch (consola)
Con Registros de Amazon CloudWatch, puede acceder a los archivos de registros de diversos Servicios de AWS, supervisarlos y almacenarlos. Puede enviar los datos de registro de las sesiones a un grupo de registros de los Registros de CloudWatch con fines de depuración y solución de problemas. La opción predeterminada es enviar los datos de registro con cifrado mediante su clave de KMS, pero puede enviar los datos a su grupo de registros con o sin cifrado.
Siga estos pasos para configurar AWS Systems Manager Session Manager para que envíe los datos de registro de las sesiones a un grupo de registros de los Registros de CloudWatch al final de sus sesiones.
**nota**
También puede utilizar la AWS CLI para especificar o cambiar el grupo de registros de los Registros de CloudWatch al que se enviarán los datos de la sesión. Para obtener más información, consulte [Actualizar preferencias de Session Manager (línea de comandos)](getting-started-configure-preferences-cli.md).
**Para registrar los datos de la sesión con los Registros de Amazon CloudWatch (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 **Session Manager**.
1. Elija la pestaña **Preferences (Preferencias)** y, a continuación, **Edit (Editar)**.
1. En **CloudWatch logging** (Registro de CloudWatch), seleccione la casilla de verificación ubicada junto a **Enable** (Habilitar).
1. Elija la opción **Upload session logs** (Cargar registros de sesiones).
1. (Recomendado) Seleccione la casilla de verificación situada junto a **Allow only encrypted CloudWatch log groups** (Permitir solo los grupos de registros cifrados de CloudWatch). Con esta opción activada, los datos de registro se cifran con la clave de cifrado del lado del servidor especificado para el grupo de registros. Si no desea cifrar los datos de registro que se envían a los Registros de CloudWatch, desactive la casilla de verificación. También debe desactivar la casilla de verificación si no se permite el cifrado en el grupo de registros.
1. En **CloudWatch logs** (Registros de CloudWatch), para especificar el grupo de registros de CloudWatch Logs existente en su Cuenta de AWS en el que se cargarán los registros de la sesión, seleccione una de las siguientes opciones:
+ **Choose a log group from the list (Elegir un grupo de recursos de la lista)**: seleccione un grupo de registros que ya se ha creado en su cuenta para almacenar datos de registros de sesiones.
+ **Enter a log group name in the text box (Escribir un nombre del grupo de registros en el cuadro de texto)**: escriba el nombre de un grupo de registros que ya se haya creado en su cuenta para almacenar los datos de registro de la sesión.
1. Seleccione **Save**.
Para obtener más información acerca del uso de los Registros de CloudWatch, consulte la *[Guía del usuario de los Registros de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)*.
# Configuración del registro de sesiones en disco
Tras habilitar el registro de Session Manager en CloudWatch o Amazon S3, todos los comandos ejecutados durante una sesión (y los resultado de estos) se registran en un archivo temporal del disco de la instancia de destino. El archivo temporal se llama `ipcTempFile.log`.
`ipcTempFile.log` se controla mediante el parámetro `SessionLogsDestination` del archivo de configuración de SSM Agent. Este parámetro acepta los siguientes valores:
+ **disk**: si especifica este parámetro y el registro de sesiones en CloudWatch o Amazon S3 está *habilitado*, SSM Agent crea el archivo de registro temporal `ipcTempFile.log` y registra los comandos de sesión y la salida en el disco. Session Manager carga este registro en CloudWatch o S3 durante o después de la sesión, según la configuración del registro. A continuación, el registro se elimina según la duración especificada para el parámetro de configuración `SessionLogsRetentionDurationHours` de SSM Agent.
Si especifica este parámetro y el registro de sesiones en CloudWatch y Amazon S3 está *deshabilitado*, SSM Agent seguirá registrando el historial de comandos y los resultados en el archivo `ipcTempFile.log`. El archivo se eliminará según la duración especificada para el parámetro de configuración `SessionLogsRetentionDurationHours` de SSM Agent.
+ **none**: si especifica este parámetro y el registro de sesiones en CloudWatch o Amazon S3 está *habilitado*, el registro en el disco funciona exactamente igual que si hubiera especificado el parámetro `disk`. SSM Agent necesita el archivo temporal cuando se habilita el registro de sesiones en CloudWatch o Amazon S3.
Si especifica este parámetro y el registro de sesiones en CloudWatch y Amazon S3 está *deshabilitado*, SSM Agent no creará el archivo `ipcTempFile.log`.
Utilice el siguiente procedimiento para activar o desactivar la creación del archivo de registro temporal `ipcTempFile.log` en el disco cuando se inicie una sesión.
**Activación o desactivación de la creación del archivo de registro temporal Session Manager en el disco**
1. Instale SSM Agent en su instancia o actualícelo a la versión 3.2.2086 o superior. Para obtener información sobre cómo comprobar el número de versión del agente, consulte [Verificación del número de versión de SSM Agent](ssm-agent-get-version.md). Para obtener información sobre cómo instalar el agente de manera manual, busque el procedimiento correspondiente a su sistema operativo en las siguientes secciones:
+ [Instalación y desinstalación manual de SSM Agent en instancias de EC2 para Linux](manually-install-ssm-agent-linux.md)
+ [Instalación y desinstalación manual de SSM Agent en instancias de EC2 para macOS](manually-install-ssm-agent-macos.md)
+ [Cómo instalar y desinstalar de forma manual SSM Agent en instancias de EC2 para Windows Server](manually-install-ssm-agent-windows.md)
1. Conéctese a su instancia y busque el archivo `amazon-ssm-agent.json` en la siguiente ubicación.
+ **Linux**: /etc/amazon/ssm/
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
Si el archivo `amazon-ssm-agent.json` no existe, copie el contenido de `amazon-ssm-agent.json.template` en un archivo nuevo del mismo directorio. Asigne al nuevo archivo el nombre `amazon-ssm-agent.json`.
1. En el parámetro `SessionLogsDestination`, especifique `none` o `disk`. Guarde los cambios.
1. [Reinicie](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html) SSM Agent.
Si especificó `disk` en el parámetro `SessionLogsDestination`, puede comprobar que SSM Agent crea el archivo de registro temporal al iniciar una nueva sesión y, a continuación, localizando `ipcTempFile.log` en la siguiente ubicación:
+ **Linux**: /var/lib/amazon/ssm/*target ID*/session/orchestration/*session ID*/Standard\$1Stream/ipcTempFile.log
+ **macOS**: /opt/aws/ssm/data/*target ID*/session/orchestration/*session ID*/Standard\$1Stream/ipcTempFile.log
+ **Windows Server**: C:\$1ProgramData\$1Amazon\$1SSM\$1InstanceData\$1*target ID*\$1session\$1orchestration\$1*session ID*\$1Standard\$1Stream\$1ipcTempFile.log
**nota**
De forma predeterminada, el archivo de registro temporal se guarda en la instancia durante 14 días.
Si desea actualizar el parámetro `SessionLogsDestination` en varias instancias, le recomendamos que cree un documento de SSM que especifique la nueva configuración. A continuación, puede usar Run Command de Systems Manager para implementar el cambio en sus instancias. Para obtener más información, consulte [Writing your own AWS Systems Manager documents (blog)](https://aws.amazon.com/blogs/mt/writing-your-own-aws-systems-manager-documents/) y [Ejecución de comandos en nodos administrados](running-commands.md).
# Ajuste del tiempo de almacenamiento del archivo de registro temporal de Session Manager en el disco
Tras habilitar el registro de Session Manager en CloudWatch o Amazon S3, todos los comandos ejecutados durante una sesión (y los resultado de estos) se registran en un archivo temporal del disco de la instancia de destino. El archivo temporal se llama `ipcTempFile.log`. Durante una sesión, o una vez finalizada, Session Manager carga este registro temporal en CloudWatch o S3. A continuación, el registro temporal se elimina según la duración especificada para el parámetro de configuración `SessionLogsRetentionDurationHours` de SSM Agent. De forma predeterminada, el archivo de registro temporal se guarda en la instancia durante 14 días en la siguiente ubicación:
+ **Linux**: /var/lib/amazon/ssm/*target ID*/session/orchestration/*session ID*/Standard\$1Stream/ipcTempFile.log
+ **macOS**: /opt/aws/ssm/data/*target ID*/session/orchestration/*session ID*/Standard\$1Stream/ipcTempFile.log
+ **Windows Server**: C:\$1ProgramData\$1Amazon\$1SSM\$1InstanceData\$1*target ID*\$1session\$1orchestration\$1*session ID*\$1Standard\$1Stream\$1ipcTempFile.log
Utilice el siguiente procedimiento para ajustar el tiempo de almacenamiento del archivo de registro de Session Manager en el disco.
**Ajuste del tiempo de almacenamiento del archivo `ipcTempFile.log` en el disco**
1. Conéctese a su instancia y busque el archivo `amazon-ssm-agent.json` en la siguiente ubicación.
+ **Linux**: /etc/amazon/ssm/
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
Si el archivo `amazon-ssm-agent.json` no existe, copie el contenido de `amazon-ssm-agent.json.template` en un archivo nuevo del mismo directorio. Asigne al nuevo archivo el nombre `amazon-ssm-agent.json`.
1. Cambie el valor de `SessionLogsRetentionDurationHours` al número de horas deseado. Si `SessionLogsRetentionDurationHours` se establece en 0, el archivo de registro temporal se creará durante la sesión y se eliminará al finalizarla. Esta configuración debe garantizar que el archivo de registro no persista una vez finalizada la sesión.
1. Guarde los cambios.
1. [Reinicie](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html) SSM Agent.
# Inhabilitación del registro de Session Manager en Registros de CloudWatch y Amazon S3
Puede utilizar la consola de Systems Manager o la AWS CLI para deshabilitar el registro de la sesión en la cuenta.
**Para deshabilitar el registro de la sesión (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 **Session Manager**.
1. Elija la pestaña **Preferences (Preferencias)** y, a continuación, **Edit (Editar)**.
1. Para deshabilitar el registro de CloudWatch, en la sección **Registro de CloudWatch**, desactive la casilla **Habilitar**.
1. Para deshabilitar el registro de S3, en la sección **Registro de S3**, desactive la casilla **Habilitar**.
1. Seleccione **Save**.
**Para deshabilitar el registro de sesiones (AWS CLI)**
Para deshabilitar el registro de la sesión mediante la AWS CLI, siga las instrucciones en [Actualizar preferencias de Session Manager (línea de comandos)](getting-started-configure-preferences-cli.md).
En el archivo JSON, asegúrese de que las entradas de `s3BucketName` y `cloudWatchLogGroupName` no contengan valores. Por ejemplo:
```
"inputs": {
"s3BucketName": "",
...
"cloudWatchLogGroupName": "",
...
}
```
Como alternativa, puede eliminar todas las entradas de `S3*` y `cloudWatch*` del archivo JSON para deshabilitar el registro.
**nota**
Según la configuración, después de deshabilitar CloudWatch o S3, es posible que SSM Agent siga generando un archivo de registro temporal en el disco. Para obtener información sobre cómo deshabilitar el registro, consulte [Configuración del registro de sesiones en disco](session-manager-logging-disk.md).
# Esquema del documento de Session
La siguiente información describe los elementos de esquema de un documento de Session. AWS Systems Manager Session Manager utiliza los documentos de Session para determinar qué tipo de sesión iniciar, como una sesión estándar, una sesión de reenvío de puertos o una sesión para ejecutar un comando interactivo.
[schemaVersion](#version)
Versión del esquema del documento de Session. Los documentos de Session solo admiten la versión 1.0.
Tipo: cadena
Obligatorio: sí
[description](#descript)
Una descripción que especifique para el documento de Session. Por ejemplo, “Documento para iniciar la sesión de reenvío de puertos con Session Manager”.
Tipo: cadena
Requerido: no
[sessionType](#type)
El tipo de sesión que se utiliza para establecer el documento de Session.
Tipo: cadena
Obligatorio: sí
Valores válidos: `InteractiveCommands` \$1 `NonInteractiveCommands` \$1 `Port` \$1 `Standard_Stream`
[inputs](#in)
Las preferencias de sesión que se van a utilizar para las sesiones establecidas mediante este documento de Session. Este elemento es necesario para los documentos de Session que se utilizan para crear sesiones `Standard_Stream`.
Tipo: StringMap
Obligatorio: no
[s3BucketName](#bucket)
El bucket de Amazon Simple Storage Service (Amazon S3) al que desea enviar los registros de las sesiones al finalizarlas.
Tipo: cadena
Requerido: no
[s3KeyPrefix](#prefix)
El prefijo que se debe utilizar al enviar registros al bucket de Amazon S3 que usted especificó en el elemento de entrada `s3BucketName` Para obtener más información acerca del uso de un prefijo compartido con almacenamiento de objetos en Amazon S3, consulte [How do I use folders in an S3 bucket?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/using-folders.html) en la *Guía del usuario de Amazon Simple Storage Service*.
Tipo: cadena
Requerido: no
[s3EncryptionEnabled](#s3Encrypt)
Si se establece en `true`, el bucket de Amazon S3 especificado en el elemento de entrada `s3BucketName` debe estar cifrado.
Tipo: Booleano
Obligatorio: sí
[cloudWatchLogGroupName](#logGroup)
El nombre del grupo de los Registros de Amazon CloudWatch (Registros de CloudWatch) al que desea enviar los registros de las sesiones al finalizarlas.
Tipo: cadena
Requerido: no
[cloudWatchEncryptionEnabled](#cwEncrypt)
Si se establece en `true`, el grupo de registros que especificó en el elemento de entrada `cloudWatchLogGroupName` debe estar cifrado.
Tipo: Booleano
Obligatorio: sí
[cloudWatchStreamingEnabled](#cwStream)
Si se establece en `true`, se envía un flujo continuo de registros de datos de sesiones al grupo de registros que especificó en el elemento de entrada `cloudWatchLogGroupName`. Si se establece en `false`, los registros de las sesiones se envían al grupo de registros que especificó en el elemento de entrada `cloudWatchLogGroupName` al finalizar las sesiones.
Tipo: Booleano
Obligatorio: sí
[kmsKeyId](#kms)
El ID de la AWS KMS key que desee utilizar para cifrar aún más los datos entre los equipos cliente locales y los nodos administrados de Amazon Elastic Compute Cloud (Amazon EC2) a los que se conecte.
Tipo: cadena
Requerido: no
[runAsEnabled](#run)
Si se establece en `true`, debe especificar una cuenta de usuario que exista en los nodos administrados a los que se conectará en el elemento de entrada `runAsDefaultUser`. De lo contrario, las sesiones no se iniciarán. De forma predeterminada, las sesiones se inician utilizando la cuenta `ssm-user` creada por AWS Systems Manager SSM Agent. La característica Ejecutar como solo se admite para conectarse a nodos administrados de Linux y macOS.
Tipo: Booleano
Obligatorio: sí
[runAsDefaultUser](#runUser)
El nombre de la cuenta de usuario con la que se iniciarán las sesiones en los nodos administrados de Linux y macOS cuando el elemento de entrada `runAsEnabled` se establezca en `true`. La cuenta de usuario que especifique para este elemento de entrada debe existir en los nodos administrados a los que se conectará; de lo contrario, las sesiones no podrán iniciarse.
Tipo: cadena
Requerido: no
[idleSessionTimeout](#timeout)
La cantidad de tiempo de inactividad que desea permitir antes de que una sesión se termine. Esta entrada se mide en minutos.
Tipo: cadena
Valores válidos: de 1 a 60
Obligatorio: no
[maxSessionDuration](#maxDuration)
La cantidad máxima de tiempo que desea permitir antes de que una sesión se termine. Esta entrada se mide en minutos.
Tipo: cadena
Valores válidos: 1-1440
Obligatorio: no
[shellProfile](#shell)
Las preferencias que especificó por sistema operativo para que se apliquen dentro de las sesiones, como las preferencias de shell, las variables de entorno, los directorios de trabajo y la ejecución de varios comandos cuando se inicia una sesión.
Tipo: StringMap
Obligatorio: no
[windows](#win)
Las preferencias de shell, las variables de entorno, los directorios de trabajo y los comandos que especifique para las sesiones en los nodos administrados de Windows Server.
Tipo: cadena
Requerido: no
[linux](#lin)
Las preferencias del intérprete de comandos, las variables de entorno, los directorios de trabajo y los comandos que especifique para las sesiones en los nodos administrados de Linux y macOS.
Tipo: cadena
Requerido: no
[parameters](#param)
Un objeto que define los parámetros que acepta el documento. Para obtener más información acerca de cómo definir los parámetros de los documentos, consulte **parámetros** en [Elementos de datos de nivel superior](documents-syntax-data-elements-parameters.md#top-level). En el caso de los parámetros a los que suele hacer referencia, le recomendamos almacenarlos en Systems Manager Parameter Store y, luego, hacer referencia a ellos. Puede hacer referencia a los parámetros de Parameter Store `String` y `StringList` en esta sección de un documento. No puede hacer referencia a los parámetros de Parameter Store `SecureString` en esta sección de un documento. Puede hacer referencia a un parámetro de Parameter Store mediante el siguiente formato.
```
{{ssm:parameter-name}}
```
Para obtener más información acerca de Parameter Store, consulte [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md).
Tipo: StringMap
Obligatorio: no
[properties](#props)
Un objeto cuyos valores especificados se utilizan en la operación `StartSession` de la API.
Para los documentos de Session que se utilizan para las sesiones `InteractiveCommands`, el objeto de propiedades incluye los comandos que se ejecutarán en los sistemas operativos que usted especifique. Además, puede determinar si los comandos se ejecutan como `root` mediante la propiedad booleana `runAsElevated`. Para obtener más información, consulte [Restricción del acceso a los comandos de una sesión](session-manager-restrict-command-access.md).
Para los documentos de Session que se utilizan para las sesiones `Port`, el objeto de propiedades contiene el número de puerto al que se debe redirigir el tráfico. Para ver un ejemplo, consulte más adelante en este tema el ejemplo de documento de Session de tipo `Port`.
Tipo: StringMap
Obligatorio: no
Ejemplo de documento de Session de tipo `Standard_Stream`
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to hold regional settings for Session Manager
sessionType: Standard_Stream
inputs:
s3BucketName: ''
s3KeyPrefix: ''
s3EncryptionEnabled: true
cloudWatchLogGroupName: ''
cloudWatchEncryptionEnabled: true
cloudWatchStreamingEnabled: true
kmsKeyId: ''
runAsEnabled: true
runAsDefaultUser: ''
idleSessionTimeout: '20'
maxSessionDuration: '60'
shellProfile:
windows: ''
linux: ''
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to hold regional settings for Session Manager",
"sessionType": "Standard_Stream",
"inputs": {
"s3BucketName": "",
"s3KeyPrefix": "",
"s3EncryptionEnabled": true,
"cloudWatchLogGroupName": "",
"cloudWatchEncryptionEnabled": true,
"cloudWatchStreamingEnabled": true,
"kmsKeyId": "",
"runAsEnabled": true,
"runAsDefaultUser": "",
"idleSessionTimeout": "20",
"maxSessionDuration": "60",
"shellProfile": {
"windows": "date",
"linux": "pwd;ls"
}
}
}
```
------
Ejemplo de documento de Session de tipo `InteractiveCommands`
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to view a log file on a Linux instance
sessionType: InteractiveCommands
parameters:
logpath:
type: String
description: The log file path to read.
default: "/var/log/amazon/ssm/amazon-ssm-agent.log"
allowedPattern: "^[a-zA-Z0-9-_/]+(.log)$"
properties:
linux:
commands: "tail -f {{ logpath }}"
runAsElevated: true
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to view a log file on a Linux instance",
"sessionType": "InteractiveCommands",
"parameters": {
"logpath": {
"type": "String",
"description": "The log file path to read.",
"default": "/var/log/amazon/ssm/amazon-ssm-agent.log",
"allowedPattern": "^[a-zA-Z0-9-_/]+(.log)$"
}
},
"properties": {
"linux": {
"commands": "tail -f {{ logpath }}",
"runAsElevated": true
}
}
}
```
------
Ejemplo de documento de Session de tipo `Port`
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Document to open given port connection over Session Manager
sessionType: Port
parameters:
paramExample:
type: string
description: document parameter
properties:
portNumber: anyPortNumber
```
------
#### [ JSON ]
```
{
"schemaVersion": "1.0",
"description": "Document to open given port connection over Session Manager",
"sessionType": "Port",
"parameters": {
"paramExample": {
"type": "string",
"description": "document parameter"
}
},
"properties": {
"portNumber": "anyPortNumber"
}
}
```
------
Ejemplo de documento de Session con caracteres especiales
------
#### [ YAML ]
```
---
schemaVersion: '1.0'
description: Example document with quotation marks
sessionType: InteractiveCommands
parameters:
Test:
type: String
description: Test Input
maxChars: 32
properties:
windows:
commands: |
$Test = '{{ Test }}'
$myVariable = \"Computer name is $env:COMPUTERNAME\"
Write-Host "Test variable: $myVariable`.`nInput parameter: $Test"
runAsElevated: false
```
------
#### [ JSON ]
```
{
"schemaVersion":"1.0",
"description":"Test document with quotation marks",
"sessionType":"InteractiveCommands",
"parameters":{
"Test":{
"type":"String",
"description":"Test Input",
"maxChars":32
}
},
"properties":{
"windows":{
"commands":[
"$Test = '{{ Test }}'",
"$myVariable = \\\"Computer name is $env:COMPUTERNAME\\\"",
"Write-Host \"Test variable: $myVariable`.`nInput parameter: $Test\""
],
"runAsElevated":false
}
}
}
```
------
# Resolución de problemas de Session Manager
Utilice la siguiente información como ayuda para solucionar problemas con AWS Systems Manager Session Manager.
**Topics**
+ [AccessDeniedException cuando se llama a la operación TerminateSession](#session-manager-troubleshooting-access-denied-exception)
+ [Se produjo un error inesperado en el proceso del documento: se agotó el tiempo de espera del operador documental.](#session-manager-troubleshooting-document-worker-timed-out)
+ [Session Manager no se puede conectar desde la consola de Amazon EC2](#session-manager-troubleshooting-EC2-console)
+ [Sin permiso para iniciar una sesión](#session-manager-troubleshooting-start-permissions)
+ [SSM Agent no está en línea](#session-manager-troubleshooting-agent-not-online)
+ [Sin permiso para cambiar preferencias de sesiones](#session-manager-troubleshooting-preferences-permissions)
+ [Nodo administrado no disponible o no configurado para Session Manager](#session-manager-troubleshooting-instances)
+ [Session ManagerComplemento de no encontrado](#plugin-not-found)
+ [Complemento de Session Manager no agregado de manera automática a la ruta de la línea de comandos (Windows)](#windows-plugin-env-var-not-set)
+ [Session ManagerEl complemento no responde](#plugin-unresponsive)
+ [TargetNotConnected](#ssh-target-not-connected)
+ [Aparece una pantalla en blanco después de iniciar una sesión](#session-manager-troubleshooting-start-blank-screen)
+ [El nodo administrado deja de responder durante las sesiones de larga ejecución](#session-manager-troubleshooting-log-retention)
+ [Se ha producido un error (InvalidDocument) al llamar a la operación StartSession](#session-manager-troubleshooting-invalid-document)
## AccessDeniedException cuando se llama a la operación TerminateSession
**Problema**: cuando se intenta terminar una sesión, Systems Manager devuelve el siguiente error:
```
An error occurred (AccessDeniedException) when calling the TerminateSession operation:
User: is not authorized to perform: ssm:TerminateSession on resource:
because no identity-based policy allows the ssm:TerminateSession action.
```
**Solución A: confirme que la [última versión del complemento de Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/plugin-version-history.html) esté instalada en el nodo.**
Introduzca el siguiente comando en el terminal y pulse Intro.
```
session-manager-plugin --version
```
**Solución B: instale o vuelva a instalar la última versión del complemento.**
Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md).
**Solución C: intente restablecer la conexión con el nodo.**
Compruebe que el nodo responda a las solicitudes. Intente restablecer la sesión. O, si es necesario, abra la consola de Amazon EC2 y compruebe el estado de la instancia en ejecución.
## Se produjo un error inesperado en el proceso del documento: se agotó el tiempo de espera del operador documental.
**Problema**: al iniciar una sesión en un host Linux, Systems Manager devuelve el siguiente error:
```
document process failed unexpectedly: document worker timed out,
check [ssm-document-worker]/[ssm-session-worker] log for crash reason
```
Si configuró el registro SSM Agent, como se describe en [Visualización de registros de SSM Agent](ssm-agent-logs.md), puede ver más detalles en el registro de depuración. En este caso, Session Manager muestra la siguiente entrada de registro:
```
failed to create channel: too many open files
```
Este error generalmente indica que hay demasiados procesos de trabajo de Session Manager en ejecución y que el sistema operativo subyacente ha alcanzado un límite. Tiene dos opciones para resolver este problema.
**Solución A: aumentar el límite de notificación de archivos del sistema operativo**
Para aumentar el límite, ejecute el siguiente comando desde un host Linux independiente. Este comando utiliza Run Command de Systems Manager. El valor especificado aumenta `max_user_instances` a 8192. Este valor es considerablemente superior al valor predeterminado de 128, pero no sobrecargará los recursos del host:
```
aws ssm send-command --document-name AWS-RunShellScript \
--instance-id i-02573cafcfEXAMPLE --parameters \
"commands=sudo sysctl fs.inotify.max_user_instances=8192"
```
**Solución B: reducir las notificaciones de archivos utilizadas por Session Manager en el host de destino**
Ejecute el siguiente comando desde un host Linux independiente para enumerar las sesiones que se ejecutan en el host de destino:
```
aws ssm describe-sessions --state Active --filters key=Target,value=i-02573cafcfEXAMPLE
```
Revise la salida del comando para identificar las sesiones que ya no se necesitan. Puede terminar esas sesiones mediante la ejecución del siguiente comando desde un host Linux independiente:
```
aws ssm terminate-session —session-id session ID
```
Opcionalmente, una vez que no haya más sesiones en ejecución en el servidor remoto, podrá liberar recursos adicionales mediante la ejecución del siguiente comando desde un host Linux independiente. Este comando termina todos los procesos de Session Manager que se ejecutan en el host remoto y, en consecuencia, todas las sesiones con el host remoto. Antes de ejecutar este comando, verifique que no haya sesiones en curso que desee conservar:
```
aws ssm send-command --document-name AWS-RunShellScript \
--instance-id i-02573cafcfEXAMPLE --parameters \
'{"commands":["sudo kill $(ps aux | grep ssm-session-worker | grep -v grep | awk '"'"'{print $2}'"'"')"]}'
```
## Session Manager no se puede conectar desde la consola de Amazon EC2
**Problema**: luego de crear una instancia nueva, en el botón **Conectar** > en la pestaña **Administrador de sesiones** de la consola de Amazon Elastic Compute Cloud (Amazon EC2) no aparece la opción para conectarse.
**Solución A: creación de un perfil de instancia**. Si aún no lo ha hecho (tal y como se indica en la información de la pestaña **Administrador de sesiones** de la consola de EC2), cree un perfil de instancia de AWS Identity and Access Management (IAM) mediante Quick Setup. Quick Setup es una herramienta de AWS Systems Manager.
Session Manager requiere un perfil de instancia de IAM para conectarse a la instancia. Puede crear un perfil de instancia y asignarlo a la instancia mediante la creación de una [configuración de administración de host](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-host-management.html) conQuick Setup. Una *configuración de administración de host* crea un perfil de instancia con los permisos necesarios y lo asigna a la instancia. Una configuración de administración de host también habilita otras herramientas de Systems Manager y crea roles de IAM para ejecutar esas herramientas. El uso de Quick Setup o de las herramientas habilitadas por la configuración de administración de host es gratuito. [Abra Quick Setup y cree una configuración de administración de host](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt).
**importante**
Luego de crear la configuración de administración de host, Amazon EC2 puede tardar varios minutos en registrar el cambio y actualizar la pestaña **Administrador de sesiones**. Si la pestaña no muestra el botón **Conectar** después de dos o tres minutos, actualice su instancia. Si sigue sin ver la opción para conectarse, abra [Configuración Rápida](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt) y verifique que solo tenga una configuración de administración de hosts. Si hay dos, elimine la configuración anterior y espere unos minutos.
Si sigue sin poder conectarse después de crear una configuración de administración de host o si se produce un error, incluido un error relacionado con SSM Agent, consulte una de las siguientes soluciones:
+ [Solución B: no hay un error, pero aún no se puede conectar](#session-manager-troubleshooting-EC2-console-no-error)
+ [Solución C: error por la falta del SSM Agent](#session-manager-troubleshooting-EC2-console-no-agent)
### Solución B: no hay un error, pero aún no se puede conectar
Si creó la configuración de administración de host, esperó varios minutos antes de intentar conectarse y sigue sin poder hacerlo, es posible que tenga que aplicar de manera manual la configuración de administración de host a la instancia. Utilice el siguiente procedimiento para actualizar la configuración de administración de host con Quick Setup y aplicar los cambios a una instancia.
**Actualización de una configuración de administración de host mediante Quick Setup**
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 **Quick Setup**.
1. En la lista **Configuraciones**, elija la configuración **Administración de host** que creó.
1. Elija **Acciones**y, luego, seleccione **Editar configuración**.
1. Cerca de la parte inferior de la sección **Objetivos**, en **Elija cómo desea segmentar las instancias**, seleccione **Manual**.
1. En la sección **Instancias**, elija la instancia que creó.
1. Elija **Actualizar**.
Espere unos minutos a que EC2 actualice la pestaña **Administrador de sesiones**. Si sigue sin poder conectarse o si se produce un error, revise las demás soluciones para este problema.
### Solución C: error por la falta del SSM Agent
Si no pudo crear una configuración de administración de host con Quick Setup o si se produjo un error que indicaba que SSM Agent no estaba instalado, es posible que deba instalar SSM Agent de manera manual en la instancia. SSM Agent es un software de Amazon que permite a Systems Manager conectarse a la instancia medianteSession Manager. SSM Agent está instalado de forma predeterminada en la mayoría de las imágenes de máquina de Amazon (AMI). Si la instancia se creó a partir de una AMI no estándar o una AMI anterior, es posible que deba instalar el agente de manera manual. Para conocer el procedimiento de instalación de SSM Agent, consulte el siguiente tema correspondiente al sistema operativo de la instancia.
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
+ [AlmaLinux](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-alma.html)
+ [Amazon Linux 2 y AL2023](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-al2.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-oracle.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-oracle.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rhel.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rhel.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rocky.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-rocky.html)
+ [https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-ubuntu.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-ubuntu.html)
Si se presentan problemas con SSM Agent, consulte [Resolución de problemas de SSM Agent](troubleshooting-ssm-agent.md).
## Sin permiso para iniciar una sesión
**Problema**: intenta iniciar una sesión, pero el sistema le indica que no tiene los permisos necesarios.
+ **Solución**: un administrador de sistema no le ha concedido los permisos de política de AWS Identity and Access Management (IAM) para iniciar sesiones de Session Manager. Para obtener información, consulte [Control del acceso de las sesiones de usuario a las instancias](session-manager-getting-started-restrict-access.md).
## SSM Agent no está en línea
**Problema**: ve un mensaje en la pestaña **Session Manager** de la instancia de Amazon EC2 que indica: “SSM Agent no está en línea. El SSM Agent no pudo conectarse a un punto de conexión de Systems Manager para registrarse en el servicio”.
**Solución**: SSM Agent es un software de Amazon que se ejecuta en instancias de Amazon EC2 para que Session Manager pueda conectarse a ellas. Si ve este error, significa SSM Agent no puede establecer una conexión con el punto de conexión de Systems Manager. Los posibles orígenes del problema podrían estar en las restricciones del firewall, en los problemas de enrutamiento o la falta de conectividad a Internet. Para resolver esta situación, investigue los problemas de conectividad de la red. Para obtener más información, consulte [Resolución de problemas de SSM Agent](troubleshooting-ssm-agent.md) y [Solución de problemas de disponibilidad de nodos administrados](fleet-manager-troubleshooting-managed-nodes.md). Para obtener información sobre los puntos de conexión de Systems Manager, consulte [Cuotas y puntos de conexión de AWS Systems Manager](https://docs.aws.amazon.com/general/latest/gr/ssm.html) en la Referencia general de AWS.
## Sin permiso para cambiar preferencias de sesiones
**Problema**: intenta actualizar las preferencias de sesión globales para su organización, pero el sistema le indica que no tiene los permisos necesarios para hacerlo.
+ **Solución**: un administrador de sistema no le ha concedido los permisos de política de IAM para configurar las preferencias de Session Manager. Para obtener más información, consulte [Concesión o denegación de permisos de usuario para actualizar preferencias de Session Manager](preference-setting-permissions.md).
## Nodo administrado no disponible o no configurado para Session Manager
**Problema 1**: desea iniciar una sesión en la página de la consola **Start a session** (Iniciar una sesión), pero un nodo administrado no está en la lista.
+ **Solución A**: El nodo administrado al que desea conectarse podría no haberse configurado para AWS Systems Manager. Para obtener más información, consulte [Cómo configurar la consola unificada de Systems Manager para una organización](systems-manager-setting-up-organizations.md).
**nota**
Si AWS Systems Manager SSM Agent ya se está ejecutando en un nodo administrado cuando adjunte el perfil de instancias de IAM, es posible que tenga que reiniciar el agente antes de que la instancia aparezca en la página **Start a session** (Iniciar una sesión) de la consola.
+ **Solución B**: la configuración del proxy que aplicó a SSM Agent en el nodo administrado puede ser incorrecta. Si la configuración del proxy es incorrecta, el nodo administrado no podrá alcanzar los puntos de conexión de servicio necesarios o el nodo se podría notificar como un sistema operativo diferente a Systems Manager. Para obtener más información, consulte [Configuración de SSM Agent para utilizar un proxy en nodos de Linux](configure-proxy-ssm-agent.md) y [Configurar el SSM Agent para usar un proxy para las instancias de Windows Server](configure-proxy-ssm-agent-windows.md).
**Problema 2**: un nodo administrado al que desea conectarse está en la lista de la página **Start a session** (Iniciar una sesión) de la consola, pero la página notifica que “The instance you selected isn't configured to use Session Manager” (La instancia que ha seleccionado no está configurada para utilizar Session Manager).
+ **Solución A**: el nodo administrado se ha configurado para usarse con el servicio de Systems Manager, pero el perfil de instancias de IAM adjunto al nodo podría no incluir los permisos para la herramienta Session Manager. Para obtener información, consulte [Verificación o creación de un perfil de instancias de IAM con permisos de Session Manager](session-manager-getting-started-instance-profile.md).
+ **Solución B**: el nodo administrado no está ejecutando una versión de SSM Agent que admita Session Manager. Actualice SSM Agent en el nodo a la versión 2.3.68.0 o una posterior.
Actualice SSM Agent de forma manual en un nodo administrado siguiendo los pasos que se describen en [Cómo instalar y desinstalar de forma manual SSM Agent en instancias de EC2 para Windows Server](manually-install-ssm-agent-windows.md), [Instalación y desinstalación manual de SSM Agent en instancias de EC2 para Linux](manually-install-ssm-agent-linux.md) o [Instalación y desinstalación manual de SSM Agent en instancias de EC2 para macOS](manually-install-ssm-agent-macos.md), en función del sistema operativo.
También puede usar el documento de Run Command `AWS-UpdateSSMAgent` para actualizar la versión del agente en una o varios nodos administrados a la vez. Para obtener más información, consulte [Actualización de SSM Agent mediante Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
**sugerencia**
Para mantener siempre actualizado el agente, le recomendamos actualizar el SSM Agent a la versión más reciente según un programa automatizado que defina utilizando cualquiera de los siguientes métodos:
Ejecutar `AWS-UpdateSSMAgent` como parte de una asociación de State Manager. Para obtener más información, consulte [Tutorial: actualización automática de SSM Agent con AWS CLI](state-manager-update-ssm-agent-cli.md).
Ejecute `AWS-UpdateSSMAgent` como parte de un periodo de mantenimiento. Para obtener información acerca de cómo trabajar con periodos de mantenimiento, consulte [Crear y administrar periodos de mantenimiento mediante la consola](sysman-maintenance-working.md) y [Tutorial: cree y configure un periodo de mantenimiento mediante la AWS CLI](maintenance-windows-cli-tutorials-create.md).
+ **Solución C**: el nodo administrado no puede alcanzar los puntos de conexión de servicio requeridos. Puede mejorar la posición de seguridad de los nodos administrados mediante el uso de puntos de conexión de interfaz con tecnología AWS PrivateLink para conectarse a los puntos de conexión de Systems Manager. La alternativa a usar un punto de conexión de interfaz es permitir el acceso a Internet saliente en los nodos administrados. Para obtener más información, consulte [Uso de PrivateLink para configurar un punto de enlace de la VPC para Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html).
+ **Solución D**: el nodo administrado dispone de recursos de memoria o CPU limitados. Aunque el nodo administrado podría de otro modo ser funcional, si el nodo no tiene suficientes recursos disponibles, no podrá establecer una sesión. Para obtener más información, consulte [Solución de problemas de una instancia inaccesible](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html).
## Session ManagerComplemento de no encontrado
Para utilizar la AWS CLI para ejecutar comandos de sesión, el complemento de Session Manager también debe estar instalado en su equipo local. Para obtener más información, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md).
## Complemento de Session Manager no agregado de manera automática a la ruta de la línea de comandos (Windows)
Cuando instala el complemento de Session Manager en Windows, el archivo ejecutable `session-manager-plugin` debería agregarse de forma automática a la variable de entorno `PATH` del sistema operativo. Si el comando no funciona después de ejecutarlo para verificar si el complemento de Session Manager se ha instalado correctamente (`aws ssm start-session --target instance-id`), es posible que deba configurarlo de forma manual mediante el procedimiento que se indica a continuación.
**Para modificar la variable PATH (Windows)**
1. Pulse la tecla de Windows e ingrese **environment variables**.
1. Elija **Edit environment variables for your account (Edición de las variables de entorno de esta cuenta)**.
1. Elija **PATH** y después **Editar**.
1. Añada rutas al campo **Variable value (Valor de variable)**, separadas por punto y coma, como se muestra en este ejemplo: *`C:\existing\path`*;*`C:\new\path`*
*`C:\existing\path`* representa el valor que ya está en el campo. *`C:\new\path`* representa la ruta que desea añadir, como se muestra en el siguiente ejemplo.
+ **64-Máquinas de 64 bits**: `C:\Program Files\Amazon\SessionManagerPlugin\bin\`
1. Elija **OK (Aceptar)** dos veces para aplicar la nueva configuración.
1. Cierre los símbolos del sistema en ejecución y vuelva a abrirlos.
## Session ManagerEl complemento no responde
Durante una sesión de remisión de puertos, el tráfico podría dejar de remitirse si tiene un software antivirus instalado en el equipo local. En algunos casos, el software antivirus interfiere con el complemento de Session Manager que causa interbloqueos en el proceso. Para resolver este problema, permita o excluya el complemento de Session Manager del software antivirus. Para obtener información sobre la ruta de instalación predeterminada para el complemento de Session Manager, consulte [Instalación del complemento de Session Manager para la AWS CLI](session-manager-working-with-install-plugin.md).
## TargetNotConnected
**Problema**: intenta iniciar una sesión, pero el sistema devuelve el mensaje de error “An error occurred (TargetNotConnected) when calling the StartSession operation: *InstanceID* isn't connected” (Se produjo un error [DestinoNoConectado] al llamar a la operación StartSession: el ID de la instancia no está conectado).
+ **Solución A**: este error se devuelve cuando el nodo administrado de destino especificado para la sesión no está completamente configurado para su uso con Session Manager. Para obtener más información, consulte [Configuración de Session Manager](session-manager-getting-started.md).
+ **Solución B**: este error también se devuelve si intenta iniciar una sesión en un nodo administrado que se encuentra en otra Cuenta de AWS o Región de AWS.
## Aparece una pantalla en blanco después de iniciar una sesión
**Problema**: ha iniciado una sesión y Session Manager muestra una pantalla en blanco.
+ **Solución A**: este problema puede darse cuando el volumen raíz del nodo administrado está lleno. Debido a la falta de espacio en disco, el SSM Agent ya no funciona en el nodo. Para resolver este problema, utilice Amazon CloudWatch para recopilar las métricas y los registros de los sistemas operativos. Para obtener información, consulte [Recopilación de métricas, registros y seguimientos con el agente de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) en la *Guía del usuario de Amazon CloudWatch*.
+ **Solución B**: puede aparecer una pantalla en blanco si accedió a la consola mediante un enlace que incluye un par de punto de enlace y región que no coinciden. Por ejemplo, en la siguiente dirección URL de la consola, `us-west-2` es el punto de enlace especificado, pero `us-west-1` es la Región de AWS especificada.
```
https://us-west-2.console.aws.amazon.com/systems-manager/session-manager/sessions?region=us-west-1
```
+ **Solución C**: el nodo administrado se conecta a Systems Manager mediante los puntos de conexión de la VPC, y las preferencias de Session Manager registran la salida de la sesión en un bucket de Amazon S3 o en grupo de Registros de Amazon CloudWatch, pero no existe ningún punto de conexión de la puerta de enlace de `s3` ni un punto de conexión de la interfaz de `logs` en la VPC. Se necesita un punto de conexión de `s3` con el formato **`com.amazonaws.region.s3`** si los nodos administrados se conectan a Systems Manager mediante puntos de conexión de la VPC y sus preferencias de Session Manager escriben la salida de la sesión en un bucket de Amazon S3. De manera alternativa, se requiere un punto de conexión de `logs` con el formato **`com.amazonaws.region.logs`** si los nodos administrados se conectan a Systems Manager mediante los puntos de conexión de la VPC, y sus preferencias de Session Manager registran la salida de la sesión en un grupo de Registros de CloudWatch. Para obtener más información, consulte [Creación de puntos de enlace de la VPC para Systems Manager](setup-create-vpc.md#create-vpc-endpoints).
+ **Solución D**: se ha eliminado el grupo de registros o el bucket de Amazon S3 que especificó en sus preferencias de sesión. Para resolver este problema, actualice sus preferencias de sesión con un grupo de registros o un bucket de S3 válidos.
+ **Solución E**: el grupo de registros o el bucket de Amazon S3 que especificó en sus preferencias de sesión no está cifrado, pero ha establecido el elemento de entrada `cloudWatchEncryptionEnabled` o `s3EncryptionEnabled` en `true`. Para resolver este problema, actualice sus preferencias de sesión con un grupo de registros o un bucket de Amazon S3 que estén cifrados o establezca el elemento de entrada `cloudWatchEncryptionEnabled` o `s3EncryptionEnabled` en `false`. Este escenario solo se aplica a los clientes que crean preferencias de sesión mediante las herramientas de línea de comandos.
## El nodo administrado deja de responder durante las sesiones de larga ejecución
**Problema**: el nodo administrado deja de responder o se bloquea durante una sesión de larga ejecución.
**Solución**: reducir la duración de la retención de registros de SSM Agent para Session Manager.
**Para reducir la duración de la retención de registros de SSM Agent de las sesiones**
1. Busque `amazon-ssm-agent.json.template` en el directorio `/etc/amazon/ssm/` para Linux o `C:\Program Files\Amazon\SSM` para Windows.
1. Copie el contenido de `amazon-ssm-agent.json.template` en un nuevo archivo dentro del mismo directorio denominado `amazon-ssm-agent.json`.
1. Disminuya el valor predeterminado de `SessionLogsRetentionDurationHours` en la propiedad de `SSM` y guarde el archivo.
1. Restablecer el SSM Agent.
## Se ha producido un error (InvalidDocument) al llamar a la operación StartSession
**Problema**: Aparece el siguiente error al iniciar una sesión empleando la AWS CLI.
```
An error occurred (InvalidDocument) when calling the StartSession operation: Document type: 'Command' is not supported. Only type: 'Session' is supported for Session Manager.
```
**Solución**: El documento SSM que especificó para el parámetro `--document-name` no es un documento *Session*. Utilice el siguiente procedimiento para ver una lista de documentos Session en la Consola de administración de AWS.
**Para ver una lista de documentos Session**
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 **Documentos**.
1. En la lista **Categorías**, seleccione **Documentos Session**.
# AWS Systems Manager State Manager
State Manager, una herramienta de AWS Systems Manager, es un servicio de administración de configuración seguro y escalable que automatiza el proceso de mantener los nodos administrados y otros recursos de AWS en el estado que defina. Para comenzar a utilizar State Manager, abra la [consola de Systems Manager](https://console.aws.amazon.com//systems-manager/state-manager). En el panel de navegación, elija **State Manager**.
**nota**
State Manager y Maintenance Windows pueden realizar algunos tipos similares de actualizaciones en los nodos administrados. La opción que elija dependerá de si necesita automatizar la conformidad del sistema o realizar tareas de alta prioridad y urgencia durante los periodos que especifique.
Para obtener más información, consulte [Elección entre State Manager y Maintenance Windows](state-manager-vs-maintenance-windows.md).
## ¿Cómo puede State Manager beneficiar a mi organización?
Mediante documentos de Systems Manager previamente configurados (documentos de SSM), State Manager ofrece los siguientes beneficios para la administración de nodos:
+ Arrancar nodos con software específico en el inicio.
+ Descargar y actualizar agentes en una programación definida, incluido SSM Agent.
+ Configure los valores de red.
+ Unir nodos a un dominio de Microsoft Active Directory.
+ Ejecute scripts en nodos administrados de Linux, macOS y Windows Server a lo largo de su ciclo de vida.
Para administrar la desviación de la configuración entre otros recursos de AWS, puede utilizar Automatización, una herramienta de Systems Manager, con State Manager para llevar a cabo los siguientes tipos de tareas:
+ Adjuntar un rol de Systems Manager a las instancias de Amazon Elastic Compute Cloud (Amazon EC2) para transformarlas en *nodos administrados*.
+ aplicar las reglas de entrada y salida que desee para un grupo de seguridad
+ crear o eliminar copias de seguridad de Amazon DynamoDB
+ crear o eliminar instantáneas de Amazon Elastic Block Store (Amazon EBS)
+ desactivar los permisos de lectura y escritura en los buckets de Amazon Simple Storage Service (Amazon S3)
+ Iniciar, reiniciar o detener los nodos administrados y las instancias de Amazon Relational Database Service (Amazon RDS).
+ aplicar revisiones a las AMIs de Linux, macOS y Windows
Para obtener información acerca del uso de State Manager con manuales de procedimientos de Automation, consulte [Programación de automatizaciones con asociaciones de State Manager](scheduling-automations-state-manager-associations.md).
## ¿Quién debe utilizar State Manager?
State Manager es una solución adecuada para cualquier cliente de AWS que quiera mejorar la administración y la gobernanza de sus recursos de AWS y reducir la desviación de la configuración.
## ¿Cuáles son las características de State Manager?
Estas son algunas de las características clave de State Manager:
+
**Asociaciones de State Manager**
Una *asociación* de State Manager es una configuración que asigna a sus recursos de AWS. La configuración define el estado que desea mantener en los recursos. Por ejemplo, una asociación puede especificar que el software antivirus debe estar instalado y ejecutándose en un nodo administrado, o bien que determinados puertos deben estar cerrados.
Una asociación especifica una programación del momento en que aplicar la configuración y los destinos para la asociación. Por ejemplo, una asociación para software antivirus puede ejecutarse una vez al día en todos los nodos administrados de una Cuenta de AWS. Si el software no está instalado en un nodo, la asociación podría exigir a State Manager que lo instale. Si el software está instalado, pero el servicio no se está ejecutando, la asociación podría exigir a State Manager que inicie el servicio.
+
**Opciones de programación flexibles**
State Manager ofrece las siguientes opciones de programación cuando se ejecuta una asociación:
+ **Procesamiento inmediato o retrasado**
Al crear una asociación, de forma predeterminada, el sistema la ejecuta de inmediato en los recursos especificados. Después de la ejecución inicial, la asociación se ejecuta en intervalos de acuerdo con la programación que definió.
Puede exigir a State Manager que no ejecute una asociación inmediatamente mediante la opción **Apply association only at the next specified Cron interval** (Aplicar la asociación solo en el siguiente intervalo cron especificado) de la consola o el parámetro `ApplyOnlyAtCronInterval` de la línea de comandos.
+ **Expresiones cron y rate**
Al crear una asociación, especifica una programación para el momento en que State Manager aplica la configuración. State Manager admite la mayoría de expresiones cron y rate estándar para programar el momento en que se ejecuta una asociación. State Manager también admite expresiones cron que incluyen un día de la semana y el signo de número (\$1) para designar el día *x* de un mes para ejecutar una asociación y el signo (L) para indicar el último día *X* del mes.
**nota**
State Manager actualmente no admite especificar meses en expresiones cron para asociaciones.
Para tener un mayor control sobre el momento en el que se ejecuta una asociación, por ejemplo, si desea ejecutar una asociación dos días después de la revisión del martes, puede especificar un desplazamiento. Un *desplazamiento* define los días que hay que esperar después del día programado para ejecutar una asociación.
Para obtener información acerca de cómo crear expresiones cron y rate, consulte [Referencia: expresiones cron y rate para Systems Manager](reference-cron-and-rate-expressions.md).
+
**Varias opciones de destino**
Una asociación especifica también sus destinos. State Manager admite indicar los destinos de los recursos de AWS mediante etiquetas, Grupos de recursos de AWS, ID de nodos individuales o todos los nodos administrados de la Región de AWS y la Cuenta de AWS actuales.
+
**Compatibilidad con Amazon S3**
Almacene la salida del comando de las ejecuciones de asociaciones en el bucket de Amazon S3 de su elección. Para obtener más información, consulte [Trabajo con asociaciones en Systems Manager](state-manager-associations.md).
+
**Compatibilidad con EventBridge**
Esta herramienta de Systems Manager se admite como un tipo de *evento* y un tipo de *destino* en las reglas de Amazon EventBridge. Para obtener más información, consulte [Cómo monitorear eventos de Systems Manager con Amazon EventBridge](monitoring-eventbridge-events.md) y [Referencia: patrones y tipos de eventos de Amazon EventBridge para Systems Manager](reference-eventbridge-events.md).
## ¿Se cobra por usar State Manager?
State Manager está disponible sin costo adicional.
**Topics**
+ [¿Cómo puede State Manager beneficiar a mi organización?](#state-manager-benefits)
+ [¿Quién debe utilizar State Manager?](#state-manager-who)
+ [¿Cuáles son las características de State Manager?](#state-manager-features)
+ [¿Se cobra por usar State Manager?](#state-manager-cost)
+ [Funcionamiento de State Manager](state-manager-about.md)
+ [Trabajo con asociaciones en Systems Manager](state-manager-associations.md)
+ [Cómo crear asociaciones que ejecutan archivos MOF](systems-manager-state-manager-using-mof-file.md)
+ [Creación de asociaciones que ejecuten manuales de estrategia de Ansible](systems-manager-state-manager-ansible.md)
+ [Creación de asociaciones que ejecuten recetas de Chef](systems-manager-state-manager-chef.md)
+ [Tutorial: actualización automática de SSM Agent con AWS CLI](state-manager-update-ssm-agent-cli.md)
+ [Tutorial: actualización automática de los controladores PV en las instancias de EC2 de Windows Server](state-manager-update-pv-drivers.md)
**Más información**
+ [Combatir la desviación de la configuración con Amazon EC2 Systems Manager y Windows PowerShell DSC](https://aws.amazon.com/blogs/mt/combating-configuration-drift-using-amazon-ec2-systems-manager-and-windows-powershell-dsc/)
+ [Configure Amazon EC2 Instances in an Auto Scaling Group Using (Configuración de instancias de Amazon EC2 en un grupo de escalado automáticomediante State Manager State Manager](https://aws.amazon.com/blogs/mt/configure-amazon-ec2-instances-in-an-auto-scaling-group-using-state-manager/)
# Funcionamiento de State Manager
State Manager, una herramienta de AWS Systems Manager, es un servicio seguro y escalable que automatiza el proceso de mantener los nodos administrados en una infraestructura [híbrida y multinube](operating-systems-and-machine-types.md#supported-machine-types) en el estado que defina.
Así es como funciona State Manager:
**1. Determine el estado que desea aplicar a sus recursos de AWS.**
¿Desea garantizar que los nodos administrados estén configurados con aplicaciones específicas, como, por ejemplo, las aplicaciones antivirus o malware? ¿Desea automatizar el proceso de actualización de SSM Agent u otros paquetes de AWS como `AWSPVDriver`? ¿Necesita garantizar que los puertos específicos se cierren o abran? Para comenzar a utilizar State Manager, determine el estado que desea aplicar a los recursos de AWS. El estado que desea aplicar determina qué documento de SSM se utiliza para crear una asociación de State Manager.
Una *asociación* de State Manager es una configuración que asigna a sus recursos de AWS. La configuración define el estado que desea mantener en los recursos. Por ejemplo, una asociación puede especificar que el software antivirus debe estar instalado y ejecutándose en un nodo administrado, o bien que determinados puertos deben estar cerrados.
Una asociación especifica una programación del momento en que aplicar la configuración y los destinos para la asociación. Por ejemplo, una asociación para software antivirus puede ejecutarse una vez al día en todos los nodos administrados de una Cuenta de AWS. Si el software no está instalado en un nodo, la asociación podría exigir a State Manager que lo instale. Si el software está instalado, pero el servicio no se está ejecutando, la asociación podría exigir a State Manager que inicie el servicio.
**2. Determine si un documento de SSM preconfigurado puede ayudarlo a crear el estado deseado en los recursos de AWS.**
Systems Manager incluye decenas de documentos de SSM preconfigurados que puede utilizar para crear una asociación. Los documentos preconfigurados están listos para llevar a cabo tareas comunes, como instalar aplicaciones, configurar Amazon CloudWatch, ejecutar automatizaciones de AWS Systems Manager, ejecutar scripts de PowerShell y Shell, y unir nodos administrados a un dominio de Directory Service para Active Directory.
Puede ver todos los documentos de SSM en la [consola de Systems Manager](https://console.aws.amazon.com/systems-manager/documents). Elija el nombre de un documento para obtener más información acerca de cada uno de ellos. A continuación, se incluyen dos ejemplos: [https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description](https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description) y [https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description](https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description).
**3. Cree una asociación.**
Puede crear una asociación mediante la consola de Systems Manager, AWS Command Line Interface (AWS CLI), AWS Tools for Windows PowerShell (Tools for Windows PowerShell) o la API de Systems Manager. Al crear una asociación, debe especificar la siguiente información:
+ Un nombre para la asociación.
+ Los parámetros del documento de SSM (por ejemplo, la ruta a la aplicación que desee instalar o el script que se va a ejecutar en los nodos).
+ Destinos para la asociación. Puede definir el destino de los nodos administrados especificando etiquetas, eligiendo identificadores de nodo individuales o eligiendo un grupo en Grupos de recursos de AWS. También puede definir el destino de *todos* los nodos administrados en la Región de AWS y la Cuenta de AWS actuales. Si sus destinos incluyen más de 1000 nodos, el sistema utiliza un mecanismo de limitación horaria. Esto significa que es posible que vea imprecisiones en el recuento de agregación de estados, ya que este proceso se ejecuta por hora y solo cuando cambia el estado de ejecución de un nodo.
+ El rol que utiliza la asociación para realizar acciones en su nombre. State Manager asumirá este rol y llamará a las API necesarias cuando se envíen las configuraciones a los nodos. Para obtener más información sobre la configuración del rol proporcionado personalizado, consulte [Configuración de roles para `AssociationDispatchAssumeRole`](#setup-assume-role). Si no se proporciona ningún rol, se utilizará el [rol vinculado al servicio para Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/using-service-linked-roles.html).
**nota**
Se recomienda que defina un rol de IAM personalizado para tener el control total sobre los permisos que dispone State Manager a la hora de realizar acciones en su nombre.
La compatibilidad de los roles vinculados a servicios en State Manager se está eliminando gradualmente. Es posible que las asociaciones que dependen de un rol vinculado al servicio necesiten actualizaciones en el futuro para seguir funcionando correctamente.
Para obtener información sobre cómo administrar el uso del rol proporcionado personalizado, consulte [Administración del uso de AssociationDispatchAssumeRole con `ssm:AssociationDispatchAssumeRole`](#context-key-assume-role).
+ Una programación para indicar cuándo o con qué frecuencia se aplicará el estado. Puede especificar una expresión cron o rate. Para obtener más información acerca de la creación de programas usando expresiones Cron y Rate, consulte [Expresiones cron y rate para asociaciones](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association).
**nota**
State Manager actualmente no admite especificar meses en expresiones cron para asociaciones.
Cuando ejecuta el comando para crear la asociación, Systems Manager vincula la información que se especifica (programación, destinos, documento de SSM y parámetros) a los recursos de destino. El estado de la asociación inicialmente muestra Pending (Pendiente) pues el sistema intenta llegar a todos los destinos y aplicar *inmediatamente* el estado especificado en la asociación.
Si crea una nueva asociación que está programada para ejecutarse mientras todavía se está ejecutando una asociación anterior, se agota el tiempo de espera de la asociación y se ejecuta la nueva asociación.
Systems Manager indica el estado de la solicitud para crear asociaciones en los recursos. Puede consultar los detalles de estado en la consola o, en el caso de los nodos administrados, mediante la operación [DescribeInstanceAssociationsStatus](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceAssociationsStatus.html) de la API. Si elige escribir el resultado del comando en Amazon Simple Storage Service (Amazon S3) cuando crea una asociación, también podrá consultar el resultado en el bucket de Simple Storage Service (Amazon S3) que haya especificado.
Para obtener más información, consulte [Trabajo con asociaciones en Systems Manager](state-manager-associations.md).
Las operaciones de la API que inicia el documento SSM durante la ejecución de una asociación no se registran en AWS CloudTrail.
**4. Monitorización y actualización.**
Después de crear la asociación, State Manager vuelve a aplicar la configuración de acuerdo con la programación definida en la asociación. Puede ver el estado de sus asociaciones en la [página de State Manager](https://console.aws.amazon.com/systems-manager/state-manager) de la consola o llamando directamente al ID de asociación generado por Systems Manager cuando creó dicha asociación. Para obtener más información, consulte [Visualización de los historiales de asociación](state-manager-associations-history.md). Puede actualizar los documentos de asociación y volver a aplicarlos según sea necesario. También puede crear varias versiones de una asociación. Para obtener más información, consulte [Cómo editar y crear una nueva versión de una asociación](state-manager-associations-edit.md).
## Cómo saber cuándo se aplican las asociaciones a los recursos
Cuando crea una asociación, especifica un documento de SSM que define la configuración, una lista de recursos de destino y una programación para aplicar la configuración. De manera predeterminada, State Manager ejecuta la asociación cuando se crea, y luego según su programación. State Manager también intenta ejecutar la asociación en las siguientes situaciones:
+ **Edición de asociación**: State Manager ejecuta la asociación después de que un usuario edite y guarde los cambios realizados en cualquiera de los siguientes campos de la asociación: `DOCUMENT_VERSION`, `PARAMETERS`, `SCHEDULE_EXPRESSION`, `OUTPUT_S3_LOCATION`.
+ **Edición de documento**: State Manager ejecuta la asociación después de que un usuario edite y guarde los cambios realizados en el documento SSM que define el estado de configuración de la asociación. Concretamente, la asociación se ejecuta después de realizar las siguientes ediciones en el documento:
+ Un usuario especifica una nueva versión del documento `$DEFAULT` y la asociación se creó utilizando la versión `$DEFAULT`.
+ Un usuario actualiza un documento y la asociación se creó utilizando la versión `$LATEST`.
+ Un usuario elimina el documento que se especificó cuando se creó la asociación.
+ **Inicio manual**: State Manager ejecuta la asociación cuando la inicia el usuario desde la consola de Systems Manager o mediante programación.
+ **Cambios de destino**: State Manager ejecuta la asociación después de que se produzca alguna de las siguientes actividades en un nodo de destino:
+ Un nodo administrado se conecta por primera vez.
+ Un nodo administrado se conecta después de perder una ejecución de asociación programada.
+ Un nodo administrado se conecta después de haber estado detenido durante más de 30 días.
**nota**
State Manager no supervisa los documentos o paquetes utilizados en las asociaciones entre Cuentas de AWS. Si actualiza un documento o paquete en una cuenta, la actualización no hará que la asociación se ejecute en la segunda cuenta. Debe ejecutar la asociación de forma manual en la segunda cuenta.
**Cómo impedir que las asociaciones se ejecuten cuando cambia un destino**
En algunos casos, es posible que no quiera que una asociación se ejecute cuando un destino formado por nodos gestionados cambia, sino únicamente de acuerdo con la programación especificada.
**nota**
La ejecución de un manual de procedimientos de automatización tiene un costo. Si la asociación con un manual de procedimientos de automatización se dirige a todas las instancias de su cuenta y lanza un gran número de instancias con regularidad, el manual de procedimientos se ejecuta en cada una de las instancias cuando se lanza. Esto puede provocar un aumento de los gastos de automatización.
Para evitar que se ejecute una asociación cuando cambian los destinos de esa asociación, seleccione la **casilla Aplicar la asociación solo en el siguiente intervalo cron especificado**. Esta casilla se encuentra en el área **Especificar programación** de las páginas **Crear asociación** y **Editar asociación**.
Esta opción se aplica a las asociaciones que incorporan un manual de procedimientos de automatización o un documento de SSM.
## Acerca de las actualizaciones de destino con los manuales de procedimientos de Automatización
Para que las asociaciones que se crean con los manuales de procedimientos de Automatización se apliquen cuando se detecten nuevos nodos de destino, se deben cumplir las siguientes condiciones:
+ La asociación debe haberla creado una configuración de [Quick Setup](systems-manager-quick-setup.md). Quick Setup es una herramienta de AWS Systems Manager. Actualmente, no se admiten asociaciones creadas por otros procesos.
+ El manual de procedimientos de Automatización se debe dirigir explícitamente al tipo de recurso `AWS::EC2::Instance` o `AWS::SSM::ManagedInstance`.
+ La asociación debe especificar los parámetros y los destinos.
En la consola, los campos **Parámetro** y **Destinos** se muestran al seleccionar una ejecución de control de velocidad.
![\[Las opciones de parámetros y destinos se presentan en la consola para las ejecuciones del control de velocidad\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/sm_Rate_control_execution_options.png)
Cuando use las acciones [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociation.html), [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociationBatch.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateAssociationBatch.html) o [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html) de la API, puede especificar estos valores con las entradas `AutomationTargetParameterName` y `Targets`. En cada una de estas acciones de la API, también puede configurar el parámetro `ApplyOnlyAtCronInterval` en `true` para evitar que la asociación se ejecute cada vez que cambia un destino.
Para obtener información sobre el uso de la consola para controlar cuándo se ejecutan las asociaciones, incluidos los detalles para evitar costos inesperadamente elevados en las ejecuciones de la automatización, consulte [Cómo saber cuándo se aplican las asociaciones a los recursos](#state-manager-about-scheduling).
## Configuración de roles para `AssociationDispatchAssumeRole`
Para configurar los roles personalizados de asunción para el envío que State Manager asume para realizar acciones en su nombre, los roles deben confiar en `ssm.amazonaws.com` y tener el permiso necesario para llamar a `ssm:SendCommand` o `ssm:StartAutomationExecution` en función de los casos de uso de la asociación.
Ejemplo de política de confianza:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Administración del uso de AssociationDispatchAssumeRole con `ssm:AssociationDispatchAssumeRole`
Para administrar los roles personalizados de asunción para el envío que State Manager asume para realizar acciones en su nombre, utilice la clave de condición `ssm:AssociationDispatchAssumeRole`. Esta condición controla si las asociaciones se pueden crear o actualizar sin especificar un rol personalizado de asunción para el envío.
En el siguiente ejemplo de política, la instrucción `"Allow"` concede permisos a las API de creación y actualización de asociaciones solo cuando se especifica el parámetro `AssociationDispatchAssumeRole`. Sin este parámetro en las solicitudes de API, la política no concede permiso para crear ni actualizar asociaciones:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:CreateAssociation",
"ssm:UpdateAssociation",
"ssm:CreateAssociationBatch"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:AssociationDispatchAssumeRole": "*"
}
}
}
]
}
```
# Trabajo con asociaciones en Systems Manager
En esta sección se describe cómo crear y administrar las asociaciones de State Manager mediante la consola de AWS Systems Manager, AWS Command Line Interface (AWS CLI) y Herramientas de AWS para PowerShell.
**Topics**
+ [Cómo comprender los controles de frecuencia y destinos en las asociaciones de State Manager](systems-manager-state-manager-targets-and-rate-controls.md)
+ [Cómo crear asociaciones](state-manager-associations-creating.md)
+ [Cómo editar y crear una nueva versión de una asociación](state-manager-associations-edit.md)
+ [Eliminación de una asociación](systems-manager-state-manager-delete-association.md)
+ [Ejecución de grupos de Auto Scaling con asociaciones](systems-manager-state-manager-asg.md)
+ [Visualización de los historiales de asociación](state-manager-associations-history.md)
+ [Uso de asociaciones mediante IAM](systems-manager-state-manager-iam.md)
# Cómo comprender los controles de frecuencia y destinos en las asociaciones de State Manager
Este tema describe las características de State Manager que lo ayudan a implementar una asociación en decenas o cientos de nodos mientras controla la cantidad de nodos que ejecutan la asociación a la hora programada. State Manager es una herramienta de AWS Systems Manager.
## Cómo utilizar destinos
Cuando crea una asociación de State Manager, usted elige los nodos que desea configurar con la asociación en la sección **Targets** (Destinos) de la consola de Systems Manager, como se muestra aquí.
![\[Diferentes opciones para establecer el destino de los nodos al momento de crear una asociación de State Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/state-manager-targets.png)
Si crea una asociación mediante una herramienta de línea de comandos como la AWS Command Line Interface (AWS CLI), especifique el parámetro `targets`. La definición del destino de los nodos le permite configurar decenas, cientos o miles de nodos con una asociación sin tener que especificar ni elegir ID de nodo individuales.
Cada nodo administrado puede ser el objetivo de un máximo de 20 asociaciones.
State Manager incluye las siguientes opciones de destino al crear una asociación.
**Specify tags (Especificar etiquetas)**
Utilice esta opción para especificar una clave de etiqueta y (opcionalmente) un valor de etiqueta asignado a los nodos. Al ejecutar la solicitud, el sistema localiza e intenta crear la asociación en todos los nodos que coinciden con la clave y el valor de etiqueta especificados. Si ha especificado varios valores de etiquetas, la asociación se dirige hacia cualquier nodo con al menos uno de esos valores de etiquetas. Cuando el sistema crea inicialmente la asociación, la ejecuta. Después de esta ejecución inicial, el sistema ejecuta la asociación de acuerdo con la programación especificada.
Si crea nuevos nodos y asigna la clave y el valor de etiqueta especificados a esos nodos, el sistema aplica automáticamente la asociación, la ejecuta inmediatamente y, a continuación, la ejecuta de acuerdo con la programación. Esto se aplica cuando la asociación utiliza un documento de comando o política y no se aplica si la asociación utiliza un manual de procedimientos de Automation. Si elimina las etiquetas especificadas de un nodo, el sistema dejará de ejecutar la asociación en esos nodos.
**nota**
Si usa manuales de procedimiento de automatización con State Manager y la limitación de etiquetado le impide alcanzar un objetivo específico, considere usar manuales de procedimiento de automatización con Amazon EventBridge. Para obtener más información, consulte [Ejecución de automatizaciones a partir de eventos EventBridge](running-automations-event-bridge.md). Para obtener información acerca del uso de State Manager con manuales de procedimientos de Automation, consulte [Programación de automatizaciones con asociaciones de State Manager](scheduling-automations-state-manager-associations.md).
Como práctica recomendada, recomendamos usar etiquetas al crear asociaciones que usen un documento de comando o de política. También recomendamos usar etiquetas al crear asociaciones para ejecutar grupos de escalado automático. Para obtener más información, consulte [Ejecución de grupos de Auto Scaling con asociaciones](systems-manager-state-manager-asg.md).
**nota**
Observe la siguiente información.
Al crear una asociación en la Consola de administración de AWS que se dirija a nodos mediante etiquetas, solo puede especificar una clave de etiqueta para una asociación de automatización y cinco claves de etiqueta para una asociación de comandos. *Todas* las claves de etiqueta especificadas en la asociación deben estar asignadas actualmente al nodo. Si no lo están, State Manager no se dirige al nodo para establecer una asociación.
Si quiere usar la consola *y* desea dirigirse a sus nodos mediante más de una clave de etiqueta para una asociación de automatización y cinco claves de etiqueta para una asociación de comando, asigne las claves de etiqueta a un grupo de Grupos de recursos de AWS y agréguele los nodos. A continuación, puede elegir la opción **Grupo de recursos** en la lista de **objetivos** al crear la asociación con State Manager.
Puede especificar un máximo de cinco claves de etiqueta mediante AWS CLI. Si utiliza las AWS CLI, *todas* las claves de etiqueta especificadas en el comando `create-association` deben estar asignadas actualmente al nodo. Si no lo están, State Manager no se dirige al nodo para establecer una asociación.
**Cómo elegir los nodos manualmente**
Utilice esta opción para seleccionar manualmente los nodos en los que desea crear la asociación. El panel **Instances** (Instancias) muestra todos los nodos administrados de Systems Manager de la Cuenta de AWS y Región de AWS actuales. Puede seleccionar manualmente tantos nodos como desee. Cuando el sistema crea inicialmente la asociación, la ejecuta. Después de esta ejecución inicial, el sistema ejecuta la asociación de acuerdo con la programación especificada.
**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.
**Cómo elegir un grupo de recursos**
Utilice esta opción para crear una asociación en todos los nodos devueltos por una consulta de Grupos de recursos de AWS basada en etiquetas o por una consulta de AWS CloudFormation basada en la pila.
A continuación, puede encontrar detalles acerca del establecimiento del destino de grupos de recursos para una asociación.
+ Si agrega nuevos nodos a un grupo, el sistema asigna automáticamente los nodos a la asociación que segmenta el grupo de recursos. El sistema aplica la asociación a los nodos cuando detecta el cambio. Después de esta ejecución inicial, el sistema ejecuta la asociación de acuerdo con la programación especificada.
+ Si crea una asociación dirigida a un grupo de recursos y el tipo de recurso `AWS::SSM::ManagedInstance` se especificó para ese grupo y, por diseño, la asociación se ejecuta en instancias de Amazon Elastic Compute Cloud (Amazon EC2) y nodos que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types).
Y viceversa. Si crea una asociación dirigida a un grupo de recursos y el tipo de recurso `AWS::EC2::Instance` se especificó para ese grupo y, por diseño, la asociación se ejecuta en instancias (Amazon EC2) y nodos que no sean de EC2 en un entorno [híbrido y multinube](operating-systems-and-machine-types.md#supported-machine-types).
+ Si crea una asociación que se dirige a un grupo de recursos, ese grupo de recursos no debe tener asignadas más de cinco claves de etiqueta o más de cinco valores especificados para cualquier clave de etiqueta individual. Si se da cualquiera de estas condiciones en las etiquetas y claves asignadas al grupo de recursos, la asociación no se ejecuta y devuelve un error `InvalidTarget`.
+ Si crea una asociación que se dirige a un grupo de recursos mediante etiquetas, no puede elegir la opción **(valor vacío)** para el valor de la etiqueta.
+ Si elimina un grupo de recursos, todas las instancias de ese grupo dejarán de ejecutar la asociación. Como práctica recomendada, elimine las asociaciones que establece el destino del grupo.
+ Como máximo, puede definir el destino de un único grupo de recursos para una asociación. No se admiten grupos múltiples o anidados.
+ Después de crear una asociación, State Manager actualiza periódicamente la asociación con información sobre los recursos del grupo de recursos. Si agrega nuevos recursos a un grupo de recursos, la programación que indica cuándo el sistema aplica la asociación a los nuevos recursos depende de varios factores. Puede determinar el estado de la asociación en la página de State Manager de la consola de Systems Manager.
**aviso**
Un usuario, grupo o rol de AWS Identity and Access Management (IAM) con permiso para crear una asociación que establece el destino de un grupo de recursos de instancias de Amazon EC2 tiene automáticamente control de nivel de raíz de todas las instancias del grupo. Solo se debe permitir a los administradores de confianza crear asociaciones.
Para obtener más información acerca de Resource Groups, consulte [¿Qué es Grupos de recursos de AWS?](https://docs.aws.amazon.com/ARG/latest/userguide/) en la *Guía del usuario de Grupos de recursos de AWS*.
**Choose all nodes (Elegir todos los nodos)**
Utilice esta opción para definir el destino de todos los nodos de la Cuenta de AWS y Región de AWS actuales. Cuando ejecuta la solicitud, el sistema localiza e intenta crear la asociación en todos los nodos de la Cuenta de AWS y Región de AWS actuales. Cuando el sistema crea inicialmente la asociación, la ejecuta. Después de esta ejecución inicial, el sistema ejecuta la asociación de acuerdo con la programación especificada. Si crea nuevos nodos, el sistema aplica automáticamente la asociación, la ejecuta inmediatamente y, a continuación, la ejecuta de acuerdo con la programación.
## Cómo utilizar controles de velocidad
Puede controlar la ejecución de una asociación en los nodos especificando un valor de simultaneidad y un umbral de error. El valor de simultaneidad especifica cuántos nodos pueden ejecutar la asociación a la vez. Un umbral de error especifica cuántas ejecuciones de asociaciones pueden producir un error antes de que Systems Manager envíe un comando a cada nodo configurado con esa asociación para detener su ejecución. El comando deja de ejecutar la asociación hasta la próxima ejecución programada. Las características de umbral de simultaneidad y error se denominan colectivamente *controles de frecuencia*.
![\[Diferentes opciones de control de velocidad al momento de crear una asociación de State Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/state-manager-rate-controls.png)
**Simultaneidad**
La simultaneidad ayuda a limitar el impacto en los nodos al permitirle especificar que solo un determinado número de nodos pueden procesar una asociación a la vez. Puede especificar un número absoluto de nodos, por ejemplo 20, o un porcentaje del conjunto de nodos de destino, por ejemplo, 10 %.
La simultaneidad de State Manager tiene las siguientes restricciones y limitaciones:
+ Si decide crear una asociación mediante el uso de destinos, pero no quiere especificar un valor de simultaneidad, State Manager fuerza automáticamente una simultaneidad máxima de 50 nodos.
+ Si los nodos nuevos que coinciden con los criterios de destino se conectan al mismo tiempo que se ejecuta una asociación que utiliza simultaneidad, los nuevos nodos ejecutarán la asociación si no se supera el valor de simultaneidad. Si el valor de simultaneidad se supera, los nodos se pasan por alto durante el intervalo de ejecución de la asociación actual. Los nodos ejecutarán la asociación durante el siguiente intervalo programado si cumplen los requisitos de simultaneidad.
+ Si actualiza una asociación que utiliza la simultaneidad y uno o varios nodos están procesando esa asociación cuando se actualiza, entonces se podrá completar cualquier nodo que esté ejecutando la asociación. Aquellas asociaciones que no se hayan iniciado se detienen. Después de finalizar la ejecución de las asociaciones, todos los nodos de destino ejecutarán inmediatamente la asociación de nuevo, ya que se ha actualizado. Cuando la asociación se ejecuta de nuevo, el valor de simultaneidad se aplica.
**Umbrales de error**
Un umbral de error especifica cuántas ejecuciones de asociaciones pueden fallar antes de que Systems Manager envíe un comando a cada nodo configurado con esa asociación. El comando deja de ejecutar la asociación hasta la próxima ejecución programada. Puede especificar un número absoluto de errores, por ejemplo, 10 o un porcentaje del destino definido, por ejemplo, el 10 %.
Si especifica un número absoluto de tres errores, por ejemplo, State Manager envía el comando de detención cuando se devuelve el cuarto error. Si se especifica 0, State Manager envía el comando de detención tras el primer resultado de error que se devuelva.
Si especifica un umbral de error del 10 % para 50 asociaciones, State Manager envía el comando de detención cuando se devuelve el sexto error. Las asociaciones que ya se están ejecutando cuando se alcanza un umbral de errores tienen permiso para completarse, pero algunas de ellas también pueden generar un error. Para asegurarse de que no haya más errores que el número especificado para el umbral de error, establezca el valor de **Concurrency (Simultaneidad)** en 1 de modo que las asociaciones sigan procesándose de una en una.
State ManagerLos umbrales de error de tienen en cuenta las siguientes restricciones y limitaciones:
+ Los umbrales de error se aplican para el intervalo actual.
+ La información sobre cada error, incluidos los detalles de nivel de paso, se registran en el historial de asociaciones.
+ Si decide crear una asociación mediante el uso de destinos, pero no quiere especificar un umbral de error, State Manager forzará automáticamente un umbral de error del 100 %.
# Cómo crear asociaciones
State Manager, una herramienta de AWS Systems Manager, lo ayuda a mantener los recursos de AWS en el estado que defina y a reducir la desviación de la configuración. Para ello, State Manager utiliza asociaciones. Una *asociación* es una configuración que asigna a los recursos de AWS. La configuración define el estado que desea mantener en los recursos. Por ejemplo, una asociación puede especificar que el software antivirus debe estar instalado y ejecutándose en un nodo administrado, o bien que determinados puertos deben estar cerrados.
Una asociación especifica una programación del momento en que aplicar la configuración y los destinos para la asociación. Por ejemplo, una asociación para software antivirus puede ejecutarse una vez al día en todos los nodos administrados de una Cuenta de AWS. Si el software no está instalado en un nodo, la asociación podría exigir a State Manager que lo instale. Si el software está instalado, pero el servicio no se está ejecutando, la asociación podría exigir a State Manager que inicie el servicio.
**aviso**
Al crear una asociación, puede elegir un grupo de recursos de AWS de nodos administrados como destino de la asociación. Si un usuario, grupo o rol de AWS Identity and Access Management (IAM) que tiene permiso para crear una asociación que establece el destino de un grupo de recursos de nodos administrados, dicho usuario, grupo o rol tiene automáticamente control de nivel de raíz de todos los nodos del grupo. Solo se permite a los administradores de confianza crear asociaciones.
**Objetivos de asociación y controles de tasas**
Una asociación especifica qué nodos administrados, o destinos, deben recibir la asociación. State Manager incluye varias características para ayudarlo a definir el destino de los nodos administrados y controlar cómo se implementa la asociación en esos destinos. Para obtener más información acerca de los controles de velocidad y destinos, 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).
**Cómo etiquetar asociaciones**
Puede asignar etiquetas a una asociación al crearla mediante una herramienta de línea de comandos como la AWS CLI o Herramientas de AWS para PowerShell. No se admite agregar etiquetas a una asociación mediante la consola de Systems Manager.
**Cómo correr asociaciones**
De forma predeterminada, State Manager ejecuta una asociación inmediatamente después de crearla y, a continuación, según la programación que haya definido.
El sistema también ejecuta asociaciones de acuerdo con las siguientes reglas:
+ State Manager intenta ejecutar la asociación en todos los nodos de destino o especificados durante un intervalo.
+ Si una asociación no se ejecuta durante un intervalo (porque, por ejemplo, un valor de simultaneidad limita el número de nodos que podría procesar la asociación simultáneamente), State Manager intenta ejecutar la asociación durante el intervalo siguiente.
+ State Manager ejecuta la asociación después de realizar cambios en la configuración, los nodos de destino, los documentos o los parámetros de la asociación. Para obtener más información, consulte [Cómo saber cuándo se aplican las asociaciones a los recursos](state-manager-about.md#state-manager-about-scheduling)
+ State Manager registra el historial de todos los intervalos omitidos. Puede ver el historial en la pestaña **Execution History (Historial de ejecución)**.
## Asociaciones de programación
Puede programar las asociaciones para que se ejecuten a intervalos básicos, por ejemplo, *cada 10 horas*, o puede crear programaciones más avanzadas mediante expresiones de frecuencia y cron personalizadas. También puede impedir que las asociaciones se ejecuten al crearlas por primera vez.
**Cómo utilizar las expresiones cron y rate para programar ejecuciones de asociaciones**
Además de las expresiones estándar de cron y rate, State Manager también admite expresiones de cron que incluyen un día de la semana y el signo de número (\$1) para designar el *n* día de un mes para ejecutar una asociación. A continuación, se incluye un ejemplo en el que se ejecuta una programación cron el tercer martes de cada mes a las 23.30 h UTC:
`cron(30 23 ? * TUE#3 *)`
A continuación, se incluye un ejemplo que se ejecuta el segundo jueves de cada mes a medianoche (UTC):
`cron(0 0 ? * THU#2 *)`
State Manager también admite el signo (L) para indicar el último día *X* del mes. A continuación, se incluye un ejemplo en el que se ejecuta una programación cron el último martes de cada mes a medianoche (UTC):
`cron(0 0 ? * 3L *)`
Para tener un mayor control sobre el momento en el que se ejecuta una asociación, por ejemplo, si desea ejecutar una asociación dos días después de la revisión del martes, puede especificar un desplazamiento. Un *desplazamiento* define los días que hay que esperar después del día programado para ejecutar una asociación. Por ejemplo, si especificó una programación cron de `cron(0 0 ? * THU#2 *)`, puede especificar el número 3 en el campo **Desplazamiento de programación** para ejecutar la asociación cada domingo después del segundo jueves del mes.
**nota**
Para utilizar los desplazamientos, seleccione **Aplicar la asociación solo en el siguiente intervalo Cron especificado** en la consola o especifique el parámetro `ApplyOnlyAtCronInterval` desde la línea de comandos. Cuando cualquiera de estas opciones está activada, State Manager no ejecuta la asociación inmediatamente después de crearla.
Para obtener más información acerca de las expresiones Cron y Rate, consulte [Referencia: expresiones cron y rate para Systems Manager](reference-cron-and-rate-expressions.md).
## Cómo crear una asociación (consola)
El siguiente procedimiento describe cómo utilizar la consola de Systems Manager para crear una asociación de State Manager.
**nota**
Observe la siguiente información.
Este procedimiento describe cómo crear una asociación que utilice un documento `Command` o un documento `Policy` para dirigirse a nodos administrados. Para obtener información sobre cómo crear una asociación que utilice un manual de ejecución de Automation para dirigirse a nodos u otros tipos de recursos de AWS, consulte [Programación de automatizaciones con asociaciones de State Manager](scheduling-automations-state-manager-associations.md).
Al crear una asociación, puede especificar un máximo de cinco claves de etiqueta mediante la Consola de administración de AWS. *Todas* las claves de etiqueta especificadas para la asociación deben estar asignadas actualmente al nodo. Si no lo están, State Manager no se dirige al nodo para establecer la asociación.
**Cómo crear una asociación de State 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 **State Manager**.
1. Elija **Crear asociación**.
1. Escriba un nombre en el campo **Nombre**.
1. En la lista **Document (Documento)**, elija la opción junto al nombre de un documento. Observe el tipo de documento. Este procedimiento se aplica a los documentos `Command` y `Policy`. Para obtener información acerca de cómo crear una asociación que utiliza un manual de procedimientos de Automation, consulte [Programación de automatizaciones con asociaciones de State Manager](scheduling-automations-state-manager-associations.md).
**importante**
State Manager no admite la ejecución de asociaciones que utilizan una nueva versión de un documento si dicho documento se comparte desde otra cuenta. State Manager siempre ejecuta la versión `default` de un documento si se comparte desde otra cuenta, aunque la consola de Systems Manager muestra que se procesó una versión nueva. Si desea ejecutar una asociación con una versión nueva de un documento compartido desde otra cuenta, debe establecer la versión del documento en `default`.
1. En **Parameters (Parámetros)**, especifique los parámetros de entrada requeridos.
1. (Opcional) En **Rol de asunción para la ejecución de asociaciones**, seleccione un rol en el menú desplegable. State Manager realizará acciones mediante el uso de este rol en su nombre. Para obtener más información sobre la configuración del rol proporcionado personalizado, consulte [Configuración de roles para `AssociationDispatchAssumeRole`](state-manager-about.md#setup-assume-role).
**nota**
Se recomienda que defina un rol de IAM personalizado para tener el control total sobre los permisos que dispone State Manager a la hora de realizar acciones en su nombre.
La compatibilidad de los roles vinculados a servicios en State Manager se está eliminando gradualmente. Es posible que las asociaciones que dependen de un rol vinculado al servicio necesiten actualizaciones en el futuro para seguir funcionando correctamente.
Para obtener información sobre cómo administrar el uso del rol proporcionado personalizado, consulte [Administración del uso de AssociationDispatchAssumeRole con `ssm:AssociationDispatchAssumeRole`](state-manager-about.md#context-key-assume-role).
1. (Opcional) Elija una alarma de CloudWatch para aplicarla a la asociación de monitoreo.
**nota**
Tenga en cuenta la siguiente información sobre este paso.
La lista de alarmas muestra un máximo de 100 alarmas. Si no ve su alarma en la lista, utilice la AWS Command Line Interface para crear la asociación. Para obtener más información, consulte [Cómo rear una asociación (línea de comandos)](#create-state-manager-association-commandline).
Para adjuntar una alarma de CloudWatch a su comando, la entidad principal de IAM que crea la asociación debe tener permiso para la acción `iam:createServiceLinkedRole`. Para obtener más información sobre las alarmas de CloudWatch, consulte [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Tenga en cuenta que si la alarma se activa, no se ejecutarán automatizaciones o invocaciones de comandos pendiente.
1. En **Targets (Destinos)**, elija una opción. Para obtener más información acerca del uso de los destinos, 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).
**nota**
Para que las asociaciones que se crean con los manuales de procedimientos de Automatización se apliquen cuando se detecten nuevos nodos de destino, se deben cumplir algunas condiciones. Para obtener más información, consulte [Acerca de las actualizaciones de destino con los manuales de procedimientos de Automatización](state-manager-about.md#runbook-target-updates).
1. En la sección **Specify schedule (Especificar programación)**, elija **On Schedule (De forma programada)** o **No schedule (Sin programación)**. Si elige **On Schedule (De forma programada)**, utilice los botones proporcionados para crear una programación Cron o Rate para la asociación.
Si no desea que una asociación se ejecute inmediatamente después de crearla, elija **Aplicar la asociación solo en el siguiente intervalo cron especificado**.
1. (Opcional) En el campo **Schedule offset** (Desplazamiento de la programación), especifique un número comprendido entre 1 y 6.
1. En la sección **Advanced options** (Opciones avanzadas), seleccione la opción **Compliance severity** (Severidad de la conformidad) para elegir un nivel de severidad para la asociación y utilice **Change Calendars** (Calendarios de cambios) para elegir un calendario de cambios para la asociación.
Los informes de conformidad indican si el estado de asociación es conforme o no conforme, junto con el nivel de gravedad que se indique aquí. Para obtener más información, consulte [Acerca de la conformidad de las asociaciones de State Manager](compliance-about.md#compliance-about-association).
El calendario de cambios determina cuándo se ejecuta la asociación. Si el calendario está cerrado, la asociación no se aplica. Si el calendario está abierto, la asociación se ejecuta en consecuencia. Para obtener más información, consulte [AWS Systems Manager Change Calendar](systems-manager-change-calendar.md).
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. 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).
En la sección **Simultaneidad**, elija una opción:
+ Elija **Targets (Destinos)** para introducir un número absoluto de destinos que pueda ejecutar la asociación de forma simultánea.
+ Elija **porcentaje** para introducir un porcentaje del destino definido que puede ejecutar la asociación de forma simultánea.
En la sección **Umbral de error**, elija una opción:
+ Elija **errors (errores)** para especificar un número absoluto de errores permitidos antes de que State Manager deje de ejecutar asociaciones en más destinos.
+ Elija **percentage (porcentaje)** para especificar un porcentaje de errores permitidos antes de que State Manager deje de ejecutar asociaciones en más destinos.
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.
A continuación, se presentan los permisos mínimos necesarios para activar la salida de Amazon S3 para una asociación. Puede restringir aún más el acceso al adjuntar políticas de IAM a usuarios o roles dentro de una cuenta. Como mínimo, un perfil de instancias de Amazon EC2 debe tener un rol de IAM con la política administrada `AmazonSSMManagedInstanceCore` y la siguiente política insertada.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
]
}
```
------
Para obtener permisos mínimos, el bucket de Amazon S3 que exporte debe tener la configuración predeterminada definida por la consola de Amazon S3. Para obtener más información acerca de la creación de buckets de Amazon S3, consulte la sección [Creación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) en la *Guía del usuario de Amazon S3*.
**nota**
Las operaciones de la API que inicia el documento SSM durante la ejecución de una asociación no se registran en AWS CloudTrail.
1. Elija **Crear asociación**.
**nota**
Si elimina la asociación creada, la asociación ya no se ejecutará en ningún destino de dicha asociación.
## Cómo rear una asociación (línea de comandos)
En el siguiente procedimiento, se describe cómo utilizar la AWS CLI (en Linux o Windows Server) o Tools for PowerShell para crear una asociación de State Manager. Esta sección incluye varios ejemplos que muestran cómo utilizar los controles de velocidad y destinos. Los controles de velocidad y destinos le permiten asignar una asociación a decenas o cientos de nodos mientras controla la ejecución de esas asociaciones. Para obtener más información acerca de los controles de velocidad y destinos, 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).
**importante**
Este procedimiento describe cómo crear una asociación que utilice un documento `Command` o un documento `Policy` para dirigirse a nodos administrados. Para obtener información sobre cómo crear una asociación que utilice un manual de ejecución de Automation para dirigirse a nodos u otros tipos de recursos de AWS, consulte [Programación de automatizaciones con asociaciones de State Manager](scheduling-automations-state-manager-associations.md).
**Antes de empezar**
El parámetro `targets` es una matriz de criterios de búsqueda que establece el destino de los nodos mediante la combinación de `Key` y `Value` que especifique. Si tiene previsto crear una asociación en decenas o cientos de nodos mediante el parámetro `targets`, revise las siguientes opciones de establecimiento de destino antes de comenzar el procedimiento.
Direccione los nodos específicos mediante la definición de ID
```
--targets Key=InstanceIds,Values=instance-id-1,instance-id-2,instance-id-3
```
```
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE,i-07782c72faEXAMPLE
```
Establecer el destino de las instancias mediante etiquetas de
```
--targets Key=tag:tag-key,Values=tag-value-1,tag-value-2,tag-value-3
```
```
--targets Key=tag:Environment,Values=Development,Test,Pre-production
```
Direccione los nodos mediante Grupos de recursos de AWS
```
--targets Key=resource-groups:Name,Values=resource-group-name
```
```
--targets Key=resource-groups:Name,Values=WindowsInstancesGroup
```
Direccione todas las instancias de la Cuenta de AWS y la Región de AWS actuales
```
--targets Key=InstanceIds,Values=*
```
**nota**
Observe la siguiente información.
State Manager no admite la ejecución de asociaciones que utilizan una nueva versión de un documento si dicho documento se comparte desde otra cuenta. State Manager siempre ejecuta la versión `default` de un documento si se comparte desde otra cuenta, aunque la consola de Systems Manager muestra que se procesó una versión nueva. Si desea ejecutar una asociación con una versión nueva de un documento compartido desde otra cuenta, debe configurar la versión del documento en `default`.
State Manager no admite los parámetros `IncludeChildOrganizationUnits`, `ExcludeAccounts`, `TargetsMaxErrors`, `TargetsMaxConcurrency`, `Targets` ni `TargetLocationAlarmConfiguration` para [TargetLocation](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TargetLocation.html).
Puede especificar un máximo de cinco claves de etiqueta mediante AWS CLI. Si utiliza las AWS CLI, *todas* las claves de etiqueta especificadas en el comando `create-association` deben estar asignadas actualmente al nodo. Si no lo están, State Manager no se dirige al nodo para establecer una asociación.
Al crear una asociación, especifica cuándo se ejecuta el programa. Especifique el programa mediante una expresión Cron o Rate. Para obtener más información acerca de las expresiones Cron y Rate, consulte [Expresiones cron y rate para asociaciones](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association).
Para que las asociaciones que se crean con los manuales de procedimientos de Automatización se apliquen cuando se detecten nuevos nodos de destino, se deben cumplir algunas condiciones. Para obtener más información, consulte [Acerca de las actualizaciones de destino con los manuales de procedimientos de Automatización](state-manager-about.md#runbook-target-updates).
**Cómo crear una asociación**
1. Si aún no lo ha hecho, instale y configure la AWS CLI o Herramientas de AWS para PowerShell.
Para obtener 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) e [Instalación de Herramientas de AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Utilice el formato siguiente para crear un comando que crea una asociación de State Manager. Reemplace cada *example resource placeholder* con su propia información.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--name document_name \
--document-version version_of_document_applied \
--instance-id instances_to_apply_association_on \
--parameters (if any) \
--targets target_options \
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations \
--schedule-expression "cron_or_rate_expression" \
--apply-only-at-cron-interval required_parameter_for_schedule_offsets \
--schedule-offset number_between_1_and_6 \
--output-location s3_bucket_to_store_output_details \
--association-name association_name \
--max-errors a_number_of_errors_or_a_percentage_of_target_set \
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set \
--compliance-severity severity_level \
--calendar-names change_calendar_names \
--target-locations aws_region_or_account \
--tags "Key=tag_key,Value=tag_value"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--name document_name ^
--document-version version_of_document_applied ^
--instance-id instances_to_apply_association_on ^
--parameters (if any) ^
--targets target_options ^
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations ^
--schedule-expression "cron_or_rate_expression" ^
--apply-only-at-cron-interval required_parameter_for_schedule_offsets ^
--schedule-offset number_between_1_and_6 ^
--output-location s3_bucket_to_store_output_details ^
--association-name association_name ^
--max-errors a_number_of_errors_or_a_percentage_of_target_set ^
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set ^
--compliance-severity severity_level ^
--calendar-names change_calendar_names ^
--target-locations aws_region_or_account ^
--tags "Key=tag_key,Value=tag_value"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-Name document_name `
-DocumentVersion version_of_document_applied `
-InstanceId instances_to_apply_association_on `
-Parameters (if any) `
-Target target_options `
-AssociationDispatchAssumeRole arn_of_role_to_be_used_when_dispatching_configurations `
-ScheduleExpression "cron_or_rate_expression" `
-ApplyOnlyAtCronInterval required_parameter_for_schedule_offsets `
-ScheduleOffSet number_between_1_and_6 `
-OutputLocation s3_bucket_to_store_output_details `
-AssociationName association_name `
-MaxError a_number_of_errors_or_a_percentage_of_target_set
-MaxConcurrency a_number_of_instances_or_a_percentage_of_target_set `
-ComplianceSeverity severity_level `
-CalendarNames change_calendar_names `
-TargetLocations aws_region_or_account `
-Tags "Key=tag_key,Value=tag_value"
```
------
En el siguiente ejemplo se crea una asociación en los nodos etiquetados con `"Environment,Linux"`. La asociación utiliza el documento `AWS-UpdateSSMAgent` para actualizar SSM Agent en los nodos de destino a las 2:00 h UTC todos los domingos por la mañana. Esta asociación se ejecuta de forma simultánea en un máximo de 10 nodos en cualquier momento. Además, esta asociación deja de ejecutarse en más nodos durante un intervalo de ejecución determinado si el recuento de errores es superior a 5. Para los informes de conformidad, a esta asociación se le asigna un nivel de gravedad medio.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--targets Key=tag:Environment,Values=Linux \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN *)" \
--max-errors "5" \
--max-concurrency "10"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--targets Key=tag:Environment,Values=Linux ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--max-errors "5" ^
--max-concurrency "10"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_Linux `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="tag:Environment"
"Values"="Linux"
} `
-ComplianceSeverity MEDIUM `
-ScheduleExpression "cron(0 2 ? * SUN *)" `
-MaxConcurrency 10 `
-MaxError 5
```
------
El ejemplo siguiente se dirige a los ID de nodo mediante la especificación de un valor de comodín (\$1). Esto permite que Systems Manager cree una asociación en *todos* los nodos de la Cuenta de AWS y Región de AWS actuales. Esta asociación se ejecuta de forma simultánea en un máximo de 10 nodos en cualquier momento. Además, esta asociación deja de ejecutarse en más nodos durante un intervalo de ejecución determinado si el recuento de errores es superior a 5. Para los informes de conformidad, a esta asociación se le asigna un nivel de gravedad medio. Esta asociación utiliza un desplazamiento de programación, lo que significa que se ejecuta dos días después de la programación cron especificada. También incluye el parámetro `ApplyOnlyAtCronInterval`, que es necesario para utilizar el desplazamiento de programación, lo que significa que la asociación no se ejecutará inmediatamente después de crearla.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--name "AWS-UpdateSSMAgent" \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--targets "Key=instanceids,Values=*" \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN#2 *)" \
--apply-only-at-cron-interval \
--schedule-offset 2 \
--max-errors "5" \
--max-concurrency "10" \
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--name "AWS-UpdateSSMAgent" ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--targets "Key=instanceids,Values=*" ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN#2 *)" ^
--apply-only-at-cron-interval ^
--schedule-offset 2 ^
--max-errors "5" ^
--max-concurrency "10" ^
--apply-only-at-cron-interval
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_All `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="InstanceIds"
"Values"="*"
} `
-ScheduleExpression "cron(0 2 ? * SUN#2 *)" `
-ApplyOnlyAtCronInterval `
-ScheduleOffset 2 `
-MaxConcurrency 10 `
-MaxError 5 `
-ComplianceSeverity MEDIUM `
-ApplyOnlyAtCronInterval
```
------
En el siguiente ejemplo, se crea una asociación en los nodos de Resource Groups. El grupo se denomina "HR-Department". La asociación utiliza el documento `AWS-UpdateSSMAgent` para actualizar SSM Agent en los nodos de destino a las 2:00 h UTC todos los domingos por la mañana. Esta asociación se ejecuta de forma simultánea en un máximo de 10 nodos en cualquier momento. Además, esta asociación deja de ejecutarse en más nodos durante un intervalo de ejecución determinado si el recuento de errores es superior a 5. Para los informes de conformidad, a esta asociación se le asigna un nivel de gravedad medio. Esta asociación se ejecuta en la programación cron especificada. No se ejecuta inmediatamente después de su creación.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name Update_SSM_Agent_Linux \
--targets Key=resource-groups:Name,Values=HR-Department \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--compliance-severity "MEDIUM" \
--schedule-expression "cron(0 2 ? * SUN *)" \
--max-errors "5" \
--max-concurrency "10" \
--apply-only-at-cron-interval
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name Update_SSM_Agent_Linux ^
--targets Key=resource-groups:Name,Values=HR-Department ^
--name AWS-UpdateSSMAgent ^
-association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--compliance-severity "MEDIUM" ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--max-errors "5" ^
--max-concurrency "10" ^
--apply-only-at-cron-interval
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName Update_SSM_Agent_Linux `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="resource-groups:Name"
"Values"="HR-Department"
} `
-ScheduleExpression "cron(0 2 ? * SUN *)" `
-MaxConcurrency 10 `
-MaxError 5 `
-ComplianceSeverity MEDIUM `
-ApplyOnlyAtCronInterval
```
------
En el siguiente ejemplo, se crea una asociación que se ejecuta en nodos etiquetados con un ID de nodo específico. La asociación utiliza el documento de SSM Agent para actualizar SSM Agent en los nodos de destino una vez cuando el calendario de cambios está abierto. La asociación verifica el estado del calendario cuando se ejecuta. Si el calendario se cierra al momento del lanzamiento y la asociación solo se ejecuta una vez, no se volverá a ejecutar porque la ventana de ejecución de asociación ha pasado. Si el calendario está abierto, la asociación se ejecuta en consecuencia.
**nota**
Si agrega nuevos nodos a las etiquetas o los grupos de recursos en los que actúa una asociación cuando se cierra el calendario de cambios, la asociación se aplica a esos nodos una vez que se abre el calendario de cambios.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name CalendarAssociation \
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" \
--schedule-expression "rate(1day)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name CalendarAssociation ^
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" ^
--schedule-expression "rate(1day)"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName CalendarAssociation `
-Target @{
"Key"="tag:instanceids"
"Values"="i-0cb2b964d3e14fd9f"
} `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" `
-ScheduleExpression "rate(1day)"
```
------
En el siguiente ejemplo, se crea una asociación que se ejecuta en nodos etiquetados con un ID de nodo específico. La asociación utiliza el documento de SSM Agent para actualizar SSM Agent en los nodos de destino a las 2:00 h todos los domingos. Esta asociación solo se ejecuta en la programación cron especificada cuando el calendario de cambios está abierto. Cuando se crea la asociación, verifica el estado del calendario. Si el calendario está cerrado, la asociación no se aplica. Cuando el intervalo para aplicar la asociación comienza a las 2:00 h del domingo, la asociación verifica si el calendario está abierto. Si el calendario está abierto, la asociación se ejecuta en consecuencia.
**nota**
Si agrega nuevos nodos a las etiquetas o los grupos de recursos en los que actúa una asociación cuando se cierra el calendario de cambios, la asociación se aplica a esos nodos una vez que se abre el calendario de cambios.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--association-name MultiCalendarAssociation \
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" \
--name AWS-UpdateSSMAgent \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--association-name MultiCalendarAssociation ^
--targets "Key=instanceids,Values=i-0cb2b964d3e14fd9f" ^
--name AWS-UpdateSSMAgent ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ PowerShell ]
```
New-SSMAssociation `
-AssociationName MultiCalendarAssociation `
-Name AWS-UpdateSSMAgent `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-Target @{
"Key"="tag:instanceids"
"Values"="i-0cb2b964d3e14fd9f"
} `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2" `
-ScheduleExpression "cron(0 2 ? * SUN *)"
```
------
**nota**
Si elimina la asociación creada, la asociación ya no se ejecutará en ningún destino de dicha asociación. Además, si especificó el parámetro `apply-only-at-cron-interval`, puede restablecer esta opción. Para ello, especifique el parámetro `no-apply-only-at-cron-interval` cuando actualice la asociación desde la línea de comandos. Este parámetro obliga a la asociación a ejecutarse inmediatamente después de actualizar la asociación y de acuerdo con el intervalo especificado.
# Cómo editar y crear una nueva versión de una asociación
Puede editar una asociación de State Manager para especificar un nombre nuevo, la programación, el nivel de severidad, los destinos u otros valores. En el caso de asociaciones basadas en documentos del tipo de comando SSM, también puede elegir escribir la salida del comando en un bucket de Amazon Simple Storage Service (Amazon S3). Después de editar una asociación, State Manager crea una nueva versión. Puede ver distintas versiones después de la edición, tal como se describe en los siguientes procedimientos.
**nota**
Para que las asociaciones que se crean con los manuales de procedimientos de Automatización se apliquen cuando se detecten nuevos nodos de destino, se deben cumplir algunas condiciones. Para obtener más información, consulte [Acerca de las actualizaciones de destino con los manuales de procedimientos de Automatización](state-manager-about.md#runbook-target-updates).
Los siguientes procedimientos describen cómo editar y crear una nueva versión de una asociación mediante la consola de Systems Manager, AWS Command Line Interface (AWS CLI) y Herramientas de AWS para PowerShell (Tools for PowerShell).
**importante**
State Manager no admite la ejecución de asociaciones que utilizan una nueva versión de un documento si dicho documento se comparte desde otra cuenta. State Manager ejecuta siempre la versión `default` de un documento si se comparte desde otra cuenta, aunque la consola de Systems Manager muestre que se procesó una versión nueva. Si desea ejecutar una asociación con una versión nueva de un documento compartido desde otra cuenta, debe configurar la versión del documento en `default`.
## Cómo crear una asociación (consola)
En el siguiente procedimiento, se describe cómo utilizar la consola de Systems Manager para editar y crear una nueva versión de una asociación.
**nota**
En el caso de las asociaciones que utilizan documentos de comandos de SSM, no manuales de procedimientos de automatización, este procedimiento requiere que tenga acceso de escritura a un bucket de Amazon S3 existente. Si no ha utilizado Amazon S3, debe tener en cuenta que se le cobrará por utilizar Amazon S3. Para obtener información sobre cómo crear un bucket, consulte [Creación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html).
**Cómo editar una asociación de State 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 **State Manager**.
1. Elija una asociación existente y luego elija **Editar**.
1. Reconfigure la asociación para que cumpla los requisitos actuales.
Para obtener información sobre las opciones de asociación con los documentos de `Policy` y de `Command`, consulte [Cómo crear asociaciones](state-manager-associations-creating.md). Para obtener información acerca de las opciones de asociación con manuales de procedimientos de Automation, consulte [Programación de automatizaciones con asociaciones de State Manager](scheduling-automations-state-manager-associations.md).
1. Elija **Save changes (Guardar cambios)**.
1. (Opcional) Para ver información sobre asociaciones, en la página **Asociaciones**, elija el nombre de la asociación que editó y, a continuación, elija la pestaña **Versiones**. El sistema enumera cada versión de la asociación que ha creado y editado.
1. (Opcional) Para ver los resultados de las asociaciones basadas en documentos de `Command` de SSM, haga lo siguiente:
1. Abra la consola de Amazon S3 en [https://console.aws.amazon.com/s3](https://console.aws.amazon.com/s3/).
1. Elija el nombre del bucket de Simple Storage Service (Amazon S3) que especificó para almacenar la información de salida del comando y, a continuación, elija la carpeta denominada con el ID del nodo que ejecutó la asociación. (si eligió almacenar información de salida en una carpeta del bucket, ábrala primero).
1. Profundice varios niveles, a través de la carpeta `awsrunPowerShell`, hasta el archivo `stdout`.
1. Elija **Open** o **Download** para ver el nombre de host.
## Cómo editar una asociación (línea de comandos)
En el siguiente procedimiento se describe cómo utilizar la AWS CLI (en Linux o Windows Server) o Herramientas de AWS para PowerShell para editar y crear una nueva versión de una asociación.
**Cómo editar una asociación de State Manager**
1. Si aún no lo ha hecho, instale y configure la AWS CLI o Herramientas de AWS para PowerShell.
Para obtener 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) e [Instalación de Herramientas de AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Utilice el siguiente formato para crear un comando para editar y crear una nueva versión de una asociación de State Manager existente. Reemplace cada *example resource placeholder* con su propia información.
**importante**
Cuando llama a `[https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html)`, el sistema elimina todos los parámetros opcionales de la solicitud y sobrescribe la asociación con valores nulos para esos parámetros. Este comportamiento es así por diseño. Debe especificar todos los parámetros opcionales de la llamada, incluso si no cambia los parámetros. Esto incluye el parámetro `--name`. Antes de llamar a esta acción, le recomendamos que llame a la operación de la API `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html)` y tome nota de todos los parámetros opcionales necesarios para su llamada a `update-association`.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--name document_name \
--document-version version_of_document_applied \
--instance-id instances_to_apply_association_on \
--parameters (if any) \
--targets target_options \
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations \
--schedule-expression "cron_or_rate_expression" \
--schedule-offset "number_between_1_and_6" \
--output-location s3_bucket_to_store_output_details \
--association-name association_name \
--max-errors a_number_of_errors_or_a_percentage_of_target_set \
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set \
--compliance-severity severity_level \
--calendar-names change_calendar_names \
--target-locations aws_region_or_account
```
------
#### [ Windows ]
```
aws ssm update-association ^
--name document_name ^
--document-version version_of_document_applied ^
--instance-id instances_to_apply_association_on ^
--parameters (if any) ^
--targets target_options ^
--association-dispatch-assume-role arn_of_role_to_be_used_when_dispatching_configurations ^
--schedule-expression "cron_or_rate_expression" ^
--schedule-offset "number_between_1_and_6" ^
--output-location s3_bucket_to_store_output_details ^
--association-name association_name ^
--max-errors a_number_of_errors_or_a_percentage_of_target_set ^
--max-concurrency a_number_of_instances_or_a_percentage_of_target_set ^
--compliance-severity severity_level ^
--calendar-names change_calendar_names ^
--target-locations aws_region_or_account
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-Name document_name `
-DocumentVersion version_of_document_applied `
-InstanceId instances_to_apply_association_on `
-Parameters (if any) `
-Target target_options `
-AssociationDispatchAssumeRole arn_of_role_to_be_used_when_dispatching_configurations `
-ScheduleExpression "cron_or_rate_expression" `
-ScheduleOffset "number_between_1_and_6" `
-OutputLocation s3_bucket_to_store_output_details `
-AssociationName association_name `
-MaxError a_number_of_errors_or_a_percentage_of_target_set
-MaxConcurrency a_number_of_instances_or_a_percentage_of_target_set `
-ComplianceSeverity severity_level `
-CalendarNames change_calendar_names `
-TargetLocations aws_region_or_account
```
------
En el siguiente ejemplo se actualiza una asociación existente para cambiar el nombre a `TestHostnameAssociation2`. La nueva versión de asociación se ejecuta cada hora y escribe la salida de los comandos en el bucket de Amazon S3 especificado.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name TestHostnameAssociation2 \
--parameters commands="echo Association" \
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--schedule-expression "cron(0 */1 * * ? *)"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name TestHostnameAssociation2 ^
--parameters commands="echo Association" ^
--association-dispatch-assume-role arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--schedule-expression "cron(0 */1 * * ? *)"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName TestHostnameAssociation2 `
-Parameter @{"commands"="echo Association"} `
-AssociationDispatchAssumeRole "arn:aws:iam::123456789012:role/myAssociationDispatchAssumeRole" `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-S3Location_OutputS3KeyPrefix logs `
-S3Location_OutputS3Region us-east-1 `
-ScheduleExpression "cron(0 */1 * * ? *)"
```
------
En el siguiente ejemplo se actualiza una asociación existente para cambiar el nombre a `CalendarAssociation`. La nueva asociación se ejecuta cuando el calendario está abierto y escribe la salida del comando en el bucket de Amazon S3 especificado.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name CalendarAssociation \
--parameters commands="echo Association" \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name CalendarAssociation ^
--parameters commands="echo Association" ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName CalendarAssociation `
-AssociationName OneTimeAssociation `
-Parameter @{"commands"="echo Association"} `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar2"
```
------
En el siguiente ejemplo se actualiza una asociación existente para cambiar el nombre a `MultiCalendarAssociation`. La nueva asociación se ejecuta cuando los calendarios están abiertos y escribe la salida del comando en el bucket de Amazon S3 especificado.
------
#### [ Linux & macOS ]
```
aws ssm update-association \
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE \
--association-name MultiCalendarAssociation \
--parameters commands="echo Association" \
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' \
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
#### [ Windows ]
```
aws ssm update-association ^
--association-id 8dfe3659-4309-493a-8755-01234EXAMPLE ^
--association-name MultiCalendarAssociation ^
--parameters commands="echo Association" ^
--output-location S3Location='{OutputS3Region=us-east-1,OutputS3BucketName=amzn-s3-demo-bucket,OutputS3KeyPrefix=logs}' ^
--calendar-names "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
#### [ PowerShell ]
```
Update-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE `
-AssociationName MultiCalendarAssociation `
-Parameter @{"commands"="echo Association"} `
-S3Location_OutputS3BucketName amzn-s3-demo-bucket `
-CalendarNames "arn:aws:ssm:us-east-1:123456789012:document/testCalendar1" "arn:aws:ssm:us-east-2:123456789012:document/testCalendar2"
```
------
1. Para ver la nueva versión de la asociación, ejecute el siguiente comando.
------
#### [ Linux & macOS ]
```
aws ssm describe-association \
--association-id b85ccafe-9f02-4812-9b81-01234EXAMPLE
```
------
#### [ Windows ]
```
aws ssm describe-association ^
--association-id b85ccafe-9f02-4812-9b81-01234EXAMPLE
```
------
#### [ PowerShell ]
```
Get-SSMAssociation `
-AssociationId b85ccafe-9f02-4812-9b81-01234EXAMPLE | Select-Object *
```
------
El sistema devuelve información similar a la siguiente.
------
#### [ Linux & macOS ]
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 */1 * * ? *)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "logs",
"OutputS3BucketName": "amzn-s3-demo-bucket",
"OutputS3Region": "us-east-1"
}
},
"Name": "AWS-RunPowerShellScript",
"Parameters": {
"commands": [
"echo Association"
]
},
"LastExecutionDate": 1559316400.338,
"Overview": {
"Status": "Success",
"DetailedStatus": "Success",
"AssociationStatusAggregatedCount": {}
},
"AssociationId": "b85ccafe-9f02-4812-9b81-01234EXAMPLE",
"DocumentVersion": "$DEFAULT",
"LastSuccessfulExecutionDate": 1559316400.338,
"LastUpdateAssociationDate": 1559316389.753,
"Date": 1559314038.532,
"AssociationVersion": "2",
"AssociationName": "TestHostnameAssociation2",
"Targets": [
{
"Values": [
"Windows"
],
"Key": "tag:Environment"
}
]
}
}
```
------
#### [ Windows ]
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 */1 * * ? *)",
"OutputLocation": {
"S3Location": {
"OutputS3KeyPrefix": "logs",
"OutputS3BucketName": "amzn-s3-demo-bucket",
"OutputS3Region": "us-east-1"
}
},
"Name": "AWS-RunPowerShellScript",
"Parameters": {
"commands": [
"echo Association"
]
},
"LastExecutionDate": 1559316400.338,
"Overview": {
"Status": "Success",
"DetailedStatus": "Success",
"AssociationStatusAggregatedCount": {}
},
"AssociationId": "b85ccafe-9f02-4812-9b81-01234EXAMPLE",
"DocumentVersion": "$DEFAULT",
"LastSuccessfulExecutionDate": 1559316400.338,
"LastUpdateAssociationDate": 1559316389.753,
"Date": 1559314038.532,
"AssociationVersion": "2",
"AssociationName": "TestHostnameAssociation2",
"Targets": [
{
"Values": [
"Windows"
],
"Key": "tag:Environment"
}
]
}
}
```
------
#### [ PowerShell ]
```
AssociationId : b85ccafe-9f02-4812-9b81-01234EXAMPLE
AssociationName : TestHostnameAssociation2
AssociationVersion : 2
AutomationTargetParameterName :
ComplianceSeverity :
Date : 5/31/2019 2:47:18 PM
DocumentVersion : $DEFAULT
InstanceId :
LastExecutionDate : 5/31/2019 3:26:40 PM
LastSuccessfulExecutionDate : 5/31/2019 3:26:40 PM
LastUpdateAssociationDate : 5/31/2019 3:26:29 PM
MaxConcurrency :
MaxErrors :
Name : AWS-RunPowerShellScript
OutputLocation : Amazon.SimpleSystemsManagement.Model.InstanceAssociationOutputLocation
Overview : Amazon.SimpleSystemsManagement.Model.AssociationOverview
Parameters : {[commands, Amazon.Runtime.Internal.Util.AlwaysSendList`1[System.String]]}
ScheduleExpression : cron(0 */1 * * ? *)
Status :
Targets : {tag:Environment}
```
------
# Eliminación de una asociación
Use el siguiente procedimiento para eliminar una asociación usando la consola AWS Systems Manager.
**Eliminación de una asociación**
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**.
1. Seleccione una asociación y, a continuación, elija **Eliminar**.
Puede eliminar varias asociaciones en una sola operación al ejecutar una automatización desde la consola AWS Systems Manager. Al seleccionar varias asociaciones para eliminarlas, State Manager abre la página de inicio del manual de procedimientos de automatización con los ID de asociación introducidos como valores de los parámetros de entrada.
**Para eliminar varias asociaciones en una sola operación**
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**.
1. Seleccione cada asociación que desee eliminar y elija **Eliminar**.
1. (Opcional) En el área de **Parámetros de entrada adicionales**, seleccione el nombre de recurso de Amazon (ARN) para el *rol de asunción* que desea que utilice la automatización durante la ejecución. Para crear un nuevo rol de asunción, elija **Crear**.
1. Elija **Enviar**.
# Ejecución de grupos de Auto Scaling con asociaciones
La práctica recomendada al momento de utilizar asociaciones para ejecutar grupos de Auto Scaling es utilizar destinos de etiqueta. Si no se utilizan etiquetas, es posible que se alcance el límite de asociación.
Si todos los nodos están etiquetados con la misma clave y valor, solo necesita una asociación para ejecutar el grupo de Auto Scaling. En el siguiente procedimiento, se describe cómo crear dicha asociación.
**Para crear una asociación que ejecute grupos de Auto Scaling**
1. Asegúrese de que todos los nodos del grupo de Auto Scaling estén etiquetados con la misma clave y valor. Para obtener más instrucciones acerca del etiquetado de nodos, consulte [Etiquetado de grupos e instancias de Auto Scaling](https://docs.aws.amazon.com//autoscaling/ec2/userguide/autoscaling-tagging.html) en la *Guía del usuario de AWS Auto Scaling*.
1. Cree una asociación siguiendo el procedimiento indicado en [Trabajo con asociaciones en Systems Manager](state-manager-associations.md).
Si está trabajando en la consola, elija **Specify instance tags** (Especificar etiquetas de instancias) en el campo **Targets** (Destinos). Para **Instance tags** (Etiquetas de instancia), ingrese la clave y el valor de la **Etiqueta** de su grupo de Auto Scaling.
Si utiliza AWS Command Line Interface (AWS CLI), especifique `--targets Key=tag:tag-key,Values=tag-value` donde la clave y el valor coinciden con lo que etiquetó sus nodos.
# Visualización de los historiales de asociación
Puede ver todas las ejecuciones correspondientes a un ID de asociación específico mediante la operación [DescribeAssociationExecutions](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutions.html) de la API. Utilice esta operación para ver el estado, el estado detallado, los resultados, la hora de la última ejecución y para obtener más información acerca de una asociación de State Manager. State Manager es una herramienta de AWS Systems Manager. Esta operación de la API también incluye filtros para ayudarlo a encontrar las asociaciones que cumplan los criterios que especifique. Por ejemplo, puede especificar una fecha y hora exactas y utilizar un filtro GREATER\$1THAN para ver las ejecuciones que se procesaron después dicha fecha y hora.
Si, por ejemplo, se produce un error en la ejecución de una asociación, puede desglosar los detalles de una ejecución específica mediante la operación [DescribeAssociationExecutionTargets](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutionTargets.html) de la API. Esta operación muestra los recursos, como, por ejemplo, los ID de nodo, en los que se ejecutó la asociación y los diferentes estados de la asociación. A continuación, puede ver en qué recurso o nodo no se pudo ejecutar la asociación. Con el ID de recurso puede ver los detalles de la ejecución del comando para ver en qué paso de un comando se ha producido el error.
En los ejemplos de esta sección, también se incluye información sobre cómo utilizar la operación [StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html) de la API para ejecutar una asociación una sola vez al momento de la creación. Puede utilizar esta operación de la API cuando investigue ejecuciones de asociaciones que produzcan errores. Si ve que se ha producido un error en una asociación, puede hacer un cambio en el recurso y, a continuación, ejecutar inmediatamente la asociación para ver si el cambio en el recurso permite que la asociación se ejecute correctamente.
**nota**
Las operaciones de la API que inicia el documento SSM durante la ejecución de una asociación no se registran en AWS CloudTrail.
## Visualización de los historiales de asociación (consola)
Utilice el siguiente procedimiento para ver el historial de ejecución de un ID de asociación específico y, a continuación, los detalles de ejecución de uno o varios recursos.
**Para ver el historial de ejecución de un ID de asociación específico**
1. Abra la consola de AWS Systems Manager en [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Elija **State Manager**.
1. En el campo **Association id (ID de asociación)**, elija la asociación cuyo historial desea ver.
1. Elija el botón **View details (Ver detalles)**.
1. Elija la pestaña **Execution history (Historial de ejecución)**.
1. Elija la asociación para la que desea ver los detalles de ejecución en el nivel de recursos. Por ejemplo, elija una asociación con el estado **Failed (Error)**. Una vez hecho esto, podrá ver los detalles de ejecución para los nodos en que no se pudo ejecutar la asociación.
Utilice los filtros del cuadro de búsqueda para localizar la ejecución cuyos detalles desea ver.
![\[Filtrado de la lista de ejecuciones de asociaciones de State Manager\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/sysman-state-executions-filter.png)
1. Elija un ID de ejecución. Se abre la página **Association execution targets (Destinos de la ejecución de la asociación)**. Esta página muestra todos los recursos en que se ha ejecutado la asociación.
1. Elija un ID de recurso para ver información específica sobre dicho recurso.
Utilice los filtros del cuadro de búsqueda para localizar el recurso cuyos detalles desea ver.
![\[Filtrado de la lista de destinos de la ejecución de asociación de State Manager.\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/sysman-state-executions-targets-filter.png)
1. Si está investigando una asociación que no se ha podido ejecutar, puede utilizar el botón **Apply association now** (Aplicar asociación ahora) para ejecutar una asociación una sola vez al momento de la creación. Una vez que haya realizado los cambios en el recurso en que no se pudo ejecutar la asociación, elija el enlace **Association ID (ID de asociación)** en la ruta de navegación.
1. Haga clic en el botón **Apply association now (Aplicar asociación ahora)**. Cuando finalice la ejecución, verifique que la ejecución de la asociación se ha realizado correctamente.
## Visualización de los historiales de asociación (línea de comandos)
En el siguiente procedimiento se describe cómo utilizar la AWS Command Line Interface (AWS CLI) (en Linux o Windows Server) o Herramientas de AWS para PowerShell para ver el historial de ejecución de un ID de asociación determinado. A continuación, el procedimiento describe cómo ver los detalles de ejecución de uno o varios recursos.
**Para ver el historial de ejecución de un ID de asociación específico**
1. Si aún no lo ha hecho, instale y configure la AWS CLI o Herramientas de AWS para PowerShell.
Para obtener 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) e [Instalación de Herramientas de AWS para PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Ejecute el siguiente comando para ver una lista de las ejecuciones de un determinado ID de asociación.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN
```
**nota**
Este comando incluye un filtro para limitar los resultados únicamente a las ejecuciones que han tenido lugar después de una fecha y hora determinadas. Si desea ver todas las ejecuciones de un ID de asociación específico, elimine el parámetro `--filters` y el valor ` Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN`.
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN
```
**nota**
Este comando incluye un filtro para limitar los resultados únicamente a las ejecuciones que han tenido lugar después de una fecha y hora determinadas. Si desea ver todas las ejecuciones de un ID de asociación específico, elimine el parámetro `--filters` y el valor ` Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN`.
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId ID `
-Filter @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="GREATER_THAN"}
```
**nota**
Este comando incluye un filtro para limitar los resultados únicamente a las ejecuciones que han tenido lugar después de una fecha y hora determinadas. Si desea ver todas las ejecuciones de un ID de asociación específico, elimine el parámetro `-Filter` y el valor ` @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="GREATER_THAN"}`.
------
El sistema devuelve información similar a la siguiente.
------
#### [ Linux & macOS ]
```
{
"AssociationExecutions":[
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"76a5a04f-caf6-490c-b448-92c02EXAMPLE",
"CreatedTime":1523986028.219,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"791b72e0-f0da-4021-8b35-f95dfEXAMPLE",
"CreatedTime":1523984226.074,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"ecec60fa-6bb0-4d26-98c7-140308EXAMPLE",
"CreatedTime":1523982404.013,
"AssociationVersion":"1"
}
]
}
```
------
#### [ Windows ]
```
{
"AssociationExecutions":[
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"76a5a04f-caf6-490c-b448-92c02EXAMPLE",
"CreatedTime":1523986028.219,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"791b72e0-f0da-4021-8b35-f95dfEXAMPLE",
"CreatedTime":1523984226.074,
"AssociationVersion":"1"
},
{
"Status":"Success",
"DetailedStatus":"Success",
"AssociationId":"c336d2ab-09de-44ba-8f6a-6136cEXAMPLE",
"ExecutionId":"ecec60fa-6bb0-4d26-98c7-140308EXAMPLE",
"CreatedTime":1523982404.013,
"AssociationVersion":"1"
}
]
}
```
------
#### [ PowerShell ]
```
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/18/2019 2:00:50 AM
DetailedStatus : Success
ExecutionId : 76a5a04f-caf6-490c-b448-92c02EXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/11/2019 2:00:54 AM
DetailedStatus : Success
ExecutionId : 791b72e0-f0da-4021-8b35-f95dfEXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
AssociationId : c336d2ab-09de-44ba-8f6a-6136cEXAMPLE
AssociationVersion : 1
CreatedTime : 8/4/2019 2:01:00 AM
DetailedStatus : Success
ExecutionId : ecec60fa-6bb0-4d26-98c7-140308EXAMPLE
LastExecutionDate : 1/1/0001 12:00:00 AM
ResourceCountByStatus : {Success=1}
Status : Success
```
------
Puede limitar los resultados mediante el uso de uno o varios filtros. En el siguiente ejemplo, se devuelven todas las asociaciones que se ejecutaron antes de una fecha y hora determinada.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=LESS_THAN
```
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=LESS_THAN
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-Filter @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="LESS_THAN"}
```
------
El comando siguiente devuelve todas las asociaciones que se ejecutaron *correctamente* después de una fecha y hora determinadas.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN Key=Status,Value=Success,Type=EQUAL
```
------
#### [ Windows ]
```
aws ssm describe-association-executions ^
--association-id ID ^
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN Key=Status,Value=Success,Type=EQUAL
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecution `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-Filter @{
"Key"="CreatedTime";
"Value"="2019-06-01T19:15:38.372Z";
"Type"="GREATER_THAN"
},
@{
"Key"="Status";
"Value"="Success";
"Type"="EQUAL"
}
```
------
1. Ejecute el comando siguiente para ver todos los destinos a los que se aplicó una ejecución específica.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE
```
------
Puede limitar los resultados mediante el uso de uno o varios filtros. En el ejemplo siguiente, se devuelve información sobre todos los destinos en que no se pudo ejecutar la asociación específica.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID \
--filters Key=Status,Value="Failed"
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID ^
--filters Key=Status,Value="Failed"
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE `
-Filter @{
"Key"="Status";
"Value"="Failed"
}
```
------
En el ejemplo siguiente, se devuelve información sobre un nodo administrado específico en que no se pudo ejecutar una asociación.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-execution-targets \
--association-id ID \
--execution-id ID \
--filters Key=Status,Value=Failed Key=ResourceId,Value="i-02573cafcfEXAMPLE" Key=ResourceType,Value=ManagedInstance
```
------
#### [ Windows ]
```
aws ssm describe-association-execution-targets ^
--association-id ID ^
--execution-id ID ^
--filters Key=Status,Value=Failed Key=ResourceId,Value="i-02573cafcfEXAMPLE" Key=ResourceType,Value=ManagedInstance
```
------
#### [ PowerShell ]
```
Get-SSMAssociationExecutionTarget `
-AssociationId 14bea65d-5ccc-462d-a2f3-e99c8EXAMPLE `
-ExecutionId 76a5a04f-caf6-490c-b448-92c02EXAMPLE `
-Filter @{
"Key"="Status";
"Value"="Success"
},
@{
"Key"="ResourceId";
"Value"="i-02573cafcfEXAMPLE"
},
@{
"Key"="ResourceType";
"Value"="ManagedInstance"
}
```
------
1. Si está investigando una asociación que no se ha podido ejecutar, puede utilizar la operación [StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html) de la API para ejecutar una asociación inmediatamente una sola vez. Después de cambiar el recurso en el que no se pudo ejecutar la asociación, ejecute el comando siguiente para ejecutar la asociación inmediatamente una sola vez.
------
#### [ Linux & macOS ]
```
aws ssm start-associations-once \
--association-id ID
```
------
#### [ Windows ]
```
aws ssm start-associations-once ^
--association-id ID
```
------
#### [ PowerShell ]
```
Start-SSMAssociationsOnce `
-AssociationId ID
```
------
# Uso de asociaciones mediante IAM
State Manager, una herramienta de AWS Systems Manager, utiliza [destinos](systems-manager-state-manager-targets-and-rate-controls.md#systems-manager-state-manager-targets-and-rate-controls-about-targets) para elegir con qué instancias configura sus asociaciones. Originalmente, las asociaciones se crearon especificando un nombre de documento (`Name`) y un ID de instancia (`InstanceId`). Esto creó una asociación entre un documento y una instancia o nodo administrados. Las asociaciones solían ser identificadas por estos parámetros. Estos parámetros ahora están obsoletos, pero siguen siendo compatibles. Los recursos `instance` y `managed-instance` se agregaron como recursos a acciones con `Name` y `InstanceId`.
AWS Identity and Access ManagementEl comportamiento de aplicación de políticas de (IAM) depende del tipo de recurso especificado. Los recursos para operaciones de State Manager solo se aplican en función de la solicitud aprobada. State Manager no realiza una verificación profunda de las propiedades de los recursos de su cuenta. Una solicitud solo se valida con recursos de política si el parámetro de solicitud presenta los recursos de política especificados. Por ejemplo, si especifica una instancia en el bloque de recursos, la política se aplica si la solicitud utiliza el parámetro `InstanceId`. El parámetro `Targets` para cada recurso de la cuenta no está verificado para ese `InstanceId`.
Los siguientes son algunos casos con comportamiento confuso:
+ [DescribeAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DescribeActivations.html), [DeleteAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DeleteAssociation.html) y [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html) utilizan recursos `instance`, `managed-instance` y `document` para especificar la forma obsoleta de referirse a asociaciones. Esto incluye todas las asociaciones creadas con el parámetro obsoleto `InstanceId`.
+ [CreateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociation.html), [CreateAssociationBatch](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociationBatch.html) y [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html) utilizan recursos `instance` y `managed-instance` para especificar la forma obsoleta de referirse a asociaciones. Esto incluye todas las asociaciones creadas con el parámetro obsoleto `InstanceId`. El tipo de recurso `document` es parte de la forma obsoleta de referirse a asociaciones y es una propiedad real de una asociación. Esto significa que puede crear políticas de IAM con los permisos `Allow` o `Deny` para las acciones `Create` y `Update` según el nombre del documento.
Para obtener más información acerca del uso de políticas de IAM con Systems Manager, consulte [Administración de identidades y accesos en AWS Systems Manager](security-iam.md) o [Acciones, recursos y claves de condiciones de AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html) en la *Referencia de autorizaciones de servicio*.
# Cómo crear asociaciones que ejecutan archivos MOF
Puede ejecutar archivos Managed Object Format (MOF) para aplicar un estado objetivo en nodos administrados de Windows Server con State Manager, una herramienta de AWS Systems Manager, mediante el documento `AWS-ApplyDSCMofs` de SSM. El documento `AWS-ApplyDSCMofs` cuenta con dos modos de ejecución. En el primer modo, puede configurar la asociación para analizar e informar si los nodos administrados se encuentran en el estado deseado definido en los archivos MOF especificados. En el segundo, puede ejecutar los archivos MOF y cambiar la configuración de los nodos en función de los recursos y sus valores definidos en los archivos MOF. El documento `AWS-ApplyDSCMofs` le permite descargar y ejecutar los archivos de configuración MOF desde Amazon Simple Storage Service (Amazon S3), un recurso compartido o un sitio web seguro con un dominio HTTPS.
State Manager registra e informa del estado de cada archivo MOF durante cada ejecución de asociación. State Manager también informa de la salida de cada ejecución de archivo MOF como un evento de conformidad que puede ver en la página [Conformidad de AWS Systems Manager](https://console.aws.amazon.com/systems-manager/compliance).
La ejecución de archivos MOF se basa en Windows PowerShell Desired State Configuration (PowerShell DSC). PowerShell DSC es una plataforma declarativa que se utiliza para la configuración, la implementación y la administración de los sistemas Windows. PowerShell DSC permite a los administradores describir, en documentos de texto sencillo llamados "configuraciones de DSC", cómo desean configurar un servidor. Una configuración de PowerShell DSC es un script de PowerShell especializado que indica qué es lo que se debe hacer, pero no cómo. La ejecución de la configuración produce un archivo MOF. El archivo MOF se puede aplicar a uno o varios servidores para lograr la configuración deseada para esos servidores. Los recursos de PowerShell DSC realizan la tarea de aplicar la configuración. Para obtener más información, consulte [Windows PowerShell Desired State Configuration Overview](https://download.microsoft.com/download/4/3/1/43113F44-548B-4DEA-B471-0C2C8578FBF8/Quick_Reference_DSC_WS12R2.pdf).
**Topics**
+ [Cómo utilizar Amazon S3 para almacenar artefactos](#systems-manager-state-manager-using-mof-file-S3-storage)
+ [Cómo resolver credenciales en archivos MOF](#systems-manager-state-manager-using-mof-file-credentials)
+ [Cómo utilizar tokens en archivos MOF](#systems-manager-state-manager-using-mof-file-tokens)
+ [Requisitos previos para la creación de asociaciones que ejecutan archivos MOF](#systems-manager-state-manager-using-mof-file-prereqs)
+ [Cómo crear una asociación que ejecuta archivos MOF](#systems-manager-state-manager-using-mof-file-creating)
+ [Solución de problemas al crear asociaciones que ejecutan archivos MOF](#systems-manager-state-manager-using-mof-file-troubleshooting)
+ [Cómo visualizar los detalles de cumplimiento de recursos de DSC](#systems-manager-state-manager-viewing-mof-file-compliance)
## Cómo utilizar Amazon S3 para almacenar artefactos
Si utiliza Amazon S3 para almacenar los módulos de PowerShell, archivos MOF, informes de conformidad o informes de estado, el rol de AWS Identity and Access Management (IAM) que utiliza SSM Agent de AWS Systems Manager debe tener permisos `ListBucket` y `GetObject` en el bucket. Si no proporciona estos permisos, el sistema devuelve un error*Acceso denegado*. Aquí hay información importante sobre el almacenamiento de artefactos en Amazon S3.
+ Si el bucket está en otra Cuenta de AWS, cree una política de recursos de bucket que concede a la cuenta (o al rol de IAM) los permisos `GetObject` y `ListBucket`.
+ Si desea utilizar recursos de DSC personalizados, puede descargar estos recursos desde un bucket de Amazon S3. También puede instalarlos automáticamente desde la galería de PowerShell.
+ Si utiliza Amazon S3 como fuente del módulo, cargue el módulo como un archivo Zip que distingue entre mayúsculas y minúsculas en el siguiente formato: *ModuleName*\$1*ModuleVersion*.zip. Por ejemplo: MiMódulo\$11.0.0.zip.
+ Todos los archivos deben estar en la raíz del bucket. Las estructuras de carpeta no son compatibles.
## Cómo resolver credenciales en archivos MOF
Las credenciales se resuelven mediante [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) o [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md). Esto permite configurar la rotación de credenciales automática. Esto también le permite a DSC propagar automáticamente las credenciales a los servidores sin tener que volver a implementar los archivos MOF.
Para utilizar un secreto de AWS Secrets Manager en una configuración, cree un objeto PSCredential donde el nombre de usuario sean los valores de SecretId o SecretARN del secreto que contiene la credencial. Puede especificar cualquier valor del contraseña. El valor se omite. A continuación se muestra un ejemplo.
```
Configuration MyConfig
{
$ss = ConvertTo-SecureString -String 'a_string' -AsPlaintext -Force
$credential = New-Object PSCredential('a_secret_or_ARN', $ss)
Node localhost
{
File file_name
{
DestinationPath = 'C:\MyFile.txt'
SourcePath = '\\FileServer\Share\MyFile.txt'
Credential = $credential
}
}
}
```
Compile los archivos usando la configuración MOF PsAllowPlaintextPassword en los datos de configuración. Esto es correcto, ya que la credencial solo contiene una etiqueta.
En Secrets Manager, asegúrese de que el nodo tenga acceso a GetSecretValue en una política administrada de IAM y, de forma opcional, en la política de recursos de secretos si existe. Para trabajar con DSC, el secreto debe tener el siguiente formato.
```
{ 'Username': 'a_name', 'Password': 'a_password' }
```
El secreto puede tener otras propiedades (por ejemplo, las propiedades utilizadas para rotación), pero debe tener, como mínimo, el nombre de usuario y la contraseña.
Es recomendable que utilice un método de rotación de varios usuarios, donde tenga dos nombres de usuario y contraseñas diferentes, y la función de AWS Lambda de rotación cambia entre ellos. Este método permite varias cuentas activas al mismo tiempo, lo que elimina el riesgo de bloquear usuarios durante la rotación.
## Cómo utilizar tokens en archivos MOF
Los tokens le ofrecen la posibilidad de modificar valores de propiedades de recursos *después* de compilar los MOF. Esto le permite volver a utilizar los archivos MOF comunes en varios servidores que requieren configuraciones similares.
La sustitución de tokens solo funciona para las propiedades de recursos de tipo `String`. Sin embargo, si el recurso tiene una propiedad de nodo CIM anidada, también resuelve tokens de propiedades `String` en ese nodo CIM. No se puede utilizar la sustitución de tokens para numerales o matrices.
Por ejemplo, considere un escenario en el que utiliza el recurso xComputerManagement y desea cambiar el nombre del equipo con DSC. Normalmente, necesitaría un archivo MOF dedicado para esa máquina. Sin embargo, gracias a la compatibilidad con token, puede crear un solo archivo MOF y aplicarlo a todos los nodos. En la propiedad `ComputerName`, en lugar de codificar de forma rígida el nombre del equipo en el MOF, puede utilizar un token de tipo de etiqueta de instancia. El valor se resuelve durante el análisis de MOF. Consulte el siguiente ejemplo.
```
Configuration MyConfig
{
xComputer Computer
{
ComputerName = '{tag:ComputerName}'
}
}
```
A continuación, configure una etiqueta en el nodo administrado en la consola de Systems Manager o una etiqueta de Amazon Elastic Compute Cloud (Amazon EC2) en la consola de Amazon EC2. Al ejecutar el documento, el script sustituye el token \$1tag:ComputerName\$1 por el valor de la etiqueta de instancia.
También puede combinar varias etiquetas en una sola propiedad, como se muestra en el ejemplo siguiente.
```
Configuration MyConfig
{
File MyFile
{
DestinationPath = '{env:TMP}\{tag:ComputerName}'
Type = 'Directory'
}
}
```
Hay cinco tipos diferentes de tokens que puede utilizar:
+ **tag**: etiquetas de los nodos administrados o Amazon EC2.
+ **tagb64**: igual que tag, pero el sistema usa base64 para descodificar el valor. Esto le permite utilizar caracteres especiales en los valores de etiqueta.
+ **env**: resuelve las variables de entorno.
+ **ssm**: valores de Parameter Store. Solo se admiten los tipos String y SecureString.
+ **tagssm**: igual que tag, pero si la etiqueta no se ha establecido en el nodo, el sistema intenta resolver el valor de un parámetro de Systems Manager con el mismo nombre. Esto resulta útil en situaciones en las que desea un valor global predeterminado, pero quiere poder anularlo en un solo nodo (por ejemplo, las implementaciones únicas).
A continuación, se muestra un ejemplo de Parameter Store que utiliza el tipo de token `ssm`.
```
File MyFile
{
DestinationPath = "C:\ProgramData\ConnectionData.txt"
Content = "{ssm:%servicePath%/ConnectionData}"
}
```
Los tokens desempeñan un papel importante a la hora de reducir el código redundante haciendo que los archivos MOF sean genéricos y reutilizables. Si puede evitar el archivo MOF específico de servidor, no tendrá que usar un servicio de creación de MOF. Un servicio de creación de MOF aumenta los costos, disminuye el tiempo de aprovisionamiento y aumenta el riesgo de desviaciones de configuración entre nodos agrupados debido a que se instalan diferentes versiones del módulo en el servidor de compilación cuando se compilan los MOF.
## Requisitos previos para la creación de asociaciones que ejecutan archivos MOF
Antes de crear una asociación que ejecuta archivos MOF, compruebe que los nodos administrados tienen los siguientes requisitos previos instalados:
+ Windows PowerShell, versión 5.0 o posterior. Para obtener más información, consulte [Requisitos del sistema de Windows PowerShell](https://docs.microsoft.com/en-us/powershell/scripting/install/windows-powershell-system-requirements?view=powershell-6) en Microsoft.com.
+ [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/) versión 3.3.261.0 o posterior.
+ SSM AgentVersión 2.2 o posterior de .
## Cómo crear una asociación que ejecuta archivos MOF
**Cómo crear una asociación que ejecuta archivos MOF**
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**.
1. Elija **State Manager** y, a continuación, **Create association** (Crear asociación).
1. Escriba un nombre en el campo **Nombre**. Esto es opcional, pero recomendable. Un nombre puede ayudarle a entender el objetivo de la asociación cuando la creó. No se permiten espacios en el nombre.
1. En la lista **Document** (Documento), elija **`AWS-ApplyDSCMofs`**.
1. En la sección **Parameters (Parámetros)**, especifique los parámetros de entrada opcionales y obligatorios.
1. **Mofs To Apply (MOF a aplicar)**: especifique uno o varios archivos MOF que se ejecutarán cuando se ejecute esta asociación. Use comas para separar una lista de archivos MOF. Systems Manager itera la lista de archivos MOF y los ejecuta en el orden especificado en la lista separada por comas.
+ Un nombre bucket de Amazon S3. Los nombres de bucket deben utilizar letras en minúscula. Especifique esta información mediante el siguiente formato.
```
s3:amzn-s3-demo-bucket:MOF_file_name.mof
```
Si desea especificar una Región de AWS, utilice el siguiente formato.
```
s3:bucket_Region:amzn-s3-demo-bucket:MOF_file_name.mof
```
+ Un sitio web seguro. Especifique esta información mediante el siguiente formato.
```
https://domain_name/MOF_file_name.mof
```
A continuación se muestra un ejemplo.
```
https://www.example.com/TestMOF.mof
```
+ Un sistema de archivos en un recurso compartido. Especifique esta información mediante el siguiente formato.
```
\server_name\shared_folder_name\MOF_file_name.mof
```
A continuación se muestra un ejemplo.
```
\StateManagerAssociationsBox\MOFs_folder\MyMof.mof
```
1. **Service Path** (Ruta de servicio): una ruta de servicio es un prefijo de bucket de Amazon S3 en la que desea escribir informes y la información de estado (opcional). Una ruta de servicio es una ruta de las etiquetas basadas en parámetros de Parameter Store. Al resolver etiquetas basadas en parámetros, el sistema utiliza \$1ssm:%servicePath%/*parameter\$1name*\$1 para inyectar el valor de servicePath en el nombre del parámetro. Por ejemplo, si la ruta de servicio es "WebServers/Production", los sistemas resuelven el parámetro como: WebServers/Production/*parameter\$1name*. Esto es útil para cuando se ejecutan varios entornos en la misma cuenta.
1. **Report Bucket Name** (Nombre del bucket de informes): ingrese el nombre de un bucket de Amazon S3 en el que desea escribir datos de conformidad (opcional). Los informes se guardan en este bucket en formato JSON.
**nota**
Puede incluir la región en la que se encuentre el bucket como prefijo del nombre del bucket. A continuación, se muestra un ejemplo: us-west-2:MyMOFBucket. Si utiliza un proxy para puntos de enlace de Amazon S3 en una región específica que no incluya us-east-1, incluya como prefijo el nombre del bucket con una región. Si el nombre del bucket no es el prefijo, se detecta automáticamente la región del bucket utilizando el punto de enlace us-east-1.
1. **Mof Operation Mode** (Modo de funcionamiento de MOF): elija el comportamiento de State Manager cuando se ejecute la asociación **`AWS-ApplyDSCMofs`**:
+ **Apply** (Aplicar): corrige las configuraciones de nodos que no son conformes.
+ **ReportOnly**: no corrige las configuraciones de nodos, sino que registra todos los datos de conformidad e informa de los nodos que no son conformes.
1. **Status Bucket Name** (Nombre del bucket de estado): ingrese el nombre de un bucket de Amazon S3 en el que desea escribir información de estado de ejecución de MOF (opcional). Estos informes de estado son resúmenes de singleton de la ejecución de conformidad más reciente de un nodo. Esto significa que el informe se sobrescribirá la próxima vez que la asociación ejecute archivos MOF.
**nota**
Puede incluir la región en la que se encuentre el bucket como prefijo del nombre del bucket. A continuación se muestra un ejemplo: `us-west-2:amzn-s3-demo-bucket`. Si utiliza un proxy para puntos de enlace de Amazon S3 en una región específica que no incluya us-east-1, incluya como prefijo el nombre del bucket con una región. Si el nombre del bucket no es el prefijo, se detecta automáticamente la región del bucket utilizando el punto de enlace us-east-1.
1. **Module Source Bucket Name** (Nombre del bucket de origen del módulo): ingrese el nombre de un bucket de Amazon S3 que contiene archivos de módulos de PowerShell (opcional). Si especifica **None** (Ninguno), elija **True** (Verdadero) para la siguiente opción, **Allow PS Gallery Module Source** (Permitir el origen de módulos de la galería de PowerShell).
**nota**
Puede incluir la región en la que se encuentre el bucket como prefijo del nombre del bucket. A continuación se muestra un ejemplo: `us-west-2:amzn-s3-demo-bucket`. Si utiliza un proxy para puntos de enlace de Amazon S3 en una región específica que no incluya us-east-1, incluya como prefijo el nombre del bucket con una región. Si el nombre del bucket no es el prefijo, se detecta automáticamente la región del bucket utilizando el punto de enlace us-east-1.
1. **Allow PS Gallery Module Source (Permitir origen de módulos de la galería de PowerShell)**: elija **Verdadero** para descargar los módulos de PowerShell de [https://www.powershellgallery.com/](https://www.powershellgallery.com/) (opcional). Si elige **False** (Falso), especifique un origen para la opción anterior, **ModuleSourceBucketName**.
1. **Proxy Uri (URI de proxy)**: utilice esta opción para descargar archivos MOF desde un servidor proxy (opcional).
1. **Reboot Behavior (Comportamiento de reinicio)**: especifique uno de los siguientes comportamientos de reinicio si la ejecución de su archivo MOF requiere reiniciar: (opcional)
+ **AfterMof**: reinicia el nodo una vez que se hayan completado todas las ejecuciones de MOF. Aunque varias ejecuciones de MOF solicitan reinicios, el sistema espera hasta que se hayan completado todas las ejecuciones de MOF para reiniciarse.
+ **Immediately** (Inmediatamente): reinicia el nodo cada vez que lo solicita una ejecución de MOF. Si se ejecutan varios archivos MOF que solicitan reinicios, los nodos se reinician varias veces.
+ **Never** (Nunca): los nodos no se reinician, incluso si la ejecución de MOF solicita expresamente un reinicio.
1. **Use Computer Name For Reporting** (Utilizar nombre de equipo para informes): habilite esta opción para utilizar el nombre del equipo cuando se crean informes de información de conformidad (opcional). El valor predeterminado es **false** (falso), lo que significa que el sistema utiliza el ID de nodo cuando se crean informes de conformidad.
1. **Turn on Verbose Logging** (Activar registros detallados): le recomendamos activar el registro detallado a la hora de implementar archivos MOF por primera vez (opcional).
**importante**
Cuando se permite, el registro detallado escribe más datos a su bucket de Amazon S3 que con el registro de ejecución de asociaciones estándar. Esto puede reducir el rendimiento y conllevar cargos de almacenamiento superiores en Amazon S3. Para mitigar los problemas de tamaños de almacenamiento, le recomendamos que active las políticas de ciclo de vida en su bucket de Amazon S3. Para obtener más información, consulte [How Do I Create a Lifecycle Policy for an S3 Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) en la *Guía del usuario de Amazon Simple Storage Service*.
1. **Turn on Debug Logging** (Activar registro de depuración): le recomendamos que active el registro de depuración para solucionar los problemas de errores de MOF (opcional). También le recomendamos que desactive esta opción para hacer un uso normal.
**importante**
Cuando se permite, el registro detallado escribe más datos en su bucket de Amazon S3 que con el registro de ejecución de asociaciones estándar. Esto puede reducir el rendimiento y conllevar cargos de almacenamiento superiores en Amazon S3. Para mitigar los problemas de tamaños de almacenamiento, le recomendamos que active las políticas de ciclo de vida en su bucket de Amazon S3. Para obtener más información, consulte [How Do I Create a Lifecycle Policy for an S3 Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) en la *Guía del usuario de Amazon Simple Storage Service*.
1. **Compliance Type (Tipo de conformidad)**: especifique el tipo de conformidad que se utilizará al crear informes de información de conformidad (opcional). El valor de conformidad predeterminado es **Custom:DSC**. Si crea varias asociaciones que ejecutan archivos MOF, asegúrese de especificar un tipo de conformidad distinto para cada asociación. Si no lo hace, cada asociación adicional que utilice **Custom:DSC** sobrescribe los datos de conformidad existentes.
1. **Pre Reboot Script (Script de reinicio previo)**: especifique un script a ejecutar si la configuración indica que es necesario reiniciar. El script se ejecuta antes del reinicio. El script debe ser de una sola línea. Separe las líneas adicionales mediante el uso de punto y coma.
1. En la sección **Targets (Destinos)**, elija **Specifying tags (Especificación de etiquetas)** o **Manually Selecting Instance (Selección manual de la instancia)**. Si decide seleccionar como destino recursos mediante el uso de etiquetas, introduzca una clave de etiqueta y un valor de etiqueta en los campos correspondientes. Para obtener más información acerca del uso de destinos, 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. En la sección **Specify schedule (Especificar programación)**, elija **On Schedule (De forma programada)** o **No schedule (Sin programación)**. Si elige **On Schedule (De forma programada)**, utilice los botones proporcionados para crear una programación Cron o Rate para la asociación.
1. En la sección **Advanced options (Opciones avanzadas)**:
+ En **Compliance severity (Gravedad de conformidad)**, elija un nivel de seguridad para la asociación. Los informes de conformidad indican si el estado de asociación es conforme o no conforme, junto con el nivel de gravedad que se indique aquí. Para obtener más información, consulte [Acerca de la conformidad de las asociaciones de State Manager](compliance-about.md#compliance-about-association).
1. En la sección **Rate control** (Control de frecuencia), configure las opciones para ejecutar asociaciones de State Manager a través de la flota de nodos administrados. Para obtener más información sobre estas opciones, 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).
En la sección **Simultaneidad**, elija una opción:
+ Elija **Targets (Destinos)** para introducir un número absoluto de destinos que pueda ejecutar la asociación de forma simultánea.
+ Elija **porcentaje** para introducir un porcentaje del destino definido que puede ejecutar la asociación de forma simultánea.
En la sección **Umbral de error**, elija una opción:
+ Elija **errors (errores)** para introducir un número absoluto de errores permitidos antes de que State Manager deje de ejecutar asociaciones en más destinos.
+ Elija **percentage (porcentaje)** para introducir un porcentaje de errores permitidos antes de que State Manager deje de ejecutar asociaciones en más destinos.
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**.
State Manager crea y ejecuta inmediatamente la asociación en los nodos o destinos especificados. Después de la ejecución inicial, la asociación se ejecuta en intervalos de acuerdo con la programación que definió y de acuerdo con las reglas siguientes:
+ State Manager ejecuta asociaciones en nodos que estén en línea cuando el intervalo comienza y omite los nodos sin conexión.
+ State Manager intenta ejecutar la asociación en todos los nodos configurados durante un intervalo.
+ Si una asociación no se ejecuta durante un intervalo (porque, por ejemplo, un valor de simultaneidad limita el número de nodos que podría procesar la asociación simultáneamente), State Manager intenta ejecutar la asociación durante el intervalo siguiente.
+ State Manager registra el historial de todos los intervalos omitidos. Puede ver el historial en la pestaña **Execution History (Historial de ejecución)**.
**nota**
`AWS-ApplyDSCMofs` es un documento de Systems Manager Command. Esto significa que también puede ejecutar este documento mediante Run Command, una herramienta de AWS Systems Manager. Para obtener más información, consulte [AWS Systems Manager Run Command](run-command.md).
## Solución de problemas al crear asociaciones que ejecutan archivos MOF
Esta sección contiene información para ayudarle a solucionar los problemas que surjan al crear asociaciones que ejecutan archivos MOF.
**Cómo activar el registro mejorado**
Como primer paso para la solución de problemas, active el registro mejorado. Más concretamente, realice lo siguiente:
1. Compruebe que la asociación se ha configurado para escribir el resultado del comando en Amazon S3 o los Registros de Amazon CloudWatch (CloudWatch).
1. Establezca el parámetro **Enable Verbose Logging (Habilitar registro detallado)** en True.
1. Establezca el parámetro **Enable Debug Logging (Habilitar registro de depuración)** en True.
Con el registro de depuración y el detallado activados, el archivo de salida **Stdout** incluye información detallada acerca de la ejecución de scripts. Este archivo de salida puede ayudarle a identificar donde el script ha producido un error. El archivo de **Stderr** contiene errores que se produjeron durante la ejecución de scripts.
**Problemas comunes al crear asociaciones que ejecutan archivos MOF**
Esta sección contiene información sobre problemas comunes que pueden ocurrir al crear asociaciones que ejecutan archivos MOF y los pasos que hay que seguir para solucionar dichos problemas.
**Mi MOF no se aplicó.**
Si State Manager no pudo aplicar la asociación a los nodos, comience a revisar el archivo de salida **Stderr**. Este archivo puede ayudarle a entender la causa raíz del problema. Además, compruebe lo siguiente:
+ El nodo tiene los permisos de acceso requeridos a todos los buckets de Simple Storage Service (Amazon S3) relacionados con MOF. En concreto:
+ **Permisos s3:GetObject**: necesarios para los archivos MOF de buckets de Amazon S3 privados, así como módulos personalizados en buckets de Amazon S3.
+ **Permiso s3:PutObject**: necesario para escribir los informes de conformidad y el estado de conformidad en los buckets de Amazon S3.
+ Si utiliza etiquetas, asegúrese de que el nodo tenga la política de IAM necesaria. Para usar las etiquetas, el rol de IAM debe tener una política que permita las acciones `ec2:DescribeInstances` y `ssm:ListTagsForResource`.
+ Asegúrese de que el nodo tiene las etiquetas esperadas o los parámetros de SSM asignados.
+ Asegúrese de que las etiquetas o los parámetros de SSM no se hayan escrito erróneamente.
+ Pruebe a aplicar el archivo MOF localmente en el nodo para asegurarse de que no hay un problema con el archivo MOF.
**Parece que mi MOF tuvo errores, pero Systems Manager se ejecutó correctamente.**
Si el documento `AWS-ApplyDSCMofs` se ha ejecutado correctamente, el estado de ejecución de Systems Manager muestra **Success** (Correcto). Este estado no refleja el estado de conformidad del nodo en función de los requisitos de configuración del archivo MOF. Para ver el estado de conformidad de los nodos, consulte los informes de conformidad. Puede ver un informe JSON en el bucket de informes de Amazon S3. Esto se aplica tanto a las ejecuciones de Run Command como a las de State Manager. Además, para State Manager, puede ver detalles de conformidad en la página de conformidad de Systems Manager.
**Estados de Stderr: error de resolución de nombres tras intentar conectar con el servicio**
Este error indica que el script no puede tener acceso a un servicio remoto. Lo más probable es que el script no pueda conectar con Amazon S3. Este problema se produce en la mayoría de los casos cuando el script intenta escribir informes de conformidad o estados de conformidad en el bucket de Amazon S3 facilitado en los parámetros de documentos. Normalmente, este error se produce cuando un entorno informático utiliza un firewall o un proxy transparente que incluya una lista de permitidos. Para resolver este problema, siga estos pasos:
+ Utilice la sintaxis de buckets específica de la región para todos los parámetros de buckets de Amazon S3. Por ejemplo, el parámetro **Mofs to Apply (MOF para aplicar)** debe tener el siguiente formato:
s3:*región-bucket*:*amzn-s3-demo-bucket*:*nombre-archivo-mof*.mof.
A continuación se muestra un ejemplo: :` s3:us-west-2:amzn-s3-demo-bucket:my-mof.mof`
Los nombres de buckets de origen de módulos, estado e informes deben tener el siguiente formato.
*región-bucket*:*amzn-s3-demo-bucket*. A continuación se muestra un ejemplo: `us-west-1:amzn-s3-demo-bucket;`
+ Si la sintaxis específica de la región no corrige el problema, asegúrese de que los nodos de destino pueden obtener acceso a Simple Storage Service (Amazon S3) en la región deseada. Para comprobar esto:
1. Busque el nombre del punto de enlace para Amazon S3 en la región de Amazon S3 adecuada. Para obtener más información, consulte [Puntos de conexión de Amazon S3 Service](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_region) en la *Referencia general de Amazon Web Services*.
1. Inicie sesión en el nodo de destino y ejecute el siguiente comando de ping.
```
ping s3.s3-region.amazonaws.com
```
Si el ping no se ejecuta correctamente, significa que Simple Storage Service (Amazon S3) está fuera de servicio, que un firewall/proxy transparente está bloqueando el acceso a la región de Amazon S3 o que el nodo no tiene acceso a Internet.
## Cómo visualizar los detalles de cumplimiento de recursos de DSC
Systems Manager capta información de conformidad de los errores de los recursos de DSC en el bucket de estado de Amazon S3 **Status Bucket** que especificó cuando ejecutó el documento `AWS-ApplyDSCMofs`. La búsqueda de información acerca de los errores del recurso de DSC en un bucket de Amazon S3 puede llevar tiempo. En su lugar, puede ver esta información en la página **Compliance** (Conformidad) de Systems Manager.
La sección **Compliance resources summary (Resumen de los recursos de cumplimiento** muestra una cuenta de los recursos que fallaron. En el siguiente ejemplo, el **ComplianceType (Tipo de cumplimiento)** es **Custom:DSC (Personalizado:DSC)** y un recurso no conforme.
**nota**
Custom:DSC es el valor predeterminado **ComplianceType** en el documento `AWS-ApplyDSCMofs`. Este valor se puede personalizar.
![\[Ver recuentos en la sección Compliance resources summary (Resumen de recursos de conformidad) de la página Compliance (Conformidad).\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-3.png)
La sección **Details overview for resources** (Información general de los detalles de los recursos) muestra información sobre el recurso de AWS con el recurso de DSC no conforme. En esta sección también se incluye el nombre de MOF, los pasos de ejecución del script y, si procede, un enlace de **View output (Ver salida)** para ver la información del estado detallada.
![\[Ver los detalles de cumplimiento para un fallo de recursos de ejecución MOF\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-1.png)
El enlace **View output** (Ver salida) muestra los últimos 4000 caracteres del estado detallado. Systems Manager comienza con la excepción como primer elemento y, a continuación, vuelve a examinar los mensajes detallados y agrega tantos como pueda hasta que alcanza la cuota de 4000 caracteres. Este proceso muestra los mensajes de registros que salieron antes de lanzar la excepción. Estos mensajes son los más importantes para la resolución de errores.
![\[Ver la salida detallada del problema de cumplimiento del recurso MOF\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-2.png)
Para obtener más información acerca de cómo ver la información de cumplimiento, consulte [Conformidad de AWS Systems Manager](systems-manager-compliance.md).
**Situaciones que afectan a los informes del cumplimiento**
Si la asociación de State Manager falla, no se notifican datos de cumplimiento. En concreto, si un MOF falla en el procesamiento, Systems Manager no notifica ningún elemento de conformidad ya que las asociaciones fallan. Por ejemplo, si Systems Manager intenta descargar un MOF de un bucket de Simple Storage Service (Amazon S3) para el que el nodo no tiene permiso de acceso, la asociación falla y no se notifican datos de conformidad.
Si un recurso en un segundo MOF falla, Systems Manager *sí* notifica los datos de conformidad. Por ejemplo, si un MOF intenta crear un archivo en una unidad que no existe, Systems Manager notifica la conformidad porque el documento de `AWS-ApplyDSCMofs` se puede procesar completamente, lo que significa que la asociación funciona correctamente.
# Creación de asociaciones que ejecuten manuales de estrategia de Ansible
Puede crear asociaciones de State Manager que ejecuten manuales de estrategia de Ansible mediante el documento `AWS-ApplyAnsiblePlaybooks` de SSM. State Manager es una herramienta de AWS Systems Manager. Este documento ofrece los siguientes beneficios para ejecutar cuadernos de trabajo:
+ Compatibilidad con la ejecución de cuadernos de trabajo complejos
+ Soporte para descargar manuales de estrategias de GitHub y Amazon Simple Storage Service (Amazon S3)
+ Compatibilidad con la estructura de cuaderno de trabajo comprimido
+ Registro optimizado
+ Capacidad para especificar qué cuaderno de trabajo ejecutar cuando se empaquetan los cuadernos de trabajo
**nota**
Systems Manager incluye dos documentos de SSM que le permiten crear asociaciones State Manager que ejecutan manuales de estrategia de Ansible: `AWS-RunAnsiblePlaybook` y `AWS-ApplyAnsiblePlaybooks`. El documento `AWS-RunAnsiblePlaybook` está obsoleto. Sigue estando disponible en Systems Manager para fines heredados. Le recomendamos que utilice el documento `AWS-ApplyAnsiblePlaybooks` debido a las mejoras que se describen aquí.
Las asociaciones que ejecutan manuales de estrategia de Ansible no son compatibles con macOS.
**Compatibilidad con la ejecución de cuadernos de trabajo complejos**
El documento `AWS-ApplyAnsiblePlaybooks` admite cuadernos de trabajo complejos agrupados, ya que copia toda la estructura de archivos en un directorio local antes de ejecutar el cuaderno de trabajo principal especificado. Puede proporcionar libros de trabajo de origen en archivos Zip o en una estructura de directorios. El archivo Zip o directorio se pueden almacenar en GitHub o Amazon S3.
**Compatibilidad con la descarga de cuadernos de trabajo desde GitHub**
El documento `AWS-ApplyAnsiblePlaybooks` utiliza el complemento `aws:downloadContent` para descargar archivos del cuaderno de trabajo. Los archivos se pueden almacenar en GitHub un único archivo o como un conjunto combinado de archivos de manual de estrategias. Para descargar contenido desde GitHub, especifique información sobre el repositorio de GitHub en formato JSON. A continuación se muestra un ejemplo.
```
{
"owner":"TestUser",
"repository":"GitHubTest",
"path":"scripts/python/test-script",
"getOptions":"branch:master",
"tokenInfo":"{{ssm-secure:secure-string-token}}"
}
```
**Compatibilidad para descargar cuadernos de trabajo desde Simple Storage Service (Amazon S3**
También puede almacenar y descargar manuales de estrategias de Ansible en Amazon S3 como un único archivo .zip o una estructura de directorios. Para descargar contenido desde Amazon S3, especifique la ruta al archivo. A continuación se incluyen dos ejemplos.
**Ejemplo 1: descargar un archivo de cuaderno de trabajo específico**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/playbook.yml"
}
```
**Ejemplo 2: descargar el contenido de un directorio**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/ansible/webservers/"
}
```
**importante**
Si especifica Amazon S3, el perfil de instancia de AWS Identity and Access Management (IAM) de los nodos administrados debe incluir permisos para el bucket de S3. Para obtener más información, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md).
**Compatibilidad con la estructura de cuaderno de trabajo comprimido**
El documento `AWS-ApplyAnsiblePlaybooks` le permite ejecutar archivos .zip comprimidos en el paquete descargado. El documento comprueba si los archivos descargados contienen un archivo comprimido en formato .zip. Si se encuentra un archivo .zip, el documento descomprime automáticamente el archivo y, a continuación, ejecuta la automatización de Ansible especificada.
**Registro optimizado**
El documento `AWS-ApplyAnsiblePlaybooks` incluye un parámetro opcional para especificar distintos niveles de registro. Especifique -v para un nivel de detalle bajo, -vv o -vvv para un nivel de detalle medio y -vvvv para el registro de nivel de depuración. Estas opciones se asignan directamente a las opciones de detalle de Ansible.
**Capacidad para especificar qué cuaderno de trabajo ejecutar cuando se empaquetan los cuadernos de trabajo**
El documento `AWS-ApplyAnsiblePlaybooks` incluye un parámetro obligatorio para especificar qué cuaderno de trabajo ejecutar cuando se agrupan varios cuadernos de trabajo. Esta opción proporciona flexibilidad para ejecutar cuadernos de trabajo para admitir diferentes casos de uso.
## Comprensión de las dependencias instaladas
Si especifica **True** (Verdadero) para el parámetro **InstallDependencies**, Systems Manager verifica que los nodos tengan las siguientes dependencias instaladas:
+ **Ubuntu Server/Debian Server**: Apt-get (administración de paquetes), Python 3, Ansible, Unzip
+ Versiones compatibles con **Amazon Linux**: Ansible
+ **RHEL**: Python 3, Ansible, Unzip
Si no se encuentra una o varias de estas dependencias, Systems Manager las instala automáticamente.
## Crear una asociación que ejecute manuales de estrategias de Ansible (consola)
En el siguiente procedimiento se describe cómo utilizar la consola de Systems Manager para crear una asociación de State Manager que ejecuta manuales de estrategias de Ansible mediante el documento de `AWS-ApplyAnsiblePlaybooks`.
**Crear una asociación que ejecute manuales de estrategias de Ansible (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 **State Manager**.
1. Elija **State Manager** y, a continuación, **Create association** (Crear asociación).
1. En **Name (Nombre)**, especifique un nombre que le ayude a recordar el objetivo de la asociación.
1. En la lista **Document** (Documento), elija **`AWS-ApplyAnsiblePlaybooks`**.
1. En la sección **Parameters (Parámetros)**, en **Source Type (Tipo de origen)**, elija **GitHub** o **S3**.
**GitHub**
Si elige **GitHub**, ingrese la información del repositorio en el siguiente formato.
```
{
"owner":"user_name",
"repository":"name",
"path":"path_to_directory_or_playbook_to_download",
"getOptions":"branch:branch_name",
"tokenInfo":"{{(Optional)_token_information}}"
}
```
**S3**
Si elige **S3**, ingrese la información de la ruta en el siguiente formato.
```
{
"path":"https://s3.amazonaws.com/path_to_directory_or_playbook_to_download"
}
```
1. En **Install Dependencies (Instalar dependencias)**, elija una opción.
1. (Opcional) En **Playbook File (Archivo de cuaderno de trabajo)**, escriba un nombre de archivo. Si el cuaderno de trabajo está contenido en un archivo Zip, especifique una ruta relativa al archivo Zip.
1. (Opcional) En **Variables adicionales**, escriba las variables que desee que State Manager envíe a Ansible en el tiempo de ejecución.
1. (Opcional) En **Check (Comprobar)**,elija una opción.
1. (Opcional) En **Verbose (Detalle)**, elija una opción.
1. En **Targets (Destinos)**, elija una opción. Para obtener más información acerca del uso de los destinos, 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. En la sección **Specify schedule (Especificar programación)**, elija **On Schedule (De forma programada)** o **No schedule (Sin programación)**. Si elige **On Schedule (De forma programada)**, utilice los botones proporcionados para crear una programación Cron o Rate para la asociación.
1. En la sección **Opciones avanzadas**, en **Gravedad de conformidad**, elija un nivel de gravedad para la asociación. Los informes de conformidad indican si el estado de asociación es conforme o no conforme, junto con el nivel de gravedad que se indique aquí. Para obtener más información, consulte [Acerca de la conformidad de las asociaciones de State Manager](compliance-about.md#compliance-about-association).
1. En la sección **Rate control** (Control de frecuencia), configure las opciones para ejecutar asociaciones de State Manager a través de una flota de nodos administrados. Para obtener más información sobre el uso de controles de frecuencia, 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).
En la sección **Simultaneidad**, elija una opción:
+ Elija **Targets (Destinos)** para introducir un número absoluto de destinos que pueda ejecutar la asociación de forma simultánea.
+ Elija **porcentaje** para introducir un porcentaje del destino definido que puede ejecutar la asociación de forma simultánea.
En la sección **Umbral de error**, elija una opción:
+ Elija **errors (errores)** para especificar un número absoluto de errores permitidos antes de que State Manager deje de ejecutar asociaciones en más destinos.
+ Elija **percentage (porcentaje)** para especificar un porcentaje de errores permitidos antes de que State Manager deje de ejecutar asociaciones en más destinos.
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**.
**nota**
Si utiliza las etiquetas para crear una asociación en uno o varios nodos de destino y después elimina las etiquetas de un nodo, dicho nodo ya no ejecutará la asociación. El nodo se desvincula del documento de State Manager.
## Crear una asociación que ejecute manuales de estrategias de Ansible (CLI)
En el siguiente procedimiento se describe cómo utilizar AWS Command Line Interface (AWS CLI) para crear una asociación de State Manager que ejecute manuales de estrategias de Ansible mediante el documento `AWS-ApplyAnsiblePlaybooks`.
**Crear una asociación que ejecute manuales de estrategias de Ansible (CLI)**
1. 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).
1. Ejecute uno de los siguientes comandos para crear una asociación que ejecute manuales de estrategias de Ansible dirigiendo nodos mediante etiquetas. Reemplace cada *example resource placeholder* con su propia información. El comando (A) especifica GitHub como tipo de origen. El comando (B) especifica Amazon S3 como tipo de origen.
**(A) Origen de GitHub**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner_name\", \"repository\": \"name\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"],"TimeoutSeconds":["3600"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner_name\", \"repository\": \"name\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"], "TimeoutSeconds":["3600"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
A continuación se muestra un ejemplo.
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets "Key=tag:OS,Values=Linux" \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ansibleDocumentTest\", \"repository\": \"Ansible\", \"getOptions\": \"branch:master\"}"],"InstallDependencies":["True"],"PlaybookFile":["hello-world-playbook.yml"],"ExtraVariables":["SSM=True"],"Check":["False"],"Verbose":["-v"]}' \
--association-name "AnsibleAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
**(B) Origen de S**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_playbook_to_download\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_playbook_to_download\"}"],"InstallDependencies":["True_or_False"],"PlaybookFile":["file_name.yml"],"ExtraVariables":["key/value_pairs_separated_by_a_space"],"Check":["True_or_False"],"Verbose":["-v,-vv,-vvv, or -vvvv"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
A continuación se muestra un ejemplo.
```
aws ssm create-association --name "AWS-ApplyAnsiblePlaybooks" \
--targets "Key=tag:OS,Values=Linux" \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/playbook.yml\"}"],"InstallDependencies":["True"],"PlaybookFile":["playbook.yml"],"ExtraVariables":["SSM=True"],"Check":["False"],"Verbose":["-v"]}' \
--association-name "AnsibleAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
**nota**
State ManagerLas asociaciones de no admiten todas las expresiones cron y de frecuencia. Para obtener más información acerca de la creación de expresiones cron y de frecuencia para asociaciones, consulte [Referencia: expresiones cron y rate para Systems Manager](reference-cron-and-rate-expressions.md).
El sistema intenta crear la asociación en los nodos y aplicar inmediatamente el estado.
1. Ejecute el siguiente comando para ver un estado actualizado de la asociación que acaba de crear.
```
aws ssm describe-association --association-id "ID"
```
# Creación de asociaciones que ejecuten recetas de Chef
Puede crear asociaciones de State Manager que ejecuten recetas de Chef con el documento `AWS-ApplyChefRecipes` de SSM. State Manager es una herramienta de AWS Systems Manager. Puede dirigirse a nodos administrados por Systems Manager basados en Linux con el documento `AWS-ApplyChefRecipes` de SSM. Este documento ofrece los siguientes beneficios para ejecutar recetas de Chef:
+ Admite múltiples versiones de Chef (de Chef 11 a Chef 18).
+ Instala automáticamente el software cliente de Chef en los nodos de destino.
+ Opcionalmente, ejecuta [comprobaciones de conformidad de Systems Manager](systems-manager-compliance.md) en nodos de destino y almacena los resultados de las comprobaciones de conformidad en un bucket de Amazon Simple Storage Service (Amazon S3).
+ Ejecuta varios libros de recetas y recetas en una sola ejecución del documento.
+ Opcionalmente, ejecuta recetas en modo `why-run`, para mostrar qué recetas cambian en nodos de destino sin realizar cambios.
+ Opcionalmente aplica atributos JSON personalizados a las ejecuciones de `chef-client`.
+ De forma opcional, aplica atributos JSON personalizados desde un archivo fuente que se almacena en la ubicación que especifique.
Puede utilizar buckets de [Git](#state-manager-chef-git), [GitHub](#state-manager-chef-github), [HTTP](#state-manager-chef-http) o [Amazon S3](#state-manager-chef-s3) como fuentes para descargar los libros de recetas y recetas de Chef que especifique en un documento `AWS-ApplyChefRecipes`.
**nota**
Las asociaciones que ejecutan recetas de Chef no son compatibles con macOS.
## Introducción
Antes de crear un documento `AWS-ApplyChefRecipes`, prepare sus libros de recetas de Chef y su repositorio de libros de recetas. Si aún no tiene un libro de recetas de Chef que desea utilizar, puede comenzar usando un libro de recetas `HelloWorld` de prueba que AWS ha preparado para usted. El documento `AWS-ApplyChefRecipes` ya apunta a este libro de recetas de forma predeterminada. Sus libros de recetas deben configurarse de forma similar a la siguiente estructura de directorios. En el siguiente ejemplo, `jenkins` y `nginx` son ejemplos de libros de recetas de Chef que están disponibles en [https://supermarket.chef.io/](https://supermarket.chef.io/) en el sitio web de Chef.
Aunque AWS no puede admitir oficialmente libros de recetas en el sitio web de [https://supermarket.chef.io/](https://supermarket.chef.io/) muchos de ellos trabajan con el documento `AWS-ApplyChefRecipes`. Los siguientes son ejemplos de criterios para determinar cuándo se está probando un libro de recetas de la comunidad:
+ El libro de recetas debe admitir los sistemas operativos basados en Linux de los nodos Systems Manager administrados a los que se dirige.
+ El libro de recetas debe ser válido para la versión cliente de Chef (de Chef 11 a Chef 18) que utilice.
+ El libro de recetas es compatible con Chef Infra Client y no requiere un servidor Chef.
Compruebe que puede comunicarse con el sitio web de `Chef.io` para que los libros de recetas que especifique en la lista de ejecución se puedan instalar cuando se ejecute el documento de Systems Manager (documento de SSM). Se admite el uso de una carpeta `cookbooks`, pero no es necesario; puede almacenar libros de recetas directamente bajo el nivel raíz.
```
└── cookbooks (optional level)
├── jenkins
│ ├── metadata.rb
│ └── recipes
└── nginx
├── metadata.rb
└── recipes
```
**importante**
Antes de crear una asociación State Manager que ejecute recetas de Chef, tenga en cuenta que la ejecución del documento instala el software cliente de Chef en los nodos administrados por Systems Manager, a menos que establezca el valor de **la versión de cliente de Chef** a `None`. Esta operación utiliza un script de instalación de Chef para instalar componentes de Chef en su nombre. Antes de ejecutar un documento `AWS-ApplyChefRecipes`, asegúrese de que su empresa pueda cumplir con los requisitos legales aplicables, incluidos los términos de licencia aplicables al uso del software Chef. Para obtener más información, consulte el [sitio web de Chef](https://www.chef.io/).
Systems Manager puede entregar informes de conformidad a un bucket de S3, a la consola de Systems Manager o hacer que los resultados de conformidad estén disponibles en respuesta a los comandos de la API de Systems Manager. Para ejecutar informes de conformidad de Systems Manager, el perfil de instancias adjuntado a nodos administrados por Systems Manager debe tener permisos para escribir en el bucket de S3. El perfil de instancias debe tener permisos para poder utilizar la API `PutComplianceItem` de Systems Manager. Para obtener más información acerca de la conformidad de Systems Manager, consulte [Conformidad de AWS Systems Manager](systems-manager-compliance.md).
### Registro de la ejecución del documento
Cuando ejecuta un documento de Systems Manager (documento de SSM) mediante una asociación de State Manager, puede configurar la asociación para elegir la salida de la ejecución del documento y puede enviar la salida a Amazon S3 o los Registros de Amazon CloudWatch (Registros de CloudWatch). Para facilitar la solución de problemas cuando una asociación ha terminado de ejecutarse, compruebe que la asociación esté configurada para escribir la salida del comando en un bucket de Amazon S3 o los Registros de CloudWatch. Para obtener más información, consulte [Trabajo con asociaciones en Systems Manager](state-manager-associations.md).
## Aplicación de atributos JSON a los destinos al ejecutar una receta
Puede especificar los atributos JSON para que su cliente de Chef los aplique a los nodos de destino durante una ejecución de asociación. Al configurar la asociación, puede proporcionar JSON sin procesar o la ruta a un archivo JSON almacenado en Amazon S3.
Utilice los atributos JSON cuando desee personalizar la forma en que se ejecuta la receta sin tener que modificar la propia receta, por ejemplo:
+ **Anular un número reducido de atributos**
Use un JSON personalizado para evitar tener que mantener varias versiones de una receta para adaptarse a pequeñas diferencias.
+ **Proporcionar los valores de las variables**
Use un JSON personalizado para especificar los valores que pueden cambiar de una ejecución a otra. Por ejemplo, si sus libros de recetas de Chef configuran una aplicación de terceros que acepta pagos, puede usar un JSON personalizado para especificar la URL del punto de conexión de pago.
**Especificar atributos en JSON sin procesar**
El siguiente es un ejemplo del formato que puede usar para especificar atributos JSON personalizados para su receta de Chef.
```
{"filepath":"/tmp/example.txt", "content":"Hello, World!"}
```
**Especificación de una ruta a un archivo JSON**
El siguiente es un ejemplo del formato que puede usar para especificar la ruta a los atributos JSON personalizados para su receta de Chef.
```
{"sourceType":"s3", "sourceInfo":"someS3URL1"}, {"sourceType":"s3", "sourceInfo":"someS3URL2"}
```
## Usar Git como fuente para el libro de recetas
El documento `AWS-ApplyChefRecipes` utiliza el complemento [aws:downloadContent para descargar libros de recetas de Chef](documents-command-ssm-plugin-reference.md#aws-downloadContent). Para descargar contenido desde Git, especifique la información sobre el repositorio de Git en formato JSON, como se muestra en el siguiente ejemplo. Reemplace cada *example-resource-placeholder* con su propia información.
```
{
"repository":"GitCookbookRepository",
"privateSSHKey":"{{ssm-secure:ssh-key-secure-string-parameter}}",
"skipHostKeyChecking":"false",
"getOptions":"branch:refs/head/main",
"username":"{{ssm-secure:username-secure-string-parameter}}",
"password":"{{ssm-secure:password-secure-string-parameter}}"
}
```
## Usar GitHub como fuente de libro de recetas
El documento `AWS-ApplyChefRecipes` utiliza el complemento [aws:downloadContent](documents-command-ssm-plugin-reference.md#aws-downloadContent) para descargar libros de recetas. Para descargar contenido desde GitHub, especifique la información sobre el repositorio de GitHub en formato JSON, como se muestra en el siguiente ejemplo. Reemplace cada *example-resource-placeholder* con su propia información.
```
{
"owner":"TestUser",
"repository":"GitHubCookbookRepository",
"path":"cookbooks/HelloWorld",
"getOptions":"branch:refs/head/main",
"tokenInfo":"{{ssm-secure:token-secure-string-parameter}}"
}
```
## Usar HTTP como fuente para el libro de recetas
Puede almacenar los libros de recetas de Chef en una ubicación HTTP personalizada ya sea como un solo archivo `.zip`, un archivo `tar.gz` o como una estructura de directorios. Para descargar contenido desde HTTP, especifique la ruta al archivo o al directorio en formato JSON, como se muestra en el siguiente ejemplo. Reemplace cada *example-resource-placeholder* con su propia información.
```
{
"url":"https://my.website.com/chef-cookbooks/HelloWorld.zip",
"allowInsecureDownload":"false",
"authMethod":"Basic",
"username":"{{ssm-secure:username-secure-string-parameter}}",
"password":"{{ssm-secure:password-secure-string-parameter}}"
}
```
## Uso de Amazon S3 como fuente de libro de recetas
También, puede almacenar y descargar libros de recetas de Chef en Amazon S3 como un único archivo `.zip`, un archivo `tar.gz` o como una estructura de directorios. Para descargar contenido desde Amazon S3, especifique la ruta al archivo en formato JSON, como se muestra en los ejemplos siguientes. Reemplace cada *example-resource-placeholder* con su propia información.
**Ejemplo 1: descargar un libro de recetas específico**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks/HelloWorld.zip"
}
```
**Ejemplo 2: descargar el contenido de un directorio**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks-test/HelloWorld"
}
```
**importante**
Si especifica Simple Storage Service (Amazon S3), el perfil de instancias de AWS Identity and Access Management (IAM) en los nodos administrados debe configurarse con la política `AmazonS3ReadOnlyAccess`. Para obtener más información, consulte [Configuración de permisos de instancia requeridos para Systems Manager](setup-instance-permissions.md).
## Crear una asociación que ejecute recetas de Chef (consola)
En el siguiente procedimiento se describe cómo utilizar la consola de Systems Manager para crear una asociación de State Manager que ejecuta libros de recetas de Chef mediante el documento de `AWS-ApplyChefRecipes`.
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**.
1. Elija **State Manager** y, a continuación, **Create association** (Crear asociación).
1. En **Name (Nombre)**, escriba un nombre que le ayude a recordar el objetivo de la asociación.
1. En la lista **Document** (Documento), elija **`AWS-ApplyChefRecipes`**.
1. En **Parámetros**, en **Tipo de origen**, seleccione **Git**, **GitHub**, **HTTP** o **S3**.
1. En **Información sobre el origen**, introduzca la información sobre la fuente del libro de recetas en el formato adecuado para el **Tipo de origen** que seleccionó en el paso 6. Para obtener más información, consulte los temas siguientes:
+ [Usar Git como fuente para el libro de recetas](#state-manager-chef-git)
+ [Usar GitHub como fuente de libro de recetas](#state-manager-chef-github)
+ [Usar HTTP como fuente para el libro de recetas](#state-manager-chef-http)
+ [Uso de Amazon S3 como fuente de libro de recetas](#state-manager-chef-s3)
1. En **Run list (Lista de ejecución)**, enumera las recetas que desea ejecutar en el siguiente formato, separando cada receta con una coma como se muestra. No incluya un espacio después de la coma. Reemplace cada *example-resource-placeholder* con su propia información.
```
recipe[cookbook-name1::recipe-name],recipe[cookbook-name2::recipe-name]
```
1. (Opcional) Especifique los atributos JSON personalizados que desee que el cliente de Chef pase a los nodos de destino.
1. En **Contenido de atributos JSON**, agregue cualquier atributo que desee que el cliente de Chef pase a los nodos de destino.
1. En **Contenido de atributos JSON**, agregue las rutas a los atributos que desee que el cliente de Chef pase a los nodos de destino.
Para obtener más información, consulte [Aplicación de atributos JSON a los destinos al ejecutar una receta](#apply-custom-json-attributes).
1. Para **Versión de cliente de Chef**, especifique una versión de Chef. Los valores válidos son de `11` a `18` o `None`. Si especifica un número entre `11` y `18` (inclusive), Systems Manager instala la versión correcta del cliente de Chef en los nodos de destino. Si especifica `None`, Systems Manager no instala el cliente de Chef en nodos de destino antes de ejecutar las recetas del documento.
1. (Opcional) En **Argumentos del cliente deChef Chef**, especifique argumentos adicionales que sean compatibles con la versión de Chef que esté utilizando. Para obtener más información acerca de los argumentos admitidos, ejecute `chef-client -h` en un nodo que esté ejecutando el cliente de Chef.
1. (Opcional) Active **Why-Run** para mostrar los cambios que se realizaron en los nodos de destino si se ejecutan las recetas, sin cambiar realmente los nodos de destino.
1. Para **Compliance severity** (Severidad de conformidad), elija la severidad de los resultados de conformidad de configuración de Systems Manager que desee informar. Los informes de conformidad indican si el estado de asociación es conforme o no conforme, junto con el nivel de gravedad que especifique. Los informes de conformidad se almacenan en un bucket de S3 que se especifica como valor del parámetro de **Bucket del informe de conformidad** (paso 14). Para obtener más información acerca de la conformidad, consulte [Detalles sobre el cumplimiento](compliance-about.md) en esta guía.
Los análisis de conformidad miden la desviación entre la configuración especificada en las recetas de Chef y los recursos de nodo. Los valores válidos son `Critical`, `High`, `Medium`, `Low`, `Informational`, `Unspecified` o `None`. Para omitir los informes de cumplimiento, elija `None`.
1. En **Compliance type (Tipo de conformidad)**, especifique el tipo de conformidad para el que desea que se informe de los resultados. Los valores válidos son `Association` para asociaciones de State Manager o `Custom:`*custom-type*. El valor predeterminado es `Custom:Chef`.
1. En **Bucket de informe de conformidad**, ingrese el nombre de un bucket de S3 en el que almacene información sobre cada ejecución de Chef realizada por este documento, incluidos los resultados de configuración de recursos y de conformidad.
1. En **Rate control** (Control de frecuencia), configure las opciones para ejecutar asociaciones de State Manager a través de una flota de nodos administrados. Para obtener más información sobre el uso de controles de frecuencia, 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).
En **Concurrency (Simultáneamente)**, elija una opción:
+ Elija **Targets (Destinos)** para introducir un número absoluto de destinos que pueda ejecutar la asociación de forma simultánea.
+ Elija **porcentaje** para introducir un porcentaje del destino definido que puede ejecutar la asociación de forma simultánea.
En **Error threshold (Umbral de error)**, elija una opción:
+ Elija **errors (errores)** para especificar un número absoluto de errores permitidos antes de que State Manager deje de ejecutar asociaciones en más destinos.
+ Elija **percentage (porcentaje)** para especificar un porcentaje de errores permitidos antes de que State Manager deje de ejecutar asociaciones en más destinos.
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**.
## Crear una asociación que ejecute recetas de Chef (CLI)
En el siguiente procedimiento se describe cómo utilizar la AWS Command Line Interface (AWS CLI) para crear una asociación de State Manager que ejecute cuadernos de trabajo de Chef mediante el documento `AWS-ApplyChefRecipes`.
1. 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).
1. Ejecute uno de los siguientes comandos para crear una asociación que ejecute libros de recetas de Chef en nodos de destino que contengan las etiquetas especificadas. Use el comando adecuado para el tipo de fuente y el sistema operativo de su libro de recetas. Reemplace cada *example-resource-placeholder* con su propia información.
1. **Origen de Git**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["Git"],"SourceInfo":["{\"repository\":\"repository-name\", \"getOptions\": \"branch:branch-name\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["Git"],"SourceInfo":["{\"repository\":\"repository-name\", \"getOptions\": \"branch:branch-name\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' ^
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
1. **Origen de GitHub**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner-name\", \"repository\": \"name\", \"path\": \"path-to-directory-or-cookbook-to-download\", \"getOptions\": \"branch:branch-name\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"owner-name\", \"repository\": \"name\", \"path\": \"path-to-directory-or-cookbook-to-download\", \"getOptions\": \"branch:branch-name\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json}"], "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' ^
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
A continuación se muestra un ejemplo.
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:OS,Values=Linux \
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ChefRecipeTest\", \"repository\": \"ChefCookbooks\", \"path\": \"cookbooks/HelloWorld\", \"getOptions\": \"branch:master\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' \
--association-name "MyChefAssociation" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:OS,Values=Linux ^
--parameters '{"SourceType":["GitHub"],"SourceInfo":["{\"owner\":\"ChefRecipeTest\", \"repository\": \"ChefCookbooks\", \"path\": \"cookbooks/HelloWorld\", \"getOptions\": \"branch:master\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' ^
--association-name "MyChefAssociation" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
1. **Origen de HTTP**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["HTTP"],"SourceInfo":["{\"url\":\"url-to-zip-file|directory|cookbook\", \"authMethod\": \"auth-method\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" \
--schedule-expression "cron-or-rate-expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["HTTP"],"SourceInfo":["{\"url\":\"url-to-zip-file|directory|cookbook\", \"authMethod\": \"auth-method\", \"username\": \"{{ ssm-secure:username-secure-string-parameter }}\", \"password\": \"{{ ssm-secure:password-secure-string-parameter }}\"}"], "RunList":["{\"recipe[cookbook-name-1::recipe-name]\", \"recipe[cookbook-name-2::recipe-name]\"}"], "JsonAttributesContent": ["{custom-json-content}"], "JsonAttributesSources": "{\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-1\"}, {\"sourceType\":\"s3\", \"sourceInfo\":\"s3-bucket-endpoint-2\"}", "ChefClientVersion": ["version-number"], "ChefClientArguments":["{chef-client-arguments}"], "WhyRun": boolean, "ComplianceSeverity": ["severity-value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["s3-bucket-name"]}' \
--association-name "name" ^
--schedule-expression "cron-or-rate-expression"
```
------
1. **Origen de Amazon S**
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets Key=tag:TagKey,Values=TagValue \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_cookbook_to_download\"}"], "RunList":["{\"recipe[cookbook_name1::recipe_name]\", \"recipe[cookbook_name2::recipe_name]\"}"], "JsonAttributesContent": ["{Custom_JSON}"], "ChefClientVersion": ["version_number"], "ChefClientArguments":["{chef_client_arguments}"], "WhyRun": true_or_false, "ComplianceSeverity": ["severity_value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["amzn-s3-demo-bucket"]}' \
--association-name "name" \
--schedule-expression "cron_or_rate_expression"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets Key=tag:TagKey,Values=TagValue ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/path_to_Zip_file,_directory,_or_cookbook_to_download\"}"], "RunList":["{\"recipe[cookbook_name1::recipe_name]\", \"recipe[cookbook_name2::recipe_name]\"}"], "JsonAttributesContent": ["{Custom_JSON}"], "ChefClientVersion": ["version_number"], "ChefClientArguments":["{chef_client_arguments}"], "WhyRun": true_or_false, "ComplianceSeverity": ["severity_value"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["amzn-s3-demo-bucket"]}' ^
--association-name "name" ^
--schedule-expression "cron_or_rate_expression"
```
------
A continuación se muestra un ejemplo.
------
#### [ Linux & macOS ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" \
--targets "Key=tag:OS,Values= Linux" \
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/HelloWorld\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' \
--association-name "name" \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association --name "AWS-ApplyChefRecipes" ^
--targets "Key=tag:OS,Values= Linux" ^
--parameters '{"SourceType":["S3"],"SourceInfo":["{\"path\":\"https://s3.amazonaws.com/amzn-s3-demo-bucket/HelloWorld\"}"], "RunList":["{\"recipe[HelloWorld::HelloWorldRecipe]\", \"recipe[HelloWorld::InstallApp]\"}"], "JsonAttributesContent": ["{\"state\": \"visible\",\"colors\": {\"foreground\": \"light-blue\",\"background\": \"dark-gray\"}}"], "ChefClientVersion": ["14"], "ChefClientArguments":["{--fips}"], "WhyRun": false, "ComplianceSeverity": ["Medium"], "ComplianceType": ["Custom:Chef"], "ComplianceReportBucket": ["ChefComplianceResultsBucket"]}' ^
--association-name "name" ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
El sistema crea la asociación y, a menos que la expresión cron o rate especificada lo impida, el sistema ejecuta la asociación en los nodos de destino.
**nota**
State ManagerLas asociaciones de no admiten todas las expresiones cron y de frecuencia. Para obtener más información acerca de la creación de expresiones cron y de frecuencia para asociaciones, consulte [Referencia: expresiones cron y rate para Systems Manager](reference-cron-and-rate-expressions.md).
1. Ejecute el siguiente comando para ver el estado de la asociación que acaba de crear.
```
aws ssm describe-association --association-id "ID"
```
## Visualización de los detalles de cumplimiento del recurso de Chef
Systems Manager captura información de conformidad sobre los recursos administrados por Chef en el valor **Bucket de informe de conformidad** de Amazon S3 que especificó cuando ejecutó el documento `AWS-ApplyChefRecipes`. La búsqueda de información acerca de los errores del recurso de Chef en un bucket de S3 puede llevar tiempo. En su lugar, puede ver esta información en la página **Compliance (Conformidad)** de Systems Manager.
Un análisis de conformidad de Systems Manager recopila información acerca de los recursos de los nodos administrados que se crearon o se registraron en la ejecución más reciente de Chef. Los recursos pueden incluir archivos, directorios, servicios de `systemd`, paquetes de `yum`, archivos con plantillas, paquetes de `gem` y libros de recetas dependientes, entre otros.
La sección **Compliance resources summary (Resumen de los recursos de cumplimiento** muestra una cuenta de los recursos que fallaron. En el siguiente ejemplo, el **Tipo de conformidad** es **Personalizado: Chef** y un recurso no conforme.
**nota**
`Custom:Chef` es el valor **ComplianceType** predeterminado del documento `AWS-ApplyChefRecipes`. Este valor se puede personalizar.
![\[Ver recuentos en la sección Compliance resources summary (Resumen de recursos de conformidad) de la página Compliance (Conformidad).\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/state-manager-chef-compliance-summary.png)
La sección **Details overview for resources** (Información general de los detalles de los recursos) muestra información sobre el recurso de AWS que no cumple los requisitos. Esta sección también incluye el tipo de recursos de Chef con el que se ejecutó la conformidad, la gravedad del problema, el estado de conformidad y los vínculos a información adicional cuando corresponda.
![\[Visualización de los detalles de conformidad de un error de recurso administrado por Chef\]](http://docs.aws.amazon.com/es_es/systems-manager/latest/userguide/images/state-manager-chef-compliance-details.png)
**View output** (Ver salida) muestra los últimos 4000 caracteres del estado detallado. Systems Manager comienza con la excepción como primer elemento, encuentra mensajes detallados y los muestra hasta que alcanza la cuota de 4000 caracteres. Este proceso muestra los mensajes de registros que salieron antes de lanzar la excepción. Estos mensajes son los más importantes para la resolución de errores.
Para obtener más información acerca de cómo ver la información de cumplimiento, consulte [Conformidad de AWS Systems Manager](systems-manager-compliance.md).
**importante**
Si la asociación de State Manager falla, no se notifican datos de cumplimiento. Por ejemplo, si Systems Manager intenta descargar un libro de recetas de Chef de un bucket de S3 para el cual el nodo no tiene permiso de acceso, la asociación falla y Systems Manager no notifica datos de conformidad.
# Tutorial: actualización automática de SSM Agent con AWS CLI
El siguiente procedimiento le guía por el proceso de crear una asociación de State Manager con AWS Command Line Interface. La asociación actualiza automáticamente el SSM Agent según la programación que especifique. Para obtener más información acerca de SSM Agent, consulte [Uso de SSM Agent](ssm-agent.md). Para personalizar la programación de actualización de SSM Agent mediante la consola, consulte [Actualización automática de SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console).
Si desea recibir notificaciones sobre actualizaciones de SSM Agent, suscríbase a la página de [SSM Agent Release Notes](https://github.com/aws/amazon-ssm-agent/blob/master/RELEASENOTES.md) en GitHub.
**Antes de empezar**
Antes de completar el siguiente procedimiento, compruebe que tiene al menos una instancia de Amazon Elastic Compute Cloud (Amazon EC2) en ejecución para Linux, macOS o Windows Server y que esté configurada para Systems Manager. Para obtener más información, consulte [Configuración de nodos administrados para AWS Systems Manager](systems-manager-setting-up-nodes.md).
Si crea una asociación mediante la AWS CLI o AWS Tools for Windows PowerShell, utilice el parámetro `--Targets` para definir las instancias, tal y como se muestra en el siguiente ejemplo. No utilice el parámetro `--InstanceID`. El parámetro `--InstanceID` es un parámetro heredado.
**Si desea crear una asociación para actualizar automáticamente el SSM Agent**
1. 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).
1. Ejecute el siguiente comando para crear una asociación dirigiéndose a instancias con las etiquetas de Amazon Elastic Compute Cloud (Amazon EC2). Reemplace cada *example resource placeholder* con su propia información. El parámetro `Schedule` establece una programación para ejecutar la asociación todos los domingos a las 2:00. (UTC).
State ManagerLas asociaciones de no admiten todas las expresiones cron y de frecuencia. Para obtener más información acerca de la creación de expresiones cron y de frecuencia para asociaciones, consulte [Referencia: expresiones cron y rate para Systems Manager](reference-cron-and-rate-expressions.md).
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=tag:tag_key,Values=tag_value \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=tag:tag_key,Values=tag_value ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
Puede dirigir varias instancias especificando los ID de instancia en una lista separada por comas.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)"
```
------
Puede especificar la versión de SSM Agent que desea actualizar.
------
#### [ Linux & macOS ]
```
aws ssm create-association \
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID \
--name AWS-UpdateSSMAgent \
--schedule-expression "cron(0 2 ? * SUN *)" \
--parameters version=ssm_agent_version_number
```
------
#### [ Windows ]
```
aws ssm create-association ^
--targets Key=instanceids,Values=instance_ID,instance_ID,instance_ID ^
--name AWS-UpdateSSMAgent ^
--schedule-expression "cron(0 2 ? * SUN *)" ^
--parameters version=ssm_agent_version_number
```
------
El sistema devuelve información similar a la siguiente.
```
{
"AssociationDescription": {
"ScheduleExpression": "cron(0 2 ? * SUN *)",
"Name": "AWS-UpdateSSMAgent",
"Overview": {
"Status": "Pending",
"DetailedStatus": "Creating"
},
"AssociationId": "123..............",
"DocumentVersion": "$DEFAULT",
"LastUpdateAssociationDate": 1504034257.98,
"Date": 1504034257.98,
"AssociationVersion": "1",
"Targets": [
{
"Values": [
"TagValue"
],
"Key": "tag:TagKey"
}
]
}
}
```
El sistema intenta crear la asociación en las instancias y aplicar el estado después de la creación. El estado de la asociación muestra `Pending`.
1. Ejecute el siguiente comando para ver un estado actualizado de la asociación que creó.
```
aws ssm list-associations
```
Si las instancias *no* están ejecutando la versión más reciente del SSM Agent, el estado muestra `Failed`. Cuando se publica una nueva versión del SSM Agent, la asociación instala automáticamente el nuevo agente y el estado es `Success` (Correcto).
# Tutorial: actualización automática de los controladores PV en las instancias de EC2 de Windows Server
Las Amazon Machine Images de Windows Server para Amazon (AMIs) incluyen un conjunto de controladores que permiten el acceso a hardware virtualizado. Amazon Elastic Compute Cloud (Amazon EC2) utiliza estos controladores para mapear el almacén de instancias y los volúmenes de Amazon Elastic Block Store (Amazon EBS) a sus dispositivos. Se recomienda instalar los últimos controladores para mejorar la estabilidad y el rendimiento de las instancias EC2 en Windows Server. Para obtener más información acerca de los controladores PV, consulte [Controladores de AWS PV](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/xen-drivers-overview.html#xen-driver-awspv).
En la siguiente explicación, se muestra cómo configurar una asociación de State Manager para descargar e instalar automáticamente los nuevos controladores de AWS PV cuando estén disponibles. State Manager es una herramienta de AWS Systems Manager.
**Antes de empezar**
Antes de completar el siguiente procedimiento, verifique que tiene al menos una instancia de Amazon EC2 para Windows Server en ejecución que esté configurada para Systems Manager. Para obtener más información, consulte [Configuración de nodos administrados para AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Para crear una asociación de State Manager que actualice automáticamente los controladores PV**
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**.
1. Elija **Crear asociación**.
1. En el campo **Nombre**, escriba un nombre descriptivo para la asociación.
1. En la lista **Document** (Documento), elija `AWS-ConfigureAWSPackage`.
1. En la sección **Parámetros**, realice lo siguiente:
+ En **Acción**, elija **Instalar**.
+ En **Tipo de instalación**, elija **Desinstalar y volver a instalar**.
**nota**
Las actualizaciones locales no son compatibles con este paquete. Debe desinstalarse y reinstalarse.
+ En **Nombre**, escriba **AWSPVDriver**.
No es necesario introducir nada para la **versión** y **los argumentos adicionales**.
1. En la sección **Targets** (Destinos), para elegir los nodos administrados en los que desea ejecutar esta operación, especifique las etiquetas, seleccione las instancias o los dispositivos de borde manualmente o especifique un grupo de recursos.
**sugerencia**
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.
**nota**
Si elige dirigirse a las instancias mediante etiquetas y especifica etiquetas que se mapean a instancias de Linux, la asociación se realiza correctamente en la instancia de Windows Server, pero no en las instancias de Linux. El estado general de la asociación muestra **Failed**.
1. En el área **Especificar la programación**, elija si desea ejecutar la asociación según la programación que usted configure o solo una vez. Los controladores PV actualizados se lanzan varias veces al año, por lo que puede programar la asociación para que se ejecute una vez al mes, si lo desea.
1. En el área **Opciones avanzadas**, en **Gravedad de conformidad**, elija un nivel de gravedad para la asociación. Los informes de conformidad indican si el estado de asociación es conforme o no conforme, junto con el nivel de gravedad que se indique aquí. Para obtener más información, consulte [Acerca de la conformidad de las asociaciones de State Manager](compliance-about.md#compliance-about-association).
1. En **Rate control** (Control de velocidad):
+ En **Concurrency** (Simultaneidad), especifique un número o un porcentaje de los nodos administrados en los que desea ejecutar el comando al mismo tiempo.
**nota**
Si seleccionó los destinos mediante la especificación de etiquetas aplicadas a nodos administrados o de grupos de recursos de AWS y no está seguro de cuántos nodos administrados tienen destino, limite el número de destinos que puede ejecutar el documento al mismo tiempo. Para ello, especifique un porcentaje.
+ En **Error threshold** (Umbral de errores), especifique cuándo desea parar la ejecución del comando en los demás nodos administrados después de que haya fallado en un número o un porcentaje de los nodos. Por ejemplo, si especifica tres errores, Systems Manager dejará de enviar el comando cuando se reciba el cuarto error. Los nodos administrados que estén procesando el comando todavía pueden enviar errores.
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. (Opcional) En la sección de **alarma de CloudWatch**, en **Nombre de alarma**, elija una alarma de CloudWatch existente para aplicarla a su tarea de monitoreo.
**nota**
Tenga en cuenta la siguiente información sobre este paso.
La lista de alarmas muestra un máximo de 100 alarmas. Si no ve su alarma en la lista, utilice la AWS Command Line Interface para crear la asociación. Para obtener más información, consulte [Cómo rear una asociación (línea de comandos)](state-manager-associations-creating.md#create-state-manager-association-commandline).
Para adjuntar una alarma de CloudWatch a su comando, la entidad principal de IAM que crea la asociación debe tener permiso para la acción `iam:createServiceLinkedRole`. Para obtener más información sobre las alarmas de CloudWatch, consulte [Uso de alarmas de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Tenga en cuenta que si la alarma se activa, no se ejecutarán automatizaciones o invocaciones de comandos pendiente.
1. Elija **Crear asociación** y, a continuación, **Cerrar**. El sistema intenta crear la asociación en las instancias y aplicar inmediatamente el estado.
Si ha creado la asociación en una o varias instancias de Amazon EC2 en Windows Server, el estado cambia a **Success** (Correcto). Si las instancias no están configuradas para Systems Manager, o si se ha dirigido accidentalmente a instancias de Linux, el estado muestra **Failed** (Error).
Si el estado es **Failed** (Error), elija el ID de asociación, elija la pestaña **Resources** (Recursos) y, a continuación, asegúrese de que la asociación se ha creado correctamente en las instancias EC2 en Windows Server. Si las instancias EC2 en Windows Server tienen el estado **Failed** (Error), asegúrese de que SSM Agent se está ejecutando en la instancia y que esta se ha configurado como un rol de AWS Identity and Access Management (IAM) en Systems Manager. Para obtener más información, consulte [Cómo configurar la consola unificada de Systems Manager para una organización](systems-manager-setting-up-organizations.md).