• Das AWS Systems Manager CloudWatch Dashboard wird nach dem 30. April 2026 nicht mehr verfügbar sein. Kunden können weiterhin die CloudWatch Amazon-Konsole verwenden, um ihre CloudWatch Amazon-Dashboards anzusehen, zu erstellen und zu verwalten, so wie sie es heute tun. Weitere Informationen finden Sie in der [Amazon CloudWatch Dashboard-Dokumentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# AWS Systems Manager Knoten-Tools
AWS Systems Manager bietet die folgenden Tools für den Zugriff, die Verwaltung und Konfiguration Ihrer *verwalteten Knoten*. Ein verwalteter Knoten ist eine Maschine, die für die Verwendung mit Systems Manager in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) konfiguriert ist.
**Topics**
+ [AWS Systems Manager-Compliance](systems-manager-compliance.md)
+ [AWS Systems Manager Distributor](distributor.md)
+ [AWS Systems Manager Fleet Manager](fleet-manager.md)
+ [AWS Systems Manager Hybride Aktivierungen](activations.md)
+ [AWS Systems Manager-Bestand](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)
# AWS Systems Manager-Compliance
Sie können Compliance, ein Tool in, verwenden AWS Systems Manager, um Ihre Flotte verwalteter Knoten auf Patch-Compliance und Konfigurationsinkonsistenzen zu überprüfen. Sie können Daten aus mehreren Regionen sammeln und aggregieren AWS-Konten und dann nach bestimmten Ressourcen suchen, die nicht den Vorschriften entsprechen. Standardmäßig zeigt Compliance aktuelle Compliance-Daten zum Patchen in Patch Manager und Assoziationen in State Manager an. (Patch Manager und State Manager sind ebenfalls beide Tools in AWS Systems Manager.) Um mit Compliance zu beginnen, öffnen Sie die [Systems-Manager-Konsole](https://console.aws.amazon.com//systems-manager/compliance). Wählen Sie im linken Navigationsbereich **Compliance**.
Daten zur Patch-Konformität von Patch Manager können an gesendet werden AWS Security Hub CSPM. Security Hub CSPM bietet Ihnen einen umfassenden Überblick über Ihre Sicherheitswarnungen mit hoher Priorität und den Compliance-Status. Er überwacht auch den Patching-Status Ihrer Flotte. Weitere Informationen finden Sie unter [Integrieren Patch Manager mit AWS Security Hub CSPM](patch-manager-security-hub-integration.md).
Compliance bietet die folgenden zusätzlichen Vorteile und Funktionen:
+ Zeigen Sie den Compliance-Verlauf und die Änderungsnachverfolgung für Patch Manager-Patching-Daten und State Manager-Zuordnungen mithilfe von AWS Config an.
+ Passen Sie Compliance an, um Ihre eigenen Compliance-Typen auf Grundlage Ihrer IT- oder Business-Anforderungen zu erstellen.
+ Beheben Sie ProblemeRun Command, indem Sie ein anderes Tool in AWS Systems Manager oder Amazon EventBridge verwenden. State Manager
+ Portieren Sie Daten zu Amazon Athena und Amazon Quick, um flottenweite Berichte zu erstellen.
**EventBridge Unterstützung**
Dieses Systems Manager Manager-Tool wird in den EventBridge Amazon-Regeln als *Ereignistyp* unterstützt. Weitere Informationen finden Sie unter [Überwachung von Systems Manager Manager-Ereignissen mit Amazon EventBridge](monitoring-eventbridge-events.md) und [Referenz: EventBridge Amazon-Ereignistypen und -muster für Systems Manager](reference-eventbridge-events.md).
**Chef InSpec-Integration**
Systems Manager lässt sich in integrieren [https://www.chef.io/inspec/](https://www.chef.io/inspec/). InSpec ist ein Open-Source-Runtime-Framework, mit dem Sie menschenlesbare Profile auf GitHub Amazon Simple Storage Service (Amazon S3) erstellen können. Anschließend können Sie Systems Manager verwenden, um Compliance-Scans auszuführen und konforme bzw. nicht konforme Knoten anzuzeigen. Weitere Informationen finden Sie unter [Verwenden von Chef InSpec-Profilen mit Systems Manager Compliance](integration-chef-inspec.md).
**Preisgestaltung**
Compliance wird ohne Zusatzkosten angeboten. Sie zahlen nur für die AWS Ressourcen, die Sie nutzen.
**Topics**
+ [Erste Schritte mit Compliance](compliance-prerequisites.md)
+ [Konfigurieren von Berechtigungen für die Compliance](compliance-permissions.md)
+ [Erstellen einer Ressource Data Sync für Compliance](compliance-datasync-create.md)
+ [Erfahren Sie mehr über Compliance](compliance-about.md)
+ [Löschen einer Ressource Data Sync für Compliance](systems-manager-compliance-delete-RDS.md)
+ [Beheben von Compliance-Problemen mithilfe von EventBridge](compliance-fixing.md)
+ [Weisen Sie benutzerdefinierte Compliance-Metadaten zu mithilfe der AWS CLI](compliance-custom-metadata-cli.md)
# Erste Schritte mit Compliance
Führen Sie die folgenden Schritte durch, um Compliance, ein Tool in AWS Systems Manager, zu verwenden.
****
| Aufgabe | Weitere Informationen |
| --- | --- |
| Compliance funktioniert mit Patch-Daten in Patch Manager und Zuordnungen in State Manager. (Patch Manager und State Manager sind ebenfalls Tools in AWS Systems Manager.) Compliance funktioniert auch mit benutzerdefinierten Kompatibilitätstypen auf verwalteten Knoten, die mit Systems Manager verwaltet werden. Überprüfen Sie, ob Sie die Einrichtungsanforderungen für Ihre Instances der Amazon Elastic Compute Cloud (Amazon EC2) und Nicht-EC2-Maschinen in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) erfüllt haben. | [Einrichten der einheitlichen Systems-Manager-Konsole für eine Organisation](systems-manager-setting-up-organizations.md) |
| Aktualisieren Sie die AWS Identity and Access Management (IAM)-Rolle, die Ihre verwalteten Knoten verwenden, um die Compliance-Berechtigungen einzuschränken. | [Konfigurieren von Berechtigungen für die Compliance](compliance-permissions.md) |
| Wenn Sie die Patch-Compliance überwachen möchten, überprüfen Sie die Konfiguration des Patch Manager. Sie müssen Patch-Vorgänge mit dem Patch Manager durchführen, bevor die Patch-Compliance-Daten von Compliance angezeigt werden können. | [AWS Systems Manager Patch Manager](patch-manager.md) |
| Wenn Sie die Zuordnungs-Compliance überwachen möchten, überprüfen Sie, dass Sie State Manager-Zuordnungen erstellt haben. Sie müssen Zuordnungen erstellen, bevor die Daten zur Zuordnungs-Compliance von Compliance angezeigt werden können. | [AWS Systems Manager State Manager](systems-manager-state.md) |
| (Optional) Konfigurieren Sie das System, um den Compliance-Verlauf und die Änderungsnachverfolgung anzuzeigen. | [Anzeigen von Compliance-Konfigurationsverlauf und Änderungsnachverfolgung](compliance-about.md#compliance-history) |
| (Optional) Erstellen Sie benutzerdefinierte Compliance-Typen. | [Weisen Sie benutzerdefinierte Compliance-Metadaten zu mithilfe der AWS CLI](compliance-custom-metadata-cli.md) |
| (Optional) Erstellen Sie eine Resource Data Sync zur Aggregation aller Compliance-Daten in einem Amazon Simple Storage Service (Amazon S3)-Bucket. | [Erstellen einer Ressource Data Sync für Compliance](compliance-datasync-create.md) |
# Konfigurieren von Berechtigungen für die Compliance
Aus Sicherheitsgründen empfehlen wir, dass Sie die von Ihren verwalteten Knoten verwendete AWS Identity and Access Management (IAM-) Rolle mit den folgenden Berechtigungen aktualisieren, um die Fähigkeit des Knotens einzuschränken, die [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API-Aktion zu verwenden. Diese API-Aktion registriert einen Compliance-Typ und andere Compliance-Details auf einer bestimmten Ressource, z. B. einer EC2 Amazon-Instance oder einem verwalteten Knoten.
Wenn es sich bei Ihrem Knoten um eine EC2 Amazon-Instance handelt, müssen Sie das von der Instance verwendete IAM-Instance-Profil mit den folgenden Berechtigungen aktualisieren. Weitere Informationen zu Instanzprofilen für von Systems Manager verwaltete EC2 Instanzen finden Sie unter[Konfigurieren von erforderlichen Instance-Berechtigungen für Systems Manager](setup-instance-permissions.md). Für andere Typen von verwalteten Knoten sollten Sie die vom Knoten verwendete IAM-Rolle mit den folgenden Berechtigungen aktualisieren. Weitere Informationen finden Sie unter [Aktualisieren von Berechtigungen für eine Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) im *IAM-Benutzerhandbuch*.
------
#### [ 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}"
}
}
}
]
}
```
------
# Erstellen einer Ressource Data Sync für Compliance
Sie können die Funktion zur Synchronisierung von Ressourcendaten verwenden AWS Systems Manager , um Compliance-Daten von all Ihren verwalteten Knoten an einen Amazon Simple Storage Service (Amazon S3) -Ziel-Bucket zu senden. Wenn Sie die Synchronisierung erstellen, können Sie verwaltete Knoten aus mehreren AWS-Konten AWS-Regionen, und Ihrer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) angeben. Resource Data Sync aktualisiert die Daten dann automatisch, sobald neue Compliance-Daten erfasst werden. Da alle Compliance-Daten in einem Ziel-S3-Bucket gespeichert sind, können Sie Dienste wie Amazon Athena und Amazon Quick verwenden, um die aggregierten Daten abzufragen und zu analysieren. Resource Data Sync muss einmalig für Compliance konfiguriert werden.
Führen Sie die folgenden Schritte aus, um mit der AWS-Managementkonsole eine Ressource Data Sync für Compliance zu erstellen.
**So erstellen und konfigurieren Sie einen S3-Bucket für die Synchronisierung von Ressourcendaten (Konsole)**
1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Erstellen Sie ein Bucket zum Speichern der zusammengefassten Compliance-Daten. Weitere Informationen finden Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*. Notieren Sie sich den Namen des Buckets und den AWS-Region Ort, an dem Sie ihn erstellt haben.
1. Öffnen Sie den Bucket, wählen Sie die Registerkarte **Permissions (Berechtigungen)** und anschließend die Option **Bucket Policy (Bucket-Richtlinie)**.
1. Kopieren Sie die folgende Bucket-Richtlinie in den Richtlinien-Editor. Ersetzen Sie amzn-s3-demo-bucket und *Account-ID* durch den Namen des S3-Buckets, den Sie erstellt haben, und eine gültige ID. AWS-Konto Optional können Sie es *Bucket-Prefix* durch den Namen eines Amazon S3 S3-Präfix (Unterverzeichnis) ersetzen. Wenn Sie kein Präfix erstellt haben, entfernen Sie*Bucket-Prefix*/aus dem ARN in der Richtlinie.
------
#### [ 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"
}
}
}
]
}
```
------
**So erstellen Sie eine Ressourcendaten-Synchronisierung**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie **Account management (Kontoverwaltung)**, **Resource Data Syncs** und dann **Create resource data sync (Resource Data Sync erstellen)**
1. Geben Sie im Feld **Sync name** einen Namen für die Synchronisierungskonfiguration ein.
1. Geben Sie im Feld **Bucket name (Bucket-Name)** den Namen des zu Beginn dieses Vorgangs erstellten Amazon S3-Buckets an.
1. (Optional) Geben Sie im Feld **Bucket-Präfix** den Namen eines S3-Bucket-Präfixes (Unterverzeichnis) an.
1. Wählen Sie im Feld **Bucket-Region** die Option **Diese Region** aus, wenn sich der erstellte S3-Bucket in der aktuellen AWS-Region befindet. Wenn sich der Bucket in einer **anderen Region befindet AWS-Region, wählen Sie „Andere Region**“ und geben Sie den Namen der Region ein.
**Anmerkung**
Wenn sich die Synchronisierung und der Ziel-S3-Bucket in verschiedenen Regionen befinden, müssen Sie möglicherweise Gebühren für die Datenübertragung zahlen. Weitere Informationen finden Sie unter [Amazon S3 – Preise](https://aws.amazon.com/s3/pricing/).
1. Wählen Sie **Erstellen** aus.
# Erfahren Sie mehr über Compliance
Compliance, ein Tool in AWS Systems Manager, sammelt und meldet Daten über den Status von Patches in Patch Manager Patching und Assoziationen in. State Manager (Patch Managerund beide Tools State Manager sind auch dabei.) AWS Systems Manager Compliance berichtet auch zu benutzerdefinierten Compliance-Typen, die Sie für Ihre verwalteten Knoten angegeben haben. Dieser Abschnitt enthält Details über jeden dieser Compliance-Typen sowie Informationen zum Anzeigen von Systems Manager-Compliance-Daten. Dieser Abschnitt enthält auch Informationen zum Anzeigen des Compliance-Verlaufs und der Änderungsnachverfolgung.
**Anmerkung**
Systems Manager lässt sich in integrieren [https://www.chef.io/inspec/](https://www.chef.io/inspec/). InSpec ist ein Open-Source-Runtime-Framework, mit dem Sie menschenlesbare Profile auf GitHub Amazon Simple Storage Service (Amazon S3) erstellen können. Anschließend können Sie Systems Manager verwenden, um Compliance-Scans auszuführen und konforme und nicht konforme Instances anzuzeigen. Weitere Informationen finden Sie unter [Verwenden von Chef InSpec-Profilen mit Systems Manager Compliance](integration-chef-inspec.md).
## Info zu Patch Compliance
Nachdem Sie mit Patch Manager in Ihren Instances installiert haben, stehen Ihnen die Compliance-Statusinformationen sofort in der Konsole oder in der Antwort auf AWS Command Line Interface (AWS CLI)-Befehle oder entsprechenden Systems Manager-API-Vorgängen zur Verfügung.
Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).
## Informationen zu State Manager-Zuordnungs-Compliance
Nachdem Sie eine oder mehrere State Manager Zuordnungen erstellt haben, stehen Ihnen Informationen zum Compliance-Status sofort in der Konsole oder als Reaktion auf AWS CLI Befehle oder entsprechende Systems Manager Manager-API-Operationen zur Verfügung. Für Zuordnungen zeigt Compliance den Status `Compliant` oder `Non-compliant` und den der Zuordnung zugewiesenen Schweregrad an, z. B. `Critical` oder `Medium`.
Wenn State Manager eine Zuordnung auf einem verwalteten Knoten ausführt, wird eine Compliance-Aggregation ausgelöst, die den Compliance-Status für alle Zuordnungen auf diesem Knoten aktualisiert. Der `ExecutionTime`-Wert in Compliance-Berichten gibt an, wann der Compliance-Status von Systems Manager erfasst wurde, und nicht, wann die Zuordnung auf dem verwalteten Knoten ausgeführt wurde. Das bedeutet, dass mehrere Verknüpfungen möglicherweise identische `ExecutionTime`-Werte anzeigen, auch wenn sie zu unterschiedlichen Zeiten ausgeführt wurden. Die tatsächlichen Ausführungszeiten von Zuordnungen können Sie mithilfe des AWS CLI Befehls [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)oder anhand der Ausführungsdetails in der Konsole im Verlauf der Zuordnungsausführung ermitteln.
## Informationen zu benutzerdefinierter Compliance
Einem verwalteten Knoten können Compliance-Metadaten zugewiesen werden. Diese Metadaten können anschließend mit anderen Compliance-Daten für Compliance-Berichte zusammengefasst werden. Beispiel: Ihr Unternehmen führt die Versionen 2.0, 3.0 und 4.0 von Software X auf Ihren verwalteten Knoten aus. Das Unternehmen möchte Version 4.0 zum Standard machen. Das bedeutet, dass Instances mit Versionen 2.0 und 3.0 nicht konform sind. Mithilfe des [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API-Vorgangs können Sie explizit angeben, auf welchen verwalteten Knoten ältere Versionen von Software X ausgeführt werden. Sie können Konformitätsmetadaten nur mithilfe von AWS CLI AWS Tools for Windows PowerShell, oder zuweisen SDKs. Mit dem folgenden CLI-Beispielbefehl werden einer verwalteten Instance Compliance-Metadaten zugewiesen und der Compliance-Typ im benötigten Format angegeben `Custom:`. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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
```
------
**Anmerkung**
Der `ResourceType`-Parameter unterstützt nur `ManagedInstance`. Wenn Sie einem AWS IoT Greengrass -Core-Gerät benutzerdefinierte Compliance hinzufügen, müssen Sie einen `ResourceType` von `ManagedInstance` angeben.
Compliance-Manager können daraufhin Zusammenfassungen anzeigen oder Berichte über nicht konforme verwaltete Knoten erstellen. Sie können einem verwalteten Knoten maximal 10 verschiedene benutzerdefinierte Compliance-Typen zuweisen.
Ein Beispiel für die Erstellung eines benutzerdefinierten Compliance-Typs und zum Anzeigen von Compliance-Daten finden Sie unter [Weisen Sie benutzerdefinierte Compliance-Metadaten zu mithilfe der AWS CLI](compliance-custom-metadata-cli.md).
## Anzeigen aktueller Compliance-Daten
In diesem Abschnitt wird beschrieben, wie Sie Compliance-Daten in der Systems Manager-Konsole und mithilfe der AWS CLI anzeigen. Weitere Informationen zum Anzeigen des Patch- und Zuordnungs-Compliance-Verlaufs und der Änderungsnachverfolgung finden Sie unter [Anzeigen von Compliance-Konfigurationsverlauf und Änderungsnachverfolgung](#compliance-history).
**Topics**
+ [Anzeigen aktueller Compliance-Daten (Konsole)](#compliance-view-results-console)
+ [Anzeigen aktueller Compliance-Daten (AWS CLI)](#compliance-view-data-cli)
### Anzeigen aktueller Compliance-Daten (Konsole)
Verwenden Sie die folgenden Verfahren, um Compliance-Daten in der Systems Manager-Konsole anzuzeigen.
**So zeigen Sie aktuelle Compliance-Berichte in der Systems Manager-Konsole an**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im linken Navigationsbereich **Compliance**.
1. Wählen Sie im Abschnitt **Compliance dashboard filtering** (Compliance-Dashboard-Filtrierung) eine Option zum Filtern von Compliance-Daten aus. Der Abschnitt **Compliance resources summary** (Zusammenfassung der Compliance-Ressourcen) zeigt die Anzahl der Compliance-Daten basierend auf dem von Ihnen ausgewählten Filter an.
1. Um weitere detaillierte Informationen zu einer Ressource zu erhalten, scrollen Sie nach unten zum Bereich **Details overview for resources** (Detailübersicht für Ressourcen) und wählen Sie die ID eines verwalteten Knotens.
1. Wählen Sie auf der Detailseite **Instance ID** (Instance-ID) oder **Name** die Registerkarte **Configuration compliance** (Konfigurations-Compliance), um den detaillierten Bericht zur Konfigurations-Compliance anzuzeigen.
**Anmerkung**
Weitere Informationen zum Beheben von Compliance-Problemen finden Sie unter [Beheben von Compliance-Problemen mithilfe von EventBridge](compliance-fixing.md).
### Anzeigen aktueller Compliance-Daten (AWS CLI)
Mithilfe der folgenden AWS CLI Befehle können Sie Zusammenfassungen der Kompatibilitätsdaten für Patches, Verknüpfungen und benutzerdefinierte Kompatibilitätstypen im in der AWS CLI anzeigen.
[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)
Gibt eine Übersichtszahl der konformen und nicht konformen Zuordnungs-Statusarten entsprechend der angegebenen Filter zurück. (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)
Gibt eine Übersichtszahl auf Ressourcenebene zurück. Die Übersicht umfasst Informationen über konforme und nicht konforme Statusarten und die detaillierte Anzahl des Schweregrads von Compliance-Elementen entsprechend den festgelegten Filterkriterien. (API: [ListResourceComplianceSummaries](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ListResourceComplianceSummaries.html))
Sie können zusätzliche Compliance-Daten für das Einspielen von Patches mit den folgenden AWS CLI -Befehlen anzeigen.
[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)
Gibt allgemeine zusammengefasste Patch-Compliance-Statusarten für eine Patch-Gruppe zurück. (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)
Gibt den allgemeinen Patch-Status für die Instances in der angegebenen Patch-Gruppe zurück. (API: [DescribeInstancePatchStatesForPatchGroup](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatchStatesForPatchGroup.html))
**Anmerkung**
Eine Veranschaulichung der Konfiguration von Patches und der Anzeige von Informationen zur Patch-Konformität mithilfe von finden Sie unter[Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). AWS CLI
## Anzeigen von Compliance-Konfigurationsverlauf und Änderungsnachverfolgung
Standardmäßig werden von Systems-Manager-Compliance die *aktuellen* Patch-Vorgänge und Zuordnungs-Compliance-Daten für Ihre verwalteten Knoten angezeigt. Sie können den Verlauf der Einhaltung von Patches und Zuordnungen sowie die Änderungsnachverfolgung anzeigen, indem Sie [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/) AWS Config bietet einen detaillierten Überblick über die Konfiguration der AWS Ressourcen in Ihrem AWS-Konto. Dazu gehört auch, wie die Ressourcen jeweils zueinander in Beziehung stehen und wie sie in der Vergangenheit konfiguriert wurden, damit Sie sehen können, wie sich die Konfigurationen und Beziehungen im Laufe der Zeit verändern. Zum Anzeigen von Patch-Einspielungen, des Zuordnungs-Compliance-Verlaufs und der Änderungsnachverfolgung müssen Sie die folgenden Ressourcen in AWS Config aktivieren:
+ `SSM:PatchCompliance`
+ `SSM:AssociationCompliance`
Weitere Informationen dazu, wie Sie diese spezifischen Ressourcen in AWS Config auswählen und konfigurieren, finden Sie unter [Selecting Which Resources AWS Config Records](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html) im *AWS Config -Entwicklerleitfaden*.
**Anmerkung**
Informationen zur AWS Config Preisgestaltung finden Sie unter [Preise](https://aws.amazon.com/config/pricing/).
# Löschen einer Ressource Data Sync für Compliance
Wenn Sie Compliance nicht mehr zum Anzeigen von AWS Systems Manager Compliance-Daten verwenden möchten, empfehlen wir außerdem, die für die Erfassung von Compliance-Daten verwendeten Ressourcendatensynchronisationen zu löschen.
**Löschen eines Compliance Resource Data Sync**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Klicken Sie auf **Account management (Kontenverwaltung)**, **Resource data syncs**.
1. Wählen Sie eine Synchronisierung aus der Liste aus.
**Wichtig**
Stellen Sie sicher, dass Sie die für Compliance verwendete Synchronisierung auswählen. Systems Manager unterstützt die Ressourcendaten-Synchronisierung für mehrere Tools. Wenn Sie die falsche Synchronisierung wählen, können Sie die Datenaggregation für Systems Manager Explorer oder Systems Manager Inventory unterbrechen.
1. Wählen Sie **Löschen** aus.
1. Löschen Sie den Amazon Simple Storage Service (Amazon S3)-Bucket, in dem die Daten gespeichert wurden. Weitere Informationen zum Löschen eines S3-Buckets finden Sie unter [Löschen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html).
# Beheben von Compliance-Problemen mithilfe von EventBridge
Mit Run Command, einem Tool in AWS Systems Manager, lassen sich Probleme bei der Patch- und Zuordnungs-Compliance schnell beheben. Sie können Instance- oder AWS IoT Greengrass-Core-Geräte-IDs oder Tags anvisieren und das `AWS-RunPatchBaseline`-Dokument oder das `AWS-RefreshAssociation`-Dokument ausführen. Wenn das Compliance-Problem nicht durch die Aktualisierung der Zuordnung oder eine erneute Ausführung der Patch-Baseline behoben wird, müssen Sie Ihre Zuordnungen, Patch-Baselines oder Instance-Konfigurationen untersuchen, um herauszufinden, warum die Run Command-Operationen das Problem nicht behoben haben.
Weitere Informationen zu Patch-Vorgängen finden Sie unter [AWS Systems Manager Patch Manager](patch-manager.md) und [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
Weitere Informationen zu Zuordnungen finden Sie unter [Arbeiten mit Zuordnungen in Systems Manager](state-manager-associations.md).
Weitere Informationen zum Ausführen eines Befehls finden Sie unter [AWS Systems Manager Run Command](run-command.md).
**Compliance als Ziel eines EventBridge-Ereignisses angeben**
Sie können Amazon EventBridge auch so konfigurieren, dass als Reaktion auf Systems Manager Compliance-Ereignisse eine Aktion ausgeführt wird. Zum Beispiel, wenn kritische Patch-Updates auf mindestens einem verwalteten Knoten nicht installiert werden oder eine Zuordnung zur Installation einer Antiviren-Software nicht ausgeführt wird, können Sie EventBridge so konfigurieren, dass das `AWS-RunPatchBaseline`-Dokument oder das `AWS-RefreshAssocation`-Dokument ausgeführt wird, wenn das Compliance-Ereignis eintritt.
Führen Sie die folgenden Schritte aus, um Compliance als Ziel eines EventBridge-Ereignisses festzulegen.
**Konfigurieren von Compliance als Ziel eines EventBridge-Ereignisses (Konsole)**
1. Öffnen Sie die Amazon EventBridge-Konsole unter [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Wählen Sie im Navigationsbereich **Regeln** aus.
1. Wählen Sie **Regel erstellen** aus.
1. Geben Sie einen Namen und eine Beschreibung für die Regel ein.
Eine Regel darf nicht denselben Namen wie eine andere Regel in derselben AWS-Region und auf demselben Event Bus haben.
1. Wählen Sie für **Event Bus** den Event Bus aus, den Sie dieser Regel zuordnen möchten. Wenn Sie möchten, dass diese Regel auf übereinstimmende Ereignisse reagiert, die von Ihrem eigenen AWS-Konto stammen, wählen Sie **Standard** aus. Wenn ein AWS-Service in Ihrem Konto ein Ereignis ausgibt, wird es stets an den Standard-Event-Bus Ihres Kontos weitergeleitet.
1. Bei **Regeltyp** wählen Sie **Regel mit einem Ereignismuster** aus.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie für **Ereignisquelle** **AWS-Ereignisse oder EventBridge-Partnerereignisse**.
1. Wählen Sie im Abschnitt **Ereignismuster** die Option **Ereignismusterformular** aus.
1. Als **Event source** (Ereignisquelle) wählen Sie **AWS-Services** aus.
1. Wählen Sie für **AWS-Service**, die Option **Systems Manager** aus.
1. Wählen Sie für **Event Type** (Ereignistyp) **Configuration Compliance**.
1. Für **Specific detail type(s)** (Spezifische(r) Detail-Typ(en)), wählen Sie **Configuration Compliance State Change** (Konfiguration-Compliance-Statusänderung).
1. Wählen Sie **Weiter** aus.
1. Bei **Zieltypen** wählen Sie **AWS-Service** aus.
1. Für **Select a target** (Ziel auswählen), wählen Sie **Systems Manager Run Command**.
1. Wählen Sie in der Liste **Document** (Dokument) ein Systems Manager-Dokument (SSM-Dokument) aus, das Sie ausführen möchten, wenn das Ziel aufgerufen wird. Wählen Sie beispielsweise `AWS-RunPatchBaseline` als ein nicht konformes Patch-Ereignis oder `AWS-RefreshAssociation` als ein nicht konformes Zuweisungsereignis aus.
1. Geben Sie Informationen für die verbleibenden Felder und Parameter an.
**Anmerkung**
Erforderliche Felder und Parameter sind mit einem Sternchen (\$1) neben den Namen gekennzeichnet. Um ein Ziel zu erstellen, müssen Sie bei jedem erforderlichen Parameter oder Feld einen Wert angeben. Andernfalls erstellt das System die Regel, führt diese aber nicht aus.
1. Wählen Sie **Weiter** aus.
1. (Optional) Geben Sie ein oder mehrere Tags für die Regel ein. Weitere Informationen finden Sie unter [Tagging Your Amazon EventBridge Resources (Taggen Ihrer Amazon EventBridge Resources)](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html) im *Amazon EventBridge-Benutzerhandbuch*.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Details der Regel und wählen Sie dann **Regel erstellen** aus.
# Weisen Sie benutzerdefinierte Compliance-Metadaten zu mithilfe der AWS CLI
Das folgende Verfahren führt Sie durch den Prozess, bei dem Sie mithilfe von AWS Command Line Interface (AWS CLI) den AWS Systems Manager [PutComplianceItems](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API-Vorgang aufrufen, um einer Ressource benutzerdefinierte Compliance-Metadaten zuzuweisen. Sie können mit dieser API-Operation zudem einem verwalteten Knoten manuell Patch- oder Zuordnungs-Compliance-Metadaten zuweisen, wie im folgenden Walkthrough dargestellt. Weitere Informationen zur Verwendung benutzerdefinierter Compliance finden Sie unter [Informationen zu benutzerdefinierter Compliance](compliance-about.md#compliance-custom).
**So weisen Sie einer verwalteten Instance benutzerdefinierte Compliance-Metadaten zu (AWS CLI)**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie den folgenden Befehl aus, um einem verwalteten Knoten benutzerdefinierte Compliance-Metadaten zuweisen. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen. Der `ResourceType`-Parameter unterstützt nur einen Wert von `ManagedInstance`. Geben Sie diesen Wert auch dann an, wenn Sie einem verwalteten AWS IoT Greengrass Kerngerät benutzerdefinierte Compliance-Metadaten zuweisen.
------
#### [ 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. Wiederholen Sie den vorherigen Schritt, um einem oder mehreren Knoten weitere benutzerdefinierte Compliance-Metadaten zuzuweisen. Mit folgenden Befehlen können Sie verwalteten Knoten die Patch- oder Zuordnungs-Compliance-Metadaten auch manuell zuweisen:
Zuordnungs-Compliance-Metadaten
------
#### [ 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
```
------
Patch Compliance-Metadaten
------
#### [ 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. Führen Sie den folgenden Befehl aus, um eine Liste der Compliance-Elemente für einen bestimmten verwalteten Knoten anzuzeigen. Mithilfe von Filtern können Sie Details zu bestimmten Compliance-Daten anzeigen.
------
#### [ 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
```
------
Die folgenden Beispiele zeigen, wie Sie diesen Befehl mit Filtern verwenden.
------
#### [ 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. Führen Sie den folgenden Befehl aus, um eine Übersicht der Compliance-Statusarten anzuzeigen. Mithilfe von Filtern können Sie Details zu bestimmten Compliance-Daten anzeigen.
```
aws ssm list-resource-compliance-summaries --filters One or more filters.
```
Die folgenden Beispiele zeigen, wie Sie diesen Befehl mit Filtern verwenden.
------
#### [ 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. Mit dem folgenden Befehl zeigen Sie eine Übersichtszahl der konformen und nicht konformen Ressourcen für einen Compliance-Typ an. Mithilfe von Filtern können Sie Details zu bestimmten Compliance-Daten anzeigen.
```
aws ssm list-compliance-summaries --filters One or more filters.
```
Die folgenden Beispiele zeigen, wie Sie diesen Befehl mit Filtern verwenden.
------
#### [ 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, ein Tool in AWS Systems Manager, hilft Ihnen dabei, Software zu verpacken und auf AWS Systems Manager verwalteten Knoten zu veröffentlichen. Sie können Ihre eigene Software verpacken und veröffentlichen oder Distributor zum Suchen und Veröffentlichen AWS bereitgestellter Agentensoftwarepakete (z. **AmazonCloudWatchAgent**B.) oder Pakete von Drittanbietern wie **Trend Micro** verwenden.Durch die Veröffentlichung eines Pakets werden bestimmte Versionen des Paketdokuments auf verwalteten Knoten angekündigt, die Sie anhand von Knoten IDs AWS-Konto IDs, Tags oder einem identifizieren. AWS-Region Um mit Distributor zu beginnen, öffnen Sie die [Systems-Manager-Konsole](https://console.aws.amazon.com//systems-manager/distributor). Wählen Sie im Navigationsbereich **Distributor** aus.
Nachdem Sie in Distributor ein Paket erstellt haben, können Sie das Paket auf eine der folgenden Weisen installieren:
+ Einmalig mithilfe von [AWS Systems Manager Run Command](run-command.md)
+ Anhand eines Zeitplans mithilfe von [AWS Systems Manager State Manager](systems-manager-state.md)
**Wichtig**
Pakete, die von Drittanbietern vertrieben werden, werden nicht vom Anbieter des Pakets verwaltet AWS und von diesem veröffentlicht. Wir empfehlen Ihnen, zusätzliche Sorgfaltsprüfungen durchzuführen, um die Einhaltung Ihrer internen Sicherheitskontrollen sicherzustellen. Sicherheit ist eine gemeinsame Verantwortung von Ihnen AWS und Ihnen. Dies wird als Modell der geteilten Verantwortung beschrieben. Weitere Informationen hierzu finden Sie in [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/).
## Welche Vorteile bietet Distributor meiner Organisation?
Distributor bietet die folgenden Vorteile:
+ **Ein Paket, viele Plattformen**
Wenn Sie ein Paket in Distributor erstellen, erstellt das System ein AWS Systems Manager -Dokument (SSM-Dokument). Sie können ZIP-Dateien an dieses Dokument anfügen. Wenn Sie Distributor ausführen, verarbeitet das System die Anweisungen im SSM-Dokument und installiert das Softwarepaket in der ZIP-Datei auf den angegebenen Zielen. Distributor unterstützt mehrere Betriebssysteme, darunter Windows, Ubuntu Server, Debian Server und Red Hat Enterprise Linux. Weitere Informationen zu unterstützten Plattformen finden Sie unter [Unterstützte Paketplattformen und -architekturen](#what-is-a-package-platforms).
+ **Kontrolle über den Paketzugriff über mehrere Gruppen verwalteter Instances hinweg**
Sie können Run Command oder State Manager verwenden, um zu steuern, welche Ihrer verwalteten Knoten ein Paket erhalten und welche Version dieses Paket haben soll. Run Command und State Manager sind Tools in AWS Systems Manager. Verwaltete Knoten können nach Instanz oder Gerät IDs, AWS-Konto Nummern, Tags oder gruppiert AWS-Regionen werden. Mithilfe von State Manager-Zuordnungen können Sie verschiedene Versionen eines Pakets für verschiedene Gruppen von Instances bereitstellen.
+ **Viele AWS Agentenpakete sind im Lieferumfang enthalten und sofort einsatzbereit**
Distributorenthält viele AWS Agentenpakete, die Sie sofort auf verwalteten Knoten bereitstellen können. Suchen Sie auf der Distributor `Packages`-Listenseite nach Paketen, die von `Amazon` veröffentlicht werden. Beispiele hierfür sind `AmazonCloudWatchAgent` und `AWSPVDriver`.
+ **Automatische Bereitstellung **
Um Ihre Umgebung auf dem aktuellen Stand zu halten, verwenden Sie State Manager, um Pakete für die automatische Bereitstellung auf ausgesuchten verwalteten Knoten zu planen, wenn diese Maschinen zum ersten Mal gestartet werden.
## An wen richtet sich Distributor?
+ Jeder AWS Kunde, der neue Softwarepakete erstellen oder bestehende Softwarepakete, einschließlich AWS veröffentlichter Pakete, auf mehreren von Systems Manager verwalteten Knoten gleichzeitig bereitstellen möchte.
+ Softwareentwickler, die Softwarepakete erstellen.
+ Administratoren, die dafür verantwortlich sind, die von Systems Manager verwalteten Knoten mit den meisten up-to-date Softwarepaketen auf dem neuesten Stand zu halten.
## Über welche Features verfügt Distributor?
+ **Bereitstellung von Paketen auf Windows- ebenso wie auf Linux-Instances**
Mit Distributor können Sie Softwarepakete auf Amazon Elastic Compute Cloud (Amazon EC2) -Instances und AWS IoT Greengrass Kerngeräten für Linux und Windows Server bereitstellen. Eine Liste der unter den jeweiligen Betriebssystemen unterstützten Instance-Typen finden Sie unter [Unterstützte Paketplattformen und -architekturen](#what-is-a-package-platforms).
**Anmerkung**
Distributor wird auf dem macOS-Betriebssystem unterstützt.
+ **Einmalige Bereitstellung von Paketen oder nach automatisiertem Zeitplan**
Sie können wählen, ob die Pakete einmalig, nach einem regelmäßigen Zeitplan oder immer dann, wenn die Standardpaketversion auf eine andere umgestellt wird, aktualisiert werden sollen.
+ **Vollständige Neuinstallation von Paketen oder Durchführen von direkten Aktualisierungen**
Um eine neue Paketversion zu installieren, können Sie die aktuelle Version vollständig deinstallieren und stattdessen eine neue Version installieren oder die aktuelle Version nur entsprechend einem von Ihnen bereitgestellten *Aktualisierungsskript* mit neuen und aktualisierten Komponenten aktualisieren. Ihre Paketanwendung ist während einer Neuinstallation nicht verfügbar, kann aber während einer direkten Aktualisierung weiterhin verfügbar bleiben. Direkte Aktualisierungen sind besonders nützlich für Anwendungen zur Sicherheitsüberwachung oder andere Szenarien, in denen Sie Anwendungsausfälle vermeiden müssen.
+ **Konsolen- PowerShell, CLI- und SDK-Zugriff auf Distributor Funktionen**
Sie können mit Distributor der Systems Manager Manager-Konsole AWS Command Line Interface (AWS CLI) oder dem AWS SDK Ihrer Wahl arbeiten. AWS -Tools für PowerShell
+ **IAM-Zugriffskontrolle**
Mithilfe von AWS Identity and Access Management (IAM-) Richtlinien können Sie steuern, welche Mitglieder Ihrer Organisation Pakete oder Paketversionen erstellen, aktualisieren, bereitstellen oder löschen können. Beispiel: Sie möchten einem Administrator Berechtigungen zum Bereitstellen von Paketen gewähren, nicht jedoch zum Ändern von Paketen oder zum Erstellen neuer Paketversionen.
+ **Support für Protokollierungs- und Prüfungsfunktionen**
AWS-Konto Durch die Integration mit anderen AWS-Services können Sie Distributor Benutzeraktionen in Ihrem System prüfen und protokollieren. Weitere Informationen finden Sie unter [Prüfen und Protokollieren von Distributor-Aktivitäten](distributor-logging-auditing.md).
## Was ist ein Paket in Distributor?
Ein *Paket* ist eine Sammlung installierbarer Software oder Komponenten. Beispiele hierfür sind:
+ Eine ZIP-Datei mit Software pro Ziel-Betriebssystemplattform. Jede ZIP-Datei muss Folgendes enthalten:
+ Ein **install** und ein **uninstall** Skript. Windows Serverbasierte verwaltete Knoten benötigen PowerShell Skripten (Skripten mit dem Namen `install.ps1` und`uninstall.ps1`). Linux-basierte verwaltete Knoten benötigen Shell-Skripten (Skripten mit dem Namen `install.sh` und`uninstall.sh`). AWS Systems Manager SSM Agentliest die Anweisungen in den **uninstall** UND-Skripten **install** und führt sie aus.
+ Eine ausführbare Datei. Diese muss SSM Agent finden, um das Paket auf den anvisierten verwalteten Knoten installieren zu können.
+ Eine Manifestdatei im JSON-Format, die den Paketinhalt beschreibt. Das Manifest ist nicht in der ZIP-Datei enthalten, aber im selben Amazon Simple Storage Service (Amazon S3)-Bucket gespeichert wie die ZIP-Dateien, aus denen das Paket besteht. Das Manifest identifiziert die Paketversion und ordnet die ZIP-Dateien im Paket den Attributen des anvisierten verwalteten Knotens zu (z. B. die Version oder Architektur des Betriebssystems). Informationen zum Erstellen des Manifests finden Sie unter [Schritt 2: Erstellen des JSON-Paketmanifests](distributor-working-with-packages-create.md#packages-manifest).
Wenn Sie **Einfache** Paketerstellung in der Distributor-Konsole wählen, generiert Distributor die Installations- und Deinstallationsskripts, sowie die Datei-Hashes und das Manifest des JSON-Pakets, basierend auf dem Dateinamen der ausführbaren Software sowie den Zielplattformen und -Architekturen.
### Unterstützte Paketplattformen und -architekturen
Sie können Distributor verwenden, um Pakete auf den folgenden Plattformen verwalteter Knoten von Systems Manager zu veröffentlichen. Ein Versionswert muss genau mit der Version des Betriebssystems-Amazon Machine Image (AMI) übereinstimmen. Weitere Informationen zum Ermitteln dieser Version finden Sie in Schritt 4 unter [Schritt 2: Erstellen des JSON-Paketmanifests](distributor-working-with-packages-create.md#packages-manifest).
**Anmerkung**
Systems Manager unterstützt nicht alle der folgenden Betriebssysteme für AWS IoT Greengrass Kerngeräte. Weitere Informationen finden Sie im *AWS IoT Greengrass Version 2 Entwicklerhandbuch* unter [Einrichten von AWS IoT Greengrass Kerngeräten](https://docs.aws.amazon.com/greengrass/v2/developerguide/setting-up.html).
| Plattform | Codewert in der Manifestdatei | Unterstützte Architekturen |
| --- | --- | --- |
| AlmaLinux | almalinux | x86\$164 ARM64 |
| Amazon Linux 2 und Amazon Linux 2023 | `amazon` | x86\$164 oder x86 ARM64(Amazon Linux 2- und AL2023 A1-Instance-Typen) |
| Debian Server | `debian` | x86\$164 oder 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 und neuer, A1-Instance-Typen) |
| Rocky Linux | rocky | x86\$164 ARM64 |
| SUSE Linux Enterprise Server (SLES) | `suse` | x86\$164 |
| Ubuntu Server | `ubuntu` | x86\$164 oder x86 ARM64 (Ubuntu Server 16 und neuer, A1-Instance-Typen) |
| Windows Server | `windows` | x86\$164 |
**Topics**
+ [Welche Vorteile bietet Distributor meiner Organisation?](#distributor-benefits)
+ [An wen richtet sich Distributor?](#distributor-who)
+ [Über welche Features verfügt Distributor?](#distributor-features)
+ [Was ist ein Paket in Distributor?](#what-is-a-package)
+ [Einrichten von Distributor](distributor-getting-started.md)
+ [Mit Distributor-Paketen arbeiten](distributor-working-with.md)
+ [Prüfen und Protokollieren von Distributor-Aktivitäten](distributor-logging-auditing.md)
+ [Problembehebung AWS Systems ManagerDistributor](distributor-troubleshooting.md)
# Einrichten von Distributor
Bevor Sie ein Tool zum Erstellen AWS Systems Manager, Verwalten und Bereitstellen von Softwarepaketen verwendenDistributor, gehen Sie wie folgt vor.
## Erfüllen von Distributor-Voraussetzungen
Stellen Sie vor der Verwendung Distributor eines Tools sicher AWS Systems Manager, dass Ihre Umgebung die folgenden Anforderungen erfüllt.
**Distributor-Voraussetzungen**
| Anforderung | Description |
| --- | --- |
| SSM Agent | AWS Systems Manager SSM AgentVersion 2.3.274.0 oder höher muss auf den verwalteten Knoten installiert sein, auf denen Sie Pakete bereitstellen oder von denen Sie Pakete entfernen möchten. Informationen zum Installieren oder Aktualisieren von SSM Agent finden Sie unter [Arbeiten mit SSM Agent](ssm-agent.md). |
| AWS CLI | (Optional) Um die AWS Command Line Interface (AWS CLI) anstelle der Systems Manager Manager-Konsole zum Erstellen und Verwalten von Paketen zu verwenden, installieren Sie die neueste Version von AWS CLI auf Ihrem lokalen Computer. Weitere Informationen zum Installieren oder Upgraden der CLI finden Sie unter [Installieren der AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) um *AWS Command Line Interface -Benutzerhandbuch*. |
| AWS -Tools für PowerShell | (Optional) Um die Tools für PowerShell anstelle der Systems Manager Manager-Konsole zum Erstellen und Verwalten von Paketen zu verwenden, installieren Sie die neueste Version von Tools für PowerShell auf Ihrem lokalen Computer. Weitere Informationen zur Installation oder zum Upgrade der Tools für PowerShell finden Sie AWS Tools for PowerShell Core im *AWS -Tools für PowerShell Benutzerhandbuch* unter [Einrichten von AWS Tools for Windows PowerShell oder](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html). |
**Anmerkung**
Systems Manager unterstützt nicht die Verteilung von Paketen an von Oracle Linux verwaltete Knoten mit Distributor.
## Überprüfen oder Erstellen eines IAM-Instance-Profils mit Distributor-Berechtigungen
Hat standardmäßig AWS Systems Manager keine Berechtigung, Aktionen auf Ihren Instances durchzuführen. Sie müssen den Zugriff mithilfe eines AWS Identity and Access Management (IAM-) Instanzprofils gewähren. Ein Instance-Profil ist ein Container, der Informationen zur IAM-Rolle beim Start an eine Amazon Elastic Compute Cloud (Amazon EC2)-Instance übergibt. Diese Anforderung gilt für Berechtigungen für alle Systems-Manager-Tools, nicht nur Distributor.
**Anmerkung**
Wenn Sie Ihre Edge-Geräte für die Ausführung der AWS IoT Greengrass Core-Software und konfigurierenSSM Agent, geben Sie eine IAM-Servicerolle an, die es Systems Manager ermöglicht, Aktionen darauf auszuführen. Sie müssen keine verwalteten Edge-Geräte mit einem Instance-Profil konfigurieren.
Wenn Sie bereits andere Systems-Manager-Tools verwenden, z. B. Run Command und State Manager, ist ein Instance-Profil mit den erforderlichen Berechtigungen für Distributor bereits Ihren Instances zugeordnet. Die einfachste Methode, um sicherzustellen, dass Sie über Berechtigungen zur Ausführung von Distributor Aufgaben verfügen, besteht darin, die **SSMManagedInstanceCoreAmazon-Richtlinie** an Ihr Instance-Profil anzuhängen. Weitere Informationen finden Sie unter [Erforderliche Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md).
## Kontrolle des Benutzerzugriffs auf Pakete
Mithilfe von AWS Identity and Access Management (IAM-) Richtlinien können Sie steuern, wer Pakete erstellen, bereitstellen und verwalten darf. Sie können auch steuern, welche Run Command- und State Manager-API-Operationen auf verwalteten Knoten ausgeführt werden können. Zum Distributor Beispiel sind Run Command sowohl State Manager als auch Tools in AWS Systems Manager.
**ARN-Format**
Benutzerdefinierte Pakete sind dem Dokument Amazon Resource Names (ARNs) zugeordnet und haben das folgende Format.
```
arn:aws:ssm:region:account-id:document/document-name
```
Im Folgenden wird ein -Beispiel gezeigt.
```
arn:aws:ssm:us-west-1:123456789012:document/ExampleDocumentName
```
Sie können zwei AWS mitgelieferte Standard-IAM-Richtlinien verwenden, eine für Endbenutzer und eine für Administratoren, um Berechtigungen für Distributor Aktivitäten zu erteilen. Sie können auch benutzerdefinierte IAM-Richtlinien erstellen, die an Ihre Berechtigungsanforderungen angepasst sind.
Weitere Informationen zur Verwendung von Variablen in IAM-Richtlinien finden Sie unter [IAM-Richtlinienelemente: Variablen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html).
Informationen zum Erstellen von Richtlinien und zum Anfügen an Benutzer oder Gruppen finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) und [Hinzufügen und Entfernen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.
## Erstellen oder Auswählen eines Amazon-S3-Buckets Distributor
Wenn Sie ein Paket erstellen, indem Sie die in der AWS Systems Manager -Konsole den Workflow **Einfach** auswählen, wählen Sie einen vorhandenen Amazon Simple Storage Service (Amazon S3)-Bucket aus, an den Distributor Ihre Software hochlädt. Distributor ist ein Tool in AWS Systems Manager Wenn Sie den Workflow **Advanced (Erweitert)** auswählen, müssen Sie Ihre Software oder Komponenten als ZIP-Dateien in einen Amazon-S3-Bucket hochladen, bevor Sie beginnen. Unabhängig davon, ob Sie ein Paket mit dem Workflow **Simple (Einfach)** oder **Advanced (Erweitert)** in der Konsole erstellen, oder aber ob Sie die API verwenden, Sie benötigen einen Amazon-S3-Bucket, bevor Sie mit der Erstellung Ihres Paket beginnen. Bei der Paketerstellung kopiert Distributor Ihre installierbare Software und die Komponenten aus diesem Bucket in einen internen Systems Manager-Speicher. Da die Komponenten in einen internen Speicher kopiert werden, können Sie Ihren Amazon-S3-Bucket löschen oder wiederverwenden, wenn die Paketerstellung abgeschlossen ist.
Weitere Informationen zur Erstellung eines Buckets finden Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) im *Amazon Simple Storage Service Getting Started Guide*. Weitere Informationen zum Ausführen eines AWS CLI Befehls zum Erstellen eines Buckets finden Sie [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html)in der *AWS CLI Befehlsreferenz.*
# Mit Distributor-Paketen arbeiten
Sie können die AWS Systems Manager-Konsole, die AWS-Befehlszeilen-Tools (AWS CLI und AWS -Tools für PowerShell) und die AWS-SDKs zum Hinzufügen, Verwalten oder Bereitstellen von Paketen in Distributor verwenden. Distributor ist ein Tool in AWS Systems Manager. Vor dem Hinzufügen eines Pakets zu Distributor:
+ Erstellen und zippen Sie die zu installierbaren Komponenten.
+ (Optional) Erstellen Sie eine JSON-Manifestdatei für das Paket. Dies ist nicht erforderlich, um den Prozess der **einfachen** Paketerstellung in der Distributor-Konsole zu nutzen. Bei der einfachen Paketerstellung wird die JSON-Manifestdatei automatisch generiert.
Sie können zum Erstellen der Manifestdatei die AWS Systems Manager-Konsole oder einen Text- oder JSON-Editor verwenden.
+ Halten Sie einen Amazon Simple Storage Service (Amazon S3)-Bucket bereit, um Ihre installierbaren Komponenten oder Software zu speichern. Wenn Sie die den **Advanced (Erweitert)**-Workflow zur Paketerstellung verwenden, laden Sie Ihre Komponenten an den Amazon-S3-Bucket herunter, bevor Sie beginnen.
**Anmerkung**
Sie können diesen Bucket nach Abschluss der Erstellung Ihres Pakets löschen oder anderweitig verwenden, weil Distributor im Rahmen des Paketerstellungsprozesses die Paketinhalte in einen internen Systems Manager-Bucket verschiebt.
Von AWS veröffentlichte Pakete sind bereits verpackt und können sofort bereitgestellt werden. Informationen zum Bereitstellen eines von AWS veröffentlichten Pakets an verwalteten Knoten finden Sie unter [Installieren oder Aktualisieren von Distributor-Paketen](distributor-working-with-packages-deploy.md).
Sie können Distributor-Pakete zwischen AWS-Konten tauschen. Wenn Sie ein Paket verwenden, das von einem anderen Konto in AWS CLI-Befehlen geteilt wird, verwenden Sie das Paket Amazon Resource Name (ARN) anstelle des Paketnamens.
**Topics**
+ [Pakete anzeigen in Distributor](distributor-view-packages.md)
+ [Erstellen eines Pakets in Distributor](distributor-working-with-packages-create.md)
+ [Bearbeiten von Distributor-Paketberechtigungen in der Konsole](distributor-working-with-packages-ep.md)
+ [Bearbeiten von Distributor-Paket-Tags in der Konsole](distributor-working-with-packages-tags.md)
+ [Hinzufügen einer Version zu einem Distributor-Paket](distributor-working-with-packages-version.md)
+ [Installieren oder Aktualisieren von Distributor-Paketen](distributor-working-with-packages-deploy.md)
+ [Deinstallieren eines Distributor-Pakets](distributor-working-with-packages-uninstall.md)
+ [Löschen eines Distributor-Pakets](distributor-working-with-packages-dpkg.md)
# Pakete anzeigen in Distributor
Um Pakete anzuzeigen, die zur Installation verfügbar sind, können Sie die AWS Systems Manager Konsole oder Ihr bevorzugtes AWS Befehlszeilentool verwenden. Distributorist ein Tool in AWS Systems Manager. Um darauf zuzugreifenDistributor, öffnen Sie die AWS Systems Manager Konsole und wählen Sie **Distributor**im linken Navigationsbereich. Sie werden alle Pakete sehen, die Ihnen zur Verfügung stehen.
Im folgenden Abschnitt wird beschrieben, wie Sie Ihre Distributor-Pakete mithilfe Ihrer bevorzugten Befehlszeilen-Tools anzeigen.
## Anzeigen des Pakets per Befehlszeile
Dieser Abschnitt enthält Informationen dazu, wie Sie Ihr bevorzugtes Befehlszeilen-Tool verwenden können, um Distributor-Pakete mit den bereitgestellten Befehlen anzuzeigen.
------
#### [ Linux & macOS ]
**Um Pakete mit dem unter AWS CLI Linux anzuzeigen**
+ Führen Sie den folgenden Befehl aus, um alle Pakete anzuzeigen, mit der Ausnahme freigegebener Pakete.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package
```
+ Führen Sie den folgenden Befehl aus, um alle Pakete anzuzeigen, die Amazon gehören.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ Führen Sie den folgenden Befehl aus, um alle Pakete anzuzeigen, die Drittanbietern gehören.
```
aws ssm list-documents \
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ Windows ]
**Um Pakete mit dem AWS CLI unter Windows anzuzeigen**
+ Führen Sie den folgenden Befehl aus, um alle Pakete anzuzeigen, mit der Ausnahme freigegebener Pakete.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package
```
+ Führen Sie den folgenden Befehl aus, um alle Pakete anzuzeigen, die Amazon gehören.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=Amazon
```
+ Führen Sie den folgenden Befehl aus, um alle Pakete anzuzeigen, die Drittanbietern gehören.
```
aws ssm list-documents ^
--filters Key=DocumentType,Values=Package Key=Owner,Values=ThirdParty
```
------
#### [ PowerShell ]
**Um Pakete mit den Tools für anzuzeigen PowerShell**
+ Führen Sie den folgenden Befehl aus, um alle Pakete anzuzeigen, mit der Ausnahme freigegebener Pakete.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "DocumentType"
$filter.Values = "Package"
Get-SSMDocumentList `
-Filters @($filter)
```
+ Führen Sie den folgenden Befehl aus, um alle Pakete anzuzeigen, die Amazon gehören.
```
$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)
```
+ Führen Sie den folgenden Befehl aus, um alle Pakete anzuzeigen, die Drittanbietern gehören.
```
$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)
```
------
# Erstellen eines Pakets in Distributor
Um ein Paket zu erstellen, bereiten Sie Ihre installierbare Software oder Komponenten vor, immer eine Datei pro Betriebssystem-Plattform. Zur Erstellung eines Pakets ist mindestens eine Datei erforderlich.
Manchmal verwenden unterschiedliche Plattformen dieselbe Datei. Alle Ihrem Paket hinzugefügten Dateien müssen jedoch im Abschnitt `Files` des Manifests aufgelistet sein. Wenn Sie ein Paket in der Konsole über den einfachen Workflow erstellen, wird das Manifest automatisch generiert. Die maximale Anzahl von Dateien, die Sie einem einzelnen Dokument anfügen können, beträgt 20. Die maximale Größe der einzelnen Dateien beträgt 1 GB. Weitere Informationen zu unterstützten Plattformen finden Sie unter [Unterstützte Paketplattformen und -architekturen](distributor.md#what-is-a-package-platforms).
Wenn Sie ein neues Paket erstellen, erstellt das System ein neues [SSM-Dokument](documents.md). Mit diesem Dokument können Sie das Paket an verwaltete Knoten bereitstellen.
Nur zu Demonstrationszwecken steht Ihnen ein Beispielpaket, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), zum Herunterladen von unserer Website zur Verfügung. Das Beispielpaket enthält ein vollständiges JSON-Manifest und drei .zip-Dateien mit Installationsprogrammen für Version 7.0.0. PowerShell Die Installations- und Deinstallationsskripts enthalten keine gültigen Befehle. Wenn Sie ein Paket im Workflow **Advanced (Erweitert)** erstellen, müssen Sie alle installierbaren Softwaredateien und Skripts in einer ZIP-Datei komprimieren, beim Workflow **Simple (Einfach)** ist es jedoch nicht notwendig, installierbare Komponenten zu zippen.
**Topics**
+ [Erstellen Sie ein Paket mithilfe des einfachen Workflows](#distributor-working-with-packages-create-simple)
+ [Erstellen Sie ein Paket mithilfe des erweiterten Workflows](#distributor-working-with-packages-create-adv)
## Erstellen Sie ein Paket mithilfe des einfachen Workflows
In diesem Abschnitt wird beschrieben, wie Sie ein Paket in Distributor erstellen, wenn Sie das Paket über den **Einfach**-Workflow in der Distributor-Konsole erstellen. Distributor ist ein Tool in AWS Systems Manager. Um ein Paket zu erstellen, bereiten Sie Ihre zu installierenden Komponenten vor, eine Datei pro Betriebssystemplattform. Zur Erstellung eines Pakets ist mindestens eine Datei erforderlich. Bei der **einfachen** Paketerstellung werden die Installations- und Deinstallationsskripts generiert, sowie die Datei-Hashes und eine Manifest-Datei im JSON-Format. Der **Simple (Einfach)**-Workflow übernimmt das Hochladen und Komprimieren Ihrer installierbaren Dateien sowie das Erstellen eines neuen Pakets und des zugehörigen [SSM-Dokuments](documents.md). Weitere Informationen zu unterstützten Plattformen finden Sie unter [Unterstützte Paketplattformen und -architekturen](distributor.md#what-is-a-package-platforms).
Wenn Sie die Methode „Simple (Einfach)“ verwenden, um ein Paket zu erstellen, erstellt Distributor die `install`- und `uninstall`-Skripts für Sie. Wenn Sie jedoch ein Paket für ein direktes Update erstellen, müssen Sie Ihren eigenen `update`-Skript-Inhalt in der Registerkarte **Update script ** bereitstellen.. Wenn Sie Eingabebefehle für ein `update`-Skript hinzufügen, schließt Distributor dieses Skript zusammen mit den `install`- und `uninstall`-Skripts in das für Sie erstellte ZIP-Paket ein.
**Anmerkung**
Verwenden Sie die Aktualisierungsoption `In-place` zum Hinzufügen neuer oder aktualisierter Dateien einer vorhandenen Paketinstallation, ohne die zugehörige Anwendung offline zu schalten.
**Erstellen Sie ein Paket mithilfe des einfachen Workflows**
1. Öffnen Sie die Konsole unter. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählen Sie auf der Distributor-Startseite die Option **Create package (Paket erstellen)** aus und wählen Sie dann die Option **Simple (Einfach)**.
1. Geben Sie auf der Seite **Create package (Paket erstellen)** einen Namen für Ihr Paket ein. Paketnamen können Buchstaben, Zahlen, Punkte, Bindestriche und Unterstriche enthalten. Der Name sollte allgemein genug sein, um auf alle Versionen der Paketanhänge angewendet werden zu können, jedoch spezifisch genug, um den Zweck des Pakets zu identifizieren.
1. (Optional) Geben Sie unter **Version name (Versionsname)** einen Versionsnamen ein. Versionsnamen dürfen maximal 512 Zeichen lang sein und dürfen keine Sonderzeichen enthalten.
1. Wählen Sie unter **Location (Speicherort)** einen Bucket aus. Verwenden Sie dazu den Namen und das Präfix des Buckets oder die Bucket-URL.
1. Wählen Sie unter **Upload software** (Software hochladen) die Option **Add software** (Software hinzufügen) aus und navigieren Sie dann zu installierbaren Softwaredateien mit den Erweiterungen `.rpm`, `.msi`, oder `.deb`. Wenn der Dateiname Leerzeichen enthält, schlägt der Upload fehl. Sie können mehrere Softwaredateien in einer einzigen Aktion hochladen.
1. Überprüfen Sie unter Für **Target platform (Ziel-Plattform** für jede Plattform, ob das Ziel-Betriebssystem für die installierbare Datei korrekt ist. Wenn das angezeigte Betriebssystem nicht korrekt ist, wählen Sie das richtige Betriebssystem aus der Dropdown-Liste aus.
Beim Workflow **Simple (Einfach)** zur Paketerstellung sind zusätzliche Schritte erforderlich, wenn Distributor nur eine Datei für mehrere Betriebssysteme verwenden soll, da installierbare Dateien nur einmal hochgeladen werden. Wenn Sie zum Beispiel eine installierbare Softwaredatei mit dem Namen `Logtool_v1.1.1.rpm` hochladen, müssen Sie einige Standardeinstellungen für den **Einfach**-Workflow ändern, um unter Amazon-Linux- und Ubuntu Server-Betriebssystemen dieselbe Software als Ziel festzulegen. Führen Sie bei Verwendung mehrerer Zielplattformen einen der folgenden Schritte aus.
+ Verwenden Sie stattdessen den Workflow **Advanced** (Erweitert), zippen Sie jede installierbare Datei, bevor Sie beginnen, und richten Sie das Manifest manuell so ein, dass eine installierbare Datei für mehrere Betriebssystemplattformen oder -versionen verwendet werden kann. Weitere Informationen finden Sie unter [Erstellen Sie ein Paket mithilfe des erweiterten Workflows](#distributor-working-with-packages-create-adv).
+ Bearbeiten Sie die Manifestdatei im Workflow **Simple (Einfach)** so, dass Ihre ZIP-Datei für mehrere Betriebssystemplattformen oder -versionen verwendet wird. Weitere Informationen zu diesem Verfahren finden Sie am Ende von Schritt 4 in [Schritt 2: Erstellen des JSON-Paketmanifests](#packages-manifest).
1. Stellen Sie unter **Platform version (Plattformversion)**sicher, dass als Betriebssystem-Plattformversion **\$1any**, eine Hauptversionsnummer, gefolgt von einem Platzhalter (7.\$1), angezeigt wird, oder genau die spezifische Betriebssystemversion, die Sie als Plattformversion für Ihre Softwareinstallation verwenden möchten. Weitere Informationen zur Angabe der Betriebssystem-Plattformversion finden Sie unter Schritt 4 in [Schritt 2: Erstellen des JSON-Paketmanifests](#packages-manifest).
1. Wählen Sie unter **Architecture (Architektur)** für jeden installierbare Datei die richtige Prozessorarchitektur aus der Dropdown-Liste aus. Weitere Informationen zu unterstützten Prozessorarchitekturen finden Sie unter [Unterstützte Paketplattformen und -architekturen](distributor.md#what-is-a-package-platforms).
1. (Optional) Erweitern Sie **Scripts (Skripts)** und überprüfen Sie die Skripts, die Distributor für Ihre installierbare Software generiert hat.
1. (Optional) Um ein Aktualisierungsskript für direkte Aktualisierungen bereitzustellen, erweitern Sie **Scripts (Skripts)**, wählen Sie die Registerkarte **Update script (Aktualisierungsskript)** aus und geben Sie die Befehle für das Aktualisierungsskript ein.
Systems Manager generiert keine Aktualisierungsskripts für Sie.
1. Zum Hinzufügen weiterer installierbaren Softwaredateien wählen Sie **Add Software (Software hinzufügen)**. Andernfalls fahren Sie mit dem nächsten Schritt fort.
1. (Optional) Erweitern Sie **Manifest** und überprüfen Sie das JSON-Manifest des Pakets, das Distributor für Ihre installierbare Software generiert hat. Wenn Sie Informationen über Ihre Software geändert haben, nachdem Sie mit dieser Prozedur begonnen haben, beispielsweise die Plattformversion oder die Zielplattform, wählen Sie **Generate Manifest (Manifest erzeugen)**, um das Paketmanifest zu aktualisieren.
Sie können das Manifest manuell bearbeiten, wenn Sie möchten, dass für eine installierbare Software mehr als ein Betriebssystem als Ziel festgelegt wird, wie in Schritt 8 beschrieben. Weitere Informationen zum Bearbeiten des Manifests finden Sie unter [Schritt 2: Erstellen des JSON-Paketmanifests](#packages-manifest).
1. Wählen Sie **Create package (Paket erstellen)** aus.
Warten Sie, bis Distributor das Hochladen Ihrer Software und das Erstellen Ihres Pakets abgeschlossen hat. Distributor zeigt den Uploadstatus für jede installierbare Datei einzeln an. Abhängig von der Anzahl und Größe der Pakete, die Sie hinzufügen, kann dies einige Minuten dauern. Distributor leitet Sie automatisch auf die Seite **Package details (Paketdetails)** für das neue Paket weiter, Sie können diese Seite aber jederzeit selbst öffnen, nachdem die Software hochgeladen ist. Auf der Seite **Package details (Paketdetails)** werden erst dann alle Informationen zu Ihrem Paket angezeigt, wenn Distributor den Paketerstellungsprozess abgeschlossen hat. Um den Upload- und Paketerstellungsprozess abzubrechen, wählen Sie **Cancel (Abbrechen)**.
Wenn Distributor keine installierbaren Softwaredateien hochladen kann, wird eine Fehlermeldung **Upload failed (Upload fehlgeschlagen)** angezeigt. Um den Uploadversuch zu wiederholen, wählen Sie **Retry Upload (Uploadversuch wiederholen)**. Weitere Informationen zur Fehlerbehebung bei der Paketerstellung finden Sie unter [Problembehebung AWS Systems ManagerDistributor](distributor-troubleshooting.md).
## Erstellen Sie ein Paket mithilfe des erweiterten Workflows
In diesem Abschnitt erfahren Sie, wie fortgeschrittene Benutzer ein Paket in Distributor erstellen können, nachdem sie die installierbaren Komponenten mit den Skripts zur Installation und Deinstallation, sowie eine JSON-Manifestdatei als ZIP-Archiv an einen Amazon S3-Bucket hochgeladen haben.
Um ein Paket zu erstellen, bereiten Sie Ihre ZIP-Dateien mit den zu installierenden Komponenten vor (eine ZIP-Datei pro Betriebssystemplattform). Zur Erstellung eines Pakets ist mindestens eine ZIP-Datei erforderlich. Erstellen Sie als Nächstes ein JSON-Manifest. Das Manifest enthält Verweise auf Ihre Paketcodedateien. Wenn Sie die erforderlichen Codedateien zu einem Ordner oder Verzeichnis hinzugefügt haben und das Manifest mit den korrekten Werten ausgefüllt ist, laden Sie Ihr Paket an einen S3-Bucket hoch.
Ein Beispielpaket, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), steht für Sie zum Herunterladen von unserer Website zur Verfügung. Das Beispielpaket enthält ein fertiges JSON-Manifest und drei ZIP-Dateien.
**Topics**
+ [Schritt 1: Erstellen der ZIP-Dateien](#packages-zip)
+ [Schritt 2: Erstellen des JSON-Paketmanifests](#packages-manifest)
+ [Schritt 3: Hochladen von Paket und Manifest zu einem Amazon S3-Bucket](#packages-upload-s3)
+ [Schritt 4: Hinzufügen eines Pakets zu Distributor](#distributor-working-with-packages-add)
### Schritt 1: Erstellen der ZIP-Dateien
Die Grundlage Ihres Pakets ist mindestens eine ZIP-Datei mit Softwaredateien oder zu installierenden Komponenten. Ein Paket enthält eine ZIP-Datei pro Betriebssystem, das Sie unterstützen möchten, es sei denn, eine ZIP-Datei kann auf mehreren Betriebssystemen installiert werden. Beispielsweise können unterstützte Versionen von Red Hat Enterprise Linux- und Amazon-Linux-Instances in der Regel dieselben ausführbaren RPM-Dateien ausführen. Daher müssen Sie Ihrem Paket nur eine ZIP-Datei anfügen, um beide Betriebssysteme zu unterstützen.
**Erforderliche Dateien**
Die folgenden Elemente müssen in jeder ZIP-Datei enthalten sein:
+ Ein **install** und ein **uninstall** Skript. Windows Serverbasierte verwaltete Knoten benötigen PowerShell Skripten (Skripten mit dem Namen `install.ps1` und`uninstall.ps1`). Linux-basierte verwaltete Knoten benötigen Shell-Skripts (Skripts mit dem Namen `install.sh` und `uninstall.sh`). SSM Agent führt die Anweisungen in den **install**- und **uninstall**-Skripts aus.
Ihre Installationsskripts können beispielsweise ein Installationsprogramm ausführen (z. B. eine RPM- oder MSI-Datei), Dateien kopieren oder Konfigurationseinstellungen festlegen.
+ Eine ausführbare Datei, Installationsprogrammpakete (.rpm, .deb, .msi usw.), weitere Skripts oder Konfigurationsdateien.
**Optionale Dateien**
Die folgenden Elemente können optional in jeder ZIP-Datei enthalten sein:
+ Ein **update**-Skript. Die Angabe eines Aktualisierungsskripts ermöglicht es Ihnen, die Option `In-place update` zum Installieren eines Pakets zu verwenden. Wenn Sie einer vorhandenen Paketinstallation neue oder aktualisierte Dateien hinzufügen möchten, wird die Paketanwendung bei dieser `In-place update` Option nicht offline geschaltet, während das Update ausgeführt wird. Windows Serverbasierte verwaltete Knoten benötigen ein PowerShell Skript (mit dem Namen`update.ps1`). Linux-basierte verwaltete Knoten benötigen ein Shell-Skript (Skript mit dem Namen `update.sh`). SSM Agent führt die Anweisungen im **update**-Skript aus.
Weitere Informationen zum Installieren oder Aktualisieren von Paketen finden Sie unter [Installieren oder Aktualisieren von Distributor-Paketen](distributor-working-with-packages-deploy.md).
Für Beispiele für ZIP-Dateien, einschließlich Beispiel **install** - und **uninstall** Skripten, laden Sie das Beispielpaket ([ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip)) herunter.
### Schritt 2: Erstellen des JSON-Paketmanifests
Nachdem Sie die zu installierenden Dateien vorbereitet und gezippt haben, erstellen Sie ein JSON-Manifest. Im Folgenden finden Sie eine Vorlage. Die einzelnen Teile der Manifestvorlage werden im Verfahren in diesem Abschnitt beschrieben. Sie können einen JSON-Editor verwenden, um dieses Manifest in einer eigenen Datei zu erstellen. Alternativ können Sie das Manifest in der AWS Systems Manager Konsole erstellen, wenn Sie ein Paket erstellen.
```
{
"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"
}
}
}
}
```
**So erstellen Sie ein JSON-Paket-Manifest**
1. Fügen Sie Ihrem Manifest die Schemaversion hinzu. In dieser Version ist die Schemaversion stets `2.0`.
```
{ "schemaVersion": "2.0",
```
1. Fügen Sie Ihrem Manifest eine benutzerdefinierte Paketversion hinzu. Dies ist auch der Wert in **Version name (Versionsname)**, den Sie angeben, wenn Sie Ihr Paket zu Distributor hinzufügen. Er wird Teil des AWS Systems Manager -Dokuments, das Distributor erstellt, wenn Sie Ihr Paket hinzufügen. Sie stellen diesen Wert auch als Eingabewert im Dokument `AWS-ConfigureAWSPackage` bereit, um eine andere als die aktuelle Version des Pakets zu installieren. Ein `version`-Wert kann Buchstaben, Zahlen, Unterstriche, Bindestriche und Punkte enthalten. Er darf jedoch höchstens 128 Zeichen enthalten. Sie sollten eine von Menschen lesbare Paketversion verwenden, um bei Bereitstellungen die Angabe der genauen Paketversionen für Sie und andere Administratoren einfacher zu machen. Im Folgenden wird ein -Beispiel gezeigt.
```
"version": "1.0.1",
```
1. (Optional) Fügen Sie den Namen des Publishers hinzu. Im Folgenden wird ein -Beispiel gezeigt.
```
"publisher": "MyOrganization",
```
1. Fügen Sie Pakete hinzu. Der Abschnitt `"packages"` beschreibt die von den ZIP-Dateien in Ihrem Paket unterstützten Plattformen, Versionen und Architekturen. Weitere Informationen finden Sie unter [Unterstützte Paketplattformen und -architekturen](distributor.md#what-is-a-package-platforms).
Das *platform-version* kann der Platzhalterwert sein,`_any`. Sie verwenden den Platzhalterwert, um anzugeben, dass eine ZIP-Datei eine beliebige Version der Plattform unterstützt. Sie können auch eine Hauptversion und gefolgt von einem Platzhalter angeben, sodass alle Nebenversionen unterstützt werden, z. B. 7.\$1. Wenn Sie einen *platform-version* Wert für eine bestimmte Betriebssystemversion angeben möchten, stellen Sie sicher, dass er genau der Release-Version des Betriebssystems entspricht, auf AMI das Sie abzielen. Im Folgenden werden Ressourcen empfohlen, mit denen Sie den richtigen Wert für das Betriebssystem ermitteln können.
+ Auf einem Windows Server-basierten verwalteten Knoten ist die Version in Form von Windows Management Instrumentation (WMI)-Daten verfügbar. Sie können den folgenden Befehl im Prompt ausführen, um Versionsinformationen zu erhalten. Anschließend müssen Sie die Ergebnisse nach `version` durchsuchen.
```
wmic OS get /format:list
```
+ Auf einem Linux-basierten verwalteten Knoten erhalten Sie die Version, indem Sie zunächst nach der Betriebssystemversion scannen (der folgende Befehl). Suchen Sie den Wert von `VERSION_ID`.
```
cat /etc/os-release
```
Wenn die ausgegebene Zeichenfolge nicht die benötigten Informationen enthält, führen Sie den folgenden Befehl aus, um die LSB-Versionsinformationen aus der Datei `/etc/lsb-release` abzurufen, und suchen den Wert von `DISTRIB_RELEASE`.
```
lsb_release -a
```
Wenn diese Methoden nicht zum Erfolg führen, finden Sie die Version in der Regel anhand der verwendeten Distribution. In Debian Server können Sie beispielsweise die Datei `/etc/debian_version` und in Red Hat Enterprise Linux die Datei `/etc/redhat-release` scannen.
```
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"
}
}
}
}
```
Im Folgenden wird ein -Beispiel gezeigt. In diesem Beispiel ist die Betriebssystemplattform `amazon`, die unterstützte Version `2016.09`, die Architektur `x86_64` und die ZIP-Datei, die diese Plattform unterstützt, `test.zip`.
```
{
"amazon": {
"2016.09": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
Sie können mit dem Platzhalterwert (`_any`) angeben, dass das Paket alle Versionen des übergeordneten Elements unterstützt. Um beispielsweise anzugeben, dass das Paket in jeder Version von Amazon Linuxs unterstützt wird, sollte Ihre Paketanweisung ähnlich wie folgt aussehen. Sie können den Platzhalter `_any` auf Versions- oder Architekturebene verwenden, um alle Versionen einer Plattform, alle Architekturen in einer Version oder alle Versionen und alle Architekturen einer Plattform zu unterstützen.
```
{
"amazon": {
"_any": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
Das folgende Beispiel fügt `_any` hinzu, um zu zeigen, dass das erste Paket `data1.zip` für alle Architekturen von Amazon Linux 2016.09 unterstützt wird. Das zweite Paket (`data2.zip`) wird für alle Versionen von Amazon Linux unterstützt, jedoch nur für verwaltete Knoten mit `x86_64`-Architektur. Sowohl die Version mit `2023.8` als auch die Version mit `_any` sind Einträge unter `amazon`. Es handelt sich um eine einzige Plattform (Amazon Linux), aber verschiedene unterstützte Versionen und Architekturen sowie zugehörige ZIP-Dateien.
```
{
"amazon": {
"2023.8": {
"_any": {
"file": "data1.zip"
}
},
"_any": {
"x86_64": {
"file": "data2.zip"
}
}
}
}
```
Sie können im Abschnitt `"packages"` des Manifests mehrmals auf eine ZIP-Datei verweisen, wenn diese mehrere Plattformen unterstützt. Wenn Sie beispielsweise eine ZIP-Datei haben, die sowohl Red Hat Enterprise Linux 8.x-Versionen als auch Amazon Linux unterstützt, haben Sie zwei Einträge in dem `"packages"` Abschnitt, die auf dieselbe .zip-Datei verweisen, wie im folgenden Beispiel gezeigt.
```
{
"amazon": {
"2023.8.20250715 ": {
"x86_64": {
"file": "test.zip"
}
}
},
"redhat": {
"8.*": {
"x86_64": {
"file": "test.zip"
}
}
}
},
```
1. Fügen Sie die Liste mit den zu diesem Paket gehörenden ZIP-Dateien aus Schritt 4 hinzu. Für jeden Dateieintrag sind der Dateiname und die Prüfsumme des `sha256`-Hash-Werts erforderlich. Die Prüfsummenwerte im Manifest müssen mit dem `sha256`-Hash-Wert in den gezippten Ressourcen übereinstimmen, um zu verhindern, dass die Paketinstallation fehlschlägt.
Um die korrekte Prüfsumme aus den zu installierenden Dateien zu erhalten, können Sie die folgenden Befehle ausführen. In Linux führen Sie `shasum -a 256 file-name.zip` oder `openssl dgst -sha256 file-name.zip` aus. Führen Sie unter Windows das Cmdlet in aus. `Get-FileHash -Path path-to-.zip-file` [PowerShell](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-6)
Der Abschnitt `"files"` des Manifests enthält einen Verweis auf jede ZIP-Datei in Ihrem Paket.
```
"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. Nachdem Sie die Paketinformationen hinzugefügt haben, speichern und schließen Sie die Manifestdatei.
Im Folgenden finden Sie ein Beispiel für ein fertiges Manifest. In diesem Beispiel haben Sie eine ZIP-Datei `NewPackage_LINUX.zip`, die mehrere Plattformen unterstützt, jedoch nur einmal im Abschnitt `"files"` referenziert wird.
```
{
"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"
}
}
}
}
```
#### Beispiel für ein Paket
Ein Beispielpaket, [ExamplePackage.zip](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/ExamplePackage.zip), steht Ihnen auf unserer Website zum Herunterladen zur Verfügung. Das Beispielpaket enthält ein fertiges JSON-Manifest und drei ZIP-Dateien.
### Schritt 3: Hochladen von Paket und Manifest zu einem Amazon S3-Bucket
Bereiten Sie Ihr Paket vor, indem Sie alle ZIP-Dateien in einen Ordner oder ein Verzeichnis kopieren oder verschieben. Ein Paket ist nur gültig, wenn es das von Ihnen in [Schritt 2: Erstellen des JSON-Paketmanifests](#packages-manifest) erstellte Manifest und alle ZIP-Dateien enthält, die in der Dateiliste des Manifests angegeben sind.
**So laden Sie das Paket und das Manifest in Amazon S3 hoch**
1. Kopieren oder verschieben Sie alle von Ihnen im Manifest angegebenen ZIP-Archivdateien in einen Ordner oder ein Verzeichnis. Komprimieren Sie nicht den Ordner oder das Verzeichnis, in das/den Sie die ZIP-Archivdateien und die Manifestdatei verschieben.
1. Erstellen Sie einen Bucket, oder wählen Sie einen vorhandenen Bucket aus. Weitere Informationen finden Sie unter [Create a Bucket (Bucket erstellen)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) im *Amazon Simple Storage Service Getting Started Guide (Amazon Simple Storage Service Erste-Schritte-Leitfaden)*. Weitere Informationen darüber, wie Sie einen AWS CLI Befehl ausführen, um einen Bucket zu erstellen, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mb.html)in der *AWS CLI Befehlsreferenz.*
1. Laden Sie den Ordner oder das Verzeichnis zum Bucket hoch. Anleitungen finden Sie unter [Hinzufügen eines Objekts zu einem Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PuttingAnObjectInABucket.html) im *Erste Schritte-Handbuch zu Amazon Simple Storage Service*. Wenn Sie Ihr JSON-Manifest in die AWS Systems Manager Konsole einfügen möchten, laden Sie das Manifest nicht hoch. Weitere Informationen zum Ausführen eines AWS CLI Befehls zum Hochladen von Dateien in einen Bucket finden Sie [https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html](https://docs.aws.amazon.com/cli/latest/reference/s3/mv.html)in der *AWS CLI Befehlsreferenz*.
1. Wählen Sie auf der Startseite des Buckets den von Ihnen hochgeladenen Ordner oder das Verzeichnis aus. Wenn Sie Ihre Dateien in einen Unterordner in einem Bucket hochgeladen haben, stellen Sie sicher, dass Sie sich den Namen des Unterordner notieren (wird auch als *Präfix* bezeichnet). Sie benötigen das Präfix, um Ihr Paket zu Distributor hinzuzufügen.
### Schritt 4: Hinzufügen eines Pakets zu Distributor
Sie können die AWS Systems Manager Konsole, die AWS Befehlszeilentools (AWS CLI und AWS -Tools für PowerShell) verwenden oder AWS SDKs ein neues Paket hinzufügenDistributor. Wenn Sie ein Paket hinzufügen, fügen Sie ein neues [SSM-Dokument](documents.md) hinzu. Mit dem Dokument können Sie das Paket an verwaltete Knoten bereitstellen.
**Topics**
+ [Fügen Sie ein Paket mit der Konsole hinzu](#create-pkg-console)
+ [Fügen Sie ein Paket hinzu, indem Sie AWS CLI](#create-pkg-cli)
#### Fügen Sie ein Paket mit der Konsole hinzu
Sie können die AWS Systems Manager Konsole verwenden, um ein Paket zu erstellen. Halten Sie den Namen des Buckets bereit, auf den Sie in Ihr Paket in [Schritt 3: Hochladen von Paket und Manifest zu einem Amazon S3-Bucket](#packages-upload-s3) hochgeladen haben.
**So fügen Sie Distributor ein Paket hinzu (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählenen Sie auf der Distributor-Startseite die Option **Create package** (Paket erstellen) und klicken Sie dann auf **Advanced** (Erweitert).
1. Geben Sie auf der Seite **Create package (Paket erstellen)** einen Namen für Ihr Paket ein. Paketnamen können Buchstaben, Zahlen, Punkte, Bindestriche und Unterstriche enthalten. Der Name sollte allgemein genug sein, um auf alle Versionen der Paketanhänge angewendet werden zu können, jedoch spezifisch genug, um den Zweck des Pakets zu identifizieren.
1. Geben Sie unter **Version name (Versionsname)** den exakten Wert des Eintrags `version` in Ihrer Manifestdatei ein.
1. Wählen Sie unter **S3 bucket name (S3-Bucketname)** den Namen des Buckets aus, in den Sie Ihre ZIP-Dateien und das Manifest in [Schritt 3: Hochladen von Paket und Manifest zu einem Amazon S3-Bucket](#packages-upload-s3) hochgeladen haben.
1. Geben Sie unter **S3 key prefix (S3-Schlüsselpräfix)** den Unterordner des Buckets ein, in dem Ihre ZIP-Dateien und das Manifest gespeichert sind.
1. Wählen Sie unter **Manifest** die Option **Extract from package (Aus Paket extrahieren)** aus, um ein Manifest zu verwenden, das Sie mit Ihren ZIP-Dateien in den Amazon S3-Bucket hochgeladen haben.
(Optional) Wenn Sie Ihr JSON-Manifest nicht in den S3-Bucket hochgeladen haben, in dem Ihre ZIP-Dateien gespeichert sind, wählen Sie **New Manifest (Neues Manifest)** aus. Sie können das gesamte Manifest in dem JSON-Editor erstellen oder in ihn hineinkopieren. Weitere Informationen zum Erstellen des JSON-Manifests finden Sie unter [Schritt 2: Erstellen des JSON-Paketmanifests](#packages-manifest).
1. Wenn das Manifest fertiggestellt ist, wählen Sie **Create package (Paket erstellen)**.
1. Warten Sie, bis Distributor die Erstellung des Pakets aus den ZIP-Dateien und dem Manifest abgeschlossen hat. Abhängig von der Anzahl und Größe der Pakete, die Sie hinzufügen, kann dies einige Minuten dauern. Distributor leitet Sie automatisch auf die Seite **Package details (Paketdetails)** für das neue Paket weiter, Sie können diese Seite aber jederzeit selbst öffnen, nachdem die Software hochgeladen ist. Auf der Seite **Package details (Paketdetails)** werden erst dann alle Informationen zu Ihrem Paket angezeigt, wenn Distributor den Paketerstellungsprozess abgeschlossen hat. Um den Upload- und Paketerstellungsprozess abzubrechen, wählen Sie **Cancel (Abbrechen)**.
#### Fügen Sie ein Paket hinzu, indem Sie AWS CLI
Sie können den verwenden AWS CLI , um ein Paket zu erstellen. Halten Sie die URL für den Bucket bereit, zu dem Sie Ihr Paket in [Schritt 3: Hochladen von Paket und Manifest zu einem Amazon S3-Bucket](#packages-upload-s3) hochgeladen haben.
**Um ein Paket zu Amazon S3 hinzuzufügen, verwenden Sie AWS CLI**
1. Um das zum Erstellen eines Pakets AWS CLI zu verwenden, führen Sie den folgenden Befehl aus und *package-name* ersetzen Sie ihn durch den Namen Ihres Pakets und *path-to-manifest-file* durch den Dateipfad für Ihre JSON-Manifestdatei. amzn-s3-demo-bucket ist die URL des Amazon S3-Buckets, in dem das gesamte Paket gespeichert ist. Wenn Sie den Befehl **create-document** in Distributor ausführen, geben Sie den `Package`-Wert für `--document-type` an.
Wenn Sie Ihre Manifestdatei nicht dem Amazon S3-Bucket hinzugefügt haben, ist der `--content`-Parameterwert der Dateipfad zur JSON-Manifestdatei.
```
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
```
Im Folgenden wird ein -Beispiel gezeigt.
```
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. Vergewissern Sie sich, dass Ihr Paket hinzugefügt wurde, und zeigen Sie das Paketmanifest an, indem Sie den folgenden Befehl ausführen und ihn durch den Namen Ihres Pakets ersetzen*package-name*. Um eine spezifische Version des Dokuments (nicht identisch mit der Version eines Pakets) zu erhalten, können Sie den Parameter `--document-version` hinzufügen.
```
aws ssm get-document \
--name "package-name"
```
Informationen zu anderen Optionen, die Sie mit dem Befehl **create-document** verwenden können, finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-document.html) im Abschnitt AWS Systems Manager der *AWS CLI -Command Reference*. Informationen zu anderen Optionen, die Sie mit dem Befehl **get-document** verwenden können, finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/get-document.html).
# Bearbeiten von Distributor-Paketberechtigungen in der Konsole
Nachdem Sie ein Paket zu Distributor einem Tool hinzugefügt haben AWS Systems Manager, können Sie die Berechtigungen des Pakets in der Systems Manager Manager-Konsole bearbeiten. Sie können AWS-Konten den Berechtigungen eines Pakets weitere hinzufügen. Pakete können nur für andere Konten in derselben AWS-Region freigegeben werden. Die Freigabe über Regionsgrenzen hinweg wird nicht unterstützt. Standardmäßig sind Pakete auf **Privat** gesetzt, was bedeutet, dass nur diejenigen, die Zugriff auf die Daten des Paketerstellers haben, die Paketinformationen einsehen und das Paket aktualisieren oder löschen AWS-Konto können. Wenn **Private (Privat)**-Berechtigungen akzeptabel sind, können Sie dieses Verfahren überspringen.
**Anmerkung**
Sie können die Berechtigungen von Paketen aktualisieren, die mit 20 oder weniger Konten freigegeben werden.
**Bearbeiten von Paketberechtigungen in der Konsole**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählen Sie auf der Seite **Packages (Pakete)** das Paket aus, für das Sie Berechtigungen bearbeiten möchten.
1. Wählen Sie auf der Registerkarte **Package details (Paketdetails)** die Option **Edit permissions (Berechtigungen bearbeiten)** aus, um Berechtigungen zu ändern.
1. Wählen Sie unter **Edit permissions (Berechtigungen bearbeiten)** die Option **Shared with specific accounts (Für bestimmte Konten freigegeben)** aus.
1. Fügen Sie in **Shared with specific accounts (Für bestimmte Konten freigegeben)** nacheinander AWS-Konto hinzu. Wenn Sie fertig sind, wählen Sie **Speichern**.
# Bearbeiten von Distributor-Paket-Tags in der Konsole
Nachdem Sie ein Paket zu einem Tool hinzugefügt habenDistributor, können Sie die Tags des Pakets in der Systems Manager Manager-Konsole bearbeiten. AWS Systems Manager Diese Tags werden auf das Paket angewendet. Sie haben keine Verbindung zu Tags in dem verwalteten Knoten, auf dem Sie das Paket bereitstellen möchten. Tags unterscheiden nach Groß- und Kleinschreibung. Es handelt sich um Schlüssel-Wert-Paare, die Ihnen helfen können, Ihre Pakete nach für Ihre Organisation relevanten Kriterien zu gruppieren und zu filtern. Wenn Sie keine Tags hinzufügen möchten, können Sie Ihr Paket installieren oder eine neue Version hinzufügen.
**So bearbeiten Sie Paket-Tags in der Konsole**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählen Sie auf der Seite **Packages (Pakete)** das Paket aus, für das Sie Tags bearbeiten möchten.
1. Wählen Sie auf der Registerkarte **Package details (Paketdetails)** in **Tags (Tags)** die Option **Edit (Bearbeiten)** aus.
1. Geben Sie unter **Add tags (Tags hinzufügen)** einen Schlüssel oder ein Schlüssel-Wert-Paar für das Tag ein. Klicken Sie anschließend auf **Add (Hinzufügen)**. Wiederholen Sie dies, wenn Sie weitere Tags hinzufügen möchten. Um Tags zu löschen, wählen Sie unten im Fenster für das Tag **X** aus.
1. Wenn Sie Ihrem Paket keine weiteren Tags mehr hinzufügen möchten, wählen Sie **Save (Speichern)** aus.
# Hinzufügen einer Version zu einem Distributor-Paket
Um eine Paketversion hinzuzufügen, [erstellen Sie ein Paket](distributor-working-with-packages-create.md) und verwenden Sie es dann, Distributor um eine Paketversion hinzuzufügen, indem Sie dem AWS Systems Manager (SSM-) Dokument, das bereits für ältere Versionen vorhanden ist, einen Eintrag hinzufügen. Distributorist ein Tool in AWS Systems Manager. Um Zeit zu sparen, aktualisieren Sie das Manifest für eine ältere Version des Pakets, ändern den Wert des Eintrags `version` im Manifest (z. B. von `Test_1.0` in `Test_2.0`) und speichern das Manifest als Manifest für die neue Version. Bei dem einfachen **Add Version (Version hinzufügen)**-Workflow in der Distributor-Konsole wird das Manifest automatisch aktualisiert.
Eine neue Paketversion kann:
+ Mindestens eine der installierbaren Dateien ersetzen, die der aktuellen Version angefügt sind.
+ Neue installierbare Dateien hinzufügen, um zusätzliche Plattformen zu unterstützen
+ Dateien löschen, um die Unterstützung für bestimmte Plattformen zu beenden
Eine neuere Version kann denselben Amazon Simple Storage Service (Amazon S3)-Bucket verwenden, muss jedoch eine URL mit einem anderen Dateinamen am Ende besitzen. Sie können die Systems Manager-Konsole oder das AWS Command Line Interface (AWS CLI) verwenden, um die neue Version hinzuzufügen. Beim Hochladen einer installierbaren Datei mit demselben Namen wie eine vorhandene installierbare Datei in dem Amazon S3-Bucket wird die vorhandene Datei überschrieben. Es werden keine Dateien aus der älteren Version in die neue Version hineinkopiert. Sie müssen installierbare Dateien aus der älteren Version erneut hochladen, damit sie in die neue Version aufgenommen werden. Nachdem Distributor Ihre neue Paketversion erstellt hat, können Sie den Amazon S3-Bucket löschen oder wiederverwenden, da Distributor Ihre Software im Rahmen der Versioning in einen internen Systems Manager-Bucket kopiert.
**Anmerkung**
Jedes Paket ist auf maximal 25 Versionen beschränkt. Sie können Versionen löschen, die nicht mehr benötigt werden.
**Topics**
+ [Hinzufügen einer Paketversion mit der Konsole](#add-pkg-version)
+ [Hinzufügen einer Paketversion mit dem AWS CLI](#add-pkg-version-cli)
## Hinzufügen einer Paketversion mit der Konsole
Führen Sie vor der Ausführung der folgenden Schritte die Anweisungen unter [Erstellen eines Pakets in Distributor](distributor-working-with-packages-create.md) aus, um ein neues Paket für die Version zu erstellen. Verwenden Sie anschließend die Systems Manager-Konsole, um Distributor eine neue Paketversion hinzuzufügen.
### Hinzufügen einer Paketversion mithilfe des einfachen Workflows
Um eine Paketversion mithilfe des **einfachen** Workflows hinzuzufügen, bereiten Sie aktualisierte installierbare Dateien vor oder fügen Sie installierbare Dateien hinzu, um weitere Plattformen und Architekturen zu unterstützen. Verwenden Sie anschließend Distributor zum Hochladen neuer und aktualisierter installierbarer Dateien und fügen Sie eine Paketversion hinzu. Die vereinfachte **Add version (Version hinzufügen)**-Workflow in der Distributor Konsole aktualisiert die Manifestdatei und das zugehörige SSM-Dokument automatisch.
**Hinzufügen einer Paketversion mithilfe des einfachen Workflows**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählen Sie auf der Distributor-Startseite das Paket aus, dem Sie eine weitere Version hinzufügen möchten.
1. Wählen Sie auf der Seite **Add version (Version hinzufügen)** die Option **Simple (Einfach)**.
1. Geben Sie unter **Version name (Versionsname)** einen Versionsnamen ein. Der Versionsname für die neue Version muss sich von der älteren Version unterscheiden. Versionsnamen dürfen maximal 512 Zeichen lang sein und dürfen keine Sonderzeichen enthalten.
1. Wählen Sie für **S3 bucket name (S3-Bucketname)**, einen vorhandenen S3-Bucket aus der Liste aus. Dabei kann es sich um den Bucket handeln, den Sie zum Speichern installierbarer Dateien für ältere Versionen verwendet haben, aber die installierbaren Dateinamen müssen unterschiedlich sein, damit das Überschreiben vorhandener installierbaren Dateien in dem Bucket vermieden wird.
1. Geben Sie unter **S3 key prefix (S3-Schlüsselpräfix)** den Unterordner des Buckets ein, in dem Ihre installierbaren Komponenten gespeichert sind.
1. Navigieren Sie unter **Upload Software (Software hochladen)** zu den installierbaren Softwaredateien, die Sie für die neue Version anfügen möchten. Installierbare Versionen von vorhandenen Dateien werden nicht automatisch in eine neue Version herüberkopiert. Sie müssen alle installierbaren Dateien aus älteren Versionen des Pakets erneut hochladen, wenn Sie diese in die neue Version übernehmen möchten. Sie können mehrere Softwaredateien in einer einzigen Aktion hochladen.
1. Überprüfen Sie unter Für **Target platform (Ziel-Plattform** für jede Plattform, ob das Ziel-Betriebssystem für die installierbare Datei korrekt ist. Wenn das angezeigte Betriebssystem nicht korrekt ist, wählen Sie das richtige Betriebssystem aus der Dropdown-Liste aus.
Bei dem Workflow **Simple (Einfach)** zur Versioning sind zusätzliche Schritte erforderlich, wenn nur eine Datei für mehrere Betriebssysteme als Ziel verwendet werden soll, da installierbare Dateien nur einmal hochgeladen werden. Wenn Sie zum Beispiel eine installierbare Softwaredatei mit dem Namen `Logtool_v1.1.1.rpm` hochladen, müssen Sie einige Standardeinstellungen für den **Einfach**-Workflow ändern, um Distributor anzuweisen, für dieselbe Software sowohl das Amazon-Linux- als auch das Ubuntu Server-Betriebssystem als Ziel festzulegen. Um dieses Problem zu beheben, können Sie eine der folgenden Aktionen ausführen.
+ Verwenden Sie stattdessen den Workflow **Advanced (Erweitert)** zur Versioning, zippen Sie jede installierbare Datei, bevor Sie beginnen, und richten Sie das Manifest manuell so ein, dass eine installierbare Datei für mehrere Betriebssystemplattformen oder -versionen verwendet werden kann. Weitere Informationen finden Sie unter [Hinzufügen einer Paketversion mithilfe des erweiterten Workflows](#add-pkg-version-adv).
+ Bearbeiten Sie die Manifestdatei im Workflow **Simple (Einfach)** so, dass Ihre ZIP-Datei für mehrere Betriebssystemplattformen oder -versionen verwendet wird. Weitere Informationen zu diesem Verfahren finden Sie am Ende von Schritt 4 in [Schritt 2: Erstellen des JSON-Paketmanifests](distributor-working-with-packages-create.md#packages-manifest).
1. **Vergewissern Sie sich, dass es sich bei der angezeigten Plattformversion des Betriebssystems entweder **\$1any** um eine Hauptversion mit einem Platzhalter (8.\$1) oder um die genaue Betriebssystemversion handelt, für die Ihre Software gelten soll.** Weitere Informationen zum Festlegen einer Plattformversion finden Sie unter Schritt 4 in [Schritt 2: Erstellen des JSON-Paketmanifests](distributor-working-with-packages-create.md#packages-manifest).
1. Wählen Sie unter **Architecture (Architektur)** für jeden installierbare Datei die richtige Prozessorarchitektur aus der Dropdown-Liste aus. Weitere Informationen zu unterstützten Architekturen finden Sie unter [Unterstützte Paketplattformen und -architekturen](distributor.md#what-is-a-package-platforms).
1. (Optional) Erweitern Sie **Scripts (Skripts)** und überprüfen Sie die Installations- und Deinstallationsskripts, die Distributor für Ihre installierbare Software generiert hat.
1. Zum Hinzufügen weiterer installierbarer Softwaredateien zu der neuen Version wählen Sie **Add Software (Software hinzufügen)**. Andernfalls fahren Sie mit dem nächsten Schritt fort.
1. (Optional) Erweitern Sie **Manifest** und überprüfen Sie das JSON-Manifest des Pakets, das Distributor für Ihre installierbare Software generiert hat. Wenn Sie Informationen über Ihre installierbare Software geändert haben, nachdem Sie mit dieser Prozedur begonnen haben, beispielsweise die Plattformversion oder die Zielplattform, wählen Sie **Generate Manifest (Manifest erzeugen)**, um das Paketmanifest zu aktualisieren.
Sie können das Manifest manuell bearbeiten, wenn Sie möchten, dass für eine installierbare Software mehr als ein Betriebssystem als Ziel festgelegt wird, wie in Schritt 9 beschrieben. Weitere Informationen zum Bearbeiten des Manifests finden Sie unter [Schritt 2: Erstellen des JSON-Paketmanifests](distributor-working-with-packages-create.md#packages-manifest).
1. Wählen Sie nach dem Hinzufügen der Software und der Überprüfung der Daten zur Zielplattform, zur Version und zur Architektur Sie **Add version (Version hinzufügen)**.
1. Warten Sie, bis Distributor das Hochladen Ihrer Software und das Erstellen Ihres neuen Pakets abgeschlossen Hat. Distributor zeigt den Uploadstatus für jede installierbare Datei einzeln an. Abhängig von der Anzahl und Größe der Pakete, die Sie hinzufügen, kann dies einige Minuten dauern. Distributor leitet Sie automatisch auf die Seite **Package details (Paketdetails)** für das neue Paket weiter, Sie können diese Seite aber jederzeit selbst öffnen, nachdem die Software hochgeladen ist. Auf der Seite **Package details (Paketdetails)** werden erst dann alle Informationen zu Ihrem Paket angezeigt, wenn Distributor den Erstellungsprozess für die neue Paketversion abgeschlossen hat. Um den Uploadvorgang bzw. den prozess zur Erstellung der Paketversion anzuhalten, wählen Sie **Stop upload (Upload anhalten)**.
1. Wenn Distributor keine installierbaren Softwaredateien hochladen kann, wird eine Fehlermeldung **Upload failed (Upload fehlgeschlagen)** angezeigt. Um den Uploadversuch zu wiederholen, wählen Sie **Retry Upload (Uploadversuch wiederholen)**. Weitere Informationen zur Fehlerbehebung bei der Paketversionserstellung finden Sie unter [Problembehebung AWS Systems ManagerDistributor](distributor-troubleshooting.md).
1. Wenn Distributor die neue Paketversion erstellt hat. zeigen Sie auf der Seite **Details (Details)** auf der Registerkarte **Versions (Versionen)** die neue Version in der Liste der verfügbaren Paketversionen an. Legen Sie die Standardversion des Pakets fest, indem Sie eine Version auswählen. Wählen Sie anschließend **Set default version (Als Standardversion festlegen)** aus.
Wenn Sie keine Standardversion festlegen, ist die neueste Paketversion die Standardversion.
### Hinzufügen einer Paketversion mithilfe des erweiterten Workflows
Um eine Paketversion hinzuzufügen, [erstellen Sie ein Paket](distributor-working-with-packages-create.md) und verwenden Sie anschließend Distributor, um eine Paketversion hochzuladen, indem Sie dem für ältere Versionen vorhandenen SSM-Dokument einen Eintrag hinzufügen. Um Zeit zu sparen, aktualisieren Sie das Manifest für eine ältere Version des Pakets, ändern den Wert des Eintrags `version` im Manifest (z. B. von `Test_1.0` in `Test_2.0`) und speichern das Manifest als Manifest für die neue Version. Sie müssen das Manifest so ändern, dass eine neue Version des Pakets hinzugefügt wird. Dies führen Sie mit dem **Advanced**-Workflow durch.
**Hinzufügen einer Paketversion mithilfe des erweiterten Workflows**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählen Sie auf der Distributor-Startseite das Paket aus, dem Sie eine weitere Version hinzufügen möchten, an wählen Sie dann **Add version (Version hinzufügen)**.
1. Geben Sie unter **Version name (Versionsname)** den exakten Wert des Eintrags `version` Ihrer Manifestdatei ein.
1. Wählen Sie für **S3 bucket name (S3-Bucketname)**, einen vorhandenen S3-Bucket aus der Liste aus. Dabei kann es sich um den Bucket handeln, den Sie zum Speichern installierbarer Dateien für ältere Versionen verwendet haben, aber die installierbaren Dateinamen müssen unterschiedlich sein, damit das Überschreiben vorhandener installierbaren Dateien in dem Bucket vermieden wird.
1. Geben Sie unter **S3 key prefix (S3-Schlüsselpräfix)** den Unterordner des Buckets ein, in dem Ihre installierbaren Komponenten gespeichert sind.
1. Wählen Sie unter **Manifest** die Option **Extract from package (Aus Paket extrahieren)** aus, um ein Manifest zu verwenden, das Sie mit Ihren ZIP-Dateien in den S3-Bucket hochgeladen haben.
(Optional) Wenn Sie kein aktualisiertes JSON-Manifest in den Amazon S3-Bucket mit Ihren ZIP-Dateien hochgeladen haben, wählen Sie **New manifest (Neues Manifest)** aus. Sie können das gesamte Manifest in dem JSON-Editor erstellen oder in ihn hineinkopieren. Weitere Informationen zum Erstellen des JSON-Manifests finden Sie unter [Schritt 2: Erstellen des JSON-Paketmanifests](distributor-working-with-packages-create.md#packages-manifest).
1. Wenn das Manifest fertiggestellt ist, wählen Sie **Add package version (Paketversion hinzufügen)**.
1. Zeigen Sie auf der Seite **Details (Details)** auf der Registerkarte **Versions (Versionen)** die neue Version in der Liste der verfügbaren Paketversionen an. Legen Sie die Standardversion des Pakets fest, indem Sie eine Version auswählen. Wählen Sie anschließend **Set default version (Als Standardversion festlegen)** aus.
Wenn Sie keine Standardversion festlegen, ist die neueste Paketversion die Standardversion.
## Hinzufügen einer Paketversion mit dem AWS CLI
Sie können den verwenden AWS CLI , um eine neue Paketversion hinzuzufügenDistributor. Vor der Ausführung der folgenden Befehle müssen Sie eine neue Paketversion erstellen und diese zu S3 hochladen wie am Anfang dieses Themas beschrieben.
**Um eine Paketversion hinzuzufügen, verwenden Sie AWS CLI**
1. Führen Sie den folgenden Befehl aus, um das AWS Systems Manager Dokument mit einem Eintrag für eine neue Paketversion zu bearbeiten. *document-name*Ersetzen Sie es durch den Namen Ihres Dokuments. *amzn-s3-demo-bucket*Ersetzen Sie es durch die URL des JSON-Manifests, das Sie kopiert haben[Schritt 3: Hochladen von Paket und Manifest zu einem Amazon S3-Bucket](distributor-working-with-packages-create.md#packages-upload-s3). *S3-bucket-URL-of-package*ist die URL des Amazon S3 S3-Buckets, in dem das gesamte Paket gespeichert ist. *version-name-from-updated-manifest*Ersetzen Sie es durch den Wert von `version` im Manifest. Legen Sie den Parameter `--document-version` auf `$LATEST` fest, um das Dokument für diese Paketversion als aktuelle Version des Dokuments festzulegen.
```
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
```
Im Folgenden wird ein -Beispiel gezeigt.
```
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. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob Ihr Paket aktualisiert wurde, und das Paketmanifest anzuzeigen. *package-name*Ersetzen Sie es durch den Namen Ihres Pakets und optional durch die Versionsnummer des Dokuments (nicht identisch *document-version* mit der Paketversion), das Sie aktualisiert haben. Wenn diese Paketversion der aktuellen Version des Dokuments zugeordnet ist, können Sie `$LATEST` als Wert des optionalen Parameters `--document-version` angeben.
```
aws ssm get-document \
--name "package-name" \
--document-version "document-version"
```
Informationen zu anderen Optionen, die Sie mit dem **update-document** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/update-document.html)im AWS Systems Manager Abschnitt der *AWS CLI Befehlsreferenz*.
# Installieren oder Aktualisieren von Distributor-Paketen
Sie können Pakete auf Ihren AWS Systems Manager verwalteten Knoten bereitstellenDistributor, indem Sie ein Tool in verwenden AWS Systems Manager. Um die Pakete bereitzustellen, verwenden Sie entweder AWS-Managementkonsole oder AWS Command Line Interface (AWS CLI). Sie können pro Befehl eine Version eines Pakets bereitstellen. Sie können neue Pakete installieren oder vorhandene Installationen direkt aktualisieren. Sie können wählen, ob Sie eine bestimmte Version oder stets die aktuelle Version eines Pakets bereitstellen möchten. Wir empfehlenState Manager, zur Installation von Paketen ein Tool in AWS Systems Manager zu verwenden. Durch die Verwendung wird State Manager sichergestellt, dass auf Ihren verwalteten Knoten immer die neueste up-to-date Version Ihres Pakets ausgeführt wird.
**Wichtig**
Mit Distributor installierte Pakete sollten nur mithilfe von Distributor deinstalliert werden. Andernfalls kann Systems Manager die Anwendung weiterhin als `INSTALLED` erkennen und es können andere unbeabsichtigte Ergebnisse auftreten.
| Präferenz | AWS Systems Manager Aktion | Weitere Informationen |
| --- | --- | --- |
| Installieren oder aktualisieren Sie ein Paket sofort. | Run Command | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| Installieren Sie ein Paket nach einem Zeitplan, sodass die Installation immer die Standardversion enthält. | State Manager | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/distributor-working-with-packages-deploy.html) |
| Installieren Sie ein Paket automatisch auf neuen verwalteten Knoten, die ein bestimmtes Tag oder einen bestimmten Satz von Tags besitzen. Zum Beispiel die Installation des CloudWatch Amazon-Agenten auf neuen Instances. | State Manager | Eine Möglichkeit besteht in der Anwendung von Tags auf neue verwaltete Knoten und die anschließende Auflistung der Tags als Ziele in der State Manager-Zuordnung. State Manager installiert automatisch das Paket in einer Zuordnung auf verwalteten Knoten, deren Tags übereinstimmen. Siehe [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md). |
**Topics**
+ [Einmaliges Installieren oder Aktualisieren eines Pakets mithilfe der Konsole](#distributor-deploy-pkg-console)
+ [Planen einer Paketinstallation oder -aktualisierung mithilfe der Konsole](#distributor-deploy-sm-pkg-console)
+ [Einmaliges Installieren eines Pakets mit dem AWS CLI](#distributor-deploy-pkg-cli)
+ [Einmaliges Aktualisieren eines Pakets mit dem AWS CLI](#distributor-update-pkg-cli)
+ [Planung einer Paketinstallation mit dem AWS CLI](#distributor-smdeploy-pkg-cli)
+ [Planung einer Paket-Aktualisierung mit dem AWS CLI](#distributor-smupdate-pkg-cli)
## Einmaliges Installieren oder Aktualisieren eines Pakets mithilfe der Konsole
Sie können die AWS Systems Manager Konsole verwenden, um ein Paket einmal zu installieren oder zu aktualisieren. Wenn Sie eine einmalige Installation konfigurieren[AWS Systems Manager Run Command](run-command.md), Distributor verwendet ein Tool in AWS Systems Manager, um die Installation durchzuführen.
**So installieren oder aktualisieren Sie ein Paket einmalig mithilfe der Konsole**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählen Sie auf der Distributor-Startseite das Paket aus, das Sie installieren möchten.
1. Wählen Sie **Install one time (Einmal installieren)** aus.
Dieser Befehl öffnet Run Command mit dem Befehlsdokument `AWS-ConfigureAWSPackage`. Ihr Distributor-Paket ist vorausgewählt.
1. Wählen Sie unter **Document version (Dokumentversion)** die Version des `AWS-ConfigureAWSPackage`-Dokuments aus, das Sie ausführen möchten.
1. Wählen Sie für **Action (Aktion)** die Option **Install (Installieren)**.
1. Wählen Sie unter **Installation type (Installationstyp)** eine der folgenden Optionen aus:
+ **Uninstall and reinstall (Deinstallieren und neu installieren)**: Das Paket wird vollständig deinstalliert und dann neu installiert. Die Anwendung ist bis zum Abschluss der Neuinstallation nicht verfügbar.
+ **In-place update (Direkte Aktualisierung)**: Der vorhandenen Installation werden entsprechend den Anweisungen, die Sie in einem `update`-Skript angeben, nur neue oder geänderte Dateien hinzugefügt. Die Anwendung ist während des Aktualisierungsprozesses weiterhin verfügbar. Diese Option wird für AWS veröffentlichte Pakete außer dem `AWSEC2Launch-Agent` Paket nicht unterstützt.
1. Überprüfen Sie, ob unter **Name** der Name des ausgewählten Pakets angegeben ist.
1. (Optional) Geben Sie unter **Version** den Versionsnamen des Pakets ein. Wenn Sie dieses Feld leer lassen, installiert Run Command die von Ihnen in Distributor ausgewählte Standardversion.
1. Wählen Sie im Abschnitt **Targets** (Ziele) die verwalteten Knoten, auf denen Sie diese Operation ausführen möchten, indem Sie Tags angeben, Instances oder Geräte manuell auswählen oder eine Ressourcengruppe angeben.
**Anmerkung**
Wenn kein verwalteter Knoten in der Liste angezeigt wird, lesen Sie [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md).
1. Für **Weitere Parameter**:
+ Geben Sie im Feld **Kommentar** Informationen zu diesem Befehl ein.
+ Geben Sie für **Timeout (Sekunden)** in Sekunden an, wie lange gewartet werden soll, bis für die gesamte Befehlsausführung ein Fehler auftritt.
1. Für **Rate control** (Temposteuerung):
+ Geben Sie unter **Concurrency** (Nebenläufigkeit) entweder eine Zahl oder einen Prozentsatz von Zielen an, auf denen der Befehl gleichzeitig ausgeführt werden soll.
**Anmerkung**
Wenn Sie Ziele ausgewählt haben, indem Sie Tags oder Ressourcengruppen angeben, und Sie noch nicht sicher sind, wie viele verwaltete Knoten anvisiert sind, sollten Sie die Anzahl von Zielen, die das Dokument gleichzeitig ausführen können, beschränken, indem Sie einen Prozentsatz angeben.
+ Geben Sie unter **Error threshold** (Fehlerschwellenwert) an, wann die Ausführung des Befehls auf anderen Zielen beendet werden soll, nachdem dafür entweder auf einer bestimmten Anzahl oder einem Prozentsatz von verwalteten Knoten ein Fehler aufgetreten ist. Falls Sie beispielsweise drei Fehler angeben, sendet Systems Manager keinen Befehl mehr, wenn der vierte Fehler empfangen wird. Von verwalteten Knoten, auf denen der Befehl noch verarbeitet wird, werden unter Umständen ebenfalls Fehler gesendet.
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben in einen S3-Bucket aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind diejenigen des Instance-Profils (für EC2-Instances) oder der IAM-Servicerolle (hybrid-aktivierte Maschinen), die der Instance zugewiesen sind, und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
1. Aktivieren Sie das Kontrollkästchen **SNS-Benachrichtigungen aktivieren** im Abschnitt **SNS-Benachrichtigungen**, wenn Sie über den Status der Befehlsausführung benachrichtigt werden möchten,
Weitere Informationen zum Konfigurieren von Amazon SNS-Benachrichtigungen für Run Command finden Sie unter [Überwachung von Systems Manager-Statusänderungen mit Amazon SNS-Benachrichtigungen](monitoring-sns-notifications.md).
1. Wenn Sie bereit sind, das Paket zu installieren, klicken Sie auf **Run (Ausführen)**.
1. Im Bereich **Command status (Befehlsstatus)** wird der Fortschritt der Installation angezeigt. Wenn der Befehl noch ausgeführt wird, klicken Sie oben links in der Konsole auf das Aktualisierungssymbol, bis in der Spalte **Overall status (Gesamtstatus)** oder **Detailed status (Detailstatus)** der Status **Success (Erfolgreich)** oder **Failed (Fehlgeschlagen)** angezeigt wird.
1. Klicken Sie im Bereich **Targets and outputs** (Ziele und Ausgaben) auf die Schaltfläche neben dem Namen eines verwalteten Knotens und wählen Sie dann **View output** (Ausgabe anzeigen).
Der Befehlsausgabeseite zeigt die Ergebnisse der Befehlsausführung an.
1. (Optional) Wenn Sie die Befehlsausgabe in einen Amazon S3-Bucket schreiben möchten, wählen Sie **Amazon S3**, um die Ausgabeprotokolldaten anzuzeigen.
## Planen einer Paketinstallation oder -aktualisierung mithilfe der Konsole
Sie können die AWS Systems Manager Konsole verwenden, um die Installation oder Aktualisierung eines Pakets zu planen. Wenn Sie die Paketinstallation oder -aktualisierung planen, verwendet Distributor [AWS Systems Manager State Manager](systems-manager-state.md) zum Installieren oder Aktualisieren.
**So planen Sie eine Paketinstallation mithilfe der Konsole**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählen Sie auf der Distributor-Startseite das Paket aus, das Sie installieren oder aktualisieren möchten.
1. Wählen Sie unter **Package (Paket)** die Option **Install on a schedule (Nach Plan installieren)** aus.
Dieser Befehl öffnet State Manager zu einer neuen Zuordnung, die für Sie erstellt wurde.
1. Geben Sie unter **Name** einen Namen ein (z. B. **Deploy-test-agent-package**). Dies ist zwar optional, wird aber empfohlen. Der Name darf keine Leerzeichen enthalten.
1. In der Liste **Document (Dokument)** ist der Dokumentname `AWS-ConfigureAWSPackage` bereits ausgewählt.
1. Überprüfen Sie unter **Action (Aktion)**, ob **Install (Installieren)** ausgewählt ist.
1. Wählen Sie unter **Installation type (Installationstyp)** eine der folgenden Optionen aus:
+ **Uninstall and reinstall (Deinstallieren und neu installieren)**: Das Paket wird vollständig deinstalliert und dann neu installiert. Die Anwendung ist bis zum Abschluss der Neuinstallation nicht verfügbar.
+ **In-place update (Direkte Aktualisierung)**: Der vorhandenen Installation werden entsprechend den Anweisungen, die Sie in einem `update`-Skript angeben, nur neue oder geänderte Dateien hinzugefügt. Die Anwendung ist während des Aktualisierungsprozesses weiterhin verfügbar.
1. Überprüfen Sie unter **Name**, ob der Name Ihres Pakets angegeben ist.
1. Geben Sie unter **Version** die Versionskennung ein, wenn Sie eine andere Paketversion als die zuletzt veröffentlichte Version installieren möchten.
1. Wählen Sie unter **Targets (Ziele)** die Optionen **Selecting all managed instances in this account (Alle verwalteten Instances in diesem Konto auswählen)**, **Specifying tags (Tags angeben)** oder **Manually Selecting Instance (Instance manuell auswählen)** aus. Wenn Sie die Zielressourcen mithilfe von Tags ausgewählt haben, geben Sie einen Tag-Schlüssel und einen Tag-Wert in die entsprechenden Felder ein.
**Anmerkung**
Sie können verwaltete AWS IoT Greengrass Kerngeräte **auswählen, indem Sie entweder Alle verwalteten Instanzen in diesem Konto** auswählen oder **Instanz manuell auswählen wählen**.
1. Wählen Sie unter **Specify schedule (Plan angeben)** die Option **On Schedule (Nach Plan)** aus, um die Zuordnung nach einem regelmäßigen Zeitplan auszuführen, oder **No Schedule (Kein Plan)**, um die Zuordnung einmalig auszuführen. Weitere Informationen zu diesen Optionen finden Sie unter [Arbeiten mit Zuordnungen in Systems Manager](state-manager-associations.md). Verwenden Sie die Steuerelemente, um einen `cron`- oder Rate-Zeitplan für die Zuordnung zu erstellen.
1. Wählen Sie **Zuordnung erstellen**.
1. Klicken Sie auf der Seite **Association (Zuordnung)** auf die Schaltfläche neben der von Ihnen erstellten Zuordnung und wählen Sie dann **Apply association now (Zuordnung jetzt anwenden)** aus.
State Manager erstellt die Zuordnung und führt sie sofort auf den angegebenen Zielen aus. Weitere Informationen zu den Ergebnissen der Ausführung von Zuordnungen finden Sie unter [Arbeiten mit Zuordnungen in Systems Manager](state-manager-associations.md) in diesem Handbuch.
Weitere Informationen zur Verwendung der Optionen unter **Advanced Options (Erweiterte Optionen)**, **Rate control (Ratensteuerung)** und **Output options (Ausgabeoptionen)** finden Sie unter [Arbeiten mit Zuordnungen in Systems Manager](state-manager-associations.md).
## Einmaliges Installieren eines Pakets mit dem AWS CLI
Sie können **send-command** den ausführen AWS CLI , um ein Distributor Paket einmal zu installieren. Wenn das Paket bereits installiert ist, wird die Anwendung offline geschaltet, während das Paket deinstalliert und stattdessen die neue Version installiert wird.
**Um ein Paket einmal zu installieren, verwenden Sie AWS CLI**
+ Führen Sie in der AWS CLI den folgenden aus.
```
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)"]}'
```
**Anmerkung**
Das Standardverhalten für `installationType` ist `Uninstall and reinstall`. Sie können `"installationType":["Uninstall and reinstall"]` im Befehl weglassen, wenn Sie ein komplettes Paket installieren.
Im Folgenden wird ein -Beispiel gezeigt.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-00000000000000" \
--parameters '{"action":["Install"],"installationType":["Uninstall and reinstall"],"name":["ExamplePackage"]}'
```
Informationen zu anderen Optionen, die Sie mit dem **send-command** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)im AWS Systems Manager Abschnitt der *AWS CLI Befehlsreferenz*.
## Einmaliges Aktualisieren eines Pakets mit dem AWS CLI
Sie können das Programm ausführen **send-command** AWS CLI , um ein Distributor Paket zu aktualisieren, ohne die zugehörige Anwendung offline zu schalten. Nur neue oder aktualisierte Dateien im Paket werden ersetzt.
**Um ein Paket einmal zu aktualisieren, verwenden Sie AWS CLI**
+ Führen Sie in der AWS CLI den folgenden aus.
```
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)"]}'
```
**Anmerkung**
Wenn Sie neue oder geänderte Dateien hinzufügen, müssen Sie `"installationType":["In-place update"]` in den Befehl einschließen.
Im Folgenden wird ein -Beispiel gezeigt.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Install"],"installationType":["In-place update"],"name":["ExamplePackage"]}'
```
Informationen zu anderen Optionen, die Sie mit dem **send-command** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)im AWS Systems Manager Abschnitt der *AWS CLI Befehlsreferenz*.
## Planung einer Paketinstallation mit dem AWS CLI
Sie können **create-association** den ausführen AWS CLI , um ein Distributor Paket nach einem Zeitplan zu installieren. Der Wert für `--name`, d. h. der Name des Dokuments, ist stets `AWS-ConfigureAWSPackage`. Der folgende Befehl verwendet den Schlüssel `InstanceIds` zur Angabe von verwalteten Knoten als Ziel. Wenn das Paket bereits installiert ist, wird die Anwendung offline geschaltet, während das Paket deinstalliert und stattdessen die neue Version installiert wird.
```
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\"]}]
```
**Anmerkung**
Das Standardverhalten für `installationType` ist `Uninstall and reinstall`. Sie können `"installationType":["Uninstall and reinstall"]` im Befehl weglassen, wenn Sie ein komplettes Paket installieren.
Im Folgenden wird ein -Beispiel gezeigt.
```
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\"]}]
```
Informationen zu anderen Optionen, die Sie mit dem **create-association** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html)im AWS Systems Manager Abschnitt der *AWS CLI Befehlsreferenz*.
## Planung einer Paket-Aktualisierung mit dem AWS CLI
Sie können den ausführen **create-association** AWS CLI , um ein Distributor Paket nach einem Zeitplan zu aktualisieren, ohne die zugehörige Anwendung offline zu nehmen. Nur neue oder aktualisierte Dateien im Paket werden ersetzt. Der Wert für `--name`, d. h. der Name des Dokuments, ist stets `AWS-ConfigureAWSPackage`. Der folgende Befehl verwendet den Schlüssel `InstanceIds` zur Angabe von Ziel-Instances.
```
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\"]}]
```
**Anmerkung**
Wenn Sie neue oder geänderte Dateien hinzufügen, müssen Sie `"installationType":["In-place update"]` in den Befehl einschließen.
Im Folgenden wird ein -Beispiel gezeigt.
```
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\"]}]
```
Informationen zu anderen Optionen, die Sie mit dem **create-association** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html)im AWS Systems Manager Abschnitt der *AWS CLI Befehlsreferenz*.
# Deinstallieren eines Distributor-Pakets
Sie können das AWS-Managementkonsole oder das AWS Command Line Interface (AWS CLI) verwenden, um Distributor Pakete von Ihren AWS Systems Manager verwalteten Knoten zu deinstallieren, indem SieRun Command. Distributorund Run Command sind Tools in AWS Systems Manager. In dieser Version können Sie pro Befehl eine Version eines Pakets deinstallieren. Sie können eine bestimmte Version oder die Standardversion deinstallieren.
**Wichtig**
Mit Distributor installierte Pakete sollten nur mithilfe von Distributor deinstalliert werden. Andernfalls kann Systems Manager die Anwendung weiterhin als `INSTALLED` erkennen und es können andere unbeabsichtigte Ergebnisse auftreten.
**Topics**
+ [Deinstallation eines Pakets über die Konsole](#distributor-pkg-uninstall-console)
+ [Deinstallation eines Pakets mit dem AWS CLI](#distributor-pkg-uninstall-cli)
## Deinstallation eines Pakets über die Konsole
Sie können Run Command in der Systems Manager-Konsole verwenden, um ein Paket einmalig zu deinstallieren. Distributor verwendet [AWS Systems Manager Run Command](run-command.md) zur Deinstallation von Paketen.
**Um ein Paket mit der Konsole zu deinstallieren**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie auf der Run Command-Startseite **Run command (Befehl ausführen)** aus.
1. Wählen Sie das Befehlsdokument `AWS-ConfigureAWSPackage` aus.
1. Wählen Sie in **Action (Aktion)** die Option **Uninstall (Deinstallieren)** aus.
1. Geben Sie in **Name (Name)** den Namen des Pakets ein, das Sie deinstallieren möchten.
1. Für **Targets** (Ziele) wählen Sie aus, wie Sie Ihre verwaltete Knoten anvisieren möchten. Sie können einen Tag-Schlüssel und Werte angeben, die von den Zielen geteilt werden. Sie können Ziele auch angeben, indem Sie Attribute wie ID, Plattform und SSM Agent-Version auswählen.
1. Sie können in den erweiterten Optionen Kommentare zur Operation hinzufügen, die Werte für **Concurrency (Gleichzeitigkeit)** und **Error threshold (Fehlerschwellenwert)** in **Rate control (Ratenkontrolle)** ändern, Ausgabeoptionen angeben oder Amazon Simple Notification Service (Amazon SNS)-Benachrichtigungen konfigurieren. Weitere Informationen finden Sie unter [Ausführen von Befehlen über die Konsole](https://docs.aws.amazon.com/systems-manager/latest/userguide/rc-console.html) in diesem Handbuch.
1. Wenn Sie zur Deinstallation des Pakets bereit sind, wählen Sie **Run (Ausführen)** und dann **View results (Ergebnisse anzeigen)** aus.
1. Wählen Sie in der Befehlsliste den `AWS-ConfigureAWSPackage` aus, den Sie ausgeführt haben. Wenn der Befehl noch in Bearbeitung ist, wählen Sie das Aktualisierungssymbol oben rechts in der Konsole aus.
1. Wenn die Spalte **Status** **Success** (Erfolg) oder **Failed** (Fehlgeschlagen) anzeigt, wählen Sie die Registerkarte **Output** (Ausgabe).
1. Wählen Sie **View output (Ausgabe anzeigen)** aus. Der Befehlsausgabeseite zeigt die Ergebnisse der Befehlsausführung an.
## Deinstallation eines Pakets mit dem AWS CLI
Sie können das verwenden AWS CLI , um ein Distributor Paket von verwalteten Knoten zu deinstallieren, indem SieRun Command.
**Um ein Paket mit dem zu deinstallieren AWS CLI**
+ Führen Sie in der AWS CLI den folgenden aus.
```
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)"]}'
```
Im Folgenden wird ein -Beispiel gezeigt.
```
aws ssm send-command \
--document-name "AWS-ConfigureAWSPackage" \
--instance-ids "i-02573cafcfEXAMPLE" \
--parameters '{"action":["Uninstall"],"name":["Test-ConfigureAWSPackage"]}'
```
Informationen zu anderen Optionen, die Sie mit dem **send-command** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)im AWS Systems Manager Abschnitt der *AWS CLI Befehlsreferenz*.
# Löschen eines Distributor-Pakets
In diesem Abschnitt wird beschrieben, wie Sie ein Paket löschen. Sie können eine Version eines Pakets nicht löschen, sondern nur das gesamte Paket.
## Löschen eines Pakets über die Konsole
Sie können die AWS Systems Manager Konsole verwenden, um ein Paket oder eine Paketversion aus Distributor einem Tool in zu löschen AWS Systems Manager. Durch das Löschen eines Pakets werden alle Versionen des Pakets aus Distributor gelöscht.
**So löschen Sie ein Paket mithilfe der Konsole**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählen Sie auf der **Distributor**-Startseite das Paket aus, das Sie löschen möchten.
1. Wählen Sie auf der Detailseite des Pakets **Delete package (Paket löschen)** aus.
1. Wenn Sie zum Bestätigen des Löschvorgangs aufgefordert werden, wählen Sie **Delete package (Paket löschen)** aus.
## Löschen einer Paketversion über die Konsole
Sie können die Systems Manager-Konsole verwenden, um eine Paketversion aus Distributor zu löschen.
**Löschen einer Paketversion über die Konsole**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Distributor** aus.
1. Wählen Sie auf der **Distributor**-Startseite das Paket aus, von dem Sie eine Version löschen möchten.
1. Wählen Sie auf der Versionsseite für das Paket die zu löschende Version und anschließend die Option **Delete version (Version löschen)** aus.
1. Wenn Sie zum Bestätigen des Löschvorgangs aufgefordert werden, wählen Sie **Delete package version (Paketversion löschen)** aus.
## Ein Paket mithilfe einer Befehlszeile löschen
Sie können Ihr bevorzugtes Befehlszeilen-Tool verwenden, um ein Paket aus Distributor zu löschen.
------
#### [ Linux & macOS ]
**Um ein Paket mit dem zu löschen AWS CLI**
1. Führen Sie den folgenden Befehl aus, um Dokumente für spezifische Pakete aufzulisten. Suchen Sie in den Ergebnissen dieses Befehls das Paket, das Sie löschen möchten.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
1. Führen Sie den folgenden Befehl aus, um ein Paket zu löschen. *package-name*Ersetzen Sie es durch den Paketnamen.
```
aws ssm delete-document \
--name "package-name"
```
1. Führen Sie den Befehl **list-documents** erneut aus, um zu überprüfen, ob das Paket gelöscht wurde. Das Paket, das Sie gelöscht haben, sollte nicht in die Liste aufgenommen werden.
```
aws ssm list-documents \
--filters Key=Name,Values=package-name
```
------
#### [ Windows ]
**Um ein Paket mit dem zu löschen AWS CLI**
1. Führen Sie den folgenden Befehl aus, um Dokumente für spezifische Pakete aufzulisten. Suchen Sie in den Ergebnissen dieses Befehls das Paket, das Sie löschen möchten.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
1. Führen Sie den folgenden Befehl aus, um ein Paket zu löschen. *package-name*Ersetzen Sie es durch den Paketnamen.
```
aws ssm delete-document ^
--name "package-name"
```
1. Führen Sie den Befehl **list-documents** erneut aus, um zu überprüfen, ob das Paket gelöscht wurde. Das Paket, das Sie gelöscht haben, sollte nicht in die Liste aufgenommen werden.
```
aws ssm list-documents ^
--filters Key=Name,Values=package-name
```
------
#### [ PowerShell ]
**Um ein Paket mit Tools für zu löschen PowerShell**
1. Führen Sie den folgenden Befehl aus, um Dokumente für spezifische Pakete aufzulisten. Suchen Sie in den Ergebnissen dieses Befehls das Paket, das Sie löschen möchten.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
1. Führen Sie den folgenden Befehl aus, um ein Paket zu löschen. *package-name*Ersetzen Sie es durch den Paketnamen.
```
Remove-SSMDocument `
-Name "package-name"
```
1. Führen Sie den Befehl **Get-SSMDocumentList** erneut aus, um zu überprüfen, ob das Paket gelöscht wurde. Das Paket, das Sie gelöscht haben, sollte nicht in die Liste aufgenommen werden.
```
$filter = New-Object Amazon.SimpleSystemsManagement.Model.DocumentKeyValuesFilter
$filter.Key = "Name"
$filter.Values = "package-name"
Get-SSMDocumentList `
-Filters @($filter)
```
------
## Eine Paketversion mithilfe einer Befehlszeile löschen
Sie können Ihr bevorzugtes Befehlszeilen-Tool verwenden, um eine Paketversion aus Distributor zu löschen.
------
#### [ Linux & macOS ]
**Um eine Paketversion mit dem zu löschen AWS CLI**
1. Führen Sie den folgenden Befehl aus, um die Versionen Ihres Pakets aufzulisten. Suchen Sie in den Ergebnissen dieses Befehls die Paketversion, die Sie löschen möchten.
```
aws ssm list-document-versions \
--name "package-name"
```
1. Führen Sie den folgenden Befehl aus, um eine Paketversion zu löschen. *package-name*Ersetzen Sie durch den Paketnamen und *version* die Versionsnummer.
```
aws ssm delete-document \
--name "package-name" \
--document-version version
```
1. Führen Sie den Befehl **list-document-versions** aus, um zu überprüfen, ob die Version des Pakets gelöscht wurde. Die von Ihnen gelöschte Paketversion sollte nicht gefunden werden.
```
aws ssm list-document-versions \
--name "package-name"
```
------
#### [ Windows ]
**Um eine Paketversion mit dem zu löschen AWS CLI**
1. Führen Sie den folgenden Befehl aus, um die Versionen Ihres Pakets aufzulisten. Suchen Sie in den Ergebnissen dieses Befehls die Paketversion, die Sie löschen möchten.
```
aws ssm list-document-versions ^
--name "package-name"
```
1. Führen Sie den folgenden Befehl aus, um eine Paketversion zu löschen. *package-name*Ersetzen Sie durch den Paketnamen und *version* die Versionsnummer.
```
aws ssm delete-document ^
--name "package-name" ^
--document-version version
```
1. Führen Sie den Befehl **list-document-versions** aus, um zu überprüfen, ob die Version des Pakets gelöscht wurde. Die von Ihnen gelöschte Paketversion sollte nicht gefunden werden.
```
aws ssm list-document-versions ^
--name "package-name"
```
------
#### [ PowerShell ]
**Um eine Paketversion mit Tools für zu löschen PowerShell**
1. Führen Sie den folgenden Befehl aus, um die Versionen Ihres Pakets aufzulisten. Suchen Sie in den Ergebnissen dieses Befehls die Paketversion, die Sie löschen möchten.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
1. Führen Sie den folgenden Befehl aus, um eine Paketversion zu löschen. *package-name*Ersetzen Sie es durch den Paketnamen und *version* die Versionsnummer.
```
Remove-SSMDocument `
-Name "package-name" `
-DocumentVersion version
```
1. Führen Sie den Befehl **Get-SSMDocumentVersionList** aus, um zu überprüfen, ob die Version des Pakets gelöscht wurde. Die von Ihnen gelöschte Paketversion sollte nicht gefunden werden.
```
Get-SSMDocumentVersionList `
-Name "package-name"
```
------
Informationen zu anderen Optionen, die Sie mit dem **list-documents** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html)im AWS Systems Manager Abschnitt der *AWS CLI Befehlsreferenz*. Informationen zu anderen Optionen, die Sie mit dem Befehl **delete-document** verwenden können, finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/delete-document.html).
# Prüfen und Protokollieren von Distributor-Aktivitäten
Sie können verwenden AWS CloudTrail , um Aktivitäten im Zusammenhang mitDistributor, einem Tool in zu überprüfen AWS Systems Manager. Weitere Informationen zu den Prüfungs- und Protokollierungsoptionen für Systems Manager finden Sie unter [Einloggen und Überwachen AWS Systems Manager](monitoring.md).
## Prüfen Sie Distributor die Aktivität mithilfe von CloudTrail
CloudTrail erfasst API-Aufrufe, die in der AWS Systems Manager Konsole, dem AWS Command Line Interface (AWS CLI) und dem Systems Manager SDK getätigt wurden. Die Informationen können in der CloudTrail Konsole angezeigt oder in einem Amazon Simple Storage Service (Amazon S3) -Bucket gespeichert werden. Ein Bucket wird für alle CloudTrail Protokolle Ihres Kontos verwendet.
Protokolle von Run Command- und State Manager-Aktionen zeigen Aktivitäten im Zusammenhang mit Dokumenterstellung, Paketinstallation und Paketdeinstallation an. Run Command und State Manager sind Tools in AWS Systems Manager. Weitere Informationen zum Anzeigen und Verwenden von CloudTrail Protokollen der Systems Manager Manager-Aktivitäten finden Sie unter[AWS Systems Manager API-Aufrufe protokollieren mit AWS CloudTrail](monitoring-cloudtrail-logs.md).
# Problembehebung AWS Systems ManagerDistributor
Die folgenden Informationen können Ihnen helfen, Fehler zu beheben, die bei der Verwendung von Distributor, einem Tool in AWS Systems Manager, möglicherweise auftreten.
**Topics**
+ [Falsches Paket mit identischem Namen installiert](#distributor-tshoot-1)
+ [Fehler: Abruf des Manifests fehlgeschlagen: Aktuelle Version des Pakets wurde nicht gefunden](#distributor-tshoot-2)
+ [Fehler: Fehler beim Abrufen des Manifests: Validierungsausnahme](#distributor-tshoot-3)
+ [Paket wird nicht unterstützt (dem Paket fehlt Installationsaktion)](#distributor-tshoot-4)
+ [Fehler: Manifest konnte nicht heruntergeladen werden: Dokument mit dem Namen ist nicht vorhanden](#distributor-tshoot-5)
+ [Hochladen fehlgeschlagen.](#distributor-tshoot-6)
+ [Fehler: Failed to find platform: no manifest found for platform: oracle, version 8.9, architecture x86\$164](#distributor-tshoot-7)
## Falsches Paket mit identischem Namen installiert
**Problem:** Sie haben ein Paket installiert, Distributor hat stattdessen ein anderes Paket installiert.
**Ursache:** Während der Installation findet Systems Manager von AWS veröffentlichte Pakete als Ergebnisse, bevor benutzerdefinierte externe Pakete gefunden werden. Wenn Ihr benutzerdefinierter Paketname mit dem Namen eines AWS veröffentlichten Pakets identisch ist, wird das AWS Paket anstelle Ihres Pakets installiert.
**Lösung:** Um dieses Problem zu vermeiden, geben Sie Ihrem Paket einen anderen Namen als den Namen eines AWS veröffentlichten Pakets.
## Fehler: Abruf des Manifests fehlgeschlagen: Aktuelle Version des Pakets wurde nicht gefunden
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
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
```
**Ursache:** Sie verwenden eine SSM Agent-Version mit einer früheren Distributor-Version als Version 2.3.274.0.
**Lösung:** Aktualisieren Sie die SSM Agent-Version auf Version 2.3.274.0 oder höher. Für weitere Informationen siehe [Aktualisierung von SSM Agent mithilfe von Run Command](run-command-tutorial-update-software.md#rc-console-agentexample) oder [Exemplarische Vorgehensweise: Automatisches Update SSM Agent mit dem AWS CLI](state-manager-update-ssm-agent-cli.md).
## Fehler: Fehler beim Abrufen des Manifests: Validierungsausnahme
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
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
```
**Ursache:** Sie verwenden eine SSM Agent-Version mit einer früheren Distributor-Version als Version 2.3.274.0.
**Lösung:** Aktualisieren Sie die SSM Agent-Version auf Version 2.3.274.0 oder höher. Für weitere Informationen siehe [Aktualisierung von SSM Agent mithilfe von Run Command](run-command-tutorial-update-software.md#rc-console-agentexample) oder [Exemplarische Vorgehensweise: Automatisches Update SSM Agent mit dem AWS CLI](state-manager-update-ssm-agent-cli.md).
## Paket wird nicht unterstützt (dem Paket fehlt Installationsaktion)
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
Package is not supported (package is missing install action)
```
**Ursache:** Die Paketverzeichnisstruktur ist falsch.
**Lösung:** Zipen Sie kein übergeordnetes Verzeichnis, das die Software und die erforderlichen Skripte enthält. Erstellen Sie stattdessen eine `.zip`-Datei aller erforderlichen Inhalte direkt im absoluten Pfad. Um zu überprüfen, ob die`.zip`-Datei korrekt erstellt wurde, entpacken Sie das Zielplattformverzeichnis und überprüfen Sie die Verzeichnisstruktur. Der absolute Pfad für das Installationsskript sollte beispielsweise `/ExamplePackage_targetPlatform/install.sh` sein.
## Fehler: Manifest konnte nicht heruntergeladen werden: Dokument mit dem Namen ist nicht vorhanden
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
Failed to download manifest - failed to retrieve package document description: InvalidDocument: Document with name filename does not exist.
```
**Ursache 1:** Distributor kann das Paket nicht anhand des Paketnamens finden, wenn ein Distributor-Paket von einem anderen Konto geteilt wird.
**Lösung 1:** Wenn Sie ein Paket von einem anderen Konto freigeben, verwenden Sie den vollständigen Amazon-Ressourcennamen (ARN) für das Paket und nicht nur den Namen.
**Ursache 2:** Wenn Sie eine VPC verwenden, haben Sie Ihrem IAM-Instanzprofil keinen Zugriff auf den AWS verwalteten S3-Bucket gewährt, der das Dokument `AWS-ConfigureAWSPackage` für das enthält, auf das AWS-Region Sie abzielen.
**Lösung 2:** Stellen Sie sicher, dass Ihr IAM-Instanzprofil Zugriff auf den AWS verwalteten S3-Bucket bietetSSM Agent, der das Dokument `AWS-ConfigureAWSPackage` für das, auf das AWS-Region Sie abzielen, enthält, wie unter erklärt. [SSM AgentKommunikation mit AWS verwalteten S3-Buckets](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions)
## Hochladen fehlgeschlagen.
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
Upload failed. At least one of your files was not successfully uploaded to your S3 bucket.
```
**Ursache:** Der Name Ihres Softwarepakets enthält ein Leerzeichen. Zum Beispiel würde bei `Hello World.msi` der Upload fehlschlagen.
## Fehler: Failed to find platform: no manifest found for platform: oracle, version 8.9, architecture x86\$164
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
Failed to find platform: no manifest found for platform: oracle, version 8.9, architecture x86_64
```
**Ursache:** Der Fehler bedeutet, dass das JSON-Paketmanifest keine Definition für diese Plattform hat, in diesem Fall Oracle Linux.
**Lösung:** Laden Sie das Paket, das Sie verteilen möchten, von der [Trend Micro Deep Security Software](https://help.deepsecurity.trendmicro.com/software.html)-Website herunter. Erstellen Sie ein `.rpm`-Softwarepaket mit dem [Erstellen Sie ein Paket mithilfe des einfachen Workflows](distributor-working-with-packages-create.md#distributor-working-with-packages-create-simple). Legen Sie die folgenden Werte für das Paket fest und schließen Sie das Upload-Softwarepaket mithilfe von Distributor ab:
```
Platform version: _any
Target platform: oracle
Architecture: x86_64
```
# AWS Systems Manager Fleet Manager
Fleet Manager, ein Tool in AWS Systems Manager, ist eine einheitliche Benutzeroberfläche (UI), mit der Sie Ihre auf AWS oder On-Premises ausgeführten Knoten remote verwalten können. Mit Fleet Manager können Sie sich den Zustand und den Leistungsstatus Ihrer gesamten Serverflotte von einer Konsole aus ansehen. Sie können auch Daten aus einzelnen Knoten sammeln, um allgemeine Problembehandlungs- und Verwaltungsaufgaben über die Konsole auszuführen. Dies umfasst die Verbindung mit Windows-Instances über das Remote Desktop Protocol (RDP), das Anzeigen von Ordner- und Dateiinhalten, die Verwaltung der Windows-Registry, die Benutzerverwaltung des Betriebssystems und vieles mehr.
Um mit Fleet Manager zu beginnen, öffnen Sie die [Systems-Manager-Konsole](https://console.aws.amazon.com/systems-manager/fleet-manager). Wählen Sie im Navigationsbereich **Fleet Manager** aus.
## An wen richtet sich Fleet Manager?
Alle AWS-Kunden, die eine zentralisierte Methode zur Verwaltung ihrer Knotenflotte möchten, sollten Fleet Manager verwenden.
## Welche Vorteile bietet Fleet Manager meiner Organisation?
Fleet Manager bietet die folgenden Vorteile:
+ Ausführen einer Vielzahl gängiger Systemverwaltungs-Aufgaben, ohne eine manuelle Verbindung zu Ihren verwalteten Knoten herstellen zu müssen.
+ Verwalten von Knoten, die auf mehreren Plattformen ausgeführt werden, über eine einzige einheitliche Konsole.
+ Verwalten von Knoten, auf denen verschiedene Betriebssysteme ausgeführt werden, über eine einzige einheitliche Konsole.
+ Verbessern Sie die Effizienz Ihrer Systemadministration.
## Über welche Features verfügt Fleet Manager?
Nachstehend sind einige der wichtigsten Features von Fleet Manager aufgelistet:
+ **Zugreifen auf das Red-Hat-Knowledgebase-Portal**
Greifen Sie über Ihre Red Hat Enterprise Linux (RHEL)-Instances auf Binärdateien, Wissensfreigaben und Diskussionsforen im Knowledgebase-Portal von Red Hat zu.
+ **Status des verwalteten Knotens**
Anzeigen, welche verwalteten Knoten `running` sind und welche `stopped` sind. Weitere Informationen zu gestoppten Instances finden Sie unter [Anhalten und Starten Ihrer Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html) im *Amazon-EC2-Benutzerhandbuch*. Für AWS IoT Greengrass-Core-Geräte können Sie sehen, welche `online` oder `offline` sind, bzw. den Status `Connection lost` anzeigen.
**Anmerkung**
Wenn Sie Ihre verwaltete Instance vor dem 12. Juli 2021 angehalten haben, wird die `stopped`-Markierung nicht angezeigt. Um die Markierung anzuzeigen, starten und beenden Sie die Instance.
+ **Anzeigen von Instance-Informationen**
Zeigen Sie Informationen zu den Ordner- und Dateidaten an, die auf den an Ihre verwalteten Instances angeschlossenen Volumes gespeichert sind, sowie Leistungsdaten zu Ihren Instances in Echtzeit und auf Ihren Instances gespeicherte Protokolldaten.
+ **Informationen über Edge-Gerät anzeigen**
Aufrufen des AWS IoT Greengrass-Objektnamens für das Gerät, SSM Agent-Ping-Status und der Version und mehr.
+ **Verwalten von Konten und Registrierung**
Verwalten von Betriebssystem-Benutzerkonten auf Ihren Instances und Registrieren auf Ihren Windows-Instances.
+ **Steuern des Zugriffs auf Features**
Steuern des Zugriffs auf Fleet Manager-Features mit AWS Identity and Access Management (IAM)-Richtlinien. Mit diesen Richtlinien können Sie steuern, welche Benutzer oder Gruppen in Ihrer Organisation verschiedene Fleet Manager-Features verwenden können und welche verwalteten Knoten sie verwalten können.
**Topics**
+ [An wen richtet sich Fleet Manager?](#fleet-who)
+ [Welche Vorteile bietet Fleet Manager meiner Organisation?](#fleet-benefits)
+ [Über welche Features verfügt Fleet Manager?](#fleet-features)
+ [Einrichten von Fleet Manager](setting-up-fleet-manager.md)
+ [Arbeiten mit verwalteten Knoten](fleet-manager-managed-nodes.md)
+ [Automatisches Verwalten von EC2-Instances mit der Standard-Host-Management-Konfiguration](fleet-manager-default-host-management-configuration.md)
+ [Eine Verbindung zu einer von Windows Server verwalteten Instance mit Remote Desktop herstellen](fleet-manager-remote-desktop-connections.md)
+ [Verwaltung von Amazon-EBS-Volumes auf verwalteten Instances](fleet-manager-manage-amazon-ebs-volumes.md)
+ [Zugriff auf das Wissensdatenbank-Portal von Red Hat](fleet-manager-red-hat-knowledge-base-access.md)
+ [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md)
# Einrichten von Fleet Manager
Bevor Benutzer in Ihrem AWS-Konto Fleet Manager verwenden können, ein Tool in AWS Systems Manager, um Ihre verwalteten Knoten zu überwachen und zu verwalten, müssen ihnen die erforderlichen Berechtigungen erteilt werden. Darüber hinaus müssen alle Amazon Elastic Compute Cloud (Amazon EC2)-Instances, AWS IoT Greengrass-Core-Geräte und On-Premises-Server, Edge-Geräte und virtuelle Maschinen (VMs), die mithilfe von Fleet Manager, überwacht und verwaltet werden können, *verwaltete Knoten* von Systems Manager sein. Ein verwalteter Knoten ist jede Maschine, die für die Verwendung mit Systems Manager in [Hybrid- und Multi-Cloud](operating-systems-and-machine-types.md#supported-machine-types)-Umgebungen konfiguriert ist.
Dies bedeutet, dass Ihre Knoten bestimmte Voraussetzungen erfüllen und mit dem AWS Systems Manager-Agent (SSM Agent) konfiguriert sein müssen.
Je nach Maschinentyp sollten Sie sich mit einem der folgenden Themen befassen, um sicherzustellen, dass Ihre Computer die Anforderungen für verwaltete Knoten erfüllen.
+ Amazon-EC2-Instances: [Verwalten von EC2-Instances mit Systems Manager](systems-manager-setting-up-ec2.md)
**Tipp**
Sie können auch Quick Setup, ein Tool in AWS Systems Manager, verwenden, um Ihre Amazon-EC2-Instances schnell als verwaltete Instances in einem einzelnen Konto konfigurieren zu können. Wenn Ihr Unternehmen oder Ihre Organisation AWS Organizations verwendet, können Sie auch Instances über mehrere Organisationseinheiten (OUs) und AWS-Regionen hinweg konfigurieren. Weitere Informationen zur Verwendung von Quick Setup zum Konfigurieren verwalteter Instance finden Sie unter [Amazon-EC2-Host-Verwaltung mit Quick Setup einrichten](quick-setup-host-management.md).
+ On-Premises und andere Servertypen in der Cloud: [Verwalten von Knoten in Hybrid- und Multi-Cloud-Umgebungen mit Systems Manager](systems-manager-hybrid-multicloud.md)
+ AWS IoT Greengrass-(Edge)-Geräte: [Verwalten von Edge-Geräten mit Systems Manager](systems-manager-setting-up-edge-devices.md)
**Topics**
+ [Steuern des Zugriffs auf Fleet Manager](configuring-fleet-manager-permissions.md)
# Steuern des Zugriffs auf Fleet Manager
Um ein Tool in verwenden zu können Fleet Manager AWS Systems Manager, muss Ihr AWS Identity and Access Management (IAM-) Benutzer oder Ihre Rolle über die erforderlichen Berechtigungen verfügen. Sie können eine IAM-Richtlinie erstellen, die Zugriff auf alle Fleet Manager-Features bieten, oder ändern Sie Ihre Richtlinie, um Zugriff auf die ausgewählten Features zu gewähren. Anschließend gewähren Sie diese Berechtigungen Benutzern oder Identitäten in Ihrem Konto.
**Aufgabe 1: Erstellen von IAM-Richtlinien zur Definition von Zugriffsberechtigungen**
Folgen Sie einer der Methoden, die im folgenden Thema des *IAM-Benutzerhandbuchs beschrieben werden, um ein IAM* zu erstellen, das Identitäten (Benutzern, Rollen oder Benutzergruppen) Zugriff gewährt auf: Fleet Manager
+ [Benutzerdefinierte IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien definieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)
Sie können eine der unten aufgeführten Beispielrichtlinien verwenden oder sie entsprechend den Berechtigungen ändern, die Sie gewähren möchten. Wir bieten Beispielrichtlinien für vollständigen Fleet Manager-Zugriff und schreibgeschützten Zugriff.
**Aufgabe 2: Ordnen Sie den Benutzern die IAM-Richtlinien zu, um ihnen Berechtigungen zu gewähren**
Nachdem Sie die IAM-Richtlinie(n) erstellt haben, die Zugriffsberechtigungen für Fleet Manager definieren, verwenden Sie eines der folgenden Verfahren im *IAM-Benutzerhandbuch*, um diese Berechtigungen für Identitäten in Ihrem Konto zu gewähren:
+ [Hinzufügen von IAM-Identitätsberechtigungen (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)
+ [Hinzufügen von IAM-Identitätsberechtigungen (AWS CLI)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-cli)
+ [Hinzufügen von IAM-Identitätsberechtigungen (AWS -API)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policy-api)
**Topics**
+ [Beispielrichtlinie für Fleet Manager-Administratorzugriff](#admin-policy-sample)
+ [Beispielrichtlinie für schreibgeschützten Fleet Manager-Zugriff](#read-only-policy-sample)
## Beispielrichtlinie für Fleet Manager-Administratorzugriff
Die folgende Richtlinie gewährt Berechtigungen für alle Fleet Manager-Features. Dies bedeutet, dass ein Benutzer lokale Benutzer und Gruppen erstellen und löschen, die Gruppenmitgliedschaft für jede lokale Gruppe ändern und Windows Server-Registrierungsschlüssel oder -werte ändern kann. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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}"
]
}
}
}
]
}
```
------
## Beispielrichtlinie für schreibgeschützten Fleet Manager-Zugriff
Die folgende Richtlinie gewährt Berechtigungen für alle schreibgeschützten Fleet Manager–Features. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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}"
]
}
}
}
]
}
```
------
# Arbeiten mit verwalteten Knoten
Ein *verwalteter Knoten* ist ein beliebiger Computer, für den er konfiguriert ist. AWS Systems Manager Sie können die folgenden Maschinentypen als verwaltete Knoten konfigurieren:
+ Amazon Elastic Compute Cloud (Amazon EC2) -Instanzen
+ Server in Ihren eigenen Räumlichkeiten (On-Premises-Server)
+ AWS IoT Greengrass Kerngeräte
+ AWS IoT und Geräte, die nicht zu den AWS Edge-Geräten gehören
+ Virtuelle Maschinen (VMs), auch VMs in anderen Cloud-Umgebungen
Jede Maschine mit dem Präfix „mi-“ in der Systems-Manager-Konsole wurde mit einer [*Hybrid-Aktivierung*](activations.md) als verwalteter Knoten konfiguriert. Edge-Geräte zeigen ihren AWS IoT Ding-Namen an.
**Anmerkung**
Die einzige unterstützte Funktion für macOS-Instances ist die Anzeige des Dateisystems.
**Üner Systems Manager Instances-Kontingente**
AWS Systems Manager bietet eine Stufe „Standard-Instances“ und eine Stufe „Advanced-Instances“. Beide unterstützen verwaltete Knoten in Ihrer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types). Die Stufe „Standard-Instances“ ermöglicht es Ihnen, maximal 1.000 Maschinen pro Person zu registrieren. AWS-Konto AWS-Region Wenn Sie mehr als 1 000 Maschinen in einem einzigen Konto und einer Region anmelden müssen, verwenden Sie das Advanced-Instances-Kontingent. Sie können im Advanced-Instances-Kontingent so viele verwaltete Knoten erstellen, wie Sie möchten. Alle verwalteten Knoten, die für Systems Manager konfiguriert sind, werden auf pay-per-use Basis von Preisen berechnet. Weitere Informationen über das Aktivieren des Advanced-Instances-Kontingent finden Sie unter [Aktivieren des Kontingents für erweiterte Instances](fleet-manager-enable-advanced-instances-tier.md). Weitere Informationen über die Preise finden Sie unter [AWS Systems Manager – Preise](https://aws.amazon.com/systems-manager/pricing/).
Beachten Sie die folgenden zusätzlichen Informationen zur Ebene für Standard-Instances und zur Ebene für erweiterte Instances:
+ Mithilfe von Advanced Instances können Sie in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) auch eine Verbindung zu Ihren EC2 Nicht-Nodes AWS Systems Manager Session Manager herstellen. Session Managerbietet interaktiven Shell-Zugriff auf Ihre Instanzen. Weitere Informationen finden Sie unter [AWS Systems Manager Session Manager](session-manager.md).
+ Das Kontingent für Standardinstanzen gilt auch für EC2 Instanzen, die eine lokale Systems Manager Manager-Aktivierung verwenden (was kein übliches Szenario ist).
+ Um von Microsoft veröffentlichte Anwendungen auf lokalen Instanzen virtueller Maschinen (VMs) zu patchen, aktivieren Sie die Stufe „Advanced-Instances“. Die Nutzung des Advanced-Instances-Kontingents ist kostenpflichtig. Für Patch-Anwendungen, die von Microsoft auf Amazon Elastic Compute Cloud (Amazon EC2) -Instances veröffentlicht wurden, fallen keine zusätzlichen Gebühren an. Weitere Informationen finden Sie unter [Informationen zum Patchen von Anwendungen, die von Microsoft unter Windows Server veröffentlicht wurden](patch-manager-patching-windows-applications.md).
**Anzeigen von verwalteten Knoten**
Wenn Ihre verwalteten Knoten nicht in der Konsole aufgeführt werden, gehen Sie wie folgt vor:
1. Stellen Sie sicher, dass die Konsole in dem Bereich geöffnet ist, in AWS-Region dem Sie Ihre verwalteten Knoten erstellt haben. Über die Liste in der oberen, rechten Ecke der Konsole können Sie zwischen dein einzelnen Regionen wechseln.
1. Überprüfen Sie, ob die Einrichtungsschritte für Ihre verwalteten Knoten den Voraussetzungen von Systems Manager entsprechen. Weitere Informationen finden Sie unter [Einrichtung verwalteter Knoten für AWS Systems Manager](systems-manager-setting-up-nodes.md).
1. Vergewissern Sie sich, dass Sie den Hybrid-Aktivierungsprozess abgeschlossen haben, falls es sich nicht um EC2 Maschinen handelt. Weitere Informationen finden Sie unter [Verwalten von Knoten in Hybrid- und Multi-Cloud-Umgebungen mit Systems Manager](systems-manager-hybrid-multicloud.md).
Beachten Sie folgende Zusatzinformationen:
+ Die Fleet Manager Konsole zeigt keine EC2 Amazon-Knoten an, die beendet wurden.
+ Systems Manager erfordert genaue Zeitreferenzen, um Operationen auf Ihren Maschinen auszuführen. Wenn auf Ihren verwalteten Knoten das Datum und die Uhrzeit nicht korrekt eingestellt wurden, stimmen sie möglicherweise nicht mit dem Signaturdatum Ihrer API-Anforderungen überein. Weitere Informationen finden Sie unter [Anwendungsfälle und bewährte Methoden](systems-manager-best-practices.md).
+ Wenn Sie Tags erstellen oder bearbeiten, kann das System bis zu einer Stunde benötigen, bis Änderungen im Tabellenfilter angezeigt werden.
+ Nachdem der Status eines verwalteten Knotens mindestens 30 Tage lang `Connection Lost` gewesen ist, wird der Knoten möglicherweise nicht mehr in der Fleet Manager-Konsole aufgeführt. Beheben Sie das Problem, das den Verbindungsverlust verursacht hat, um ihn wieder in die Liste aufzunehmen. Tipps zur Fehlerbehebung finden Sie unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md).
**Überprüfen des Supports für Systems Manager auf einem verwalteten Knoten**
AWS Config stellt AWS verwaltete Regeln bereit. Dabei handelt es sich um vordefinierte, anpassbare Regeln, AWS Config anhand derer bewertet wird, ob Ihre AWS Ressourcenkonfigurationen den gängigen bewährten Methoden entsprechen. AWS Config Zu den verwalteten Regeln gehört die [instance-managed-by-systemsec2-manager-Regel](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html). Diese Regel prüft, ob die EC2 Amazon-Instances in Ihrem Konto von Systems Manager verwaltet werden. Weitere Informationen finden Sie unter [AWS Config Managed Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_use-managed-rules.html).
**Erhöhen des Sicherheitsstatus auf verwalteten Knoten**
Informationen zur Steigerung des Sicherheitsstatus in Bezug auf nicht autorisierte Befehle auf Root-Ebene auf Ihren verwalteten Knoten finden Sie unter [Einschränken des Zugriffs auf Befehle auf Stammebene durch SSM Agent](ssm-agent-restrict-root-level-commands.md).
**Abmelden verwalteter Knoten**
Sie können verwaltete Knoten jederzeit abmelden. Wenn Sie beispielsweise mehrere Knoten mit derselben AWS Identity and Access Management (IAM-) Rolle verwalten und irgendein bösartiges Verhalten feststellen, können Sie jederzeit eine beliebige Anzahl von Computern abmelden. (Um dasselbe Gerät erneut zu registrieren, müssen Sie einen anderen Hybrid-Aktivierungscode und eine andere Aktivierungs-ID als zuvor verwenden.) Informationen über das Abmelden verwalteter Knoten finden Sie unter [Aufheben der Registrierung von verwalteten Knoten in einer Hybrid- und Multi-Cloud-Umgebung](fleet-manager-deregister-hybrid-nodes.md).
**Topics**
+ [Konfigurieren von Instance-Kontingenten](fleet-manager-configure-instance-tiers.md)
+ [Zurücksetzen von Passwörtern für verwaltete Knoten](fleet-manager-reset-password.md)
+ [Aufheben der Registrierung von verwalteten Knoten in einer Hybrid- und Multi-Cloud-Umgebung](fleet-manager-deregister-hybrid-nodes.md)
+ [Arbeiten mit Betriebssystemdateisystemen mithilfe von Fleet Manager](fleet-manager-file-system-management.md)
+ [Überwachung der Leistung verwalteter Knoten](fleet-manager-monitoring-node-performance.md)
+ [Arbeiten mit Prozessen](fleet-manager-manage-processes.md)
+ [Protokolle auf verwalteten Knoten anzeigen](fleet-manager-view-node-logs.md)
+ [Verwalten von Betriebssystembenutzerkonten und Gruppen auf verwalteten Knoten mithilfe von Fleet Manager](fleet-manager-manage-os-user-accounts.md)
+ [Verwalten der Windows-Registrierung auf verwalteten Knoten](fleet-manager-manage-windows-registry.md)
# Konfigurieren von Instance-Kontingenten
In diesem Thema werden die Szenarien beschrieben, in denen Sie das Advanced-Instances-Kontingent aktivieren müssen.
AWS Systems Manager [bietet eine Standard-Instance-Stufe und eine Advanced-Instance-Stufe für Nicht-EC2-Computer in einer Hybrid- und Multi-Cloud-Umgebung.](operating-systems-and-machine-types.md#supported-machine-types)
Sie können bis zu 1.000 standardmäßige, [hybridaktivierte](activations.md) Knoten pro Konto und ohne zusätzliche Kosten registrieren. AWS-Region Um mehr als 1 000 Hybrid-Knoten zu registrieren, müssen Sie jedoch das Advanced-Instances-Kontingent aktivieren. Die Nutzung des Advanced-Instances-Kontingents ist kostenpflichtig. Weitere Informationen finden Sie unter [AWS Systems Manager – Preise](https://aws.amazon.com/systems-manager/pricing/).
Selbst mit weniger als 1 000 registrierten hybrid-aktivierten Knoten erfordern zwei weitere Szenarien des Advanced-Instances-Kontingents:
+ Sie möchten Session Manager verwenden, um eine Verbindung zu Nicht-EC2-Knoten herzustellen.
+ Sie möchten Anwendungen (nicht Betriebssysteme), die von Microsoft auf Nicht-EC2-Knoten veröffentlicht wurden, patchen.
**Anmerkung**
Für Patch-Anwendungen, die von Microsoft auf Amazon-EC2-Instances veröffentlicht wurden, fallen keine Gebühren an.
## Detaillierte Szenarien für Advanced-Instances-Kontingent
Die folgenden Informationen enthalten Details zu den drei Szenarien, für die Sie das Advanced-Instances-Kontingent aktivieren müssen.
Szenario 1: Sie möchten mehr als 1 000 hybrid-aktivierte Knoten registrieren
Mit der Stufe „Standard-Instances“ können Sie pro AWS-Region Konto maximal 1.000 Nicht-EC2-Knoten in einer [Hybrid- und Multicloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) ohne zusätzliche Kosten registrieren. Wenn Sie mehr als 1 000 Nicht-EC2-Knoten in einer Region anmelden müssen, müssen Sie das Advanced-Instances-Kontingent verwenden. Sie können dann so viele Maschinen für Ihre Hybrid- und Multi-Cloud-Umgebung aktivieren, wie Sie möchten. Die Gebühren für das Advanced-Instance-Kontingent basieren auf der Anzahl der Advanced-Knoten, die als von Systems Manager verwaltete Knoten aktiviert wurden, und den Stunden, in denen diese Knoten ausgeführt werden.
Für alle von Systems Manager verwalteten Knoten, die den unter [Eine Hybridaktivierung zum Registrieren von Knoten bei Systems Manager erstellen](hybrid-activation-managed-nodes.md) beschriebenen Aktivierungsprozess verwenden, wird eine Gebühr erhoben, wenn Sie in einer Region in einem bestimmten Konto die Zahl von 1 000 On-Premises-Knoten überschreiten.
Sie können auch vorhandene Amazon Elastic Compute Cloud (Amazon EC2)-Instances mithilfe von Hybrid-Aktivierungen von Systems Manager installieren und mit ihnen als Nicht-EC2-Instances arbeiten, z. B. zu Testzwecken. Diese zählen auch als Hybrid-Knoten. Dies ist kein übliches Szenario.
Szenario 2: Patchen von von Microsoft veröffentlichten Anwendungen auf hybrid-aktivierten Knoten
Das Advanced-Instances-Kontingent ist auch erforderlich, wenn Sie von Microsoft veröffentlichte Anwendungen auf Nicht-EC2-Knoten in einer Hybrid- und Multi-Cloud-Umgebung patchen möchten. Wenn Sie das Advanced-Instances-Kontingent aktivieren, um Microsoft-Anwendungen auf Nicht-EC2-Knoten zu patchen, fallen Gebühren für alle On-Premises-Knoten an, selbst wenn Sie weniger als 1 000 haben.
Für Patch-Anwendungen, die von Microsoft auf Amazon Elastic Compute Cloud (Amazon EC2)-Instances veröffentlicht wurden, fallen keine zusätzlichen Gebühren an. Weitere Informationen finden Sie unter [Informationen zum Patchen von Anwendungen, die von Microsoft unter Windows Server veröffentlicht wurden](patch-manager-patching-windows-applications.md).
Szenario 3: Herstellen einer Verbindung zu hybrid-aktivierten Knoten mit Session Manager
Session Manager bietet interaktiven Shell-Zugriff auf Ihre Instances. Um über Session Manager eine Verbindung zu hybrid-aktivierten Knoten herzustellen, müssen Sie die Advanced-Instances-Kontingente aktivieren. Dann fallen Gebühren für alle hybrid-aktivierten Knoten an, auch wenn Sie weniger als 1 000 haben.
**Zusammenfassung: Wann brauche ich das Advanced-Instances-Kontingent?**
Anhand der folgenden Tabelle können Sie überprüfen, wann Sie das Advanced-Instances-Kontingent verwenden müssen und für welche Szenarien zusätzliche Gebühren anfallen.
****
| Szenario | Advanced-Instances-Kontingent erforderlich? | Es fallen zusätzliche Gebühren an. |
| --- | --- | --- |
| Die Anzahl der hybrid-aktivierten Knoten in meiner Region in einem bestimmten Konto beträgt mehr als 1 000. | Ja | Ja |
| Ich möchte Patch Manager benutzen, um von Microsoft veröffentlichte Anwendungen auf einer beliebigen Anzahl hybrid-aktivierter Knoten zu patchen, sogar weniger als 1 000. | Ja | Ja |
| Ich möchte Session Manager benutzen, um sich mit einer beliebigen Anzahl hybrid-aktivierter Knoten zu verbinden, sogar weniger als 1 000. | Ja | Ja |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/fleet-manager-configure-instance-tiers.html) | Nein | Nein |
**Topics**
+ [Detaillierte Szenarien für Advanced-Instances-Kontingent](#systems-manager-managed-instances-tier-scenarios)
+ [Aktivieren des Kontingents für erweiterte Instances](fleet-manager-enable-advanced-instances-tier.md)
+ [Wechsel vom Kontingent für erweiterte Instances zurück zum Kontingent für Standard-Instances](fleet-manager-revert-to-standard-tier.md)
# Aktivieren des Kontingents für erweiterte Instances
AWS Systems Manager [bietet eine Stufe „Standard-Instances“ und eine Stufe „Advanced-Instances“ für Nicht-EC2-Computer in einer Hybrid- und Multi-Cloud-Umgebung.](operating-systems-and-machine-types.md#supported-machine-types) Mit der Stufe „Standard-Instances“ können Sie pro Person maximal 1.000 hybridaktivierte Maschinen registrieren. AWS-Konto AWS-Region Die erweiterte Instances-Ebene ist auch erforderlich, um Patch Manager zum Patchen von von Microsoft freigegebenen Anwendungen auf Nicht-EC2-Knoten zu verwenden und mit Session Manager eine Verbindung zu Nicht-EC2-Knoten herzustellen. Weitere Informationen finden Sie unter [Aktivieren des Kontingents für erweiterte Instances](#fleet-manager-enable-advanced-instances-tier).
In diesem Abschnitt wird beschrieben, wie Sie Ihre Hybrid- und Multi-Cloud-Umgebung für die Nutzung des Kontingents für erweiterte Instances konfigurieren.
**Bevor Sie beginnen**
Prüfen Sie die Preisdetails für erweiterte Instances. Erweiterte Instanzen sind auf a verfügbar. per-use-basis Weitere Informationen dazu finden Sie unter [AWS Systems Manager -Preise](https://aws.amazon.com/systems-manager/pricing/).
## Konfigurieren von Berechtigungen zum Aktivieren des Kontingents für erweiterte Instances
Vergewissern Sie sich, dass Sie in AWS Identity and Access Management (IAM) berechtigt sind, Ihre Umgebung von der Stufe Standard-Instances auf die Stufe Advanced-Instances umzustellen. Sie müssen entweder die `AdministratorAccess`-IAM-Richtlinie an Ihren Benutzer, Ihre Gruppe oder Ihre Rolle anfügen oder über die Berechtigung zum Ändern der Service-Einstellung für die Aktivierungsebene in Systems Manager verfügen. Diese nutzt die folgenden API-Operationen:
+ [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)
Gehen Sie wie folgt vor, um einem Benutzerkonto eine IAM-Richtlinie hinzufügen. Mit dieser Richtlinie können Benutzer die aktuelle Einstellung für das Kontingent für verwaltete Instances anzeigen. Diese Richtlinie ermöglicht es dem Benutzer auch, die aktuelle Einstellung im angegebenen und zu ändern oder zurückzusetzen. AWS-Konto AWS-Region
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Klicken Sie im Navigationsbereich auf **Users (Benutzer)**.
1. Wählen Sie in der Liste den Namen des Benutzers aus, in den Sie die Richtlinie einbinden möchten.
1. Wählen Sie die Registerkarte **Berechtigungen**.
1. Klicken Sie rechts auf der Seite unter **Permission policies (Berechtigungsrichtlinien)** auf **Add inline policy (Inline-Richtlinie hinzufügen)**.
1. Wählen Sie den Tab **JSON**.
1. Ersetzen Sie den Standardinhalt durch folgenden Inhalt:
------
#### [ 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. Wählen Sie **Richtlinie prüfen**.
1. Geben Sie auf der Seite **Richtlinie prüfen** im Feld **Name** einen Namen für die Inline-Richtlinie ein. Beispiel: **Managed-Instances-Tier**.
1. Wählen Sie **Richtlinie erstellen** aus.
Administratoren können schreibgeschützte Berechtigungen angeben, indem sie dem Benutzer die folgende Inline-Richtlinie zuweisen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetServiceSetting"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"ssm:ResetServiceSetting",
"ssm:UpdateServiceSetting"
],
"Resource": "*"
}
]
}
```
------
Informationen zum Erstellen einer IAM-Richtlinie finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.
## Aktivieren des Kontingents für erweiterte Instances (Konsole)
Das folgende Verfahren zeigt Ihnen, wie Sie mit der Systems Manager Manager-Konsole *alle* Nicht-EC2-Knoten, die mithilfe der Managed-Instance-Aktivierung hinzugefügt wurden, in der angegebenen AWS-Konto und auf die AWS-Region Advanced-Instance-Stufe umstellen.
**Bevor Sie beginnen**
Stellen Sie sicher, dass die Konsole in dem Bereich geöffnet ist, in AWS-Region dem Sie Ihre verwalteten Instanzen erstellt haben. Über die Liste in der oberen, rechten Ecke der Konsole können Sie zwischen dein einzelnen Regionen wechseln.
Überprüfen Sie, ob Sie die Einrichtungsanforderungen für Ihre Instances der Amazon Elastic Compute Cloud (Amazon EC2) und Nicht-EC2-Maschinen in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) erfüllt haben. Weitere Informationen finden Sie unter [Einrichtung verwalteter Knoten für AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Wichtig**
Nachfolgend wird beschrieben, wie Sie eine Einstellung auf Kontoebene ändern. Durch diese Änderung fallen für Ihr Konto Gebühren an.
**So aktivieren Sie das Kontingent für erweiterte Instances (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie **Einstellungen** und anschließend **Einstellungen der Instance-Ebene ändern**.
1. Überprüfen Sie die Informationen im Dialogfeld zum Ändern der Kontoeinstellungen.
1. Wenn Sie zustimmen, wählen Sie die Option, die Sie akzeptieren möchten, und klicken Sie dann auf **Einstellung ändern**.
Es kann einige Minuten dauern, bis alle Instances vom Kontingent für Standard-Instances in das Kontingent für erweiterte Instances verschoben wurden.
**Anmerkung**
Informationen zum Wechsel zurück zum Kontingent für Standard-Instances finden Sie unter [Wechsel vom Kontingent für erweiterte Instances zurück zum Kontingent für Standard-Instances](fleet-manager-revert-to-standard-tier.md).
## Aktivieren des Kontingents für erweiterte Instances (AWS CLI)
Das folgende Verfahren zeigt Ihnen, wie Sie *alle* lokalen Server AWS Command Line Interface , die mithilfe der Aktivierung von verwalteten Instanzen hinzugefügt wurden VMs , in der angegebenen Version ändern AWS-Konto und AWS-Region, um die Stufe Advanced-Instances zu verwenden.
**Wichtig**
Nachfolgend wird beschrieben, wie Sie eine Einstellung auf Kontoebene ändern. Durch diese Änderung fallen für Ihr Konto Gebühren an.
**Um die Stufe Advanced-Instances zu aktivieren, verwenden Sie den AWS CLI**
1. Öffnen Sie den AWS CLI und führen Sie den folgenden Befehl aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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
```
------
Wenn der Befehl erfolgreich ausgeführt wurde, gibt es keine Ausgabe.
1. Führen Sie den folgenden Befehl aus, um die aktuellen Diensteinstellungen für verwaltete Knoten im aktuellen AWS-Konto und anzuzeigen AWS-Region.
------
#### [ 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
```
------
Der Befehl gibt Informationen wie die folgenden zurück.
```
{
"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"
}
}
```
## Aktivieren des Kontingents für erweiterte Instances (PowerShell)
Das folgende Verfahren zeigt Ihnen, wie Sie *alle* lokalen Server AWS Tools for Windows PowerShell , die mithilfe der Aktivierung von verwalteten Instanzen hinzugefügt wurden VMs , in der angegebenen AWS-Konto Ebene ändern und, um die Stufe „ AWS-Region Advanced-Instances“ zu verwenden.
**Wichtig**
Nachfolgend wird beschrieben, wie Sie eine Einstellung auf Kontoebene ändern. Durch diese Änderung fallen für Ihr Konto Gebühren an.
**Um die Advanced-Instance-Stufe zu aktivieren, verwenden Sie PowerShell**
1. Öffnen Sie den folgenden AWS Tools for Windows PowerShell Befehl und führen Sie ihn aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "advanced"
```
Wenn der Befehl erfolgreich ausgeführt wurde, gibt es keine Ausgabe.
1. Führen Sie den folgenden Befehl aus, um die aktuellen Diensteinstellungen für verwaltete Knoten im aktuellen AWS-Konto und anzuzeigen AWS-Region.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
Der Befehl gibt Informationen wie die folgenden zurück.
```
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
```
Es kann einige Minuten dauern, bis alle Knoten vom Standard-Instances-Kontingent in das Advanced-Instances-Kontingent verschoben wurden.
**Anmerkung**
Informationen zum Wechsel zurück zum Kontingent für Standard-Instances finden Sie unter [Wechsel vom Kontingent für erweiterte Instances zurück zum Kontingent für Standard-Instances](fleet-manager-revert-to-standard-tier.md).
# Wechsel vom Kontingent für erweiterte Instances zurück zum Kontingent für Standard-Instances
In diesem Abschnitt wird beschrieben, wie hybrid-aktivierte Knoten, die im Advanced-Instances-Kontingent ausgeführt werden, wieder zum Standard-Instances-Kontingent umgestellt werden. Diese Konfiguration gilt für alle hybridaktivierten Knoten in einem AWS-Konto und einem. AWS-Region
**Bevor Sie beginnen**
Lesen Sie die folgenden wichtigen Details.
**Anmerkung**
Sie können nicht wieder zum Kontingent für Standard-Instances zurückkehren, wenn Sie im Konto und in der Region mehr als 1 000 hybrid-aktivierte Knoten ausführen. Sie müssen also zunächst die Registrierung für Knoten aufheben, bis 1 000 oder weniger vorhanden sind. Dies gilt auch für Amazon Elastic Compute Cloud (Amazon EC2)-Instances, die eine Hybrid-Aktivierung von Systems Manager verwenden (kein gängiges Szenario). Weitere Informationen finden Sie unter [Aufheben der Registrierung von verwalteten Knoten in einer Hybrid- und Multi-Cloud-Umgebung](fleet-manager-deregister-hybrid-nodes.md).
Nach dem Zurücksetzen können Sie Session Manager, ein Tool in AWS Systems Manager, nicht mehr verwenden, um interaktiv auf Ihre hybrid-aktivierten Knoten zuzugreifen.
Nach dem Zurücksetzen können Sie Patch Manager, ein Tool in AWS Systems Manager, nicht mehr verwenden, um von Microsoft veröffentlichte Anwendungen auf hybrid-aktivierten Knoten zu patchen.
Das Zurücksetzen aller hybrid-aktivierten Knoten auf das Kontingent für Standard-Instances kann 30 Minuten oder länger dauern.
In diesem Abschnitt wird beschrieben, wie Sie alle hybridaktivierten Knoten in einer Stufe AWS-Konto und AWS-Region von der Stufe Advanced-Instances auf die Stufe Standard-Instances zurücksetzen.
## Zurücksetzen auf das Kontingent für Standard-Instances (Konsole)
Das folgende Verfahren zeigt Ihnen, wie Sie die Systems Manager Manager-Konsole verwenden, um alle hybridaktivierten Knoten in Ihrer [Hybrid- und Multicloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) so zu ändern, dass sie die Stufe „Standardinstanzen“ im angegebenen und verwenden. AWS-Konto AWS-Region
**So stellen Sie das Kontingent für Standard-Instances wieder her (Konsole)**
1. Öffnen Sie die Konsole unter. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie das Dropdown-Menü **Account settings (Kontoeinstellungen)** und wählen Sie **Instance tier settings (Instance-Kontingenteneinstellungen)**.
1. Wählen Sie die Option **Change account settings (Kontoeinstellungen ändern)** aus.
1. Lesen Sie die Informationen zum Ändern der Kontoeinstellungen im angezeigten Popup-Fenster und wählen Sie ggf. die Option zum Akzeptieren und Fortfahren aus.
## Zurücksetzen auf das Kontingent für Standard-Instances (AWS CLI)
Das folgende Verfahren zeigt Ihnen, wie Sie die AWS Command Line Interface verwenden, um alle hybridaktivierten Knoten in Ihrer [Hybrid- und Multicloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) so zu ändern, dass sie die Stufe „Standard-Instances“ im angegebenen und verwenden. AWS-Konto AWS-Region
**Um zur Stufe „Standard-Instances“ zurückzukehren, verwenden Sie AWS CLI**
1. Öffnen Sie den AWS CLI und führen Sie den folgenden Befehl aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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
```
------
Wenn der Befehl erfolgreich ausgeführt wurde, gibt es keine Ausgabe.
1. Führen Sie den folgenden Befehl 30 Minuten später aus, um die Einstellungen für verwaltete Instanzen in der aktuellen Version AWS-Konto und anzuzeigen AWS-Region.
------
#### [ 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
```
------
Der Befehl gibt Informationen wie die folgenden zurück.
```
{
"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"
}
}
```
Der Status ändert sich auf *Standard*, nachdem die Anfrage genehmigt wurde.
## Zurücksetzen auf das Kontingent für Standard-Instances (PowerShell)
Das folgende Verfahren zeigt Ihnen, wie Sie hybridaktivierte Knoten in Ihrer Hybrid- und Multicloud-Umgebung so ändern, dass sie die Stufe „Standardinstanzen“ im angegebenen und verwenden. AWS Tools for Windows PowerShell AWS-Konto AWS-Region
**Um zur Stufe „Standard-Instances“ zurückzukehren, verwenden Sie PowerShell**
1. Öffnen Sie den folgenden AWS Tools for Windows PowerShell Befehl und führen Sie ihn aus.
```
Update-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier" `
-SettingValue "standard"
```
Wenn der Befehl erfolgreich ausgeführt wurde, gibt es keine Ausgabe.
1. Führen Sie den folgenden Befehl 30 Minuten später aus, um die Einstellungen für verwaltete Instanzen in der aktuellen Version AWS-Konto und anzuzeigen AWS-Region.
```
Get-SSMServiceSetting `
-SettingId "arn:aws:ssm:region:aws-account-id:servicesetting/ssm/managed-instance/activation-tier"
```
Der Befehl gibt Informationen wie die folgenden zurück.
```
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
```
Der Status ändert sich auf *Standard*, nachdem die Anfrage genehmigt wurde.
# Zurücksetzen von Passwörtern für verwaltete Knoten
Sie können das Passwort für einen beliebigen Benutzer auf einem verwalteten Knoten zurücksetzen. Dazu gehören Amazon Elastic Compute Cloud (Amazon EC2) -Instances, AWS IoT Greengrass Kerngeräte und lokale Server, Edge-Geräte und virtuelle Maschinen (VMs), die von verwaltet werden. AWS Systems Manager Die Funktionalität zum Zurücksetzen des Passworts basiert auf Session Manager, einem Tool in AWS Systems Manager. Sie können diese Funktionalität verwenden, um eine Verbindung zu verwalteten Knoten herzustellen, ohne eingehende Ports öffnen, Bastion-Hosts zu pflegen oder SSH-Schlüssel verwalten zu müssen.
Die Option zum Zurücksetzen des Passworts ist nützlich, wenn ein Benutzer ein Passwort vergessen hat, oder wenn Sie schnell ein Passwort aktualisieren möchten, ohne eine RDP- oder SSH-Verbindung mit einem verwalteten Knoten herzustellen.
**Voraussetzungen**
Um das Passwort auf einem verwalteten Knoten zurücksetzen zu können, müssen die folgenden Anforderungen erfüllt sein:
+ Der verwaltete Knoten, auf dem Sie ein Passwort ändern möchten, muss ein von Systems Manager verwalteter Knoten sein. Auch muss SSM Agent Version 2.3.668.0 oder höher auf dem verwalteten Knoten installiert sein. Informationen über das Installieren oder Aktualisieren von SSM Agent finden Sie unter [Arbeiten mit SSM Agent](ssm-agent.md).
+ Die Funktionalität zum Zurücksetzen des Passworts verwendet die Session Manager-Konfiguration, die für Ihr Konto eingerichtet ist, um eine Verbindung mit dem verwalteten Knoten herzustellen. Aus diesem Grund müssen die Voraussetzungen für die Verwendung von Session Manager für Ihr Konto in der aktuellen AWS-Region erfüllt sein. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
**Anmerkung**
Session Manager-Support für On-Premises-Knoten wird nur für das Advanced-Instances-Kontingent bereitgestellt. Weitere Informationen finden Sie unter [Aktivieren des Kontingents für erweiterte Instances](fleet-manager-enable-advanced-instances-tier.md).
+ Der AWS Benutzer, der das Passwort ändert, muss über die `ssm:SendCommand` Berechtigung für den verwalteten Knoten verfügen. Weitere Informationen finden Sie unter [Den Zugriff von Run Command anhand von Tags beschränken](run-command-setting-up.md#tag-based-access).
**Beschränken des Zugriffs**
Sie können die Fähigkeit eines Benutzers, Passwörter zurückzusetzen, auf bestimmte verwaltete Knoten beschränken. Dies geschieht durch Verwendung von identitätsbasierten Richtlinien für die Session Manager-Operation `ssm:StartSession` über dem SSM-Dokument `AWS-PasswordReset`. Weitere Informationen finden Sie unter [Kontrollieren des Sitzungszugriffs von Benutzern auf Instances](session-manager-getting-started-restrict-access.md).
**Verschlüsseln von Daten**
Aktivieren Sie AWS Key Management Service (AWS KMS) die vollständige Verschlüsselung für Session Manager Daten, um die Option zum Zurücksetzen des Kennworts für verwaltete Knoten zu verwenden. Weitere Informationen finden Sie unter [So aktivieren Sie die KMS-Schlüsselverschlüsselung von Sitzungsdaten (Konsole)](session-preferences-enable-encryption.md).
## Zurücksetzen eines Passworts auf einem verwalteten Knoten
Sie können ein Passwort auf einem von Systems Manager verwalteten Knoten mithilfe der Systems Manager **Fleet Manager**Manager-Konsole oder der Taste AWS Command Line Interface (AWS CLI) zurücksetzen.
**So ändern Sie das Passwort auf einem verwalteten Knoten (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem Knoten, der ein neues Passwort benötigt.
1. Wählen Sie **Instance-Aktionen, Passwort zurücksetzen**.
1. Geben Sie im Feld **User name (Benutzername)** den Namen des Benutzers ein, für den Sie das Passwort ändern. Dabei kann es sich um jeden Benutzernamen handeln, der ein Konto auf dem Knoten hat.
1. Wählen Sie **Absenden** aus.
1. Befolgen Sie die Eingabe-Prompts im Befehlsfenster **Neues Passwort eingeben**, um das neue Passwort anzugeben.
**Anmerkung**
Wenn die Version von SSM Agent auf dem verwalteten Knoten kein Zurücksetzen von Passwörtern unterstützt, werden Sie aufgefordert, mit Run Command, einem Tool in AWS Systems Manager, eine unterstützte Version zu installieren.
**So setzen Sie das Passwort auf einem verwalteten Knoten zurück (AWS CLI)**
1. Um das Passwort für einen Benutzer auf einem verwalteten Knoten zurückzusetzen, führen Sie den folgenden Befehl aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
**Anmerkung**
Um das AWS CLI zum Zurücksetzen eines Passworts zu verwenden, muss das Session Manager Plugin auf Ihrem lokalen Computer installiert sein. Weitere Informationen finden Sie unter [Installiere das Session Manager Plugin für 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. Befolgen Sie die Eingabe-Prompts im Befehlsfenster **Neues Passwort eingeben**, um das neue Passwort anzugeben.
## Fehlerbehebung beim Zurücksetzen von Passwörtern auf verwalteten Knoten
Viele Probleme beim Zurücksetzen von Passwörtern können behoben werden, wenn Sie sicherstellen, dass Sie die [Voraussetzungen für das Zurücksetzen von Passwörtern](#pw-reset-prereqs) gelesen haben. Bei anderen Problemen nehmen Sie die folgenden Informationen zur Behebung von Problemen beim Zurücksetzen von Passwörtern zu Hilfe.
**Topics**
+ [Verwalteter Knoten nicht verfügbar](#password-reset-troubleshooting-instances)
+ [SSM Agentnicht up-to-date (Konsole)](#password-reset-troubleshooting-ssmagent-console)
+ [Optionen zum Zurücksetzen des Passworts werden nicht bereitgestellt (AWS CLI)](#password-reset-troubleshooting-ssmagent-cli)
+ [Keine Berechtigung zum Ausführen von `ssm:SendCommand`](#password-reset-troubleshooting-sendcommand)
+ [Session Manager-Fehlermeldung](#password-reset-troubleshooting-session-manager)
### Verwalteter Knoten nicht verfügbar
**Problem**: Sie möchten auf der Seite **Managed Instances** (Verwaltete Instances) der Konsole das Passwort für einen verwalteten Knoten zurücksetzen, der jedoch nicht in der Liste enthalten ist.
+ **Solution** (Lösung): Der verwaltete Knoten, mit dem Sie eine Verbindung herstellen möchten, wurde möglicherweise nicht für Systems Manager konfiguriert. Um eine EC2-Instance mit Systems Manager zu verwenden, muss der Instance ein AWS Identity and Access Management (IAM-) Instanzprofil angehängt werden, das Systems Manager die Erlaubnis erteilt, Aktionen auf Ihren Instances auszuführen. Informationen finden Sie unter [Konfiguration von erforderliche Instance-Berechtigungen für Systems Manager](setup-instance-permissions.md).
Um eine Nicht-EC2-Maschine mit Systems Manager zu verwenden, erstellen Sie eine IAM-Servicerolle, die Systems Manager die Berechtigung gibt, Aktionen auf Ihren verwalteten Knoten durchzuführen. Weitere Informationen finden Sie unter [Erstellen der für Systems Manager erforderlichen IAM-Servicerolle in Hybrid- und Multicloud-Umgebungen](hybrid-multicloud-service-role.md). (Session ManagerUnterstützung für lokale Server und VMs wird nur für die Stufe „Advanced-Instances“ bereitgestellt. Weitere Informationen finden Sie unter.) [Aktivieren des Kontingents für erweiterte Instances](fleet-manager-enable-advanced-instances-tier.md)
### SSM Agentnicht up-to-date (Konsole)
**Problem**: Es wird eine Meldung angezeigt, dass die Version von SSM Agent die Funktionalität zum Zurücksetzen von Passwörtern nicht unterstützt.
+ **Lösung**: Es ist Version 2.3.668.0 oder höher von SSM Agent erforderlich, um Passwörter zurückzusetzen. In der Konsole können Sie den Agent auf dem verwalteten Knoten aktualisieren, indem Sie **Update SSM Agent** ( aktualisieren) auswählen.
Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter [Automatisieren von Updates für SSM Agent](ssm-agent-automatic-updates.md). Abonnieren Sie die [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten.
### Optionen zum Zurücksetzen des Passworts werden nicht bereitgestellt (AWS CLI)
**Problem**: Sie haben mit dem 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)` Befehl erfolgreich eine Verbindung zu einem verwalteten Knoten hergestellt. Sie haben das SSM-Dokument `AWS-PasswordReset` und einen gültigen Benutzernamen angegeben, aber die Eingabeaufforderungen zur Änderung des Passworts werden nicht angezeigt.
+ **Lösung**: Die Version von SSM Agent auf dem verwalteten Knoten ist es nicht up-to-date. Es ist Version 2.3.668.0 oder höher erforderlich, um das Passwort zurückzusetzen.
Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter [Automatisieren von Updates für SSM Agent](ssm-agent-automatic-updates.md). Abonnieren Sie die [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten.
### Keine Berechtigung zum Ausführen von `ssm:SendCommand`
**Problem**: Sie versuchen, eine Verbindung zu einem verwalteten Knoten herzustellen, um das Passwort zu ändern, aber es wird eine Fehlermeldung angezeigt, dass Sie nicht autorisiert sind, `ssm:SendCommand` auf dem verwalteten Knoten auszuführen.
+ **Lösung**: Ihre IAM-Richtlinie muss die Berechtigung zum Ausführen des `ssm:SendCommand`-Befehls enthalten. Weitere Informationen finden Sie unter [Den Zugriff von Run Command anhand von Tags beschränken](run-command-setting-up.md#tag-based-access).
### Session Manager-Fehlermeldung
**Problem**: Sie erhalten eine Fehlermeldung zu Session Manager.
+ **Lösung**: Die Unterstützung für das Zurücksetzen von Passwörtern erfordert, dass Session Manager korrekt konfiguriert ist. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md) und [Fehlerbehebung für Session Manager](session-manager-troubleshooting.md).
# Aufheben der Registrierung von verwalteten Knoten in einer Hybrid- und Multi-Cloud-Umgebung
Wenn Sie einen lokalen Server, ein Edge-Gerät oder eine virtuelle Maschine (VM) nicht mehr mithilfe von verwenden möchten AWS Systems Manager, können Sie die Registrierung aufheben. Wenn Sie einen hybridaktivierten Knoten deregistrieren, wird er aus der Liste der verwalteten Knoten in Systems Manager entfernt. AWS Systems Manager Der Agent (SSM Agent) der auf dem hybrid-aktivierten Knoten läuft, kann sein Autorisierungs-Token nicht mehr aktualisieren, da es nicht mehr registriert ist. SSM Agent wird in den Ruhezustand versetzt und reduziert seine Ping-Frequenz auf Systems Manager in der Cloud auf einmal pro Stunde. Systems Manager speichert den Befehlsverlauf für einen verwaltete Knoten, deren Registrierung aufgehoben wurde, 30 Tage lang.
**Anmerkung**
Sie können einen lokalen Server, ein Edge-Gerät oder eine VM mit demselben Aktivierungscode und derselben ID erneut registrieren, solange Sie das Instance-Limit für den angegebenen Aktivierungscode und die angegebene ID nicht erreicht haben. **Sie können das Instance-Limit in der Konsole überprüfen, indem Sie **Node-Tools** und dann Hybrid-Aktivierungen** auswählen. Wenn der Wert für **Registrierte Instances** unter dem **Registrierungslimit** liegt, können Sie eine Maschine mit demselben Aktivierungscode und derselben ID erneut registrieren. Wenn der Wert über dem Limit liegt, müssen Sie einen anderen Aktivierungscode und eine andere ID verwenden.
Im folgenden Verfahren wird beschrieben, wie Sie die Registrierung für einen hybrid-aktivierten Knoten mithilfe der Systems-Manager-Konsole aufheben. Informationen dazu, wie Sie dies mithilfe von tun können AWS Command Line Interface, finden Sie unter [deregister-managed-instance](https://docs.aws.amazon.com/cli/latest/reference/ssm/deregister-managed-instance.html).
Verwandte Informationen finden Sie in den folgenden Themen:
+ [Abmelden und Neuregistrieren eines verwalteten Knotens (Linux)](hybrid-multicloud-ssm-agent-install-linux.md#systems-manager-install-managed-linux-deregister-reregister) (Linux)
+ [Abmelden und Neuregistrieren eines verwalteten Knotens (Windows Server)](hybrid-multicloud-ssm-agent-install-windows.md#systems-manager-install-managed-win-deregister-reregister) (Windows Server)
**Um die Registrierung eines hybrid-aktivierten Knotens aufzuheben (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Aktivieren Sie das Kontrollkästchen neben dem verwalteten Knoten, den Sie abmelden möchten.
1. Wählen Sie **„Knotenaktionen“, „Tools“, „Diesen verwalteten Knoten abmelden“**.
1. Überprüfen Sie die Informationen im Dialogfeld **Diesen verwalteten Knoten deregistrieren**. Wenn Sie zustimmen, wählen Sie **Deregister** aus.
# Arbeiten mit Betriebssystemdateisystemen mithilfe von Fleet Manager
Sie könnenFleet Manager, ein Tool in AWS Systems Manager, verwenden, um mit dem Dateisystem auf Ihren verwalteten Knoten zu arbeiten. Mit Fleet Manager können Sie Informationen über das Verzeichnis und die Dateidaten anzeigen, die auf den Volumes gespeichert sind, die an Ihre verwalteten Knoten angefügt sind. Sie können beispielsweise den Namen, die Größe, die Erweiterung, den Besitzer und die Berechtigungen für Ihre Verzeichnisse und Dateien anzeigen. Bis zu 10.000 Zeilen von Dateidaten können als Text in der Fleet Manager-Konsole angezeigt werden. Sie können diese Funktion auch für `tail`-Dateien verwenden. Bei Verwendung von `tail`, um Dateidaten anzuzeigen, werden zunächst die letzten 10 Zeilen der Datei angezeigt. Wenn neue Datenzeilen in die Datei geschrieben werden, wird die Ansicht in Echtzeit aktualisiert. Daher können Sie Protokolldaten von der Konsole aus überprüfen, was die Effizienz Ihrer Fehlerbehebung und Systemverwaltung verbessern kann. Darüber hinaus können Sie Verzeichnisse erstellen und Dateien und Verzeichnisse kopieren, ausschneiden, einfügen, umbenennen oder löschen.
Wir empfehlen Ihnen, regelmäßige Backups zu erstellen oder Snapshots der Amazon Elastic Block Store (Amazon EBS)-Volumes zu erstellen, die an Ihre verwalteten Knoten angefügt sind. Beim Kopieren oder Ausschneiden und Einfügen von Dateien werden vorhandene Dateien und Verzeichnisse im Zielpfad mit dem gleichen Namen wie die neuen Dateien oder Verzeichnisse ersetzt. Schwerwiegende Probleme können auftreten, wenn Sie Systemdateien und -verzeichnisse ersetzen oder ändern. AWS garantiert nicht, dass diese Probleme gelöst werden können. Ändern Sie Systemdateien auf eigenes Risiko. Sie sind für alle Änderungen an Dateien und Verzeichnissen verantwortlich und stellen sicher, dass Sie Backups haben. Das Löschen oder Ersetzen von Dateien und Verzeichnissen kann nicht rückgängig gemacht werden.
**Anmerkung**
Fleet ManagerverwendetSession Manager, ein Tool in AWS Systems Manager, um Textvorschauen und `tail` Dateien anzusehen. Für Amazon Elastic Compute Cloud (Amazon EC2)-Instances muss das Instance-Profil, das Ihren verwalteten Instances angefügt ist, Berechtigungen für Session Manager bereitstellen, um diese Funktion zu verwenden. Weitere Informationen zum Hinzufügen von Session Manager-Berechtigungen an ein Instance-Profil finden Sie unter [Session Manager-Berechtigungen für eine vorhandene IAM-Rolle hinzufügen](getting-started-add-permissions-to-existing-profile.md).
**Topics**
+ [Anzeigen des OS-Dateisystems mithilfe von Fleet Manager](fleet-manager-viewing-file-system.md)
+ [Vorschau von Betriebssystemdateien mit Fleet Manager](fleet-manager-preview-os-files.md)
+ [Speichern von Betriebssystemdateien mit Fleet Manager](fleet-manager-tailing-os-files.md)
+ [Kopieren, Ausschneiden und Einfügen von Betriebssystemdateien oder -verzeichnissen mit Fleet Manager](fleet-manager-move-files-or-directories.md)
+ [Umbenennen von Betriebssystemdateien und -verzeichnissen mit Fleet Manager](fleet-manager-renaming-files-and-directories.md)
+ [Löschen von Betriebssystemdateien und -verzeichnissen mit Fleet Manager](fleet-manager-deleting-files-and-directories.md)
+ [Betriebssystemverzeichnisse erstellen mit Fleet Manager](fleet-manager-creating-directories.md)
+ [Ausschneiden, Kopieren und Einfügen von Betriebssystemverzeichnissen mit Fleet Manager](fleet-manager-managing-directories.md)
# Anzeigen des OS-Dateisystems mithilfe von Fleet Manager
Sie können Fleet Manager verwenden, um das Betriebssystemdateisystem auf einem von Systems Manager verwalteten Knoten anzuzeigen.
**Anzeigen des OS-Dateisystems mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens mit dem Dateisystem, das Sie anzeigen möchten.
1. Wählen Sie **Tools, Dateisysteme**.
# Vorschau von Betriebssystemdateien mit Fleet Manager
Sie können Fleet Manager verwenden, um eine Vorschau von Textdateien auf einem Betriebssystem anzuzeigen.
**So zeigen Sie Textvorschauen mit Fleet Manager an**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens mit den Dateien, die Sie anzeigen möchten.
1. Wählen Sie **Tools, Dateisysteme**.
1. Wählen Sie den **File name** (Dateiname) des Verzeichnisses, das die Datei enthält, die Sie in der Vorschau anzeigen möchten.
1. Wählen Sie die Schaltfläche neben der Datei, deren Inhalt Sie in der Vorschau anzeigen möchten.
1. Wählen Sie **Aktionen, Vorschau als Text**.
# Speichern von Betriebssystemdateien mit Fleet Manager
Sie können sie Fleet Manager verwenden, um eine Datei auf einem verwalteten Knoten als Tail zu speichern.
**So verfolgen Sie OS-Dateien mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens mit den Dateien, die Sie verfolgen möchten.
1. Wählen Sie **Tools, Dateisysteme**.
1. Wählen Sie den **File name** (Dateiname) des Verzeichnisses, das die Datei enthält, die verfolgen möchten.
1. Wählen Sie die Schaltfläche neben der Datei, deren Inhalt Sie verfolgen möchten.
1. Wählen Sie **Aktionen, Enddatei**.
# Kopieren, Ausschneiden und Einfügen von Betriebssystemdateien oder -verzeichnissen mit Fleet Manager
Sie können Fleet Manager mit Betriebssystemdateien auf einem verwalteten Knoten kopieren, ausschneiden und einfügen.
**So kopieren oder fügen Sie Dateien oder Verzeichnisse mit Fleet Manager ein**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens mit den Dateien, die Sie kopieren oder ausschneiden und einfügen möchten.
1. Wählen Sie **Tools, Dateisysteme**.
1. Um eine Datei zu kopieren oder auszuschneiden, wählen Sie den **File name** (Dateiname) des Verzeichnisses, das die Datei enthält, die Sie kopieren oder ausschneiden möchten. Um ein Verzeichnis zu kopieren oder auszuschneiden, wählen Sie die Schaltfläche neben dem Verzeichnis, das Sie kopieren oder ausschneiden möchten, und fahren Sie dann mit Schritt 8 fort.
1. Wählen Sie die Schaltfläche neben der Datei, die Sie kopieren oder ausschneiden möchten.
1. Wählen Sie im Menü **Actions** (Aktionen) **Copy** (Kopieren) oder **Cut** (Ausschneiden).
1. Wählen Sie in der Ansicht **Dateisystem** die Schaltfläche neben dem Verzeichnis, in das Sie die Datei einfügen möchten.
1. Wählen Sie im Menü **Aktionen** **Einfügen**.
# Umbenennen von Betriebssystemdateien und -verzeichnissen mit Fleet Manager
Sie können Fleet Manager verwenden, um Dateien und Verzeichnisse auf einem verwalteten Knoten in Ihrem Konto umzubenennen.
**So können Sie Dateien oder Verzeichnisse mit Fleet Manager umbenennen**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens mit den Dateien oder Verzeichnissen, die Sie umbenennen möchten.
1. Wählen Sie **Tools, Dateisysteme**.
1. Um eine Datei umzubenennen, wählen Sie den **File name** (Dateiname) des Verzeichnisses, das die Datei enthält, die Sie umbenennen möchten. Um ein Verzeichnis umzubenennen, wählen Sie die Schaltfläche neben dem Verzeichnis, das Sie umbenennen möchten, und fahren Sie dann mit Schritt 8 fort.
1. Wählen Sie die Schaltfläche neben der Datei, deren Inhalt Sie umbenennen möchten.
1. Wählen Sie **Aktionen, Umbenennen**.
1. Geben Sie im Feld **Dateiname** den neuen Namen für die Datei ein und wählen Sie **Umbenennen**.
# Löschen von Betriebssystemdateien und -verzeichnissen mit Fleet Manager
Sie können Fleet Manager verwenden, um Dateien und Verzeichnisse auf einem verwalteten Knoten in Ihrem Konto zu löschen.
**So löschen Sie Dateien oder Verzeichnisse mithilfe von Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens mit den Dateien oder Verzeichnissen, die Sie löschen möchten.
1. Wählen Sie **Tools, Dateisysteme**.
1. Um eine Datei zu löschen, wählen Sie **File name** (Dateiname) des Verzeichnisses, das die Datei enthält, die Sie löschen möchten. Um ein Verzeichnis zu löschen, wählen Sie die Schaltfläche neben dem Verzeichnis, das Sie löschen möchten, und fahren Sie dann mit Schritt 7 fort.
1. Wählen Sie die Schaltfläche neben der Datei, deren Inhalt Sie löschen möchten.
1. Wählen Sie **Aktionen, Löschen**.
# Betriebssystemverzeichnisse erstellen mit Fleet Manager
Sie können Fleet Manager verwenden, um Dateien und Verzeichnisse auf einem verwalteten Knoten in Ihrem Konto zu erstellen.
**Erstellen eines Verzeichnisses mithilfe von Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens, in dem Sie ein Verzeichnis erstellen möchten.
1. Wählen Sie **Tools, Dateisysteme**.
1. Wählen Sie den **File name** (Dateiname) des Verzeichnisses, in dem Sie ein neues Verzeichnis erstellen möchten.
1. Wählen Sie **Create directory** (Verzeichnis erstellen).
1. Geben Sie im Feld **Verzeichnisname** den Namen für das neue Verzeichnis ein und wählen Sie **Verzeichnis erstellen**.
# Ausschneiden, Kopieren und Einfügen von Betriebssystemverzeichnissen mit Fleet Manager
Sie können Fleet Manager verwenden, um Verzeichnisse auf einem verwalteten Knoten in Ihrem Konto auszuschneiden, zu kopieren und einzufügen.
**So kopieren oder fügen Sie Verzeichnisse mit Fleet Manager ein**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens mit den Dateien, die Sie kopieren oder ausschneiden und einfügen möchten.
1. Wählen Sie **Tools, Dateisysteme**.
1. Wählen Sie die Schaltfläche neben dem Verzeichnis, das Sie kopieren oder ausschneiden möchten, und fahren Sie dann mit Schritt 8 fort.
1. Wählen Sie im Menü **Aktionen** **Kopieren** oder **Ausschneiden**.
1. Wählen Sie in der Ansicht **Dateisystem** die Schaltfläche neben dem Verzeichnis, in das Sie die Datei einfügen möchten.
1. Wählen Sie im Menü **Aktionen** **Einfügen**.
# Überwachung der Leistung verwalteter Knoten
Sie können ein Tool in verwenden Fleet Manager AWS Systems Manager, um Leistungsdaten zu Ihren verwalteten Knoten in Echtzeit anzuzeigen. Die Leistungsdaten werden von Leistungsindikatoren abgerufen.
Die folgenden Leistungsindikatoren sind in Fleet Manager verfügbar:
+ CPU-Auslastung
+ Festplattenauslastung input/output (I/O)
+ Netzwerkdatenverkehr
+ Speicherauslastung
**Anmerkung**
Fleet ManagerverwendetSession Manager, ein Tool in AWS Systems Manager, zum Abrufen von Leistungsdaten. Für Amazon Elastic Compute Cloud (Amazon EC2)-Instances muss das Instance-Profil, das Ihren verwalteten Instances angefügt ist, Berechtigungen für Session Manager bereitstellen, um diese Funktion zu verwenden. Weitere Informationen zum Hinzufügen von Session Manager-Berechtigungen an ein Instance-Profil finden Sie unter [Session Manager-Berechtigungen für eine vorhandene IAM-Rolle hinzufügen](getting-started-add-permissions-to-existing-profile.md).
**Anzeigen von Leistungsdaten mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, dessen Leistung Sie überwachen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Leistungsindikatoren**.
# Arbeiten mit Prozessen
Sie können Fleet Manager verwenden, ein Tool in AWS Systems Manager, um mit Prozessen auf Ihren verwalteten Knoten zu arbeiten. Mit Fleet Manager können Sie Informationen über Prozesse anzeigen. Beispielsweise können Sie zusätzlich zu ihren Handles und Threads die CPU-Auslastung und Speicherauslastung von Prozessen sehen. Mit Fleet Manager können Sie Prozesse von der Konsole aus starten und beenden.
**Anmerkung**
Fleet Manager verwendet Session Manager, ein Tool in AWS Systems Manager, um Prozessdaten abzurufen. Für Amazon Elastic Compute Cloud (Amazon EC2)-Instances muss das Instance-Profil, das Ihren verwalteten Instances angefügt ist, Berechtigungen für Session Manager bereitstellen, um diese Funktion zu verwenden. Weitere Informationen zum Hinzufügen von Session Manager-Berechtigungen an ein Instance-Profil finden Sie unter [Session Manager-Berechtigungen für eine vorhandene IAM-Rolle hinzufügen](getting-started-add-permissions-to-existing-profile.md).
**Topics**
+ [Anzeigen von Details zu Betriebssystemprozessen mithilfe von Fleet Manager](fleet-manager-view-process-details.md)
+ [Starten eines Betriebssystemprozesses auf einem verwalteten Knoten mit Fleet Manager](fleet-manager-start-process.md)
+ [Beenden eines Betriebssystemprozesses mit Fleet Manager](fleet-manager-terminate-process.md)
# Anzeigen von Details zu Betriebssystemprozessen mithilfe von Fleet Manager
Sie können Fleet Manager nutzen, um Details zu Prozessen auf Ihren verwalteten Knoten anzuzeigen.
**So zeigen Sie Details zu Prozessen mit Fleet Manager an**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung der Knoten aus, deren Prozesse Sie anzeigen möchten.
1. Wählen Sie **Tools, Prozesse**.
# Starten eines Betriebssystemprozesses auf einem verwalteten Knoten mit Fleet Manager
Sie können Fleet Manager verwenden, um einen Prozess auf einem verwalteten Knoten zu starten.
**So starten Sie einen Prozess mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens aus, auf dem Sie einen Prozess starten möchten.
1. Wählen Sie **Tools, Prozesse**.
1. Wählen Sie **Start new process** (Neuen Prozess starten).
1. Geben Sie im Feld **Prozessname oder vollständiger Pfad** den Namen des Prozesses oder den vollständigen Pfad zur ausführbaren Datei ein.
1. (Optional) Geben Sie im Feld **Arbeitsverzeichnis** den Verzeichnispfad ein, in dem der Prozess ausgeführt werden soll.
# Beenden eines Betriebssystemprozesses mit Fleet Manager
**So beenden Sie einen Betriebssystemprozess mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Verknüpfung des verwalteten Knotens aus, auf dem Sie einen Prozess starten möchten.
1. Wählen Sie **Tools, Prozesse**.
1. Wählen Sie die Schaltfläche neben dem Prozess, den Sie beenden möchten.
1. Wählen Sie **Aktionen, Prozess beenden** oder **Aktionen, Prozessstruktur beenden**.
**Anmerkung**
Durch das Beenden eines Prozessbaums werden auch alle Prozesse und Anwendungen beendet, die diesen Prozess verwenden.
# Protokolle auf verwalteten Knoten anzeigen
Sie können Fleet Manager verwenden, ein Tool in AWS Systems Manager, um Protokolldaten anzuzeigen, die auf Ihren verwalteten Knoten gespeichert sind. Bei Windows-verwalteten Knoten können Sie aus der Konsole Windows-Ereignisprotokolle anzeigen und ihre Details kopieren. Um Ihnen bei der Suche nach Ereignissen zu helfen, filtern Sie Windows-Ereignisprotokolle nach **Event level (Event-Ebene)**, **Event ID (Ereignis-ID)**, **Event source (Ereignisquelle)** und **Time created (Erstellungszeitpunkt)**. Sie können auch andere Protokolldaten mit dem Verfahren zum Anzeigen des Dateisystemen anzeigen. Weitere Informationen zum Anzeigen des Dateisystems mit Fleet Manager finden Sie unter [Arbeiten mit Betriebssystemdateisystemen mithilfe von Fleet Manager](fleet-manager-file-system-management.md).
**Anzeigen von Windows-Ereignisprotokolle mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, dessen Ereignisprotokolle Sie anzeigen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Windows-Ereignisprotokolle**.
1. Wählen Sie den **Log name (Protokollnamen)**, welcher die Ereignisse enthält, die Sie anzeigen möchten.
1. Wählen Sie die Schaltfläche neben dem **Log name (Protokollnamen)**, den Sie anzeigen möchten und wählen Sie dann **View events (Anzeigen von Ereignissen)**.
1. Wählen Sie die Schaltfläche neben dem Ereignis, das Sie anzeigen möchten und wählen Sie dann **View event details (Eventdetails anzeigen)**.
1. (Optional) Wählen Sie **Copy as JSON (Copy as JSON)**, um die Ereignisdetails in die Zwischenablage zu kopieren.
# Verwalten von Betriebssystembenutzerkonten und Gruppen auf verwalteten Knoten mithilfe von Fleet Manager
Sie könnenFleet Manager, ein Tool in AWS Systems Manager, verwenden, um Benutzerkonten und Gruppen des Betriebssystems (OS) auf Ihren verwalteten Knoten zu verwalten. Sie können beispielsweise Benutzer und Gruppen erstellen und löschen. Darüber hinaus können Sie Details wie Gruppenmitgliedschaft, Benutzerrollen und Status anzeigen.
**Wichtig**
Fleet Managerverwendet Run Command undSession Manager, Tools in AWS Systems Manager, für verschiedene Benutzerverwaltungsvorgänge. Daher könnte ein Benutzer einem Betriebssystembenutzerkonto Berechtigungen erteilen, die andernfalls nicht möglich wären. Das liegt daran, dass AWS Systems Manager Agent (SSM Agent) auf Amazon Elastic Compute Cloud (Amazon EC2) -Instances mit Root-Rechten (Linux) oder SYSTEM-Berechtigungen (Windows Server) ausgeführt wird. Weitere Informationen zum Einschränken des Zugriffs auf Befehle auf Root-Ebene über SSM Agent finden Sie unter [Einschränken des Zugriffs auf Befehle auf Stammebene durch SSM Agent](ssm-agent-restrict-root-level-commands.md). Um den Zugriff auf diese Funktion einzuschränken, empfehlen wir, AWS Identity and Access Management (IAM-) Richtlinien für Ihre Benutzer zu erstellen, die nur Zugriff auf die von Ihnen definierten Aktionen gewähren. Weitere Informationen zum Erstellen von IAM-Richtlinien für Fleet Manager finden Sie unter [Steuern des Zugriffs auf Fleet Manager](configuring-fleet-manager-permissions.md).
**Topics**
+ [Einen Betriebssystembenutzer oder eine Betriebssystemgruppe erstellen mit Fleet Manager](manage-os-user-accounts-create.md)
+ [Benutzer- oder Gruppenmitgliedschaft aktualisieren mit Fleet Manager](manage-os-user-accounts-update.md)
+ [Löschen eines Betriebssystembenutzers oder einer Betriebssystemgruppe mit Fleet Manager](manage-os-user-accounts-delete.md)
# Einen Betriebssystembenutzer oder eine Betriebssystemgruppe erstellen mit Fleet Manager
**Anmerkung**
Fleet Manager nutzt Session Manager, um Kennwörter für neue Benutzer festzulegen. Für Amazon-EC2-Instances muss das Instance-Profil, das Ihren verwalteten Instances angefügt ist, Berechtigungen für Session Manager bereitstellen, um dieses Feature zu verwenden. Weitere Informationen zum Hinzufügen von Session Manager-Berechtigungen an ein Instance-Profil finden Sie unter [Session Manager-Berechtigungen für eine vorhandene IAM-Rolle hinzufügen](getting-started-add-permissions-to-existing-profile.md).
Anstatt sich direkt bei einem Server anzumelden, um ein Benutzerkonto oder eine Gruppe zu erstellen, können Sie die Fleet Manager-Konsole verwenden, um dieselben Aufgaben auszuführen.
**So erstellen Sie ein BS-Benutzerkonto mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem Sie einen neuen Benutzer erstellen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Benutzer und Gruppen**.
1. Wählen Sie die Registerkarte **Users** und anschließend die Option **Create user (Benutzer erstellen)**.
1. Geben Sie einen Wert für den **Namen** des neuen Benutzers an.
1. (Empfohlen) Aktivieren Sie das Kontrollkästchen neben **Set password (Passwort festlegen)**. Am Ende des Verfahrens werden Sie aufgefordert, ein Passwort für den neuen Benutzer einzugeben.
1. Wählen Sie **Create user (Benutzer erstellen)**. Wenn Sie das Kontrollkästchen zum Erstellen eines Kennworts für den neuen Benutzer aktiviert haben, werden Sie aufgefordert, einen Wert für das Kennwort einzugeben und **Done (Fertig)** zu wählen. Wenn das angegebene Passwort die Anforderungen der lokalen oder Domain-Richtlinien Ihres verwalteten Knotens nicht erfüllt, wird ein Fehler zurückgegeben.
**So erstellen Sie eine OS-Gruppe mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem Sie eine Gruppe erstellen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Benutzer und Gruppen**.
1. Wählen Sie die Registerkarte **Groups (Gruppen)** und dann **Create group (Gruppe erstellen)** aus.
1. Geben Sie einen Wert für den **Namen** der neuen Gruppe an.
1. (Optional) Geben Sie einen Wert für die **Description (Beschreibung)** der neuen Gruppe ein.
1. (Optional) Wählen Sie die Benutzer aus, die zu den **Group members (Gruppenmitgliedern)** hinzugefügt werden sollen.
1. Wählen Sie **Create group (Gruppe erstellen)**.
# Benutzer- oder Gruppenmitgliedschaft aktualisieren mit Fleet Manager
Anstatt sich direkt bei einem Server anzumelden, um ein Benutzerkonto oder eine Gruppe zu aktualisieren, können Sie die Fleet Manager-Konsole verwenden, um dieselben Aufgaben auszuführen.
**So fügen Sie ein Betriebssystem-Benutzerkonto zu einer neuen Gruppe mit Fleet Manager hinzu**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem sich das Benutzerkonto befindet, das Sie aktualisieren möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Benutzer und Gruppen**.
1. Wählen Sie die Registerkarte **Users**.
1. Wählen Sie die Schaltfläche neben dem Benutzer, den Sie aktualisieren möchten.
1. Wählen Sie **Aktionen, Benutzer zu Gruppe hinzufügen**.
1. Wählen Sie unter **Add to group (Zur Gruppe hinzufügen)** die Gruppe aus, zu der Sie den Benutzer hinzufügen möchten.
1. Wählen Sie **Add user to group (Benutzer zur Gruppe hinzufügen)**.
**So bearbeiten Sie die Mitgliedschaft einer Betriebssystemgruppe mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem sich die Gruppe befindet, die Sie aktualisieren möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Benutzer und Gruppen**.
1. Wählen Sie die Registerkarte **Groups (Gruppen)**.
1. Wählen Sie die Schaltfläche neben der Gruppe, die Sie aktualisieren möchten.
1. Wählen Sie **Aktionen, Gruppe ändern**.
1. Wählen Sie unter **Gruppenmitglieder** die Benutzer aus, die Sie hinzufügen oder entfernen möchten.
1. Wählen Sie ** Modify group (Gruppe ändern)**.
# Löschen eines Betriebssystembenutzers oder einer Betriebssystemgruppe mit Fleet Manager
Anstatt sich direkt bei einem Server anzumelden, um ein Benutzerkonto oder eine Gruppe zu löschen, können Sie die Fleet Manager-Konsole verwenden, um dieselben Aufgaben auszuführen.
**So löschen Sie Betriebssystem-Benutzerkonten mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem sich das Benutzerkonto befindet, das Sie löschen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Benutzer und Gruppen**.
1. Wählen Sie die Registerkarte **Users**.
1. Wählen Sie die Schaltfläche neben dem Benutzer, dem Sie löschen möchten.
1. Wählen Sie **Aktionen, Lokalen Benutzer löschen**.
**So löschen Sie eine Betriebssystemgruppe mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem sich die Gruppe befindet, die Sie löschen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Benutzer und Gruppen**.
1. Wählen Sie die Registerkarte **Group (Gruppe)**.
1. Wählen Sie die Schaltfläche neben der Gruppe, die Sie aktualisieren möchten.
1. Wählen Sie **Aktionen, Lokale Gruppe löschen**.
# Verwalten der Windows-Registrierung auf verwalteten Knoten
Sie könnenFleet Manager, ein Tool in, verwenden AWS Systems Manager, um die Registrierung auf Ihren Windows Server verwalteten Knoten zu verwalten. Von der Fleet Manager-Konsole können Sie Registrierungseinträge und -werte erstellen, kopieren, aktualisieren und löschen.
**Wichtig**
Wir empfehlen, ein Backup der Registry oder einen Snapshot des Amazon Elastic Block Store (Amazon EBS)-Root-Volume zu erstellen, das Ihrem verwalteten Knoten angefügt ist, bevor Sie die Registry ändern. Schwerwiegende Probleme können auftreten, wenn Sie eine falsche Änderung in der Registrierung vornehmen. Bei diesen Problemen müssen Sie möglicherweise das Betriebssystem neu installieren oder das Root-Volume Ihres Knotens anhand eines Snapshots wiederherstellen. AWS garantiert nicht, dass diese Probleme gelöst werden können. Ändern Sie die Registrierung auf eigenes Risiko. Sie sind für alle Registrierungsänderungen verantwortlich und stellen sicher, dass Sie Backups haben.
## Erstellen eines Windows-Registrierungsschlüssels oder -Eintrags
**Erstellen eines Windows-Registrierungsschlüssel mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem Sie einen Registry-Schlüssel erstellen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Windows Registry**.
1. Wählen Sie den Hive aus, in dem Sie einen neuen Registrierungsschlüssel erstellen möchten, indem Sie den **Registry name** (Registry-Name) wählen.
1. Wählen Sie **Registrierungsschlüssel erstellen**.
1. Wählen Sie die Schaltfläche neben dem Registrierungseintrag, in dem Sie einen Schlüssel erstellen möchten.
1. Wählen Sie **Create registry key** (Registry-Schlüssel erstellen).
1. Geben Sie einen Wert für den **Namen** des neuen Registrierungsschlüssels ein und wählen Sie **Submit (Senden)**
**Erstellen eines Windows-Registrierungseintrags mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben der Instance, in der Sie einen Registrierungseintrag erstellen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Windows Registry**.
1. Wählen Sie den Hive und den darauffolgenden Registrierungsschlüssel aus, in dem Sie einen neuen Registrierungseintrag erstellen möchten, indem Sie den **Registry name** (Registry-Name) wählen.
1. Wählen Sie **Erstellen, Registrierungseintrag erstellen**.
1. Geben Sie einen Wert für den **Namen** des neuen Registrierungseintrags ein.
1. Wählen Sie den **Typ** des Wertes, den Sie für den Registrierungseintrag erstellen möchten. Weitere Informationen zu Registry-Werttypen finden Sie unter [Registry value types](https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-value-types) (Registry-Wertetypen).
1. Geben Sie einen Wert für den **Value (Wert)** des neuen Registrierungseintrags ein.
## Aktualisieren eines Windows-Registrierungseintrags
**Aktualisieren eines Windows-Registrierungseintrags mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem Sie einen Registry-Eintrag aktualisieren möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Windows Registry**.
1. Wählen Sie den Hive und den nachfolgenden Registrierungsschlüssel aus, den Sie aktualisieren möchten, indem Sie das Kontrollkästchen **Registry name** (Registry-Name) anklicken.
1. Wählen Sie die Schaltfläche neben dem Registrierungseintrag aus, den Sie aktualisieren möchten.
1. Wählen Sie **Aktionen, Registrierungseintrag aktualisieren**.
1. Geben Sie den neuen Wert für den **Value (Wert)** des Registrierungseintrags ein.
1. Wählen Sie **Aktualisieren** aus.
## Löschen eines Windows-Registrierungseintrags oder -schlüssels
**Erstellen eines Windows-Registrierungsschlüssel mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem Sie einen Registry-Schlüssel löschen möchten.
1. Wählen Sie **Tools, Windows Registry**.
1. Wählen Sie den Hive und den nachfolgenden Registrierungsschlüssel aus, den Sie löschen möchten, indem Sie das Kontrollkästchen **Registry name** (Registry-Name) anklicken.
1. Wählen Sie die Schaltfläche neben dem Registrierungsschlüssel, den Sie löschen möchten
1. Wählen Sie **Aktionen, Registrierungsschlüssel löschen**.
**Löschen eines Windows-Registrierungseintrags mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben dem verwalteten Knoten, auf dem Sie einen Registry-Eintrag löschen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, Windows Registry**.
1. Wählen Sie den Hive und den nachfolgenden Registrierungsschlüssel, der den Eintrag enthält, aus, den Sie löschen möchten, indem Sie das Kontrollkästchen **Registry name** (Registry-Name) anklicken.
1. Wählen Sie die Schaltfläche neben dem Registrierungseintrag, den Sie löschen möchten
1. Wählen Sie **Aktionen, Registrierungseintrag löschen**.
# Automatisches Verwalten von EC2-Instances mit der Standard-Host-Management-Konfiguration
Mit der Einstellung Standard-Host-Management-Konfiguration können AWS Systems Manager Sie Ihre Amazon EC2 EC2-Instances automatisch als *verwaltete Instances* verwalten. Eine verwaltete Instance ist eine EC2-Instance, die für die Verwendung mit Systems Manager konfiguriert ist.
Die Verwaltung Ihrer Instances mit Systems Manager bietet unter anderem folgende Vorteile:
+ Stellen Sie mit Session Manager eine sichere Verbindung zu Ihren EC2-Instances her.
+ Führen Sie automatisierte Patch-Scans mit Patch Manager durch.
+ Zeigen Sie mit Systems Manager Inventory detaillierte Informationen zu Ihren Instances an.
+ Verfolgen und verwalten Sie Instances mithilfe von Fleet Manager.
+ Halten Sie SSM Agent automatisch auf dem neuesten Stand.
*Fleet Manager, Inventory, Patch Manager und Session Manager sind Tools in Systems Manager.*
Mit der Standard-Host-Management-Konfiguration können Sie EC2-Instances verwalten, ohne manuell ein AWS Identity and Access Management (IAM-) Instance-Profil erstellen zu müssen. Stattdessen erstellt und wendet die Standard-Host-Management-Konfiguration eine Standard-IAM-Rolle an, um sicherzustellen, dass Systems Manager über Berechtigungen zur Verwaltung aller Instances in der AWS-Konto und an der AWS-Region Stelle verfügt, an der sie aktiviert ist.
Wenn die bereitgestellten Berechtigungen für Ihren Anwendungsfall nicht ausreichen, können Sie auch Richtlinien zur Standard-IAM-Rolle hinzufügen, die von der Standardkonfiguration für die Host-Verwaltung erstellt wird. Wenn Sie keine Berechtigungen für alle Funktionen benötigen, die von der Standard-IAM-Rolle bereitgestellt werden, können Sie alternativ Ihre eigene benutzerdefinierte Rolle und Richtlinien erstellen. Alle Änderungen an der IAM-Rolle, die Sie für die Standardkonfiguration für die Host-Verwaltung auswählen, gelten für alle verwalteten Amazon-EC2-Instances in der Region und im Konto.
Weitere Informationen zu der Richtlinie, die von der Standardkonfiguration für die Host-Verwaltung verwendet wird, finden Sie unter [AWS verwaltete Richtlinie: Amazon SSMManaged EC2 InstanceDefaultPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonSSMManagedEC2InstanceDefaultPolicy).
**Implementieren des Zugriffs mit geringsten Berechtigungen**
Die in diesem Thema beschriebenen Verfahren sollten nur von Administratoren durchgeführt werden. Daher empfehlen wir, *Zugriff mit den geringsten Berechtigungen* zu implementieren, um zu verhindern, dass nichtadministrative Benutzer die Standardkonfiguration für die Host-Verwaltung konfigurieren oder ändern. Beispielrichtlinien, die den Zugriff auf die Standardkonfiguration für die Host-Verwaltung einschränken, finden Sie unter [Beispiele für Richtlinien mit den geringsten Berechtigungen für die Standardkonfiguration für die Host-Verwaltung](#least-privilege-examples) weiter unten in diesem Thema.
**Wichtig**
Registrierungsinformationen für Instances, die mit der Standardkonfiguration für die Host-Verwaltung registriert wurden, speichern Registrierungsinformationen lokal in den Verzeichnissen `var/lib/amazon/ssm` oder `C:\ProgramData\Amazon`. Das Entfernen dieser Verzeichnisse oder der enthaltenen Dateien verhindert, dass die Instance die erforderlichen Anmeldeinformationen für die Verbindung mit Systems Manager über die Standardkonfiguration für die Host-Verwaltung erhält. In diesen Fällen müssen Sie ein Instance-Profil verwenden, um Ihrer IAM-Instance die erforderlichen Berechtigungen zu erteilen, oder die Instance neu erstellen.
**Topics**
+ [Voraussetzungen](#dhmc-prerequisites)
+ [Die Umgebung der Standardkonfiguration für die Host-Verwaltung aktivieren](#dhmc-activate)
+ [Die Umgebung der Standardkonfiguration für die Host-Verwaltung deaktivieren](#dhmc-deactivate)
+ [Beispiele für Richtlinien mit den geringsten Berechtigungen für die Standardkonfiguration für die Host-Verwaltung](#least-privilege-examples)
## Voraussetzungen
Um die Standard-Host-Management-Konfiguration in der AWS-Region und an der AWS-Konto Stelle zu verwenden, an der Sie die Einstellung aktivieren, müssen die folgenden Anforderungen erfüllt sein.
+ Eine zu verwaltende Instanz muss den Instanz-Metadatendienst Version 2 (IMDSv2) verwenden.
Die Standardkonfiguration für die Host-Verwaltung unterstützt die Instance-Metadaten-Service-Version 1 nicht. Informationen zur Umstellung auf IMDSv2 Version 2 finden Sie unter [Übergang zur Verwendung von Instance Metadata Service Version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) im *Amazon EC2 EC2-Benutzerhandbuch*
+ SSM Agent-Version 3.2.582.0 oder höher muss auf der zu verwaltenden Instance installiert sein.
Informationen zur Überprüfung der auf Ihrer Instance installierten Version von SSM Agent finden Sie unter [Überprüfen der SSM Agent-Versionsnummer](ssm-agent-get-version.md).
Weitere Informationen zur Aktualisierung von SSM Agent finden Sie unter [Automatische Aktualisierung von SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console).
+ Sie als Administrator, der die Aufgaben in diesem Thema ausführt, benötigen Berechtigungen für die [GetServiceSetting[UpdateServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateServiceSetting.html)](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetServiceSetting.html)API-Operationen [ResetServiceSetting](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_ResetServiceSetting.html), und. Darüber hinaus müssen Sie über Berechtigungen für die `iam:PassRole`-Berechtigung für die `AWSSystemsManagerDefaultEC2InstanceManagementRole`-IAM-Rolle verfügen. Im Folgenden finden Sie ein Beispiel für eine Richtlinie, die diese Berechtigungen vorsieht. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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"
]
}
}
}
]
}
```
------
+ Wenn ein IAM-Instance-Profil bereits mit einer mit Systems Manager zu verwaltenden EC2 Instance verknüpft ist, müssen Sie alle Berechtigungen entfernen, die die `ssm:UpdateInstanceInformation`-Operation zulassen. SSM Agent versucht, die Berechtigungen des Instance-Profils zu verwenden, bevor Sie die Berechtigungen der Standardkonfiguration für die Host-Verwaltung verwenden. Wenn Sie die `ssm:UpdateInstanceInformation`-Operation in Ihrem eigenen IAM-Instance-Profil zulassen, wird die Instance die Berechtigungen der Standardkonfiguration für die Host-Verwaltung nicht verwenden.
## Die Umgebung der Standardkonfiguration für die Host-Verwaltung aktivieren
Sie können die Standard-Host-Management-Konfiguration von der Fleet Manager Konsole aus oder mithilfe von AWS Command Line Interface oder aktivieren AWS Tools for Windows PowerShell.
Sie müssen die Standardkonfiguration für die Hostverwaltung einzeln in jeder Region aktivieren, in der Ihre Amazon-EC2-Instances mit dieser Einstellung verwaltet werden sollen.
Nachdem Sie die Standardkonfiguration für die Hostverwaltung aktiviert haben, kann es bis zu 30 Minuten dauern, bis Ihre Instances die Anmeldeinformationen der Rolle verwenden, die Sie im folgenden Verfahren in Schritt 5 ausgewählt haben.
**So aktivieren Sie die Standardkonfiguration für die Host-Verwaltung (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie im **Kontoverwaltung, Standardkonfiguration für die Host-Verwaltung konfigurieren**.
1. Aktivieren Sie **Standardkonfiguration für die Host-Verwaltung aktivieren**.
1. Wählen Sie die AWS Identity and Access Management (IAM) -Rolle aus, die verwendet wird, um die Systems Manager Manager-Tools für Ihre Instances zu aktivieren. Wir empfehlen die Verwendung der Standardrolle, die in der Standardkonfiguration für die Host-Verwaltung bereitgestellt wird. Sie enthält die Mindestberechtigungen für die Verwaltung Ihrer Amazon-EC2-Instances mit Systems Manager. Wenn Sie es vorziehen, eine benutzerdefinierte Rolle zu verwenden, muss die Vertrauensrichtlinie der Rolle Systems Manager als vertrauenswürdige Entität zulassen.
1. Wählen Sie **Konfigurieren**, um die Einrichtung abzuschließen.
**So aktivieren Sie die Standardkonfiguration für die Host-Verwaltung (Befehlszeile)**
1. Erstellen Sie auf Ihrem lokalen Computer eine JSON-Datei, die die folgende Vertrauensbeziehungsrichtlinie enthält.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"",
"Effect":"Allow",
"Principal":{
"Service":"ssm.amazonaws.com"
},
"Action":"sts:AssumeRole"
}
]
}
```
------
1. Öffnen Sie AWS CLI oder Tools für Windows PowerShell und führen Sie je nach Betriebssystemtyp Ihres lokalen Computers einen der folgenden Befehle aus, um eine Servicerolle in Ihrem Konto zu erstellen. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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. Führen Sie den folgenden Befehl aus, um Ihrer neu erstellten Rolle die von `AmazonSSMManagedEC2InstanceDefaultPolicy` verwaltete Richtlinie anzufügen. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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. Öffnen Sie AWS CLI oder Tools für Windows PowerShell und führen Sie den folgenden Befehl aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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"
```
------
Wenn der Befehl erfolgreich ausgeführt wurde, gibt es keine Ausgabe.
1. Führen Sie den folgenden Befehl aus, um die aktuellen Diensteinstellungen für die Standard-Hostverwaltungskonfiguration im aktuellen AWS-Konto und anzuzeigen AWS-Region.
------
#### [ 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"
```
------
Der Befehl gibt Informationen wie die folgenden zurück.
```
{
"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"
}
}
```
## Die Umgebung der Standardkonfiguration für die Host-Verwaltung deaktivieren
Sie können die Standard-Host-Management-Konfiguration von der Fleet Manager Konsole aus oder mithilfe von AWS Command Line Interface oder deaktivieren AWS Tools for Windows PowerShell.
Sie müssen die Einstellung Standardmäßige Hostverwaltungskonfiguration nacheinander in jeder Region deaktivieren, in der Ihre Amazon-EC2-Instances nicht mehr von dieser Konfiguration verwaltet werden sollen. Wenn Sie sie in einer Region deaktivieren, wird sie nicht in allen Regionen deaktiviert.
Wenn Sie die Standardkonfiguration für die Host-Verwaltung ausschalten und Ihren Amazon-EC2-Instances kein Instance-Profil zugeordnet haben, das den Zugriff auf Systems Manager ermöglicht, werden diese nicht mehr von Systems Manager verwaltet.
**So deaktivieren Sie die Standardkonfiguration für die Host-Verwaltung (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie im **Kontoverwaltung, Standardkonfiguration für die Host-Verwaltung**.
1. Deaktivieren Sie **Einstellung der Standardkonfiguration für die Host-Verwaltung aktivieren**.
1. Wählen Sie **Konfigurieren**, um die Standardkonfiguration für die Host-Verwaltung zu deaktivieren.
**So deaktivieren Sie die Standardkonfiguration für die Host-Verwaltung (Befehlszeile)**
+ Öffnen Sie AWS CLI oder Tools für Windows PowerShell und führen Sie den folgenden Befehl aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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"
```
------
## Beispiele für Richtlinien mit den geringsten Berechtigungen für die Standardkonfiguration für die Host-Verwaltung
Die folgenden Beispielrichtlinien zeigen, wie Sie verhindern können, dass Mitglieder Ihrer Organisation Änderungen an der Standardkonfiguration für die Host-Verwaltung in Ihrem Konto vornehmen.
### Richtlinie zur Dienststeuerung für AWS Organizations
Die folgende Richtlinie zeigt, wie Sie verhindern können, dass Mitglieder, die keine Administratorrechte haben, Ihre AWS Organizations Einstellung für die Standard-Host-Management-Konfiguration aktualisieren. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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"
]
}
}
}
]
}
```
------
### Richtlinie für IAM-Prinzipale
Die folgende Richtlinie zeigt, wie Sie verhindern können, dass IAM-Gruppen, -Rollen oder Benutzer in AWS Organizations Ihrem Unternehmen Ihre Einstellung für die Standard-Host-Management-Konfiguration aktualisieren. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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"
}
]
}
```
------
# Eine Verbindung zu einer von Windows Server verwalteten Instance mit Remote Desktop herstellen
Sie könnenFleet Manager, ein Tool in, verwenden AWS Systems Manager, um mithilfe von (RDP) eine Verbindung zu Ihren Windows Server Amazon Elastic Compute Cloud (Amazon EC2) -Instances herzustellen. Remote Desktop Protocol Fleet Manager Remote Desktop, das von [Amazon DCV](https://docs.aws.amazon.com/dcv/latest/adminguide/what-is-dcv.html) unterstützt wird, bietet Ihnen eine sichere Verbindung zu Ihren Windows Server-Instances direkt von der Systems-Manager-Konsole aus. Sie können bis zu vier gleichzeitige Verbindungen in einem einzigen Browserfenster haben.
Die Fleet Manager Remote Desktop API trägt den Namen AWS Systems Manager GUI Connect. Informationen zur Verwendung der GUI Connect API in Systems Manager finden Sie in der *[API-Referenz für AWS Systems Manager GUI Connect](https://docs.aws.amazon.com/ssm-guiconnect/latest/APIReference)*.
Sie können Remote Desktop nur mit Instances verwenden, auf denen Windows Server 2012 RTM oder höher ausgeführt wird. Remote Desktop unterstützt nur englischsprachige Eingaben.
Fleet Manager Remote Desktop ist ein Service, der nur für Konsolen verfügbar ist und keine Befehlszeilenverbindungen zu Ihren verwalteten Instances unterstützt. Um über eine Shell eine Verbindung zu einer von Windows Server verwalteten Instance herzustellen, können Sie Session Manager verwenden, ein weiteres Tool in AWS Systems Manager. Weitere Informationen finden Sie unter [AWS Systems Manager Session Manager](session-manager.md).
**Anmerkung**
Die Dauer einer RDP-Verbindung wird nicht durch die Dauer Ihrer AWS Identity and Access Management (IAM)-Anmeldeinformationen bestimmt. Die Verbindung bleibt bestehen, bis die maximale Verbindungsdauer oder das Leerlaufzeitlimit erreicht ist, je nachdem, was zuerst eintritt. Weitere Informationen finden Sie unter [Dauer und Gleichzeitigkeit der Remoteverbindung](#rdp-duration-concurrency).
Informationen zur Konfiguration von AWS Identity and Access Management (IAM) -Berechtigungen, damit Ihre Instances mit Systems Manager interagieren können, finden [Sie unter Instanzberechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md).
**Topics**
+ [Einrichten Ihrer Umgebung](#rdp-prerequisites)
+ [Konfiguration von IAM-Berechtigungen für Remote Desktop](#rdp-iam-policy-examples)
+ [Authentifizierung von Remote-Desktop-Verbindungen](#rdp-authentication)
+ [Dauer und Gleichzeitigkeit der Remoteverbindung](#rdp-duration-concurrency)
+ [Systems Manager GUI Connect, Umgang mit AWS IAM Identity Center Attributen](#iam-identity-center-attribute-handling)
+ [Verbindung zu einem verwalteten Knoten über Remote Desktop](#rdp-connect-to-node)
+ [Anzeigen von Informationen über aktuelle und abgeschlossene Verbindungen](#list-connections)
## Einrichten Ihrer Umgebung
Vergewissern Sie sich vor der Verwendung von Remote Desktop, dass Ihre Umgebung die folgenden Anforderungen erfüllt:
+ **Konfiguration von verwalteten Knoten**
Stellen Sie sicher, dass Ihre Amazon-EC2-Instances als [verwaltete Knoten](fleet-manager-managed-nodes.md) in Systems Manager konfiguriert sind.
+ **SSM Agent-Mindestversion**
Stellen Sie sicher, dass auf den Knoten SSM Agent-Version 3.0.222.0 oder höher ausgeführt wird. Hinweise dazu, wie Sie überprüfen können, welche Agentenversion auf einem Knoten läuft, finden Sie unter [Überprüfen der SSM Agent-Versionsnummer](ssm-agent-get-version.md). Informationen über das Installieren oder Aktualisieren von SSM Agent finden Sie unter [Arbeiten mit SSM Agent](ssm-agent.md).
+ **Konfiguration des RDP-Ports**
Um Remote-Verbindungen zu akzeptieren, muss der Remote Desktop Services-Service auf Ihren Windows Server-Knoten den Standard-RDP-Port 3389 verwenden. Dies ist die Standardkonfiguration von AWS on Amazon Machine Images (AMIs). Sie müssen nicht explizit irgendwelche eingehenden Ports öffnen, um Remote Desktop zu verwenden.
+ **PSReadLine-Modulversion für Tastaturfunktionen**
Um sicherzustellen, dass Ihre Tastatur in PowerShell ordnungsgemäß funktioniert, stellen Sie sicher, dass auf den Knoten, auf denen Windows Server-2022 läuft, die PSReadLine-Modulversion 2.2.2 oder höher installiert ist. Wenn sie eine ältere Version verwenden, können Sie die erforderliche Version mit den folgenden Befehlen installieren.
```
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
```
Führen Sie nach der Installation des NuGet Paketanbieters den folgenden Befehl aus.
```
Install-Module `
-Name PSReadLine `
-Repository PSGallery `
-MinimumVersion 2.2.2 -Force
```
+ **Session-Manager-Konfiguration**
Bevor Sie Remote Desktop verwenden können, müssen Sie die Voraussetzungen für die Einrichtung von Session Manager erfüllen. Wenn Sie über Remote Desktop eine Verbindung zu einer Instanz herstellen, AWS-Region werden alle für Sie AWS-Konto definierten Sitzungseinstellungen angewendet. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
**Anmerkung**
Wenn Sie die Aktivitäten von Session Manager mit Amazon Simple Storage Service (Amazon S3) protokollieren, dann erzeugen Ihre Remotedesktop-Verbindungen den folgenden Fehler in `bucket_name/Port/stderr`. Dieser Fehler ist ein erwartetes Verhalten und kann ignoriert werden.
```
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
```
## Konfiguration von IAM-Berechtigungen für Remote Desktop
Zusätzlich zu den erforderlichen IAM-Berechtigungen für Systems Manager und Session Manager, muss der Benutzer oder die Rolle, die Sie verwenden, über Berechtigungen zum Initiieren von Verbindungen verfügen.
**Berechtigungen für das Initiieren von Verbindungen**
Um RDP-Verbindungen zu EC2-Instances in der Konsole herzustellen, sind die folgenden Berechtigungen erforderlich:
+ `ssm-guiconnect:CancelConnection`
+ `ssm-guiconnect:GetConnection`
+ `ssm-guiconnect:StartConnection`
**Berechtigungen zum Auflisten von Verbindungen**
Um Verbindungslisten in der Konsole anzuzeigen, ist die folgende Berechtigung erforderlich:
`ssm-guiconnect:ListConnections`
Im Folgenden finden Sie Beispiele für IAM-Richtlinien, die Sie einem Benutzer oder einer Rolle zuordnen können, um verschiedene Arten der Interaktion mit Remote Desktop zu erlauben. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
### Standardrichtlinie für die Verbindung mit EC2-Instances
------
#### [ 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": "*"
}
]
}
```
------
### Richtlinie für die Verbindung mit EC2-Instances mit bestimmten Tags
**Anmerkung**
In der folgenden IAM-Richtlinie benötigt der `SSMStartSession`-Abschnitt einen Amazon-Ressourcennamen (ARN) für die Aktion `ssm:StartSession`. Wie gezeigt, benötigt der von Ihnen angegebene ARN *keine* AWS-Konto ID. Wenn Sie eine Konto-ID angeben, gibt Fleet Manager `AccessDeniedException` zurückgegeben.
Der `AccessTaggedInstances` Abschnitt, der sich weiter unten in der Beispielrichtlinie befindet, erfordert ebenfalls ARNs für`ssm:StartSession`. Für diese ARNs geben Sie an AWS-Konto IDs.
------
#### [ 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": "*"
}
]
}
```
------
### Richtlinie für AWS IAM Identity Center Benutzer, um eine Verbindung zu EC2-Instances herzustellen
------
#### [ 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": "*"
}
]
}
```
------
## Authentifizierung von Remote-Desktop-Verbindungen
Wenn Sie eine Remote-Verbindung herstellen, können Sie sich mit Windows-Anmeldeinformationen oder dem Amazon-EC2-Schlüsselpaar (`.pem`-Datei) authentifizieren, das der Instance zugeordnet ist. Weitere Informationen zur Verwendung von Schlüsselpaaren finden Sie unter [Amazon-EC2-Schlüsselpaare und Windows-Instances](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html) im *Amazon-EC2-Benutzerhandbuch*.
Wenn Sie für die AWS-Managementkonsole Nutzung authentifiziert sind, können Sie alternativ eine Verbindung zu Ihren Instances herstellen AWS IAM Identity Center, ohne zusätzliche Anmeldeinformationen angeben zu müssen. Ein Beispiel für eine Richtlinie, die die Authentifizierung von Fernverbindungen mit IAM Identity Center erlaubt, finden Sie unter [Konfiguration von IAM-Berechtigungen für Remote Desktop](#rdp-iam-policy-examples).
**Bevor Sie beginnen**
Beachten Sie die folgenden Bedingungen für die Verwendung der IAM Identity Center-Authentifizierung, bevor Sie eine Verbindung über Remote Desktop herstellen.
+ Remote Desktop unterstützt die IAM Identity Center-Authentifizierung für Knoten in derselben AWS-Region , in der Sie IAM Identity Center aktiviert haben.
+ Remote Desktop unterstützt IAM Identity Center-Benutzernamen mit bis zu 16 Zeichen.
+ Remote Desktop unterstützt IAM Identity Center-Benutzernamen, die aus alphanumerischen Zeichen und den folgenden Sonderzeichen bestehen: `.` `-` `_`
**Wichtig**
Für IAM-Identity-Center-Benutzernamen, die die folgenden Zeichen enthalten, können keine Verbindungen hergestellt werden: `+` `=` `,`
IAM Identity Center unterstützt diese Zeichen in Benutzernamen, Fleet Manager-RDP-Verbindungen jedoch nicht.
Wenn darüber hinaus ein IAM-Identity-Center-Benutzername ein oder mehrere `@`-Symbole enthält, ignoriert Fleet Manager das erste `@`-Symbol und alle darauf folgenden Zeichen, unabhängig davon, ob das `@` den Domainteil einer E-Mail-Adresse einleitet oder nicht. Für den IAM Identity Center-Benutzernamen `diego_ramirez@example.com` wird der `@example.com`-Teil beispielsweise ignoriert und der Benutzername für Fleet Manager wird `diego_ramirez`. Für `diego_r@mirez@example.com` ignoriert Fleet Manager `@mirez@example.com` und der Benutzername für Fleet Manager wird `diego_r`.
+ Wenn eine Verbindung mit IAM Identity Center authentifiziert wird, erstellt Remote Desktop einen lokalen Windows-Benutzer in der Gruppe Lokale Administratoren der Instance. Dieser Benutzer bleibt bestehen, nachdem die Remoteverbindung beendet wurde.
+ Remote Desktop erlaubt keine IAM Identity Center-Authentifizierung für Knoten, die Microsoft Active Directory-Domain-Controller sind.
+ Obwohl Remote Desktop die Verwendung der IAM Identity Center-Authentifizierung für Knoten, die einer Active Directory-Domain *angeschlossen* sind, ermöglicht, raten wir davon ab, dies zu tun. Diese Authentifizierungsmethode gewährt Benutzern administrative Berechtigungen, die restriktivere, von der Domain gewährte Berechtigungen außer Kraft setzen können.
**Unterstützte Regionen für die IAM Identity Center-Authentifizierung**
Remote Desktop-Verbindungen, die die IAM Identity Center-Authentifizierung verwenden, werden in den folgenden AWS-Regionen unterstützt:
+ USA Ost (Ohio): (us-east-2)
+ USA Ost (Nord-Virginia): (us-east-1)
+ USA West (Nordkalifornien) (us-west-1)
+ USA West (Oregon): (us-west-2)
+ Afrika (Kapstadt) (af-south-1)
+ Asien-Pazifik (Hongkong) (ap-east-1)
+ Asien-Pazifik (Mumbai): (ap-south-1)
+ Asien-Pazifik (Tokyo) (ap-northeast-1)
+ Asien-Pazifik (Seoul): (ap-northeast-2)
+ Asien-Pazifik (Osaka) (ap-northeast-3)
+ Asien-Pazifik (Singapur): (ap-southeast-1)
+ Asien-Pazifik (Sydney): (ap-southeast-2)
+ Asien-Pazifik (Jakarta) (ap-southeast-3)
+ Kanada (Zentral): (ca-central-1)
+ Europa (Frankfurt) (eu-central-1)
+ Europa (Stockholm) (eu-north-1)
+ Europa (Irland) (eu-west-1)
+ Europa (London) (eu-west-2)
+ Europa (Paris) (eu-west-3)
+ Israel (Tel Aviv) (il-central-1)
+ Südamerika (São Paulo) (sa-east-1)
+ Europa (Mailand) (eu-south-1)
+ Naher Osten (Bahrain) (me-south-1)
+ AWS GovCloud (US-Ost) (us-gov-east-1)
+ AWS GovCloud (US-West) (us-gov-west-1)
## Dauer und Gleichzeitigkeit der Remoteverbindung
Die folgenden Bedingungen gelten für aktive Remote-Desktop-Verbindungen:
+ **Verbindungsdauer**
Standardmäßig wird eine Remote-Desktop-Verbindung nach 60 Minuten getrennt. Um zu verhindern, dass eine Verbindung getrennt wird, können Sie die Option **Sitzung erneuern** wählen, bevor sie getrennt wird, um den Timer für die Verbindungsdauer zurückzusetzen.
+ **Verbindungstimeout**
Eine Remote-Desktop-Verbindung wird getrennt, nachdem sie länger als 10 Minuten inaktiv war.
+ **Verbindungspersistenz**
Nachdem Sie mit Remote Desktop eine Verbindung zu Windows Server hergestellt haben, bleibt die Verbindung bestehen, bis die maximale Verbindungsdauer (60 Minuten) oder das Leerlaufzeitlimit (10 Minuten) erreicht ist. Die Verbindungsdauer wird nicht durch die Dauer Ihrer AWS Identity and Access Management (IAM-) Anmeldeinformationen bestimmt. Die Verbindung bleibt auch nach Ablauf der IAM-Anmeldeinformationen bestehen, bis die maximale Verbindungsdauer erreicht wird. Wenn Sie Remote Desktop verwenden, sollten Sie Ihre Verbindung nach Ablauf Ihrer IAM-Anmeldeinformationen beenden, indem Sie die Browserseite verlassen.
+ **Gleichzeitige Verbindungen**
Standardmäßig können Sie für dasselbe und maximal 5 aktive Remotedesktopverbindungen gleichzeitig AWS-Konto haben. AWS-Region Informationen zum Beantragen einer Erhöhung der Service Quotas um bis zu 50 gleichzeitige Verbindungen finden Sie unter [Eine Erhöhung der *Kontingente beantragen im Benutzerhandbuch für Servicekontingenten*](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html).
**Anmerkung**
Die Standardlizenz für Windows Server ermöglicht zwei gleichzeitige RDP-Verbindungen. Um mehr Verbindungen zu unterstützen, müssen Sie zusätzliche Clientzugriffslizenzen (CALs) von Microsoft oder Microsoft Remote Desktop Services-Lizenzen von erwerben AWS. Weitere Informationen zu zusätzlichen Lizenzen finden Sie in den folgenden Themen:
[Clientzugriffslizenzen und Verwaltungslizenzen](https://www.microsoft.com/en-us/licensing/product-licensing/client-access-license) auf der Microsoft-Website
[Verwenden benutzerbasierter License-Manager-Abonnements für unterstützte Softwareprodukte](https://docs.aws.amazon.com/license-manager/latest/userguide/user-based-subscriptions.html) im *Benutzerhandbuch für License Manager*
## Systems Manager GUI Connect, Umgang mit AWS IAM Identity Center Attributen
Systems Manager GUI Connect ist die API, die Fleet Manager-Verbindungen zu EC2-Instances mithilfe von RDP unterstützt. Die folgenden IAM-Identity-Center-Benutzerdaten werden nach dem Trennen einer Verbindung beibehalten:
+ `username`
Systems Manager GUI Connect verschlüsselt dieses Identitätsattribut im Ruhezustand Von AWS verwalteter Schlüssel standardmäßig mit einem. Vom Kunden verwaltete Schlüssel werden für die Verschlüsselung dieses Attributs in Systems Manager GUI Connect nicht unterstützt. Wenn Sie einen Benutzer in Ihrer IAM-Identity-Center-Instance löschen, wird das verknüpfte `username`-Attribut 7 Jahre lang in Systems Manager GUI Connect aufbewahrt und anschließend gelöscht. Diese Daten werden zur Unterstützung von Überwachungsereignissen aufbewahrt, z. B. zur Auflistung des Verbindungsverlaufs von Systems Manager GUI Connect. Die Daten können nicht manuell gelöscht werden.
## Verbindung zu einem verwalteten Knoten über Remote Desktop
**copy/paste Browser-Unterstützung für Text**
Mit den Browsern Google Chrome und Microsoft Edge können Sie Text von einem verwalteten Knoten auf Ihren lokalen Computer und von Ihrem lokalen Computer in einen verwalteten Knoten, mit dem Sie verbunden sind, kopieren und einfügen.
Mit dem Mozilla-Firefox-Browser können Sie Text nur von einem verwalteten Knoten auf Ihren lokalen Computer kopieren und einfügen. Das Kopieren von Ihrem lokalen Computer auf den verwalteten Knoten wird nicht unterstützt.
**So stellen Sie über Fleet Manager Remote Desktop eine Verbindung zu einem verwalteten Knoten her**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie den Knoten, zu dem Sie eine Verbindung herstellen möchten. Sie können entweder das Kontrollkästchen oder den Knotennamen auswählen.
1. Wählen Sie im Menü **Knotenaktionen** die Option **Mit Remote Desktop verbinden**.
1. Wählen Sie den gewünschten **Authentication type** (Authentifizierungs-Typ). Wenn Sie **Benutzeranmeldeinformationen** wählen, geben Sie den Benutzernamen und das Passwort für ein Windows-Benutzerkonto auf dem Knoten ein, zu dem Sie eine Verbindung herstellen möchten. Wenn Sie **Schlüsselpaar** wählen, können Sie die Authentifizierung mit einer der folgenden Methoden durchführen:
1. Wählen Sie **Lokale Maschine durchsuchen**, wenn Sie den mit Ihrer Instance verbundenen PEM-Schlüssel aus Ihrem lokalen Dateisystem auswählen möchten.
– oder –
1. Wählen Sie **Schlüsselpaarinhalt einfügen**, wenn Sie den Inhalt der PEM-Datei kopieren und in das vorgesehene Feld einfügen möchten.
1. Wählen Sie **Verbinden** aus.
1. Um Ihre bevorzugte Bildschirmauflösung zu wählen, wählen Sie im Menü **Aktionen** die Option **Auflösungen**, und wählen Sie dann eine der folgenden Optionen:
+ **Automatisch anpassen**
+ **1920 x 1080**
+ **1 400 x 900**
+ **1 366 x 768**
+ **800 x 600**
Die Option **Automatisch anpassen** legt die Auflösung auf der Grundlage der erkannten Bildschirmgröße fest.
## Anzeigen von Informationen über aktuelle und abgeschlossene Verbindungen
Sie können den Fleet Manager-Bereich der Systems-Manager-Konsole verwenden, um Informationen zu RDP-Verbindungen anzuzeigen, die in Ihrem Konto hergestellt wurden. Mithilfe einer Reihe von Filtern können Sie die angezeigte Liste der Verbindungen auf einen Zeitraum, eine bestimmte Instance, den Benutzer, der die Verbindungen hergestellt hat, und Verbindungen mit einem bestimmten Status einschränken. Die Konsole bietet auch Registerkarten, auf denen Informationen zu allen derzeit aktiven Verbindungen und allen vergangenen Verbindungen angezeigt werden.
**So zeigen Sie Informationen über aktuelle und abgeschlossene Verbindungen an**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie Kontoverwaltung, Mit Remote Desktop Connect.****
1. Wählen Sie eine der folgenden Registerkarten:
+ **Aktive Verbindungen**
+ **Verlauf der Verbindung**
1. Um die Liste der angezeigten Verbindungsergebnisse weiter einzuschränken, geben Sie einen oder mehrere Filter in das Suchfeld (![\[\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/search-icon.png)) ein. Sie können auch einen Freitext-Suchbegriff eingeben.
# Verwaltung von Amazon-EBS-Volumes auf verwalteten Instances
[Amazon Elastic Block Store](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html) (Amazon EBS) bietet Volumes für die Speicherung auf Blockebene, die in Verbindung mit Instances von Amazon Elastic Compute Cloud (EC2) verwendet werden. EBS-Volumes verhalten sich wie unformatierte Blockgeräte. Sie können diese Volumes als Geräte auf Ihren Instances mounten.
Sie können ein Tool in verwenden Fleet Manager AWS Systems Manager, um Amazon EBS-Volumes auf Ihren verwalteten Instances zu verwalten. Sie können beispielsweise ein EBS-Volume initialisieren, eine Partition formatieren und das Volume mounten, um es für die Nutzung verfügbar zu machen.
**Anmerkung**
Fleet Manager unterstützt derzeit die Amazon-EBS-Volume-Verwaltung nur für Windows Server-Instances.
## Anzeigen von Details zu EBS-Volumes
**So zeigen Sie Details für ein EBS-Volume mit Fleet Manager an**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben der verwalteten Instance aus, deren EBS-Volumedetails Sie anzeigen möchten.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie **Tools, EBS-Volumes**.
1. Um Details zu einem EBS-Volume anzuzeigen, wählen Sie seine ID in der Spalte **Volume-ID**.
## Initialisieren und Formatieren eines EBS-Volumes
**So initialisieren und formatieren Sie ein EBS-Volume mit Fleet Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die Schaltfläche neben der verwalteten Instance aus, die Sie initialisieren, formatieren und mounten möchten. Sie können ein EBS-Volume nur initialisieren, wenn sein Datenträger leer ist.
1. Wählen Sie die Option **Details anzeigen** aus.
1. Wählen Sie im Menü **Tools** die Option **EBS-Volumes**.
1. Wählen Sie die Schaltfläche neben dem EBS-Volume, das Sie initialisieren und formatieren möchten.
1. Wählen Sie **Initialisieren und formatieren**.
1. Wählen Sie unter **Partitionsstil** den Partitionsstil aus, den Sie für das EBS-Volume verwenden möchten.
1. (Optional) Wählen Sie einen **Laufwerksbuchstaben** für die Partition.
1. (Optional) Geben Sie einen **Partitionsnamen** ein, um die Partition zu identifizieren.
1. Wählen Sie das **Dateisystem** aus, das zum Organisieren der in der Partition gespeicherten Dateien und Daten verwendet werden soll.
1. Wählen Sie **Bestätigen**, um das EBS-Volume zur Verwendung verfügbar zu machen. Sie können die Partitionskonfiguration AWS-Managementkonsole nach der Bestätigung nicht ändern. Sie können sich jedoch mit SSH oder RDP bei der Instanz anmelden, um die Partitionskonfiguration zu ändern.
# Zugriff auf das Wissensdatenbank-Portal von Red Hat
Wenn Sie ein RedHat-Kunde sind AWS Systems Manager, können Sie ein Tool in verwendenFleet Manager, um auf das Knowledge Base-Portal zuzugreifen. Sie gelten als Red-Hat-Kunde, wenn Sie auf AWSRed Hat Enterprise Linux (RHEL)-Instances ausführen oder RHEL-Services verwenden. Das Wissendatenbank-Portal umfasst Binärdateien sowie Wissensaustausch- und Diskussionsforen für Community-Support, die nur von Red Hat lizenzierten Kunden zur Verfügung stehen.
Zusätzlich zu den erforderlichen AWS Identity and Access Management (IAM-) Berechtigungen für Systems Manager und muss der Benutzer oder die RolleFleet Manager, die Sie für den Zugriff auf die Konsole verwenden, der `rhelkb:GetRhelURL` Aktion den Zugriff auf das Knowledge Base-Portal ermöglichen.
**Zugreifen auf das Red-Hat-Knowledgebase-Portal**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie die RHEL-Instance, die Sie verwenden möchten, um sich mit dem Knowledgebase-Portal von Red Hat zu verbinden.
1. Wählen Sie **Kontomanagement**, **Auf Red-Hat-Wissensdatenbank zugreifen**, um die Red-Hat-Wissensdatenbank zu öffnen.
Wenn Sie RHEL on verwenden, AWS um vollständig unterstützte RHEL Workloads auszuführen, können Sie mit Ihren AWS Zugangsdaten auch über die Website von Red Hat auf die Red Hat Knowledge Base zugreifen.
# Problembehandlung bei der Verfügbarkeit verwalteter Knoten
Bei verschiedenen AWS Systems Manager Tools wie Run Command DistributorSession Manager, und können Sie die verwalteten Knoten, auf denen Sie einen Vorgang ausführen möchten, manuell auswählen. In solchen Fällen zeigt das System, nachdem Sie angegeben haben, dass Sie Knoten manuell auswählen möchten, eine Liste der verwalteten Knoten an, auf denen Sie die Operation ausführen können.
Dieses Thema liefert Informationen zur Diagnose, warum ein verwalteter Knoten, *für den Sie bestätigt haben, dass er ausgeführt wird*, nicht in Ihren Listen verwalteter Knoten in Systems Manager aufgeführt wird.
Damit ein Knoten von Systems Manager verwaltet und in Listen verwalteter Knoten verfügbar ist, muss er drei primäre Anforderungen erfüllen:
+ SSM Agent muss auf dem Knoten installiert sein und mit einem unterstützten Betriebssystem ausgeführt werden.
**Anmerkung**
Einige AWS managed Amazon Machine Images (AMIs) sind so konfiguriert, dass sie Instances mit [SSM Agent](ssm-agent.md)vorinstallierter Installation starten. (Sie können auch ein benutzerdefiniertes AMI zur Vorinstallation von SSM Agent konfigurieren). Weitere Informationen finden Sie unter [Finden Sie AMIs mit dem vorinstallierten SSM Agent](ami-preinstalled-agent.md).
+ Für Amazon Elastic Compute Cloud (Amazon EC2) -Instances müssen Sie ein AWS Identity and Access Management (IAM-) Instance-Profil an die Instance anhängen. Das Instance-Profil ermöglicht es der Instance, mit dem Systems-Manager-Service zu kommunizieren. Wenn Sie der Instance kein Instance-Profil zuweisen, registrieren Sie sie mit einer [Hybrid-Aktivierung](activations.md), was kein übliches Szenario ist.
+ SSM Agent muss in der Lage sein, eine Verbindung zu einem Systems Manager-Endpunkt herzustellen, um sich beim Service zu registrieren. Danach muss der verwaltete Knoten für den Service verfügbar sein, was vom Service bestätigt wird, der alle fünf Minuten ein Signal sendet, um den Zustand der Instance zu überprüfen.
+ Nachdem der Status eines verwalteten Knotens mindestens 30 Tage lang `Connection Lost` gewesen ist, wird der Knoten möglicherweise nicht mehr in der Fleet Manager-Konsole aufgeführt. Beheben Sie das Problem, das den Verbindungsverlust verursacht hat, um ihn wieder in die Liste aufzunehmen.
Nachdem Sie überprüft haben, dass ein verwalteter Knoten ausgeführt wird, können Sie den folgenden Befehl verwenden, um zu überprüfen, ob SSM Agent erfolgreich beim Systems-Manager-Service registriert wurde. Dieser Befehl gibt keine Ergebnisse zurück, bis eine erfolgreiche Registrierung stattgefunden hat.
------
#### [ 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
```
------
Wenn die Registrierung erfolgreich war und der verwaltete Knoten jetzt für Systems-Manager-Operationen verfügbar ist, gibt der Befehl ähnliche Ergebnisse wie die folgenden zurück.
```
{
"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"
}
]
}
```
Wenn die Registrierung noch nicht abgeschlossen wurde oder nicht erfolgreich war, gibt der Befehl ähnliche Ergebnisse wie die folgenden zurück:
```
{
"InstanceAssociationStatusInfos": []
}
```
Wenn der Befehl nach etwa 5 Minuten keine Ergebnisse zurückgibt, verwenden Sie die folgenden Informationen, um Probleme mit Ihren verwalteten Knoten zu beheben.
**Topics**
+ [Lösung 1: Überprüfen Sie, ob SSM Agent installiert ist und auf dem verwalteten Knoten ausgeführt wird](#instances-missing-solution-1)
+ [Lösung 2: Überprüfen Sie, ob ein IAM-Instance-Profil für die Instance angegeben wurde (nur EC2-Instances)](#instances-missing-solution-2)
+ [Lösung 3: Überprüfen der Konnektivität des Service-Endpunkts](#instances-missing-solution-3)
+ [Lösung 4: Überprüfen der Unterstützung des Zielbetriebssystems](#instances-missing-solution-4)
+ [Lösung 5: Stellen Sie sicher, dass Sie in derselben AWS-Region Amazon EC2 EC2-Instance arbeiten](#instances-missing-solution-5)
+ [Lösung 6: Überprüfen Sie die Proxy-Konfiguration, die Sie auf SSM Agent in Ihrem verwalteten Knoten angewendet haben](#instances-missing-solution-6)
+ [Lösung 7: Installieren eines TLS-Zertifikats auf verwalteten Instances](#hybrid-tls-certificate)
+ [Problembehandlung bei der Verfügbarkeit von verwalteten Knoten mit `ssm-cli`](troubleshooting-managed-nodes-using-ssm-cli.md)
## Lösung 1: Überprüfen Sie, ob SSM Agent installiert ist und auf dem verwalteten Knoten ausgeführt wird
Stellen Sie sicher, dass die neueste Version von SSM Agent auf dem verwalteten Knoten installiert ist und ausgeführt wird.
Informationen zum Feststellen, ob SSM Agent installiert ist und auf einem verwalteten Knoten ausgeführt wird, finden Sie unter [Prüfen des SSM Agent-Status und Starten des Agenten](ssm-agent-status-and-restart.md).
Um SSM Agent auf einem verwalteten Knoten zu installieren bzw. deinstallieren, siehe folgende Themen:
+ [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für Linux](manually-install-ssm-agent-linux.md)
+ [So installieren Sie den SSM Agent in Hybrid-Linux-Knoten](hybrid-multicloud-ssm-agent-install-linux.md)
+ [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für Windows Server](manually-install-ssm-agent-windows.md)
+ [So installieren Sie den SSM Agent in Hybrid-Windows-Knoten](hybrid-multicloud-ssm-agent-install-windows.md)
## Lösung 2: Überprüfen Sie, ob ein IAM-Instance-Profil für die Instance angegeben wurde (nur EC2-Instances)
Vergewissern Sie sich bei Amazon Elastic Compute Cloud (Amazon EC2)-Instances, ob die Instance mit einem AWS Identity and Access Management (IAM)-Instance-Profil konfiguriert ist, das es der Instance erlaubt, mit der Systems-Manager-API zu kommunizieren. Stellen Sie außerdem sicher, dass Ihr Benutzer über eine IAM-Vertrauensrichtlinie verfügt, die es Ihrem Benutzer ermöglicht, mit der Systems-Manager-API zu kommunizieren.
**Anmerkung**
Lokale Server, Edge-Geräte und virtuelle Maschinen (VMs) verwenden eine IAM-Servicerolle anstelle eines Instanzprofils. Weitere Informationen finden Sie unter [Erstellen der für Systems Manager in Hybrid- und Multi-Cloud-Umgebungen erforderlichen IAM-Servicerolle](hybrid-multicloud-service-role.md).
**So stellen Sie fest, ob ein Instance-Profil mit den nötigen Berechtigungen einer EC2-Instance angefügt ist**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Instances** aus.
1. Wählen Sie die Instance, die nach einem Instance-Profil überprüft werden soll.
1. Suchen Sie auf der Registerkarte **Description (Beschreibung)** im unteren Bereich die **IAM-Rolle** und wählen Sie den Namen der Rolle.
1. Vergewissern Sie sich auf der Seite **Summary** des Instance-Profils auf der Registerkarte **Permissions (Berechtigungen)**, dass unter den **Berechtigungsrichtlinien** `AmazonSSMManagedInstanceCore` aufgeführt ist.
Wenn stattdessen eine benutzerdefinierte Richtlinie verwendet wird, stellen Sie sicher, dass sie dieselben Berechtigungen wie `AmazonSSMManagedInstanceCore` bereitstellt.
[Öffnen Sie `AmazonSSMManagedInstanceCore` in der Konsole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore$jsonEditor)
Informationen über andere Richtlinien, die an ein Instance-Profil für Systems Manager angefügt werden können, finden Sie unter [Konfigurieren von erforderlichen Instances-Berechtigungen für Systems Manager](setup-instance-permissions.md).
## Lösung 3: Überprüfen der Konnektivität des Service-Endpunkts
Stellen Sie sicher, dass die Instance eine Verbindung zu den Systems Manager Service-Endpunkten hat. Diese Konnektivität wird entweder durch das Erstellen und Konfigurieren von VPC-Endpunkten für Systems Manager oder durch die Genehmigung von ausgehenden HTTPS-Datenverkehr (Port 443) zu den Service-Endpunkten bereitgestellt.
Bei Amazon EC2 EC2-Instances AWS-Region wird der Systems Manager Manager-Serviceendpunkt für die zur Registrierung der Instance verwendet, wenn Ihre Virtual Private Cloud (VPC) -Konfiguration ausgehenden Datenverkehr zulässt. Wenn die VPC-Konfiguration, in der die Instance gestartet wurde, jedoch keinen ausgehenden Datenverkehr zulässt und Sie diese Konfiguration nicht ändern können, um Konnektivität zu den öffentlichen Service-Endpunkten zu erlauben, müssen Sie stattdessen Schnittstellenendpunkte für Ihre VPC konfigurieren.
Weitere Informationen finden Sie unter [Verbessern der Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für](setup-create-vpc.md) Systems Manager.
## Lösung 4: Überprüfen der Unterstützung des Zielbetriebssystems
Stellen Sie sicher, dass die ausgewählte Operation für den Typ von verwalteten Knoten ausgeführt werden kann, den Sie in der Liste erwarten. Einige Systems Manager-Vorgänge können nur auf Windows-Instanceen oder nur auf Linux-Instances abzielen. Zum Beispiel können die Systems Manager (SSM) Dokumente `AWS-InstallPowerShellModule` und `AWS-ConfigureCloudWatch` nur auf Windows-Instances ausgeführt werden. Wenn Sie auf der Seite **Run a command (Ausführen eines Befehls)** eines dieser Dokumente auswählen und die Option **Choose instances manually (Instancen manuell auswählen)** wählen, werden nur Ihre Windows-Instances aufgelistet und stehen zur Auswahl.
## Lösung 5: Stellen Sie sicher, dass Sie in derselben AWS-Region Amazon EC2 EC2-Instance arbeiten
Amazon EC2 EC2-Instances werden in bestimmten Regionen erstellt und sind verfügbar AWS-Regionen, z. B. in der Region USA Ost (Ohio) (us-east-2) oder Europa (Irland) (eu-west-1). Stellen Sie sicher, dass Sie in derselben AWS-Region Amazon EC2 EC2-Instance arbeiten, mit der Sie arbeiten möchten. Weitere Informationen dazu erhalten Sie unter [Choosing a Region (Region wählen)](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html#select-region) in *Getting Started with the AWS-Managementkonsole*.
## Lösung 6: Überprüfen Sie die Proxy-Konfiguration, die Sie auf SSM Agent in Ihrem verwalteten Knoten angewendet haben
Überprüfen Sie, ob die Proxy-Konfiguration, die Sie auf SSM Agent in Ihrem verwalteten Knoten angewendet haben, korrekt ist. Wenn die Proxy-Konfiguration falsch ist, kann der Knoten keine Verbindung zu den erforderlichen Service-Endpunkten herstellen, oder Systems Manager identifiziert möglicherweise das Betriebssystem des verwalteten Knotens falsch. Weitere Informationen erhalten Sie unter [Konfigurieren Sie SSM Agent, um einen Proxy in Linux-Knoten zu verwenden](configure-proxy-ssm-agent.md) und [Konfigurieren des SSM Agent zur Nutzung eines Proxys für Windows Server-Instances](configure-proxy-ssm-agent-windows.md).
## Lösung 7: Installieren eines TLS-Zertifikats auf verwalteten Instances
Auf jeder verwalteten Instance, die Sie verwenden, muss ein Transport Layer Security (TLS) -Zertifikat installiert sein. AWS Systems Manager AWS-Services Verwenden Sie diese Zertifikate, um Anrufe an andere AWS-Services zu verschlüsseln.
Auf jeder Amazon-EC2-Instance, die aus einem Amazon Machine Image (AMI) erstellt wurde, ist standardmäßig bereits ein TLS-Zertifikat installiert. Die meisten modernen Betriebssysteme enthalten das erforderliche TLS-Zertifikat von Amazon Trust Services CAs in ihrem Trust Store.
Um zu überprüfen, ob das erforderliche Zertifikat auf Ihrer Instance installiert ist, führen Sie den folgenden Befehl basierend auf dem Betriebssystem Ihrer Instance aus. Achten Sie darauf, den *region* Teil der URL durch den Teil zu ersetzen, AWS-Region in dem sich Ihre verwaltete Instance befindet.
------
#### [ Linux & macOS ]
```
curl -L https://ssm.region.amazonaws.com
```
------
#### [ Windows ]
```
Invoke-WebRequest -Uri https://ssm.region.amazonaws.com
```
------
Der Befehl sollte einen `UnknownOperationException`-Fehler zurückgeben. Wenn Sie stattdessen eine SSL/TLS Fehlermeldung erhalten, ist das erforderliche Zertifikat möglicherweise nicht installiert.
Wenn Sie feststellen, AMIs dass die erforderlichen CA-Zertifikate von Amazon Trust Services nicht auf Ihren Basisbetriebssystemen, auf Instances installiert sind, die nicht von Amazon bereitgestellt wurden, oder auf Ihren eigenen lokalen Servern VMs, müssen Sie ein Zertifikat von [Amazon Trust Services](https://www.amazontrust.com/repository/) installieren und zulassen oder AWS Certificate Manager (ACM) verwenden, um Zertifikate für einen unterstützten integrierten Service zu erstellen und zu verwalten.
Auf jeder Ihrer verwalteten Instances muss eines der folgenden Transport Layer Security (TLS)-Zertifikate installiert sein.
+ Amazon Root CA 1
+ Starfield Services Root Certificate Authority – G2
+ Starfield Class 2 Certificate Authority
Informationen zur Verwendung von ACM finden Sie im *[AWS Certificate Manager -Benutzerhandbuch](https://docs.aws.amazon.com/acm/latest/userguide/)*.
Wenn Zertifikate in Ihrer Datenverarbeitungsumgebung von einem Gruppenrichtlinienobjekt (GPO) verwaltet werden, dann müssen Sie möglicherweise die Gruppenrichtlinie so konfigurieren, dass eines dieser Zertifikate enthalten ist.
Weitere Informationen zu den Amazon Root- und Starfield-Zertifikaten finden Sie im Blogbeitrag [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/).
# Problembehandlung bei der Verfügbarkeit von verwalteten Knoten mit `ssm-cli`
Die `ssm-cli` ist ein eigenständiges Befehlszeilentool, das in der SSM Agent-Installation enthalten ist. Wenn Sie SSM Agent 3.1.501.0 oder höher auf einem Computer installieren, können Sie `ssm-cli`-Befehle auf diesem Computer ausführen. Anhand der Ausgabe dieser Befehle können Sie feststellen, ob der Computer die Mindestanforderungen für eine Amazon EC2 EC2-Instance oder einen Nicht-EC2-Computer erfüllt AWS Systems Manager, von dem er verwaltet werden kann, und daher zu den Listen der verwalteten Knoten in Systems Manager hinzugefügt wird. (SSM AgentVersion 3.1.501.0 wurde im November 2021 veröffentlicht.)
**Mindestanforderungen**
Damit eine Amazon EC2 EC2-Instance oder ein Nicht-EC2-Computer von AWS Systems Manager verwaltet werden kann und in Listen verwalteter Knoten verfügbar ist, muss sie drei Hauptanforderungen erfüllen:
+ SSM Agent muss auf einer Maschine mit einem [unterstützten Betriebssystem](operating-systems-and-machine-types.md#prereqs-operating-systems) installiert sein und laufen.
Einige AWS managed Amazon Machine Images (AMIs) für EC2 sind so konfiguriert, dass sie Instances mit vorinstallierter Installation starten. [SSM Agent](ssm-agent.md) (Sie können auch ein benutzerdefiniertes AMI zur Vorinstallation von SSM Agent konfigurieren). Weitere Informationen finden Sie unter [Finden Sie AMIs mit dem vorinstallierten SSM Agent](ami-preinstalled-agent.md).
+ Ein AWS Identity and Access Management (IAM-) Instanzprofil (für EC2-Instances) oder eine IAM-Servicerolle (für Nicht-EC2-Maschinen), das die erforderlichen Berechtigungen für die Kommunikation mit dem Systems Manager Manager-Dienst bereitstellt, muss an den Computer angehängt werden.
+ SSM Agent muss in der Lage sein, eine Verbindung zu einem Systems-Manager-Endpunkt herzustellen, um sich beim Service anzumelden. Danach muss der verwaltete Knoten für den Service verfügbar sein, was vom Service bestätigt wird, der alle fünf Minuten ein Signal sendet, um den Zustand des verwalteten Knoten zu überprüfen.
**Vorkonfigurierte Befehle in `ssm-cli`**
Es sind vorkonfigurierte Befehle enthalten, die die erforderlichen Informationen sammeln, um Ihnen bei der Diagnose zu helfen, warum eine Maschine, von der Sie bestätigt haben, dass sie läuft, nicht in Ihrer Liste der verwalteten Knoten in Systems Manager enthalten ist. Diese Befehle werden ausgeführt, wenn Sie die `get-diagnostics`-Option angeben.
Führen Sie auf der Maschine den folgenden Befehl aus, um `ssm-cli` für die Problembehebung in Bezug auf die Verfügbarkeit der verwalteten Knoten zu verwenden.
------
#### [ Linux & macOS ]
```
ssm-cli get-diagnostics --output table
```
------
#### [ Windows ]
In Windows Server-Maschinen müssen Sie zum `C:\Program Files\Amazon\SSM`-Verzeichnis navigieren, bevor Sie den Befehl ausführen.
```
ssm-cli.exe get-diagnostics --output table
```
------
#### [ PowerShell ]
Auf Windows Server-Maschinen müssen Sie zum `C:\Program Files\Amazon\SSM`-Verzeichnis navigieren, bevor Sie den Befehl ausführen.
```
.\ssm-cli.exe get-diagnostics --output table
```
------
Der Befehl liefert eine Ausgabe in Form einer Tabelle ähnlich der folgenden.
**Anmerkung**
Konnektivitätsprüfungen zu den `monitoring` Endpunkten `ssmmessages` `s3``kms`,`logs`,, und dienen zusätzlichen optionalen Funktionen, z. B. Session Manager die Möglichkeit, sich bei Amazon Simple Storage Service (Amazon S3) oder Amazon CloudWatch Logs zu protokollieren und AWS Key Management Service (AWS KMS) -Verschlüsselung zu verwenden.
------
#### [ 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 │
└───────────────────────────────────────┴─────────┴─────────────────────────────────────────────────────────────────────┘
```
------
Die folgende Tabelle enthält zusätzliche Details für jede der von `ssm-cli` ausgeführten Überprüfungen.
**`ssm-cli`-Diagnoseprüfungen**
| Check | Details |
| --- | --- |
| Amazon-EC2-Instance-Metadaten-Service | Gibt an, ob der verwaltete Knoten den Metadaten-Service erreichen kann. Ein fehlgeschlagener Test deutet auf ein Konnektivitätsproblem zu http://169.254.169.254 hin, das durch das lokale Routing, den Proxy oder die Firewall- und Proxy-Konfigurationen des Betriebssystems verursacht werden kann. |
| Hybrid-Instance-Registrierung | Zeigt an, ob SSM Agent über eine Hybrid-Aktivierung registriert ist. |
| Konnektivität mit ssm-Endpunkt | Zeigt an, ob der Knoten in der Lage ist, die Service-Endpunkte für Systems Manager auf TCP-Port 443 zu erreichen. Ein fehlgeschlagener Test weist auf Verbindungsprobleme hin, https://ssm.region.amazonaws.com je nachdem AWS-Region , wo sich der Knoten befindet. Konnektivitätsprobleme können durch die VPC-Konfiguration verursacht werden, einschließlich Sicherheitsgruppen, Netzwerkzugriffs-Kontrolllisten, Routing-Tabellen oder OS-Firewalls und Proxys. |
| Konnektivität mit ec2messages-Endpunkt | Zeigt an, ob der Knoten in der Lage ist, die Service-Endpunkte für Systems Manager auf TCP-Port 443 zu erreichen. Ein fehlgeschlagener Test weist auf Verbindungsprobleme hin, https://ec2messages.region.amazonaws.com je nachdem AWS-Region , wo sich der Knoten befindet. Konnektivitätsprobleme können durch die VPC-Konfiguration verursacht werden, einschließlich Sicherheitsgruppen, Netzwerkzugriffs-Kontrolllisten, Routing-Tabellen oder OS-Firewalls und Proxys. |
| Konnektivität mit ssmmessages-Endpunkt | Zeigt an, ob der Knoten in der Lage ist, die Service-Endpunkte für Systems Manager auf TCP-Port 443 zu erreichen. Ein fehlgeschlagener Test weist auf Verbindungsprobleme hin, https://ssmmessages.region.amazonaws.com je nachdem AWS-Region , wo sich der Knoten befindet. Konnektivitätsprobleme können durch die VPC-Konfiguration verursacht werden, einschließlich Sicherheitsgruppen, Netzwerkzugriffs-Kontrolllisten, Routing-Tabellen oder OS-Firewalls und Proxys. |
| Konnektivität mit s3-Endpunkt | Zeigt an, ob der Knoten in der Lage ist, den Service-Endpunkt für Amazon Simple Storage Service auf TCP-Port 443 zu erreichen. Ein fehlgeschlagener Test weist auf Verbindungsprobleme hin, https://s3.region.amazonaws.com je nachdem AWS-Region , wo sich der Knoten befindet. Eine Verbindung zu diesem Endpunkt ist nicht erforderlich, damit ein Knoten in Ihrer Liste der verwalteten Knoten erscheint. |
| Konnektivität mit kms-Endpunkt | Gibt an, ob der Knoten den Dienstendpunkt für AWS Key Management Service den TCP-Port 443 erreichen kann. Ein fehlgeschlagener Test weist auf Verbindungsprobleme hin, `https://kms.region.amazonaws.com` je nachdem AWS-Region , wo sich der Knoten befindet. Eine Verbindung zu diesem Endpunkt ist nicht erforderlich, damit ein Knoten in Ihrer Liste der verwalteten Knoten erscheint. |
| Konnektivität mit logs-Endpunkt | Gibt an, ob der Knoten den Service-Endpunkt für Amazon CloudWatch Logs auf TCP-Port 443 erreichen kann. Ein fehlgeschlagener Test weist auf Verbindungsprobleme hin, https://logs.region.amazonaws.com je nachdem AWS-Region , wo sich der Knoten befindet. Eine Verbindung zu diesem Endpunkt ist nicht erforderlich, damit ein Knoten in Ihrer Liste der verwalteten Knoten erscheint. |
| Konnektivität mit monitoring-Endpunkt | Gibt an, ob der Knoten den Service-Endpunkt für Amazon CloudWatch auf TCP-Port 443 erreichen kann. Ein fehlgeschlagener Test weist auf Verbindungsprobleme hin, https://monitoring.region.amazonaws.com je nachdem AWS-Region , wo sich der Knoten befindet. Eine Verbindung zu diesem Endpunkt ist nicht erforderlich, damit ein Knoten in Ihrer Liste der verwalteten Knoten erscheint. |
| AWS Erweitern Sie im angezeigten Detailbereich die Option | Zeigt an, ob SSM Agent über die erforderlichen Anmeldeinformationen auf der Grundlage des IAM-Instance-Profils (für EC2-Instances) oder der IAM-Servicerolle (für Nicht-EC2-Maschinen) verfügt, die mit der Maschine verbunden sind. Ein fehlgeschlagener Test zeigt an, dass der Maschine kein IAM-Instance-Profil oder keine IAM-Servicerolle zugeordnet ist, oder dass sie nicht die erforderlichen Berechtigungen für Systems Manager enthält. |
| Agent-Service | Zeigt an, ob der SSM Agent-Service läuft und ob der Service als Root für Linux oder macOS bzw. als SYSTEM für Windows Server läuft. Ein fehlgeschlagener Test zeigt an, dass der SSM Agent-Service nicht ausgeführt oder nicht als Root oder SYSTEM ausgeführt wird. |
| Proxykonfiguration | Gibt an, ob SSM Agent konfiguriert ist, einen Proxy zu verwenden. |
| Sysprep-Image-Status (nur Windows) | Zeigt den Status von Sysprep auf dem Knoten an. SSM Agent wird nicht auf dem Knoten gestartet, wenn der Sysprep-Status einen anderen Wert als IMAGE\$1STATE\$1COMPLETE hat. |
| SSM Agent-Version | Zeigt an, ob die neueste verfügbare Version von SSM Agent installiert ist. |
# AWS Systems Manager Hybride Aktivierungen
*Um EC2 Maschinen für die Verwendung AWS Systems Manager in einer [Hybrid- und Multicloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) zu konfigurieren, erstellen Sie eine Hybrid-Aktivierung.* Als verwaltete Knoten werden u. a. folgende Typen unterstützt, die keine EC2 Maschinen sind:
+ Server in Ihren eigenen Räumlichkeiten (On-Premises-Server)
+ AWS IoT Greengrass Kerngeräte
+ AWS IoT und Geräte, die nicht zu den AWS Edge-Geräten gehören
+ Virtuelle Maschinen (VMs), auch VMs in anderen Cloud-Umgebungen
Wenn Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-activation.html) ausführen, um einen Hybrid-Aktivierungsprozess zu starten, erhalten Sie in der Befehlsantwort einen Aktivierungscode und eine ID. Anschließend fügen Sie den Aktivierungscode und die ID dem Befehl zur Installation von SSM Agent auf der Maschine bei, wie in Schritt 3 von [Installation von SSM Agent auf hybriden Linux-Knoten](hybrid-multicloud-ssm-agent-install-linux.md) und Schritt 4 von [Installation von SSM Agent auf hybriden Windows Server-Knoten](hybrid-multicloud-ssm-agent-install-windows.md) beschrieben.
Dieser Aktivierungsprozess gilt für alle Typen, die keine EC2 Maschinen sind, *mit Ausnahme* von AWS IoT Greengrass Kerngeräten. Weitere Informationen zum Konfigurieren von AWS IoT Greengrass -Core-Geräten für Systems Manager finden Sie unter [Verwalten von Edge-Geräten mit Systems Manager](systems-manager-setting-up-edge-devices.md).
**Anmerkung**
Support wird derzeit nicht für EC2 macOS Maschinen bereitgestellt.
**Üner Systems Manager Instances-Kontingente**
AWS Systems Manager bietet eine Stufe „Standard-Instances“ und eine Stufe „Advanced-Instances“. Beide unterstützen verwaltete Knoten in Ihrer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types). Die Stufe „Standard-Instances“ ermöglicht es Ihnen, maximal 1.000 Maschinen pro Person zu registrieren. AWS-Konto AWS-Region Wenn Sie mehr als 1 000 Maschinen in einem einzigen Konto und einer Region anmelden müssen, verwenden Sie das Advanced-Instances-Kontingent. Sie können im Advanced-Instances-Kontingent so viele verwaltete Knoten erstellen, wie Sie möchten. Alle verwalteten Knoten, die für Systems Manager konfiguriert sind, werden auf pay-per-use Basis von Preisen berechnet. Weitere Informationen über das Aktivieren des Advanced-Instances-Kontingent finden Sie unter [Aktivieren des Kontingents für erweiterte Instances](fleet-manager-enable-advanced-instances-tier.md). Weitere Informationen über die Preise finden Sie unter [AWS Systems Manager – Preise](https://aws.amazon.com/systems-manager/pricing/).
Beachten Sie die folgenden zusätzlichen Informationen zur Ebene für Standard-Instances und zur Ebene für erweiterte Instances:
+ Mithilfe von Advanced Instances können Sie in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) auch eine Verbindung zu Ihren EC2 Nicht-Nodes AWS Systems Manager Session Manager herstellen. Session Managerbietet interaktiven Shell-Zugriff auf Ihre Instanzen. Weitere Informationen finden Sie unter [AWS Systems Manager Session Manager](session-manager.md).
+ Das Kontingent für Standardinstanzen gilt auch für EC2 Instanzen, die eine lokale Systems Manager Manager-Aktivierung verwenden (was kein übliches Szenario ist).
+ Um von Microsoft veröffentlichte Anwendungen auf lokalen Instanzen virtueller Maschinen (VMs) zu patchen, aktivieren Sie die Stufe „Advanced-Instances“. Die Nutzung des Advanced-Instances-Kontingents ist kostenpflichtig. Für Patch-Anwendungen, die von Microsoft auf Amazon Elastic Compute Cloud (Amazon EC2) -Instances veröffentlicht wurden, fallen keine zusätzlichen Gebühren an. Weitere Informationen finden Sie unter [Informationen zum Patchen von Anwendungen, die von Microsoft unter Windows Server veröffentlicht wurden](patch-manager-patching-windows-applications.md).
# AWS Systems Manager-Bestand
AWS Systems Manager Inventar bietet Einblick in Ihre AWS Computerumgebung. Mit Inventory können Sie *Metadaten* aus Ihren verwalteten Knoten erfassen. Sie können diese Metadaten in einem zentralen Amazon Simple Storage Service (Amazon S3)-Bucket speichern und dann die integrierten Tools nutzen, um Daten abzufragen und schnell zu ermitteln, welche Knoten die Software ausführen, welche Konfigurationen im Rahmen Ihrer Software-Richtlinie erforderlich sind und welche Knoten aktualisiert werden müssen. Sie können Inventory mit nur einem Klick für all Ihre verwalteten Knoten konfigurieren. Sie können mithilfe von Amazon Athena auch Inventardaten von mehreren AWS-Konten Geräten konfigurieren AWS-Regionen und anzeigen. Um mit Inventory zu beginnen, öffnen Sie die [Systems-Manager-Konsole](https://console.aws.amazon.com//systems-manager/inventory). Wählen Sie im Navigationsbereich **Inventory**.
Wenn die vorkonfigurierten, von Systems Manager Inventory Inventory erfassten Metadaten nicht Ihren Anforderungen entsprechen, können Sie einen benutzerdefinierten Bestand erstellen. Beim benutzerdefinierten Bestand handelt es sich lediglich um eine JSON-Datei mit Informationen, die Sie bereitstellen und zum verwalteten Knoten in einem bestimmten Verzeichnis hinzufügen. Bei der Datenerfassung erfasst Systems Manager Inventory diese Daten für den benutzerdefinierten Bestand. Beispiel: Wenn Sie ein großes Rechenzentrum betreiben, können Sie die Rack-Standorte der einzelnen Server als benutzerdefinierten Bestand angeben. Anschließend können Sie beim Anzeigen anderer Bestandsdaten die Daten im Rack-Bereich anzeigen.
**Wichtig**
Systems Manager Inventory erfasst *nur* Metadaten von Ihren verwalteten Knoten. Inventory greift nicht auf proprietäre Informationen oder Daten zu.
In der folgenden Tabelle werden die Arten von Daten beschrieben, die Sie mit Systems Manager Inventory erfassen können. Außerdem werden darin verschiedene Angebote für die gezielte Erfassung von Knoten sowie die Erfassungsintervalle beschrieben, die angegeben werden können.
****
| Konfiguration | Details |
| --- | --- |
| Metadatentypen | Sie können Inventory so konfigurieren, dass die folgenden Typen von Daten erfasst werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/systems-manager-inventory.html) Wie Sie eine Liste aller durch Inventory erfassten Metadaten anzeigen, lesen Sie nach unter [Metadaten-Erfassung durch Inventory](inventory-schema.md) |
| Zu erfassende Knoten | Sie können wählen, ob Sie alle verwalteten Knoten in Ihren AWS-Konto individuell ausgewählten Knoten oder Zielgruppen von Knoten mithilfe von Tags inventarisieren möchten. Weitere Informationen zur Erfassung von Bestandsdaten aller verwalteten Knoten finden Sie unter [Inventarisieren Sie alle verwalteten Knoten in Ihrem AWS-Konto](inventory-collection.md#inventory-management-inventory-all). |
| Wann Daten erfasst werden sollen | Sie können ein Intervall für die Erfassung in Minuten, Stunden und Tagen angeben. Das kürzeste mögliche Erfassungsintervall ist alle 30 Minuten. |
**Anmerkung**
Abhängig von der Menge der erfassten Daten kann es einige Minuten in Anspruch nehmen, bis die Daten vom System in der Ausgabe bereitgestellt werden können, die Sie angegeben haben. Nachdem die Informationen gesammelt wurden, werden die Daten über einen sicheren HTTPS-Kanal an einen AWS Klartext-Speicher gesendet, auf den nur von Ihrem aus zugegriffen werden kann. AWS-Konto
Sie können die Daten in der Systems Manager-Konsole auf der Seite **Inventory** anzeigen. Diese enthält mehrere vordefinierte Karten zur Datenabfrage.
![\[Systems Manager-Inventory-Karten in der Systems Manager-Konsole.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-cards.png)
**Anmerkung**
Inventarkarten filtern automatisch von Amazon EC2 verwaltete Instances mit dem Status „*Beendet*“ und „*Gestoppt*“ heraus. Bei Knoten, die vor Ort und über AWS IoT Greengrass zentrale Geräte verwaltet werden, filtern Inventarkarten automatisch Knoten mit dem Status „*Beendet*“ heraus.
Wenn Sie eine Resource Data Sync zum Synchronisieren und Speichern aller Daten in einem einzelnen Amazon S3-Bucket erstellen, können Sie die Daten auf der Seite **Inventory Detailed View (Detailansicht zum Bestand)** detailliert anzeigen. Weitere Informationen finden Sie unter [Abfragen von Bestandsdaten aus mehreren Regionen und Konten](systems-manager-inventory-query.md).
**EventBridge Unterstützung**
Dieses Systems Manager Manager-Tool wird in den EventBridge Amazon-Regeln als *Ereignistyp* unterstützt. Weitere Informationen finden Sie unter [Überwachung von Systems Manager Manager-Ereignissen mit Amazon EventBridge](monitoring-eventbridge-events.md) und [Referenz: EventBridge Amazon-Ereignistypen und -muster für Systems Manager](reference-eventbridge-events.md).
**Topics**
+ [Weitere Informationen über Systems Manager Inventory](inventory-about.md)
+ [Einrichten von Systems Manager Inventory](systems-manager-inventory-setting-up.md)
+ [Konfigurieren der Bestandserfassung](inventory-collection.md)
+ [Abfragen von Bestandsdaten aus mehreren Regionen und Konten](systems-manager-inventory-query.md)
+ [Abfragen der Bestandserfassung mithilfe von Filtern](inventory-query-filters.md)
+ [Aggregieren von Bestandsdaten](inventory-aggregate.md)
+ [Arbeiten mit benutzerdefiniertem Bestand](inventory-custom.md)
+ [Anzeigen von Bestandsverlauf und Änderungsnachverfolgung](inventory-history.md)
+ [Anhalten der Datenerfassung und Löschen von Bestandsdaten](systems-manager-inventory-delete.md)
+ [Zuweisen benutzerdefinierter Bestands-Metadaten zu einem verwalteten Knoten](inventory-custom-metadata.md)
+ [Verwenden von AWS CLI , um die Inventardatenerfassung zu konfigurieren](inventory-collection-cli.md)
+ [Walkthrough: Verwenden von Resource Data Sync zum Aggregieren von Bestandsdaten](inventory-resource-data-sync.md)
+ [Fehlerbehebung bei Problemen mit Systems Manager Inventory](syman-inventory-troubleshooting.md)
# Weitere Informationen über Systems Manager Inventory
Wenn Sie AWS Systems Manager Inventory konfigurieren, geben Sie den Typ der zu erfassenden Metadaten, die verwalteten Knoten, aus denen die Metadaten erfasst werden sollen, und einen Zeitplan für die Erfassung der Metadaten an. Diese Konfigurationen werden als AWS Systems Manager State Manager-Zuordnung in Ihrem AWS-Konto gespeichert. Eine Zuordnung ist einfach eine Konfiguration.
**Anmerkung**
Inventory erfasst nur Metadaten. Es werden keine personenbezogenen oder vertraulichen Daten erfasst.
**Topics**
+ [Metadaten-Erfassung durch Inventory](inventory-schema.md)
+ [Arbeiten mit Datei- und Windows-Registrierungsbestand](inventory-file-and-registry.md)
# Metadaten-Erfassung durch Inventory
Das folgende Beispiel zeigt die vollständige Liste der Metadaten von jedem AWS Systems Manager Inventar-Plugin erfasst wurden.
```
{
"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"}
]
}
```
**Anmerkung**
Für`"typeName": "AWS:InstanceInformation"` kann der `InstanceStatus` einer der folgenden sein: Active, ConnectionLost, Stopped, Terminated (Aktiv, Verbindung abgebrochen, angehalten, beendet).
Mit der Veröffentlichung von Version 2.5 ersetzt der RPM-Paketmanager ersetzt das Serial-Attribut durch Epoch. Das Epoch-Attribut ist eine monoton zunehmende Ganzzahl wie Serial. Wenn Sie eine Bestandsaufnahme unter Verwendung des `AWS:Application`-Typs durchführen, bedeutet ein größerer Wert für Epoch eine neuere Version. Wenn Epoch-Werte gleich oder leer sind, verwenden Sie den Wert des Version- oder Release-Attributs, um die neuere Version zu bestimmen.
Einige Metadaten sind in Linux-Instances nicht verfügbar. Insbesondere für „typeName“: „AWS:Network“ werden die folgenden Metadatentypen für Linux-Instances noch nicht unterstützt. Sie WERDEN für Windows unterstützt.
\$1 "name": "SubnetMask", "dataType": "STRING"\$1,
\$1 "name": "DHCPServer", "dataType": "STRING"\$1,
\$1 "name": "DNSServer", "dataType": "STRING"\$1,
\$1 "name": "Gateway", "dataType": "STRING"\$1,
# Arbeiten mit Datei- und Windows-Registrierungsbestand
AWS Systems Manager Inventory ermöglicht das Suchen und Inventarisieren von Dateien auf Windows Server Linux- und macOS Betriebssystemen. Sie können auch die Windows-Registry durchsuchen und inventarisieren.
**Dateien**: Sie können Metadaten-Informationen zu Dateien erfassen, einschließlich Dateinamen, der Erstellungszeit der Dateien, der letzten Änderungs- und Zugriffszeit der Dateien oder Dateigrößen, um nur ein paar zu nennen. Um mit der Erfassung eines Dateibestands zu beginnen, geben Sie einen Dateipfad an, in dem Sie die Inventarisierung durchführen möchten, ein oder mehrere Muster, die definieren, welche Dateitypen inventarisiert werden soll, und ob der Pfad rekursiv durchsucht werden soll. Systems Manager inventarisiert alle Datei-Metadaten für Dateien im angegebenen Pfad, die dem Muster entsprechen. Die Dateiinventarisierung verwendet die folgenden Eingangsparameter.
```
{
"Path": string,
"Pattern": array[string],
"Recursive": true,
"DirScanLimit" : number // Optional
}
```
+ **Path**: Der Verzeichnispfad, in dem Dateien inventarisiert werden sollen. Für Windows können Sie Umgebungsvariablen wie `%PROGRAMFILES% ` verwenden, solange die Variable einem einzigen Verzeichnispfad zugeordnet ist. Wenn Sie beispielsweise %PATH% verwenden, das auf mehreren Verzeichnispfade abgebildet wird, wirft Inventory einen Fehler auf.
+ **Pattern**: Ein Array mit zu identifizierenden Mustern.
+ **Recursive**: Ein Boolescher Wert, der angibt, ob Inventory die Verzeichnisse rekursiv durchlaufen soll.
+ **DirScanLimit**: Ein optionaler Wert, der angibt, wie viele Verzeichnisse gescannt werden sollen. Verwenden Sie diesen Parameter, um die Leistung Ihrer verwalteten Knoten möglichst wenig zu beeinträchtigen. Inventory scannt maximal 5.000 Verzeichnisse.
**Anmerkung**
Inventory erfasst Metadaten für maximal 500 Dateien für alle angegebenen Pfade.
Hier finden Sie einige Beispiele, wie Sie die Parameter angeben, wenn Sie eine Inventarisierung von Dateien vornehmen wollen.
+ Unter Linux und macOS erfassen Sie Metadaten von .sh-Dateien im Verzeichnis `/home/ec2-user` ohne die Unterverzeichnisse.
```
[{"Path":"/home/ec2-user","Pattern":["*.sh", "*.sh"],"Recursive":false}]
```
+ Unter Windows erfassen Sie rekursiv Metadaten aller „.exe“-Dateien im Ordner Programme, einschließlich der Unterverzeichnisse.
```
[{"Path":"C:\Program Files","Pattern":["*.exe"],"Recursive":true}]
```
+ Unter Windows erfassen Sie Metadaten bestimmter Log-Muster.
```
[{"Path":"C:\ProgramData\Amazon","Pattern":["*amazon*.log"],"Recursive":true}]
```
+ Beschränken Sie die Anzahl der Verzeichnisse, wenn Sie eine rekursive Erfassung durchführen.
```
[{"Path":"C:\Users","Pattern":["*.ps1"],"Recursive":true, "DirScanLimit": 1000}]
```
**Windows Registry**: Sie können Schlüssel und Werte der Windows Registry erfassen. Sie können einen Schlüssel-Pfad auswählen und alle Schlüssel und Werte rekursiv erfassen. Sie können auch einen bestimmten Registrierungsschlüssel und seinen Wert für einen bestimmten Pfad erfassen. Inventory erfasst den Schlüsselpfad, den Namen, Typ und Wert.
```
{
"Path": string,
"Recursive": true,
"ValueNames": array[string] // optional
}
```
+ **Path**: Der Pfad zum Registry-Schlüssel.
+ **Recursive**: Ein Boolescher Wert, der angibt, ob Inventory die Registry-Pfade rekursiv durchlaufen soll.
+ **ValueNames**: Eine Reihe von Wertnamen für die Inventarisierung von Registrierungsschlüsseln. Wenn Sie diesen Parameter verwenden, inventarisiert Systems Manager nur die angegebenen Wertenamen für den angegebenen Pfad.
**Anmerkung**
Inventory erfasst Metadaten für maximal 250 Registry-Schlüsselwerte für alle angegebenen Pfade.
Hier finden Sie einige Beispiele, wie Sie die Parameter angeben, wenn Sie eine Inventarisierung der Windows Registry vornehmen wollen.
+ Erfassen Sie alle Schlüssel und Werte rekursiv für einen bestimmten Pfad.
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon","Recursive": true}]
```
+ Erfassen Sie alle Schlüssel und Werte für einen bestimmten Pfad (die rekursive Suche ist deaktiviert).
```
[{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Intel\PSIS\PSIS_DECODER", "Recursive": false}]
```
+ Erfasst einen bestimmten Schlüssel unter Verwendung der Option `ValueNames`.
```
{"Path":"HKEY_LOCAL_MACHINE\SOFTWARE\Amazon\MachineImage","ValueNames":["AMIName"]}
```
# Einrichten von Systems Manager Inventory
Bevor Sie AWS Systems Manager Inventory verwenden, um Metadaten über die Anwendungen, Dienste, AWS Komponenten und mehr zu sammeln, die auf Ihren verwalteten Knoten ausgeführt werden, empfehlen wir Ihnen, die Ressourcendatensynchronisierung zu konfigurieren, um die Speicherung Ihrer Inventardaten in einem einzigen Amazon Simple Storage Service (Amazon S3) -Bucket zu zentralisieren. Wir empfehlen Ihnen außerdem, die EventBridge Amazon-Überwachung von Inventarereignissen zu konfigurieren. Diese Prozesse erleichtern das Anzeigen und Verwalten von Bestandsdaten und -sammlungen.
**Topics**
+ [Erstellen einer Resource Data Sync für Inventory](inventory-create-resource-data-sync.md)
+ [EventBridge Zur Überwachung von Inventarereignissen verwenden](systems-manager-inventory-setting-up-eventbridge.md)
# Erstellen einer Resource Data Sync für Inventory
In diesem Thema wird beschrieben, wie Sie die Ressourcendatensynchronisierung für AWS Systems Manager -Inventar einrichten und konfigurieren. Informationen zu Resource Data Sync für Systems Manager Explorer finden Sie unter [Einrichten von Systems Manager Explorer, um Daten aus mehreren Konten und Regionen anzuzeigen](Explorer-resource-data-sync.md).
## Über Resource Data Sync
Sie können mit der Ressourcen-Datensynchronisierung von Systems Manager Bestandsdaten aus allen Ihren verwalteten Knoten an einen einzelnen Amazon Simple Storage Service (Amazon S3)-Bucket senden. Resource Data Sync aktualisiert die Daten dann automatisch, wenn neue Bestandsdaten erfasst werden. Da alle Inventardaten in einem Amazon S3 S3-Ziel-Bucket gespeichert sind, können Sie Dienste wie Amazon Athena und Amazon Quick verwenden, um die aggregierten Daten abzufragen und zu analysieren.
Sie können Inventory z. B. so konfigurieren, dass Daten über das Betriebssystem (OS) und die Anwendungen erfasst werden, die auf eine Flotte von 150 verwalteten Knoten ausgeführt werden. Einige dieser Knoten befinden sich in einem On-Premises-Rechenzentrum und andere werden in Amazon Elastic Compute Cloud (Amazon EC2) über mehrere AWS-Regionen hinweg ausgeführt. Wenn Sie die Ressourcen-Datensynchronisierung *nicht* konfiguriert haben, müssen Sie die erfassten Bestandsdaten für jeden verwalteten Knoten manuell einholen oder Sie müssen entsprechende Skripts erstellen, die diese Informationen sammeln. Anschließend müssten Sie die Daten in eine Anwendung portieren, um Abfragen ausführen und diese analysieren zu können.
Mit der Ressourcen-Datensynchronisierung führen Sie eine einmalige Operation aus, die alle Bestandsdaten von allen Ihren verwalteten Knoten synchronisiert. Wenn die Synchronisierung erfolgreich erstellt wurde, erstellt Systems Manager eine Ausgangsbasis mit allen Bestandsdaten und speichert diese in dem jeweiligen Amazon S3-Ziel-Bucket. Wenn neue Bestandsdaten erfasst werden, aktualisiert Systems Manager die Daten in dem Amazon S3-Bucket automatisch. Anschließend können Sie die Daten schnell und kostengünstig nach Amazon Athena und Amazon Quick portieren.
Diagramm 1 zeigt, wie Bestandsdaten von Amazon EC2 und anderen Maschinentypen in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) in einem Ziel-Amazon-S3-Bucket zusammengeführt werden. Dieses Diagramm zeigt auch, wie die Ressourcendatensynchronisierung mit mehreren AWS-Konten und funktioniert. AWS-Regionen
**Diagramm 1: Synchronisieren von Ressourcendaten mit mehreren AWS-Konten und AWS-Regionen**
![\[Architektur von Systems Manager Resource Data Sync\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-resource-data-sync-updated.png)
Wenn Sie einen verwalteten Knoten löschen, behält die Ressourcen-Datensynchronisierung die Bestandsdatei für den gelöschten Knoten bei. Für ausgeführte Knoten überschreibt die Ressourcen-Datensynchronisierung die alte Bestandsdatei jedoch automatisch, wenn neue Dateien erstellt und in den Amazon-S3-Bucket geschrieben werden. Wenn Sie Inventaränderungen im Laufe der Zeit verfolgen möchten, können Sie den AWS Config Dienst verwenden, um den `SSM:ManagedInstanceInventory` Ressourcentyp zu verfolgen. Weitere Informationen finden Sie unter [Erste Schritte mit AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html).
Gehen Sie wie in diesem Abschnitt beschrieben vor, um mithilfe von Amazon S3 und AWS Systems Manager Konsolen eine Ressourcendatensynchronisierung für Inventory zu erstellen. Sie können sie auch verwenden AWS CloudFormation , um eine Ressourcendatensynchronisierung zu erstellen oder zu löschen. Um sie zu verwenden CloudFormation, fügen Sie die [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)Ressource zu Ihrer CloudFormation Vorlage hinzu. Informationen dazu finden Sie in einer der folgenden Dokumentationsressourcen:
+ [AWS CloudFormation Ressource für die Synchronisation von Ressourcendaten in AWS Systems Manager](https://aws.amazon.com/blogs/mt/aws-cloudformation-resource-for-resource-data-sync-in-aws-systems-manager/) (Blog)
+ [Arbeiten mit AWS CloudFormation -Vorlagen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html) im *AWS CloudFormation -Benutzerhandbuch*
**Anmerkung**
Sie können AWS Key Management Service (AWS KMS) verwenden, um Inventardaten im Amazon S3 S3-Bucket zu verschlüsseln. Ein Beispiel dafür, wie Sie mithilfe von AWS Command Line Interface (AWS CLI) eine verschlüsselte Synchronisation erstellen und wie Sie mit den zentralisierten Daten in Amazon Athena und Amazon Quick arbeiten, finden Sie unter[Walkthrough: Verwenden von Resource Data Sync zum Aggregieren von Bestandsdaten](inventory-resource-data-sync.md).
## Bevor Sie beginnen
Bevor Sie eine Ressourcendatensynchronisierung erstellen, verwenden Sie das folgende Verfahren, um einen zentralen Amazon S3-Bucket zum Speichern aggregierter Bestandsdaten zu erstellen. Das Verfahren beschreibt, wie Sie eine Bucket-Richtlinie zuweisen, die es Systems Manager ermöglicht, Bestandsdaten aus mehreren Konten in den Bucket zu schreiben. Wenn Sie bereits über einen Amazon S3-Bucket verfügen, den Sie zum Aggregieren von Bestandsdaten für die Ressourcendatensynchronisierung verwenden möchten, müssen Sie den Bucket so konfigurieren, dass die Richtlinie im folgenden Verfahren verwendet wird.
**Anmerkung**
Systems Manager Inventory kann keine Daten zu einem angegebenen Amazon S3-Bucket hinzufügen, wenn dieser Bucket für die Verwendung von Object Lock konfiguriert ist. Stellen Sie sicher, dass der Amazon S3-Bucket, den Sie für die Resource Data Sync erstellen oder auswählen, nicht für die Verwendung von Amazon S3 Object Lock konfiguriert ist. Weitere Informationen finden Sie unter [Funktionsweise von Amazon S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
**So erstellen und konfigurieren Sie einen Amazon S3-Bucket für Resource Data Sync**
1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Erstellen Sie einen Bucket zum Speichern der aggregierten Bestandsdaten. Weitere Informationen finden Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*. Notieren Sie sich den Namen des Buckets und den AWS-Region Ort, an dem Sie ihn erstellt haben.
1. Klicken Sie auf die Registerkarte **Permissions** (Berechtigungen) und anschließend auf **Bucket Policy** (Bucket-Richtlinie).
1. Kopieren Sie die folgende Bucket-Richtlinie in den Richtlinien-Editor. *amzn-s3-demo-bucket*Ersetzen Sie ihn durch den Namen des S3-Buckets, den Sie erstellt haben. *account\$1ID\$1number*Ersetzen Sie es durch eine gültige AWS-Konto ID-Nummer.
------
#### [ 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. Speichern Sie Ihre Änderungen.
## Erstellen einer Resource Data Sync für Inventory
Führen Sie die folgenden Schritte aus, um mit der Systems Manager-Konsole eine Ressource Data Sync for Systems Manager Inventory zu erstellen. Informationen zum Erstellen einer Ressourcendatensynchronisierung mithilfe von finden Sie unter[Verwenden von AWS CLI , um die Inventardatenerfassung zu konfigurieren](inventory-collection-cli.md). AWS CLI
**So erstellen Sie eine Ressourcendaten-Synchronisierung**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie im Menü **Account management (Kontoverwaltung)** die Option **Resource Data Sync (Ressourcendaten)**.
1. Wählen Sie **Ressourcen-Datensynchronisierung erstellen**.
1. Geben Sie im Feld **Sync name** einen Namen für die Synchronisierungskonfiguration ein.
1. Geben Sie in das Feld **Bucket name (Bucket-name)** den Namen des Amazon S3-Buckets ein, das Sie mit dem Verfahren **To create and configure an Amazon S3 bucket for resource data sync (Erstellen und Konfigurieren eines Amazon S3-Buckets für Ressource Data Sync)** erstellt haben.
1. (Optional) Geben Sie im Feld **Bucket prefix (Bucket-Präfix)** den Namen eines Amazon S3-Bucket-Präfixes (Unterverzeichnis) an.
1. Wählen Sie im Feld **Bucket region (Bucket-Region)** die Option **This region (Diese Region)** aus, wenn sich der erstellte Amazon S3-Bucket in der aktuellen AWS-Region befindet. Befindet sich der erstellte Bucket in einer anderen AWS-Region, wählen Sie **Another region (Andere Region)** aus und geben den Namen der Region an.
**Anmerkung**
Wenn sich der Synchronisierungs- und der Amazon S3-Ziel-Bucket in verschiedenen Regionen befinden, können Kosten für Datenübertragung anfallen. Weitere Informationen finden Sie unter [Amazon S3 – Preise](https://aws.amazon.com/s3/pricing/).
1. (Optional) Geben Sie im Feld **KMS Key ARN (KMS-Schlüssel-ARN)** einen KMS-Schlüssel-ARN zum Verschlüsseln von Bestandsdaten in Amazon S3 ein oder fügen Sie einen ein.
1. Wählen Sie **Erstellen** aus.
Um Inventardaten aus mehreren zu synchronisieren AWS-Regionen, müssen Sie in *jeder* Region eine Ressourcendatensynchronisierung einrichten. Wiederholen Sie diesen Vorgang an jedem AWS-Region Ort, an dem Sie Inventardaten sammeln und an den zentralen Amazon S3 S3-Bucket senden möchten. Wenn Sie die Synchronisierung in jeder Region erstellen, geben Sie den zentralen Amazon S3-Bucket im **Bucket name (Bucket-Name)** an. Verwenden Sie dann die Option **Bucket region (Bucket-Region)**, um die Region auszuwählen, in der Sie den zentralen Amazon S3-Bucket erstellt haben, wie im folgenden Screenshot gezeigt. Wenn die Zuordnung zu Erfassen von Bestandsdaten das nächste Mal ausgeführt wird, speichert Systems Manager die Daten im zentralen Amazon S3-Bucket.
![\[Systems Manager Manager-Ressourcendatensynchronisierung von mehreren AWS-Regionen\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-rds-multiple-regions.png)
## Erstellen einer Synchronisierung von Inventarressourcendaten für Konten, die in definiert sind AWS Organizations
Sie können Inventardaten von AWS-Konten Defined in AWS Organizations mit einem zentralen Amazon S3 S3-Bucket synchronisieren. Nachdem Sie das folgende Verfahren abgeschlossen haben, werden Bestandsdaten mit *einzelnen* Amazon S3-Schlüsselpräfixen im zentralen Bucket synchronisiert. Jedes key prefix steht für eine andere AWS-Konto ID.
**Bevor Sie beginnen**
Bevor Sie beginnen, stellen Sie sicher, dass Sie AWS-Konten in eingerichtet und konfiguriert haben AWS Organizations. Weitere Informationen finden Sie unter [*im AWS Organizations -Benutzerhandbuch*.](https://docs.aws.amazon.com/organizations/latest/userguide/rgs_getting-started.html)
Beachten Sie außerdem, dass Sie die organisationsbasierte Ressourcendatensynchronisierung für jede Ressource erstellen müssen AWS-Region und dass unter AWS-Konto definiert ist. AWS Organizations
### Erstellen eines zentralen Amazon S3-Buckets
Verwenden Sie das folgende Verfahren, um einen zentralen Amazon S3-Bucket zum Speichern aggregierter Bestandsdaten zu erstellen. Das Verfahren beschreibt, wie Sie eine Bucket-Richtlinie zuweisen, die es Systems Manager ermöglicht, Bestandsdaten aus Ihrer AWS Organizations -Konto-ID in den Bucket zu schreiben. Wenn Sie bereits über einen Amazon S3-Bucket verfügen, den Sie zum Aggregieren von Bestandsdaten für die Ressourcendatensynchronisierung verwenden möchten, müssen Sie den Bucket so konfigurieren, dass die Richtlinie im folgenden Verfahren verwendet wird.
**Um einen Amazon S3 S3-Bucket für die Ressourcendatensynchronisierung für mehrere Konten zu erstellen und zu konfigurieren, definiert in AWS Organizations**
1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Erstellen Sie einen Bucket zum Speichern der aggregierten Bestandsdaten. Weitere Informationen finden Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*. Notieren Sie sich den Namen des Buckets und den AWS-Region Ort, an dem Sie ihn erstellt haben.
1. Klicken Sie auf die Registerkarte **Permissions** (Berechtigungen) und anschließend auf **Bucket Policy** (Bucket-Richtlinie).
1. Kopieren Sie die folgende Bucket-Richtlinie in den Richtlinien-Editor. Ersetzen Sie *amzn-s3-demo-bucket * und *organization-id* durch den Namen des Amazon S3 S3-Buckets, den Sie erstellt haben, und durch eine gültige AWS Organizations Konto-ID.
Optional können Sie es *bucket-prefix* durch den Namen eines Amazon S3 S3-Präfix (Unterverzeichnis) ersetzen. Wenn Sie kein Präfix erstellt haben, entfernen Sie in der folgenden Richtlinie*bucket-prefix*/aus dem ARN.
------
#### [ 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=*/*"
]
}
]
}
```
------
### Erstellen Sie eine Synchronisierung der Inventarressourcendaten für Konten, die in definiert sind AWS Organizations
Das folgende Verfahren beschreibt, wie Sie mithilfe von eine Ressourcendatensynchronisierung für Konten erstellen, die in definiert sind AWS Organizations. AWS CLI Sie müssen den verwenden AWS CLI , um diese Aufgabe auszuführen. Sie müssen dieses Verfahren auch für jedes AWS-Region Verfahren ausführen, das AWS-Konto unter definiert ist AWS Organizations.
**Um eine Ressourcendatensynchronisierung für ein in AWS Organizations (AWS CLI) definiertes Konto zu erstellen**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob keine anderen auf *AWS Organizations basierten* Resource Data Syncs vorhanden sind. Sie können mehrere Standardsynchronisierungen haben, einschließlich mehrerer Standardsynchronisierungen und einer organisationsbasierten Synchronisierung. Sie können jedoch nur eine organisationsbasierte Ressourcendatensynchronisierung durchführen.
```
aws ssm list-resource-data-sync
```
Wenn der Befehl andere organisationsbasierte Ressourcendatensynchronisierungen zurückgibt, müssen Sie diese löschen oder sich dafür entscheiden, keine neue zu erstellen.
1. Führen Sie den folgenden Befehl aus, um eine Ressourcendatensynchronisierung für ein Konto zu erstellen, das in AWS Organizations definiert ist. Geben Sie für amzn-s3-demo-bucket den Namen des Amazon-S3-Buckets an, den Sie zuvor in diesem Thema erstellt haben. Wenn Sie ein Präfix (Unterverzeichnis) für Ihren Bucket erstellt haben, geben Sie diese Information für *prefix-name* an.
```
aws ssm create-resource-data-sync --sync-name name --s3-destination "BucketName=amzn-s3-demo-bucket,Prefix=prefix-name,SyncFormat=JsonSerDe,Region=AWS-Region, for example us-east-2,DestinationDataSharing={DestinationDataSharingType=Organization}"
```
1. Wiederholen Sie die Schritte 2 und 3 für alle AWS-Region Bereiche AWS-Konto , in denen Sie Daten mit dem zentralen Amazon S3 S3-Bucket synchronisieren möchten.
### Ressourcendatensynchronisierungen verwalten
In jedem AWS-Konto Fall können 5 Ressourcendatensynchronisierungen durchgeführt werden. AWS-Region Sie können die AWS Systems Manager Fleet Manager Konsole verwenden, um Ihre Ressourcendatensynchronisierungen zu verwalten.
**Um Ressourcendatensynchronisierungen anzuzeigen**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie im Menü-Dropdown **Kontoverwaltung** die Option **Ressourcendatensynchronisierung**.
1. Wählen Sie eine Ressourcendatensynchronisierung aus der Tabelle aus, und klicken Sie dann auf **Details anzeigen**, um Informationen zu Ihrer Ressourcendatensynchronisierung anzuzeigen.
**So löschen Sie eine Ressourcendaten-Synchronisierung**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie im Menü-Dropdown **Kontoverwaltung** die Option **Ressourcendatensynchronisierung**.
1. Wählen Sie eine Ressourcendatensynchronisierung aus der Tabelle aus, und klicken Sie dann auf **Löschen**.
# EventBridge Zur Überwachung von Inventarereignissen verwenden
Sie können in Amazon eine Regel konfigurieren EventBridge , um ein Ereignis als Reaktion auf Änderungen des Status der AWS Systems Manager Inventarressourcen zu erstellen. EventBridge unterstützt Ereignisse für die folgenden Änderungen des Inventarstatus. Alle Ereignisse werden auf bestmögliche Weise ausgegeben.
**Benutzerdefinierter Inventartyp wurde für eine bestimmte Instanz gelöscht**: Wenn eine Regel für die Überwachung dieses Ereignisses konfiguriert ist, wird EventBridge ein Ereignis ausgelöst, wenn ein benutzerdefinierter Inventartyp für eine bestimmte verwaltete Instanz gelöscht wird. EventBridgesendet ein Ereignis pro Knoten und benutzerdefiniertem Inventartyp. Hier ist ein Beispielereignismuster.
```
{
"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"
}
}
```
**Ereignis beim Löschen eines benutzerdefinierten Inventartyps für alle Instanzen**: Wenn eine Regel für die Überwachung dieses Ereignisses konfiguriert ist, wird EventBridge ein Ereignis ausgelöst, wenn ein benutzerdefinierter Inventartyp für alle verwalteten Knoten gelöscht wird. Hier ist ein Beispielereignismuster.
```
{
"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"
}
}
```
**[PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)Ereignis „Aufruf mit alter Schemaversion**“: Wenn eine Regel für die Überwachung dieses Ereignisses konfiguriert ist, wird EventBridge ein Ereignis ausgelöst, wenn ein PutInventory Aufruf erfolgt, der eine Schemaversion verwendet, die niedriger als die aktuelle Schemaversion ist. Dieses Ereignis gilt für alle Inventararten. Hier ist ein Beispielereignismuster.
```
{
"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"
}
}
```
Hinweise EventBridge zur Konfiguration der Überwachung dieser Ereignisse finden Sie unter[Konfiguration EventBridge für Systems Manager Manager-Ereignisse](monitoring-systems-manager-events.md).
# Konfigurieren der Bestandserfassung
In diesem Abschnitt wird beschrieben, wie Sie die AWS Systems Manager Inventarerfassung auf einem oder mehreren verwalteten Knoten mithilfe der Systems Manager Manager-Konsole konfigurieren. Ein Beispiel für die Konfiguration der Inventarerfassung mithilfe von AWS Command Line Interface (AWS CLI) finden Sie unter[Verwenden von AWS CLI , um die Inventardatenerfassung zu konfigurieren](inventory-collection-cli.md).
Wenn Sie die Inventarerfassung konfigurieren, erstellen Sie zunächst eine AWS Systems Manager State Manager Zuordnung. Systems Manager erfasst die Bestandsdaten, wenn der Zuordnungsstatus ausgeführt wird. Wenn Sie die Zuordnung nicht zuerst erstellen und versuchen, das `aws:softwareInventory` Plug-in beispielsweise mithilfe von aufzurufen, gibt das System den folgenden Fehler zurück: AWS Systems Manager Run Command `The aws:softwareInventory plugin can only be invoked via ssm-associate.`
**Anmerkung**
Beachten Sie das folgende Verhalten, wenn Sie mehrere Bestandszuordnungen für einen verwalteten Knoten erstellen:
Jedem Knoten kann eine Inventarzuordnung zugewiesen werden, die auf *alle* Knoten abzielt (--targets „Key=InstanceIds, Values=\$1“).
Jedem Knoten kann auch eine bestimmte Assoziation zugewiesen werden, die entweder key/value Tag-Paare oder eine Ressourcengruppe verwendet. AWS
Wenn einem Knoten mehrere Bestandszuordnungen zugewiesen sind, zeigt der Status *Skipped* (Übersprungen) für die Zuordnung an, die nicht ausgeführt wurde. Die zuletzt durchgeführte Zuordnung zeigt den aktuellen Status der Bestandszuordnung an.
Wenn einem Knoten mehrere Inventarzuordnungen zugewiesen sind und jede ein key/value Tag-Paar verwendet, können diese Inventarzuordnungen aufgrund des Tag-Konflikts nicht auf dem Knoten ausgeführt werden. Die Zuordnung wird immer noch auf Knoten ausgeführt, bei denen der key/value Tagkonflikt nicht vorliegt.
**Bevor Sie beginnen**
Führen Sie die folgenden Aufgaben aus, bevor Sie die Bestandserfassung konfigurieren.
+ Aktualisieren Sie AWS Systems Manager SSM Agent die Knoten, die Sie inventarisieren möchten. Durch Ausführen der neuesten Version von SSM Agent stellen Sie sicher, dass Sie Metadaten für alle unterstützten Bestandstypen sammeln können. Informationen zur Aktualisierung von SSM Agent mithilfe von State Manager finden Sie unter [Exemplarische Vorgehensweise: Automatisches Update SSM Agent mit dem AWS CLI](state-manager-update-ssm-agent-cli.md).
+ Überprüfen Sie, ob Sie die Einrichtungsanforderungen für Ihre Instances der Amazon Elastic Compute Cloud (Amazon EC2) und Nicht-EC2-Maschinen in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) erfüllt haben. Weitere Informationen finden Sie unter [Einrichtung verwalteter Knoten für AWS Systems Manager](systems-manager-setting-up-nodes.md).
+ Stellen Sie für Windows Server Microsoft-Knoten sicher, dass Ihr verwalteter Knoten mit Windows PowerShell 3.0 (oder höher) konfiguriert ist. SSM Agentverwendet das `ConvertTo-Json` Cmdlet in PowerShell , um die Windows Update-Inventardaten in das erforderliche Format zu konvertieren.
+ (Optional) Erstellen Sie eine Resource Data Sync, um Bestandsdaten zentral in einem Amazon S3-Bucket zu speichern. Resource Data Sync aktualisiert die Daten dann automatisch, wenn neue Bestandsdaten erfasst werden. Weitere Informationen finden Sie unter [Walkthrough: Verwenden von Resource Data Sync zum Aggregieren von Bestandsdaten](inventory-resource-data-sync.md).
+ (Optional) Erstellen Sie eine JSON-Datei für das Erfassen des benutzerdefinierten Bestands. Weitere Informationen finden Sie unter [Arbeiten mit benutzerdefiniertem Bestand](inventory-custom.md).
## Inventarisieren Sie alle verwalteten Knoten in Ihrem AWS-Konto
Sie können alle verwalteten Knoten in Ihrem inventarisieren, AWS-Konto indem Sie eine globale Inventarzuordnung erstellen. Eine globale Bestandszuordnung führt die folgenden Aktionen aus:
+ Wendet die globale Inventarkonfiguration (Zuordnung) automatisch auf alle vorhandenen verwalteten Knoten in Ihrem an AWS-Konto. Verwaltete Knoten, die bereits über eine Bestandszuordnung verfügen, werden übersprungen, wenn die globale Bestandszuordnung angewendet wurde und ausgeführt wird. Wenn ein Knoten ausgelassen wird, zeigt die detaillierte Statusmeldung `Overridden By Explicit Inventory Association` an. Diese Knoten werden von der globalen Zuordnung übersprungen, sie melden aber immer noch den Bestand, wenn sie ihre zugewiesene Bestandszuordnung ausführen.
+ Fügt neue Knoten, die in Ihrem erstellt wurden, automatisch AWS-Konto zur globalen Inventarzuordnung hinzu.
**Anmerkung**
Wenn ein verwalteter Knoten für die globale Bestandszuordnung konfiguriert ist und Sie diesem Knoten eine bestimmte Zuordnung zuweisen, dann stellt Systems Manager Inventory die globale Zuordnung zurück und wendet die spezifische Zuordnung an.
Globale Bestandszuordnungen sind in SSM Agent-Version 2.0.790.0 oder höher verfügbar. Weitere Informationen zur Aktualisierung von SSM Agent auf Ihren Knoten finden Sie unter [Aktualisierung von SSM Agent mithilfe von Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
### Konfigurieren der Bestandserfassung mit einem Klick (Konsole)
Gehen Sie wie folgt vor, um Systems Manager Inventory für alle verwalteten Knoten in Ihrem AWS-Konto und in einem einzigen zu konfigurieren AWS-Region.
**So konfigurieren Sie all Ihre verwalteten Knoten in der aktuellen Region für Systems Manager Inventory**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Inventory**.
1. Wählen Sie auf der Karte **Managed instances with inventory enabled (Verwaltete Instances mit aktiviertem Bestand)** die Option **Click here to enable inventory on all instances (Klicken Sie hier, um den Bestand für alle Instances zu aktivieren)** aus.
![\[Aktivieren von Systems Manager Inventory für alle verwalteten Knoten.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-one-click-1.png)
Wurde dieser Vorgang erfolgreich abgeschlossen, zeigt die Konsole die folgende Meldung an.
![\[Aktivieren von Systems Manager Inventory für alle verwalteten Knoten.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-one-click-2.png)
Je nach Anzahl der verwalteten Knoten in Ihrem Konto kann es einige Minuten dauern, bis die globale Bestandszuordnung angewendet wird. Warten Sie ein paar Minuten und aktualisieren Sie dann die Seite. Überprüfen Sie, ob die Konfiguration des Bestands auf all Ihren verwalteten Knoten in der Grafik entsprechend angezeigt wird.
### Konfigurieren der Erfassung über die Konsole
Dieser Abschnitt enthält Informationen zum Konfigurieren von Systems Manager Inventory für das Sammeln von Metadaten aus Ihren verwalteten Knoten mithilfe der Systems-Manager-Konsole. Sie können schnell Metadaten von allen Knoten in einem bestimmten AWS-Konto (und allen future Knoten, die möglicherweise in diesem Konto erstellt werden) sammeln oder Sie können Inventardaten selektiv mithilfe von Tags oder Knoten IDs sammeln.
**Anmerkung**
Bevor Sie dieses Verfahren ausführen, prüfen Sie, ob bereits eine globale Bestandszuordnung existiert. Wenn bereits eine globale Bestandszuordnung vorhanden ist, wird diese bei jedem Start einer neuen Instance auf diese angewendet und die neue Instance wird inventarisiert.
**So konfigurieren Sie die Bestandserfassung**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Inventory**.
1. Wählen Sie die Option **Setup Inventory**.
1. Identifizieren Sie im Abschnitt **Targets** (Ziele) die Knoten, auf denen Sie diese Operation ausführen möchten, indem Sie eine der folgenden Optionen auswählen.
+ **Auswählen aller verwalteten Instances in diesem Konto** – Diese Option wählt alle verwalteten Knoten aus, für die es keine Bestandszuordnung gibt. Wenn Sie diese Option auswählen, werden Knoten, für die bereits Bestandszuordnungen durchgeführt wurden, während der Bestandserfassung übersprungen und mit dem Status **Skipped** (Übersprungen) in den Bestandsergebnissen angezeigt. Weitere Informationen finden Sie unter [Inventarisieren Sie alle verwalteten Knoten in Ihrem AWS-Konto](#inventory-management-inventory-all).
+ **Specifying a tag** (Angeben eines Tags) – Mit dieser Option können Sie ein einzelnes Tag zum Identifizieren von Knoten in Ihrem Konto angeben, aus denen Sie den Bestand erfassen möchten. Wenn Sie ein Tag verwenden, wird jeder in der Zukunft mit demselben Tag erstellte Knoten den Bestand ebenfalls melden. Wenn bereits eine Bestandszuordnung für alle Knoten besteht, überschreibt die Verwendung eines Tags zum Auswählen bestimmter Knoten als Ziel für einen anderen Bestand die Knoten-Mitgliedschaft in der Zielgruppe **Alle verwalteten Instances**. Verwaltete Knoten mit dem angegebenen Tag werden bei der künftigen Bestandserfassung von **Allen verwalteten Instances** übersprungen.
+ **Manually selecting instances** (Manuelles Auswählen von Instances) – Mit dieser Option können Sie bestimmte verwaltete Knoten in Ihrem Konto auswählen. Die explizite Auswahl bestimmter Knoten überschreibt bei Verwendung dieser Option die Bestandszuordnungen im Ziel **Alle verwalteten Instances**. Der Knoten wird bei der künftigen Bestandserfassung von **Alle verwalteten Instances** übersprungen.
**Anmerkung**
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
1. Wählen Sie im Bereich **Schedule** (Planung) aus, wie oft das System die Bestand-Metadaten in Ihren Knoten erfassen soll.
1. Verwenden Sie die Listen im Bereich **Parameters**, um die verschiedenen Typen der Bestandserfassung zu aktivieren oder zu deaktivieren. Weitere Informationen zur Erfassung von Datei- und Windows-Registry-Bestand finden Sie unter [Arbeiten mit Datei- und Windows-Registrierungsbestand](inventory-file-and-registry.md).
1. Wählen Sie im Bereich **Advanced (Erweitert)** die Option **Sync inventory execution logs to an Amazon S3 bucket (Bestandsausführungsprotokolle mit einem Amazon S3-Bucket synchronisieren)**, wenn Sie den Ausführungsstatus der Zuordnung in einem S3-Bucket speichern möchten.
1. Wählen Sie die Option **Setup Inventory**. Systems Manager erstellt eine State Manager-Zuordnung und führt sofort Inventory auf den Knoten aus.
1. Wählen Sie im Navigationsbereich **State Manager** aus. Überprüfen Sie, ob eine neue Zuordnung erstellt wurde, die das `AWS-GatherSoftwareInventory`-Dokument verwendet. Der Zuordnungszeitplan verwendet einen Rate-Ausdruck. Überprüfen Sie auch, ob das Feld **Status** den Wert **Success** enthält. Wenn Sie die Option **Sync inventory execution logs to an S3 bucket (Inventory-Ausführungsprotokolle mit einem S3-Bucket synchronisieren)** ausgewählt haben, können Sie die Protokolldaten nach einigen Minuten in Amazon S3 anzeigen. Wenn Sie Bestandsdaten für einen bestimmten Knoten anzeigen möchten, klicken Sie auf **Managed Instances** (Verwaltete Instances) im Navigationsbereich.
1. Wählen Sie einen Knoten und anschließend **View details** (Details anzeigen).
1. Wählen Sie auf der Knoten-Detailseite **Inventory** aus. Verwenden Sie die **Inventory type**-Listen, um den Bestand zu filtern.
# Abfragen von Bestandsdaten aus mehreren Regionen und Konten
AWS Systems Manager Inventory ist in Amazon Athena integriert, sodass Sie Inventardaten von mehreren AWS-Regionen und AWS-Konten abfragen können. Die Athena-Integration verwendet die Ressourcendatensynchronisierung, sodass Sie Inventardaten von all Ihren verwalteten Knoten auf der **Detailansichtsseite in der AWS Systems Manager Konsole anzeigen** können.
**Wichtig**
Diese Funktion wird verwendet AWS Glue , um die Daten in Ihrem Amazon Simple Storage Service (Amazon S3) -Bucket zu crawlen, und Amazon Athena, um die Daten abzufragen. Abhängig davon, wie viele Daten durchsucht und abgefragt werden, werden Ihnen diese Services in Rechnung gestellt. Mit AWS Glue zahlen Sie einen Stundensatz, der sekundengenau abgerechnet wird, für Crawler (Erkennung von Daten) und ETL-Jobs (Verarbeitung und Laden von Daten). Bei Athena richtet sich die Gebühr nach der Menge der pro Abfrage durchsuchten Daten. Wir empfehlen Ihnen, die Preisrichtlinien für diese Services zu lesen, bevor Sie die Amazon Athena-Integration mit Systems Manager Inventory verwenden. Weitere Informationen finden Sie unter [Amazon Athena – Preise](https://aws.amazon.com/athena/pricing/) und [AWS Glue -Preise](https://aws.amazon.com/glue/pricing/).
Sie können Inventory-Daten auf der Seite **Detailed View (Detailsansicht** in allen AWS-Regionen anzeigen, in denen Amazon Athena verfügbar ist. Eine Liste der unterstützten Regionen finden Sie unter [Amazon Athena-Service-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/athena.html#athena_region) im *Allgemeine Amazon Web Services-Referenz*.
**Bevor Sie beginnen**
Die Athena-Integration verwendet Resource Data Sync. Sie müssen Resource Data Sync einrichten und konfigurieren, um dieses Feature zu verwenden. Weitere Informationen finden Sie unter [Walkthrough: Verwenden von Resource Data Sync zum Aggregieren von Bestandsdaten](inventory-resource-data-sync.md).
Beachten Sie außerdem, dass die **Detailed View (Detailansicht** Bestandsdaten für den *Besitzer* des zentralen Amazon S3-Buckets anzeigt, der von Resource Data Sync verwendet wird. Wenn Sie nicht der Besitzer des zentralen Amazon S3-Buckets sind, werden Ihnen auf der Seite **Detailed View (Detailansicht)** keine Bestandsdaten angezeigt.
## Zugriff konfigurieren
Bevor Sie Daten aus mehreren Konten und Regionen auf der Seite **Detailsansicht** in der Systems-Manager-Konsole abfragen und anzeigen können, müssen Sie Ihre (IAM)-Entität mit Berechtigungen zur Ansicht der Daten konfigurieren.
Wenn die Inventardaten in einem Amazon S3 S3-Bucket gespeichert sind, der die Verschlüsselung AWS Key Management Service (AWS KMS) verwendet, müssen Sie auch Ihre IAM-Entität und die `Amazon-GlueServiceRoleForSSM` Servicerolle für die AWS KMS Verschlüsselung konfigurieren.
**Topics**
+ [Konfigurieren Ihrer IAM-Entität für den Zugriff auf die Seite Detailansicht](#systems-manager-inventory-query-iam-user)
+ [(Optional) Konfigurieren Sie Berechtigungen für die Anzeige AWS KMS verschlüsselter Daten](#systems-manager-inventory-query-kms)
### Konfigurieren Ihrer IAM-Entität für den Zugriff auf die Seite Detailansicht
Im Folgenden werden die Mindestberechtigungen beschrieben, die zum Anzeigen von Bestandsdaten auf der Seite **Detailansicht** erforderlich sind.
Die von `AWSQuicksightAthenaAccess` verwaltete Richtlinie
Die folgende `PassRole` und der zusätzliche erforderliche Berechtigungsblock
------
#### [ 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/*"
}
]
}
```
------
(Optional) Wenn der Amazon S3 S3-Bucket, der zum Speichern von Inventardaten verwendet wird AWS KMS, mithilfe von verschlüsselt ist, müssen Sie der Richtlinie auch den folgenden Block hinzufügen.
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
Um Zugriff zu gewähren, fügen Sie Ihren Benutzern, Gruppen oder Rollen Berechtigungen hinzu:
+ Benutzer und Gruppen in AWS IAM Identity Center:
Erstellen Sie einen Berechtigungssatz. Befolgen Sie die Anweisungen unter [Erstellen eines Berechtigungssatzes](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
+ Benutzer, die in IAM über einen Identitätsanbieter verwaltet werden:
Erstellen Sie eine Rolle für den Identitätsverbund. Befolgen Sie die Anleitung unter [Eine Rolle für einen externen Identitätsanbieter (Verbund) erstellen](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) im *IAM-Benutzerhandbuch*.
+ IAM-Benutzer:
+ Erstellen Sie eine Rolle, die Ihr Benutzer annehmen kann. Befolgen Sie die Anleitung unter [Eine Rolle für einen IAM-Benutzer erstellen](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) im *IAM-Benutzerhandbuch*.
+ (Nicht empfohlen) Weisen Sie einem Benutzer eine Richtlinie direkt zu oder fügen Sie einen Benutzer zu einer Benutzergruppe hinzu. Befolgen Sie die Anweisungen unter [Hinzufügen von Berechtigungen zu einem Benutzer (Konsole)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) im *IAM-Benutzerhandbuch*.
### (Optional) Konfigurieren Sie Berechtigungen für die Anzeige AWS KMS verschlüsselter Daten
Wenn der Amazon S3 S3-Bucket, der zum Speichern von Inventardaten verwendet wird, mithilfe von AWS Key Management Service (AWS KMS) verschlüsselt ist, müssen Sie Ihre IAM-Entität und die **GlueServiceRoleForAmazon-SSM-Rolle** mit `kms:Decrypt` Berechtigungen für den AWS KMS Schlüssel konfigurieren.
**Bevor Sie beginnen**
Um die `kms:Decrypt` Berechtigungen für den AWS KMS Schlüssel bereitzustellen, fügen Sie Ihrer IAM-Entität den folgenden Richtlinienblock hinzu:
```
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:Region:account_ID:key/key_ARN"
]
}
```
Falls Sie dies noch nicht getan haben, schließen Sie dieses Verfahren ab und fügen Sie `kms:Decrypt` Berechtigungen für den AWS KMS Schlüssel hinzu.
Gehen Sie wie folgt vor, um die **GlueServiceRoleForAmazon-SSM-Rolle** mit den `kms:Decrypt` Berechtigungen für den AWS KMS Schlüssel zu konfigurieren.
**So konfigurieren Sie die **GlueServiceRoleForAmazon-SSM-Rolle** mit Berechtigungen `kms:Decrypt`**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Wählen Sie im Navigationsbereich **Rollen** aus, und verwenden Sie dann das Suchfeld, um die **GlueServiceRoleForAmazon-SSM-Rolle** zu suchen. Die Seite **Summary (Übersicht)** wird geöffnet.
1. Verwenden Sie das Suchfeld, um die **GlueServiceRoleForAmazon-SSM-Rolle** zu finden. Wählen Sie den Rollennamen aus. Die Seite **Summary (Übersicht)** wird geöffnet.
1. Wählen Sie den Rollennamen aus. Die Seite **Summary (Übersicht)** wird geöffnet.
1. Wählen Sie **Inline-Richtlinie hinzufügen**. Die Seite **Create policy (Richtlinie erstellen)** wird geöffnet.
1. Wählen Sie den Tab **JSON**.
1. Löschen Sie den vorhandenen JSON-Text im Editor, kopieren Sie die folgende Richtlinie und fügen Sie sie in den JSON-Editor ein.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:us-east-1:111122223333:key/key_ARN"
]
}
]
}
```
------
1. Wählen Sie **Review policy** (Richtlinie überprüfen) aus.
1. Geben Sie auf der Seite **Review Policy (Richtlinie überprüfen)** im Feld **Name** einen Namen ein.
1. Wählen Sie **Richtlinie erstellen** aus.
## Abfragen von Daten auf der Seite „Inventory Detailed View (Detaillierte Bestandsansicht)“
Gehen Sie wie folgt vor, um Inventardaten von mehreren AWS-Regionen und AWS-Konten auf der Seite Inventar **Detailed View** von Systems Manager anzuzeigen.
**Wichtig**
Die Seite Inventory **Detailed View (Detailansicht)** ist nur in AWS-Regionen verfügbar, die Amazon Athena anbieten. Wenn die folgenden Registerkarten nicht auf der Seite Systems Manager Inventory angezeigt werden, bedeutet dies, dass Athena nicht in der Region verfügbar ist und Sie die **Detailansicht** nicht verwenden können, um Daten abzufragen.
![\[Anzeigen des Inventory-Dashboards | Detailed View (Detailansicht) | Registerkarte „Settings“ (Einstellungen)\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
**So zeigen Sie Inventardaten aus mehreren Regionen und Konten in der AWS Systems Manager Konsole an**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Inventory**.
1. Wählen Sie die Registerkarte **Detailed View (Detaillierte Ansicht)** aus.
![\[Zugriff auf die Seite mit der detaillierten Ansicht des AWS Systems Manager Inventars\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-detailed-view.png)
1. Wählen Sie die Resource Data Sync aus, für die Sie Daten abfragen möchten.
![\[Inventardaten in der AWS Systems Manager Konsole anzeigen\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-display-data.png)
1. Wählen Sie in der Liste **Inventory Type (Bestandstyp)** den Typ der Bestandsdaten aus, die Sie abfragen möchten, und drücken Sie dann Enter.
![\[Auswahl eines Inventartyps in der AWS Systems Manager Konsole\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-type.png)
1. Um die Daten zu filtern, wählen Sie die Filterleiste aus und wählen Sie dann eine Filteroption aus.
![\[Filtern von Inventardaten in der AWS Systems Manager Konsole\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-filter.png)
Sie können die Schaltfläche **Export to CSV (Exportieren in CSV)** verwenden, um die aktuelle Abfrage in einem Tabellenkalkulationsprogramm wie Microsoft Excel anzuzeigen. Sie können auch die Schaltflächen **Query History (Abfrageverlauf**) und **Run Advanced Queries (Erweiterte Abfragen ausführen)** verwenden, um mit Ihren Daten in Amazon Athena zu interagieren.
### Den AWS Glue Crawler-Zeitplan bearbeiten
AWS Glue crawlt standardmäßig zweimal täglich die Inventardaten im zentralen Amazon S3 S3-Bucket. Wenn Sie häufig die Arten der auf Ihren Knoten zu erfassenden Daten ändern, möchten Sie möglicherweise Sie die Daten häufiger durchsuchen, wie im folgenden Verfahren beschrieben.
**Wichtig**
AWS Glue AWS-Konto berechnet Ihnen für Crawler (Erkennung von Daten) und ETL-Jobs (Verarbeitung und Laden von Daten) einen Stundensatz, der sekundenweise abgerechnet wird. Bevor Sie den Crawler-Zeitplan anzeigen, rufen Sie die [AWS Glue -Preisliste](https://aws.amazon.com/glue/pricing/) auf.
**So ändern Sie den Bestandsdatencrawler-Zeitplan**
1. Öffnen Sie die AWS Glue Konsole unter. [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/)
1. Wählen Sie im Navigationsbereich **Crawlers (Crawler)** aus.
1. Wählen Sie in der Liste der Crawler die Option neben dem Systems Manager Inventory-Crawler aus. Der Crawler-Name verwendet das folgende Format:
`AWSSystemsManager-s3-bucket-name-Region-account_ID`
1. Wählen Sie **Action (Aktion)** und **Edit crawler (Crawler bearbeiten)** aus.
1. Wählen Sie im Navigationsbereich **Schedule (Zeitplan)** aus.
1. Geben Sie im Feld **Cron expression (cron-Ausdruck)** einen neuen Zeitplan mit einem Cron-Format an. Weitere Informationen zum Cron-Format finden Sie unter [Zeitpläne für Aufträge und Crawler](https://docs.aws.amazon.com/glue/latest/dg/monitor-data-warehouse-schedule.html) im *AWS Glue Developer Guide*.
**Wichtig**
Sie können den Crawler anhalten, damit keine Gebühren mehr von anfallen. AWS Glue Wenn Sie den Crawler aussetzen oder die Häufigkeit ändern, damit die Daten weniger häufig durchsucht werden, zeigt Inventory **Detailed View (Detaillierte Ansicht)** möglicherweise Daten an, die nicht aktuell sind.
# Abfragen der Bestandserfassung mithilfe von Filtern
Nachdem Sie Inventardaten erfasst haben, können Sie mithilfe der Filterfunktionen eine Liste verwalteter Knoten abfragen, die bestimmte Filterkriterien erfüllen. AWS Systems Manager
**So fragen Sie Knoten basierend auf Bestandsfiltern ab**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Inventory**.
1. Wählen Sie im Abschnitt **Filter by resource groups, tags or inventory types** die Filteroption. Eine Liste vordefinierter Filter wird angezeigt.
1. Wählen Sie ein Attribut, nach dem gefiltert werden soll. Wählen Sie zum Beispiel `AWS:Application` aus. Wenn Sie dazu aufgefordert werden, wählen Sie ein sekundäres Attribut, nach dem gefiltert werden soll. Wählen Sie zum Beispiel `AWS:Application.Name` aus.
1. Wählen Sie eine Begrenzung in der Liste aus. Wählen Sie z. B. **Begin with**. Im Filter wird ein Textfeld angezeigt.
1. Geben Sie einen Wert in das Textfeld ein. Geben Sie beispielsweise *Amazon* ein (SSM Agent ist als *Amazon SSM Agent benannt*).
1. Drücken Sie Enter. Das System gibt eine Liste der verwalteten Knoten zurück, die einen Anwendungsnamen haben, der mit dem Wort *Amazon* beginnt.
**Anmerkung**
Sie können mehrere Filter kombinieren, um die Suche zu verfeinern.
# Aggregieren von Bestandsdaten
Nachdem Sie Ihre verwalteten Knoten für AWS Systems Manager Inventar konfiguriert haben, können Sie die aggregierte Anzahl der Inventardaten anzeigen. Nehmen wir beispielsweise an, Sie haben Dutzende oder Hunderte von verwalteten Knoten zur Erfassung des Bestandstyps `AWS:Application` konfiguriert. Mithilfe der Informationen in diesem Abschnitt können Sie die genaue Zahl der Knoten anzeigen, die zum Erfassen dieser Daten konfiguriert sind.
Sie können außerdem spezifische Bestandsdetails durch Aggregieren eines Datentyps sehen. Beispiel: Der Bestandstyp `AWS:InstanceInformation` erfasst Betriebssystem-Plattforminformationen mit dem Datentyp `Platform`. Durch die Aggregierung von Daten für den Datentyp `Platform` können Sie schnell sehen, auf wie vielen Knoten Windows Server, Linux und macOS ausgeführt wird.
Die Verfahren in diesem Abschnitt beschreiben, wie Sie die aggregierte Anzahl von Inventardaten mithilfe von AWS Command Line Interface ()AWS CLI anzeigen können. **Sie können vorkonfigurierte aggregierte Zählungen auch in der AWS Systems Manager Konsole auf der Inventarseite anzeigen.** Diese vorkonfigurierten Dashboards werden als *Inventory Insights (Bestandseinblicke)* bezeichnet. Sie bieten eine 1-Klick-Wiederherstellung Ihrer Bestand-Konfigurationsprobleme.
Beachten Sie die folgenden wichtigen Details zu den Aggregationszählungen von Bestandsdaten:
+ Wenn Sie einen verwalteten Knoten beenden, der zum Sammeln von Bestandsdaten konfiguriert ist, behält Systems Manager die Bestandsdaten 30 Tage lang bei und löscht sie anschließend. Für ausgeführte Knoten löscht das System alle Bestandsdaten, die älter als 30 Tage sind. Wenn Sie Inventardaten länger als 30 Tage speichern müssen, können AWS Config Sie den Verlauf aufzeichnen oder die Daten regelmäßig abfragen und in einen Amazon Simple Storage Service (Amazon S3) -Bucket hochladen.
+ Wenn ein Knoten zuvor konfiguriert wurde, um einen spezifischen Bestandsdatentyp zu melden, z. B. `AWS:Network`, und Sie die Konfiguration später so ändern, dass die Daten dieses Typs nicht mehr erfasst werden, zeigt die Aggregationszählung nach wie vor `AWS:Network`-Daten an, bis der Knoten beendet wurde und 30 Tage vergangen sind.
Informationen zur schnellen Konfiguration und Erfassung von Inventardaten von allen Knoten in einem bestimmten AWS-Konto (und allen future Knoten, die möglicherweise in diesem Konto erstellt werden) finden Sie unter[Inventarisieren Sie alle verwalteten Knoten in Ihrem AWS-Konto](inventory-collection.md#inventory-management-inventory-all).
**Topics**
+ [Aggregieren von Bestandsdaten zum Anzeigen der Anzahl von Knoten, die bestimmte Arten von Daten erfassen](#inventory-aggregate-type)
+ [Aggregieren von Bestandsdaten mit Gruppen, um zu sehen, welche Knoten zur Erfassung eines Bestandstyps konfiguriert sind und welche nicht](#inventory-aggregate-groups)
## Aggregieren von Bestandsdaten zum Anzeigen der Anzahl von Knoten, die bestimmte Arten von Daten erfassen
Sie können den AWS Systems Manager [GetInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetInventory.html)API-Vorgang verwenden, um die aggregierte Anzahl von Knoten anzuzeigen, die einen oder mehrere Inventar- und Datentypen erfassen. Mit dem `AWS:InstanceInformation` Inventartyp können Sie beispielsweise eine Zusammenfassung von Betriebssystemen anzeigen, indem Sie den GetInventory API-Vorgang mit dem `AWS:InstanceInformation.PlatformType` Datentyp verwenden. Hier finden Sie ein Beispiel für den AWS CLI -Befehl und die Ausgabe.
```
aws ssm get-inventory --aggregators "Expression=AWS:InstanceInformation.PlatformType"
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"Entities":[
{
"Data":{
"AWS:InstanceInformation":{
"Content":[
{
"Count":"7",
"PlatformType":"windows"
},
{
"Count":"5",
"PlatformType":"linux"
}
]
}
}
}
]
}
```
**Erste Schritte**
Bestimmen Sie die Bestands- und Datentypen, für die Sie Zählungen anzeigen möchten. Sie können eine Liste der Bestandstypen und Datentypen anzeigen, die die Aggregation unterstützen, indem Sie den folgenden Befehl im Fenster AWS CLI ausführen.
```
aws ssm get-inventory-schema --aggregator
```
Der Befehl gibt eine JSON-Liste mit Bestands- und Datentypen zurück, die die Aggregation unterstützen. Das **TypeName**Feld zeigt die unterstützten Inventartypen. Das Feld **Name** zeigt die einzelnen Datentypen. Der Bestandstyp `AWS:Application` in der folgenden Listen enthält z. B. Datentypen für `Name` und `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"
}
]
}
]
}
```
Sie können Daten für einen der gelisteten Bestandstypen aggregieren, indem Sie einen Befehl erstellen, der die folgende Syntax verwendet.
```
aws ssm get-inventory --aggregators "Expression=InventoryType.DataType"
```
Hier sind einige Beispiele.
**Beispiel 1**
Dieses Beispiel aggregiert eine Zählung der Windows-Rollen, die von Ihren Knoten verwendet werden.
```
aws ssm get-inventory --aggregators "Expression=AWS:WindowsRole.Name"
```
**Beispiel 2**
Dieses Beispiel aggregiert eine Zählung der Anwendungen, die auf Ihren Knoten installiert sind.
```
aws ssm get-inventory --aggregators "Expression=AWS:Application.Name"
```
**Kombinieren von mehreren Aggregatoren**
Sie können auch mehrere Bestands- und Datentypen in einem Befehl kombinieren, um die Daten besser zu verstehen. Hier sind einige Beispiele.
**Beispiel 1**
Dieses Beispiel aggregiert eine Zählung der Betriebssystemtypen, die von Ihren Knoten verwendet werden. Außerdem wird der spezifische Name der Betriebssysteme zurückgegeben.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:InstanceInformation.PlatformType", "Aggregators":[{"Expression": "AWS:InstanceInformation.PlatformName"}]}]'
```
**Beispiel 2**
Dieses Beispiel aggregiert eine Zählung der Anwendungen, die auf Ihren Knoten ausgeführt werden, sowie die spezifische Version der einzelnen Anwendungen.
```
aws ssm get-inventory --aggregators '[{"Expression": "AWS:Application.Name", "Aggregators":[{"Expression": "AWS:Application.Version"}]}]'
```
Wenn Sie möchten, können Sie einen Aggregationsausdruck mit einem oder mehreren Bestands- und Datentypen in einer JSON-Datei erstellen und die Datei über die AWS CLI aufrufen. Die JSON-Datei muss die folgende Syntax verwenden.
```
[
{
"Expression": "string",
"Aggregators": [
{
"Expression": "string"
}
]
}
]
```
Sie müssen die Datei mit der Erweiterung „.json” speichern.
Im folgenden Beispiel werden mehrere Bestands- und Datentypen verwendet.
```
[
{
"Expression": "AWS:Application.Name",
"Aggregators": [
{
"Expression": "AWS:Application.Version",
"Aggregators": [
{
"Expression": "AWS:InstanceInformation.PlatformType"
}
]
}
]
}
]
```
Rufen Sie die Datei mit folgendem Befehl über die AWS CLI auf.
```
aws ssm get-inventory --aggregators file://file_name.json
```
Der Befehl gibt Informationen wie die folgenden zurück.
```
{"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"}
]
}
```
## Aggregieren von Bestandsdaten mit Gruppen, um zu sehen, welche Knoten zur Erfassung eines Bestandstyps konfiguriert sind und welche nicht
Gruppen in Systems Manager Inventory ermöglichen es Ihnen, schnell eine Anzahl der verwalteten Knoten zu sehen, die für das Erfassen einer oder mehrerer Bestandstypen konfiguriert bzw. nicht konfiguriert sind. Mit Gruppen geben Sie einen oder mehrere Bestandstypen sowie einen Filter an, der den `exists`-Operator verwendet.
Beispiel: Angenommen, Sie haben vier verwaltete Knoten zum Erfassen der folgenden Bestandstypen konfiguriert:
+ Knoten 1: `AWS:Application`
+ Knoten 2: `AWS:File`
+ Knoten 3: `AWS:Application`, `AWS:File`
+ Knoten 4: `AWS:Network`
Sie können den folgenden Befehl vom ausführen, AWS CLI um zu sehen, wie viele Knoten so konfiguriert sind, dass sie `AWS:Application` sowohl die `AWS:File inventory` Typen als auch erfassen. Die Antwort gibt auch die Anzahl der Knoten zurück, die nicht zum Erfassen dieser beiden Bestandstypen konfiguriert sind.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationAndFile,Filters=[{Key=TypeName,Values=[AWS:Application],Type=Exists},{Key=TypeName,Values=[AWS:File],Type=Exists}]}]'
```
Die Befehlsantwort zeigt, dass nur ein verwalteter Knoten zum Erfassen der beiden Bestandstypen `AWS:Application` und `AWS:File` konfiguriert ist.
```
{
"Entities":[
{
"Data":{
"ApplicationAndFile":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
**Anmerkung**
Gruppen geben keine Datentypzahlen zurück. Außerdem können Sie die Ergebnisse nicht detailliert aufschlüsseln, um zu sehen, welche Knoten für die Erfassung IDs des Inventartyps konfiguriert sind oder nicht.
Wenn Sie möchten, können Sie einen Aggregationsausdruck mit einem oder mehreren Bestandstypen in einer JSON-Datei erstellen und die Datei über die AWS CLI aufrufen. Die JSON-Datei muss die folgende Syntax verwenden:
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"Name",
"Filters":[
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
},
{
"Key":"TypeName",
"Values":[
"Inventory_type"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Sie müssen die Datei mit der Erweiterung „.json” speichern.
Rufen Sie die Datei mit folgendem Befehl über die AWS CLI auf.
```
aws ssm get-inventory --cli-input-json file://file_name.json
```
**Weitere Beispiele**
Die folgenden Beispiele zeigen Ihnen, wie Sie Bestandsdaten aggregieren, um zu sehen, welche verwalteten Knoten zum Erfassen der angegebenen Bestandstypen konfiguriert bzw. nicht konfiguriert sind. Diese Beispiele verwenden die AWS CLI. Jedes Beispiel enthält einen vollständigen Befehl mit Filtern, die Sie über die Befehlszeile ausführen können, und eine input.json-Beispieldatei, falls Sie es vorziehen, die Informationen in eine Datei einzugeben.
**Beispiel 1**
Dieses Beispiel aggregiert eine Zählung der Knoten, die zum Erfassen entweder des Bestandstyps `AWS:Application` oder des Typs `AWS:File` konfiguriert bzw. nicht konfiguriert sind.
Führen Sie den folgenden Befehl über die AWS CLI aus.
```
aws ssm get-inventory --aggregators 'Groups=[{Name=ApplicationORFile,Filters=[{Key=TypeName,Values=[AWS:Application, AWS:File],Type=Exists}]}]'
```
Wenn Sie eine Datei verwenden möchten, kopieren Sie das folgende Beispiel in eine Datei und speichern Sie sie unter dem Namen input.json.
```
{
"Aggregators":[
{
"Groups":[
{
"Name":"ApplicationORFile",
"Filters":[
{
"Key":"TypeName",
"Values":[
"AWS:Application",
"AWS:File"
],
"Type":"Exists"
}
]
}
]
}
]
}
```
Führen Sie den folgenden Befehl über die AWS CLI aus.
```
aws ssm get-inventory --cli-input-json file://input.json
```
Der Befehl gibt Informationen wie die folgenden zurück.
```
{
"Entities":[
{
"Data":{
"ApplicationORFile":{
"Content":[
{
"notMatchingCount":"1"
},
{
"matchingCount":"3"
}
]
}
}
}
]
}
```
**Beispiel 2**
Dieses Beispiel aggregiert eine Zählung der Knoten, die zum Erfassen des Bestandstyps `AWS:Application`, `AWS:File` und `AWS:Network` konfiguriert bzw. nicht konfiguriert sind.
Führen Sie den folgenden Befehl über die AWS CLI aus.
```
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}]}]'
```
Wenn Sie eine Datei verwenden möchten, kopieren Sie das folgende Beispiel in eine Datei und speichern Sie sie unter dem Namen 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"
}
]
}
]
}
]
}
```
Führen Sie den folgenden Befehl über die AWS CLI aus.
```
aws ssm get-inventory --cli-input-json file://input.json
```
Der Befehl gibt Informationen wie die folgenden zurück.
```
{
"Entities":[
{
"Data":{
"Application":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"File":{
"Content":[
{
"notMatchingCount":"2"
},
{
"matchingCount":"2"
}
]
},
"Network":{
"Content":[
{
"notMatchingCount":"3"
},
{
"matchingCount":"1"
}
]
}
}
}
]
}
```
# Arbeiten mit benutzerdefiniertem Bestand
Sie können Ihren Knoten beliebige Metadaten zuweisen, indem Sie ein *benutzerdefiniertes AWS Systems Manager Inventar* erstellen. Nehmen wir z. B. an, dass Sie eine große Anzahl von Servern in Racks in Ihrem Rechenzentrum verwalten; und diese Server als von Systems Manager verwaltete Knoten konfiguriert wurden. Derzeit speichern Sie die Informationen zu den Standorten der Server-Racks in einer Tabelle. Mit einem benutzerdefinierten Bestand können Sie die Rack-Standorte der einzelnen Knoten als Metadaten auf dem Knoten angeben. Wenn Sie den Bestand mit Systems Manager erfassen, werden die Metadaten zusammen mit den anderen Bestandsmetadaten erfasst. Anschließend können Sie alle Bestandsmetadaten in einen zentralen Amazon S3-Bucket portieren, indem Sie [Resource Data Sync (Ressourcendaten-Synchronisation)](inventory-resource-data-sync.html) verwenden und die Daten abfragen.
**Anmerkung**
Systems Manager unterstützt maximal 20 benutzerdefinierte Bestandstypen pro AWS-Konto.
Um einem Knoten ein benutzerdefiniertes Inventar zuzuweisen, können Sie entweder den Systems Manager [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)API-Vorgang verwenden, wie unter beschrieben[Zuweisen benutzerdefinierter Bestands-Metadaten zu einem verwalteten Knoten](inventory-custom-metadata.md). Oder Sie können eine JSON-Datei für den benutzerdefinierten Bestand erstellen und diese auf den Knoten hochladen. In diesem Abschnitt wird beschrieben, wie Sie die JSON-Datei erstellen.
Die folgende Beispiel-JSON-Datei mit benutzerdefiniertem Bestand gibt Rack-Informationen zu einem On-Premises-Server an. Dieses Beispiel gibt einen Typ von benutzerdefinierten Bestandsdaten (`"TypeName": "Custom:RackInformation"`) an, mit mehreren Einträgen unter `Content`, die die Daten beschreiben.
```
{
"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"
}
}
```
Sie können wie im folgenden Beispiel gezeigt auch verschiedene Einträge im Abschnitt `Content` angeben.
```
{
"SchemaVersion": "1.0",
"TypeName": "Custom:PuppetModuleInfo",
"Content": [{
"Name": "puppetlabs/aws",
"Version": "1.0"
},
{
"Name": "puppetlabs/dsc",
"Version": "2.0"
}
]
}
```
Das JSON-Schema für den benutzerdefinierten Bestand erfordert die Abschnitte `SchemaVersion`, `TypeName` und `Content`, aber Sie können die Informationen in diesen Abschnitten definieren.
```
{
"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"
}
}
```
Der `TypeName`-Wert ist auf 100 Zeichen begrenzt. Außerdem muss der `TypeName`-Wert mit dem großgeschriebenen Wort `Custom` beginnen. Beispiel, `Custom:PuppetModuleInfo`. Daher würden die folgenden Beispiele zu einer Ausnahme führen: `CUSTOM:PuppetModuleInfo`, `custom:PuppetModuleInfo`.
Der `Content` Abschnitt umfasst Attribute und*data*. Beachten Sie, dass bei diesen Elementen Groß- und Kleinschreibung nicht berücksichtigt wird. Wenn Sie jedoch ein Attribut definieren (z. B: "`Vendor`": "DELL") müssen Sie dieses Attribut in Ihren Dateien für den benutzerdefinierten Bestand konsistent referenzieren. Wenn Sie in einer Datei "`Vendor`": "DELL" (mit einem großen „V” in `vendor`) und in einer anderen Datei "`vendor`": "DELL" (mit einem kleinen „v” in `vendor`) angeben, gibt das System ein Fehler zurück.
**Anmerkung**
Sie müssen die Datei mit der Erweiterung `.json` speichern und die von Ihnen definierte Bestandsliste darf nur aus Zeichenfolgenwerten bestehen.
Wenn Sie die Datei erstellt haben, müssen Sie sie auf dem Knoten speichern. In der folgenden Tabelle wird der jeweilige Speicherort angezeigt, an dem die JSON-Dateien für den benutzerdefinierten Bestand auf dem Knoten gespeichert werden müssen.
****
| Betriebssystem | Pfad |
| --- | --- |
| Linux | /var/lib/amazon/ssm/*node-id*/inventory/benutzerdefiniert |
| macOS | `/opt/aws/ssm/data/node-id/inventory/custom` |
| Windows Server | %SystemDrive%\$1ProgramData\$1 Amazon\$1 SSM\$1\$1InstanceData\$1 Inventar*node-id*\$1 Benutzerdefiniert |
Ein Beispiel für die Verwendung des benutzerdefinierten Bestands finden Sie unter [Abrufen der Laufwerkauslastung Ihrer Flotte mit benutzerdefinierten Bestandstypen in EC2 Systems Manager](https://aws.amazon.com/blogs/mt/get-disk-utilization-of-your-fleet-using-ec2-systems-manager-custom-inventory-types/).
## Löschen eines benutzerdefinierten Bestands
Sie können den [DeleteInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DeleteInventory.html)API-Vorgang verwenden, um einen benutzerdefinierten Inventartyp und die mit diesem Typ verknüpften Daten zu löschen. Sie rufen den Befehl delete-inventory unter Verwendung der AWS Command Line Interface (AWS CLI) auf, um alle Daten für einen Bestandstyp zu löschen. Sie rufen den Befehl delete-inventory mit der `SchemaDeleteOption` auf, um einen benutzerdefinierten Bestandstyp zu löschen.
**Anmerkung**
Ein Bestandstyp wird auch als Bestandsschema bezeichnet.
Der Parameter `SchemaDeleteOption` umfasst die folgenden Optionen:
+ **DeleteSchema**: Diese Option löscht den angegebenen benutzerdefinierten Typ und alle damit verknüpften Daten. Sie können das Schema später bei Bedarf erneut erstellen.
+ **DisableSchema**: Wenn Sie diese Option wählen, schaltet das System die aktuelle Version aus, löscht alle zugehörigen Daten und ignoriert alle neuen Daten, wenn die Version kleiner oder gleich der ausgeschalteten Version ist. Sie können diesen Inventartyp wieder zulassen, indem Sie die [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)Aktion für eine Version aufrufen, die höher ist als die ausgeschaltete Version.
**Um das benutzerdefinierte Inventar zu löschen oder zu deaktivieren, verwenden Sie AWS CLI**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie den folgenden Befehl aus, um mit der Option `dry-run` anzuzeigen, welche Daten aus dem System gelöscht werden. Mit diesem Befehl werden keine Daten gelöscht.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --dry-run
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
```
Informationen zur Interpretation der Übersicht für gelöschten Bestand finden Sie unter [Interpretieren der Übersicht für gelöschten Bestand](#delete-custom-inventory-summary).
1. Führen Sie den folgenden Befehl aus, um alle Daten für einen benutzerdefinierten Bestandstyp zu löschen.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name"
```
**Anmerkung**
Der Fortschritt des Löschvorgangs wird in der Ausgabe dieses Befehls nicht angezeigt. Aus diesem Grund sind TotalCount und Verbleibende Anzahl immer gleich, da das System noch nichts gelöscht hat. Sie können den describe-inventory-deletions Befehl verwenden, um den Fortschritt des Löschvorgangs anzuzeigen, wie später in diesem Thema beschrieben.
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
```
Das System löscht alle Daten für den angegebenen benutzerdefinierten Bestandstyp aus dem Systems Manager Inventory-Service.
1. Führen Sie den folgenden Befehl aus. Der Befehl führt die folgenden Aktionen für die aktuelle Version des Bestandstyps aus: Deaktivieren der aktuellen Version, Löschen aller Daten daraus und Ignorieren aller neuen Daten, wenn die Version kleiner oder gleich der deaktivierten Version ist.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DisableSchema"
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
```
Sie können einen deaktivierten Bestandstyp mit dem folgenden Befehl anzeigen.
```
aws ssm get-inventory-schema --type-name Custom:custom_type_name
```
1. Führen Sie den folgenden Befehl aus, um einen Bestandstyp zu löschen.
```
aws ssm delete-inventory --type-name "Custom:custom_type_name" --schema-delete-option "DeleteSchema"
```
Das System löscht das Schema und alle Bestandsdaten für den angegebenen benutzerdefinierten Typ.
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
```
### Anzeigen des Löschstatus
Sie können den Status eines Löschvorgangs mithilfe des `describe-inventory-deletions` AWS CLI Befehls überprüfen. Sie können eine Lösch-ID angeben, um den Status eines bestimmten Löschvorgangs anzuzeigen. Wenn Sie keine Lösch-ID angeben, wird eine Liste aller Löschvorgänge der letzten 30 Tage angezeigt.
****
1. Führen Sie den folgenden Befehl aus, um den Status eines Löschvorgangs anzuzeigen. Das System gibt in der Übersicht über gelöschten Bestand die Lösch-ID zurück.
```
aws ssm describe-inventory-deletions --deletion-id system_generated_deletion_ID
```
Das System gibt den aktuellen Status zurück. Der Löschvorgang ist möglicherweise noch nicht abgeschlossen. Das System gibt unter anderem folgende Informationen zurück
```
{"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"}
]
}
```
Wenn der Löschvorgang abgeschlossen ist, wird in `LastStatusMessage` die Meldung "Deletion is successful" (Löschvorgang erfolgreich) angezeigt.
```
{"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. Führen Sie den folgenden Befehl aus, um eine Liste aller Löschvorgänge der letzten 30 Tage anzuzeigen.
```
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"
```
### Interpretieren der Übersicht für gelöschten Bestand
Sehen Sie sich das folgende Beispiel an, um den Inhalt der Übersicht für gelöschten Bestand besser zu verstehen. Ein Benutzer hat drei Knoten Benutzerdefiniert: RackSpace Inventar zugewiesen. Die Inventarelemente 1 und 2 verwenden den benutzerdefinierten Typ Version 1.0 (“ SchemaVersion „:"1.0"). Für Inventarartikel 3 wird der benutzerdefinierte Typ Version 2.0 (“ SchemaVersion „:"2.0") verwendet.
RackSpace benutzerdefiniertes Inventar 1
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567890",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace benutzerdefiniertes Inventar 2
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567891",
"SchemaVersion":"1.0" "Content":[
{
content of custom type omitted
}
]
}
```
RackSpace benutzerdefiniertes Inventar 3
```
{
"CaptureTime":"2018-02-19T10:48:55Z",
"TypeName":"CustomType:RackSpace",
"InstanceId":"i-1234567892",
"SchemaVersion":"2.0" "Content":[
{
content of custom type omitted
}
]
}
```
Der Benutzer führt den folgenden Befehl aus, um eine Vorschau der zu löschenden Daten anzuzeigen.
```
aws ssm delete-inventory --type-name "Custom:RackSpace" --dry-run
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
```
Der Benutzer führt den folgenden Befehl aus, um das benutzerdefinierte RackSpace Inventar zu löschen.
**Anmerkung**
Der Fortschritt des Löschvorgangs wird in der Ausgabe dieses Befehls nicht angezeigt. Daher sind `TotalCount` und `RemainingCount` immer identisch, da das System noch nichts gelöscht hat. Sie können den `describe-inventory-deletions`-Befehl verwenden, um den Fortschritt des Löschvorgangs anzuzeigen.
```
aws ssm delete-inventory --type-name "Custom:RackSpace"
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
```
### Aktionen zum Löschen von Inventar anzeigen in EventBridge
Sie können Amazon so konfigurieren EventBridge , dass jedes Mal, wenn ein Benutzer benutzerdefiniertes Inventar löscht, ein Ereignis erstellt wird. EventBridge bietet drei Arten von Ereignissen für benutzerdefinierte Vorgänge zum Löschen von Inventar:
+ **Löschaktion für eine Instance**: Ob der benutzerdefinierte Bestand für einen bestimmten verwalteten Knoten erfolgreich gelöscht wurde oder nicht.
+ **Löschaktion-Übersicht**: Eine Übersicht über die Löschaktion.
+ **Warnung für deaktivierten benutzerdefinierten Inventartyp**: Ein Warnungsereignis, wenn ein Benutzer den [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)API-Vorgang für eine Version des benutzerdefinierten Inventartyps aufgerufen hat, die zuvor deaktiviert war.
Hier finden Sie Beispiele für jedes Ereignis.
**Löschaktion für eine Instance**
```
{
"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"
}
}
```
**Löschaktion-Übersicht**
```
{
"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"
}
}
```
**Warnung für einen deaktivierten benutzerdefinierten Bestandstyp**
```
{
"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"
}
}
```
Gehen Sie wie folgt vor, um eine EventBridge Regel für benutzerdefinierte Inventarlöschvorgänge zu erstellen. In diesem Verfahren wird gezeigt, wie Sie eine Regel erstellen, die Benachrichtigungen für Löschvorgänge an benutzerdefiniertem Bestand an ein Amazon SNS-Thema sendet. Bevor Sie beginnen, stellen Sie sicher, dass Sie ein Amazon SNS-Thema haben oder ein neues erstellen. Weitere Informationen dazu erhalten Sie unter [Erste Schritte](https://docs.aws.amazon.com/sns/latest/dg/GettingStarted.html) im *Amazon Simple Notification Service Entwicklerhandbuch*.
**So konfigurieren Sie EventBridge das Löschen von Inventarvorgängen**
1. Öffnen Sie die EventBridge Amazon-Konsole unter [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Wählen Sie im Navigationsbereich **Regeln** aus.
1. Wählen Sie **Regel erstellen** aus.
1. Geben Sie einen Namen und eine Beschreibung für die Regel ein.
Eine Regel darf nicht denselben Namen wie eine andere Regel in derselben Region und auf demselben Event Bus haben.
1. Wählen Sie für **Event Bus** den Event Bus aus, den Sie dieser Regel zuordnen möchten. Wenn Sie möchten, dass diese Regel auf übereinstimmende Ereignisse reagiert, die von Ihnen selbst stammen AWS-Konto, wählen Sie **Standard**. Wenn ein AWS-Service in Ihrem Konto ein Ereignis ausgibt, wird es immer an den Standard-Event-Bus Ihres Kontos weitergeleitet.
1. Bei **Regeltyp** wählen Sie **Regel mit einem Ereignismuster** aus.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie als **Eventquelle AWS ** **Events oder EventBridge Partnerevents** aus.
1. Wählen Sie im Abschnitt **Ereignismuster** die Option **Ereignismusterformular** aus.
1. Als **Event source** (Ereignisquelle) wählen Sie **AWS -Services** aus.
1. Wählen Sie für **AWS service** (-Service), die Option **Systems Manager** aus.
1. Wählen Sie **Inventory** für **Event type (Ereignistyp)**.
1. Für **Specific detail type(s)** (Spezifische(r) Detail-Typ(en)), wählen Sie **Inventory Resource State Change** (Inventar-Ressourcen-Statusänderung).
1. Wählen Sie **Weiter** aus.
1. Bei **Zieltypen** wählen Sie **AWS -Service** aus.
1. Wählen Sie für **Select a target** (Ziel auswählen), die Option **SNS topic** (SNS-Thema), und dann für **Topic** (Thema), Ihr Thema aus.
1. Vergewissern Sie sich, dass im Abschnitt **Additional settings** (Zusätzliche Einstellungen) für **Configure target input** (Zieleingabe konfigurieren) die Option **Matched event** (Übereinstimmendes Ereignis) ausgewählt ist.
1. Wählen Sie **Weiter** aus.
1. (Optional) Geben Sie ein oder mehrere Tags für die Regel ein. Weitere Informationen finden Sie unter [Tagging Your Amazon EventBridge Resources](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-tagging.html) im * EventBridge Amazon-Benutzerhandbuch*.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Details der Regel und wählen Sie dann **Regel erstellen** aus.
# Anzeigen von Bestandsverlauf und Änderungsnachverfolgung
Sie können den AWS Systems Manager Inventarverlauf und die Änderungsnachverfolgung für alle Ihre verwalteten Knoten anzeigen, indem Sie [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/) AWS Config bietet einen detaillierten Überblick über die Konfiguration der AWS Ressourcen in Ihrem AWS-Konto. Dazu gehört auch, wie die Ressourcen jeweils zueinander in Beziehung stehen und wie sie in der Vergangenheit konfiguriert wurden, damit Sie sehen können, wie sich die Konfigurationen und Beziehungen im Laufe der Zeit verändern. Um den Bestandsverlauf und die Änderungsverfolgung anzuzeigen, müssen Sie die folgenden Ressourcen in AWS Config aktivieren:
+ SSM: ManagedInstanceInventory
+ SSM: PatchCompliance
+ SSM: AssociationCompliance
+ SSM: FileData
**Anmerkung**
Beachten Sie die folgenden wichtigen Hinweise zum Inventory-Verlauf und der Änderungsverfolgung:
Wenn Sie Änderungen in Ihrem System nachverfolgen AWS Config möchten, müssen Sie Systems Manager Inventory so konfigurieren, dass `AWS:File` Metadaten erfasst werden, sodass Sie Dateiänderungen in AWS Config (`SSM:FileData`) anzeigen können. Wenn Sie das nicht tun, dann verfolgt AWS Config keine Dateiänderungen auf Ihrem System.
Wenn Sie SSM: PatchCompliance und SSM: aktivierenAssociationCompliance, können Sie den Compliance-Verlauf und die Änderungsverfolgung von Systems Patch Manager Manager-Patches und Systems State Manager Manager-Verknüpfungen einsehen. Weitere Informationen über die Compliance-Verwaltung für diese Ressourcen finden Sie unter [Erfahren Sie mehr über Compliance](compliance-about.md).
Im folgenden Verfahren wird beschrieben, wie Sie den Inventarverlauf und die Aufzeichnung von Änderungen mithilfe AWS Config von () aktivieren. AWS Command Line Interface AWS CLI Weitere Informationen zur Auswahl und Konfiguration dieser Ressourcen finden Sie unter [Auswahl welcher AWS Config Ressourceneinträge](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html) im *AWS Config Entwicklerhandbuch*. AWS Config Informationen zu AWS Config -Preisen erhalten Sie unter [ Pricing](https://aws.amazon.com/config/pricing/) (Preise für WAF).
**Bevor Sie beginnen**
AWS Config benötigt AWS Identity and Access Management (IAM) -Berechtigungen, um Konfigurationsdetails zu Systems Manager Manager-Ressourcen abzurufen. Im folgenden Verfahren müssen Sie einen Amazon-Ressourcennamen (ARN) für eine IAM-Rolle angeben, die AWS Config Berechtigungen für Systems Manager Manager-Ressourcen erteilt. Sie können die verwaltete `AWS_ConfigRole`-Richtlinie der IAM-Rolle hinzufügen, die Sie AWS Config zuweisen. Weitere Informationen zu dieser Rolle finden Sie unter [AWS managed policy: AWS\$1 ConfigRole](https://docs.aws.amazon.com/config/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AWS_ConfigRole) im *AWS Config Developer Guide*. Weitere Informationen zum Erstellen einer IAM-Rolle und dem Zuweisen der `AWS_ConfigRole`-verwalteten Richtlinie zu dieser Rolle finden Sie unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen AWS-Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) im *IAM-Benutzerhandbuch*.
**So aktivieren Sie den Inventarverlauf und die Aufzeichnung von Änderungen in AWS Config**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Kopieren Sie das folgende JSON-Beispiel in einen einfachen Texteditor und speichern Sie die Datei unter dem Namen recordingGroup.json.
```
{
"allSupported":false,
"includeGlobalResourceTypes":false,
"resourceTypes":[
"AWS::SSM::AssociationCompliance",
"AWS::SSM::PatchCompliance",
"AWS::SSM::ManagedInstanceInventory",
"AWS::SSM::FileData"
]
}
```
1. Führen Sie den folgenden Befehl aus, um die Datei recordingGroup.json in AWS Config zu laden.
```
aws configservice put-configuration-recorder --configuration-recorder name=myRecorder,roleARN=arn:aws:iam::123456789012:role/myConfigRole --recording-group file://recordingGroup.json
```
1. Führen Sie den folgenden Befehl aus, um die Erfassung des Bestandsverlaufs und der Änderungsnachverfolgung zu starten.
```
aws configservice start-configuration-recorder --configuration-recorder-name myRecorder
```
Nachdem Sie die Verlaufs- und Änderungsverfolgung konfiguriert haben, können Sie weitere Details des Verlaufs für einen bestimmten verwalteten Knoten mit der Schaltfläche **AWS Config** in der Systems-Manager-Konsole anzeigen. Sie können entweder von der Seite **Managed Instances** (Verwaltete Instances) oder der **Inventory**(Inventory)-Seite aus auf die Schaltfläche **AWS Config** zugreifen. Je nach Bildschirmgröße müssen Sie möglicherweise einen Bildlauf nach rechts auf der Seite ausführen, um die Schaltfläche anzuzeigen.
# Anhalten der Datenerfassung und Löschen von Bestandsdaten
Wenn Sie AWS Systems Manager Inventar nicht mehr verwenden möchten, um Metadaten zu Ihren AWS Ressourcen anzuzeigen, können Sie die Datenerfassung beenden und bereits gesammelte Daten löschen. Dieser Abschnitt enthält folgende Informationen.
**Topics**
+ [Beenden der Datensammlung](#systems-manager-inventory-delete-association)
+ [Löschen einer Inventory Resource Data Sync](#systems-manager-inventory-delete-RDS)
## Beenden der Datensammlung
Wenn Sie Systems Manager zunächst so konfigurieren, dass Bestandsdaten erfasst werden, erstellt das System eine State Manager-Zuordnung, die den Zeitplan und die Ressourcen definiert, aus denen Metadaten gesammelt werden sollen. Sie können die Datenerfassung stoppen, indem Sie alle State Manager-Zuordnungen löschen, die das `AWS-GatherSoftwareInventory`-Dokument verwenden.
**Löschen einer Bestandszuordnung**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **State Manager** aus.
1. Wählen Sie eine Zuordnung aus, die das `AWS-GatherSoftwareInventory`-Dokument nutzt und wählen Sie dann **Delete (Löschen)**.
1. Wiederholen Sie Schritt drei für alle verbleibenden Zuordnungen, die das `AWS-GatherSoftwareInventory`-Dokument verwenden.
## Löschen einer Inventory Resource Data Sync
Wenn Sie AWS Systems Manager Inventar nicht mehr verwenden möchten, um Metadaten zu Ihren AWS Ressourcen anzuzeigen, empfehlen wir außerdem, die für die Erfassung von Inventardaten verwendeten Ressourcendatensynchronisationen zu löschen.
**Löschen einer Inventory Resource Data Sync**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Inventory**.
1. Wählen Sie **Resource Data Syncs (Ressourcen-Datensynchronisierung)**.
1. Wählen Sie eine Synchronisierung aus der Liste aus.
**Wichtig**
Stellen Sie sicher, dass Sie die Synchronisierung für Inventory auswählen. Systems Manager unterstützt die Ressourcendaten-Synchronisierung für mehrere Tools. Wenn Sie die falsche Synchronisierung wählen, könnten Sie die Datenaggregation für Systems Manager Explorer oder Systems Manager Compliance unterbrechen.
1. Wählen Sie **Delete** (Löschen)
1. Wiederholen Sie diese Schritte für alle verbleibenden Resource Data Syncs, die Sie löschen möchten.
1. Löschen Sie den Amazon Simple Storage Service (Amazon S3)-Bucket, in dem die Daten gespeichert wurden. Weitere Informationen zum Löschen eines Amazon S3-Buckets finden Sie unter [Deleting a bucket (Löschen eines Buckets)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-bucket.html).
# Zuweisen benutzerdefinierter Bestands-Metadaten zu einem verwalteten Knoten
Das folgende Verfahren führt Sie durch den Prozess der Verwendung des AWS Systems Manager [PutInventory](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutInventory.html)API-Vorgangs, um einem verwalteten Knoten benutzerdefinierte Inventarmetadaten zuzuweisen. In diesem Beispiel werden einem Knoten Informationen zum Rack-Standort zugewiesen. Weitere Informationen zum benutzerdefinierten Bestand finden Sie unter [Arbeiten mit benutzerdefiniertem Bestand](inventory-custom.md)
**So weisen Sie benutzerdefinierte Bestands-Metadaten zu einem verwalteten Knoten zu**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie den folgenden Befehl aus, um einem Knoten Informationen zum Rack-Standort zuzuweisen.
**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. Führen Sie den folgenden Befehl aus, um die Einträge eines benutzerdefinierten Bestands für diesen Knoten anzuzeigen.
```
aws ssm list-inventory-entries --instance-id ID --type-name "Custom:RackInfo"
```
Das System gibt die folgenden Informationen zurück.
```
{
"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. Führen Sie den folgenden Befehl aus, um das benutzerdefinierte Bestandsschema anzuzeigen.
```
aws ssm get-inventory-schema --type-name Custom:RackInfo
```
Das System gibt die folgenden Informationen zurück.
```
{
"Schemas": [
{
"TypeName": "Custom:RackInfo",
"Version": "1.0",
"Attributes": [
{
"DataType": "STRING",
"Name": "RackLocation"
}
]
}
]
}
```
# Verwenden von AWS CLI , um die Inventardatenerfassung zu konfigurieren
Die folgenden Verfahren führen Sie durch die Schritte zur Konfiguration von AWS Systems Manager Inventory für das Erfassen von Metadaten aus Ihren verwalteten Knoten. Wenn Sie die Erfassung durch Inventory konfigurieren, erstellen Sie zuerst eine Systems Manager State Manager-Zuordnung. Systems Manager erfasst die Bestandsdaten, wenn der Zuordnungsstatus ausgeführt wird. Wenn Sie den Zuordnungsstatus nicht zuerst erstellen und versuchen, das `aws:softwareInventory`-Plugin z. B. mit Systems Manager Run Command aufzurufen, gibt das System den folgenden Fehler aus:
`The aws:softwareInventory plugin can only be invoked via ssm-associate`.
**Anmerkung**
Pro Knoten kann nur jeweils eine Bestandszuordnungs konfiguriert werden. Wenn Sie einen Knoten mit zwei oder mehr Bestandszuordnungen konfigurieren, wird die Zuordnung nicht ausgeführt und es werden keine Bestandsdaten erfasst.
## Schnelle Konfiguration aller Ihrer verwalteten Knoten für Inventory (CLI)
Sie können schnell alle verwalteten Knoten in Ihrer AWS-Konto und in der aktuellen Region konfigurieren, um Inventardaten zu sammeln. Dieser Vorgang wird als „Erstellen einer globalen Bestandszuordnung“ bezeichnet. Um mithilfe von eine globale Inventarzuordnung zu erstellen AWS CLI, verwenden Sie die Platzhalteroption für den `instanceIds` Wert, wie im folgenden Verfahren gezeigt.
**So konfigurieren Sie das Inventar für alle verwalteten Knoten in Ihrer AWS-Konto und in der aktuellen Region (CLI)**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie den folgenden Befehl aus.
------
#### [ 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
```
------
**Anmerkung**
Mit diesem Befehl kann Inventory keine Metadaten für die Windows-Registrierung oder Dateien sammeln. Um diese Datentypen in den Bestand aufzunehmen, fahren Sie mit dem nächsten Schritt fort.
## Manuelle Konfiguration von Inventory auf Ihren verwalteten Knoten (CLI)
Gehen Sie wie folgt vor, um AWS Systems Manager Inventar auf Ihren verwalteten Knoten mithilfe von Knoten IDs oder Tags manuell zu konfigurieren.
**So konfigurieren Sie Ihre verwalteten Knoten manuell für Inventory (CLI)**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie den folgenden Befehl aus, um eine State Manager-Zuordnung zu erstellen, die Systems Manager Inventory auf dem Knoten ausführt. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen. Mit diesem Befehl wird der Service so konfiguriert, dass er alle sechs Stunden ausgeführt wird und Metadaten über Netzwerkkonfigurationen, Windows Update und Anwendungen aus einem Knoten erfasst.
------
#### [ 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"
```
------
Das System gibt die folgenden Informationen zurück.
```
{
"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"
}
]
}
}
```
Sie können dies für große Gruppen von Knoten durchführen, indem Sie den `Targets`-Parameter in Verbindung mit EC2-Tags verwenden. Sehen Sie sich das folgende Beispiel an.
------
#### [ 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"
```
------
Sie können auch Dateien und Windows-Registry-Schlüssel auf einem Windows Server-Knoten inventarisieren, indem Sie die Bestandstypen `files` und `windowsRegistry` mit Ausdrücken verwenden. Weitere Informationen zu diesen Bestandstypen finden Sie unter [Arbeiten mit Datei- und Windows-Registrierungsbestand](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. Führen Sie den folgenden Befehl aus, um den Zuordnungsstatus anzuzeigen.
```
aws ssm describe-instance-associations-status --instance-id an_instance_ID
```
Das System gibt die folgenden Informationen zurück.
```
{
"InstanceAssociationStatusInfos": [
{
"Status": "Pending",
"DetailedStatus": "Associated",
"Name": "reInvent2016PolicyDocumentTest",
"InstanceId": "i-1a2b3c4d5e6f7g",
"AssociationId": "1a2b3c4d5e6f7g-1a2b3c-1a2b3c-1a2b3c-1a2b3c4d5e6f7g",
"DocumentVersion": "1"
}
]
}
```
# Walkthrough: Verwenden von Resource Data Sync zum Aggregieren von Bestandsdaten
In der folgenden exemplarischen Vorgehensweise wird beschrieben, wie Sie mithilfe von AWS Command Line Interface (AWS CLI) eine Konfiguration für die AWS Systems Manager Ressourcendatensynchronisierung für Inventar erstellen. Eine Ressourcen-Datensynchronisierung portiert alle Bestandsdaten aus verwalteten Knoten automatisch in einen zentralen Amazon Simple Storage Service (Amazon S3)-Bucket. Die Synchronisierung aktualisiert die Daten in dem zentralen Amazon S3-Bucket automatisch, sobald neue Bestandsdaten erfasst werden.
In dieser exemplarischen Vorgehensweise wird auch beschrieben, wie Sie Amazon Athena und Amazon Quick verwenden, um die aggregierten Daten abzufragen und zu analysieren. Informationen zum Erstellen einer Ressourcendatensynchronisierung mithilfe von Systems Manager finden Sie unter[Walkthrough: Verwenden von Resource Data Sync zum Aggregieren von Bestandsdaten](#inventory-resource-data-sync). AWS-Managementkonsole Informationen zum Abfragen von Inventar von mehreren AWS-Regionen Konten mithilfe von Systems Manager finden Sie AWS-Managementkonsole unter[Abfragen von Bestandsdaten aus mehreren Regionen und Konten](systems-manager-inventory-query.md).
**Anmerkung**
Diese Anleitung enthält Informationen dazu, wie die Synchronisierung mit AWS Key Management Service (AWS KMS) verschlüsselt werden kann. Inventory erfasst keine personenbezogenen, geschützten oder vertraulichen Daten, d. h. die Verschlüsselung ist optional. Weitere Informationen zu AWS KMS finden Sie im [AWS Key Management Service Entwicklerhandbuch](https://docs.aws.amazon.com/kms/latest/developerguide/).
**Bevor Sie beginnen**
Überprüfen oder erledigen Sie die folgenden Aufgaben, bevor Sie mit dem Walkthrough in diesem Abschnitt beginnen:
+ Sammeln Sie Bestandsdaten von Ihren verwalteten Knoten. Für die Zwecke der Abschnitte Amazon Athena und Amazon Quick in dieser exemplarischen Vorgehensweise empfehlen wir Ihnen, Anwendungsdaten zu sammeln. Weitere Informationen zur Erfassung von Bestandsdaten finden Sie unter [Konfigurieren der Bestandserfassung](inventory-collection.md) oder [Verwenden von AWS CLI , um die Inventardatenerfassung zu konfigurieren](inventory-collection-cli.md).
+ (Optional) Wenn die Inventardaten in einem Amazon Simple Storage Service (Amazon S3) -Bucket gespeichert werden, der die Verschlüsselung AWS Key Management Service (AWS KMS) verwendet, müssen Sie auch Ihr IAM-Konto und die `Amazon-GlueServiceRoleForSSM` Servicerolle für die AWS KMS Verschlüsselung konfigurieren. Wenn Sie Ihr IAM-Konto und diese Rolle nicht konfigurieren, wird Systems Manage `Cannot load Glue tables` anzeigen, wenn Sie die Registerkarte **Detailed View (Detailansicht)** in der Konsole wählen. Weitere Informationen finden Sie unter [(Optional) Konfigurieren Sie Berechtigungen für die Anzeige AWS KMS verschlüsselter Daten](systems-manager-inventory-query.md#systems-manager-inventory-query-kms).
+ (Optional) Wenn Sie die Ressourcendatensynchronisierung mithilfe von verschlüsseln möchten AWS KMS, müssen Sie entweder einen neuen Schlüssel erstellen, der die folgende Richtlinie enthält, oder Sie müssen einen vorhandenen Schlüssel aktualisieren und diese Richtlinie hinzufügen.
------
#### [ 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/*"
}
}
}
]
}
```
------
**So erstellen Sie eine Resource Data Sync für Inventory**
1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Erstellen Sie einen Bucket zum Speichern der aggregierten Bestandsdaten. Weitere Informationen erhalten Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) im *Benutzerhandbuch für Amazon Simple Storage Service*. Notieren Sie sich den Namen des Buckets und den AWS-Region Ort, an dem Sie ihn erstellt haben.
1. Wenn Sie den Bucket erstellt haben, wählen Sie die Registerkarte **Permissions** aus und wählen Sie dann die Option **Bucket Policy**.
1. Kopieren Sie die folgende Bucket-Richtlinie in den Richtlinien-Editor. Ersetzen Sie amzn-s3-demo-bucket und *account-id* durch den Namen des Amazon S3-Buckets, den Sie erstellt haben, und eine gültige ID. AWS-Konto Wenn Sie mehrere Konten hinzufügen, fügen Sie für jedes Konto eine zusätzliche Bedingungszeichenfolge und einen ARN hinzu. Entfernen Sie die zusätzlichen Platzhalter aus dem Beispiel, wenn Sie einzelne Konten hinzufügen. Optional können Sie es *bucket-prefix* durch den Namen eines Amazon S3 S3-Präfix (Unterverzeichnis) ersetzen. Wenn Sie kein Präfix erstellt haben, entfernen Sie es *bucket-prefix/* aus dem ARN in der Richtlinie.
------
#### [ 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. (Optional) Wenn Sie die Synchronisierung verschlüsseln möchten, müssen Sie der im vorherigen Schritt aufgeführten Richtlinie die folgenden Bedingungen hinzufügen. Fügen Sie diese zum Abschnitt `StringEquals` hinzu.
```
"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"
```
Ein Beispiel:
```
"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. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. (Optional) Wenn Sie die Synchronisation verschlüsseln möchten, führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Bucket-Richtlinie die AWS KMS Schlüsselanforderung durchsetzt. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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. Führen Sie den folgenden Befehl aus, um eine Resource Data Sync-Konfiguration mit dem zu Beginn dieses Verfahrens erstellten Amazon S3-Bucket zu erstellen. Dieser Befehl erstellt eine Synchronisation aus dem, bei dem AWS-Region Sie angemeldet sind.
**Anmerkung**
Wenn sich der Synchronisierungs- und der Amazon S3-Ziel-Bucket in verschiedenen Regionen befinden, können Kosten für Datenübertragung anfallen. Weitere Informationen finden Sie unter [Amazon S3 – Preise](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"
```
------
Sie können über den `region`-Parameter angeben, wo die Synchronisierungskonfiguration erstellt werden soll. Im folgenden Beispiel werden Bestandsdaten aus der Region us-west-1 in dem Amazon S3-Bucket in der Region us-west-2 synchronisiert.
------
#### [ 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
```
------
(Optional) Wenn Sie die Synchronisation mit verschlüsseln möchten, führen Sie den folgenden Befehl aus AWS KMS, um die Synchronisierung zu erstellen. Wenn Sie die Synchronisierung verschlüsseln, müssen sich der AWS KMS Schlüssel und der Amazon S3 S3-Bucket in derselben Region befinden.
------
#### [ 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. Führen Sie den folgenden Befehl aus, um den Status der Synchronisierungskonfiguration anzuzeigen.
```
aws ssm list-resource-data-sync
```
Wenn Sie die Synchronisierungskonfiguration in einer anderen Region erstellt haben, müssen Sie den `region`-Parameter angeben, wie im folgenden Beispiel gezeigt.
```
aws ssm list-resource-data-sync --region us-west-1
```
1. Wenn die Synchronisierungskonfiguration erfolgreich erstellt wurde, prüfen Sie den Ziel-Bucket in Amazon S3. Die Bestandsdaten sollten in der Regel nach nur wenige Minuten angezeigt werden.
**Arbeiten mit den Daten in Amazon Athena**
Im folgenden Abschnitt wird beschrieben, wie Sie die Daten in Amazon Athena anzeigen und abfragen können. Bevor Sie beginnen, empfehlen wir Ihnen, sich mit Athena vertraut zu machen. Weitere Informationen finden Sie unter [Was ist Amazon Athena?](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) und [Arbeiten mit Daten](https://docs.aws.amazon.com/athena/latest/ug/work-with-data.html) im *Benutzerhandbuch für Amazon Athena*.
**Anzeigen und Abfragen von Daten in Amazon Athena**
1. Öffnen Sie die Athena-Konsole unter [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home).
1. Kopieren Sie die folgende Anweisung, fügen Sie sie in den Abfrage-Editor ein und wählen Sie dann **Run Query**.
```
CREATE DATABASE ssminventory
```
Das System erstellt eine Datenbank mit dem Namen ssminventory.
1. Kopieren Sie die folgende Anweisung, fügen Sie sie in den Abfrage-Editor ein und wählen Sie dann **Run Query**. Ersetzen Sie amzn-s3-demo-bucket und durch den Namen und das Präfix des *bucket\$1prefix* Amazon S3 S3-Ziels.
```
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. Kopieren Sie die folgende Anweisung, fügen Sie sie in den Abfrage-Editor ein und wählen Sie dann **Run Query**.
```
MSCK REPAIR TABLE ssminventory.AWS_Application
```
Das System partitioniert die Tabelle.
**Anmerkung**
Wenn Sie Ressourcendatensynchronisationen aus zusätzlichen AWS-Regionen oder erstellen, müssen Sie diesen Befehl erneut ausführen AWS-Konten, um die Partitionen zu aktualisieren. Sie müssen möglicherweise auch Ihre Amazon S3-Bucket-Richtlinie aktualisieren.
1. Sie können Ihre Daten in der Vorschau anzeigen, indem Sie das Ansichtssymbol neben der Tabelle `AWS_Application` wählen.
![\[Das Daten-Vorschau-Symbol in Amazon Athena.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/sysman-inventory-resource-data-sync-walk.png)
1. Kopieren Sie die folgende Anweisung, fügen Sie sie in den Abfrage-Editor ein und wählen Sie dann **Run Query**.
```
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
```
Die Abfrage gibt die Anzahl der verschiedenen Versionen von zurück`aws-cfn-bootstrap`, wobei es sich um eine AWS Anwendung handelt, die auf Amazon Elastic Compute Cloud (Amazon EC2) -Instances für Linux vorhanden istmacOS, undWindows Server.
1. **Kopieren Sie die folgenden Anweisungen einzeln und fügen Sie sie in den Abfrage-Editor ein, ersetzen Sie amzn-s3-demo-bucket und durch Informationen für Amazon S3 und *bucket-prefix* wählen Sie dann Run Query.** Diese Anweisungen richten zusätzliche Bestandstabellen in Athena ein.
```
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
```
**Arbeiten mit den Daten in Amazon Quick**
Der folgende Abschnitt bietet eine Übersicht mit Links zum Erstellen einer Visualisierung in Amazon Quick.
**So erstellen Sie eine Visualisierung in Amazon Quick**
1. Melden Sie sich bei [Amazon Quick](https://quicksight.aws/) an und melden Sie sich dann bei der Quick-Konsole an.
1. Erstellen Sie einen Datensatz aus der Tabelle `AWS_Application` sowie aus allen anderen Tabellen, die Sie erstellt haben. Weitere Informationen finden Sie unter [Erstellen eines Datensatzes mit Amazon Athena Athena-Daten](https://docs.aws.amazon.com/quicksuite/latest/userguide/create-a-data-set-athena.html) in der *Amazon-Kurzanleitung*.
1. Verknüpfen Sie Tabellen. Sie können z. B. die Spalte `instanceid` aus `AWS_InstanceInformation` verknüpfen, da sie der Spalte `resourceid` in anderen Bestandstabellen entspricht. Weitere Informationen zum Verknüpfen von Tabellen finden Sie unter [Daten](https://docs.aws.amazon.com/quicksuite/latest/userguide/joining-data.html) verknüpfen in der *Amazon-Kurzanleitung*.
1. Erstellen Sie eine Visualisierung. Weitere Informationen finden Sie unter [Analysen und Berichte: Visualisieren von Daten in Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/working-with-visuals.html) im *Amazon Quick User Guide*.
# Fehlerbehebung bei Problemen mit Systems Manager Inventory
Dieses Thema enthält Informationen zur Behebung häufiger Fehler oder Probleme mit AWS Systems Manager Inventar. Informationen zur Behebung von Problemen bei der Anzeige Ihrer Knoten in Systems Manager finden Sie unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md).
**Topics**
+ [Mehrere Anwenden aller Zuordnungen mit Dokument '`AWS-GatherSoftwareInventory`' werden nicht unterstützt](#systems-manager-inventory-troubleshooting-multiple)
+ [Der Inventory-Ausführungsstatus verlässt nie den Status „ausstehend“.](#inventory-troubleshooting-pending)
+ [Das `AWS-ListWindowsInventory`-Dokument kann nicht ausgeführt werden](#inventory-troubleshooting-ListWindowsInventory)
+ [Konsole zeigt das Inventory-Dashboard nicht an \$1 Detailed View (Detailansicht) \$1 Registerkarte „Settings“ (Einstellungen)](#inventory-troubleshooting-tabs)
+ [UnsupportedAgent](#inventory-troubleshooting-unsupported-agent)
+ [Übersprungen](#inventory-troubleshooting-skipped)
+ [Fehlgeschlagen](#inventory-troubleshooting-failed)
+ [Inventark-Compliance für eine Amazon-EC2-Instance fehlgeschlagen](#inventory-troubleshooting-ec2-compliance)
+ [S3-Bucket-Objekt enthält alte Daten](#systems-manager-inventory-troubleshooting-s3)
## Mehrere Anwenden aller Zuordnungen mit Dokument '`AWS-GatherSoftwareInventory`' werden nicht unterstützt
Ein Fehler `Multiple apply all associations with document 'AWS-GatherSoftwareInventory' are not supported`, der bedeutet, dass eine oder mehrere AWS-Regionen , in denen Sie versuchen, eine Bestandszuordnung *für alle Knoten* zu konfigurieren, sind bereits mit einer Bestandszuordnung für alle Knoten konfiguriert. Falls erforderlich, können Sie die vorhandene Bestandszuordnung für alle Knoten löschen und anschließend eine neue erstellen. Um vorhandene Bestandszuordnungen anzuzeigen, wählen Sie **State Manager** in der Systems Manager Konsole und suchen Sie dann nach Zuordnungen, die das `AWS-GatherSoftwareInventory`-SSM-Dokument verwenden. Wenn die vorhandene Bestandszuordnung für alle Knoten in mehreren Regionen erstellt wurde und Sie eine neue erstellen möchten, müssen Sie die vorhandene Zuordnung aus jeder Region löschen, in der sie vorhanden ist.
## Der Inventory-Ausführungsstatus verlässt nie den Status „ausstehend“.
Es gibt zwei Gründe, warum die Bestandsammlung niemals den `Pending` Status annimmt:
+ Keine Knoten in der ausgewählten Liste AWS-Region:
Wenn Sie eine globale Bestandszuordnung mithilfe von Systems Manager Quick Setup erstellen, zeigt der Status der Bestandszuordnung (`AWS-GatherSoftwareInventory`-Dokument) `Pending` an, wenn in der ausgewählten Region keine Knoten verfügbar sind.****
+ Unzureichende Berechtigungen:
Eine Bestandszuordnung zeigt `Pending` an, wenn eine oder mehrere Knoten nicht über die Berechtigung zum Ausführen von Systems Manager Inventory verfügen. Stellen Sie sicher, dass das Instance-Profil AWS Identity and Access Management (IAM) die von **Amazon SSMManaged InstanceCore** verwaltete Richtlinie enthält. Weitere Informationen zum Hinzufügen dieser Richtlinie zu einem Instance-Profil finden Sie unter [Alternative Konfiguration für EC2-Instance-Berechtigungen](setup-instance-permissions.md#instance-profile-add-permissions).
Das Instance-Profil muss mindestens über die folgenden IAM-Berechtigungen verfügen.
------
#### [ 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": "*"
}
]
}
```
------
## Das `AWS-ListWindowsInventory`-Dokument kann nicht ausgeführt werden
Das `AWS-ListWindowsInventory`-Dokument ist veraltet. Verwenden Sie dieses Dokument nicht zur Bestandserfassung. Verwenden Sie stattdessen einen der unter [Konfigurieren der Bestandserfassung](inventory-collection.md) beschriebenen Prozesse.
## Konsole zeigt das Inventory-Dashboard nicht an \$1 Detailed View (Detailansicht) \$1 Registerkarte „Settings“ (Einstellungen)
Die Seite Inventory **Detailed View (Detailansicht)** ist nur in AWS-Regionen verfügbar, die Amazon Athena anbieten. Wenn die folgenden Registerkarten nicht auf der Seite Systems Manager Inventory angezeigt werden, bedeutet dies, dass Athena nicht in der Region verfügbar ist und Sie die **Detailansicht** nicht verwenden können, um Daten abzufragen.
![\[Anzeigen des Inventory-Dashboards | Detailed View (Detailansicht) | Registerkarte „Settings“ (Einstellungen)\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/inventory-detailed-view-for-error.png)
## UnsupportedAgent
Wenn der detaillierte Status einer Inventarzuordnung und der **Zuordnungsstatus **Fehlgeschlagen**** angezeigt wird, ist die Version von AWS Systems Manager SSM Agent auf dem verwalteten Knoten nicht korrekt. **UnsupportedAgent** Um beispielsweise eine globale Inventarzuordnung zu erstellen (um alle Knoten in Ihrem Verzeichnis zu inventarisieren AWS-Konto), müssen Sie SSM Agent Version 2.0.790.0 oder höher verwenden. Sie können die Ausführung der Agenten-Version auf jedem Ihrer Knoten auf der Seite **Managed Instances** (Verwaltete Instances) in der Spalte **Agent version** (Agent-Version) anzeigen. Weitere Informationen zur Aktualisierung von SSM Agent auf Ihren Knoten finden Sie unter [Aktualisierung von SSM Agent mithilfe von Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
## Übersprungen
Wenn der Status der Bestandszuordnung für einen Knoten **Übersprungen** anzeigt, bedeutet dies, dass auf diesem Knoten bereits eine Bestandszuordnung mit höherer Priorität ausgeführt wird. Systems Manager folgt einer bestimmten Prioritätsreihenfolge, wenn mehrere Bestandszuordnungen für denselben verwalteten Knoten gelten können.
### Prioritätsreihenfolge der Bestandszuordnung
Systems Manager wendet Bestandszuordnungen in der folgenden Prioritätsreihenfolge an:
1. **Quick Setup-Bestandszuordnungen** – Zuordnungen, die mit Quick Setup und der vereinheitlichten Konsole erstellt wurden. Diese Zuordnungen haben Namen, die mit `AWS-QuickSetup-SSM-CollectInventory-` beginnen und auf alle verwalteten Knoten abzielen.
1. **Explizite Bestandszuordnungen** – Zuordnungen, die auf bestimmte verwaltete Knoten abzielen und dabei Folgendes verwenden:
+ Instanz IDs
+ Tag-Schlüssel-Wert-Paare
+ AWS Ressourcengruppen
1. **Globale Inventarzuordnungen** – Zuordnungen, die auf alle verwalteten Knoten abzielen (mithilfe von `--targets "Key=InstanceIds,Values=*"`), aber **nicht** über Quick Setup erstellt wurden.
### Gängige Szenarien
**Szenario 1: Die Quick Setup-Zuordnung hat Vorrang vor der expliziten Zuordnung**
+ Sie haben eine Quick Setup-Inventarzuordnung, die auf alle Instances abzielt
+ Sie erstellen eine manuelle Zuordnung, die nach Tag auf bestimmte verwaltete Knoten abzielt
+ Ergebnis: Die manuelle Zuordnung zeigt `Skipped` mit detailliertem Status `OverriddenByExplicitInventoryAssociation` an
+ Die Quick Setup-Zuordnung erfasst weiterhin Inventar von allen Instances
**Szenario 2: Eine explizite Zuordnung hat Vorrang vor der globalen Zuordnung**
+ Sie haben eine globale Inventarzuordnung, die auf alle Instances abzielt (nicht erstellt von Quick Setup)
+ Sie erstellen eine Zuordnung, die eine spezifische Instance anvisiert
+ Ergebnis: Die globale Zuordnung zeigt `Skipped` für die speziell anvisierten Instances an
+ Die explizite Zuordnung wird auf den anvisierten Instances ausgeführt
### Lösungsschritte
**Wenn Sie anstelle von Quick Setup Ihre eigene Inventarzuordnung verwenden möchten:**
1. **Quick Setup-Zuordnungen identifizieren**: Gehen Sie in der Systems-Manager-Konsole zu State Manager und suchen Sie nach Zuordnungen, deren Namen mit `AWS-QuickSetup-SSM-CollectInventory-` beginnen.
1. **Entfernen der Quick Setup-Konfiguration**:
+ Gehen Sie zu Quick Setup in der Systems-Manager-Konsole.
+ Finden Sie Ihre Konfiguration für die Inventarerfassung.
+ Löschen Sie die Quick Setup-Konfiguration (dadurch wird die zugehörige Inventarzuordnung entfernt).
**Anmerkung**
Sie müssen die Zuordnung, die von Quick Setup erstellt wurde, nicht manuell löschen.
1. **Stellen Sie sicher, dass Ihre Zuordnung ausgeführt wird**: Nachdem Sie die Quick Setup-Konfiguration entfernt haben, sollte Ihre explizite Inventarzuordnung erfolgreich ausgeführt werden.
**Wenn Sie das bestehende Verhalten ändern möchten:**
+ Um alle vorhandenen Inventarzuordnungen anzuzeigen, wählen Sie **State Manager** in der Systems-Manager-Konsole und suchen Sie dann nach Zuordnungen, die das `AWS-GatherSoftwareInventory`-SSM-Dokument verwenden.
+ Denken Sie daran, dass jeder verwaltete Knoten jeweils nur über eine aktive Inventarzuordnung verfügen kann.
**Wichtig**
Inventardaten werden weiterhin von übersprungenen Knoten erfasst, wenn die ihnen zugewiesene Inventarzuordnung (mit höherer Priorität) ausgeführt wird.
Quick Setup-Inventarzuordnungen haben Vorrang vor allen anderen Typen, auch solchen mit expliziter Ausrichtung.
Die detaillierte Statusmeldung `OverriddenByExplicitInventoryAssociation` wird unabhängig vom Zuordnungstyp angezeigt, wenn eine Zuordnung durch eine Zuordnung mit höherer Priorität außer Kraft gesetzt wird.
## Fehlgeschlagen
Wenn der Status der Bestandszuordnung für einen Knoten **Failed** (Fehlgeschlagen) anzeigt, könnte dies bedeuten, dass der Knoten über mehrere ihm zugewiesene Bestandszuordnungen verfügt. Ein Knoten kann jeweils nur über eine zugewiesene Bestandszuordnung verfügen. Eine Inventarvereinigung verwendet das `AWS-GatherSoftwareInventory` AWS Systems Manager Dokument (SSM-Dokument). Sie können den folgenden Befehl ausführen, indem Sie die AWS Command Line Interface (AWS CLI) verwenden, um eine Liste der Verknüpfungen für einen Knoten anzuzeigen.
```
aws ssm describe-instance-associations-status --instance-id instance-ID
```
## Inventark-Compliance für eine Amazon-EC2-Instance fehlgeschlagen
Die Inventar-Compliance für eine Amazon Elastic Compute Cloud (Amazon EC2)-Instance kann fehlschlagen, wenn Sie der Instance mehrere Inventarzuordnungen zuweisen.
Um dieses Problem zu beheben, löschen Sie eine oder mehrere Inventarzuordnungen, die der Instance zugewiesen sind. Weitere Informationen finden Sie unter [Löschen einer Zuordnung](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html).
**Anmerkung**
Beachten Sie das folgende Verhalten, wenn Sie mehrere Bestandszuordnungen für einen verwalteten Knoten erstellen:
Jedem Knoten kann eine Inventarzuordnung zugewiesen werden, die auf *alle* Knoten abzielt (--targets „Key=InstanceIds, Values=\$1“).
Jedem Knoten kann auch eine bestimmte Assoziation zugewiesen werden, die entweder Tag-Schlüssel-Wert-Paare oder eine Ressourcengruppe verwendet. AWS
Wenn einem Knoten mehrere Bestandszuordnungen zugewiesen sind, zeigt der Status *Skipped* (Übersprungen) für die Zuordnung an, die nicht ausgeführt wurde. Die zuletzt durchgeführte Zuordnung zeigt den aktuellen Status der Bestandszuordnung an.
Wenn einem Knoten mehrere Bestandszuordnungen zugewiesen sind und jede ein Tag-Schlüssel-Wert-Paar verwendet, können diese Bestandszuordnungen aufgrund des Tag-Konflikts nicht auf dem Knoten ausgeführt werden. Die Zuordnung wird weiterhin auf Knoten ausgeführt, bei denen der Tag-Schlüssel-Wert-Konflikt nicht besteht.
## S3-Bucket-Objekt enthält alte Daten
Die Daten im Amazon-S3-Bucket-Objekt werden aktualisiert, wenn die Zuordnung zum Bestand erfolgreich ist und neue Daten entdeckt werden. Das Amazon-S3-Bucket-Objekt wird für jeden Knoten aktualisiert, wenn die Zuordnung läuft und fehlschlägt, aber die Daten innerhalb des Objekts werden in diesem Fall nicht aktualisiert. Die Daten im Amazon-S3-Bucket-Objekt werden nur dann aktualisiert, wenn die Zuordnung erfolgreich verläuft. Wenn die Bestandszuordnung fehlschlägt, sehen Sie alte Daten in dem Amazon-S3-Bucket-Objekt.
# AWS Systems Manager Patch Manager
Patch Manager, ein Tool in AWS Systems Manager, automatisiert das Patchen von verwalteten Knoten sowohl mit sicherheitsrelevanten Updates als auch mit anderen Arten von Updates.
**Anmerkung**
Systems Manager bietet Unterstützung für *Patch-Richtlinien* in Quick Setup, einem Tool in AWS Systems Manager. Die Verwendung von Patch-Richtlinien ist die empfohlene Methode zur Konfiguration Ihrer Patching-Vorgänge. Mit einer einzelnen Patch-Richtlinienkonfiguration können Sie Patches für alle Konten in allen Regionen in Ihrer Organisation, nur für die von Ihnen ausgewählten Konten und Regionen oder für ein einzelnes Konto-Region-Paar definieren. Weitere Informationen finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).
Sie können Patch Manager verwenden, um Patches sowohl für Betriebssysteme als auch für Anwendungen durchzuführen. (Unter Windows Server ist der Anwendungssupport auf Updates für Microsoft-Anwendungen beschränkt.) Sie können mit Patch Manager Service Packs auf Windows-Instances installieren und Nebenversionsupgrades auf Linux-Knoten ausführen. Sie können Flotten von Amazon Elastic Compute Cloud (Amazon EC2) -Instances, Edge-Geräten, lokalen Servern und virtuellen Maschinen (VMs) nach Betriebssystemtyp patchen. Dazu gehören unterstützte Versionen mehrerer Betriebssysteme, wie unter [Patch Manager-Voraussetzungen](patch-manager-prerequisites.md) aufgeführt. Sie können Instances nur auf Patches hin durchsuchen und dann einen Bericht zu fehlenden Patches anzeigen oder automatisch alle fehlenden Patches installieren. Um mit Patch Manager zu beginnen, öffnen Sie die [Systems-Manager-Konsole](https://console.aws.amazon.com//systems-manager/patch-manager). Wählen Sie im Navigationsbereich **Patch Manager** aus.
AWS testet Patches nicht, bevor sie in verfügbar gemacht werden. Patch Manager Unterstützt auch Patch Manager nicht die Aktualisierung von Hauptversionen von Betriebssystemen, wie Windows Server 2016 bis Windows Server 2019 oder Red Hat Enterprise Linux (RHEL) 7.0 auf RHEL 8.0.
Für Linux-basierte Betriebssysteme, die einen Schweregrad für Patches melden, verwendet Patch Manager den vom Software-Publisher gemeldeten Schweregrad für den Update-Hinweis oder den einzelnen Patch. Patch Manager leitet keinen Schweregrad aus Drittquellen wie dem [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS) oder aus Metriken ab, die von der [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD) veröffentlicht werden.
## Welche Vorteile bietet Patch Manager meiner Organisation?
Patch Manager automatisiert den Prozess des Patchens verwalteter Knoten sowohl mit sicherheitsrelevanten Updates als auch mit anderen Arten von Updates. Er bietet mehrere große Vorteile:
+ **Zentralisierte Patching-Kontrolle** – Mit Patch-Richtlinien können Sie wiederkehrende Patches für alle Konten in allen Regionen in Ihrer Organisation, für bestimmte Konten und Regionen oder für ein einzelnes Konto-Region-Paar einrichten.
+ **Flexible Patching-Vorgänge** – Sie können Instances nur auf Patches hin durchsuchen und dann einen Bericht zu fehlenden Patches anzeigen oder automatisch alle fehlenden Patches installieren.
+ **Umfassende Compliance-Berichterstattung** – Nach dem Scannen können Sie detaillierte Informationen darüber abrufen, für welche verwalteten Knoten die Patch-Konformität nicht eingehalten wurde und welche Patches fehlen.
+ **Plattformübergreifende Unterstützung** – Patch Manager unterstützt mehrere Betriebssysteme, einschließlich verschiedener Linux-Distributionen, macOS, und Windows Server.
+ **Benutzerdefinierte Patch-Baselines** – Mithilfe von benutzerdefinierten Patch-Baselines, die angeben, welche Patches für die Installation zugelassen sind, können Sie definieren, was Patch-Compliance für Ihr Unternehmen bedeutet.
+ **Integration mit anderen AWS Diensten** — Patch Manager lässt sich in AWS Organizations, AWS Security Hub CSPM, und integrieren AWS CloudTrail, AWS Config um Verwaltung und Sicherheit zu verbessern.
+ **Deterministische Upgrades** – Support für deterministische Upgrades über versionierte Repositorys für Betriebssysteme wie Amazon Linux 2023.
## An wen richtet sich Patch Manager?
Patch Manager ist auf die folgenden Anwendungsfälle ausgelegt:
+ IT-Administratoren, die die Patch-Compliance für ihre gesamte Flotte verwalteter Knoten sicherstellen müssen
+ Betriebsmanager, die Einblick in den Status der Patch-Compliance in ihrer gesamten Infrastruktur benötigen
+ Cloud-Architekten, die automatisierte Patching-Lösungen in großem Umfang implementieren möchten
+ DevOps Techniker, die Patching in ihre betrieblichen Arbeitsabläufe integrieren müssen
+ Unternehmen mit Bereitstellungen mit mehreren Konten oder mehreren Regionen, die ein zentrales Patch-Management benötigen
+ Jeder, der für die Aufrechterhaltung der Sicherheitslage und des Betriebszustands von AWS verwalteten Knoten, Edge-Geräten, lokalen Servern und virtuellen Maschinen verantwortlich ist
## Was sind die Hauptfeatures von Patch Manager?
Patch Manager bietet mehrere wichtige Features:
+ **Patch-Richtlinien** — Konfigurieren Sie Patch-Operationen über mehrere AWS-Konten Regionen hinweg mithilfe einer einzigen Richtlinie durch Integration mit. AWS Organizations
+ **Benutzerdefinierte Patch-Baselines** – Definieren Sie Regeln für die automatische Genehmigung von Patches innerhalb weniger Tage nach ihrer Veröffentlichung, zusammen mit genehmigten und abgelehnten Patches.
+ **Verschiedene Patching-Methoden** – Wählen Sie je nach Ihren spezifischen Anforderungen zwischen Patch-Richtlinien, Wartungsfenstern oder On-Demand-Vorgängen „Jetzt patchen“.
+ **Compliance-Berichte** – Generieren Sie detaillierte Berichte zum Patch-Compliance-Status, die im CSV-Format an einen Amazon-S3-Bucket gesendet werden können.
+ **Plattformübergreifende Unterstützung** – Patchen Sie sowohl Betriebssysteme als auch Anwendungen auf Windows Server, verschiedenen Linux-Distributionen und macOS.
+ **Flexibilität bei der Terminplanung** – Legen Sie mithilfe benutzerdefinierter CRON- oder Rate-Ausdrücke unterschiedliche Zeitpläne für das Scannen und Installieren von Patches fest.
+ **Lebenszyklus-Hooks** – Führen Sie benutzerdefinierte Skripts vor und nach Patch-Vorgängen mithilfe von Systems-Manager-Dokumenten aus.
+ **Sicherheitsfokus** – Der Schwerpunkt von Patch Manager liegt standardmäßig auf sicherheitsrelevanten Updates und nicht auf der Installation aller verfügbaren Patches.
+ **Ratenkontrolle** – Konfigurieren Sie Schwellenwerte für Parallelität und Fehler bei Patch-Vorgängen, um die Auswirkungen auf den Betrieb zu minimieren.
## Worin besteht Compliance in Patch Manager?
Der Maßstab dafür, was die *Patch-Compliance* für die verwalteten Knoten in Ihren Systems Manager Manager-Flotten ausmacht AWS, wird nicht von Betriebssystemanbietern (OS) oder von Dritten wie Sicherheitsberatungsfirmen definiert.
Stattdessen definieren Sie in einer *Patch-Baseline*, was Patch-Compliance für verwaltete Knoten in Ihrer Organisation oder Ihrem Konto bedeutet. Eine Patch-Baseline ist eine Konfiguration, die Regeln festlegt, nach denen Patches auf einem verwalteten Knoten installiert werden müssen. Ein verwalteter Knoten ist patch-konform, wenn er über alle Patches auf dem neuesten Stand ist, die die in der Patch-Baseline angegebenen Genehmigungskriterien erfüllen.
Beachten Sie, dass *die Einhaltung* einer Patch-Baseline nicht bedeutet, dass ein verwalteter Knoten unbedingt *sicher* ist. Konformität bedeutet, dass die in der Patch-Baseline definierten Patches, die sowohl *verfügbar* als auch *genehmigt* sind, auf dem Knoten installiert wurden. Die Gesamtsicherheit eines verwalteten Knotens wird von vielen Faktoren bestimmt, die nicht in den Anwendungsbereich von Patch Manager fallen. Weitere Informationen finden Sie unter [Sicherheit in AWS Systems Manager](security.md).
Jede Patch-Baseline ist eine Konfiguration für einen bestimmten unterstützten Betriebssystemtyp (OS), z. B. Red Hat Enterprise Linux (RHEL), macOS oder Windows Server. Eine Patch-Baseline kann Patchregeln für alle unterstützten Versionen eines Betriebssystems definieren oder nur auf die von Ihnen angegebenen beschränkt sein, z. B. RHEL 7.8 und RHEL 9.3.
In einer Patch-Baseline könnten Sie angeben, dass alle Patches mit bestimmten Klassifizierungen und Schweregraden für die Installation zugelassen werden. Sie könnten beispielsweise alle als `Security` klassifizierten Patches einbeziehen, andere Klassifizierungen wie `Bugfix` oder `Enhancement` jedoch ausschließen. Und Sie könnten alle Patches mit einem Schweregrad von `Critical` einbeziehen und andere ausschließen, z. B. `Important` und `Moderate`.
Sie können Patches auch explizit in einer Patch-Baseline definieren, indem Sie sie IDs zu Listen bestimmter Patches hinzufügen, die genehmigt oder abgelehnt werden sollen, z. B. `KB2736693` `dbus.x86_64:1:1.12.28-1.amzn2023.0.1` für Windows Server oder für Amazon Linux 2023 (AL2023). Sie können optional eine bestimmte Anzahl von Tagen angeben, die auf das Patching gewartet wird, nachdem ein Patch verfügbar ist. Für Linux und macOS haben Sie die Möglichkeit, anstelle der in den Patch-Baseline-Regeln definierten Patches eine externe Liste von Patches aus Compliance-Gründen (eine Install Override-Liste) anzugeben.
Wenn ein Patching-Vorgang ausgeführt wird, vergleicht Patch Manager die Patches, die derzeit auf einen verwalteten Knoten angewendet werden, mit denen, die gemäß den in der Patch-Baseline oder in einer Install Override-Liste festgelegten Regeln angewendet werden sollten. Sie können auswählen, dass Patch Manager Ihnen nur einen Bericht über fehlende Patches anzeigt (ein `Scan`-Vorgang), oder Sie können auswählen, dass Patch Manager automatisch alle Patches installiert, die es auf einem verwalteten Knoten findet (ein `Scan and install`-Vorgang).
**Anmerkung**
Die Daten zur Patch-Konformität stellen eine point-in-time Momentaufnahme des letzten erfolgreichen Patch-Vorgangs dar. Jeder Konformitätsbericht enthält eine Erfassungszeit, aus der hervorgeht, wann der Konformitätsstatus berechnet wurde. Berücksichtigen Sie bei der Überprüfung der Compliance-Daten die Erfassungszeit, um festzustellen, ob der Vorgang wie erwartet ausgeführt wurde.
Patch Manager stellt vordefinierte Patch-Baselines bereit, die Sie für Ihre Patching-Vorgänge verwenden können. Diese vordefinierten Konfigurationen dienen jedoch nur als Beispiele und nicht als empfohlene bewährte Methoden. Wir empfehlen, dass Sie selbst benutzerdefinierte Patch-Baselines erstellen, um besser kontrollieren zu können, was unter Patch-Compliance für Ihre Flotte zu verstehen ist.
Weitere Informationen zu Patch-Baselines finden Sie in den folgenden Themen:
+ [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md)
+ [AWS Vordefinierte Patch-Baselines anzeigen](patch-manager-view-predefined-patch-baselines.md)
+ [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md)
+ [Arbeiten mit Patch-Compliance-Berichten](patch-manager-compliance-reports.md)
## Primäre Komponenten
Bevor Sie mit der Arbeit mit dem Patch Manager-Tool beginnen, sollten Sie sich mit einigen wichtigen Komponenten und Features der Patching-Vorgänge des Tools vertraut machen.
**Patch-Baselines**
Patch Manager verwendet *Patch-Baselines*, die Regeln für die automatische Genehmigung von Patches innerhalb weniger Tage nach ihrer Veröffentlichung enthalten, zusätzlich zu den optionalen Listen der genehmigten und abgelehnten Patches. Wenn ein Patching-Vorgang ausgeführt wird, vergleicht Patch Manager die Patches, die derzeit auf einen verwalteten Knoten angewendet werden, mit denen, die gemäß den in der Patch-Baseline festgelegten Regeln angewendet werden sollten. Sie können auswählen, dass Patch Manager Ihnen nur einen Bericht über fehlende Patches anzeigt (ein `Scan`-Vorgang), oder Sie können auswählen, dass Patch Manager automatisch alle Patches installiert, die es auf einem verwalteten Knoten findet (ein `Scan and install`-Vorgang).
**Methoden für das Patchen von Vorgängen**
Patch Manager bietet derzeit vier Methoden zum Ausführen von `Scan`- und `Scan and install`-Operationen:
+ **(Empfohlen) Eine in konfigurierte Patch-Richtlinie Quick Setup** — Basierend auf der Integration mit AWS Organizations können mit einer einzigen Patch-Richtlinie Patch-Zeitpläne und Patch-Baselines für eine gesamte Organisation definiert werden, einschließlich mehrerer AWS-Konten und all AWS-Regionen dieser Konten. Eine Patch-Richtlinie kann sich auch nur auf einige Organisationseinheiten (OUs) in einer Organisation beziehen. Sie können eine einzige Patch-Richtlinie verwenden, um nach verschiedenen Zeitplänen zu scannen und zu installieren. Weitere Informationen erhalten Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md) und [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).
+ **Eine Host-Management-Option, konfiguriert in Quick Setup** — Host-Management-Konfigurationen werden auch durch die Integration mit unterstützt AWS Organizations, sodass ein Patch-Vorgang für bis zu eine gesamte Organisation ausgeführt werden kann. Diese Option ist jedoch darauf beschränkt, anhand der aktuellen Standard-Patch-Baseline nach fehlenden Patches zu suchen und Ergebnisse in Compliance-Berichten bereitzustellen. Mit dieser Vorgangsmethode können keine Patches installiert werden. Weitere Informationen finden Sie unter [Amazon-EC2-Host-Verwaltung mit Quick Setup einrichten](quick-setup-host-management.md).
+ **Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe** – Ein Wartungsfenster, das Sie im Systems-Manager-Tool mit dem Namen Maintenance Windows einrichten, kann so konfiguriert werden, dass es verschiedene Arten von Aufgaben nach einem von Ihnen definierten Zeitplan ausführt. Eine Aufgabe vom Run Command-Typ kann verwendet werden, um `Scan` oder `Scan and install` Aufgaben auf einem Satz verwalteter Knoten Ihrer Wahl auszuführen. Jede Aufgabe im Wartungsfenster kann nur auf verwaltete Knoten in einem einzigen AWS-Region Paar AWS-Konto abzielen. Weitere Informationen finden Sie unter [Tutorial: Erstellen Sie ein Wartungsfenster zum Patchen über die Konsole](maintenance-window-tutorial-patching.md).
+ **Ein „**Jetzt patchen**“-On-Demand-Vorgang in Patch Manager** – Mit der Option **Jetzt patchen** können Sie Zeitplan-Einrichtungen umgehen, wenn Sie verwaltete Knoten so schnell wie möglich patchen müssen. Mit **Patch now** (Jetzt patchen) geben Sie an, ob der `Scan`- oder `Scan and install`-Vorgang ausgeführt werden soll und auf welchen verwalteten Knoten der Vorgang ausgeführt werden soll. Sie können sich auch dafür entscheiden, Systems-Manager-Dokumente (SSM-Dokumente) als Lebenszyklus-Hooks während des Patch-Vorgangs auszuführen. Jeder **Patch-Now-Vorgang** kann auf verwaltete Knoten in nur einem einzigen AWS-KontoAWS-Region Paar abzielen. Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).
**Compliance-Meldung**
Nach einer `Scan`-Operation können Sie die Systems-Manager-Konsole verwenden, um Informationen darüber anzuzeigen, welche Ihrer verwalteten Knoten die Patch-Compliance nicht erfüllen und welche Patches auf jedem dieser Knoten fehlen. Sie können auch Patch-Compliance-Berichte im CSV-Format generieren, die an einen Amazon Simple Storage Service (Amazon S3)-Bucket Ihrer Wahl gesendet werden. Sie können einmalige Berichte erstellen oder Berichte nach einem regelmäßigen Zeitplan erstellen. Für einen einzelnen verwalteten Knoten enthalten Berichte Details aller Patches für den Knoten. Für einen Bericht über alle verwaltete Knoten wird nur eine Zusammenfassung der fehlenden Patches bereitgestellt. Nachdem ein Bericht generiert wurde, können Sie ein Tool wie Amazon Quick verwenden, um die Daten zu importieren und zu analysieren. Weitere Informationen finden Sie unter [Arbeiten mit Patch-Compliance-Berichten](patch-manager-compliance-reports.md).
**Anmerkung**
Ein durch die Verwendung einer Patch-Richtlinie generiertes Compliance-Element hat den Ausführungstyp `PatchPolicy`. Ein Compliance-Element, das nicht in einem Patch-Richtlinienvorgang generiert wurde, hat den Ausführungstyp `Command`.
**Integrationen**
Patch Managerlässt sich in die folgenden anderen AWS-Services integrieren:
+ **AWS Identity and Access Management (IAM)** — Verwenden Sie IAM, um zu steuern, welche Benutzer, Gruppen und Rollen Zugriff Patch Manager auf Operationen haben. Weitere Informationen erhalten Sie unter [Funktionsweise von AWS Systems Manager mit IAM](security_iam_service-with-iam.md) und [Konfiguration von erforderlichen Instance-Berechtigungen für Systems Manager](setup-instance-permissions.md).
+ **AWS CloudTrail**— Wird verwendet CloudTrail , um einen überprüfbaren Verlauf von Patch-Vorgängen aufzuzeichnen, die von Benutzern, Rollen oder Gruppen ausgelöst wurden. Weitere Informationen finden Sie unter [AWS Systems Manager API-Aufrufe protokollieren mit AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **AWS Security Hub CSPM**— Daten zur Patch-Konformität von Patch Manager können an gesendet werden. AWS Security Hub CSPM Security Hub CSPM bietet Ihnen einen umfassenden Überblick über Ihre Sicherheitswarnungen mit hoher Priorität und den Compliance-Status. Er überwacht auch den Patching-Status Ihrer Flotte. Weitere Informationen finden Sie unter [Integrieren Patch Manager mit AWS Security Hub CSPM](patch-manager-security-hub-integration.md).
+ **AWS Config**— Richten Sie die Aufzeichnung ein AWS Config , um die Amazon EC2 EC2-Instance-Verwaltungsdaten im Patch Manager Dashboard anzuzeigen. Weitere Informationen finden Sie unter [Patch-Dashboard-Zusammenfassungen anzeigen](patch-manager-view-dashboard-summaries.md).
**Topics**
+ [Welche Vorteile bietet Patch Manager meiner Organisation?](#how-can-patch-manager-benefit-my-organization)
+ [An wen richtet sich Patch Manager?](#who-should-use-patch-manager)
+ [Was sind die Hauptfeatures von Patch Manager?](#what-are-the-main-features-of-patch-manager)
+ [Worin besteht Compliance in Patch Manager?](#patch-manager-definition-of-compliance)
+ [Primäre Komponenten](#primary-components)
+ [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md)
+ [Patch Manager-Voraussetzungen](patch-manager-prerequisites.md)
+ [So funktionieren Patch Manager-Operationen](patch-manager-patching-operations.md)
+ [SSM-Befehlsdokumente zum Patchen verwalteter Knoten](patch-manager-ssm-documents.md)
+ [Patch-Baselines](patch-manager-patch-baselines.md)
+ [Verwenden von Kernel Live Patching auf von Amazon Linux 2 verwalteten Knoten](patch-manager-kernel-live-patching.md)
+ [Arbeiten mit Patch Manager-Ressourcen und Compliance mithilfe der Konsole](patch-manager-console.md)
+ [Arbeiten mit Patch Manager-Ressourcen unter Verwendung der AWS CLI](patch-manager-cli-commands.md)
+ [AWS Systems Manager Patch Manager Tutorials](patch-manager-tutorials.md)
+ [Fehlerbehebung für Patch Manager](patch-manager-troubleshooting.md)
# Patch-Richtlinienkonfigurationen in Quick Setup
AWS empfiehlt die Verwendung von *Patch-Richtlinien* zur Konfiguration von Patches für Ihr Unternehmen und. AWS-Konten Patch-Richtlinien wurden in Patch Manager im Dezember 2022 eingeführt.
Eine Patch-Richtlinie ist eine Konfiguration, die Sie mit Quick Setup, einem Tool in AWS Systems Manager, einrichten. Patch-Richtlinien bieten eine umfassendere und zentralisiertere Kontrolle über Ihre Patching-Vorgänge, als dies mit früheren Methoden zum Konfigurieren von Patches möglich war. Patch-Richtlinien können mit [allen von Patch Manager unterstützten Betriebssystemen](patch-manager-prerequisites.md#pm-prereqs) verwendet werden, einschließlich unterstützter Versionen von Linux, macOS und Windows Server. Anweisungen zum Erstellen einer Patch-Richtlinie finden Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md).
## Hauptfeatures von Patch-Richtlinien
Anstatt andere Methoden zum Patchen Ihrer Knoten zu verwenden, verwenden Sie eine Patch-Richtlinie, um die Vorteile dieser Hauptfeatures zu nutzen:
+ **Einzelkonfiguration** – Das Einrichten von Patching-Vorgängen mithilfe eines Wartungsfensters oder einer State Manager-Zuordnung kann mehrere Aufgaben in verschiedenen Teilen der Systems-Manager-Konsole erfordern. Mithilfe einer Patch-Richtlinie können alle Ihre Patching-Vorgänge in einem einzigen Assistenten eingerichtet werden.
+ **Support für mehrere Benutzerkonten/Regionen** — Mithilfe eines Wartungsfensters, einer State Manager Zuordnung oder der Funktion „**Jetzt patchen**“ können Sie nur verwaltete Knoten in einem einzigen Paar auswählen. Patch Manager AWS-KontoAWS-Region Wenn Sie mehrere Konten und mehrere Regionen verwenden, können Ihre Einrichtungs- und Wartungsaufgaben viel Zeit in Anspruch nehmen, da Sie Einrichtungsaufgaben in jedem Konto-Region-Paar durchführen müssen. Wenn Sie jedoch die Option verwenden AWS Organizations, können Sie eine Patch-Richtlinie einrichten, die für alle Ihre verwalteten Knoten gilt. AWS-Regionen AWS-Konten Wenn Sie möchten, kann eine Patch-Richtlinie auch nur für einige Organisationseinheiten (OUs) in den von Ihnen ausgewählten Konten und Regionen gelten. Eine Patch-Richtlinie kann auf Wunsch auch für ein einzelnes lokales Konto gelten.
+ **Installationsunterstützung auf Organisationsebene** – Die vorhandene Host-Management-Konfigurationsoption in Quick Setup bietetUnterstützung für einen täglichen Scan Ihrer verwalteten Knoten auf Patch-Compliance. Dieser Scan wird jedoch zu einem vorher festgelegten Zeitpunkt durchgeführt und liefert nur Patch-Compliance-Informationen. Es werden keine Patch-Installationen durchgeführt. Mithilfe einer Patch-Richtlinie können Sie unterschiedliche Zeitpläne für das Scannen und Installieren festlegen. Sie können auch die Häufigkeit und Zeit dieser Vorgänge auswählen, indem Sie benutzerdefinierte CRON- oder Rate-Ausdrücke verwenden. Sie könnten beispielsweise jeden Tag nach fehlenden Patches suchen, um regelmäßig aktualisierte Compliance-Informationen bereitzustellen. Ihr Installationsplan könnte jedoch nur einmal pro Woche sein, um unerwünschte Ausfallzeiten zu vermeiden.
+ **Vereinfachte Auswahl von Patch-Baselines** – Patch-Richtlinien enthalten weiterhin Patch-Baselines, und es gibt keine Änderungen an der Art und Weise, wie Patch-Baselines konfiguriert werden. Wenn Sie jedoch eine Patch-Richtlinie erstellen oder aktualisieren, können Sie die AWS verwaltete oder benutzerdefinierte Baseline, die Sie für jeden Betriebssystemtyp (OS) verwenden möchten, in einer einzigen Liste auswählen. Es ist nicht erforderlich, die Standard-Baseline für jeden Betriebssystemtyp in separaten Aufgaben anzugeben.
**Anmerkung**
Wenn Patching-Vorgänge, die auf einer Patch-Richtlinie basieren, ausgeführt werden, verwenden diese das `AWS-RunPatchBaseline`-SSM-Dokument. Weitere Informationen finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
**Ähnliche Informationen**
[Stellen Sie mithilfe von Systems Manager zentral Patching-Operationen in Ihrem gesamten AWS Unternehmen](https://aws.amazon.com/blogs/mt/centrally-deploy-patching-operations-across-your-aws-organization-using-systems-manager-quick-setup/) bereit Quick Setup (AWS Cloud Operations and Migrations Blog)
## Weitere Unterschiede bei Patch-Richtlinien
Hier sind einige weitere Unterschiede, die bei der Verwendung von Patch-Richtlinien anstelle der vorherigen Methoden zum Konfigurieren von Patches zu beachten sind:
+ **Keine Patchgruppen erforderlich** – Bei früheren Patching-Vorgängen konnten Sie mehrere Knoten so kennzeichnen, dass sie zu einer Patch-Gruppe gehören, und dann die Patch-Baseline angeben, die für diese Patch-Gruppe verwendet werden soll. Wenn keine Patch-Gruppe definiert wurde, patcht Patch Manager die Instances mit der aktuellen Standard-Patch-Baseline für den OS-Typ. Durch die Verwendung von Patch-Richtlinien ist es nicht mehr erforderlich, Patch-Gruppen einzurichten und zu verwalten.
**Anmerkung**
Die Patchgruppenfunktion wird in der Konsole für Konto-Regionen-Paare nicht unterstützt, die vor der Veröffentlichung der Patch-Richtlinienunterstützung am 22. Dezember 2022 noch keine Patchgruppen verwendet haben. Die Patchgruppenfunktion ist weiterhin für Konto-Regionen-Paare verfügbar, die vor diesem Datum mit der Verwendung von Patchgruppen begonnen haben.
+ **Seite „Patching konfigurieren“ entfernt** – Vor der Veröffentlichung von Patch-Richtlinien konnten Sie auf der Seite **Configure patching** (Patching konfigurieren) Standardwerte für die zu patchenden Knoten, einen Patch-Zeitplan und einen Patching-Vorgang angeben. Diese Seite wurde von Patch Manager entfernt. Diese Optionen werden jetzt in Patch-Richtlinien festgelegt.
+ **Keine „Jetzt patchen“ -Unterstützung** — Die Möglichkeit, Knoten bei Bedarf zu patchen, ist immer noch auf jeweils ein einzelnes Paar AWS-Konto beschränkt.AWS-Region Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).
+ **Patch-Richtlinien und Compliance-Informationen** – Wenn Ihre verwalteten Knoten gemäß einer Patching-Richtlinienkonfiguration auf Compliance gescannt werden, werden Ihnen Compliance-Daten zur Verfügung gestellt. Sie können die Daten auf die gleiche Weise wie bei anderen Methoden des Compliance-Scannens anzeigen und bearbeiten. Sie können zwar eine Patch-Richtlinie für eine gesamte Organisation oder mehrere Organisationseinheiten einrichten, die Compliance-Informationen werden jedoch für jedes Paar einzeln gemeldet AWS-Konto.AWS-Region Weitere Informationen finden Sie unter [Arbeiten mit Patch-Compliance-Berichten](patch-manager-compliance-reports.md).
+ **Konformitätsstatus der Zuordnungen und Patch-Richtlinien** – Der Patching-Status für einen verwalteten Knoten, für den eine Quick Setup-Patch-Richtlinie gilt, entspricht dem Status der State Manager-Zuordnungsausführung für diesen Knoten. Wenn der Status der Zuordnungsausführung `Compliant` lautet, wird der Patching-Status für den verwalteten Knoten ebenfalls als `Compliant` markiert. Wenn der Status der Zuordnungsausführung `Non-Compliant` lautet, wird der Patching-Status für den verwalteten Knoten ebenfalls als `Non-Compliant` markiert.
## AWS-Regionen wird für Patch-Richtlinien unterstützt
Patch-Richtlinien-Konfigurationen in Quick Setup werden derzeit in den folgenden Regionen unterstützt:
+ USA Ost (Ohio): (us-east-2)
+ USA Ost (Nord-Virginia): (us-east-1)
+ USA West (Nordkalifornien) (us-west-1)
+ USA West (Oregon): (us-west-2)
+ Asien-Pazifik (Mumbai): (ap-south-1)
+ Asien-Pazifik (Seoul): (ap-northeast-2)
+ Asien-Pazifik (Singapur): (ap-southeast-1)
+ Asien-Pazifik (Sydney): (ap-southeast-2)
+ Asien-Pazifik (Tokyo) (ap-northeast-1)
+ Kanada (Zentral): (ca-central-1)
+ Europa (Frankfurt) (eu-central-1)
+ Europa (Irland) (eu-west-1)
+ Europa (London) (eu-west-2)
+ Europa (Paris) (eu-west-3)
+ Europa (Stockholm) (eu-north-1)
+ Südamerika (São Paulo) (sa-east-1)
# Patch Manager-Voraussetzungen
Stellen Sie sicher, dass Sie die erforderlichen Voraussetzungen erfüllt habenPatch Manager, bevor Sie ein Tool in verwenden AWS Systems Manager.
**Topics**
+ [SSM Agent-Version](#agent-versions)
+ [Python-Version](#python-version)
+ [Zusätzliche Paketanforderungen](#additional-package-requirements)
+ [Konnektivität zur Patch-Quelle](#source-connectivity)
+ [S3-Endpunkt-Zugriff](#s3-endpoint-access)
+ [Berechtigungen zur lokalen Installation von Patches](#local-installation-permissions)
+ [Unterstützte Betriebssysteme für Patch Manager](#supported-os)
## SSM Agent-Version
Version 2.0.834.0 oder höher von SSM Agent muss auf dem verwalteten Knoten ausgeführt werden, den Sie mit Patch Manager verwalten möchten.
**Anmerkung**
Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter [Automatisieren von Updates für SSM Agent](ssm-agent-automatic-updates.md). Abonnieren Sie die [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten.
## Python-Version
Unterstützt Patch Manager derzeit die Python-Versionen 2.6 bis 3.12 für macOS und die meisten Linux-Betriebssysteme (OSs). Die AlmaLinuxDebian Server, und Ubuntu Server OSs erfordern eine unterstützte Version von Python 3 (3.0-3.12).
## Zusätzliche Paketanforderungen
Bei DNF-basierten Betriebssystemen können die `unzip` Dienstprogramme `zstd``xz`, und zum Dekomprimieren von Repository-Informationen und Patch-Dateien erforderlich sein. Zu den DNF-basierten Betriebssystemen gehören Amazon Linux 2023, Red Hat Enterprise Linux 8 und spätere Versionen, Oracle Linux Rocky Linux AlmaLinux, und CentOS 8 und spätere Versionen. Wenn Sie einen ähnlichen Fehler wie `No such file or directory: b'zstd'``No such file or directory: b'unxz'`, sehen oder wenn das Patchen aufgrund fehlender Informationen fehlschlägt`unzip`, müssen Sie diese Dienstprogramme installieren. `zstd``xz`, und `unzip` kann installiert werden, indem Sie den folgenden Befehl ausführen:
```
dnf install zstd xz unzip
```
## Konnektivität zur Patch-Quelle
Wenn Ihre verwalteten Knoten keine direkte Verbindung zum Internet haben und Sie eine Amazon Virtual Private Cloud (Amazon VPC) mit einem VPC-Endpunkt verwenden, müssen Sie sicherstellen, dass die Knoten Zugriff auf die Quell-Patch-Verzeichnisse (Repos) haben. Auf Linux-Knoten werden Patch-Updates normalerweise von den auf dem Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten eine Verbindung zu den Repos herstellen können, damit die Patches ausgeführt werden können. Weitere Informationen finden Sie unter [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md).
Wenn Sie einen Knoten patchen, der in einer IPv6 reinen Umgebung ausgeführt wird, stellen Sie sicher, dass der Knoten mit der Patch-Quelle verbunden ist. Sie können die Run Command Ausgabe der Patching-Ausführung überprüfen, um nach Warnungen zu unzugänglichen Repositorys zu suchen. Für DNF-basierte Betriebssysteme ist es möglich, nicht verfügbare Repositorys so zu konfigurieren, dass sie beim Patchen übersprungen werden, wenn die Option auf unter gesetzt ist. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` Zu den DNF-basierten Betriebssystemen gehören Amazon Linux 2023, Red Hat Enterprise Linux 8 und spätere Versionen, Oracle Linux Rocky Linux AlmaLinux, und CentOS 8 und spätere Versionen. Unter Amazon Linux 2023 ist die `skip_if_unavailable` Option `True` standardmäßig auf eingestellt.
**CentOS Stream: Das `EnableNonSecurity`-Flag aktivieren**
CentOS Stream-Knoten verwenden DNF als Paketmanager, das das Konzept eines Update-Hinweises verwendet. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben.
Standard-Repos von CentOS Stream werden jedoch nicht mit einem Update-Hinweis konfiguriert. Das bedeutet, dass Patch Manager Pakete auf einem Standard-CentOS Stream-Repos nicht erkennt. Um Patch Manager für die Verarbeitung von Paketen, die nicht in einem Update-Hinweis enthalten sind, zu aktivieren, müssen Sie die `EnableNonSecurity`-Markierung in den Patch-Baseline-Regeln aktivieren.
**Windows Server: Stellen Sie die Konnektivität zum Windows Update Catalog oder Windows Server Update Services (WSUS) sicher**
Von Windows Server verwaltete Knoten müssen eine Verbindung zum Windows Update Catalog oder Windows Server Update Services (WSUS) herstellen können. Vergewissern Sie sich, dass Ihre Knoten über ein Internet-Gateway, ein NAT-Gateway oder eine NAT-Instance eine Verbindung zum [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) hergestellt haben. Wenn Sie WSUS verwenden, stellen Sie sicher, dass der Knoten eine Verbindung zum WSUS-Server in Ihrer Umgebung hat. Weitere Informationen finden Sie unter [Problem: Der verwaltete Knoten hat keinen Zugriff auf Windows Update Catalog oder WSUS](patch-manager-troubleshooting.md#patch-manager-troubleshooting-instance-access).
## S3-Endpunkt-Zugriff
Unabhängig davon, ob Ihre verwalteten Knoten in einem privaten oder öffentlichen Netzwerk betrieben werden, ohne Zugriff auf die erforderlichen AWS verwalteten Amazon Simple Storage Service (Amazon S3) -Buckets schlagen Patch-Vorgänge fehl. Informationen zu den S3-Buckets, auf die Ihre verwalteten Knoten zugreifen können müssen, finden Sie unter [SSM AgentKommunikation mit AWS verwalteten S3-Buckets](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) und [Die Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für Systems Manager verbessern](setup-create-vpc.md).
## Berechtigungen zur lokalen Installation von Patches
Unter den Betriebssystemen Windows Server und Linux setzt Patch Manager zum Installieren von Patches die Benutzerkonten Administrator bzw. Root voraus.
Unter macOS unterstützt Homebrew für Brew und Brew Cask jedoch nicht die Ausführung seiner Befehle unter dem Root-Benutzerkonto. Darum fragt Patch Manager entweder als Eigentümer des Homebrew-Verzeichnisses oder als gültiger Benutzer,der zur Eigentümergruppe des Homebrew-Verzeichnisses gehört, Homebrew–Befehle ab und führt sie aus. Um Patches installieren zu können, benötigt der Besitzer des `homebrew`-Verzeichnisses daher auch rekursive Eigentümerberechtigungen für das `/usr/local`-Verzeichnis.
**Tipp**
Der folgende Befehl stellt diese Berechtigung für den angegebenen Benutzer bereit:
```
sudo chown -R $USER:admin /usr/local
```
## Unterstützte Betriebssysteme für Patch Manager
Das Patch Manager-Tool unterstützt nicht dieselben Betriebssystemversionen, die von anderen Systems-Manager-Tools unterstützt werden. (Eine vollständige Liste der von Systems Manager unterstützten Betriebssysteme finden Sie unter [Unterstützte Betriebssysteme für Systems Manager](operating-systems-and-machine-types.md#prereqs-operating-systems).) Stellen Sie daher sicher, dass die verwalteten Knoten, die Sie mit Patch Manager verwenden möchten, eines der Betriebssysteme ausführen, die in der folgenden Tabelle aufgeführt sind.
**Anmerkung**
Patch Manager stützt sich auf die Patch-Repositorys, die auf einem verwalteten Knoten konfiguriert sind, z. B. Windows Update Catalog und Windows Server Update Services für Windows, um verfügbare Patches für die Installation abzurufen. Daher können Betriebssystemversionen, die am Ende ihres Lebenszyklus (EOL) sind, ist Patch Manager möglicherweise nicht in der Lage, über die neuen Updates zu berichten, wenn keine neuen Updates verfügbar sind. Dies kann daran liegen, dass vom Linux-Distributionsbetreuer, Microsoft oder Apple keine neuen Updates veröffentlicht wurden oder dass der verwaltete Knoten nicht über die richtige Lizenz für den Zugriff auf die neuen Updates verfügt.
Wir empfehlen dringend, die Verwendung von Betriebssystemversionen zu vermeiden, die End-of-Life (EOL) erreicht haben. Betriebssystemanbieter, darunter auch, bieten AWS in der Regel keine Sicherheitspatches oder andere Updates für Versionen an, die EOL erreicht haben. Die weitere Verwendung eines EOL-Systems erhöht das Risiko, dass Upgrades, einschließlich Sicherheitsupdates, und andere Betriebsprobleme nicht durchgeführt werden können, erheblich. AWS testet die Systems Manager Manager-Funktionalität nicht auf Betriebssystemversionen, die EOL erreicht haben.
Patch Manager meldet den Konformitätsstatus anhand der verfügbaren Patches auf dem verwalteten Knoten. Wenn auf einer Instance ein EOL-Betriebssystem ausgeführt wird und keine Updates verfügbar sind, wird Patch Manager den Knoten daher möglicherweise als konform melden, je nachdem, welche Patch-Baselines für den Patchvorgang konfiguriert wurden.
| Betriebssystem | Details |
| --- | --- |
| Linux | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-prerequisites.html) |
| macOS | *macOS wird nur für Amazon EC2-Instances unterstützt.* 13.0–13.7 (Ventura) 14*.x* (Sonoma) 15*.x* (Sequoia) macOS Updates Patch Manager unterstützt keine Updates oder Upgrades für macOS, z. B. von 13.1 auf 13.2. Für die Aktualisierung der Betriebssystemversion von macOS empfehlen wir, die in Apple integrierten Mechanismen zu verwenden. Weitere Informationen finden Sie auf der Website mit Entwicklerdokumentation von Apple unter [Device Management](https://developer.apple.com/documentation/devicemanagement). Unterstützung für Homebrew Patch Manager erfordert, dass Homebrew, das Open-Source-Softwarepaketverwaltungssystem, an einem der folgenden Standardinstallationsverzeichnisse installiert ist: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-prerequisites.html) Patch-Vorgänge, die Patch Manager verwenden, funktionieren nicht richtig, wenn Homebrew nicht installiert ist. Regionsunterstützung macOSwird nicht in AWS-Regionen allen unterstützt. Weitere Informationen zur Amazon-EC2-Unterstützung für macOS finden Sie unter [Amazon-EC2-Mac-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) im *Amazon-EC2-Benutzerhandbuch*. macOS-Edge-Geräte SSM Agentfür AWS IoT Greengrass Kerngeräte wird auf nicht unterstütztmacOS. Sie können Patch Manager nicht verwenden, um macOS-Edge-Geräte zu patchen. |
| Windows | Windows Server 2012 bis Windows Server 2025, einschließlich R2-Versionen. SSM Agentfür AWS IoT Greengrass Kerngeräte wird unter Windows 10 nicht unterstützt. Sie können Patch Manager nicht verwenden, um Windows-10-Edge-Geräte zu patchen. Windows Server 2012 und 2012 R2 Windows Server 2012 und 2012 R2 haben am 10. Oktober 2023 das Ende der Unterstützung erreicht. Für die Verwendung Patch Manager mit diesen Versionen empfehlen wir, auch Extended Security Updates (ESUs) von Microsoft zu verwenden. Weitere Informationen finden Sie auf der Microsoft-Website unter [Windows Server 2012 und 2012 R2 erreichen das Ende des Supports](https://learn.microsoft.com/en-us/lifecycle/announcements/windows-server-2012-r2-end-of-support). |
# So funktionieren Patch Manager-Operationen
Dieser Abschnitt enthält technische Details, die erklären, wie Patch Manager, ein Tool in AWS Systems Manager, bestimmt, welche Patches installiert werden und wie er sie auf dem jeweiligen unterstützten Betriebssystem installiert. Für Linux-Betriebssysteme enthält er auch Informationen zur Angabe einer Quell-Repository, in einer benutzerdefinierten Patch-Baseline, für andere Patches als diejenigen, die standardmäßig auf einem verwalteten Knoten konfiguriert sind. Dieser Abschnitt bietet außerdem Informationen darüber, wie Patch-Baseline-Regeln auf verschiedenen Verteilungen des Linux-Betriebssystems funktionieren.
**Anmerkung**
Die Informationen in den folgenden Themen gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihre Patching-Vorgänge verwenden:
Eine in Quick Setup konfigurierte Patch-Richtlinie
Eine in Quick Setup konfigurierte Host-Management-Option
Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
Ein On-Demand-**Jetzt patchen**-Vorgang
**Topics**
+ [So werden Veröffentlichungs- und Aktualisierungsdaten von Paketen berechnet](patch-manager-release-dates.md)
+ [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md)
+ [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md)
+ [Wie Patches installiert werden](patch-manager-installing-patches.md)
+ [Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen](patch-manager-linux-rules.md)
+ [Unterschiede beim Patchvorgang zwischen Linux und Windows Server](patch-manager-windows-and-linux-differences.md)
# So werden Veröffentlichungs- und Aktualisierungsdaten von Paketen berechnet
**Wichtig**
Die Informationen auf dieser Seite beziehen sich auf Amazon-Linux-2 und Amazon-Linux-2023-Betriebssysteme (OS) für Amazon Elastic Compute Cloud (Amazon EC2)-Instances. Die Pakete für diese Betriebssystemtypen werden von Amazon Web Services erstellt und verwaltet. Wie die Hersteller anderer Betriebssysteme ihre Pakete und Repositorys verwalten, wirkt sich darauf aus, wie ihre Veröffentlichungs- und Aktualisierungsdaten berechnet werden. OSs Neben Amazon Linux 2 und Amazon Linux 2023 finden Sie in der Dokumentation des Herstellers Informationen darüberRed Hat Enterprise Linux, wie ihre Pakete aktualisiert und gewartet werden.
In den Einstellungen für [benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom), die Sie für die meisten Betriebssystemtypen erstellen, können Sie angeben, dass Patches nach einer bestimmten Anzahl von Tagen automatisch für die Installation genehmigt werden. AWS bietet mehrere vordefinierte Patch-Baselines, die automatische Genehmigungsdaten von 7 Tagen enthalten.
Eine *Verzögerung der automatischen Genehmigung* ist die Anzahl an Tagen, die gewartet werde soll, nachdem die Patch veröffentlicht wurde, bevor der Patch automatisch genehmigt wird. Beispielsweise erstellen Sie eine Regel mit der `CriticalUpdates`-Klassifizierung und konfigurieren sie für eine Verzögerung der automatischen Genehmigung um sieben Tage. Infolgedessen wird ein neuer kritischer Patch mit einem Veröffentlichungsdatum oder dem letzten Aktualisierungsdatum vom 7. Juli automatisch am 14. Juli genehmigt.
Um unerwartete Ergebnisse mit Verzögerungen bei der automatischen Genehmigung auf Amazon Linux 2 und Amazon Linux 2023 zu vermeiden, ist es wichtig zu wissen, wie die Veröffentlichungs- und Aktualisierungsdaten berechnet werden.
**Anmerkung**
Wenn ein Amazon Linux 2- oder Amazon Linux 2023-Repository keine Informationen zum Veröffentlichungsdatum von Paketen bereitstellt, verwendet Patch Manager die Erstellungszeit des Pakets als Datum zur automatischen Genehmigung der Datumsangaben. Wenn die Erstellungszeit des Pakets nicht bestimmt werden kann, verwendet Patch Manager als Standarddatum den 1. Januar 1970. Dies führt dazu, dass alle Angaben zum Datum der automatischen Genehmigung in Patch-Baselines von Patch Manager umgangen werden, die so konfiguriert sind, dass Patches für jedes Datum nach dem 1. Januar 1970 genehmigt werden.
In den meisten Fällen wird die Wartezeit für die automatische Genehmigung vor der Installation von Patches aus einem `Updated Date`-Wert in `updateinfo.xml` und nicht aus einem `Release Date`-Wert berechnet. Im Folgenden finden Sie wichtige Details zu diesen Datumsberechnungen:
+ Das `Release Date` ist das Datum, an dem ein *Hinweis* veröffentlicht wird. Dies bedeutet nicht, dass das Paket bereits in den zugehörigen Repositorys verfügbar ist.
+ Das `Update Date` ist das letzte Datum, an dem der Hinweis aktualisiert wurde. Eine Aktualisierung eines Hinweises kann etwas so Kleines wie eine Text- oder Beschreibungsaktualisierung darstellen. Dies bedeutet nicht, dass das Paket ab diesem Datum veröffentlicht wurde oder notwendigerweise in den zugehörigen Repositorys verfügbar ist.
Dies bedeutet, dass ein Paket einen `Update Date`-Wert vom 7. Juli haben kann, aber erst (zum Beispiel) am 13. Juli für die Installation verfügbar sein kann. Angenommen, in diesem Fall wird am 14. Juli in einem `Install`-Vorgang eine Patch-Baseline ausgeführt, die eine 7-tägige automatische Genehmigungsverzögerung angibt. Da der `Update Date`-Wert sieben Tage vor dem Ausführungsdatum liegt, werden die Patches und Updates im Paket am 14. Juli installiert. Die Installation erfolgt, obwohl erst ein Tag vergangen ist, seit das Paket für die eigentliche Installation verfügbar ist.
+ Ein Paket, das Betriebssystem- oder Anwendungs-Patches enthält, kann nach der ersten Veröffentlichung mehrmals aktualisiert werden.
+ Ein Paket kann in den AWS verwalteten Repositorys veröffentlicht, dann aber zurückgesetzt werden, wenn später Probleme damit entdeckt werden.
Bei einigen Patch-Vorgängen sind diese Faktoren möglicherweise nicht wichtig. Wenn beispielsweise eine Patch-Baseline so konfiguriert ist, dass ein Patch mit den Schweregraden `Low` und `Medium` und der Klassifizierung `Recommended` installiert wird, kann jede Verzögerung der automatischen Genehmigung nur geringe Auswirkungen auf Ihren Betrieb haben.
In Fällen, in denen das Timing kritischer Patches oder Patches mit hohem Schweregrad wichtiger ist, sollten Sie möglicherweise mehr Kontrolle darüber haben, wann Patches installiert werden. Die empfohlene Methode hierfür ist die Verwendung alternativer Patch-Quell-Repositorys anstelle der Standard-Repositorys für Patch-Vorgänge auf einem verwalteten Knoten.
Sie können beim Erstellen einer benutzerdefinierten Patch-Baseline alternative Patch-Quell-Repositorys angeben. Für jede benutzerdefinierte Patch-Baseline können Sie Patch-Quellkonfigurationen für bis zu 20 Versionen eines unterstützten Linux-Betriebssystems angeben. Weitere Informationen finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).
# Wie Sicherheitspatches ausgewählt werden
Das Hauptaugenmerk vonPatch Manager, einem Tool in AWS Systems Manager, liegt auf der Installation sicherheitsrelevanter Betriebssystemupdates auf verwalteten Knoten. Standardmäßig installiert Patch Manager daher nicht alle verfügbaren Patches, sondern eher eine kleinere Reihe von Patches mit Schwerpunkt auf der Sicherheit.
Standardmäßig ersetzt Patch Manager kein Paket, das in einem Paket-Repository mit Ersatzpaketen als veraltet markiert wurde mit Ersatzpaketen mit anderen Namen, es sei denn, dieser Ersatz ist für die Installation eines anderen Paket-Updates erforderlich. Stattdessen meldet und installiert Patch Manager bei Befehlen, die ein Paket aktualisieren, nur fehlende Updates für das Paket, das installiert wird, aber veraltet ist. Dies liegt daran, dass das Ersetzen eines veralteten Pakets normalerweise die Deinstallation eines vorhandenen Pakets und die Installation des Ersatzpakets erfordert. Durch das Ersetzen des veralteten Pakets könnten grundlegende Änderungen oder zusätzliche Funktionen eingeführt werden, die Sie nicht beabsichtigt hatten.
Dieses Verhalten entspricht dem `update-minimal`-Befehl von YUM und DNF, der sich eher auf Sicherheitsupdates als auf Feature-Updates konzentriert. Weitere Informationen finden Sie unter [Wie Patches installiert werden](patch-manager-installing-patches.md).
**Anmerkung**
Wenn Sie den `ApproveUntilDate` Parameter oder `ApproveAfterDays` Parameter in einer Patch-Baseline-Regel verwenden, werden die Veröffentlichungsdaten von Patches anhand der koordinierten Weltzeit (UTC) Patch Manager ausgewertet.
Wenn Sie beispielsweise ein Datum angeben`ApproveUntilDate`, werden Patches`2025-11-16`, die zwischen `2025-11-16T00:00:00Z` und veröffentlicht wurden`2025-11-16T23:59:59Z`, genehmigt.
Beachten Sie, dass die Veröffentlichungsdaten von Patches, die von systemeigenen Paketmanagern auf Ihren verwalteten Knoten angezeigt werden, je nach der lokalen Zeitzone Ihres Systems unterschiedliche Zeiten anzeigen können. Für Genehmigungsberechnungen wird jedoch Patch Manager immer die UTC-Datum/Uhrzeit verwendet. Dadurch wird die Konsistenz mit den auf offiziellen Websites mit Sicherheitshinweisen veröffentlichten Patch-Veröffentlichungsdaten gewährleistet.
Für Linux-basierte Betriebssysteme, die einen Schweregrad für Patches melden, verwendet Patch Manager den vom Softwareherausgeber gemeldeten Schweregrad für den Update-Hinweis oder den einzelnen Patch. Patch Manager leitet keinen Schweregrad aus Drittquellen wie dem [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS) oder aus Metriken ab, die von der [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD) veröffentlicht werden.
**Anmerkung**
Auf allen Linux-basierten Systemen, die von Patch Manager unterstützt werden, können Sie ein anderes für den verwalteten Knoten konfiguriertes Quell-Repository auswählen, typischerweise zur Installation von nicht-sicherheitsrelevanten Updates. Weitere Informationen finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).
Wählen Sie aus den folgenden Registerkarten, um zu erfahren, wie Patch Manager sicherheitsrelevante Patches für Ihr Betriebssystem auswählt.
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
Vorkonfigurierte Repositorys werden auf Amazon Linux 2 anders behandelt als auf Amazon Linux 2023.
Auf Amazon Linux 2 verwendet der Patch-Baseline-Server des Systems Managers vorkonfigurierte Repositorys auf dem verwalteten Knoten. Es gibt in der Regel zwei vorkonfigurierte Repositorys (Repos) auf einem Knoten:
**Auf Amazon Linux 2**
+ **Repo-ID**: `amzn2-core/2/architecture`
**Repo-Name**: `Amazon Linux 2 core repository`
+ **Repo-ID**: `amzn2extra-docker/2/architecture`
**Repo-Name**: `Amazon Extras repo for docker`
**Anmerkung**
*architecture*kann x86\$164 oder (für Graviton-Prozessoren) aarch64 sein.
Wenn Sie eine Amazon Linux 2023 (AL2023) -Instance erstellen, enthält sie die Updates, die in der von AMI Ihnen ausgewählten Version AL2023 und spezifischen Version verfügbar waren. Ihre AL2023 Instance erhält beim Start nicht automatisch zusätzliche kritische und wichtige Sicherheitsupdates. Stattdessen können Sie mit der Unterstützung der Funktion *deterministische Upgrades durch versionierte Repositorys* AL2023, die standardmäßig aktiviert ist, Updates nach einem Zeitplan anwenden, der Ihren spezifischen Anforderungen entspricht. Weitere Informationen finden Sie unter [Deterministische Upgrades durch versionierte Repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) im *Benutzerhandbuch von Amazon Linux 2023*.
Bei aktivierter AL2023 Option sieht das vorkonfigurierte Repository wie folgt aus:
+ **Repo-ID**: `amazonlinux`
**Repository-Name**: Amazon-Linux-2023-Repository
Bei Amazon Linux 2023 (Vorschauversion) sind die vorkonfigurierten Repositories an *gesperrte Versionen* von Paket-Updates gebunden. Wenn new Amazon Machine Images (AMIs) für veröffentlicht AL2023 werden, sind sie an eine bestimmte Version gebunden. Bei Patch-Aktualisierungen ruft Patch Manager die letzte gesperrte Version des Patch-Aktualisierungs-Repositorys ab und aktualisiert dann die Pakete auf dem verwalteten Knoten basierend auf dem Inhalt dieser gesperrten Version.
**Paket-Manager**
Amazon Linux 2 verwaltete Knoten verwenden YUM als Paket-Manager. Amazon Linux 2023 verwendet DNF als Paket-Manager.
Beide Paket-Manager verwenden das Konzept einer *Aktualisierungsbenachrichtigung* in Form einer Datei mit dem Namen `updateinfo.xml`. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. Alle Pakete in einem Update-Hinweis werden von Patch Manager als sicherheitsrelevant betrachtet. Einzelnen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Daher weist Patch Manager die Attribute eines Update-Hinweises den jeweiligen Paketen zu.
**Anmerkung**
Wenn Sie das Kontrollkästchen **Funktionsupdates einschließen** auf der Seite **Patch-Baseline erstellen** aktivieren, können Pakete, die nicht in einer `updateinfo.xml`-Datei klassifiziert sind (oder Pakete, die eine Datei ohne korrekt formatierte Klassifizierung, Schweregrad und Datenwerte), in die vorgefilterte Patchliste aufgenommen werden. Damit ein Patch jedoch angewendet werden kann, muss er dennoch die benutzerspezifischen Patch-Baseline-Regeln erfüllen.
Weitere Informationen zur Option **Nicht sicherheitsrelevante Updates einbeziehen** finden Sie unter [Wie Patches installiert werden](patch-manager-installing-patches.md) und [Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen](patch-manager-linux-rules.md).
------
#### [ CentOS Stream ]
Der Patch-Baseline-Service des Systems Managers auf CentOS Stream verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Die folgende Liste enthält Beispiele für ein fiktives CentOS 9.2 Amazon Machine Image (AMI):
+ **Repo-ID**: `example-centos-9.2-base`
**Repo-Name**: `Example CentOS-9.2 - Base`
+ **Repo-ID**: `example-centos-9.2-extras`
**Repo-Name**: `Example CentOS-9.2 - Extras`
+ **Repo-ID**: `example-centos-9.2-updates`
**Repo-Name**: `Example CentOS-9.2 - Updates`
+ **Repo-ID**: `example-centos-9.x-examplerepo`
**Repo-Name**: `Example CentOS-9.x – Example Repo Packages`
**Anmerkung**
Alle Updates werden von den auf dem verwalteten Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten über einen ausgehenden Zugang zum Internet verfügen, um eine Verbindung zu den Repos herzustellen, damit das Patching durchgeführt werden kann.
CentOS Stream-Knoten verwenden DNF als Paket-Manager. Der Paket-Manager verwenden das Konzept eines Update-Hinweises. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben.
Standard-Repos von CentOS Stream werden jedoch nicht mit einem Update-Hinweis konfiguriert. Das bedeutet, dass Patch Manager Pakete auf einem Standard-CentOS Stream-Repos nicht erkennt. Um Patch Manager für die Verarbeitung von Paketen, die nicht in einem Update-Hinweis enthalten sind, zu aktivieren, müssen Sie die `EnableNonSecurity`-Markierung in den Patch-Baseline-Regeln aktivieren.
**Anmerkung**
CentOS Stream-Update-Hinweise werden unterstützt. Repos mit Update-Hinweisen können nach dem Start heruntergeladen werden.
------
#### [ Debian Server ]
Der Systems Manager-Patch-Baseline-Service auf Debian Server verwendet vorkonfigurierte Repositorys (Repos) auf der Instance. Diese vorkonfigurierten Repos werden verwendet, um eine aktualisierte Liste der verfügbaren Paket-Upgrades abzurufen. Dazu führt Systems Manager das Äquivalent eines `sudo apt-get update`-Befehls durch.
Pakete werden dann aus `debian-security codename`-Repos gefiltert. Das bedeutet, dass für jede Version von Debian Server, Patch Manager nur Upgrades identifiziert, die Teil des zugehörigen Repositorys für diese Version sind, und zwar wie folgt:
+ Debian Server11: `debian-security bullseye`
+ Debian Server12: `debian-security bookworm`
------
#### [ Oracle Linux ]
Der Patch-Baseline-Service des Systems Managers auf Oracle Linux verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Es gibt in der Regel zwei vorkonfigurierte Repositorys (Repos) auf einem Knoten.
**Oracle Linux 7**:
+ **Repo-ID**: `ol7_UEKR5/x86_64`
**Repo-Name**: `Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **Repo-ID**: `ol7_latest/x86_64`
**Repo-Name**: `Oracle Linux 7Server Latest (x86_64)`
**Oracle Linux 8**:
+ **Repo-ID**: `ol8_baseos_latest`
**Repo-Name**: `Oracle Linux 8 BaseOS Latest (x86_64)`
+ **Repo-ID**: `ol8_appstream`
**Repo-Name**: `Oracle Linux 8 Application Stream (x86_64)`
+ **Repo-ID**: `ol8_UEKR6`
**Repo-Name**: `Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`
**Oracle Linux 9**:
+ **Repo-ID**: `ol9_baseos_latest`
**Repo-Name**: `Oracle Linux 9 BaseOS Latest (x86_64)`
+ **Repo-ID**: `ol9_appstream`
**Repo-Name**: `Oracle Linux 9 Application Stream Packages(x86_64)`
+ **Repo-ID**: `ol9_UEKR7`
**Repo-Name**: `Oracle Linux UEK Release 7 (x86_64)`
**Anmerkung**
Alle Updates werden von den auf dem verwalteten Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten über einen ausgehenden Zugang zum Internet verfügen, um eine Verbindung zu den Repos herzustellen, damit das Patching durchgeführt werden kann.
Von Oracle Linux verwaltete Knoten verwenden Yum als Paketmanager und Yum verwendet das Konzept eines Update-Hinweises in Form einer Datei namens `updateinfo.xml`. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. Einzelnen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Aus diesem Grund weist Patch Manager die Attribute eines Update-Hinweises den jeweiligen Paketen zu und installiert Pakete basierend auf den Klassifizierungsfiltern, die in der Patch-Baseline angegeben sind.
**Anmerkung**
Wenn Sie das Kontrollkästchen **Funktionsupdates einschließen** auf der Seite **Patch-Baseline erstellen** aktivieren, können Pakete, die nicht in einer `updateinfo.xml`-Datei klassifiziert sind (oder Pakete, die eine Datei ohne korrekt formatierte Klassifizierung, Schweregrad und Datenwerte), in die vorgefilterte Patchliste aufgenommen werden. Damit ein Patch jedoch angewendet werden kann, muss er dennoch die benutzerspezifischen Patch-Baseline-Regeln erfüllen.
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
Ein AlmaLinuxRed Hat Enterprise Linux, und Rocky Linux der Systems Manager Patch Baseline Service verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Es gibt in der Regel drei vorkonfigurierte Repositorys (Repos) auf einem Knoten.
Alle Updates werden von den auf dem verwalteten Knoten konfigurierten Remote-Repos heruntergeladen. Daher muss der Knoten über einen ausgehenden Zugang zum Internet verfügen, um eine Verbindung zu den Repos herzustellen, damit das Patching durchgeführt werden kann.
**Anmerkung**
Wenn Sie das Kontrollkästchen **Funktionsupdates einschließen** auf der Seite **Patch-Baseline erstellen** aktivieren, können Pakete, die nicht in einer `updateinfo.xml`-Datei klassifiziert sind (oder Pakete, die eine Datei ohne korrekt formatierte Klassifizierung, Schweregrad und Datenwerte), in die vorgefilterte Patchliste aufgenommen werden. Damit ein Patch jedoch angewendet werden kann, muss er dennoch die benutzerspezifischen Patch-Baseline-Regeln erfüllen.
Red Hat Enterprise Linux7 verwaltete Knoten verwenden Yum als Paketmanager. AlmaLinux, Red Hat Enterprise Linux 8, und Rocky Linux verwaltete Knoten verwenden DNF als Paketmanager. Beide Paketmanager verwenden das Konzept eines Update-Hinweises als Datei namens `updateinfo.xml`. Ein Update-Hinweis ist einfach eine Sammlung von Paketen, die bestimmte Probleme beheben. Einzelnen Paketen werden keine Klassifizierungen oder Schweregrade zugewiesen. Aus diesem Grund weist Patch Manager die Attribute eines Update-Hinweises den jeweiligen Paketen zu und installiert Pakete basierend auf den Klassifizierungsfiltern, die in der Patch-Baseline angegeben sind.
RHEL 7
Das folgende Repo ist mit IDs RHUI 2 verknüpft. RHUI 3 wurde im Dezember 2019 veröffentlicht und führte ein anderes Benennungsschema für das Yum-Repository ein. IDs Abhängig von dem RHEL-7-AMI, aus dem Sie Ihre verwalteten Knoten erstellen, müssen Sie möglicherweise Ihre Befehle aktualisieren. Weitere Informationen finden Sie unter [Repository IDs for RHEL 7 in Have AWS Changed](https://access.redhat.com/articles/4599971) im *Red Hat* Customer Portal.
+ **Repo-ID**: `rhui-REGION-client-config-server-7/x86_64`
**Repo-Name**: `Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **Repo-ID**: `rhui-REGION-rhel-server-releases/7Server/x86_64`
**Repo-Name**: `Red Hat Enterprise Linux Server 7 (RPMs)`
+ **Repo-ID**: `rhui-REGION-rhel-server-rh-common/7Server/x86_64`
**Repo-Name**: `Red Hat Enterprise Linux Server 7 RH Common (RPMs)`
AlmaLinux, 8, RHEL 8 und Rocky Linux 8
+ **Repo-ID**: `rhel-8-appstream-rhui-rpms`
**Repo-Name**: `Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **Repo-ID**: `rhel-8-baseos-rhui-rpms`
**Repo-Name**: `Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **Repo-ID**: `rhui-client-config-server-8`
**Repo-Name**: `Red Hat Update Infrastructure 3 Client Configuration Server 8`
AlmaLinux 9, RHEL 9 und Rocky Linux 9
+ **Repo-ID**: `rhel-9-appstream-rhui-rpms`
**Repo-Name**: `Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **Repo-ID**: `rhel-9-baseos-rhui-rpms`
**Repo-Name**: `Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **Repo-ID**: `rhui-client-config-server-9`
**Repo-Name**: `Red Hat Enterprise Linux 9 Client Configuration`
------
#### [ SLES ]
Auf von SUSE Linux Enterprise Server (SLES) verwalteten Knoten erhält die ZYPP-Bibliothek die Liste der verfügbaren Patches (eine Sammlung von Paketen) von den folgenden Standorten:
+ Liste der Repositorys: `etc/zypp/repos.d/*`
+ Paketinformationen: `/var/cache/zypp/raw/*`
Von SLES verwaltete Knoten verwenden Zypper als Paketmanager und Zypper verwendet das Konzept eines Patches. Ein Patch ist einfach eine Sammlung von Paketen, die ein bestimmtes Problem beheben. Patch Manager behandelt alle Pakete, auf die in einem Patch verwiesen wird, als sicherheitsbezogen. Da einzelnen Paketen weder Klassifizierungen noch Schweregrade zugewiesen werden, weist Patch Manager den Paketen die Attribute des Patches zu, dem sie angehören.
------
#### [ Ubuntu Server ]
Der Patch-Baseline-Service des Systems Managers auf Ubuntu Server verwendet vorkonfigurierte Repositorys (Repos) auf dem verwalteten Knoten. Diese vorkonfigurierten Repos werden verwendet, um eine aktualisierte Liste der verfügbaren Paket-Upgrades abzurufen. Dazu führt Systems Manager das Äquivalent eines `sudo apt-get update`-Befehls durch.
Pakete werden dann aus `codename-security`-Repos gefiltert, wobei der Codename für die Release-Version eindeutig ist, z. B. `trusty` für Ubuntu Server 14. Patch Manager identifiziert nur Upgrades, die Teil dieser Repos sind:
+ 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 ]
Unter Microsoft Windows-Betriebssystemen ruft Patch Manager eine Liste der verfügbaren, von Microsoft über Microsoft Update veröffentlichten und automatisch auf Windows Server Update Services (WSUS) verfügbaren Updates ab.
**Anmerkung**
Patch Manager stellt nur dann Patches für Windows Server-Betriebssystemversionen bereit, wenn diese für Patch Manager unterstützt werden. Beispiel: Patch Manager kann nicht zum Patchen von Windows RT verwendet werden.
Patch Manager überwacht kontinuierlich neue Updates in allen AWS-Region. Die Liste der verfügbaren Updates wird in jeder Region mindestens einmal pro Tag aktualisiert. Wenn die Patch-Informationen von Microsoft verarbeitet werden, entfernt Patch Manager Updates, die durch spätere Updates ersetzt wurden, aus der Patch-Liste. Daher werden nur die neuesten Updates angezeigt und zur Installation zur Verfügung gestellt. Beispiel: Wenn `KB4012214` `KB3135456` ersetzt, steht nur `KB4012214` als Update in Patch Manager zur Verfügung.
Ebenso kann Patch Manager nur Patches installieren, die zum Zeitpunkt des Patchvorgangs auf dem verwalteten Knoten verfügbar sind. Standardmäßig entfernen Windows Server 2019 und Windows Server 2022 Updates, die durch spätere Updates ersetzt werden. Wenn Sie den `ApproveUntilDate`-Parameter in einer Windows Server-Patch-Baseline verwenden, das im `ApproveUntilDate`-Parameter ausgewählte Datum jedoch *vor dem* Datum des letzten Patches liegt, tritt das folgende Szenario ein:
+ Der ersetzte Patch wurde vom Knoten entfernt und kann daher nicht mit Patch Manager installiert werden.
+ Der neueste Ersatz-Patch ist auf dem Knoten vorhanden, wurde aber zum angegebenen Datum noch nicht für die `ApproveUntilDate`-Installation freigegeben.
Das bedeutet, dass der verwaltete Knoten die Anforderungen des Systems-Manager-Betriebs erfüllt, auch wenn ein kritischer Patch aus dem Vormonat möglicherweise nicht installiert wurde. Das gleiche Szenario kann bei Verwendung des `ApproveAfterDays`-Parameters auftreten. Aufgrund des Verhaltens von Microsoft bei abgelösten Patches ist es möglich, eine Zahl (im Allgemeinen größer als 30 Tage) festzulegen, sodass Patches für Windows Server nie installiert werden, wenn der neueste verfügbare Patch von Microsoft veröffentlicht wird, bevor die Anzahl der Tage in `ApproveAfterDays` verstrichen ist. Beachten Sie, dass dieses Systemverhalten nicht zutrifft, wenn Sie Ihre Einstellungen für das Windows-Gruppenrichtlinienobjekt (GPO) so geändert haben, dass der abgelöste Patch auf Ihren verwalteten Knoten verfügbar ist.
**Anmerkung**
In einigen Fällen veröffentlicht Microsoft Patches für Anwendungen, die kein aktualisiertes Datum und keine aktualisierte Uhrzeit angeben. In diesen Fällen wird ein aktualisiertes Datum und eine Uhrzeit von `01/01/1970` standardmäßig angegeben.
------
# So geben Sie ein alternatives Patch-Quell-Repository an (Linux)
Wenn Sie die auf einem verwalteten Knoten konfigurierten Standardrepositorys für Patch-Operationen verwenden Patch Manager AWS Systems Manager, sucht ein Tool in nach sicherheitsrelevanten Patches oder installiert diese. Dies ist das Standardverhalten für Patch Manager. Ausführliche Informationen darüber, wie Patch Manager Sicherheits-Patches auswählt und installiert, finden Sie unter [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md).
Sie können auf Linux-Systemen jedoch auch mithilfe von Patch Manager Patches installieren, die nicht auf Sicherheit bezogen sind oder die sich in einem anderen als dem Standard-Quell-Repository befinden, das in dem verwalteten Knoten konfiguriert ist. Sie können beim Erstellen einer benutzerdefinierten Patch-Baseline alternative Patch-Quell-Repositorys angeben. Für jede benutzerdefinierte Patch-Baseline können Sie Patch-Quellkonfigurationen für bis zu 20 Versionen eines unterstützten Linux-Betriebssystems angeben.
Angenommen, Ihre Ubuntu Server-Flotte beinhaltet Ubuntu Server 25.04-verwaltete Knoten. In diesem Fall können Sie alternative Repositorys für jede Version in derselben benutzerdefinierten Patch-Baseline angeben. Geben Sie für jede Version einen Namen, die Version und den Typ des Betriebssystems (Produkt) und eine Repository-Konfiguration an. Sie können auch ein einziges alternatives Quell-Repository angeben, das für alle Versionen eines unterstützten Betriebssystems gilt.
**Anmerkung**
Wenn Sie eine benutzerdefinierte Patch-Baseline ausführen, die alternative Patch-Repositorys für einen verwalteten Knoten angeben, werden diese Repositorys dadurch nicht zum neuen Standard-Repository auf dem Betriebssystem. Nach Abschluss der Patching-Operation bleiben die zuvor definierten Standard-Repositorys für das Betriebssystem des Knoten als Standard erhalten.
Eine Liste mit Beispielszenarien zur Verwendung dieser Option finden Sie weiter [Anwendungsbeispiele für alternative Patch-Quell-Repositorys](#patch-manager-alternative-source-repository-examples) unten in diesem Thema.
Weitere Informationen zu Standard- und benutzerdefinierten Patch-Baselines finden Sie unter [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md).
**Beispiel: Verwenden der Konsole**
Um alternative Patch-Quell-Repositorys anzugeben, wenn Sie in der Systems Manager-Konsole arbeiten, verwenden Sie den Abschnitt **Patch sources** auf der Seite **Create patch baseline**. Weitere Informationen zur Verwendung der Optionen in **Patch sources (Patch-Quellen)** finden Sie unter [So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux](patch-manager-create-a-patch-baseline-for-linux.md).
**Beispiel: Verwendung des AWS CLI**
Ein Beispiel für die Verwendung der Option `--sources` mit der AWS Command Line Interface (AWS CLI) finden Sie in [Erstellen einer Patch-Baseline mit benutzerdefinierten Repositorys für verschiedene Betriebssystemversionen](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources).
**Topics**
+ [Wichtige Überlegungen für alternative Repositorys](#alt-source-repository-important)
+ [Anwendungsbeispiele für alternative Patch-Quell-Repositorys](#patch-manager-alternative-source-repository-examples)
## Wichtige Überlegungen für alternative Repositorys
Beachten Sie die folgenden Punkte, wenn Sie planen, in Ihrer Patching-Strategie alternative Patch-Repositorys zu verwenden.
**Erzwingen Sie Überprüfungen von Repo-Updates (YUM und DNF)**
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution kann so eingestellt sein, dass ein nicht erreichbares Paket-Repository übersprungen wird, wenn keine Verbindung zum Repository hergestellt werden kann. Um die Überprüfung des Repository-Updates `skip_if_unavailable=False` zu erzwingen, fügen Sie es der Repository-Konfiguration hinzu.
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).
**Nur angegebene Repositorys werden für das Einspielen von Patches verwendet.**
Angeben von alternativen Repositorys bedeutet nicht das Angeben *zusätzlicher* Repositorys. Sie können wählen, andere Repositorys als die auf einem verwalteten Knoten als Standardwerte konfigurierten festzulegen. Sie müssen jedoch auch die Standard-Repositorys als Teil der alternativen Patch-Quell-Konfiguration angeben, wenn Sie möchten, dass deren Updates übernommen werden.
Beispielsweise sind die Standard-Repositorys auf von Amazon Linux 2 verwalteten Knoten `amzn2-core` und `amzn2extra-docker`. Wenn Sie das Repository "Extra Packages for Enterprise Linux (EPEL)" in Ihre Patching-Operationen einschließen möchten, müssen Sie alle drei Repositorys als alternative Repositorys angeben.
**Anmerkung**
Wenn Sie eine benutzerdefinierte Patch-Baseline ausführen, die alternative Patch-Repositorys für einen verwalteten Knoten angeben, werden diese Repositorys dadurch nicht zum neuen Standard-Repository auf dem Betriebssystem. Nach Abschluss der Patching-Operation bleiben die zuvor definierten Standard-Repositorys für das Betriebssystem des Knoten als Standard erhalten.
**Das Patching-Verhalten für YUM-basierte Distributionen hängt vom updateinfo.xml-Manifest ab**
Wenn Sie alternative Patch-Repositorys für YUM-basierte Distributionen festlegen, z. B. Amazon Linux 2 oder Red Hat Enterprise Linux, hängt das Patching-Verhalten davon ab, ob das Repository ein Update-Manifest in Form einer vollständig und korrekt formatierten `updateinfo.xml`-Datei enthält. Diese Datei gibt das Release-Datum, Klassifizierungen und Schweregrade der verschiedenen Pakete an. Jede der folgenden Optionen wirkt sich auf das Patching-Verhalten aus:
+ Wenn Sie nach **Klassifizierung** und **Schweregrad** filtern, diese aber nicht in `updateinfo.xml` angegeben sind, wird das Paket nicht in Filter aufgenommen. Dies bedeutet auch, dass Pakete ohne eine `updateinfo.xml`-Datei werden nicht in das Patching eingeschlossen werden.
+ Wenn Sie nach filtern **ApprovalAfterDays**, aber das Veröffentlichungsdatum des Pakets nicht im Format Unix Epoch ist (oder kein Veröffentlichungsdatum angegeben ist), wird das Paket nicht in den Filter aufgenommen.
+ Eine Ausnahme besteht, wenn Sie das Kontrollkästchen **Genehmigte Patches umfassen nicht sicherheitsrelevante Updates** auf der Seite **Patch-Baseline erstellen** aktivieren. In diesem Fall *werden* Pakete ohne eine `updateinfo.xml`-Datei (oder die diese Datei ohne ordnungsgemäß formatierte Werte für **Klassifizierung**, **Schweregrad** und **Datum** enthalten) in die vorgefilterte Liste der Patches aufgenommen. (Diese müssen nach wie vor die übrigen Anforderungen Patch-Baseline Regel erfüllen, damit sie installiert werden.)
## Anwendungsbeispiele für alternative Patch-Quell-Repositorys
**Beispiel 1: Nicht sicherheitsrelevante Updates für Ubuntu Server**
Sie verwenden bereitsPatch Manager, um Sicherheitspatches auf einer Flotte von Ubuntu Server verwalteten Knoten mithilfe der von AWS Ihnen bereitgestellten vordefinierten Patch-Baseline zu installieren. `AWS-UbuntuDefaultPatchBaseline` Sie können eine neue Patch-Baseline erstellen, die auf diesem Standard basiert, aber in den Genehmigungsregeln angeben, dass nicht auf die Sicherheit bezogene Updates, die Teil der Standardverteilung sind, ebenfalls installiert werden sollen. Wenn diese Patch-Baseline für Ihre Knoten ausgeführt wird, werden sowohl sicherheitsbezogene als auch nicht-sicherheitsbezogene Patches angewendet. Sie können auch auswählen, dass nicht sicherheitsbezogene Patches in den Patch-Ausnahmen, die Sie für eine Baseline angeben, genehmigt werden.
**Beispiel 2: Personal Package Archives (PPA) für Ubuntu Server**
Auf Ihren von Ubuntu Server verwalteten Knoten wird Software ausgeführt, die über ein [Personal Package Archives (PPA) für Ubuntu](https://launchpad.net/ubuntu/+ppas) verteilt wird. In diesem Fall erstellen Sie eine Patch-Baseline, die ein PPA-Repository angibt, das Sie auf dem verwalteten Knoten als das Quell-Repository für die Patch-Operation konfiguriert haben. Führen Sie anschließend mithilfe von Run Command das Patch-Baseline-Dokument auf den Knoten aus.
**Beispiel 3: Interne Firmenanwendungen in unterstützten Amazon-Linux-Versionen**
Sie müssen auf Ihren von Amazon Linux verwalteten Knoten einige Anwendungen ausführen, die für die Compliance gesetzlicher Vorschriften und Branchenstandards erforderlich sind. Sie können ein Repository für diese Anwendungen auf den Knoten konfigurieren, mit YUM die Anwendungen erstmals installieren und eine neue Patch-Baseline aktualisieren oder erstellen, um dieses neue Unternehmens-Repository hinzuzufügen. Anschließend können Sie mit Run Command das Dokument `AWS-RunPatchBaseline` mit der Option `Scan` ausführen, um zu prüfen, ob das Unternehmenspaket unter den installierten Paketen aufgelistet und auf dem verwalteten Knoten aktuell ist. Wenn es nicht aktuell ist, können Sie das Dokument mithilfe der Option `Install` erneut ausführen, um die Anwendungen zu aktualisieren.
# Wie Patches installiert werden
Patch Manager, ein Tool in AWS Systems Manager, verwendet den im Betriebssystem integrierten Paketmanager, um Updates auf verwalteten Knoten zu installieren. Beispielsweise verwendet es die Windows Update API `DNF` auf Windows Server und unter Amazon Linux 2023. Patch Manager berücksichtigt bestehende Paketmanager- und Repository-Konfigurationen auf den Knoten, einschließlich Einstellungen wie Repository-Status URLs, Spiegelung, GPG-Überprüfung und Optionen wie`skip_if_unavailable`.
Patch Manager installiert kein neues Paket, das ein veraltetes Paket ersetzt, das derzeit installiert ist. (Ausnahmen: Das neue Paket hängt davon ab, ob ein anderes Paket-Update installiert wird, oder das neue Paket hat denselben Namen wie das veraltete Paket.) Stattdessen meldet und installiert Patch Manager verfügbare Updates für installierte Pakete. Dieser Ansatz trägt dazu bei, unerwartete Änderungen an der Systemfunktionalität zu verhindern, die auftreten können, wenn ein Paket ein anderes ersetzt.
Wenn Sie ein veraltetes Paket deinstallieren und dessen Ersatz installieren müssen, müssen Sie möglicherweise ein benutzerdefiniertes Skript verwenden oder Paket-Manager-Befehle außerhalb der Standardvorgänge von Patch Manager verwenden.
Wählen Sie aus den folgenden Registerkarten, um zu erfahren, wie Patch Manager Patches auf einem Betriebssystem installiert.
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
Auf von Amazon Linux 2 und Amazon Linux 2023 verwalteten Knoten sieht der Workflow der Patch-Installation wie folgt aus:
1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.
1. Wenden Sie [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) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.
Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [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) verworfen wurden oder wenn keine in [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) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.
1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.
1. Die YUM-Aktualisierungs-API (Amazon Linux 2) oder die DNF-Aktualisierungs-API (Amazon Linux 2023) wird wie folgt auf genehmigte Patches angewendet:
+ Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, werden nur die in `updateinfo.xml` angegebenen Patches angewendet (nur Sicherheitsupdates). Dies liegt daran, dass das Kontrollkästchen **Funktionsupdates einschließen** nicht aktiviert ist. Die vordefinierten Baselines entsprechen einer benutzerdefinierten Baseline mit folgenden Eigenschaften:
+ Das Kontrollkästchen **Funktionsupdates einschließen** ist nicht aktiviert
+ Eine Liste des SCHWEREGRADE von `[Critical, Important]`
+ Eine Liste der KLASSIFIZIERUNGEN von `[Security, Bugfix]`
Für Amazon Linux 2 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt:
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
Für Amazon Linux 2023 lautet der entsprechende DNF-Befehl für diesen Workflow wie folgt:
```
sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
```
Wenn das Kontrollkästchen **Funktionsupdates einschließen** aktiviert ist, werden alle Patches angewendet (Sicherheits- und Funktionsupdates), die in `updateinfo.xml` und nicht in `updateinfo.xml` sind.
Für Amazon Linux 2, wenn eine Baseline mit **Funktionsupdates einschließen** ausgewählt ist, und die eine SCHWEREGRAD-Liste von `[Critical, Important]` und eine KLASSIFIKATION-Liste von `[Security, Bugfix]` hat, lautet der entsprechende YUM-Befehl:
```
sudo yum update --security --sec-severity=Critical,Important --bugfix -y
```
Für Amazon Linux 2023 lautet der entsprechende DNF-Befehl wie folgt:
```
sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
```
**Anmerkung**
Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese `yum`- oder `dnf`-Befehle außerhalb von Patch Manager ausführen. Sie werden jedoch *nicht* mit den entsprechenden Patch Manager-Vorgängen installiert.
**Zusätzliche Patchdetails für Amazon Linux 2023**
Support für den Schweregrad „Keine“
Amazon Linux 2023 unterstützt auch den Patch-Schweregrad `None`, der vom DNF-Paket-Manager erkannt wird.
Support für den Schweregrad „Mittel“
Für Amazon Linux 2023 entspricht ein Patch-Schweregrad von `Medium` einem Schweregrad von `Moderate`, der möglicherweise in einigen externen Repositorys definiert ist. Wenn Sie Patches mit dem `Medium`-Schweregrad in die Patch-Baseline aufnehmen, werden auch Patches mit dem `Moderate`-Schweregrad von externen Patches auf den Instances installiert.
Wenn Sie Konformitätsdaten mit der API-Aktion [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) abfragen, werden beim Filtern nach dem Schweregrad `Medium` Patches mit den Schweregraden `Medium` und `Moderate` gemeldet.
Transitive Abhängigkeitsbehandlung für Amazon Linux 2023
Für Amazon Linux 2023 installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden `dnf`-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).
`dnf upgrade-minimal --security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die ** neuesten verfügbaren Versionen derselben transitiven Abhängigkeiten.
1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)
**Anmerkung**
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution könnte so eingestellt sein, dass ein Paket-Repository, das nicht erreichbar ist, ohne Fehler übersprungen wird. In solchen Fällen wird der entsprechende Patchvorgang ohne Installation von Updates aus dem Projektarchiv fortgesetzt und erfolgreich abgeschlossen. Um Repository-Updates zu erzwingen, fügen Sie `skip_if_unavailable=False` es der Repository-Konfiguration hinzu.
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).
------
#### [ CentOS Stream ]
Auf von CentOS Stream verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:
1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.
Wenden Sie [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) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.
Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [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) verworfen wurden oder wenn keine in [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) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.
1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.
1. Das DNF-Update auf CentOS Stream wird auf genehmigte Patches angewendet.
**Anmerkung**
Für CentOS Stream installiert Patch Manager möglicherweise andere Versionen transitiver Abhängigkeiten als die entsprechenden `dnf`-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).
`dnf upgrade-minimal ‐‐security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die *neuesten verfügbaren Versionen* derselben transitiven Abhängigkeiten.
1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)
------
#### [ Debian Server ]
Auf Debian Server-Instances sieht der Patch-Installations-Workflow wie folgt aus:
1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.
1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)
1. Wenden Sie [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) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.
**Anmerkung**
Da es nicht möglich ist, die Veröffentlichungstermine von Update-Paketen für Debian Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.
Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
**Anmerkung**
Für Debian Server sind Patch-Kandidaten-Versionen auf Patches beschränkt, die in `debian-security` enthalten sind.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [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) verworfen wurden oder wenn keine in [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) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.
1. Die APT-Bibliothek wird verwendet, um Upgrades für Pakete durchzuführen.
**Anmerkung**
Patch Manager unterstützt nicht die Verwendung der `Pin-Priority`-APT-Option, um Paketen Prioritäten zuzuweisen. Patch Manager aggregiert verfügbare Updates aus allen aktivierten Repositorys und wählt das neueste Update aus, das der Baseline für jedes installierte Paket entspricht.
1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)
------
#### [ macOS ]
Auf von macOS verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:
1. Die `/Library/Receipts/InstallHistory.plist`-Eigenschaft ist ein Datensatz der Software, die mit den `softwareupdate`- und `installer`-Paketmanagern installiert und aktualisiert wurde. Unter Verwendung der`pkgutil`-Befehlszeilen-Tool (für `installer`) und des `softwareupdate`-Paketmanagers werden CLI-Befehle ausgeführt, um diese Liste zu analysieren.
Für `installer` umfasst die Antwort auf die CLI-Befehle Details zu `package name`, `version`, `volume`, `location` und `install-time`, aber nur der `package name` und die `version` werden von Patch Manager verwendet.
Für `softwareupdate` umfasst die Antwort auf die CLI-Befehle den Paketnamen (`display name`),`version` und`date`, aber nur der Paketname und die Version werden vom Patch Manager verwendet.
Für Brew and Brew Cask unterstützt Homebrew seine Befehle, die unter dem Root-Benutzer ausgeführt werden, nicht. Darum fragt Patch Manager entweder als Eigentümer des Homebrew-Verzeichnisses oder als gültiger Benutzer,der zur Eigentümergruppe des Homebrew-Verzeichnisses gehört, Homebrew–Befehle ab und führt sie aus. Die Befehle sind ähnlich wie `softwareupdate` und `installer` und werden durch einen Python-Subprozess ausgeführt, um Paketdaten zu sammeln. Die Ausgabe wird dann analysiert, um Paketnamen und -versionen zu identifizieren.
1. Wenden Sie [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) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [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) verworfen wurden oder wenn keine in [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) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.
1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.
1. Ruft die entsprechende Paket-CLI auf dem verwalteten Knoten auf, um genehmigte Patches wie folgt zu verarbeiten:
**Anmerkung**
`installer` fehlt die Funktion, um nach Updates zu suchen und sie zu installieren. Daher meldet Patch Manager für `installer` nur, welche Pakete installiert sind. Das Ergebnis: `installer`-Pakete werden nie als `Missing` gemeldet.
+ Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, und für benutzerdefinierte Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *nicht* ausgewählt wurde, werden nur Sicherheitsupdates angewendet.
+ Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *aktiviert* ist, werden sowohl Sicherheits- als auch Funktionsupdates angewendet.
1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)
------
#### [ Oracle Linux ]
Auf von Oracle Linux verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:
1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.
1. Wenden Sie [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) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.
Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [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) verworfen wurden oder wenn keine in [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) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.
1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.
1. Auf von Version 7 verwalteten Knoten wird die YUM-Update-API wie folgt auf genehmigte Patches angewendet:
+ Für vordefinierte Standard-Patch-Baselines, die von AWS bereitgestellt werden, und für benutzerdefinierte Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *nicht* ausgewählt wurde, werden nur Patches, die in `updateinfo.xml` angegeben sind (nur Sicherheitsupdates), angewendet.
Der entsprechende Yum-Befehl für diesen Workflow lautet:
```
sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
```
+ Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *aktiviert* ist, werden sowohl Patches aus der Datei `updateinfo.xml` als auch solche, die nicht in `updateinfo.xml` enthalten sind, angewendet (sowohl Sicherheits- als auch Funktionsupdates).
Der entsprechende Yum-Befehl für diesen Workflow lautet:
```
sudo yum update --security --bugfix -y
```
Auf von Version 8 und 9 verwalteten Knoten wird die DNF-Update-API wie folgt auf genehmigte Patches angewendet:
+ Für vordefinierte Standard-Patch-Baselines, die von bereitgestellt werden AWS, und für benutzerdefinierte Patch-Baselines, bei denen das Kontrollkästchen **Nicht sicherheitsrelevante Updates einbeziehen** *nicht* aktiviert ist, `updateinfo.xml` werden nur die in angegebenen Patches angewendet (nur Sicherheitsupdates).
Der entsprechende Yum-Befehl für diesen Workflow lautet:
```
sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
```
**Anmerkung**
Für Oracle Linux installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden `dnf`-Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).
`dnf upgrade-minimal --security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die *neuesten verfügbaren Versionen* derselben transitiven Abhängigkeiten.
+ Bei benutzerdefinierten Patch-Baselines, bei denen das Kästchen **Funktionsupdates einschließen** *aktiviert* ist, werden sowohl Patches aus der Datei `updateinfo.xml` als auch solche, die nicht in `updateinfo.xml` enthalten sind, angewendet (sowohl Sicherheits- als auch Funktionsupdates).
Der entsprechende Yum-Befehl für diesen Workflow lautet:
```
sudo dnf upgrade --security --bugfix
```
**Anmerkung**
Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese `yum`- oder `dnf`-Befehle außerhalb von Patch Manager ausführen. Sie werden jedoch *nicht* mit den entsprechenden Patch Manager-Vorgängen installiert.
1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)
**Anmerkung**
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution kann so eingestellt sein, dass ein Paket-Repository, das nicht erreichbar ist, ohne Fehler übersprungen wird. In solchen Fällen wird der entsprechende Patchvorgang ohne Installation von Updates aus dem Projektarchiv fortgesetzt und erfolgreich abgeschlossen. Um Repository-Updates zu erzwingen, fügen Sie `skip_if_unavailable=False` es der Repository-Konfiguration hinzu.
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
Auf AlmaLinuxRed Hat Enterprise Linux, und Rocky Linux verwalteten Knoten sieht der Arbeitsablauf für die Patch-Installation wie folgt aus:
1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.
1. Wenden Sie [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) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.
Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [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) verworfen wurden oder wenn keine in [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) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.
1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.
1. Die YUM-Update-API (auf RHEL 7) oder die DNF-Update-API (auf AlmaLinux 8 und 9, RHEL 8, 9 und 10 sowie Rocky Linux 8 und 9) wird gemäß den folgenden Regeln auf genehmigte Patches angewendet:
**Szenario 1: Nicht sicherheitsrelevante Updates ausgeschlossen**
+ **Gilt für**: Vordefinierte Standard-Patch-Baselines, die von bereitgestellt werden, AWS und benutzerdefinierte Patch-Baselines.
+ Das Kontrollkästchen **Funktionsupdates einschließen** ist *nicht* aktiviert
+ **Angewendete Patches**: Die unter `updateinfo.xml` (nur Sicherheitsupdates) angegebenen Patches werden *nur* angewendet, wenn sie beide der Patch-Baseline-Konfiguration entsprechen und sich in den konfigurierten Repositorys befinden.
In einigen Fällen ist ein in `updateinfo.xml` spezifizierter Patch möglicherweise nicht mehr in einem konfigurierten Repository verfügbar. Konfigurierte Repositorys verfügen normalerweise nur über die neueste Version eines Patches, bei dem es sich um einen kumulativen Rollup aller vorherigen Updates handelt. Die neueste Version entspricht jedoch möglicherweise nicht den Patch-Baseline-Regeln und wird beim Patchen nicht berücksichtigt.
+ **Befehle**: Für RHEL 7 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt:
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
Für AlmaLinux, RHEL 8 undRocky Linux, lauten die entsprechenden dnf-Befehle für diesen Workflow:
```
sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y
```
**Anmerkung**
For AlmaLinuxRHEL, und Rocky Linux Rocky Linux installiert Patch Manager möglicherweise andere Versionen von transitiven Abhängigkeiten als die entsprechenden `dnf` Befehle install. Transitive Abhängigkeiten sind Pakete, die automatisch installiert werden, um die Anforderungen anderer Pakete zu erfüllen (Abhängigkeiten von Abhängigkeiten).
`dnf upgrade-minimal --security` installiert beispielsweise die *Minimalversionen* transitiver Abhängigkeiten, die zur Lösung bekannter Sicherheitsprobleme erforderlich sind, und Patch Manager installiert gleichzeitig die *neuesten verfügbaren Versionen* derselben transitiven Abhängigkeiten.
**Szenario 2: Nicht sicherheitsrelevante Updates enthalten**
+ **Gilt für**: Benutzerdefinierte Patch-Baselines.
+ Das Kontrollkästchen **Funktionsupdates einschließen** ist aktiviert.
+ **Angewendete Patches**: Patches in `updateinfo.xml` *und* nicht in `updateinfo.xml` werden angewendet (Sicherheits- und andere Updates).
+ **Befehle**: Für RHEL 7 lautet der entsprechende YUM-Befehl für diesen Workflow wie folgt:
```
sudo yum update --security --bugfix -y
```
Für AlmaLinux 8 und 9, RHEL 8 und 9 sowie Rocky Linux 8 und 9 lautet der entsprechende dnf-Befehl für diesen Workflow:
```
sudo dnf update --security --bugfix -y
```
**Anmerkung**
Neue Pakete, die veraltete Pakete mit anderen Namen ersetzen, werden installiert, wenn Sie diese `yum`- oder `dnf`-Befehle außerhalb von Patch Manager ausführen. Sie werden jedoch *nicht* mit den entsprechenden Patch Manager-Vorgängen installiert.
1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)
**Anmerkung**
Eine Standardkonfiguration für einen Paketmanager auf einer Linux-Distribution könnte so eingestellt sein, dass ein Paket-Repository, das nicht erreichbar ist, ohne Fehler übersprungen wird. In solchen Fällen wird der entsprechende Patchvorgang ohne Installation von Updates aus dem Projektarchiv fortgesetzt und erfolgreich abgeschlossen. Um Repository-Updates zu erzwingen, fügen Sie `skip_if_unavailable=False` es der Repository-Konfiguration hinzu.
Weitere Informationen zur Option `skip_if_available` finden Sie unter [Konnektivität zur Patch-Quelle](patch-manager-prerequisites.md#source-connectivity).
------
#### [ SLES ]
Auf von SUSE Linux Enterprise Server (SLES) verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:
1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.
1. Wenden Sie [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) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.
Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [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) verworfen wurden oder wenn keine in [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) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.
1. Wenn mehrere Versionen von Patches genehmigt wurden, wird die neueste Version angewendet.
1. Die Zypper-Update-API wird auf genehmigte Patches angewendet.
1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)
------
#### [ Ubuntu Server ]
Auf von Ubuntu Server verwalteten Knoten sieht der Patch-Installations-Workflow wie folgt aus:
1. Wenn eine Liste mit Patches mithilfe einer HTTPS-URL oder einer Amazon Simple Storage Service (Amazon S3)-URL im PathStyle über den `InstallOverrideList`-Parameter für die `AWS-RunPatchBaseline`- oder `AWS-RunPatchBaselineAssociation`-Dokumente angegeben wird, werden die aufgelisteten Patches installiert, und die Schritte 2-7 werden übersprungen.
1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)
1. Wenden Sie [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) wie in der Patch-Baseline an und behalten Sie nur die qualifizierten Pakete zur weiteren Verarbeitung.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Jede Genehmigungsregel kann ein Paket als genehmigt definieren.
**Anmerkung**
Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein.
Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
**Anmerkung**
Für jede Version von Ubuntu Server sind die Patchkandidatenversionen wie folgt auf Patches beschränkt, die Teil des zugehörigen Repositorys für diese Version sind:
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. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die genehmigten Patches sind für Updates genehmigt, auch wenn sie von [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) verworfen wurden oder wenn keine in [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) festgelegte Genehmigungsregel ihnen diese Genehmigung erteilt.
1. Wenden Sie [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) wie in der Patch-Baseline angegeben an. Die abgelehnten Patches werden aus der Liste der genehmigten Patches entfernt und werden nicht angewendet.
1. Die APT-Bibliothek wird verwendet, um Upgrades für Pakete durchzuführen.
**Anmerkung**
Patch Manager unterstützt nicht die Verwendung der `Pin-Priority`-APT-Option, um Paketen Prioritäten zuzuweisen. Patch Manager aggregiert verfügbare Updates aus allen aktivierten Repositorys und wählt das neueste Update aus, das der Baseline für jedes installierte Paket entspricht.
1. Der verwaltete Knoten wird neu gestartet, wenn Updates installiert wurden. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)
------
#### [ Windows Server ]
Wenn eine Patch-Operation auf einem von Windows Server verwalteten Knoten durchgeführt wird, fordert die Instance einen Snapshot der entsprechenden Patch-Baseline von Systems Manager an. Dieser Snapshot enthält die Liste aller in der Patch-Baseline verfügbaren Updates, die für die Bereitstellung genehmigt wurden. Diese Liste der Updates wird an die Windows-Update-API gesendet, die festlegt, welche Updates für den verwalteten Knoten zutreffen, und diese bei Bedarf installiert. Windows erlaubt nur die Installation der neuesten verfügbaren Version einer KB. Patch Manager installiert die neueste Version einer KB, wenn sie oder eine frühere Version der KB mit der angewendeten Patch-Baseline übereinstimmt. Wenn Updates installiert sind, wird der verwaltete Knoten danach so oft wie nötig neu gestartet, bis alle erforderlichen Patches abgeschlossen sind. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).) Die Zusammenfassung des Patch-Vorgangs finden Sie in der Ausgabe der Run Command-Anfrage. Zusätzliche Protokolle finden Sie auf dem verwalteten Knoten im `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`-Ordner.
Da die Windows Update-API zum Herunterladen und Installieren verwendet wird KBs, werden alle Gruppenrichtlinieneinstellungen für Windows Update berücksichtigt. Für die Verwendung von Patch Manager sind keine Gruppenrichtlinien-Einstellungen erforderlich. Allerdings werden alle definierten Einstellungen angewendet, wie etwa die Weiterleitung von verwalteten Knoten an einen Windows Server Update Services (WSUS)-Server.
**Anmerkung**
Standardmäßig lädt Windows alles KBs von der Windows Update-Website von Microsoft herunter, da die Windows Update-API Patch Manager verwendet wird, um den Download und die Installation von voranzutreiben KBs. Der verwaltete Knoten muss daher die Website von Microsoft Windows Update erreichen können. Andernfalls tritt ein Fehler bei der Patch-Operation auf. Alternativ können Sie einen WSUS-Server als KB-Repository konfigurieren und Ihre verwalteten Knoten so konfigurieren, dass sie den WSUS-Server anvisieren, anstatt Gruppenrichtlinien zu verwenden.
Patch Managerverweist möglicherweise auf KB, IDs wenn benutzerdefinierte Patch-Baselines für erstellt werdenWindows Server, z. B. wenn eine Liste **zulässiger Patches** oder **abgelehnter Patches** in der Basiskonfiguration enthalten ist. Nur Updates, denen in Microsoft Windows Update oder einem WSUS-Server eine KB-ID zugewiesen wurde, werden von Patch Manager installiert. Updates, denen eine KB-ID fehlt, sind nicht in den Patchvorgängen enthalten.
Informationen zum Erstellen benutzerdefinierter Patch-Baselines finden Sie in den folgenden Themen:
[Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
[Erstellen einer Patch-Baseline (CLI)](patch-manager-create-a-patch-baseline-for-windows.md)
[Paketnamen-Formate für Windows-Betriebssysteme](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)
------
# Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen
Die Regeln in einer Patch-Baseline für Linux-Verteilungen funktionieren je nach Verteilungstyp unterschiedlich. Im Gegensatz zu Patch-Updates auf Windows Server verwalteten Knoten werden Regeln auf jedem Knoten ausgewertet, um die konfigurierten Repos auf der Instanz zu berücksichtigen. Patch Manager, ein Tool in AWS Systems Manager, verwendet den systemeigenen Paketmanager, um die Installation von Patches voranzutreiben, die von der Patch-Baseline genehmigt wurden.
Für Linux-basierte Betriebssysteme, die einen Schweregrad für Patches melden, verwendet Patch Manager den vom Software-Publisher gemeldeten Schweregrad für den Update-Hinweis oder den einzelnen Patch. Patch Manager leitet keinen Schweregrad aus Drittquellen wie dem [Common Vulnerability Scoring System](https://www.first.org/cvss/) (CVSS) oder aus Metriken ab, die von der [National Vulnerability Database](https://nvd.nist.gov/vuln) (NVD) veröffentlicht werden.
**Topics**
+ [Funktionsweise von Patch-Baseline-Regeln unter Amazon Linux 2 und Amazon Linux 2023](#linux-rules-amazon-linux)
+ [Funktionsweise von Patch-Baseline-Regeln auf CentOS Stream](#linux-rules-centos)
+ [Funktionsweise von Patch-Baseline-Regeln auf Debian Server](#linux-rules-debian)
+ [Funktionsweise von Patch-Baseline-Regeln auf macOS](#linux-rules-macos)
+ [Funktionsweise von Patch-Baseline-Regeln auf Oracle Linux](#linux-rules-oracle)
+ [So funktionieren Patch-Basisregeln für AlmaLinuxRHEL, und Rocky Linux](#linux-rules-rhel)
+ [Funktionsweise von Patch-Baseline-Regeln auf SUSE Linux Enterprise Server](#linux-rules-sles)
+ [Funktionsweise von Patch-Baseline-Regeln auf Ubuntu Server](#linux-rules-ubuntu)
## Funktionsweise von Patch-Baseline-Regeln unter Amazon Linux 2 und Amazon Linux 2023
**Anmerkung**
Amazon Linux 2023 (AL2023) verwendet versionierte Repositorys, die über eine oder mehrere Systemeinstellungen für eine bestimmte Version gesperrt werden können. Für alle Patching-Vorgänge auf AL2023 EC2-Instances verwendet Patch Manager unabhängig von der Systemkonfiguration die neuesten Repository-Versionen. Weitere Informationen finden Sie unter [Deterministische Upgrades durch versionierte Repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html) im *Benutzerhandbuch von Amazon Linux 2023*.
Unter Amazon Linux 2 und Amazon Linux 2023 erfolgt die Patch-Auswahl folgendermaßen:
1. Auf dem verwalteten Knoten greift die YUM-Bibliothek (Amazon Linux 2) oder die DNF-Bibliothek (Amazon Linux 2023) auf die `updateinfo.xml`-Datei für jedes konfigurierte Repository zu.
Wenn keine `updateinfo.xml`-Datei gefunden wird, hängt es von den Einstellungen für **Funktionsupdates einschließen** und **Automatische Genehmigung** ab, ob Patches installiert werden. Wenn beispielsweise nicht sicherheitsrelevante Updates zulässig sind, werden sie installiert, wenn die automatische Genehmigung eintrifft.
1. Jeder Update-Hinweis in `updateinfo.xml` enthält mehrere Attribute, die die Eigenschaften der Pakete im Hinweis kennzeichnen, wie in der folgenden Tabelle beschrieben.
**Update-Hinweis-Attribute**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.
1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).
## Funktionsweise von Patch-Baseline-Regeln auf CentOS Stream
Die CentOS Stream-Standard-Repositorys enthalten keine `updateinfo.xml`-Datei. Benutzerdefinierte Repositorys, die Sie erstellen oder verwenden, können diese Datei jedoch enthalten. In diesem Thema beziehen sich Verweise nur `updateinfo.xml` auf diese benutzerdefinierten Repositorys.
In CentOS Stream erfolgt die Patch-Auswahl folgendermaßen:
1. Auf dem verwalteten Knoten ruft die DNF-Bibliothek die `updateinfo.xml`-Datei für jedes konfigurierte Repository auf, sofern diese in einem benutzerdefinierten Repository vorhanden ist.
Wenn kein `updateinfo.xml` gefunden wird (was immer die Standard-Repos einschließt), hängt die Installation von Patches von den Einstellungen für **Nicht sicherheitsrelevante Updates einschließen** und **Automatische Genehmigung** ab. Wenn beispielsweise nicht sicherheitsrelevante Updates zulässig sind, werden sie installiert, wenn die automatische Genehmigung eintrifft.
1. Wenn `updateinfo.xml` vorhanden ist, enthält jede Aktualisierungsmitteilung in der Datei mehrere Attribute, die die Eigenschaften der Pakete in der Mitteilung bezeichnen, wie in der folgenden Tabelle beschrieben.
**Update-Hinweis-Attribute**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
1. Das Produkt des verwalteten Knotens wird in allen Fällen durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.
1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).
## Funktionsweise von Patch-Baseline-Regeln auf Debian Server
Auf Debian Server bietet der Patch-Baseline-Service Filter in den Feldern *Priorität* und *Abschnitt*. Diese Felder sind normalerweise für alle Debian Server-Pakete vorhanden. Um zu bestimmen, ob ein Patch von der Patch-Baseline ausgewählt wird, geht Patch Manager folgendermaßen vor:
1. Auf Debian Server-Systemen wird das Äquivalent von `sudo apt-get update` ausgeführt, um die Liste der verfügbaren Pakete zu aktualisieren. Repos sind nicht konfiguriert und die Daten werden aus Repos abgerufen, die in einer `sources`-Liste konfiguriert sind.
1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)
1. Als Nächstes werden die Listen [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) und [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) angewendet.
**Anmerkung**
Da es nicht möglich ist, die Veröffentlichungstermine von Update-Paketen für Debian Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. Für Debian Server sind Patch-Kandidaten-Versionen in diesem Fall auf Patches beschränkt, die in den folgenden Repos enthalten sind:
Diese Repos werden wie folgt benannt:
+ Debian Server11: `debian-security bullseye`
+ Debian Server12: `debian-security bookworm`
Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
Zum Anzeigen der Inhalte der Felder *Priorität* und *Abschnitt* führen Sie den folgenden `aptitude`-Befehl aus:
**Anmerkung**
Möglicherweise müssen Sie zuerst Aptitude auf Debian Server-Systemen installieren.
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
In der Antwort auf diesen Befehl werden alle Pakete, für die ein Upgrade durchgeführt werden kann, in diesem Format gemeldet:
```
name, priority, section, archive, candidate version
```
Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).
## Funktionsweise von Patch-Baseline-Regeln auf macOS
In macOS erfolgt die Patch-Auswahl folgendermaßen:
1. Auf dem verwalteten Knoten greift Patch Manager auf den geparsten Inhalt der `InstallHistory.plist`-Datei zu und identifiziert Paketnamen und -versionen.
Details zum Parsing-Prozess finden Sie unter der Registerkarte **macOS** in [Wie Patches installiert werden](patch-manager-installing-patches.md).
1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.
1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).
## Funktionsweise von Patch-Baseline-Regeln auf Oracle Linux
In Oracle Linux erfolgt die Patch-Auswahl folgendermaßen:
1. Auf dem verwalteten Knoten ruft die YUM-Bibliothek die `updateinfo.xml`-Datei für jedes konfigurierte Repo auf.
**Anmerkung**
Die `updateinfo.xml`-Datei ist möglicherweise nicht verfügbar, wenn das Repo nicht von Oracle verwaltet wird. Wenn keine `updateinfo.xml`-Datei gefunden wird, hängt es von den Einstellungen für **Funktionsupdates einschließen** und **Automatische Genehmigung** ab, ob Patches installiert werden. Wenn beispielsweise nicht sicherheitsrelevante Updates zulässig sind, werden sie installiert, wenn die automatische Genehmigung eintrifft.
1. Jeder Update-Hinweis in `updateinfo.xml` enthält mehrere Attribute, die die Eigenschaften der Pakete im Hinweis kennzeichnen, wie in der folgenden Tabelle beschrieben.
**Update-Hinweis-Attribute**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.
1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).
## So funktionieren Patch-Basisregeln für AlmaLinuxRHEL, und Rocky Linux
Bei AlmaLinux, Red Hat Enterprise Linux (RHEL) und Rocky Linux erfolgt die Patch-Auswahl wie folgt:
1. Auf dem verwalteten Knoten greift die YUM-Bibliothek (RHEL7) oder die DNF-Bibliothek (AlmaLinux 8 und 9, RHEL 8, 9 und 10 sowie Rocky Linux 8 und 9) auf die `updateinfo.xml` Datei für jedes konfigurierte Repository zu.
**Anmerkung**
Die `updateinfo.xml`-Datei ist möglicherweise nicht verfügbar, wenn das Repo nicht von Red Hat verwaltet wird. Falls keine `updateinfo.xml` gefunden werden, wird kein Patch angewendet.
1. Jeder Update-Hinweis in `updateinfo.xml` enthält mehrere Attribute, die die Eigenschaften der Pakete im Hinweis kennzeichnen, wie in der folgenden Tabelle beschrieben.
**Update-Hinweis-Attribute**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
1. Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des Produktschlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.
1. Pakete für das Update werden gemäß den folgenden Richtlinien ausgewählt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-linux-rules.html)
Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).
## Funktionsweise von Patch-Baseline-Regeln auf SUSE Linux Enterprise Server
Auf SLES enthält jeder Patch die folgenden Attribute, mit denen die Eigenschaften der Pakete im Patch gekennzeichnet werden:
+ **Category**: Entspricht dem Wert des **Klassifizierungs**-Schlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline. Kennzeichnet den Typ des im Update-Hinweis enthaltenen Patches.
Sie können die Liste der unterstützten Werte mithilfe des AWS CLI Befehls **[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)** oder der API-Operation **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** anzeigen. Sie können die Liste auch im Bereich **Genehmigungsregeln** der Seite **Erstellen einer Patch-Baseline** der Seite **Patch-Baseline bearbeiten** in der Systems Manager-Konsole anzeigen.
+ **Schweregrad**: Entspricht dem Wert des **Schweregrads**-Schlüsselattributs in dem [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline. Kennzeichnet den Schweregrad der Patches.
Sie können die Liste der unterstützten Werte mithilfe des AWS CLI Befehls **[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)** oder der API-Operation anzeigen**[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)**. Sie können die Liste auch im Bereich **Genehmigungsregeln** der Seite **Erstellen einer Patch-Baseline** der Seite **Patch-Baseline bearbeiten** in der Systems Manager-Konsole anzeigen.
Das Produkt des verwalteten Knotens wird durch SSM Agent bestimmt. Dieses Attribut entspricht dem Wert des **Produkt**-Schlüsselattributs im [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html)-Datentyp der Patch-Baseline.
Für jeden Patch wird die Patch-Baseline als Filter verwendet, der nur den qualifizierten Paketen die Aufnahme in das Update erlaubt. Wenn mehrere Pakete zutreffen, wird die aktuelle Version nach Anwenden der Patch-Baseline-Definition verwendet.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
## Funktionsweise von Patch-Baseline-Regeln auf Ubuntu Server
Auf Ubuntu Server bietet der Patch-Baseline-Service Filter in den Feldern *Priorität* und *Abschnitt*. Diese Felder sind normalerweise für alle Ubuntu Server-Pakete vorhanden. Um zu bestimmen, ob ein Patch von der Patch-Baseline ausgewählt wird, geht Patch Manager folgendermaßen vor:
1. Auf Ubuntu Server-Systemen wird das Äquivalent von `sudo apt-get update` ausgeführt, um die Liste der verfügbaren Pakete zu aktualisieren. Repos sind nicht konfiguriert und die Daten werden aus Repos abgerufen, die in einer `sources`-Liste konfiguriert sind.
1. Wenn eine Aktualisierung für `python3-apt` (eine Python-Bibliotheks-Schnittstelle zu `libapt`) verfügbar ist, wird es auf die neueste Version aktualisiert. (Dieses nicht sicherheitsrelevante Paket wird aktualisiert, auch wenn Sie die Option **Mit nicht sicherheitsrelevanten Updates** nicht ausgewählt haben.)
1. Als Nächstes werden die Listen [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) und [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) angewendet.
**Anmerkung**
Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.
Genehmigungsregeln sind jedoch auch davon abhängig, ob das Kästchen **Mit nicht sicherheitsrelevanten Updates** beim Erstellen oder letzten Aktualisieren einer Patch-Baseline aktiviert wurde.
Wenn nicht sicherheitsrelevante Updates ausgeschlossen werden, wird eine implizite Regel angewendet, um nur Pakete mit Upgrades in Sicherheits-Repos auszuwählen. Für jedes Paket muss die Kandidatenversion des Pakets (in der Regel die neueste Version) Teil eines Sicherheits-Repos sein. Für Ubuntu Server sind Patch-Kandidaten-Versionen in diesem Fall auf Patches beschränkt, die in den folgenden Repos enthalten sind:
+ 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`)
Wenn nicht sicherheitsrelevante Updates enthalten sind, werden auch Patches aus anderen Repositorys berücksichtigt.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
Zum Anzeigen der Inhalte der Felder *Priorität* und *Abschnitt* führen Sie den folgenden `aptitude`-Befehl aus:
**Anmerkung**
Möglicherweise müssen Sie zuerst Aptitude auf Ubuntu Server 16-Systemen installieren.
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
In der Antwort auf diesen Befehl werden alle Pakete, für die ein Upgrade durchgeführt werden kann, in diesem Format gemeldet:
```
name, priority, section, archive, candidate version
```
Weitere Informationen über Patch-Compliance-Statuswerte finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).
# Unterschiede beim Patchvorgang zwischen Linux und Windows Server
In diesem Thema werden wichtige Unterschiede zwischen Linux- und Windows Server-Patching in Patch Manager, einem Tool in AWS Systems Manager, beschrieben.
**Anmerkung**
Um von Linux verwaltete Knoten zu patchen, müssen Ihre Knoten SSM Agent der Version 2.0.834.0 oder höher ausführen.
Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter [Automatisieren von Updates für SSM Agent](ssm-agent-automatic-updates.md). Abonnieren Sie die [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten.
## Unterschied 1: Patch-Bewertung
Patch Manager verwendet auf Windows-verwalteten Knoten und Linux-verwalteten Knoten jeweils andere Prozesse, um zu ermitteln, welche Patches installiert sein sollten.
**Linux**
Bei Linux-Patches wertet Systems Manager auf *jedem* verwalteten Knoten einzeln zuerst die Patch-Baseline-Regeln und dann die Liste der genehmigten bzw. abgelehnten Patches aus. Systems Manager muss die Patches auf jedem Knoten gesondert auswerten, weil der Service die Liste der bekannten Patches und Updates von den Repositorys abruft, die auf dem verwalteten Knoten konfiguriert sind.
**Windows**
Für Windows-Patches wertet Systems Manager *direkt im Service* zuerst die Patch-Baseline-Regeln und dann die Liste der genehmigten bzw. abgelehnten Patches aus. Dies ist möglich, weil Windows-Patches aus einem einzigen Repository (Windows Update) abgerufen werden.
## Unterschied 2: `Not Applicable`-Patches
Aufgrund der großen Anzahl der verfügbaren Pakete für Linux-Betriebssysteme, meldet Systems Manager keine Details zu Patches mit dem Status *Nicht anwendbar*. Ein `Not Applicable`-Patch ist beispielsweise ein Patch für Apache-Software, wenn auf der Instance Apache nicht installiert ist. Systems Manager meldet zwar die Anzahl der `Not Applicable` Patches in der Zusammenfassung, aber wenn Sie die [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html)API für einen verwalteten Knoten aufrufen, enthalten die zurückgegebenen Daten keine Patches mit dem Status von`Not Applicable`. Dieses Verhalten unterscheidet sich von dem bei Windows.
## Unterschied 3: Unterstützung von SSM-Dokumenten
Das Systems-Manager-Dokument (SSM-Dokument) `AWS-ApplyPatchBaseline` unterstützt keine Linux-verwalteten Knoten. Um Patch-Baselines auf Linux-, macOS- und Windows Server-verwalteten Knoten anzuwenden, wird das SSM-Dokument `AWS-RunPatchBaseline` empfohlen. Weitere Informationen erhalten Sie unter [SSM-Befehlsdokumente zum Patchen verwalteter Knoten](patch-manager-ssm-documents.md) und [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
## Unterschied 4: Anwendungspatches
Der Hauptfokus von Patch Manager liegt auf dem Patchen von Betriebssystemen. Sie können mit Patch Manager jedoch auch Patches für bestimmte Anwendungen auf Ihren verwalteten Knoten anwenden.
**Linux**
Auf Linux-Betriebssystemen verwendet Patch Manager die konfigurierten Repositorys für Updates und unterscheidet dabei nicht zwischen Betriebssystem- und Anwendungs-Patches. Sie können mit Patch Manager festlegen, aus welchen Repositorys Updates abgerufen werden. Weitere Informationen finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).
**Windows**
Auf von Windows Server verwaltete Knoten können Sie für Microsoft-Anwendungen wie Microsoft Word 2016 und Microsoft Exchange Server 2016 Genehmigungsregeln sowie die Patch-Ausnahmen *Approved* (Freigegeben) und *Rejected* (Abgelehnt) anwenden. Weitere Informationen finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).
## Unterschied 5: Optionen für abgelehnte Patch-Listen in benutzerdefinierten Patch-Baselines
Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für eine Liste Abgelehnte Patches einen oder **mehrere Patches** angeben. Bei verwalteten Linux-Knoten können Sie auch festlegen, dass sie installiert werden dürfen, wenn es sich um Abhängigkeiten für einen anderen Patch handelt, der laut Baseline zulässig ist.
Windows Server unterstützt jedoch das Konzept der Patch-Abhängigkeiten nicht. Sie können einen Patch zur Liste der **abgelehnten Patches** in einer benutzerdefinierten Baseline für Windows Server hinzufügen. Das Ergebnis hängt jedoch davon ab, (1) ob der abgelehnte Patch bereits auf einem verwalteten Knoten installiert ist oder nicht, und (2) welche Option Sie für die **Aktion Abgelehnte Patches** wählen.
In der folgenden Tabelle finden Sie Einzelheiten zu den Optionen für abgelehnte Patches in Windows Server.
| Status der installation | Option: „Als Abhängigkeit zulassen“ | Option: „Blockieren“ |
| --- | --- | --- |
| Der Patch ist bereits installiert | Gemeldeter Status: INSTALLED\$1OTHER | Gemeldeter Status: INSTALLED\$1REJECTED |
| Der Patch ist noch nicht installiert | Patch übersprungen | Patch übersprungen |
Jeder von Microsoft veröffentlichte Patch für Windows Server enthält normalerweise alle Informationen, die für eine erfolgreiche Installation erforderlich sind. Gelegentlich kann jedoch ein Paket erforderlich sein, das Sie manuell installieren müssen. Patch Manager meldet keine Informationen zu diesen Voraussetzungen. Weitere Informationen finden Sie auf der Microsoft-Website unter [Problembehandlung bei Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting).
# SSM-Befehlsdokumente zum Patchen verwalteter Knoten
In diesem Thema werden die neun derzeit verfügbaren Systems-Manager-Dokumente (SSM-Dokumente) beschrieben, die Ihnen dabei helfen, Ihre verwalteten Knoten mit den neuesten sicherheitsrelevanten Updates zu patchen.
Wir empfehlen Ihnen, nur fünf dieser Dokumente für Ihre Patches zu verwenden. Zusammen bieten Ihnen diese fünf SSM-Dokumente eine breite Palette an Patch-Optionen mit AWS Systems Manager. Vier dieser Dokumente wurden später veröffentlicht als die vier alten SSM-Dokumente, die sie ersetzen und Erweiterungen oder Konsolidierungen der Funktion darstellen.
**Empfohlene SSM-Dokumente zum Patchen**
Wir empfehlen, bei Ihren Patchvorgängen die folgenden fünf SSM-Dokumente zu verwenden.
+ `AWS-ConfigureWindowsUpdate`
+ `AWS-InstallWindowsUpdates`
+ `AWS-RunPatchBaseline`
+ `AWS-RunPatchBaselineAssociation`
+ `AWS-RunPatchBaselineWithHooks`
**Ältere SSM-Dokumente zum Patchen**
Die folgenden vier älteren SSM-Dokumente sind in einigen AWS-Regionen weiterhin verfügbar, werden jedoch nicht mehr aktualisiert oder unterstützt. Es kann nicht garantiert werden, dass diese Dokumente nur in IPv6 Umgebungen und im Support funktionieren. IPv4 Es kann nicht garantiert werden, dass sie in allen Szenarien funktionieren, und sie könnten in Zukunft den Support verlieren. Es wird empfohlen, diese Dokumente nicht für Patch-Vorgänge zu verwenden.
+ `AWS-ApplyPatchBaseline`
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Anweisungen zum Einrichten von Patching-Vorgängen in einer Umgebung, die nur Support bietet, finden Sie unter IPv6. [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md)
In den folgenden Abschnitten finden Sie weitere Informationen zur Verwendung dieser SSM-Dokumente bei Ihren Patching-Vorgängen.
**Topics**
+ [Empfohlene SSM-Dokumente für das Patchen von verwalteten Knoten](#patch-manager-ssm-documents-recommended)
+ [Legacy-SSM-Dokumente für das Patchen von verwalteten Knoten](#patch-manager-ssm-documents-legacy)
+ [Bekannte Einschränkungen der SSM-Dokumente für das Patchen verwalteter Knoten](#patch-manager-ssm-documents-known-limitations)
+ [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)
+ [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md)
+ [Beispielszenario für die Verwendung des InstallOverrideList Parameters in `AWS-RunPatchBaseline` oder `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md)
+ [Verwenden des BaselineOverride Parameters](patch-manager-baselineoverride-parameter.md)
## Empfohlene SSM-Dokumente für das Patchen von verwalteten Knoten
Die folgenden fünf SSM-Dokumente werden für die Verwendung bei Ihren Patching-Operationen für Ihre verwalteten Knoten empfohlen.
**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`
Unterstützt die Konfiguration grundlegender Funktionen für Windows Update und deren Verwendung zum automatischen Installieren von Updates (oder zum Deaktivieren automatischer Updates). In allen AWS-Regionen verfügbar.
Mit diesem SSM-Dokument wird Windows Update aufgefordert, die angegebenen Updates herunterzuladen und zu installieren und die verwalteten Knoten bei Bedarf neu zu starten. Verwenden Sie dieses Dokument zusammen mit einem Tool inState Manager, um sicherzustellen AWS Systems Manager, dass Windows Update seine Konfiguration beibehält. Sie können es auch manuell ausführenRun Command, indem Sie ein Tool in verwenden AWS Systems Manager, um die Windows Update-Konfiguration zu ändern.
Die in diesem Dokument verfügbaren Parameter unterstützen die Angabe einer Kategorie von Updates, die installiert werden sollen (oder ob automatische Updates deaktiviert werden sollen), sowie die Angabe des Wochentages und der Tageszeit für die Ausführung von Patch-Vorgängen. Dieses SSM-Dokument ist besonders dann von Vorteil, wenn Sie keine strenge Kontrolle über Windows Updates benötigen und keine Compliance-Informationen sammeln müssen.
**Replaces legacy SSM documents: **
+ *Keine*
### `AWS-InstallWindowsUpdates`
Installiert Updates auf einem von Windows Server verwalteten Knoten. In allen AWS-Regionen verfügbar.
Dieses SSM-Dokument bietet grundlegende Patch-Funktion für den Fall, dass Sie entweder ein bestimmtes Update (mit Hilfe des `Include Kbs`-Parameters) installieren möchten oder Patches mit bestimmten Klassifizierungen oder Kategorien installieren möchten, aber keine Informationen zur Patch-Compliance benötigen.
**Replaces legacy SSM documents:**
+ `AWS-FindWindowsUpdates`
+ `AWS-InstallMissingWindowsUpdates`
+ `AWS-InstallSpecificWindowsUpdates`
Die drei alten Dokumente erfüllen zwar unterschiedliche Funktionen, aber Sie können die gleichen Ergebnisse erzielen, indem Sie unterschiedliche Parametereinstellungen mit dem neueren SSM-Dokument `AWS-InstallWindowsUpdates` verwenden. Diese Parametereinstellungen werden in [Legacy-SSM-Dokumente für das Patchen von verwalteten Knoten](#patch-manager-ssm-documents-legacy) beschrieben.
### `AWS-RunPatchBaseline`
Installiert Patches auf Ihren verwalteten Knoten oder scannt Knoten, um festzustellen, ob qualifizierte Patches fehlen. In allen AWS-Regionen verfügbar.
Mit `AWS-RunPatchBaseline` können Sie Patch-Genehmigungen mithilfe der Patch-Baseline steuern, die als „Standard“ für einen Betriebssystemtyp angegeben ist. Stellt Informationen zur Patch-Compliance dar, die Sie mit den Systems Manager-Compliance-Tools einsehen können. Mit diesen Tools erhalten Sie Erkenntnisse in den Zustand der Patch-Compliance Ihrer verwalteten Knoten, z. B. bei welchen Knoten Patches fehlen und was diese Patches sind. Wenn Sie `AWS-RunPatchBaseline` verwenden, werden Patch-Compliance-Informationen mit dem API-Befehl `PutInventory` aufgezeichnet. Für Linux-Betriebssysteme werden Compliance-Informationen für Patches sowohl über das in einem verwalteten Knoten konfigurierte Standard-Quell-Repository bereitgestellt, als auch von einem beliebigen alternativen Quell-Repository aus, das Sie in einer benutzerdefinierten Patch-Baseline angeben. Weitere Informationen über alternative Quell-Repositorys finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md). Weitere Informationen zu den Systems Manager-Compliance-Tools finden Sie unter [AWS Systems Manager-Compliance](systems-manager-compliance.md).
**Ersetzt alte Dokumente:**
+ `AWS-ApplyPatchBaseline`
Das Legacy-Dokument `AWS-ApplyPatchBaseline` gilt nur für von Windows Server verwaltete Knoten und bietet keinen Support für Anwendungs-Patches. Das neue Dokument `AWS-RunPatchBaseline` bietet die gleiche Unterstützung für sowohl Windows- als auch Linux-Systeme. Version 2.0.834.0 oder höher von SSM Agent ist erforderlich, um das Dokument `AWS-RunPatchBaseline` zu verwenden.
Weitere Informationen über das SSM-Dokument `AWS-RunPatchBaseline` finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
### `AWS-RunPatchBaselineAssociation`
Installiert Patches auf Ihren Instances oder scannt Instances, um festzustellen, ob qualifizierte Patches fehlen. In allen kommerziellen AWS-Regionen verfügbar.
`AWS-RunPatchBaselineAssociation` unterscheidet sich in verschiedenen wichtigen Punkten von `AWS-RunPatchBaseline`:
+ `AWS-RunPatchBaselineAssociation` ist hauptsächlich für die Verwendung mit State Manager-Zuordnungen vorgesehen, die mithilfe von Quick Setup, einem Tool in AWS Systems Manager, erstellt wurden. Insbesondere, wenn Sie den Quick Setup-Host-Management-Konfigurationstyp verwenden und die Option **Scan instances for missing patches daily** (Instances täglich auf fehlende Patches scannen) auswählen, verwendet das System `AWS-RunPatchBaselineAssociation` für diese Operation.
In den meisten Fällen sollten Sie jedoch beim Einrichten eigener Patching-Vorgänge [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) oder [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) anstelle von `AWS-RunPatchBaselineAssociation` auswählen.
Weitere Informationen finden Sie unter den folgenden Themen:
+ [AWS Systems Manager Quick Setup](systems-manager-quick-setup.md)
+ [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md)
+ `AWS-RunPatchBaselineAssociation` unterstützt die Verwendung von Tags, um zu identifizieren, welche Patch-Baseline bei der Ausführung mit einer Reihe von Zielen verwendet werden soll.
+ Für Patching-Vorgänge, die `AWS-RunPatchBaselineAssociation` verwenden, werden Patch-Compliance-Daten in Bezug auf eine bestimmte State Manager-Zuordnung gesammelt. Die Patch-Compliance-Daten, die gesammelt werden, wenn `AWS-RunPatchBaselineAssociation` ausgeführt wird, werden mit dem API-Befehl `PutComplianceItems` anstelle des Befehls `PutInventory` aufgezeichnet. Dies verhindert, dass Compliance-Daten, die nicht mit dieser bestimmten Zuordnung verknüpft sind, überschrieben werden.
Für Linux-Betriebssysteme werden Compliance-Informationen für Patches sowohl über das in einer Instance konfigurierte Standard-Quell-Repository bereitgestellt, als auch von einem beliebigen alternativen Quell-Repository aus, das Sie in einer benutzerdefinierten Patch-Baseline angeben. Weitere Informationen über alternative Quell-Repositorys finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md). Weitere Informationen zu den Systems Manager-Compliance-Tools finden Sie unter [AWS Systems Manager-Compliance](systems-manager-compliance.md).
**Ersetzt alte Dokumente:**
+ **Keine**
Weitere Informationen über das SSM-Dokument `AWS-RunPatchBaselineAssociation` finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md).
### `AWS-RunPatchBaselineWithHooks`
Installiert Patches auf Ihren verwalteten Knoten oder scannt Knoten, um festzustellen, ob qualifizierte Patches fehlen. Mit optionalen Hooks können Sie SSM-Dokumente an drei Punkten während des Patch-Zyklus ausführen. In allen kommerziellen AWS-Regionen verfügbar. Wird nicht unterstützt auf macOS.
`AWS-RunPatchBaselineWithHooks` unterscheidet sich von `AWS-RunPatchBaseline` in seiner `Install`-Operation.
`AWS-RunPatchBaselineWithHooks` unterstützt Lebenszyklus-Hooks, die während dem Patching von verwalteten Knoten an festgelegten Punkten ausgeführt werden. Da Patch-Installationen manchmal den Neustart von verwalteten Knoten erfordern, ist die Patch-Operation in zwei Ereignisse unterteilt, wobei insgesamt drei Hooks enthalten sind, die benutzerdefinierte Funktion unterstützen. Der erste Hook ist vor der `Install with NoReboot`-Operation. Der zweite Hook ist nach der `Install with NoReboot`-Operation. Der dritte Hook ist nach dem Neustart des Knoten verfügbar.
**Ersetzt alte Dokumente:**
+ **Keine**
Weitere Informationen über das SSM-Dokument `AWS-RunPatchBaselineWithHooks` finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
## Legacy-SSM-Dokumente für das Patchen von verwalteten Knoten
Die folgenden vier SSM-Dokumente sind in einigen AWS-Regionen noch verfügbar. Sie werden jedoch nicht mehr aktualisiert und möglicherweise in Zukunft nicht mehr unterstützt. Daher empfehlen wir ihre Verwendung nicht. Stattdessen verwenden Sie bitte die unter [Empfohlene SSM-Dokumente für das Patchen von verwalteten Knoten](#patch-manager-ssm-documents-recommended) beschriebenen Dokumente.
**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`
Unterstützt nur von Windows Server verwaltete Knoten, enthält jedoch, anders als der Nachfolger `AWS-RunPatchBaseline`, keinen Support für Anwendungs-Patches. Nicht verfügbar in Versionen, die nach August 2017 AWS-Regionen veröffentlicht wurden.
**Anmerkung**
Um dieses SSM-Dokument, `AWS-RunPatchBaseline`, zu ersetzen, wird die Version 2.0.834.0 oder eine neuere Version von SSM Agent benötigt. Sie können das Dokument `AWS-UpdateSSMAgent` verwenden, um Ihre verwalteten Knoten auf die neueste Version des Agenten zu aktualisieren.
### `AWS-FindWindowsUpdates`
Ersetzt durch `AWS-InstallWindowsUpdates`, die alle die gleichen Aktionen ausführen können. Nicht verfügbar bei AWS-Regionen Markteinführungen nach April 2017.
Um das gleiche Ergebnis wie bei diesem alten SSM-Dokument zu erzielen, verwenden Sie die folgende Parameterkonfiguration mit dem empfohlenen Ersatzdokument, `AWS-InstallWindowsUpdates`:
+ `Action` = `Scan`
+ `Allow Reboot` = `False`
### `AWS-InstallMissingWindowsUpdates`
Ersetzt durch `AWS-InstallWindowsUpdates`, die alle die gleichen Aktionen ausführen können. Nicht verfügbar bei Produkten, die nach April 2017 auf den AWS-Regionen Markt gebracht wurden.
Um das gleiche Ergebnis wie bei diesem alten SSM-Dokument zu erzielen, verwenden Sie die folgende Parameterkonfiguration mit dem empfohlenen Ersatzdokument, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
### `AWS-InstallSpecificWindowsUpdates`
Ersetzt durch `AWS-InstallWindowsUpdates`, die alle die gleichen Aktionen ausführen können. Nicht verfügbar bei Produkten, die nach April 2017 auf den AWS-Regionen Markt gebracht wurden.
Um das gleiche Ergebnis wie bei diesem alten SSM-Dokument zu erzielen, verwenden Sie die folgende Parameterkonfiguration mit dem empfohlenen Ersatzdokument, `AWS-InstallWindowsUpdates`:
+ `Action` = `Install`
+ `Allow Reboot` = `True`
+ `Include Kbs` = *comma-separated list of KB articles*
## Bekannte Einschränkungen der SSM-Dokumente für das Patchen verwalteter Knoten
### Unterbrechungen des externen Neustarts
Wenn das System auf dem Knoten während der Patch-Installation einen Neustart initiiert (z. B. um Firmware-Updates oder andere Funktionen anzuwenden SecureBoot), kann die Ausführung des Patch-Dokuments unterbrochen und als fehlgeschlagen markiert werden, obwohl Patches erfolgreich installiert wurden. Dies ist darauf zurückzuführen, dass der SSM-Agent den Status der Dokumentausführung bei externen Neustarts nicht beibehalten und wieder aufnehmen kann.
Um den Status der Patch-Installation nach einer fehlgeschlagenen Ausführung zu überprüfen, führen Sie einen `Scan` Patch-Vorgang aus und überprüfen Sie anschließend die Patch-Kompatibilitätsdaten in Patch Manager, um den aktuellen Kompatibilitätsstatus zu beurteilen.
# SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`
AWS Systems Manager unterstützt`AWS-RunPatchBaseline`, ein Systems Manager Manager-Dokument (SSM-Dokument) fürPatch Manager, ein Tool in AWS Systems Manager. Dieses SSM-Dokument führt Patch-Operationen auf verwaltete Knoten sowohl für sicherheitsrelevante als auch für andere Arten von Updates durch. Wenn das Dokument ausgeführt wird, verwendet es die Patch-Baseline, die der „Standard“ für einen Betriebssystemtyp ist, wenn keine Patch-Gruppe angegeben ist. Andernfalls wird die Patch-Baseline verwendet, die der Patch-Gruppe zugeordnet ist. Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md).
Sie können das Dokument `AWS-RunPatchBaseline` verwenden, um Patches sowohl für Betriebssysteme als auch für Anwendungen durchzuführen. (Unter Windows Server ist der Anwendungssupport auf Updates für Microsoft-Anwendungen beschränkt.)
Dieses Dokument unterstützt von Linux, macOS und Windows Server verwaltete Knoten. Das Dokument führt die entsprechenden Aktionen für jede Plattform durch.
**Anmerkung**
Patch Manager unterstützt auch das veraltete SSM-Dokument `AWS-ApplyPatchBaseline`. Dieses Dokument unterstützt jedoch nur das Patchen von Windows-verwalteten Knoten. Wir empfehlen Ihnen, stattdessen `AWS-RunPatchBaseline` zu verwenden, da es das Patchen auf Linux-, macOS- und Windows Server-verwaltete Knoten unterstützt. Version 2.0.834.0 oder höher von SSM Agent ist erforderlich, um das Dokument `AWS-RunPatchBaseline` zu verwenden.
------
#### [ Windows Server ]
Auf Windows Server verwalteten Knoten lädt das `AWS-RunPatchBaseline` Dokument ein PowerShell Modul herunter und ruft es auf, das wiederum einen Snapshot der Patch-Baseline herunterlädt, die für den verwalteten Knoten gilt. Dieser Patch-Baseline-Snapshot enthält eine Liste genehmigter Patches, die kompiliert werden, indem die Patch-Baseline auf einem WSUS-Server (Windows Server Update Services) abgefragt wird. Diese Liste wird an die Windows Update-API weitergeleitet, die das Herunterladen und Installieren des genehmigten Patches entsprechend steuert.
------
#### [ Linux ]
Auf Linux-verwalteten Knoten ruft das Dokument `AWS-RunPatchBaseline` ein Python-Modul auf, das wiederum einen entsprechenden Snapshot der Patch-Baseline für den verwalteten Knoten herunterlädt. Dieser Patch-Baseline-Snapshot verwendet die definierten Regeln und Listen der genehmigten und gesperrten Patches, um den entsprechenden Paketmanager für jeden Knoten-Typ anzutreiben:
+ Von Amazon Linux 2, Oracle Linux und RHEL 7 verwaltete Knoten verwenden YUM. Für YUM-Operationen ist eine `Python 2.6` oder eine neuere unterstützte Version Patch Manager erforderlich (2.6 — 3.12). Amazon Linux 2023 verwendet DNF. Für DNF-Operationen Patch Manager ist eine unterstützte Version von `Python 2` oder `Python 3` (2.6 - 3.12) erforderlich.
+ Von RHEL 8 verwaltete Knoten verwenden DNF. Für DNF-Operationen Patch Manager ist eine unterstützte Version von `Python 2` or `Python 3` (2.6 - 3.12) erforderlich. (Keine der beiden Versionen ist standardmäßig auf RHEL 8 installiert. Sie müssen die eine oder andere Version manuell installieren.)
+ Debian Server, und Ubuntu Server Instanzen verwenden APT. Für APT-Operationen Patch Manager ist eine unterstützte Version von `Python 3` (3.0 - 3.12) erforderlich.
------
#### [ macOS ]
Auf macOS-verwalteten Knoten ruft das Dokument `AWS-RunPatchBaseline` ein Python-Modul auf, das wiederum einen entsprechenden Snapshot der Patch-Baseline für den verwalteten Knoten herunterlädt. Als Nächstes ruft ein Python-Unterprozess die AWS Command Line Interface (AWS CLI) auf dem Knoten auf, um die Installations- und Aktualisierungsinformationen für die angegebenen Paketmanager abzurufen und den entsprechenden Paketmanager für jedes Aktualisierungspaket zu steuern.
------
Jeder Snapshot ist spezifisch für eine Patchgruppe AWS-Konto, ein Betriebssystem und eine Snapshot-ID. Der Snapshot wird über eine vorsignierte Amazon Simple Storage Service (Amazon S3)-URL bereitgestellt, die 24 Stunden nach Erstellung des Snapshots abläuft. Wenn Sie jedoch denselben Snapshot-Inhalt auf andere verwaltete Knoten anwenden möchten, können Sie nach Ablauf der URL bis zu drei Tage nach Erstellung des Snapshots eine neue vorsignierte Amazon-S3-URL generieren. Verwenden Sie dazu den Befehl [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).
Nachdem alle genehmigten und zutreffenden Updates installiert und je nach Bedarf Neustarts durchgeführt wurden, werden Patch-Compliance-Informationen auf einem verwalteten Knoten generiert und wieder an Patch Manager gemeldet.
**Anmerkung**
Wenn der Parameter `RebootOption` im Dokument `AWS-RunPatchBaseline` auf `NoReboot` gesetzt ist, wird der verwaltete Knoten nach dem Ausführen von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
Weitere Informationen zum Anzeigen von Patch-Compliance-Daten finden Sie unter [Info zu Patch Compliance](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaseline`-Parameter
`AWS-RunPatchBaseline` unterstützt sechs Parameter. Der Parameter `Operation` muss angegeben werden. Die Parameter `InstallOverrideList`, `BaselineOverride` und `RebootOption` sind optional. `Snapshot-ID` ist technisch optional, wir empfehlen allerdings, dass Sie einen benutzerdefinierten Wert dafür angeben, wenn Sie `AWS-RunPatchBaseline` außerhalb von einem Wartungsfenster ausführen, und Patch Manager den Wert benutzerdefinierten automatisch angeben lassen, wenn das Dokument als Teil eines Wartungsfenstervorgangs ausgeführt wird.
**Topics**
+ [Parametername: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Parametername: `AssociationId`](#patch-manager-aws-runpatchbaseline-parameters-association-id)
+ [Parametername: `Snapshot ID`](#patch-manager-aws-runpatchbaseline-parameters-snapshot-id)
+ [Parametername: `InstallOverrideList`](#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)
+ [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption)
+ [Parametername: `BaselineOverride`](#patch-manager-aws-runpatchbaseline-parameters-baselineoverride)
+ [Parametername: `StepTimeoutSeconds`](#patch-manager-aws-runpatchbaseline-parameters-steptimeoutseconds)
### Parametername: `Operation`
**Nutzung**: erforderlich.
**Optionen**: `Scan` \$1 `Install`.
Scan
Wenn Sie die Option `Scan` wählen, bestimmt `AWS-RunPatchBaseline` den Patch-Compliance-Status des verwalteten Knoten und meldet diese Informationen an Patch Manager. `Scan` fordert nicht zum Installieren von Updates oder zum Neustarten von verwalteten Knoten auf. Stattdessen erkennt die Operation, wo für den Knoten genehmigte und geeignete Updates fehlen.
Installieren
Bei Auswahl der Option `Install` versucht `AWS-RunPatchBaseline`, die genehmigten und geeigneten Updates zu installieren, die auf dem verwalteten Knoten fehlen. Patch-Compliance-Informationen, die als Teil eines `Install`-Vorgangs generiert wurden, enthalten keine fehlenden Updates, melden allerdings möglicherweise Updates im Fehlerzustand, wenn die Installation des Updates aus einem beliebigen Grund nicht erfolgreich war. Immer wenn ein Update auf einem verwalteten Knoten installiert wird, wird der Knoten neu gestartet, um sicherzustellen, dass das Update installiert und aktiviert ist. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaseline` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaseline-parameters-norebootoption).)
Wenn ein von den Basisregeln festgelegter Patch installiert wird, *bevor* der Patch Manager den verwalteten Knoten aktualisiert, wird das System möglicherweise nicht wie erwartet neu gestartet. Dies kann passieren, wenn ein Patch manuell von einem Benutzer oder automatisch von einem anderen Programm, z. B. dem `unattended-upgrades`-Paket auf Ubuntu Server, installiert wird.
### Parametername: `AssociationId`
**Nutzung**: optional.
`AssociationId` ist die ID einer Zuordnung in State Manager, einem Tool in AWS Systems Manager. Es wird von Patch Manager verwendet, um einer angegebenen Zuordnung Compliance-Daten hinzuzufügen. Diese Zuordnung bezieht sich auf einen Patching-Vorgang, der [in einer Patch-Richtlinie in Quick Setup eingerichtet](quick-setup-patch-manager.md) ist.
**Anmerkung**
Wenn mit der `AWS-RunPatchBaseline` ein `AssociationId`-Wert zusammen mit einer Baseline-Überschreibung der Patch-Richtlinie bereitgestellt wird, wird das Patchen als eine `PatchPolicy`-Operation durchgeführt und der `ExecutionType`-Wert, der in `AWS:ComplianceItem` gemeldet wird, ist ebenfalls `PatchPolicy`. Wenn kein `AssociationId`-Wert angegeben wird, wird das Patchen als eine `Command`-Operation durchgeführt, und der `ExecutionType`-Wert, der in `AWS:ComplianceItem` übermittelt wird, ist ebenfalls `Command`.
Wenn Sie noch keine Zuordnung erstellt haben, die Sie verwenden möchten, können Sie eine erstellen, indem Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) ausführen.
### Parametername: `Snapshot ID`
**Nutzung**: optional.
`Snapshot ID` ist eine eindeutige ID (GUID), die von Patch Manager verwendet wird, um sicherzustellen, dass ein Satz von verwalteten Knoten, für die in einer einzelnen Operation Patches durchgeführt werden, den genau gleichen Satz genehmigter Patches aufweist. Auch wenn der Parameter als optional definiert ist, hängen unsere Empfehlungen für bewährte Methoden davon ab, ob Sie `AWS-RunPatchBaseline` in einem Wartungsfenster, wie in der folgenden Tabelle beschrieben, ausführen.
**Bewährte Methoden für `AWS-RunPatchBaseline`**
| Mode | Bewährte Methode | Details |
| --- | --- | --- |
| Ausführen von AWS-RunPatchBaseline innerhalb eines Wartungsfensters | Geben Sie keine Snapshot ID an. Patch Manager wird sie für Sie bereitstellen. | Falls Sie ein Wartungsfenster zum Ausführen von `AWS-RunPatchBaseline` verwenden, dürfen Sie Ihre eigene generierte Snapshot ID nicht angeben. In diesem Szenario stellt Systems Manager einen GUID-Wert auf Grundlage der Wartungsfensterausführungs-ID bereit. Auf diese Weise wird sichergestellt, dass eine richtige ID für alle Aufrufe von `AWS-RunPatchBaseline` in diesem Wartungsfenster verwendet wird. Wenn Sie einen Wert in diesem Szenario angeben, beachten Sie, dass der Snapshot der Patch-Baseline möglicherweise nicht länger als drei Tagen erhalten bleibt. Danach wird ein neuer Snapshot erstellt, auch wenn Sie dieselbe ID angeben, nachdem der Snapshot abgelaufen ist. |
| Ausführen von AWS-RunPatchBaseline außerhalb eines Wartungsfensters | Generieren Sie einen benutzerdefinierten GUID-Wert für die Snapshot-ID und geben Sie ihn an.¹ | Wenn Sie kein Wartungsfenster zum Ausführen von `AWS-RunPatchBaseline` verwenden, empfehlen wir, dass Sie eine eindeutige Snapshot-ID für jede Patch-Baseline generieren und angeben, insbesondere wenn Sie das Dokument `AWS-RunPatchBaseline` auf mehreren verwaltete Knoten in derselben Operation ausführen. Wenn Sie keine ID in diesem Szenario angeben, generiert Systems Manager eine andere Snapshot-ID für jeden verwalteten Knoten, an den der Befehl gesendet wird. Dies kann zu unterschiedlichen Sätzen von Patches führen, die auf den jeweiligen verwalteten Knoten angegeben sind. Angenommen, Sie führen das Dokument `AWS-RunPatchBaseline` direkt über Run Command aus, ein Tool in AWS Systems Manager, und richten es auf eine Gruppe von 50 verwalteten Knoten aus. Das Angeben einer benutzerdefinierten Snapshot-ID führt zur Erstellung eines einzelnen Baseline-Snapshots, der verwendet wird, um alle Knoten zu bewerten und zu patchen. Dadurch wird gewährleistet, dass sie letztendlich einen konsistenten Zustand aufweisen. |
| ¹ Sie können jedes beliebige Tool zum Generieren eines Werts für den Snapshot-ID-Parameter verwenden, das eine GUID generieren kann. In können Sie PowerShell beispielsweise das `New-Guid` Cmdlet verwenden, um eine GUID im Format von zu generieren. `12345699-9405-4f69-bc5e-9315aEXAMPLE` |
### Parametername: `InstallOverrideList`
**Nutzung**: optional.
Mit `InstallOverrideList` können Sie eine https-URL oder eine Amazon S3-PathStyle-URL zu einer Liste mit zu installierenden Patches angeben. Diese im YAML-Format geführte Patch-Installationsliste überschreibt die von der Standard-Patch-Baseline angegebenen Patches. Dies bietet Ihnen eine detalliertere Kontrolle darüber, welche Patches auf Ihren verwalteten Knoten installiert sind.
**Wichtig**
Der `InstallOverrideList`-Dateiname darf die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).
Das Verhalten des Patch-Vorgangs bei Verwendung des `InstallOverrideList`-Parameters unterscheidet sich zwischen Linux- und macOS-verwalteten Knoten und Windows Server-verwalteten Knoten. Unter Linux und macOS versucht Patch Manager, Patches aus der Patchliste `InstallOverrideList` anzuwenden, die in einem auf dem Knoten aktivierten Repository vorhanden sind, unabhängig davon, ob die Patches den Patch-Baseline-Regeln entsprechen oder nicht. Auf Windows Server-Knoten werden Patches in der `InstallOverrideList`-Patch-Liste jedoch *nur* angewendet, wenn sie auch den Patch-Baseline-Regeln entsprechen.
Beachten Sie, dass Compliance-Berichte Patch-Status entsprechend den Angaben in der Patch-Baseline wiedergeben, nicht entsprechend Ihren Angaben in einer `InstallOverrideList`-Liste von Patches. Mit anderen Worten: Scan-Operationen ignorieren den Parameter `InstallOverrideList`. Auf diese Weise wird sichergestellt, dass Compliance-Berichte den Patch-Status konsistent entsprechend der Richtlinie wiedergeben und nicht danach, was für eine bestimmte Patching-Operation genehmigt wurde.
**Anmerkung**
Wenn Sie einen Knoten patchen, der nur verwendet, stellen Sie sicher IPv6, dass die angegebene URL vom Knoten aus erreichbar ist. Wenn die SSM Agent Konfigurationsoption auf gesetzt `UseDualStackEndpoint` ist`true`, wird ein Dual-Stack-S3-Client verwendet, wenn eine S3-URL bereitgestellt wird. Weitere Informationen [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md) zur Konfiguration des Agenten für die Verwendung von Dualstack finden Sie unter.
Eine Beschreibung, wie Sie den Parameter `InstallOverrideList` verwenden können, um verschiedene Patch-Typen in verschiedenen Wartungsfenster-Zeitplänen auf eine Zielgruppe anzuwenden und gleichzeitig eine einzelne Patch-Baseline zu verwenden, finden Sie unter [Beispielszenario für die Verwendung des InstallOverrideList Parameters in `AWS-RunPatchBaseline` oder `AWS-RunPatchBaselineAssociation`](patch-manager-override-lists.md).
**Gültige URL-Formate**
**Anmerkung**
Wenn Ihre Datei in einem öffentlich zugänglichen Bucket gespeichert ist, können Sie entweder ein HTTPS-URL-Format oder eine URL im Amazon S3-Pfadstil angeben. Wenn Ihre Datei in einem privaten Bucket gespeichert ist, müssen Sie eine URL im Amazon S3-Pfadstil angeben.
+ **HTTPS-URL-Format**:
```
https://s3.aws-api-domain/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **URL im Amazon S3-Pfadstil**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Gültige YAML-Inhaltsformate**
Die Formate, die Sie verwenden, um Patches in Ihrer Liste anzugeben, hängen von dem Betriebssystem Ihres verwalteten Knoten ab. Das allgemeine Format lautet jedoch folgendermaßen:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Sie können zwar zusätzliche Felder in der YAML-Datei bereitstellen, diese werden jedoch während der Patch-Operationen ignoriert.
Darüber hinaus empfehlen wir zu überprüfen, ob das Format Ihrer YAML-Datei gültig ist, bevor Sie die Liste in Ihrem S3-Bucket hinzufügen oder aktualisieren. Weitere Informationen zum YAML-Format finden Sie unter [yaml.org](http://www.yaml.org). Für Validierungstool-Optionen suchen Sie im Internet nach „yaml format validators“ durch.
------
#### [ Linux ]
**id**
Das Feld **id** ist ein Pflichtfeld. Verwenden Sie es, um Patches mit Paketnamen und Architektur anzugeben. Beispiel: `'dhclient.x86_64'`. Sie können Platzhalter in der ID verwenden, um mehrere Pakete anzugeben. Zum Beispiel `'dhcp*'` und `'dhcp*1.*'`.
**Title**
Das Feld **Titel** ist optional, es bietet jedoch auf Linux-Systemen zusätzliche Filterfunktionen. Wenn Sie **Titel** verwenden, sollte er die Versionsinformationen des Pakets in einem der folgenden Formate enthalten:
YUM/SUSE Linux Enterprise Server (SLES):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Für Linux-Patch-Titel können Sie einen oder mehrere Platzhalter in beliebigen Positionen verwenden, um die Anzahl der Paketzuordnungen zu erhöhen. Beispiel: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Zum Beispiel:
+ apt-Paketversion 1.2.25 ist derzeit auf Ihrem verwalteten Knoten installiert, aber Version 1.2.27 ist jetzt verfügbar.
+ Fügen Sie die apt.amd64-Version 1.2.27 der Liste hinzu. Sie ist abhängig von apt utils.amd64 Version 1.2.27, aber apt-utils.amd64 Version 1.2.25 ist in der Liste angegeben.
In diesem Fall wird die Installation der APT-Version 1.2.27 blockiert und als „Fehlgeschlagen-“ gemeldet. NonCompliant
------
#### [ Windows Server ]
**id**
Das Feld **id** ist ein Pflichtfeld. Verwenden Sie es, um Patches mithilfe von Microsoft Knowledge Base IDs (z. B. KB2736693) und Microsoft Security Bulletin IDs (z. B. MS17 -023) anzugeben.
Alle anderen Felder, die Sie in einer Patch-Liste für Windows bereitstellen möchten, sind optional und dienen nur zu Ihrer eigenen Information. Sie können zusätzlichen Felder verwenden, wie z. B. **Titel**, **Klassifizierung**, **Schweregrad** oder andere Angaben für detailliertere Informationen über die angegebenen Patches.
------
#### [ macOS ]
**id**
Das Feld **id** ist ein Pflichtfeld. Der Wert für das Feld **id** kann entweder mit einem `{package-name}.{package-version}`-Format oder einem \$1package\$1name\$1-Format bereitgestellt werden.
------
**Patch-Beispiellisten**
+ **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'
```
### Parametername: `RebootOption`
**Nutzung**: optional.
**Optionen**: `RebootIfNeeded` \$1 `NoReboot`
**Standardwert**: `RebootIfNeeded`
**Warnung**
Die Standardoption ist `RebootIfNeeded`. Stellen Sie sicher, dass Sie die richtige Option für Ihren Anwendungsfall auswählen. Wenn Ihre verwalteten Knoten beispielsweise sofort neu gestartet werden müssen, um einen Konfigurationsprozess abzuschließen, wählen Sie `RebootIfNeeded` aus. Oder wenn Sie die Verfügbarkeit von verwalteten Knoten bis zu einer geplanten Neustartzeit beibehalten müssen, wählen Sie `NoReboot` aus.
**Wichtig**
Wir empfehlen nicht, Cluster-Instances in Amazon EMR (früher Amazon Elastic MapReduce genannt) zum Patchen zu verwendenPatch Manager. Wählen Sie insbesondere nicht die Option `RebootIfNeeded` für den Parameter `RebootOption` aus. (Diese Option ist in den SSM-Befehlsdokumenten für das Patchen von `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` und `AWS-RunPatchBaselineWithHooks` verfügbar.)
Die zugrunde liegenden Befehle für das Patchen mithilfe von Patch Manager verwenden `yum`- und `dnf`-Befehle. Daher führen die Operationen aufgrund der Art und Weise, wie Pakete installiert werden, zu Inkompatibilitäten. Informationen zu den bevorzugten Methoden für die Aktualisierung von Software auf Amazon-EMR-Clustern finden Sie unter [Verwenden des Standard-AMI für Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) im *Amazon EMR Management Guide*.
RebootIfNeeded
Wenn Sie die Option `RebootIfNeeded` auswählen, wird der verwaltete Knoten in einem der folgenden Fälle neu gestartet:
+ Patch Manager ist auf einem oder mehreren Patches installiert.
Patch Manager wertet nicht aus, ob ein Neustart vom Patch *erfordert* wird. Das System wird neu gestartet, auch wenn der Patch keinen Neustart erfordert.
+ Patch Manager erkennt ein oder mehrere Patches mit dem Status `INSTALLED_PENDING_REBOOT` während der `Install`-Operation.
Der `INSTALLED_PENDING_REBOOT`-Status kann bedeuten, dass die Option `NoReboot` ausgewählt wurde, als der `Install`-Vorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von Patch Manager seit dem letzten Neustart des verwalteten Knotens installiert wurde.
Durch den Neustart von verwalteten Knoten wird in diesen beiden Fällen sichergestellt, dass aktualisierte Pakete aus dem Speicher gelöscht werden und das Patch- und Neustartverhalten über alle Betriebssysteme hinweg konsistent bleibt.
NoReboot
Wenn Sie die Option `NoReboot` auswählen, startet Patch Manager einen verwalteten Knoten nicht neu, selbst wenn über ihn während der `Install`-Operation Patches installiert wurden. Diese Option ist nützlich, wenn Sie wissen, dass für Ihre verwalteten Knoten nach dem Anwenden von Patches kein Neustart erforderlich ist oder Anwendungen bzw. Prozesse auf einem Knoten ausgeführt werden, die nicht durch einen Neustart beim Patchen unterbrochen werden sollten. Sie ist auch nützlich, wenn Sie mehr Kontrolle über das Timing von Neustarts von verwalteten Knoten wünschen, z. B. durch die Verwendung eines Wartungsfensters.
Wenn Sie die Option `NoReboot` auswählen und ein Patch installiert ist, wird dem Patch der Status `InstalledPendingReboot` zugewiesen. Der verwaltete Knoten selbst wird jedoch als `Non-Compliant` gekennzeichnet. Nach einem Neustart und Ausführung einer `Scan`-Operation wird der Status des verwalteten Knoten auf `Compliant` aktualisiert.
Die Option `NoReboot` verhindert nur Neustarts auf Betriebssystemebene. Im Rahmen des Patch-Vorgangs können weiterhin Neustarts auf Service-Ebene erfolgen. Wenn Docker beispielsweise aktualisiert wird, können abhängige Services wie Amazon Elastic Container Service automatisch neu gestartet werden, auch wenn `NoReboot` aktiviert ist. Wenn Sie wichtige Services haben, die nicht unterbrochen werden dürfen, sollten Sie zusätzliche Maßnahmen in Betracht ziehen. Sie könnten z. B. Instances vorübergehend außer Betrieb nehmen oder Patches während Wartungsfenstern planen.
**Datei zum Nachverfolgen der Patch-Installation**: Um die Patch-Installation nachzuverfolgen, insbesondere von Patches, die seit dem letzten Neustart des Systems installiert wurden, erstellt Systems Manager eine Datei auf dem verwalteten Knoten.
**Wichtig**
Löschen oder ändern Sie die Tracking-Datei nicht. Wenn diese Datei gelöscht oder beschädigt wird, ist der Patch-Compliance-Bericht für den verwalteten Knoten ungenau. Starten Sie in diesem Fall den Knoten neu und führen Sie eine Patch-Scan-Operation aus, um die Datei wiederherzustellen.
Diese Tracking-Datei wird an den folgenden Speicherorten auf Ihren verwalteten Knoten gespeichert:
+ Linux-Betriebssysteme:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server-Betriebssystem:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Parametername: `BaselineOverride`
**Nutzung**: optional.
Sie können Patching-Voreinstellungen zur Laufzeit mit dem `BaselineOverride`-Parameter definieren. Diese Baseline-Überschreibung wird als JSON-Objekt in einem S3-Bucket beibehalten. Sie stellt sicher, dass Patchvorgänge die bereitgestellten Baselines verwenden, die dem Host-Betriebssystem entsprechen, anstatt die Regeln aus der Standard-Patch-Baseline anzuwenden
**Wichtig**
Der `BaselineOverride`-Dateiname darf die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).
Weitere Informationen zur Verwendung des Parameters `BaselineOverride` finden Sie unter [Verwenden des BaselineOverride Parameters](patch-manager-baselineoverride-parameter.md).
### Parametername: `StepTimeoutSeconds`
**Nutzung**: erforderlich.
Die Zeit in Sekunden – zwischen 1 und 36 000 Sekunden (10 Stunden) –, die ein Befehl in Anspruch nehmen darf, bevor er als fehlgeschlagen betrachtet wird.
# SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`
Wie das `AWS-RunPatchBaseline`-Dokument führt auch `AWS-RunPatchBaselineAssociation` Patching-Operationen auf Instances für sicherheitsrelevante und andere Arten von Updates aus. Sie können das Dokument `AWS-RunPatchBaselineAssociation` auch verwenden, um Patches sowohl für Betriebssysteme als auch für Anwendungen durchzuführen. (Unter Windows Server ist der Anwendungssupport auf Updates für Microsoft-Anwendungen beschränkt.)
Dieses Dokument unterstützt Amazon Elastic Compute Cloud (Amazon EC2)-Instances für Linux, macOS und Windows Server. Nicht-EC2-Knoten in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) werden nicht unterstützt. Das Dokument führt die entsprechenden Aktionen für jede Plattform durch und ruft ein Python-Modul auf Linux und macOS Instanzen und ein PowerShell Modul auf Windows-Instanzen auf.
`AWS-RunPatchBaselineAssociation` unterscheidet sich jedoch auf folgende Weise von `AWS-RunPatchBaseline`:
+ `AWS-RunPatchBaselineAssociation` ist hauptsächlich für die Verwendung mit State Manager-Zuordnungen vorgesehen, die mithilfe von [Quick Setup](systems-manager-quick-setup.md), einem Tool in AWS Systems Manager, erstellt wurden. Insbesondere, wenn Sie den Quick Setup-Host-Management-Konfigurationstyp verwenden und die Option **Scan instances for missing patches daily** (Instances täglich auf fehlende Patches scannen) auswählen, verwendet das System `AWS-RunPatchBaselineAssociation` für diese Operation.
In den meisten Fällen sollten Sie jedoch beim Einrichten eigener Patching-Vorgänge [`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) oder [`AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md) anstelle von `AWS-RunPatchBaselineAssociation` auswählen.
+ Wenn Sie das `AWS-RunPatchBaselineAssociation`-Dokument verwenden, können Sie ein Tag-Schlüssel-Paar im `BaselineTags`-Parameterfeld des Dokuments angeben. Wenn eine benutzerdefinierte Patch-Baseline in Ihrem AWS-Konto System diese Tags verwendetPatch Manager, verwendet ein Tool in diese markierte Baseline AWS Systems Manager, wenn es auf den Ziel-Instances ausgeführt wird, und nicht die aktuell angegebene „Standard“ -Patch-Baseline für den Betriebssystemtyp.
**Anmerkung**
Wenn Sie `AWS-RunPatchBaselineAssociation` in anderen Patching-Operationen als den mithilfe von Quick Setup eingerichteten verwenden und Sie den optionalen `BaselineTags`-Parameter verwenden möchten, müssen Sie einige zusätzliche Berechtigungen für das [Instance-Profil](setup-instance-permissions.md) für Amazon Elastic Compute Cloud (Amazon EC2)-Instances bereitstellen. Weitere Informationen finden Sie unter [Parametername: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags).
Die beiden folgenden Formate sind gültig für Ihre `BaselineTags`-Parameter:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Wichtig**
Tag-Schlüssel und -Werte dürfen die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).
+ Wenn `AWS-RunPatchBaselineAssociation` ausgeführt wird, werden die Patch-Compliance-Daten, die es sammelt, mit dem API-Befehl `PutComplianceItems` anstelle des Befehls `PutInventory`, der von `AWS-RunPatchBaseline` verwendet wird, aufgezeichnet. Dieser Unterschied bedeutet, dass die Patch-Compliance-Informationen gemäß einer bestimmten *Zuordnung* gespeichert und gemeldet werden. Patch-Compliance-Daten, die außerhalb dieser Zuordnung generiert wurden, werden nicht überschrieben.
+ Die Patch-Compliance-Informationen, die nach der Ausführung von `AWS-RunPatchBaselineAssociation` gemeldet werden, geben an, ob eine Instance konform ist oder nicht. Es enthält keine Details auf Patch-Ebene, wie die Ausgabe des folgenden AWS Command Line Interface (AWS CLI) -Befehls zeigt. Der Befehl filtert auf `Association` als Compliance-Typ:
```
aws ssm list-compliance-items \
--resource-ids "i-02573cafcfEXAMPLE" \
--resource-types "ManagedInstance" \
--filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
--region us-east-2
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
]
}
```
Wenn ein Tag-Schlüssel-Paar-Wert als Parameter für das `AWS-RunPatchBaselineAssociation`-Dokument angegeben wurde, sucht Patch Manager nach einer benutzerdefinierten Patch-Baseline, die mit dem Betriebssystemtyp übereinstimmt und mit demselben Tag-Schlüssel-Paar gekennzeichnet wurde. Diese Suche ist nicht auf die aktuell angegebene Standard-Patch-Baseline oder die Baseline beschränkt, die einer Patch-Gruppe zugewiesen ist. Wenn keine Baseline mit den angegebenen Tags gefunden wird, sucht Patch Manager als Nächstes nach einer Patch-Gruppe, wenn eine in dem Befehl angegeben wurde, der `AWS-RunPatchBaselineAssociation` ausführt. Wenn keine Patch-Gruppe übereinstimmt, wird Patch Manager auf die aktuelle Standard-Patch-Baselines für das Betriebssystemkonto zurückgesetzt.
Wenn mehr als eine Patch-Baseline mit den Tags gefunden wird, die im `AWS-RunPatchBaselineAssociation`-Dokument angegeben sind, gibt Patch Manager eine Fehlermeldung zurück, die angibt, dass nur eine Patch-Baseline mit diesem Schlüssel-Wert-Paar gekennzeichnet werden kann, damit der Vorgang fortgesetzt wird.
**Anmerkung**
Auf Linux-Knoten wird der entsprechende Paketmanager für jeden Knotentyp verwendet, um Pakete zu installieren:
Amazon-Linux-2-, Oracle Linux- und RHEL-Instances verwenden YUM. Für YUM-Operationen ist eine `Python 2.6` oder eine Patch Manager neuere unterstützte Version (2.6 - 3.12) erforderlich. Amazon Linux 2023 verwendet DNF. Für DNF-Vorgänge erfordert Patch Manager eine unterstützte Version von `Python 2` oder `Python 3` (2.6–3.12).
Debian Serverund Ubuntu Server Instanzen verwenden APT. Für APT-Operationen Patch Manager ist eine unterstützte Version von `Python 3` (3.0 - 3.12) erforderlich.
Nachdem der Scan abgeschlossen wurde oder alle genehmigten und zutreffenden Updates installiert und je nach Bedarf Neustarts durchgeführt wurden, werden Patch-Compliance-Informationen auf einer Instance generiert und wieder an den Patchmanager-Service gemeldet.
**Anmerkung**
Wenn der Parameter `RebootOption` im Dokument `AWS-RunPatchBaselineAssociation` auf `NoReboot` gesetzt ist, wird die Instance nach dem Ausführen von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).
Weitere Informationen zum Anzeigen von Patch-Compliance-Daten finden Sie unter [Info zu Patch Compliance](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaselineAssociation`-Parameter
`AWS-RunPatchBaselineAssociation` unterstützt fünf Parameter. Die Parameter `Operation` und `AssociationId` müssen angegeben werden. Die Parameter `InstallOverrideList`, `RebootOption` und `BaselineTags` sind optional.
**Topics**
+ [Parametername: `Operation`](#patch-manager-aws-runpatchbaselineassociation-parameters-operation)
+ [Parametername: `BaselineTags`](#patch-manager-aws-runpatchbaselineassociation-parameters-baselinetags)
+ [Parametername: `AssociationId`](#patch-manager-aws-runpatchbaselineassociation-parameters-association-id)
+ [Parametername: `InstallOverrideList`](#patch-manager-aws-runpatchbaselineassociation-parameters-installoverridelist)
+ [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption)
### Parametername: `Operation`
**Nutzung**: erforderlich.
**Optionen**: `Scan` \$1 `Install`.
Scan
Wenn Sie die Option `Scan` wählen, bestimmt `AWS-RunPatchBaselineAssociation` den Patch-Compliance-Status der Instance und meldet diese Informationen an Patch Manager. `Scan` fordert nicht zum Installieren von Updates oder zum Neustarten von Instances auf. Stattdessen erkennt der Vorgang, wo für die Instance genehmigte und geeignete Updates fehlen.
Installieren
Bei Auswahl der Option `Install` versucht `AWS-RunPatchBaselineAssociation`, die genehmigten und geeigneten Updates zu installieren, die auf der Instance fehlen. Patch-Compliance-Informationen, die als Teil eines `Install`-Vorgangs generiert wurden, enthalten keine fehlenden Updates, melden allerdings möglicherweise Updates im Fehlerzustand, wenn die Installation des Updates aus einem beliebigen Grund nicht erfolgreich war. Immer wenn ein Update auf einer Instance installiert wird, wird die Instance neu gestartet, um sicherzustellen, dass es installiert und aktiviert ist. (Ausnahme: Wenn der `RebootOption`-Parameter im `AWS-RunPatchBaselineAssociation`-Dokument auf `NoReboot` gesetzt ist, wird die Instance nach der Ausführung von Patch Manager nicht neugestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselineassociation-parameters-norebootoption).)
Wenn ein von den Basisregeln festgelegter Patch installiert wird, *bevor* der Patch Manager die Instance aktualisiert, wird das System möglicherweise nicht wie erwartet neu gestartet. Dies kann passieren, wenn ein Patch manuell von einem Benutzer oder automatisch von einem anderen Programm, z. B. dem `unattended-upgrades`-Paket auf Ubuntu Server, installiert wird.
### Parametername: `BaselineTags`
**Nutzung**: optional.
`BaselineTags` ist ein eindeutiges Tag-Schlüssel-Wert-Paar, das Sie auswählen und einer individuellen benutzerdefinierten Patch-Baseline zuweisen. Sie können einen oder mehrere Werte für diesen Parameter angeben. Beider der folgenden Formate sind gültig:
`Key=tag-key,Values=tag-value`
`Key=tag-key,Values=tag-value1,tag-value2,tag-value3`
**Wichtig**
Tag-Schlüssel und -Werte dürfen die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).
Der `BaselineTags`-Wert wird von Patch Manager verwendet, um sicherzustellen, dass eine Gruppe von Instances, für die in einem Vorgang Patches durchgeführt werden, den genau gleichen Satz genehmigter Patches aufweist. Wenn der Patching-Vorgang ausgeführt wird, überprüft Patch Manager, ob eine Patch-Baseline für den Betriebssystemtyp mit demselben Schlüssel-Wert-Paar versehen ist, das Sie für `BaselineTags` angeben. Wenn eine Übereinstimmung vorliegt, wird diese benutzerdefinierte Patch-Baseline verwendet. Wenn keine Übereinstimmung vorliegt, wird eine Patch-Baseline anhand einer beliebigen Patchgruppe identifiziert, die für die Patching-Operation angegeben wurde. Wenn keine vorhanden ist, wird die AWS verwaltete vordefinierte Patch-Baseline für dieses Betriebssystem verwendet.
**Zusätzliche Berechtigungsanforderungen**
Wenn Sie `AWS-RunPatchBaselineAssociation` in anderen Patching-Operationen als den mithilfe von Quick Setup eingerichteten verwenden und Sie den optionalen `BaselineTags`-Parameter verwenden möchten, müssen Sie die folgenden Berechtigungen für das [Instance-Profil](setup-instance-permissions.md) für Amazon Elastic Compute Cloud (Amazon EC2)-Instances bereitstellen.
**Anmerkung**
Quick Setupund unterstützen `AWS-RunPatchBaselineAssociation` keine lokalen Server und virtuelle Maschinen (VMs).
```
{
"Effect": "Allow",
"Action": [
"ssm:DescribePatchBaselines",
"tag:GetResources"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetPatchBaseline",
"ssm:DescribeEffectivePatchesForPatchBaseline"
],
"Resource": "patch-baseline-arn"
}
```
*patch-baseline-arn*Ersetzen Sie es durch den Amazon-Ressourcennamen (ARN) der Patch-Baseline, auf die Sie Zugriff gewähren möchten, im folgenden Format`arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE`.
### Parametername: `AssociationId`
**Nutzung**: erforderlich.
`AssociationId` ist die ID einer Zuordnung in State Manager, einem Tool in AWS Systems Manager. Es wird von Patch Manager verwendet, um einer angegebenen Zuordnung Compliance-Daten hinzuzufügen. Diese Zuordnung bezieht sich auf einen `Scan`-Patching-Vorgang, der in einer [in Quick Setup erstellten Host-Management-Konfiguration](quick-setup-host-management.md) aktiviert ist. Indem Sie die Patching-Ergebnisse als Zuordnungs-Compliance-Daten statt als Inventar-Compliance-Daten senden, werden die vorhandenen Inventar-Compliance-Informationen für Ihre Instances nach einem Patchvorgang oder bei anderen Zuordnungen nicht überschrieben. IDs Wenn Sie noch keine Zuordnung erstellt haben, die Sie verwenden möchten, können Sie eine erstellen, indem Sie den Befehl [https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/create-association.html) ausführen. Beispiel:
------
#### [ 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
```
------
### Parametername: `InstallOverrideList`
**Nutzung**: optional.
Mit `InstallOverrideList` können Sie eine https-URL oder eine Amazon Simple Storage Service (Amazon S3)-URL im Pfadstil zu einer Liste mit zu installierenden Patches angeben. Diese im YAML-Format geführte Patch-Installationsliste überschreibt die von der Standard-Patch-Baseline angegebenen Patches. Dies bietet Ihnen eine differenziertere Kontrolle darüber, welche Patches auf Ihren Instances installiert sind.
**Wichtig**
Der `InstallOverrideList`-Dateiname darf die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).
Das Verhalten des Patch-Vorgangs bei Verwendung des `InstallOverrideList`-Parameters unterscheidet sich zwischen Linux- und macOS-verwalteten Knoten und Windows Server-verwalteten Knoten. Unter Linux und macOS versucht Patch Manager, Patches aus der Patchliste `InstallOverrideList` anzuwenden, die in einem auf dem Knoten aktivierten Repository vorhanden sind, unabhängig davon, ob die Patches den Patch-Baseline-Regeln entsprechen oder nicht. Auf Windows Server-Knoten werden Patches in der `InstallOverrideList`-Patch-Liste jedoch *nur* angewendet, wenn sie auch den Patch-Baseline-Regeln entsprechen.
Beachten Sie, dass Compliance-Berichte Patch-Status entsprechend den Angaben in der Patch-Baseline wiedergeben, nicht entsprechend Ihren Angaben in einer `InstallOverrideList`-Liste von Patches. Mit anderen Worten: Scan-Operationen ignorieren den Parameter `InstallOverrideList`. Auf diese Weise wird sichergestellt, dass Compliance-Berichte den Patch-Status konsistent entsprechend der Richtlinie wiedergeben und nicht danach, was für eine bestimmte Patching-Operation genehmigt wurde.
**Gültige URL-Formate**
**Anmerkung**
Wenn Ihre Datei in einem öffentlich zugänglichen Bucket gespeichert ist, können Sie entweder ein HTTPS-URL-Format oder eine URL im Amazon S3-Pfadstil angeben. Wenn Ihre Datei in einem privaten Bucket gespeichert ist, müssen Sie eine URL im Amazon S3-Pfadstil angeben.
+ **Beispiel des HTTPS-URL-Formats**:
```
https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml
```
+ **Beispiel-URL im Amazon-S3-Pfadstil**:
```
s3://amzn-s3-demo-bucket/my-windows-override-list.yaml
```
**Gültige YAML-Inhaltsformate**
Die Formate, die Sie verwenden, um Patches in Ihrer Liste anzugeben, hängen von dem Betriebssystem Ihrer Instance ab. Das allgemeine Format lautet jedoch folgendermaßen:
```
patches:
-
id: '{patch-d}'
title: '{patch-title}'
{additional-fields}:{values}
```
Sie können zwar zusätzliche Felder in der YAML-Datei bereitstellen, diese werden jedoch während der Patch-Operationen ignoriert.
Darüber hinaus empfehlen wir zu überprüfen, ob das Format Ihrer YAML-Datei gültig ist, bevor Sie die Liste in Ihrem S3-Bucket hinzufügen oder aktualisieren. Weitere Informationen zum YAML-Format finden Sie unter [yaml.org](http://www.yaml.org). Für Validierungstool-Optionen suchen Sie im Internet nach „yaml format validators“ durch.
+ Microsoft Windows
**id**
Das Feld **id** ist ein Pflichtfeld. Verwenden Sie es, um Patches mithilfe von Microsoft Knowledge Base IDs (z. B. KB2736693) und Microsoft Security Bulletin IDs (z. B. MS17 -023) anzugeben.
Alle anderen Felder, die Sie in einer Patch-Liste für Windows bereitstellen möchten, sind optional und dienen nur zu Ihrer eigenen Information. Sie können zusätzlichen Felder verwenden, wie z. B. **Titel**, **Klassifizierung**, **Schweregrad** oder andere Angaben für detailliertere Informationen über die angegebenen Patches.
+ Linux
**id**
Das Feld **id** ist ein Pflichtfeld. Verwenden Sie es, um Patches mit Paketnamen und Architektur anzugeben. Beispiel: `'dhclient.x86_64'`. Sie können Platzhalter in der ID verwenden, um mehrere Pakete anzugeben. Zum Beispiel `'dhcp*'` und `'dhcp*1.*'`.
**Titel**
Das Feld **Titel** ist optional, es bietet jedoch auf Linux-Systemen zusätzliche Filterfunktionen. Wenn Sie **Titel** verwenden, sollte er die Versionsinformationen des Pakets in einem der folgenden Formate enthalten:
YUM/Red Hat Enterprise Linux (RHEL):
```
{name}.{architecture}:{epoch}:{version}-{release}
```
APT
```
{name}.{architecture}:{version}
```
Für Linux-Patch-Titel können Sie einen oder mehrere Platzhalter in beliebigen Positionen verwenden, um die Anzahl der Paketzuordnungen zu erhöhen. Beispiel: `'*32:9.8.2-0.*.rc1.57.amzn1'`.
Zum Beispiel:
+ apt-Paketversion 1.2.25 ist derzeit auf Ihrer Instance installiert, aber Version 1.2.27 ist jetzt verfügbar.
+ Fügen Sie die apt.amd64-Version 1.2.27 der Liste hinzu. Sie ist abhängig von apt utils.amd64 Version 1.2.27, aber apt-utils.amd64 Version 1.2.25 ist in der Liste angegeben.
In diesem Fall wird die Installation der APT-Version 1.2.27 blockiert und als „Fehlgeschlagen-“ gemeldet. NonCompliant
**Andere Felder**
Alle anderen Felder, die Sie in einer Patch-Liste für Linux bereitstellen möchten, sind optional und dienen nur zu Ihrer eigenen Information. Sie können zusätzlichen Felder verwenden, wie z. B. **Klassifizierung**, **Schweregrad** oder andere Angaben für detailliertere Informationen über die angegebenen Patches.
**Patch-Beispiellisten**
+ **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'
```
### Parametername: `RebootOption`
**Nutzung**: optional.
**Optionen**: `RebootIfNeeded` \$1 `NoReboot`
**Standardwert**: `RebootIfNeeded`
**Warnung**
Die Standardoption ist `RebootIfNeeded`. Stellen Sie sicher, dass Sie die richtige Option für Ihren Anwendungsfall auswählen. Wenn Ihre Instances beispielsweise sofort neu starten müssen, um einen Konfigurationsprozess abzuschließen, wählen Sie `RebootIfNeeded` aus. Oder wenn Sie die Verfügbarkeit von Instances bis zu einer geplanten Neustartzeit beibehalten müssen, wählen Sie `NoReboot` aus.
**Wichtig**
Die Option `NoReboot` verhindert nur Neustarts auf Betriebssystemebene. Im Rahmen des Patch-Vorgangs können weiterhin Neustarts auf Service-Ebene erfolgen. Wenn Docker beispielsweise aktualisiert wird, können abhängige Services wie Amazon Elastic Container Service automatisch neu gestartet werden, auch wenn `NoReboot` aktiviert ist. Wenn Sie wichtige Services haben, die nicht unterbrochen werden dürfen, sollten Sie zusätzliche Maßnahmen in Betracht ziehen. Sie könnten z. B. Instances vorübergehend außer Betrieb nehmen oder Patches während Wartungsfenstern planen.
**Wichtig**
Wir empfehlen nicht, Cluster-Instances in Amazon EMR (früher Amazon Elastic MapReduce genannt) zum Patchen zu verwendenPatch Manager. Wählen Sie insbesondere nicht die Option `RebootIfNeeded` für den Parameter `RebootOption` aus. (Diese Option ist in den SSM-Befehlsdokumenten für das Patchen von `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` und `AWS-RunPatchBaselineWithHooks` verfügbar.)
Die zugrunde liegenden Befehle für das Patchen mithilfe von Patch Manager verwenden `yum`- und `dnf`-Befehle. Daher führen die Operationen aufgrund der Art und Weise, wie Pakete installiert werden, zu Inkompatibilitäten. Informationen zu den bevorzugten Methoden für die Aktualisierung von Software auf Amazon-EMR-Clustern finden Sie unter [Verwenden des Standard-AMI für Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) im *Amazon EMR Management Guide*.
RebootIfNeeded
Wenn Sie die Option `RebootIfNeeded` auswählen, wird die Instance in einem der folgenden Fälle neu gestartet:
+ Patch Manager ist auf einem oder mehreren Patches installiert.
Patch Manager wertet nicht aus, ob ein Neustart vom Patch *erfordert* wird. Das System wird neu gestartet, auch wenn der Patch keinen Neustart erfordert.
+ Patch Manager erkennt ein oder mehrere Patches mit dem Status `INSTALLED_PENDING_REBOOT` während der `Install`-Operation.
Der `INSTALLED_PENDING_REBOOT`-Status kann bedeuten, dass die Option `NoReboot` ausgewählt wurde, als der `Install`-Vorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von Patch Manager seit dem letzten Neustart des verwalteten Knotens installiert wurde.
Durch den Neustart von Instances wird in diesen beiden Fällen sichergestellt, dass aktualisierte Pakete aus dem Speicher gelöscht werden und das Patch- und Neustartverhalten über alle Betriebssysteme hinweg konsistent bleibt.
NoReboot
Wenn Sie die Option `NoReboot` auswählen, startet Patch Manager eine Instance nicht neu, selbst wenn über ihn während der `Install`-Operation Patches installiert wurden. Diese Option ist nützlich, wenn Sie wissen, dass für Ihre Instances nach dem Anwenden von Patches kein Neustart erforderlich ist oder Anwendungen bzw. Prozesse auf einer Instance ausgeführt werden, die nicht durch einen Neustart des Patches unterbrochen werden sollten. Sie ist auch nützlich, wenn Sie mehr Kontrolle über das Timing von Instance-Neustarts wünschen, z. B. durch die Verwendung eines Wartungsfensters.
**Datei zum Nachverfolgen der Patch-Installation (Tracking-Datei)**: Um die Patch-Installation nachzuverfolgen, insbesondere von Patches, die seit dem letzten Neustart des Systems installiert wurden, erstellt Systems Manager eine Datei auf der verwalteten Instance.
**Wichtig**
Löschen oder ändern Sie die Tracking-Datei nicht. Wenn diese Datei gelöscht oder beschädigt wird, ist der Patch-Compliance-Bericht für die Instance ungenau. Starten Sie in diesem Fall die Instance neu und führen Sie einen Patch-Scan-Vorgang aus, um die Datei wiederherzustellen.
Diese Tracking-Datei wird an den folgenden Speicherorten auf Ihren verwalteten Instances gespeichert:
+ Linux-Betriebssysteme:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server-Betriebssystem:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
# SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineWithHooks`
AWS Systems Manager unterstützt`AWS-RunPatchBaselineWithHooks`, ein Systems Manager Manager-Dokument (SSM-Dokument) fürPatch Manager, ein Tool in AWS Systems Manager. Dieses SSM-Dokument führt Patch-Operationen auf verwaltete Knoten sowohl für sicherheitsrelevante als auch für andere Arten von Updates durch.
`AWS-RunPatchBaselineWithHooks` unterscheidet sich auf folgende Weise von `AWS-RunPatchBaseline`:
+ **Ein Wrapper-Dokument** – `AWS-RunPatchBaselineWithHooks` ist ein Wrapper für `AWS-RunPatchBaseline` und setzt für einige seiner Operationen auf`AWS-RunPatchBaseline`.
+ **Die `Install`-Operation** – `AWS-RunPatchBaselineWithHooks` unterstützt Lebenszyklus-Hooks, die während dem Patchen von verwalteten Knoten an festgelegten Punkten ausgeführt werden. Da Patch-Installationen manchmal den Neustart von verwalteten Knoten erfordern, ist die Patch-Operation in zwei Ereignisse unterteilt, wobei insgesamt drei Hooks enthalten sind, die benutzerdefinierte Funktion unterstützen. Der erste Hook ist vor der `Install with NoReboot`-Operation. Der zweite Hook ist nach der `Install with NoReboot`-Operation. Der dritte Hook ist nach dem Neustart des verwalteten Knoten verfügbar.
+ **Keine Unterstützung für benutzerdefinierte Patchlisten** – `AWS-RunPatchBaselineWithHooks` unterstützt den `InstallOverrideList`-Parameter nicht.
+ **SSM Agent-Support** – `AWS-RunPatchBaselineWithHooks` erfordert die Installation von SSM Agent 3.0.502 oder höher auf dem zu patchenden verwalteten Knoten.
Wenn das Dokument ausgeführt wird, verwendet es die Patch-Baseline, die aktuell der „Standard“ für einen Betriebssystemtyp ist, wenn keine Patch-Gruppe angegeben ist. Andernfalls werden die Patch-Baselines verwendet, die der Patch-Gruppe zugeordnet sind. Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md).
Sie können das Dokument `AWS-RunPatchBaselineWithHooks` verwenden, um Patches sowohl für Betriebssysteme als auch für Anwendungen durchzuführen. (Unter Windows Server ist der Anwendungssupport auf Updates für Microsoft-Anwendungen beschränkt.)
Dieses Dokument unterstützt von Linux und von Windows Server verwaltete Knoten. Das Dokument führt die entsprechenden Aktionen für jede Plattform durch.
**Anmerkung**
`AWS-RunPatchBaselineWithHooks` wird in macOS nicht unterstützt.
------
#### [ Linux ]
Auf Linux-verwalteten Knoten ruft das Dokument `AWS-RunPatchBaselineWithHooks` ein Python-Modul auf, das wiederum einen entsprechenden Snapshot der Patch-Baseline für den verwalteten Knoten herunterlädt. Dieser Patch-Baseline-Snapshot verwendet die definierten Regeln und Listen der genehmigten und gesperrten Patches, um den entsprechenden Paketmanager für jeden Knoten-Typ anzutreiben:
+ Von Amazon Linux 2, Oracle Linux und RHEL 7 verwaltete Knoten verwenden YUM. Für YUM-Operationen ist eine `Python 2.6` oder eine Patch Manager neuere unterstützte Version (2.6 - 3.12) erforderlich. Amazon Linux 2023 verwendet DNF. Für DNF-Operationen Patch Manager ist eine unterstützte Version von `Python 2` oder `Python 3` (2.6 - 3.12) erforderlich.
+ Von RHEL 8 verwaltete Knoten verwenden DNF. Für DNF-Operationen Patch Manager ist eine unterstützte Version von `Python 2` or `Python 3` (2.6 - 3.12) erforderlich. (Keine der beiden Versionen ist standardmäßig auf RHEL 8 installiert. Sie müssen die eine oder andere Version manuell installieren.)
+ Debian Serverund Ubuntu Server Instanzen verwenden APT. Für APT-Operationen Patch Manager ist eine unterstützte Version von `Python 3` (3.0 - 3.12) erforderlich.
------
#### [ Windows Server ]
Auf Windows Server verwalteten Knoten lädt das `AWS-RunPatchBaselineWithHooks` Dokument ein PowerShell Modul herunter und ruft es auf, das wiederum einen Snapshot der Patch-Baseline herunterlädt, die für den verwalteten Knoten gilt. Dieser Patch-Baseline-Snapshot enthält eine Liste genehmigter Patches, die kompiliert werden, indem die Patch-Baseline auf einem WSUS-Server (Windows Server Update Services) abgefragt wird. Diese Liste wird an die Windows Update-API weitergeleitet, die das Herunterladen und Installieren des genehmigten Patches entsprechend steuert.
------
Jeder Snapshot ist spezifisch für eine AWS-Konto Patch-Gruppe, ein Betriebssystem und eine Snapshot-ID. Der Snapshot wird über eine vorsignierte Amazon Simple Storage Service (Amazon S3)-URL bereitgestellt, die 24 Stunden nach Erstellung des Snapshots abläuft. Wenn Sie jedoch denselben Snapshot-Inhalt auf andere verwaltete Knoten anwenden möchten, können Sie nach Ablauf der URL bis zu drei Tage nach Erstellung des Snapshots eine neue vorsignierte Amazon-S3-URL generieren. Verwenden Sie dazu den Befehl [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).
Nachdem alle genehmigten und zutreffenden Updates installiert und je nach Bedarf Neustarts durchgeführt wurden, werden Patch-Compliance-Informationen auf einem verwalteten Knoten generiert und wieder an Patch Manager gemeldet.
Wenn der Parameter `RebootOption` im Dokument `AWS-RunPatchBaselineWithHooks` auf `NoReboot` gesetzt ist, wird der verwaltete Knoten nach dem Ausführen von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption).
**Wichtig**
Die Option `NoReboot` verhindert zwar Neustarts des Betriebssystems, aber keine Neustarts auf Service-Ebene, die beim Aktualisieren bestimmter Pakete erfolgen können. Beispielsweise kann die Aktualisierung von Paketen wie Docker automatische Neustarts abhängiger Services auslösen (etwa Container-Orchestrierungsservices), selbst wenn `NoReboot` angegeben ist.
Weitere Informationen zum Anzeigen von Patch-Compliance-Daten finden Sie unter [Info zu Patch Compliance](compliance-about.md#compliance-monitor-patch).
## `AWS-RunPatchBaselineWithHooks`-Betriebsschritte
Wenn `AWS-RunPatchBaselineWithHooks` ausgeführt wird, werden die folgenden Schritte durchgeführt:
1. **Scan** – Eine `Scan`-Operation mit `AWS-RunPatchBaseline` wird auf dem verwalteten Knoten ausgeführt und ein Compliance-Bericht wird generiert und hochgeladen.
1. **Überprüfen der lokalen Patch-Zustände** – Ein Skript wird ausgeführt, um zu bestimmen, welche Schritte auf der Grundlage der ausgewählten Operation und dem `Scan`-Ergebnis aus Schritt 1 ausgeführt werden.
1. Wenn die ausgewählte Operation `Scan` ist, wird die Operation als abgeschlossen markiert. Die Operation ist abgeschlossen.
1. Wenn die ausgewählte Operation `Install` ist, werte Patch Manager das `Scan`-Ergebnis aus Schritt 1, um zu bestimmen, was als nächstes ausgeführt werden soll:
1. Wenn keine fehlenden Patches erkannt werden und keine ausstehenden Neustarts erforderlich sind, fährt die Operation direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen.
1. Wenn keine fehlenden Patches erkannt werden, aber ausstehende Neustarts erforderlich sind und die Neustartoption `NoReboot` ist, fährt die Operation direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen.
1. Andernfalls fährt die Operation mit dem nächsten Schritt fort.
1. **Hook-Operation vor dem Patchen** – Das SSM-Dokument, das Sie für den ersten Lebenszyklus-Hook bereitgestellt haben, `PreInstallHookDocName` wird auf dem verwalteten Knoten ausgeführt.
1. **Installation mit NoReboot** — Auf dem verwalteten Knoten `AWS-RunPatchBaseline` wird ein `Install` Vorgang `NoReboot` mit der Neustartoption ausgeführt, und es wird ein Konformitätsbericht generiert und hochgeladen.
1. **Hook-Operation nach der Installation** – Das SSM-Dokument, das Sie für den zweiten Lebenszyklus-Hook bereitgestellt haben, `PostInstallHookDocName` wird auf dem verwalteten Knoten ausgeführt.
1. **Überprüfen des Neustarts** – Ein Skript wird ausgeführt, um festzustellen, ob ein Neustart für den verwalteten Knoten erforderlich ist und welche Schritte ausgeführt werden sollen:
1. Wenn die ausgewählte Neustartoption `NoReboot` ist, geht die Operation direkt zum letzten Schritt (Schritt 8) über, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen.
1. Wenn die ausgewählte Neustartoption `RebootIfNeeded` ist, prüft Patch Manager, ob ausstehende Neustarts aus dem in Schritt 4 erfassten Bestand erforderlich sind. Dies bedeutet, dass der Vorgang mit Schritt 7 fortgesetzt wird und der verwaltete Knoten in einem der folgenden Fälle neu gestartet wird:
1. Patch Manager hat einen oder mehrere Patches installiert. (Patch Manager wertet nicht aus, ob für den Patch ein Neustart erforderlich ist. Das System wird auch dann neu gestartet, wenn der Patch keinen Neustart erfordert.)
1. Patch Manager erkennt ein oder mehrere Patches mit dem Status `INSTALLED_PENDING_REBOOT` während des Installationsvorgangs. Der `INSTALLED_PENDING_REBOOT`-Status kann bedeuten, dass die Option `NoReboot` ausgewählt wurde, als der Installations-Vorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von Patch Manager seit dem letzten Neustart des verwalteten Knotens installiert wurde.
Wenn keine Patches gefunden werden, die diese Kriterien erfüllen, ist der Patch-Vorgang für verwaltete Knoten abgeschlossen, und der Vorgang fährt direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen.
1. **Neustart und Bericht** – Eine Installations-Operation mit der Neustart-Option `RebootIfNeeded` wird auf dem verwalteten Knoten unter Verwendung von `AWS-RunPatchBaseline` ausgeführt und ein Compliance-Bericht wird generiert und hochgeladen.
1. **Hook-Operation nach Neustart** – Das SSM-Dokument, das Sie für den dritten Lebenszyklus-Hook bereitgestellt haben, `OnExitHookDocName` wird auf dem verwalteten Knoten ausgeführt.
Bei einer `Scan`-Operation wird der Prozess der Ausführung des Dokuments beendet, wenn Schritt 1 fehlschlägt, und der Schritt wird als fehlgeschlagen gemeldet, obwohl nachfolgende Schritte als erfolgreich gemeldet werden.
Wenn bei einem `Install`-Vorgang einer der `aws:runDocument`-Schritte während des Vorgangs fehlschlagen, werden diese Schritte als fehlgeschlagen gemeldet, und der Vorgang fährt direkt mit dem letzten Schritt (Schritt 8) fort, der einen von Ihnen bereitgestellten Hook enthält. Alle Schritte dazwischen werden übersprungen. Dieser Schritt wird als fehlgeschlagen gemeldet, der letzte Schritt meldet den Status des Vorgangsergebnisses, und alle dazwischen liegenden Schritte werden als erfolgreich gemeldet.
## `AWS-RunPatchBaselineWithHooks`-Parameter
`AWS-RunPatchBaselineWithHooks` unterstützt sechs Parameter.
Der Parameter `Operation` muss angegeben werden.
Die Parameter `RebootOption`, `PreInstallHookDocName`, `PostInstallHookDocName` und `OnExitHookDocName` sind optional.
`Snapshot-ID` ist eigentlich optional, wir empfehlen jedoch, einen benutzerdefinierten Wert dafür anzugeben, wenn Sie `AWS-RunPatchBaselineWithHooks` außerhalb eines Wartungsfensters ausführen. Lassen Sie Patch Manager den Wert automatisch angeben, wenn das Dokument als Teil einer Wartungsfenster-Operation ausgeführt wird.
**Topics**
+ [Parametername: `Operation`](#patch-manager-aws-runpatchbaseline-parameters-operation)
+ [Parametername: `Snapshot ID`](#patch-manager-aws-runpatchbaselinewithhook-parameters-snapshot-id)
+ [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption)
+ [Parametername: `PreInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-preinstallhookdocname)
+ [Parametername: `PostInstallHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-postinstallhookdocname)
+ [Parametername: `OnExitHookDocName`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-onexithookdocname)
### Parametername: `Operation`
**Nutzung**: erforderlich.
**Optionen**: `Scan` \$1 `Install`.
Scan
Wenn Sie die Option `Scan` wählen, verwende das System das Dokument `AWS-RunPatchBaseline`, um den Patch-Compliance-Zustand des verwalteten Knoten zu bestimmen und diese Informationen an Patch Manager zu melden. `Scan` fordert nicht zum Installieren von Updates oder zum Neustarten von verwalteten Knoten auf. Stattdessen erkennt die Operation, wo für den Knoten genehmigte und geeignete Updates fehlen.
Installieren
Bei Auswahl der Option `Install` versucht `AWS-RunPatchBaselineWithHooks`, die genehmigten und geeigneten Updates zu installieren, die auf dem verwalteten Knoten fehlen. Patch-Compliance-Informationen, die als Teil eines `Install`-Vorgangs generiert wurden, enthalten keine fehlenden Updates, melden allerdings möglicherweise Updates im Fehlerzustand, wenn die Installation des Updates aus einem beliebigen Grund nicht erfolgreich war. Immer wenn ein Update auf einem verwalteten Knoten installiert wird, wird der Knoten neu gestartet, um sicherzustellen, dass das Update installiert und aktiviert ist. (Ausnahme: Wenn der `RebootOption`-Parameter im `NoReboot`-Dokument auf `AWS-RunPatchBaselineWithHooks` gesetzt ist, wird der verwaltete Knoten nach der Ausführung von Patch Manager nicht neu gestartet. Weitere Informationen finden Sie unter [Parametername: `RebootOption`](#patch-manager-aws-runpatchbaselinewithhooks-parameters-norebootoption).)
Wenn ein von den Basisregeln festgelegter Patch installiert wird, *bevor* der Patch Manager den verwalteten Knoten aktualisiert, wird das System möglicherweise nicht wie erwartet neu gestartet. Dies kann passieren, wenn ein Patch manuell von einem Benutzer oder automatisch von einem anderen Programm, z. B. dem `unattended-upgrades`-Paket auf Ubuntu Server, installiert wird.
### Parametername: `Snapshot ID`
**Nutzung**: optional.
`Snapshot ID` ist eine eindeutige ID (GUID), die von Patch Manager verwendet wird, um sicherzustellen, dass ein Satz von verwalteten Knoten, für die in einer einzelnen Operation Patches durchgeführt werden, den genau gleichen Satz genehmigter Patches aufweist. Auch wenn der Parameter als optional definiert ist, hängen unsere Empfehlungen für bewährte Methoden davon ab, ob Sie `AWS-RunPatchBaselineWithHooks` in einem Wartungsfenster, wie in der folgenden Tabelle beschrieben, ausführen.
**Bewährte Methoden für `AWS-RunPatchBaselineWithHooks`**
| Mode | Bewährte Methode | Details |
| --- | --- | --- |
| Ausführen von AWS-RunPatchBaselineWithHooks innerhalb eines Wartungsfensters | Geben Sie keine Snapshot ID an. Patch Manager wird sie für Sie bereitstellen. | Falls Sie ein Wartungsfenster zum Ausführen von `AWS-RunPatchBaselineWithHooks` verwenden, dürfen Sie Ihre eigene generierte Snapshot ID nicht angeben. In diesem Szenario stellt Systems Manager einen GUID-Wert auf Grundlage der Wartungsfensterausführungs-ID bereit. Auf diese Weise wird sichergestellt, dass eine richtige ID für alle Aufrufe von `AWS-RunPatchBaselineWithHooks` in diesem Wartungsfenster verwendet wird. Wenn Sie einen Wert in diesem Szenario angeben, beachten Sie, dass der Snapshot der Patch-Baseline möglicherweise nicht länger als drei Tagen erhalten bleibt. Danach wird ein neuer Snapshot erstellt, auch wenn Sie dieselbe ID angeben, nachdem der Snapshot abgelaufen ist. |
| Ausführen von AWS-RunPatchBaselineWithHooks außerhalb eines Wartungsfensters | Generieren Sie einen benutzerdefinierten GUID-Wert für die Snapshot-ID und geben Sie ihn an.¹ | Wenn Sie kein Wartungsfenster zum Ausführen von `AWS-RunPatchBaselineWithHooks` verwenden, empfehlen wir, dass Sie eine eindeutige Snapshot-ID für jede Patch-Baseline generieren und angeben, insbesondere wenn Sie das Dokument `AWS-RunPatchBaselineWithHooks` auf mehreren verwaltete Knoten in derselben Operation ausführen. Wenn Sie keine ID in diesem Szenario angeben, generiert Systems Manager eine andere Snapshot-ID für jeden verwalteten Knoten, an den der Befehl gesendet wird. Dies kann zu unterschiedlichen Sätzen von Patches führen, die auf den Knoten angegeben sind. Angenommen, Sie führen das Dokument `AWS-RunPatchBaselineWithHooks` direkt über Run Command aus, ein Tool in AWS Systems Manager, und richten es auf eine Gruppe von 50 verwalteten Knoten aus. Das Angeben einer benutzerdefinierten Snapshot-ID führt zur Erstellung eines einzelnen Baseline-Snapshots, der verwendet wird, um alle verwaltete Knoten zu bewerten und zu patchen. Dadurch wird gewährleistet, dass sie letztendlich einen konsistenten Zustand aufweisen. |
| ¹ Sie können jedes beliebige Tool zum Generieren eines Werts für den Snapshot-ID-Parameter verwenden, das eine GUID generieren kann. In können Sie PowerShell beispielsweise das `New-Guid` Cmdlet verwenden, um eine GUID im Format von zu generieren. `12345699-9405-4f69-bc5e-9315aEXAMPLE` |
### Parametername: `RebootOption`
**Nutzung**: optional.
**Optionen**: `RebootIfNeeded` \$1 `NoReboot`
**Standardwert**: `RebootIfNeeded`
**Warnung**
Die Standardoption ist `RebootIfNeeded`. Stellen Sie sicher, dass Sie die richtige Option für Ihren Anwendungsfall auswählen. Wenn Ihre verwalteten Knoten beispielsweise sofort neu gestartet werden müssen, um einen Konfigurationsprozess abzuschließen, wählen Sie `RebootIfNeeded` aus. Oder wenn Sie die Verfügbarkeit von verwalteten Knoten bis zu einer geplanten Neustartzeit beibehalten müssen, wählen Sie `NoReboot` aus.
**Wichtig**
Wir empfehlen nicht, Cluster-Instances in Amazon EMR (früher Amazon Elastic MapReduce genannt) zum Patchen zu verwendenPatch Manager. Wählen Sie insbesondere nicht die Option `RebootIfNeeded` für den Parameter `RebootOption` aus. (Diese Option ist in den SSM-Befehlsdokumenten für das Patchen von `AWS-RunPatchBaseline`, `AWS-RunPatchBaselineAssociation` und `AWS-RunPatchBaselineWithHooks` verfügbar.)
Die zugrunde liegenden Befehle für das Patchen mithilfe von Patch Manager verwenden `yum`- und `dnf`-Befehle. Daher führen die Operationen aufgrund der Art und Weise, wie Pakete installiert werden, zu Inkompatibilitäten. Informationen zu den bevorzugten Methoden für die Aktualisierung von Software auf Amazon-EMR-Clustern finden Sie unter [Verwenden des Standard-AMI für Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-default-ami.html) im *Amazon EMR Management Guide*.
RebootIfNeeded
Wenn Sie die Option `RebootIfNeeded` auswählen, wird der verwaltete Knoten in einem der folgenden Fälle neu gestartet:
+ Patch Manager ist auf einem oder mehreren Patches installiert.
Patch Manager wertet nicht aus, ob ein Neustart vom Patch *erfordert* wird. Das System wird neu gestartet, auch wenn der Patch keinen Neustart erfordert.
+ Patch Manager erkennt ein oder mehrere Patches mit dem Status `INSTALLED_PENDING_REBOOT` während der `Install`-Operation.
Der `INSTALLED_PENDING_REBOOT`-Status kann bedeuten, dass die Option `NoReboot` ausgewählt wurde, als der `Install`-Vorgang das letzte Mal ausgeführt wurde, oder dass ein Patch außerhalb von Patch Manager seit dem letzten Neustart des verwalteten Knotens installiert wurde.
Durch den Neustart von verwalteten Knoten wird in diesen beiden Fällen sichergestellt, dass aktualisierte Pakete aus dem Speicher gelöscht werden und das Patch- und Neustartverhalten über alle Betriebssysteme hinweg konsistent bleibt.
NoReboot
Wenn Sie die Option `NoReboot` auswählen, startet Patch Manager einen verwalteten Knoten nicht neu, selbst wenn über ihn während der `Install`-Operation Patches installiert wurden. Diese Option ist nützlich, wenn Sie wissen, dass für Ihre verwalteten Knoten nach dem Anwenden von Patches kein Neustart erforderlich ist oder Anwendungen bzw. Prozesse auf einem Knoten ausgeführt werden, die nicht durch einen Neustart beim Patchen unterbrochen werden sollten. Sie ist auch nützlich, wenn Sie mehr Kontrolle über das Timing von Neustarts von verwalteten Knoten wünschen, z. B. durch die Verwendung eines Wartungsfensters.
Wenn Sie die Option `NoReboot` auswählen und ein Patch installiert ist, wird dem Patch der Status `InstalledPendingReboot` zugewiesen. Der verwaltete Knoten selbst wird jedoch als `Non-Compliant` gekennzeichnet. Nach einem Neustart und Ausführung einer `Scan`-Operation wird der Knoten-Status in `Compliant` aktualisiert.
**Datei zum Nachverfolgen der Patch-Installation**: Um die Patch-Installation nachzuverfolgen, insbesondere von Patches, die seit dem letzten Neustart des Systems installiert wurden, erstellt Systems Manager eine Datei auf dem verwalteten Knoten.
**Wichtig**
Löschen oder ändern Sie die Tracking-Datei nicht. Wenn diese Datei gelöscht oder beschädigt wird, ist der Patch-Compliance-Bericht für den verwalteten Knoten ungenau. Starten Sie in diesem Fall den Knoten neu und führen Sie eine Patch-Scan-Operation aus, um die Datei wiederherzustellen.
Diese Tracking-Datei wird an den folgenden Speicherorten auf Ihren verwalteten Knoten gespeichert:
+ Linux-Betriebssysteme:
+ `/var/log/amazon/ssm/patch-configuration/patch-states-configuration.json`
+ `/var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json`
+ Windows Server-Betriebssystem:
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json`
+ `C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json`
### Parametername: `PreInstallHookDocName`
**Nutzung**: optional.
**Standard**: `AWS-Noop`.
Der Wert, der für den `PreInstallHookDocName`-Parameter anzugeben ist, ist der Name oder der Amazon-Ressourcenname (ARN) eines SSM-Dokuments Ihrer Wahl. Sie können den Namen eines AWS verwalteten Dokuments oder den Namen oder ARN eines benutzerdefinierten SSM-Dokuments angeben, das Sie erstellt haben oder das für Sie freigegeben wurde. (Für ein SSM-Dokument, das von einem anderen für Sie freigegeben wurde AWS-Konto, müssen Sie den vollständigen Ressourcen-ARN angeben, z. `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` B.)
Das von Ihnen angegebene SSM-Dokument wird vor der `Install`-Operation ausgeführt und führt alle Aktionen aus, die von SSM Agent unterstützt werden, z. B. ein Shell-Skript, um die Zustandsprüfung der Anwendung zu überprüfen, bevor der verwaltete Knoten gepatcht wird. (Eine Liste der Aktionen finden Sie unter [Referenz für Befehlsdokument-Plugins](documents-command-ssm-plugin-reference.md)). Der SSM-Dokumentname ist standardmäßig `AWS-Noop`, was keine Operation für den verwalteten Knoten ausführt.
Informationen zum Erstellen eines benutzerdefinierten SSM-Dokuments finden Sie unter [Erstellen von SSM-Dokumentinhalten](documents-creating-content.md).
### Parametername: `PostInstallHookDocName`
**Nutzung**: optional.
**Standard**: `AWS-Noop`.
Der Wert, der für den `PostInstallHookDocName`-Parameter anzugeben ist, ist der Name oder der Amazon-Ressourcenname (ARN) eines SSM-Dokuments Ihrer Wahl. Sie können den Namen eines AWS verwalteten Dokuments oder den Namen oder ARN eines benutzerdefinierten SSM-Dokuments angeben, das Sie erstellt haben oder das für Sie freigegeben wurde. (Für ein SSM-Dokument, das von einem anderen für Sie freigegeben wurde AWS-Konto, müssen Sie den vollständigen Ressourcen-ARN angeben, z. `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument` B.)
Das von Ihnen angegebene SSM-Dokument wird nach der `Install with NoReboot`-Operation ausgeführt und führt alle Aktionen aus, die von SSM Agent unterstützt werden, z. B. ein Shell-Skript zum Installieren von Updates von Drittanbietern vor dem Neustart. (Eine Liste der Aktionen finden Sie unter [Referenz für Befehlsdokument-Plugins](documents-command-ssm-plugin-reference.md)). Der SSM-Dokumentname ist standardmäßig `AWS-Noop`, was keine Operation für den verwalteten Knoten ausführt.
Informationen zum Erstellen eines benutzerdefinierten SSM-Dokuments finden Sie unter [Erstellen von SSM-Dokumentinhalten](documents-creating-content.md).
### Parametername: `OnExitHookDocName`
**Nutzung**: optional.
**Standard**: `AWS-Noop`.
Der Wert, der für den `OnExitHookDocName`-Parameter anzugeben ist, ist der Name oder der Amazon-Ressourcenname (ARN) eines SSM-Dokuments Ihrer Wahl. Sie können den Namen eines AWS verwalteten Dokuments oder den Namen oder ARN eines benutzerdefinierten SSM-Dokuments angeben, das Sie erstellt haben oder das für Sie freigegeben wurde. (Für ein SSM-Dokument, das aus einem anderen AWS-Konto freigegeben wurde, müssen Sie den vollständigen Ressourcen-ARN angeben, z. B. `arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument`.)
Das von Ihnen angegebene SSM-Dokument wird nach dem Neustart des verwalteten Knoten ausgeführt und führt alle Aktionen aus, die von SSM Agent unterstützt werden, z. B. ein Shell-Skript, um den Knoten-Zustand nach Abschluss des Patchvorgangs zu überprüfen. (Eine Liste der Aktionen finden Sie unter [Referenz für Befehlsdokument-Plugins](documents-command-ssm-plugin-reference.md)). Der SSM-Dokumentname ist standardmäßig `AWS-Noop`, was keine Operation für den verwalteten Knoten ausführt.
Informationen zum Erstellen eines benutzerdefinierten SSM-Dokuments finden Sie unter [Erstellen von SSM-Dokumentinhalten](documents-creating-content.md).
# Beispielszenario für die Verwendung des InstallOverrideList Parameters in `AWS-RunPatchBaseline` oder `AWS-RunPatchBaselineAssociation`
Sie können den Parameter `InstallOverrideList` verwenden, wenn Sie die von der aktuellen Standard-Patch-Baseline in Patch Manager, ein Tool in AWS Systems Manager, angegebenen Patches überschreiben möchten. In diesem Thema finden Sie Beispiele, die zeigen, wie Sie diesen Parameter verwenden, um Folgendes zu erreichen:
+ Anwendung verschiedener Sätzen von Patches auf eine Zielgruppe von verwalteten Knoten.
+ Anwendung dieser Patch-Sets auf verschiedene Häufigkeiten
+ Verwendung derselben Patch-Baseline für beide Operationen
Angenommen, Sie möchten zwei verschiedene Kategorien von Patches auf Ihren von Amazon Linux 2 verwalteten Knoten installieren. Sie möchten diese Patches mithilfe von Wartungsfenstern nach verschiedenen Zeitplänen installieren. Sie möchten, dass jede Woche ein Wartungsfenster ausgeführt wird und alle `Security`-Patches installiert werden. Sie möchten, dass einmal im Monat ein weiteres Wartungsfenster ausgeführt wird und dabei alle verfügbaren Patches oder Kategorien von Patches außer `Security` installiert werden.
Es kann jedoch nur jeweils eine Patch-Baseline als Standard für ein Betriebssystem definiert werden. Diese Anforderung hilft, Situationen zu vermeiden, in denen eine Patch-Baseline einen Patch genehmigt, während eine andere ihn blockiert, was zu Problemen zwischen in Konflikt stehenden Versionen führen kann.
Mit der folgenden Strategie können Sie den Parameter `InstallOverrideList` verwenden, um verschiedene Patch-Typen nach verschiedenen Zeitplänen auf eine Zielgruppe anzuwenden und dabei dennoch dieselbe Patch-Baseline zu verwenden:
1. Stellen Sie in der Standard-Patch-Baseline sicher, dass nur `Security`-Updates angegeben sind.
1. Erstellen Sie ein Wartungsfenster, das `AWS-RunPatchBaseline` oder `AWS-RunPatchBaselineAssociation` jede Woche ausführt. Geben Sie keine Überschreibungsliste an.
1. Erstellen Sie eine Überschreibungsliste der Patches aller Typen, die Sie monatlich anwenden möchten, und speichern Sie sie in einem Amazon Simple Storage Service (Amazon S3)-Bucket.
1. Erstellen Sie ein zweites Wartungsfenster, das einmal im Monat ausgeführt wird. Geben Sie für die Run Command-Aufgabe, die Sie für dieses Wartungsfenster registrieren, jedoch den Speicherort Ihrer Überschreibungsliste an.
Das Ergebnis: Jede Woche werden nur `Security`-Patches installiert, wie in Ihrer Standard-Patch-Baseline definiert. Die Installation aller verfügbaren Patches oder einer von Ihnen definierten Teilmenge von Patches erfolgt jeden Monat.
**Anmerkung**
Wenn Sie einen Knoten patchen, der nur verwendet IPv6, stellen Sie sicher, dass die angegebene URL vom Knoten aus erreichbar ist. Wenn die SSM Agent Konfigurationsoption auf gesetzt `UseDualStackEndpoint` ist`true`, wird ein Dual-Stack-S3-Client verwendet, wenn eine S3-URL bereitgestellt wird. Weitere Informationen [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md) zur Konfiguration des Agenten für die Verwendung von Dualstack finden Sie unter.
Weitere Informationen und Beispiellisten finden Sie unter [Parametername: `InstallOverrideList`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist).
# Verwenden des BaselineOverride Parameters
Sie können Patching-Voreinstellungen zur Laufzeit mit der Baseline-Überschreibungsfunktion in Patch Manager definieren, einem Tool in AWS Systems Manager. Geben Sie dazu einen Amazon Simple Storage Service (Amazon S3)-Bucket an, der ein JSON-Objekt mit einer Liste mit Patch-Baselines enthält. Beim Patchvorgang werden die im JSON-Objekt bereitgestellten Baselines verwendet, die mit dem Hostbetriebssystem übereinstimmen, anstatt die Regeln aus der Standard-Patch-Baseline anzuwenden.
**Wichtig**
Der `BaselineOverride`-Dateiname darf die folgenden Zeichen nicht enthalten: Backtick (`), einfaches Anführungszeichen ('), doppeltes Anführungszeichen („) und Dollarzeichen (\$1).
Wenn Sie Patch-Policy verwenden, wird die Patch-Compliance der im `BaselineOverride`-Parameter angegebenen Baseline nicht überschrieben. Die Ausgabe wird in den Stdout-Protokollen von Run Command aufgezeichnet, einem Tool in AWS Systems Manager. Die Ergebnisse drucken nur Pakete aus, die als `NON_COMPLIANT` gekennzeichnet sind. Das bedeutet, dass das Paket als `Missing`, `Failed`, `InstalledRejected` oder `InstalledPendingReboot` gekennzeichnet ist.
Wenn ein Patch-Vorgang jedoch eine Patch-Richtlinie verwendet, übergibt das System den Override-Parameter aus dem zugehörigen S3-Bucket, und der Compliance-Wert wird für den verwalteten Knoten aktualisiert. Weitere Informationen zum Patch-Richtlinienverhalten finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).
**Anmerkung**
Wenn Sie einen Knoten patchen, der nur verwendet IPv6, stellen Sie sicher, dass die angegebene URL vom Knoten aus erreichbar ist. Wenn die SSM Agent Konfigurationsoption auf gesetzt `UseDualStackEndpoint` ist`true`, wird ein Dual-Stack-S3-Client verwendet, wenn eine S3-URL bereitgestellt wird. Weitere Informationen [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md) zur Konfiguration des Agenten für die Verwendung von Dualstack finden Sie unter.
## Verwenden der Patch-Baseline-Überschreibung mit den Parametern „Snapshot-ID“ oder „Install Override List“
Es gibt zwei Fälle, in denen die Patch-Baseline-Überschreibung ein bemerkenswertes Verhalten aufweist.
**Gleichzeitiges Verwenden von Baseline-Überschreiben und Snapshot-ID**
Snapshot-IDs stellen sicher, dass alle verwalteten Knoten in einem bestimmten Patching-Befehl dasselbe anwenden. Wenn Sie beispielsweise 1 000 Knoten gleichzeitig patchen, sind die Patches identisch.
Wenn Sie sowohl eine Snapshot-ID als auch eine Patch-Baseline-Überschreibung verwenden, hat die Snapshot-ID Vorrang vor der Patch-Baseline-Überschreibung. Die Baseline-Überschreibungsregeln werden weiterhin verwendet, aber sie werden nur einmal ausgewertet. Im vorangegangenen Beispiel sind die Patches für Ihre 1 000 verwaltete Knoten immer gleich. Wenn Sie in der Mitte des Patching-Vorgangs die JSON-Datei im referenzierten S3-Bucket auf etwas anderes geändert haben, sind die angewendeten Patches immer noch identisch. Dies liegt daran, dass die Snapshot-ID bereitgestellt wurde.
**Gleichzeitiges Verwenden der Baseline-Überschreibung und des Parameters „Override List“**
Sie können diese beiden Parameter nicht gleichzeitig verwenden. Das Patching-Dokument schlägt fehl, wenn beide Parameter angegeben sind, und es führt keine Scans oder Installationen auf dem verwalteten Knoten durch.
## Codebeispiele
Das folgende Codebeispiel für Python zeigt, wie die Patch-Baseline-Überschreibung generiert wird.
```
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)
```
So wird eine Patch-Baseline-Überschreibung wie die folgende erstellt.
```
[
{
"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": []
}
]
```
# Patch-Baselines
In den Themen in diesem Abschnitt finden Sie Informationen zur Funktionsweise von Patch-Baselines in Patch Manager, einem Tool in AWS Systems Manager, wenn Sie einen `Scan`- oder `Install`-Vorgang auf Ihren verwalteten Knoten ausführen.
**Topics**
+ [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md)
+ [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md)
+ [Patch-Gruppen](patch-manager-patch-groups.md)
+ [Informationen zum Patchen von Anwendungen, die von Microsoft unter Windows Server veröffentlicht wurden](patch-manager-patching-windows-applications.md)
# Vordefinierte und benutzerdefinierte Patch-Baselines
Patch Manager, ein Tool in AWS Systems Manager, bietet vordefinierte Patch-Baselines für jedes der Betriebssysteme, die von unterstützt werden. Patch Manager Sie können diese Baselines in ihrer aktuellen Konfiguration verwenden (eine Anpassung ist nicht möglich) oder eigene benutzerdefinierte Patch-Baselines erstellen. Benutzerdefinierte Patch-Baselines ermöglichen Ihnen eine bessere Kontrolle darüber, welche Patches für Ihre Umgebung genehmigt oder abgelehnt werden. Außerdem weisen die vordefinierten Baselines allen Patches, die mit diesen Baselines installiert wurden, die Compliance-Ebene `Unspecified` zu. Für die Zuweisung von Compliance-Werten können Sie eine Kopie einer vordefinierten Baseline erstellen und die Compliance-Werte angeben, die Patches zugewiesen werden sollen. Weitere Informationen erhalten Sie unter [Benutzerdefinierte Baselines](#patch-manager-baselines-custom) und [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).
**Anmerkung**
Die Informationen in diesem Thema gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihren Patching-Vorgang verwenden:
Eine in Quick Setup konfigurierte Patch-Richtlinie
Eine in Quick Setup konfigurierte Host-Management-Option
Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
Ein On-Demand-**Jetzt patchen**-Vorgang
**Topics**
+ [Vordefinierte Baselines](#patch-manager-baselines-pre-defined)
+ [Benutzerdefinierte Baselines](#patch-manager-baselines-custom)
## Vordefinierte Baselines
Die folgende Tabelle beschreibt die mit Patch Manager bereitgestellten vordefinierten Patch-Baselines.
Informationen dazu, welche Versionen der einzelnen Betriebssysteme von Patch Manager unterstützt werden, finden Sie unter [Patch Manager-Voraussetzungen](patch-manager-prerequisites.md).
****
| Name | Unterstütztes Betriebssystem | Details |
| --- | --- | --- |
| `AWS-AlmaLinuxDefaultPatchBaseline` | AlmaLinux | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
| AWS-AmazonLinux2DefaultPatchBaseline | Amazon Linux 2 | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden automatisch sieben Tage nach der Veröffentlichung genehmigt.¹ |
| AWS-AmazonLinux2023DefaultPatchBaseline | Amazon Linux 2023 | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Patches werden automatisch sieben Tage nach der Veröffentlichung genehmigt. Genehmigt außerdem alle Patches mit einer Klassifizierung „Bugfix“ sieben Tage nach der Veröffentlichung. |
| AWS-CentOSDefaultPatchBaseline | CentOS Stream | Genehmigt alle Aktualisierungen sieben Tage nach ihrer Verfügbarkeit, einschließlich nicht sicherheitsrelevanter Aktualisierungen. |
| AWS-DebianDefaultPatchBaseline | Debian Server | Genehmigt sofort alle sicherheitsrelevanten Patches für Betriebssysteme mit der Priorität „Required“, „Important“, „Standard“, „Optional“ oder „Extra“. Die Genehmigung erfolgt unverzüglich, weil in den Repositorys keine zuverlässigen Datumsangaben zur Veröffentlichung verfügbar sind. |
| AWS-MacOSDefaultPatchBaseline | macOS | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“. Genehmigt auch alle Pakete mit einem aktuellen Update. |
| AWS-OracleLinuxDefaultPatchBaseline | Oracle Linux | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Important“ oder „Moderate“. Genehmigt außerdem alle als „Bugfix“ eingestuften Patches 7 Tage nach Veröffentlichung. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
| `AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
| `AWS-RockyLinuxDefaultPatchBaseline` | Rocky Linux | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Genehmigt außerdem alle Patches mit der Klassifizierung „Bugfix“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
| AWS-SuseDefaultPatchBaseline | SUSE Linux Enterprise Server (SLES) | Genehmigt alle Betriebssystem-Patches mit der Klassifizierung „Security“ und dem Schweregrad „Critical“ oder „Important“. Patches werden sieben Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.¹ |
| `AWS-UbuntuDefaultPatchBaseline` | Ubuntu Server | Genehmigt sofort alle sicherheitsrelevanten Patches für Betriebssysteme mit der Priorität „Required“, „Important“, „Standard“, „Optional“ oder „Extra“. Die Genehmigung erfolgt unverzüglich, weil in den Repositorys keine zuverlässigen Datumsangaben zur Veröffentlichung verfügbar sind. |
| AWS-DefaultPatchBaseline | Windows Server | Genehmigt alle Windows Server Betriebssystem-Patches, die als "" oder CriticalUpdates SecurityUpdates "eingestuft sind und die den MSRC-Schweregrad „Kritisch“ oder „Wichtig“ haben. Patches werden 7 Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.² |
| AWS-WindowsPredefinedPatchBaseline-OS | Windows Server | Genehmigt alle Windows Server Betriebssystem-Patches, die als "oder" CriticalUpdates "eingestuft sind und die den MSRC-Schweregrad „Kritisch“ oder „Wichtig“ haben. SecurityUpdates Patches werden 7 Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.² |
| AWS-WindowsPredefinedPatchBaseline-OS-Applications | Windows Server | Genehmigt für das Windows Server Betriebssystem alle Patches, die als "oder CriticalUpdatesSecurityUpdates" eingestuft sind und die den MSRC-Schweregrad „Kritisch“ oder „Wichtig“ haben. Genehmigt für von Microsoft veröffentlichte Anwendungen alle Patches. Patches für Betriebssysteme und Anwendungen werden 7 Tage nach ihrer Veröffentlichung oder Aktualisierung automatisch genehmigt.² |
¹ Für Amazon Linux 2 wird die 7-Tage-Wartezeit, bevor Patches automatisch genehmigt werden, aus einem `Updated Date`-Wert in `updateinfo.xml` und nicht aus einem `Release Date`-Wert berechnet. Verschiedene Faktoren können den `Updated Date`-Wert beeinflussen. Andere Betriebssysteme behandeln Veröffentlichungs- und Aktualisierungsdaten unterschiedlich. Informationen dazu, wie Sie unerwartete Ergebnisse durch Verzögerungen bei der automatischen Genehmigung vermeiden können, finden Sie unter [So werden Veröffentlichungs- und Aktualisierungsdaten von Paketen berechnet](patch-manager-release-dates.md).
² Für Windows Server enthalten die Standard-Baselines eine Verzögerung von 7 Tagen für die automatische Genehmigung. Um einen Patch innerhalb von 7 Tagen nach der Veröffentlichung zu installieren, müssen Sie eine benutzerdefinierte Baseline erstellen.
## Benutzerdefinierte Baselines
Mithilfe der folgenden Informationen können Sie benutzerdefinierte Patch-Baselines erstellen, um Ihre Patching-Ziele zu erreichen.
**Topics**
+ [Automatische Genehmigungen in benutzerdefinierten Baselines verwenden](#baselines-auto-approvals)
+ [Zusätzliche Informationen zum Erstellen von Patch-Baselines](#baseline-additional-info)
### Automatische Genehmigungen in benutzerdefinierten Baselines verwenden
Wenn Sie eine eigene Patch-Baseline herstellen, können Sie die Patches wahlweise automatisch genehmigen, indem Sie die folgenden Kategorien verwenden.
+ **Betriebssystem**: Unterstützte Versionen von Windows Server, Amazon Linux, Ubuntu Server, usw.
+ **Produktname **(für Betriebssysteme): Beispielsweise RHEL 7.5, Amazon Linux 2023 2023.8.20250808, Windows Server 2012, Windows Server 2012 R2 usw.
+ **Produktname** (Windows Servernur für von Microsoft veröffentlichte Anwendungen): Zum Beispiel Word 2016, BizTalk Server usw.
+ **Klassifizierung**: Beispielsweise kritische Updates, Sicherheitsupdates usw.
+ **Schweregrad**: Beispielsweise kritisch, wichtig usw.
Für jede von Ihnen erstellte Genehmigungsregel können Sie eine Verzögerung für die automatische Genehmigung oder ein Stichdatum für die Patch-Genehmigung angeben.
**Anmerkung**
Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.
Eine Verzögerung der automatischen Genehmigung ist die Anzahl an Tagen, die gewartet werde soll, nachdem die Patch veröffentlicht oder zuletzt aktualisiert wurde, bevor der Patch automatisch genehmigt wird. Wenn Sie beispielsweise eine Regel mit der `CriticalUpdates`-Klassifizierung erstellen und für sie für eine Verzögerung der automatischen Genehmigung von sieben Tagen konfigurieren, wird ein neuer kritischer Patch, der am 7. Juli veröffentlicht wird, am 14. Juli automatisch genehmigt.
Wenn ein Linux-Repository keine Informationen zum Veröffentlichungsdatum von Paketen bereitstellt, verwendet Patch Manager den Erstellungszeitpunkt des Pakets als Datum zur automatischen Genehmigung der Datumsangaben für Amazon Linux 2, Amazon Linux 2023 und Red Hat Enterprise Linux (RHEL). Wenn die Erstellungszeit des Pakets nicht bestimmt werden kann, verwendet Patch Manager als Standarddatum den 1. Januar 1970. Dies führt dazu, dass alle Angaben zum Datum der automatischen Genehmigung in Patch-Baselines von Patch Manager umgangen werden, die so konfiguriert sind, dass Patches für jedes Datum nach dem 1. Januar 1970 genehmigt werden.
Wenn Sie ein Stichdatum für die automatische Genehmigung angeben, wendet Patch Manager automatisch alle Patches an, die an oder vor diesem Datum veröffentlicht oder zuletzt aktualisiert wurden. Wenn Sie beispielsweise den 07. Juli 2023 als Stichtag angeben, werden keine Patches automatisch installiert, die an oder nach dem 08. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden.
Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für Patches, die von dieser Patch-Baseline genehmigt wurden, einen Schweregrad für die Konformität angeben, beispielsweise `Critical` oder `High`. Wenn der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann ist der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline der von Ihnen angegebene Schweregrad.
### Zusätzliche Informationen zum Erstellen von Patch-Baselines
Beachten Sie bei der Erstellung einer Patch-Baseline Folgendes:
+ Patch Manager stellt eine vordefinierte Patch-Baseline für jedes unterstützte Betriebssystem bereit. Diese vordefinierten Patch-Baselines werden als Standard-Patch-Baselines für alle Betriebssystemtypen verwendet, wenn Sie nicht eigene Patch-Baselines erstellen und diese als Standard für den jeweiligen Betriebssystemtyp festlegen.
**Anmerkung**
Für Windows Server werden drei vordefinierte Patch-Baselines bereitgestellt. Die Patch-Baselines `AWS-DefaultPatchBaseline` und `AWS-WindowsPredefinedPatchBaseline-OS` unterstützen nur Betriebssystemupdates auf dem Windows-Betriebssystem selbst. `AWS-DefaultPatchBaseline` wird als Standard-Patch-Baseline für von Windows Server verwalteten Knoten verwendet, es sei denn, Sie geben eine andere Patch-Baseline an. Die Konfigurationseinstellungen in diesen beiden Patch-Baselines sind identisch. Die neuere der beiden, `AWS-WindowsPredefinedPatchBaseline-OS`, wurde erstellt, um sie von der dritten vordefinierten Patch-Baseline für Windows Server zu unterscheiden. Diese Patch-Baseline, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, kann verwendet werden, um Patches sowohl auf das Windows Server-Betriebssystem als auch auf unterstützte Anwendungen, die von Microsoft veröffentlicht wurden, anzuwenden.
+ Standardmäßig entfernen Windows Server 2019 und Windows Server 2022 Updates, die durch spätere Updates ersetzt werden. Wenn Sie also den `ApproveUntilDate`-Parameter in einer Windows Server-Patch-Baseline verwenden, das im `ApproveUntilDate`-Parameter ausgewählte Datum jedoch vor dem Datum des neuesten Patches liegt, wird der neue Patch nicht installiert, wenn der Patching-Vorgang ausgeführt wird. Weitere Informationen zu Windows Server-Patching-Regeln, finden Sie in der Registerkarte Windows Server in [Wie Sicherheitspatches ausgewählt werden](patch-manager-selecting-patches.md).
Das bedeutet, dass der verwaltete Knoten die Anforderungen des Systems-Manager-Betriebs erfüllt, auch wenn ein kritischer Patch aus dem Vormonat möglicherweise nicht installiert wurde. Das gleiche Szenario kann bei Verwendung des `ApproveAfterDays`-Parameters auftreten. Aufgrund des Verhaltens von Microsoft bei abgelösten Patches ist es möglich, eine Zahl (im Allgemeinen größer als 30 Tage) festzulegen, sodass Patches für Windows Server nie installiert werden, wenn der neueste verfügbare Patch von Microsoft veröffentlicht wird, bevor die Anzahl der Tage in `ApproveAfterDays` verstrichen ist.
+ Nur für Windows Server kann ein verfügbarer Sicherheitsupdate-Patch, der nicht von der Patch-Baseline genehmigt wurde, den Konformitätswert `Compliant` oder `Non-Compliant` haben, wie in einer benutzerdefinierten Patch-Baseline definiert.
Wenn Sie eine Patch-Baseline erstellen oder aktualisieren, wählen Sie den Status, den Sie Sicherheitspatches zuweisen möchten, die zwar verfügbar, aber nicht genehmigt sind, weil sie die in der Patch-Baseline angegebenen Installationskriterien nicht erfüllen. Beispielsweise können Sicherheitspatches, die Sie möglicherweise installieren möchten, übersprungen werden, wenn Sie eine lange Wartezeit für die Installation nach der Veröffentlichung eines Patches angegeben haben. Wenn während der von Ihnen angegebenen Wartezeit ein Update für den Patch veröffentlicht wird, beginnt die Wartezeit für die Installation des Patches von vorne. Wenn die Wartezeit zu lang ist, können mehrere Versionen des Patches veröffentlicht, aber nie installiert werden.
Wenn Sie die Konsole verwenden, um eine Patch-Baseline zu erstellen oder zu aktualisieren, geben Sie diese Option im Feld **Compliance-Status für verfügbare Sicherheitsupdates** an. Mit AWS CLI dem [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)Befehl [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)oder geben Sie diese Option im `available-security-updates-compliance-status` Parameter an.
+ Patch ManagerVersucht bei lokalen Servern und virtuellen Maschinen (VMs), Ihre benutzerdefinierte Standard-Patch-Baseline zu verwenden. Wenn keine benutzerdefinierte Standard-Patch-Baseline vorhanden ist, verwendet das System die vordefinierte Patch-Baseline für das entsprechende Betriebssystem.
+ Wenn ein Patch sowohl als genehmigt als auch als abgelehnt aufgelistet ist, wird der Patch abgelehnt.
+ Für einen verwalteten Knoten kann nur eine einzige Patch-Baseline definiert werden.
+ Die Formate der Paketnamen, die Sie zu den Listen der genehmigten und abgelehnten Patches für eine Patch-Baseline hinzufügen können, hängen von der Art des Betriebssystems ab, das gepatcht wird.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
+ Wenn Sie eine [Patch-Richtlinienkonfiguration](patch-manager-policies.md) in Quick Setup verwenden, werden Aktualisierungen, die Sie an benutzerdefinierten Patch-Baselines vornehmen, einmal pro Stunde mit Quick Setup synchronisiert.
Wenn eine benutzerdefinierte Patch-Baseline gelöscht wird, auf die in einer Patch-Richtlinie verwiesen wurde, wird auf der Seite mit den Quick Setup-**Konfigurationsdetails** ein Banner für Ihre Patch-Richtlinie angezeigt. Das Banner informiert Sie darüber, dass die Patch-Richtlinie auf eine nicht mehr vorhandene Patch-Baseline verweist und nachfolgende Patching-Vorgänge fehlschlagen werden. Kehren Sie in diesem Fall zur Seite Quick Setup-**Konfigurationen** zurück, wählen Sie die Patch Manager-Konfiguration aus und wählen Sie **Aktionen**, **Konfiguration bearbeiten**. Der Name der gelöschten Patch-Baseline wird hervorgehoben, und Sie müssen eine neue Patch-Baseline für das betroffene Betriebssystem auswählen.
+ Wenn Sie eine Genehmigungsregel mit mehreren `Classification`- und `Severity`-Werten erstellen, werden Patches auf der Grundlage ihrer verfügbaren Attribute genehmigt. Pakete mit beiden `Classification`- und `Severity`-Attributen und entsprechen den ausgewählten Basiswerten für beide Felder. Pakete, die nur `Classification`-Attribute enthalten, werden nur mit den ausgewählten `Classification`-Basiswerten verglichen. Schweregradanforderungen in derselben Regel werden für Pakete ohne `Severity`-Attribute ignoriert.
Informationen zum Erstellen einer Patch-Baseline finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md) und [Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).
# Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen
Die Formate der Paketnamen, die Sie zu den Listen der genehmigten und abgelehnten Patches hinzufügen können, hängen von der Art des Betriebssystems ab, das gepatcht wird.
## Paketnamen-Formate für Linux-Betriebssysteme
Die Formate, die Sie für genehmigte und abgelehnte Patches in der Patch-Baseline festlegen können, variieren je nach Linux-Typ. Genauer gesagt hängen die unterstützten Formate von dem Paket-Manager ab, der vom Linux-Betriebssystemtyp verwendet wird.
**Topics**
+ [Amazon Linux 2, Amazon Linux 2023, Oracle Linux und Red Hat Enterprise Linux (RHEL)](#patch-manager-approved-rejected-package-name-formats-standard)
+ [Debian Server und 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 und Red Hat Enterprise Linux (RHEL)
**Paket-Manager**: YUM, außer unter Amazon Linux 2023 und RHEL 8, die DNF als Paket-Manager verwenden.
**Genehmigte Patches**: Für genehmigte Patches können Sie Folgendes festlegen:
+ Bugzilla IDs, im Format `1234567` (Das System verarbeitet Zeichenketten, die nur Zahlen enthalten, als Bugzilla.) IDs
+ CVE IDs, im Format `CVE-2018-1234567`
+ Beratung IDs, in Formaten wie und `RHSA-2017:0864` `ALAS-2018-123`
+ Paketnamen, die unter Verwendung einer oder mehrerer der verfügbaren Komponenten für die Paketbenennung erstellt wurden. Zur Veranschaulichung lauten die Komponenten für das genannte `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`-Paket wie folgt:
+ `name`: `dbus`
+ `architecture`: `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
Paketnamen mit den folgenden Konstruktionen werden unterstützt:
+ `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`
Hier einige Beispiele:
+ `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`
+ Wir unterstützen auch Paketnamenkomponenten mit einem einzigen Platzhalter in den oben genannten Formaten, z. B. in den folgenden:
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
**Abgelehnte Patches**: Für abgelehnte Patches können Sie Folgendes festlegen:
+ Paketnamen, die unter Verwendung einer oder mehrerer der verfügbaren Komponenten für die Paketbenennung erstellt wurden. Zur Veranschaulichung lauten die Komponenten für das genannte `dbus.x86_64:1:1.12.28-1.amzn2023.0.1`-Paket wie folgt:
+ `name`: `dbus`
+ `architecture`; `x86_64`
+ `epoch`: `1`
+ `version`: `1.12.28`
+ `release`: `1.amzn2023.0.1`
Paketnamen mit den folgenden Konstruktionen werden unterstützt:
+ `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`
Hier einige Beispiele:
+ `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`
+ Wir unterstützen auch Paketnamenkomponenten mit einem einzigen Platzhalter in den oben genannten Formaten, z. B. in den folgenden:
+ `dbus*`
+ `dbus-1.12.2*`
+ `dbus-*:1.12.28-1.amzn2023.0.1.x86_64`
### Debian Server und Ubuntu Server
**Paket-Manager**: APT
**Genehmigte Patches** und **abgelehnte Patches**: Legen Sie für genehmigte sowie abgelehnte Patches Folgendes fest:
+ Paketnamen im Format `ExamplePkg33`
**Anmerkung**
Verwenden Sie für Debian Server- und Ubuntu Server-Listen keine Elemente wie Architektur oder Versionen. Beispiel: Sie legen den Paketnamen `ExamplePkg33` fest, um alles Folgende in einer Patch-Liste einzubeziehen:
`ExamplePkg33.x86.1`
`ExamplePkg33.x86.2`
`ExamplePkg33.x64.1`
`ExamplePkg33.3.2.5-364.noarch`
### SUSE Linux Enterprise Server (SLES)
**Paket-Manager**: Zypper
**Genehmigte Patches** und **abgelehnte Patches**: Sie können für genehmigte sowie abgelehnte Patch-Listen Folgendes festlegen:
+ Vollständige Paketnamen in Formaten wie z. B.:
+ `SUSE-SLE-Example-Package-15-2023-123`
+ `example-pkg-2023.15.4-46.17.1.x86_64.rpm`
+ Paketnamen mit einem einzigen Platzhalter wie z. B.:
+ `SUSE-SLE-Example-Package-15-2023-*`
+ `example-pkg-2023.15.4-46.17.1.*.rpm`
## Paketnamen-Formate für macOS
**Unterstützte Paketmanager**: Softwareupdate, Installationsprogramm, Brew, Brew Cask
**Genehmigte Patches** und **abgelehnte Patches**: Geben Sie für genehmigte sowie abgelehnte Patch-Listen vollständige Paketnamen in folgenden formaten an:
+ `XProtectPlistConfigData`
+ `MRTConfigData`
Platzhalter werden in Listen genehmigter und abgelehnter Patches für macOS nicht unterstützt.
## Paketnamen-Formate für Windows-Betriebssysteme
Geben Sie für Windows-Betriebssysteme Patches mithilfe von Microsoft Knowledge Base IDs und Microsoft Security Bulletin an IDs. Beispiel:
```
KB2032276,KB2124261,MS10-048
```
# Patch-Gruppen
**Anmerkung**
Patch-Gruppen werden nicht in Patch-Vorgängen verwendet, die auf *Patch-Richtlinien* basieren. Weitere Informationen zur Arbeit mit Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).
Die Patchgruppenfunktion wird in der Konsole für Konto-Regionen-Paare nicht unterstützt, die vor der Veröffentlichung der Patch-Richtlinienunterstützung am 22. Dezember 2022 noch keine Patchgruppen verwendet haben. Die Patchgruppenfunktion ist weiterhin für Konto-Regionen-Paare verfügbar, die vor diesem Datum mit der Verwendung von Patchgruppen begonnen haben.
Mithilfe einer *Patch-Gruppe* können Sie verwaltete Knoten einer bestimmten Patch-Baseline in Patch Manager, ein Tool in AWS Systems Manager, zuordnen. Mit Patch-Gruppen können Sie sicherstellen, dass Sie geeignete Patches basierend auf den zugeordneten Patch-Baseline-Regeln für die richtigen Sätze von Knoten bereitstellen. Patch-Gruppen können außerdem dazu beitragen, die Bereitstellung von Patches zu vermeiden, bevor diese angemessen getestet sind. So können Sie Patch-Gruppen beispielsweise für unterschiedliche Umgebungen (Entwicklung, Test und Produktion) erstellen und jede Patch-Gruppe für eine geeignete Patch-Baseline registrieren.
Wenn Sie `AWS-RunPatchBaseline` oder andere SSM-Befehlsdokumente zum Patching ausführen, können Sie verwaltete Knoten über deren ID oder Tags anvisieren. Basierend auf dem Patch-Gruppenwert, den Sie dem verwalteten Knoten hinzugefügt haben, werten dann SSM Agent und Patch Manager aus, welche Patch-Baseline verwendet werden soll.
## Verwendung von Tags zur Definition von Patchgruppen
Sie können eine Patchgruppe erstellen, indem Sie Tags verwenden, die auf Ihre Instances der Amazon Elastic Compute Cloud (Amazon EC2) und Nicht-EC2-Knoten in Ihrer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) angewendet werden. Beachten Sie die folgenden Details zum Verwenden von Tags für Patchgruppen:
+
Eine Patchgruppe muss entweder mithilfe des Tag-Schlüssels `Patch Group` oder `PatchGroup` definiert werden, die auf Ihre verwalteten Knoten angewendet werden. Bei der Registrierung einer Patchgruppe für eine Patch-Baseline werden alle identischen *Werte*, die für diese beiden Schlüssel angegeben wurden, als Teil derselben Gruppe interpretiert. Nehmen wir zum Beispiel an, Sie haben fünf Knoten mit dem ersten der folgenden Schlüssel-Wert-Paare und fünf mit dem zweiten getaggt:
+ `key=PatchGroup,value=DEV`
+ `key=Patch Group,value=DEV`
Der Patch Manager-Befehl zum Erstellen einer Baseline fasst diese 10 verwalteten Knoten auf der Grundlage des Werts `DEV` zu einer einzigen Gruppe zusammen. Das AWS CLI-Äquivalent für den Befehl zum Erstellen einer Patch-Baseline für Patch-Gruppen lautet wie folgt:
```
aws ssm register-patch-baseline-for-patch-group \
--baseline-id pb-0c10e65780EXAMPLE \
--patch-group DEV
```
Die Kombination von Werten aus verschiedenen Schlüsseln zu einem einzigen Ziel ist einzigartig für diesen Patch Manager-Befehl zum Erstellen einer neuen Patchgruppe und wird von anderen API-Aktionen nicht unterstützt. Wenn Sie beispielsweise [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html)-Aktionen mit `PatchGroup`- und `Patch Group`-Schlüsseln und mit denselben Werten ausführen, zielen Sie auf zwei völlig unterschiedliche Gruppen von Knoten ab:
```
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"
```
+ Es gibt Beschränkungen für das Tag-basierte Targeting. Jedes Ziele-Array für `SendCommand` kann maximal fünf Schlüssel-Wert-Paare haben.
+ Es wird empfohlen, nur eine dieser Konventionen für Tag-Schlüssel zu wählen, entweder `PatchGroup` (ohne Leerzeichen) oder `Patch Group` (mit Leerzeichen). Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie jedoch `PatchGroup` verwenden.
+ Bei dem Schlüssel wird die Groß-/Kleinschreibung berücksichtigt. Sie können einen beliebigen *Wert* angeben, um die Ressourcen in dieser Gruppe zu identifizieren und darauf auszurichten, z. B. „Webserver“ oder „US-EAST-PROD“, aber der Schlüssel muss `Patch Group` oder `PatchGroup` sein.
Wenn Sie eine Patch-Gruppe erstellt und verwaltete Knoten mit Tags markiert haben, können Sie die Patch-Gruppe für eine Patch-Baseline anmelden. Indem Sie die Patch-Gruppe für eine Patch-Baseline registrieren, stellen Sie sicher, dass die Knoten innerhalb der Patch-Gruppe die in der zugehörigen Patch-Baseline definierten Regeln befolgen.
Weitere Informationen zum Erstellen von Patch-Gruppen und Zuordnen von Patch-Gruppen zu einer Patch-Baseline finden Sie unter [Erstellen und Verwalten von Patch-Gruppen](patch-manager-tag-a-patch-group.md) und [Einer Patch-Baseline eine Patch-Gruppe hinzufügen](patch-manager-tag-a-patch-group.md#sysman-patch-group-patchbaseline).
Ein Beispiel für das Erstellen einer Patch-Baseline und von Patch-Gruppen über die AWS Command Line Interface (AWS CLI) finden Sie unter [Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md). Weitere Informationen über Amazon-EC2-Tags finden Sie unter [Ihre Amazon-EC2-Ressourcen markieren](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) im *Amazon-EC2-Benutzerhandbuch*.
## Funktionsweise
Wenn das System eine Patch-Baseline auf einen verwalteten Knoten anwendet, überprüft SSM Agent, ob für den Knoten ein Patch-Gruppenwert definiert wurde. Wenn der Knoten einer Patch-Gruppe zugewiesen wurde, ermittelt Patch Manager anschließend, welche Patch-Baseline für diese Gruppe registriert wurde. Wenn für die Gruppe eine Patch-Baseline gefunden wird, weist Patch Manager SSM Agent an, die zugehörige Patch-Baseline zu verwenden. Wenn ein Knoten nicht für eine Patch-Gruppe konfiguriert wurde, weist Patch Manager SSM Agent automatisch an, die aktuell konfigurierte Standard-Patch-Baseline zu verwenden.
**Wichtig**
Ein verwalteter Knoten kann sich nur in einer Patch-Gruppe befinden.
Eine Patch-Gruppe kann nur für eine Patch-Baseline für jeden Betriebssystemtyp registriert werden.
Sie können das `Patch Group`-Tag (mit einem Leerzeichen) nicht auf eine Amazon-EC2-Instance anwenden, wenn die Option **Allow tags in instance metadata** (Tags in Instance-Metadaten zulassen) auf der Instance aktiviert ist. Durch das Zulassen von Tags in Instance-Metadaten wird verhindert, dass Tag-Schlüsselnamen Leerzeichen enthalten. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie den Tag-Schlüssel `PatchGroup` (ohne Leerzeichen) verwenden.
**Abbildung 1: Allgemeines Beispiel für den Prozessablauf beim Patch-Vorgang**
In der folgenden Abbildung sehen Sie ein allgemeines Beispiel der Prozesse, die Systems Manager beim Senden einer Run Command-Aufgabe an Ihre Serverflotte sendet, um mit Patch Manager Patches einzuspielen. Diese Prozesse bestimmen, welche Patch-Baselines für Patch-Vorgänge verwendet werden sollen. (Ein ähnlicher Prozess wird verwendet, wenn ein Wartungsfenster konfiguriert wurde, um einen Befehl zum Patchen mithilfe von Patch Manager zu senden.)
Der vollständige Vorgang wird unter der Abbildung erklärt.
![\[Patch Manager-Workflow zum Bestimmen, welche Patch-Baselines beim Ausführen von Patchvorgängen verwendet werden sollen.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/patch-groups-how-it-works.png)
In diesem Beispiel haben wir drei Gruppen von EC2-Instances für Windows Server mit den folgenden Tags:
****
| EC2-Instances-Gruppe | Tags |
| --- | --- |
| Gruppe 1 | `key=OS,value=Windows` `key=PatchGroup,value=DEV` |
| Gruppe 2 | `key=OS,value=Windows` |
| Gruppe 3 | `key=OS,value=Windows` `key=PatchGroup,value=QA` |
In diesem Beispiel haben wir außerdem diese beiden Windows Server-Patch-Baselines:
****
| Patch-Baseline-ID | Standard | Zugehörige Patch-Gruppe |
| --- | --- | --- |
| `pb-0123456789abcdef0` | Ja | `Default` |
| `pb-9876543210abcdef0` | Nein | `DEV` |
Der allgemeine Ablauf zum Scannen bzw. Installieren von Patches mit Run Command, einem Tool in AWS Systems Manager, und Patch Manager sieht wie folgt aus:
1. **Einen Patchbefehl senden**: Verwenden Sie die Systems Manager-Konsole, das SDK, die AWS Command Line Interface (AWS CLI) oder AWS Tools for Windows PowerShell zum Senden einer Run Command-Aufgabe mithilfe des Dokuments `AWS-RunPatchBaseline`. Die Abbildung zeigt eine Run Command-Aufgabe zum Patchen verwalteter Instances mit dem Tag `key=OS,value=Windows` als Ziel.
1. **Patch-Baseline bestimmen**: SSM Agent überprüft die auf die EC2-Instance angewendeten Patch-Gruppen-Tags und sendet eine Anfrage an Patch Manager für die entsprechende Patch-Baseline.
+ **Passender Patch-Gruppenwert einer Patch-Baseline zugeordnet:**
1. SSM Agent, das auf EC2-Instance in Gruppe 1 installiert ist, empfängt den in Schritt 1 gesendeten Befehl, mit dem Patchvorgang zu beginnen. SSM Agent überprüft, ob die EC2-Instances über den Patch-Gruppen-Tag-Wert `DEV` verfügen und sendet eine Anfrage an Patch Manager für die zugehörige Patch-Baseline.
1. Patch Manager überprüft, ob der Patch-Baseline `pb-9876543210abcdef0` die Patch-Gruppe `DEV` zugeordnet ist, und sendet eine Benachrichtigung an SSM Agent.
1. SSM Agent ruft basierend auf den in Patch Manager konfigurierten Genehmigungsregeln und Ausnahmen einen Snapshot der Patch-Baseline von `pb-9876543210abcdef0` ab und fährt mit dem nächsten Schritt fort.
+ **Instance verfügt nicht über ein Patch-Gruppen-Tag:**
1. SSM Agent, das auf EC2-Instance in Gruppe 2 installiert ist, empfängt den in Schritt 1 gesendeten Befehl, mit dem Patchvorgang zu beginnen. SSM Agent überprüft, ob die EC2-Instances nicht über das Patch-Gruppen-Tag `Patch Group` oder `PatchGroup` verfügen. SSM Agent sendet daraufhin eine Anfrage an Patch Manager für die Standard-Windows-Patch-Baseline.
1. Patch Manager überprüft, ob die Standard-Patch-Baseline für Windows Server `pb-0123456789abcdef0` ist, und benachrichtigt SSM Agent.
1. SSM Agent ruft basierend auf den in der Standard-Patch-Baseline Patch Manager konfigurierten Genehmigungsregeln und Ausnahmen einen Snapshot der Patch-Baseline von `pb-0123456789abcdef0` ab und fährt mit dem nächsten Schritt fort.
+ **Es gibt keinen passenden, einer Patch-Baseline zugeordneten Patch-Gruppenwert:**
1. SSM Agent, das auf EC2-Instance in Gruppe 3 installiert ist, empfängt den in Schritt 1 gesendeten Befehl, mit dem Patchvorgang zu beginnen. SSM Agent überprüft, ob die EC2-Instances über den Patch-Gruppen-Tag-Wert `QA` verfügen und sendet eine Anfrage an Patch Manager für die zugehörige Patch-Baseline.
1. Patch Manager findet keine Patch-Baseline mit der zugeordneten Patch-Gruppe `QA`.
1. Patch Manager benachrichtigt SSM Agent, die Standard-Patch-Baseline für Windows, `pb-0123456789abcdef0`, zu verwenden.
1. SSM Agent ruft basierend auf den in der Standard-Patch-Baseline Patch Manager konfigurierten Genehmigungsregeln und Ausnahmen einen Snapshot der Patch-Baseline von `pb-0123456789abcdef0` ab und fährt mit dem nächsten Schritt fort.
1. **Auf Patches scannen oder Patches installieren**: Nachdem die anzuwendende Patch-Baseline bestimmt wurde, beginnt SSM Agent basierend auf dem in Schritt 1 festgelegten Vorgangswert entweder damit, nach Patches zu scannen oder diese zu installieren. Nach welchen Patches gescannt bzw. welche Patches installiert werden, wird durch die Genehmigungsregeln und Patch-Ausnahmen bestimmt, die im von Patch Manager bereitgestellten Patch-Baseline-Snapshot definiert sind.
**Weitere Informationen**
+ [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md)
# Informationen zum Patchen von Anwendungen, die von Microsoft unter Windows Server veröffentlicht wurden
Verwenden Sie die Informationen in diesem Thema, um die Vorbereitung auf Patchanwendungen auf Windows Server mit Patch Manager, einem Tool in AWS Systems Manager, zu erleichtern.
**Patching von Microsoft-Anwendungen**
Patching-Support für Anwendungen auf von Windows Server verwalteten Knoten ist auf Anwendungen beschränkt, die von Microsoft veröffentlicht werden.
**Anmerkung**
In einigen Fällen veröffentlicht Microsoft Patches für Anwendungen, die kein aktualisiertes Datum und keine aktualisierte Uhrzeit angeben. In diesen Fällen wird ein aktualisiertes Datum und eine Uhrzeit von `01/01/1970` standardmäßig angegeben.
**Patch-Baselines, um von Microsoft veröffentlichte Anwendungen zu patchen**
Für Windows Server werden drei vordefinierte Patch-Baselines bereitgestellt. Die Patch-Baselines `AWS-DefaultPatchBaseline` und `AWS-WindowsPredefinedPatchBaseline-OS` unterstützen nur Betriebssystemupdates auf dem Windows-Betriebssystem selbst. `AWS-DefaultPatchBaseline` wird als Standard-Patch-Baseline für von Windows Server verwalteten Knoten verwendet, es sei denn, Sie geben eine andere Patch-Baseline an. Die Konfigurationseinstellungen in diesen beiden Patch-Baselines sind identisch. Die neuere der beiden, `AWS-WindowsPredefinedPatchBaseline-OS`, wurde erstellt, um sie von der dritten vordefinierten Patch-Baseline für Windows Server zu unterscheiden. Diese Patch-Baseline, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, kann verwendet werden, um Patches sowohl auf das Windows Server-Betriebssystem als auch auf unterstützte Anwendungen, die von Microsoft veröffentlicht wurden, anzuwenden.
Sie können zum Aktualisieren von Anwendungen, die von Microsoft veröffentlicht wurden, auf Windows Server-Computern auch benutzerdefinierte Patch-Baselines erstellen.
**Support für Patch-Anwendungen, die von Microsoft auf On-Premises-Servern, Edge-Geräten, VMs und anderen Nicht-EC2-Knoten veröffentlicht wurden**
Aktivieren Sie das Advanced-Instances-Kontingent, um Anwendungen, die von Microsoft auf virtuellen Maschinen (VMs) und anderen nicht EC2-verwalteten Knoten veröffentlicht wurden, zu patchen. Die Nutzung des Advanced-Instances-Kontingents ist kostenpflichtig. **Für Patch-Anwendungen, die von Microsoft auf Amazon Elastic Compute Cloud (Amazon EC2)-Instances veröffentlicht wurden, fallen jedoch keine zusätzlichen Gebühren an.** Weitere Informationen finden Sie unter [Konfigurieren von Instance-Kontingenten](fleet-manager-configure-instance-tiers.md).
**Windows-Update-Option für „andere Microsoft-Produkte“**
Damit Patch Manager von Microsoft auf Ihren von Windows Server verwalteten Knoten veröffentlichte Anwendungen patchen kann, muss die Windows-Update-Option **Ich möchte Updates für andere Microsoft-Produkte erhalten, wenn ich Windows aktualisiere** auf dem verwalteten Knoten aktiviert sein.
Informationen zum Zulassen dieser Option für einen einzelnen verwalteten Knoten finden Sie unter [Aktualisieren von Office mit Microsoft Update](https://support.microsoft.com/en-us/office/update-office-with-microsoft-update-f59d3f9d-bd5d-4d3b-a08e-1dd659cf5282) auf der Microsoft-Support-Website.
Bei einer Flotte von verwalteten Knoten auf Windows Server 2016 und höher können Sie die Einstellung mithilfe eines Group Policy Object (GPO, Gruppenrichtlinienobjekt) aktivieren. Navigieren Sie im Gruppenrichtlinien-Verwaltungseditor zu **Computer-Konfiguration**, **Administrative Vorlagen**, **Windows-Komponenten**, **Windows-Updates** und wählen Sie **Installieren von Updates für andere Microsoft-Produkte** aus. Wir empfehlen außerdem, das GPO mit zusätzlichen Parametern zu konfigurieren, die ungeplante automatische Updates und Neustarts außerhalb von Patch Manager verhindern. Weitere Informationen finden Sie unter [Konfigurieren automatischer Updates in einer Umgebung ohne Active Directory](https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127499) auf der Website für technische Dokumentation von Microsoft.
Bei einer Flotte von verwalteten Knoten, die auf Windows Server 2012 oder 2012 R2 ausgeführt werden, können Sie die Option mithilfe eines Skripts aktivieren, wie unter [Aktivieren und Deaktivieren von Microsoft Update in Windows 7 über Skript](https://docs.microsoft.com/en-us/archive/blogs/technet/danbuche/enabling-and-disabling-microsoft-update-in-windows-7-via-script) auf der Microsoft-Docs-Blog-Website beschrieben. Sie können z. B. Folgendes tun:
1. Speichern Sie das Skript aus dem Blogbeitrag in einer Datei.
1. Laden Sie die Datei in einen Amazon Simple Storage Service (Amazon S3)-Bucket oder an einem anderen zugänglichen Speicherort hoch.
1. Verwenden SieRun Command, ein Tool in AWS Systems Manager, um das Skript mithilfe des Systems Manager Manager-Dokuments (SSM-Dokument) `AWS-RunPowerShellScript` mit einem Befehl ähnlich dem folgenden auf Ihren verwalteten Knoten auszuführen.
```
Invoke-WebRequest `
-Uri "https://s3.aws-api-domain/amzn-s3-demo-bucket/script.vbs" `
-Outfile "C:\script.vbs" cscript c:\script.vbs
```
**Mindestparameteranforderungen**
Um von Microsoft veröffentlichte Anwendungen in Ihre benutzerdefinierte Patch-Baseline aufzunehmen, müssen Sie mindestens das Produkt angeben, das Sie patchen möchten. Der folgende Befehl AWS Command Line Interface (AWS CLI) veranschaulicht die Mindestanforderungen für das Patchen eines Produkts, z. B. 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}]"
```
------
Wenn Sie die Produktfamilie der Microsoft-Anwendung angeben, müssen alle Produkte der ausgewählten Produktfamilie unterstützt werden. Um beispielsweise das Produkt „Active Directory Rights Management Services Client 2.0“ zu patchen, müssen Sie dessen Produktfamilie als „Active Directory“ und nicht beispielsweise als „Office“ oder „SQL Server“ angeben. Der folgende AWS CLI Befehl demonstriert eine übereinstimmende Kombination von Produktfamilie und Produkt.
------
#### [ 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}]"
```
------
**Anmerkung**
Wenn Sie eine Fehlermeldung über eine nicht übereinstimmende Produkt- und Familienkopplung erhalten, finden Sie unter [Problem: Nicht übereinstimmende Produktpaare family/product](patch-manager-troubleshooting.md#patch-manager-troubleshooting-product-family-mismatch) Tipps zur Lösung des Problems.
# Verwenden von Kernel Live Patching auf von Amazon Linux 2 verwalteten Knoten
Kernel Live Patching für Amazon Linux 2 ermöglicht es Ihnen, Patches für Sicherheitsschwachstellen und kritische Fehler auf einen laufenden Linux-Kernel anzuwenden, ohne Neustarts oder Unterbrechungen der laufenden Anwendungen. Sie profitieren damit von einer verbesserten Service- und Anwendungsverfügbarkeit, gleichzeitig bleibt Ihre Infrastruktur sicher und auf dem neuesten Stand. Kernel Live Patching wird auf Amazon-EC2-Instances und AWS IoT Greengrass -Core-Geräten unterstützt sowie auf [virtuellen On-Premises-Maschinen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-2-virtual-machine.html), die auf Amazon Linux 2 ausgeführt werden.
Allgemeine Informationen zu Kernel Live Patching finden Sie unter [Kernel Live Patchingon AL2](https://docs.aws.amazon.com/linux/al2/ug/al2-live-patching.html) im *Amazon Linux 2-Benutzerhandbuch*.
Nachdem Sie Kernel Live Patching auf einem von Amazon Linux 2 verwalteten Knoten aktiviert haben, können Sie Patch Manager, ein Tool in AWS Systems Manager, verwenden, um Kernel-Live-Patches auf den verwalteten Knoten anzuwenden. Die Verwendung des Patch Manager ist eine Alternative zur Verwendung vorhandener Yum-Workflows auf dem Knoten, um die Updates anzuwenden.
**Bevor Sie beginnen**
Um mithilfe des Patch Manager Kernel-Live-Patches auf Ihre von Amazon Linux 2 verwalteten Knoten anzuwenden, stellen Sie sicher, dass Ihre Knoten auf der richtigen Architektur und Kernel-Version basieren. Weitere Informationen finden Sie unter [Unterstützte Konfigurationen und Voraussetzungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) im *Amazon-EC2-Benutzerhandbuch*.
**Topics**
+ [Kernel Live Patching mit Patch Manager verwenden](#about-klp)
+ [So funktioniert Patch Manager mit Kernel Live Patching](#how-klp-works)
+ [Aktivieren von Kernel Live Patching mit Run Command](enable-klp.md)
+ [Anwenden von Kernel-Live-Patches unter Verwendung von Run Command](install-klp.md)
+ [Deaktivieren von Kernel Live Patching mit Run Command](disable-klp.md)
## Kernel Live Patching mit Patch Manager verwenden
Aktualisieren der Kernel-Version
Sie müssen einen verwalteten Knoten nicht neu starten, nachdem Sie ein Kernel-Live-Patch-Update angewendet haben. AWS Stellt jedoch Kernel-Live-Patches für eine Amazon Linux 2-Kernelversion für bis zu drei Monate nach ihrer Veröffentlichung bereit. Nach Ablauf der dreimonatigen Frist müssen Sie auf eine spätere Kernel-Version aktualisieren, um weiterhin Kernel-Live-Patches zu erhalten. Wir empfehlen Ihnen, mithilfe eines Wartungsfensters mindestens einmal alle drei Monate einen Neustart Ihres Knoten zu planen, um das Update der Kernel-Version zu veranlassen.
Deinstallieren von Kernel-Live-Patches
Kernel-Live-Patches können nicht mit dem Patch Manager deinstalliert werden. Stattdessen können Sie Kernel Live Patching deaktivieren, wodurch die RPM-Pakete für die angewendeten Kernel-Live-Patches entfernt werden. Weitere Informationen finden Sie unter [Deaktivieren von Kernel Live Patching mit Run Command](disable-klp.md).
Kernel-Compliance
In einigen Fällen kann der Kernel durch die Installation aller CVE-Fixes von Live-Patches für die aktuelle Kernel-Version die Compliance-Ebene erreichen, die auch eine neuere Kernel-Version hätte. Wenn dies geschieht, wird die neuere Version als `Installed` und der verwaltete Knoten als `Compliant` gemeldet. Für die neuere Kernel-Version wird jedoch keine Installationszeit gemeldet.
Ein Kernel-Live-Patch, mehrere CVEs
Wenn ein Kernel-Live-Patch mehrere CVEs adressiert und diese unterschiedliche Klassifizierungs- und Schweregradwerte CVEs haben, CVEs wird für den Patch nur die höchste Klassifizierung und der höchste Schweregrad gemeldet.
Im weiteren Teil dieses Abschnitts wird erläutert, wie Patch Manager zum Anwenden von Kernel-Live-Patches auf verwaltete Knoten verwendet wird, die diese Anforderungen erfüllen.
## So funktioniert Patch Manager mit Kernel Live Patching
AWS veröffentlicht zwei Arten von Kernel-Live-Patches für Amazon Linux 2: Sicherheitsupdates und Bugfixes. Um diese Patch-Typen anzuwenden, verwenden Sie ein Patch-Baseline-Dokument, das nur auf die in der folgenden Tabelle aufgeführten Klassifizierungen und Schweregrade ausgerichtet ist.
| Klassifizierung | Schweregrad |
| --- | --- |
| Security | Critical, Important |
| Bugfix | All |
Sie können eine benutzerdefinierte Patch-Baseline erstellen, die nur auf diese Patches ausgerichtet ist, oder die vordefinierte Patch-Baseline `AWS-AmazonLinux2DefaultPatchBaseline` verwenden. Mit anderen Worten, Sie können `AWS-AmazonLinux2DefaultPatchBaseline` mit von Amazon Linux 2 verwalteten Knoten verwenden, auf denen Kernel Live Patching aktiviert ist, und es werden Kernel-Live-Updates angewendet.
**Anmerkung**
Die `AWS-AmazonLinux2DefaultPatchBaseline`-Konfiguration hat eine Wartezeit von sieben Tagen nach Veröffentlichung oder letzten Aktualisierung eines Patches, bevor er automatisch installiert wird. Wenn Sie nicht sieben Tage warten möchten, bis Kernel-Live-Patches automatisch genehmigt werden, können Sie eine benutzerdefinierte Patch-Baseline erstellen und verwenden. In der Patch-Baseline können Sie keine Wartezeit für automatische Genehmigung oder einen kürzeren oder längeren Zeitraum angeben. Weitere Informationen finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).
Wir empfehlen die folgende Strategie zum Patchen Ihrer verwalteten Knoten mit Kernel-Live-Updates:
1. Aktivieren Sie Kernel Live Patching auf Ihren von Amazon Linux 2 verwalteten Knoten.
1. Verwenden SieRun Command, ein Tool in AWS Systems Manager, um einen `Scan` Vorgang auf Ihren verwalteten Knoten unter Verwendung der vordefinierten `AWS-AmazonLinux2DefaultPatchBaseline` oder einer benutzerdefinierten Patch-Baseline auszuführen, die auch nur auf `Security` Updates abzielt, deren Schweregrad als `Critical` und und eingestuft ist`Important`, und dem `Bugfix` Schweregrad von`All`.
1. Verwenden Sie Compliance, ein Tool in AWS Systems Manager, um zu überprüfen, ob für einen der verwalteten Knoten, die gescannt wurden, Verstöße wegen Patches gemeldet wurden. Wenn dies der Fall ist, zeigen Sie die Compliance-Details für den Knoten an, um festzustellen, ob Kernel-Live-Patches im verwalteten Knoten fehlen.
1. Um fehlende Kernel-Live-Patches zu installieren, verwenden Sie Run Command mit derselben Patch-Baseline, die Sie zuvor angegeben haben, führen Sie dieses Mal jedoch eine `Install`-Operation anstelle einer `Scan`-Operation aus.
Da Kernel-Live-Patches installiert werden, ohne dass ein Neustart erforderlich ist, können Sie die Neustartoption `NoReboot` für diese Operation auswählen.
**Anmerkung**
Sie können den verwalteten Knoten dennoch neu starten, wenn dies für andere auf dem Knoten installierte Patch-Typen erforderlich ist oder wenn Sie auf einen neueren Kernel aktualisieren möchten. Wählen Sie in diesen Fällen stattdessen die Neustartoption `RebootIfNeeded` aus.
1. Kehren Sie zu Compliance zurück, um zu überprüfen, ob die Kernel-Live-Patches installiert wurden.
# Aktivieren von Kernel Live Patching mit Run Command
Um Kernel Live Patching zu aktivieren, können Sie entweder `yum`-Befehle auf Ihren verwalteten Knoten ausführen oder Run Command und ein benutzerdefiniertes Systems-Manager-Dokument (SSM-Dokument) verwenden, das Sie erstellen.
Weitere Informationen zum Aktivieren von Kernel Live Patching durch Ausführen von `yum`-Befehlen direkt auf dem verwalteten Knoten finden Sie unter [Aktivieren von Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-prereq) im *Benutzerhandbuch zu Amazon EC2*.
**Anmerkung**
Wenn Sie Kernel-Live-Patching aktivieren und der bereits auf dem verwalteten Knoten ausgeführte Kernel eine *frühere* Version als `kernel-4.14.165-131.185.amzn2.x86_64` (die unterstützte Mindestversion) ist, installiert der Prozess die neueste verfügbare Kernel-Version und startet den verwalteten Knoten neu. Wenn der Knoten bereits `kernel-4.14.165-131.185.amzn2.x86_64` oder höher ausführt, installiert der Prozess keine neuere Version und startet den Knoten nicht neu.
**So aktivieren Sie Kernel Live Patching mit Run Command (Konsole)**
1. Öffnen Sie die AWS Systems Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste **Command document (Befehlsdokument)** das benutzerdefinierte SSM-Dokument `AWS-ConfigureKernelLivePatching` aus.
1. Geben Sie im Abschnitt **Command parameters** (Befehlsparameter) an, ob verwaltete Knoten als Teil dieser Operation neu gestartet werden sollen.
1. Weitere Informationen zur Verwendung der übrigen Steuerelemente auf dieser Seite finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).
1. Wählen Sie **Ausführen** aus.
**Aktivieren von Kernel Live Patching (AWS CLI)**
+ Führen Sie den folgenden Befehl auf Ihrem lokalen Computer aus.
------
#### [ 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"
```
------
Ersetzen Sie *instance-id* durch die ID des von Amazon Linux 2 verwalteten Knoten, auf dem Sie das Feature aktivieren möchten, beispielsweise i-02573cafcfEXAMPLE. Um das Feature auf mehreren verwalteten Knoten zu aktivieren, können Sie eines der folgenden Formate verwenden.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Informationen über andere Optionen, die Sie in dem Befehl verwenden können, finden Sie im Abschnitt [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in der *AWS CLI-Befehlsreferenz*.
# Anwenden von Kernel-Live-Patches unter Verwendung von Run Command
Um Kernel-Live-Patches anzuwenden, können Sie entweder `yum`-Befehle auf Ihren verwalteten Knoten ausführen oder Run Command und das SSM-Dokument `AWS-RunPatchBaseline` verwenden.
Weitere Informationen zum Anwenden von Kernel-Live-Patches durch Ausführung von `yum`-Befehlen direkt auf dem verwalteten Knoten finden Sie unter [Anwenden von Kernel-Live-Patches](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-apply) im *Benutzerhandbuch zu Amazon EC2*.
**So wenden Sie Kernel-Live-Patches unter Verwendung von Run Command an (Konsole)**
1. Öffnen Sie die AWS Systems Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste **Command document (Befehlsdokument)** das SSM-Dokument `AWS-RunPatchBaseline` aus.
1. Führen Sie im Abschnitt **Command parameters (Befehlsparameter)** einen der folgenden Schritte aus:
+ Wenn Sie prüfen, ob neue Kernel-Live-Patches verfügbar sind, wählen Sie für **Operation** die Option `Scan` aus. Wenn Ihre verwalteten Knoten nach dieser Operation nicht neu gestartet werden sollen, wählen Sie für **Reboot Option** (Neustartoption) `NoReboot` aus. Nach Abschluss der Operation können Sie in Compliance prüfen, ob neue Patches vorhanden sind und wie der Compliance-Status lautet.
+ Wenn Sie die Patch-Compliance bereits überprüft haben und bereit sind, verfügbare Kernel-Live-Patches anzuwenden, wählen Sie für **Operation** die Option `Install` aus. Wenn Ihre verwalteten Knoten nach dieser Operation nicht neu gestartet werden sollen, wählen Sie für **Reboot Option** (Neustartoption) `NoReboot` aus.
1. Weitere Informationen zur Verwendung der übrigen Steuerelemente auf dieser Seite finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).
1. Wählen Sie **Ausführen** aus.
**So wenden Sie Kernel-Live-Patches unter Verwendung von Run Command an (AWS CLI)**
1. Führen Sie den folgenden Befehl von Ihrem lokalen Computer aus, um eine `Scan`-Operation auszuführen, bevor Sie Ihre Ergebnisse in Compliance überprüfen.
------
#### [ 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\"]}
```
------
Informationen über andere Optionen, die Sie in dem Befehl verwenden können, finden Sie im Abschnitt [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in der *AWS CLI-Befehlsreferenz*.
1. Führen Sie den folgenden Befehl von Ihrem lokalen Computer aus, um eine `Install`-Operation auszuführen, nachdem Sie die Ergebnisse in Compliance überprüft haben.
------
#### [ 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\"]}
```
------
Ersetzen Sie in den beiden vorangegangenen Befehlen *instance-id* durch die ID des von Amazon Linux 2 verwalteten Knoten, auf dem Sie Kernel-Live-Patches anwenden möchten, beispielsweise i-02573cafcfEXAMPLE. Um das Feature auf mehreren verwalteten Knoten zu aktivieren, können Sie eines der folgenden Formate verwenden.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Informationen über andere Optionen, die Sie in diesen Befehlen verwenden können, finden Sie im Abschnitt [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in der *AWS CLI-Befehlsreferenz*.
# Deaktivieren von Kernel Live Patching mit Run Command
Um Kernel Live Patching zu deaktivieren, können Sie entweder `yum`-Befehle auf Ihren verwalteten Knoten ausführen oder Run Command und das benutzerdefinierte SSM-Dokument `AWS-ConfigureKernelLivePatching`.
**Anmerkung**
Wenn Sie das Kernel-Live-Patching nicht mehr verwenden möchten, können Sie es jederzeit deaktivieren. In den meisten Fällen ist das Deaktivieren des Features nicht erforderlich.
Weitere Informationen zum Deaktivieren von Kernel Live Patching durch Ausführen von `yum`-Befehlen direkt auf dem verwalteten Knoten finden Sie unter [Aktivieren von Kernel Live Patching](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/al2-live-patching.html#al2-live-patching-enable) im *Benutzerhandbuch zu Amazon EC2*.
**Anmerkung**
Wenn Sie Kernel Live Patching deaktivieren, deinstalliert der Prozess das Kernel Live Patching-Plugin und startet dann den verwalteten Knoten neu.
**Deaktivieren von Kernel Live Patching mit Run Command (Konsole)**
1. Öffnen Sie die AWS Systems Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste **Command document (Befehlsdokument)** das SSM-Dokument `AWS-ConfigureKernelLivePatching` aus.
1. Geben Sie im Abschnitt **Befehlsparameter** Werte für erforderliche Parameter an.
1. Weitere Informationen zur Verwendung der übrigen Steuerelemente auf dieser Seite finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).
1. Wählen Sie **Ausführen** aus.
**Deaktivieren von Kernel Live Patching (AWS CLI)**
+ Verwenden Sie einen Befehl ähnlich dem folgenden:
------
#### [ 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"
```
------
Ersetzen Sie *instance-id* durch die ID des von Amazon Linux 2 verwalteten Knoten, auf dem Sie das Feature deaktivieren möchten, beispielsweise i-02573cafcfEXAMPLE. Um das Feature auf mehreren verwalteten Knoten zu deaktivieren, können Sie eines der folgenden Formate verwenden.
+ `--targets "Key=instanceids,Values=instance-id1,instance-id2"`
+ `--targets "Key=tag:tag-key,Values=tag-value"`
Informationen über andere Optionen, die Sie in dem Befehl verwenden können, finden Sie im Abschnitt [https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/send-command.html) in der *AWS CLI-Befehlsreferenz*.
# Arbeiten mit Patch Manager-Ressourcen und Compliance mithilfe der Konsole
Um ein Tool in zu verwenden Patch Manager AWS Systems Manager, führen Sie die folgenden Aufgaben aus. Diese Aufgaben werden später in diesem Abschnitt ausführlich erläutert.
1. Stellen Sie sicher, dass die AWS vordefinierte Patch-Baseline für jeden von Ihnen verwendeten Betriebssystemtyp Ihren Anforderungen entspricht. Ist dies nicht der Fall, sollten Sie eine Patch-Baseline erstellen, in der Standard-Patches für diesen Typ von verwalteten Knoten definiert sind, und diese als Standard-Patch-Baseline festlegen.
1. Organisieren Sie verwaltete Knoten mithilfe von Amazon Elastic Compute Cloud (Amazon EC2)-Tags in Patch-Gruppen (optional, aber empfohlen).
1. Führen Sie eine der folgenden Aktionen aus:
+ (Empfohlen) Konfigurieren Sie eine Patch-Richtlinie in Quick Setup, einem Tool in Systems Manager, mit dem Sie fehlende Patches nach einem Zeitplan für eine gesamte Organisation, eine Teilmenge von Organisationseinheiten oder ein einzelnes AWS-Konto installieren können. Weitere Informationen finden Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md).
+ Erstellen Sie ein Wartungsfenster, das das Systems Manager-Dokument (SSM-Dokument) `AWS-RunPatchBaseline` in einem Run Command-Aufgabentyp verwendet. Weitere Informationen finden Sie unter [Tutorial: Erstellen Sie ein Wartungsfenster zum Patchen über die Konsole](maintenance-window-tutorial-patching.md).
+ Führen Sie `AWS-RunPatchBaseline` manuell in einer Run Command-Operation aus. Weitere Informationen finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).
+ Patchen Sie Knoten bei Bedarf manuell mit der Funktion **Patch now** (Jetzt patchen). Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).
1. Überwachen Sie das Patching, um die Compliance zu überprüfen und Fehler zu untersuchen.
**Topics**
+ [Erstellen einer Patch-Richtlinie](patch-manager-create-a-patch-policy.md)
+ [Patch-Dashboard-Zusammenfassungen anzeigen](patch-manager-view-dashboard-summaries.md)
+ [Arbeiten mit Patch-Compliance-Berichten](patch-manager-compliance-reports.md)
+ [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md)
+ [Arbeiten mit Patch-Baselines](patch-manager-create-a-patch-baseline.md)
+ [Anzeigen verfügbarer Patches](patch-manager-view-available-patches.md)
+ [Erstellen und Verwalten von Patch-Gruppen](patch-manager-tag-a-patch-group.md)
+ [Integrieren Patch Manager mit AWS Security Hub CSPM](patch-manager-security-hub-integration.md)
# Erstellen einer Patch-Richtlinie
Eine Patch-Richtlinie ist eine Konfiguration, die Sie mit Quick Setup, einem Tool in AWS Systems Manager, einrichten. Patch-Richtlinien bieten eine umfassendere und zentralisiertere Kontrolle über Ihre Patching-Vorgänge, als dies mit anderen Methoden zum Konfigurieren von Patches möglich ist. Eine Patch-Richtlinie definiert den Zeitplan und die Baseline, die beim automatischen Patchen Ihrer Knoten und Anwendungen verwendet werden sollen.
Weitere Informationen finden Sie unter den folgenden Themen:
+ [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md)
+ [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md)
# Patch-Dashboard-Zusammenfassungen anzeigen
Die **Dashboard**-Registerkarte in Patch Manager bietet eine Übersicht über die Konsole, die Sie verwenden können, um Ihre Patch-Vorgänge in einer konsolidierten Ansicht zu überwachen. Patch Manager ist ein Tool in AWS Systems Manager. Auf der Registerkarte **Dashboard** können Sie folgenden Tabellen anzeigen:
+ Ein Snapshot, wie viele verwaltete Knoten mit Patching-Regeln konform bzw. nicht konform sind.
+ Ein Snapshot des Alters der Patch-Compliance-Ergebnisse für Ihre verwalteten Knoten.
+ Eine verknüpfte Anzahl davon, wie viele nicht konforme verwaltete Knoten für jeden der häufigsten Gründe für Nicht-Compliance vorhanden sind.
+ Eine verknüpfte Liste der letzten Patching-Vorgänge.
+ Eine verknüpfte Liste der wiederkehrenden Patching-Vorgänge, die eingerichtet wurden.
**So zeigen Sie Patch-Dashboard-Übersichten**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Dashboard** aus.
1. Scrollen Sie zu dem Abschnitt mit zusammenfassenden Daten, den Sie anzeigen möchten:
+ **Amazon-EC2-Instance-Management**
+ **Zusammenfassung der Compliance**
+ **Anzahl der Nichteinhaltungen der Compliance**
+ **Compliance-Berichte**
+ **Nicht auf Patch-Richtlinien basierende Vorgänge**
+ **Wiederkehrende Aufgaben, die nicht auf Patch-Richtlinien basieren**
# Arbeiten mit Patch-Compliance-Berichten
Die Informationen in den folgenden Themen helfen Ihnen beim Erstellen von und Arbeiten mit Patch-Compliance-Berichten in Patch Manager, einem Tool in AWS Systems Manager.
Die Informationen in den folgenden Themen gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihre Patching-Vorgänge verwenden:
+ Eine in Quick Setup konfigurierte Patch-Richtlinie
+ Eine in Quick Setup konfigurierte Host-Management-Option
+ Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
+ Ein On-Demand-**Jetzt patchen**-Vorgang
**Wichtig**
Patch-Compliance-Berichte sind point-in-time Schnappschüsse, die nur bei erfolgreichen Patch-Vorgängen generiert werden. Jeder Bericht enthält eine Erfassungszeit, aus der hervorgeht, wann der Compliance-Status berechnet wurde.
Wenn Sie mehrere Arten von Vorgängen einsetzen, um Ihre Instances auf Patch-Compliance zu überprüfen, beachten Sie, dass jeder Scan die Patch-Compliance-Daten der vorherigen Scans überschreibt. Dies kann zu unerwarteten Ergebnissen in Ihren Patch-Compliance-Daten führen. Weitere Informationen finden Sie unter [Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat](patch-manager-compliance-data-overwrites.md).
Um zu überprüfen, welche Patch-Baseline verwendet wurde, um die neuesten Compliance-Informationen zu generieren, navigieren Sie zur Registerkarte **Compliance-Berichte** in Patch Manager, suchen Sie die Zeile für den verwalteten Knoten, zu dem Sie Informationen wünschen, und wählen Sie dann die Baseline-ID in der Spalte **Verwendete Baseline-ID** aus.
**Topics**
+ [Anzeigen der Patch-Compliance-Ergebnisse](patch-manager-view-compliance-results.md)
+ [Generieren von Patch-Compliance-Berichten im .csv-Format](patch-manager-store-compliance-results-in-s3.md)
+ [Behebung nicht konformer verwalteter Knoten mit Patch Manager](patch-manager-noncompliant-nodes.md)
+ [Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat](patch-manager-compliance-data-overwrites.md)
# Anzeigen der Patch-Compliance-Ergebnisse
Gehen Sie wie folgt vor, um Patch-Compliance-Informationen zu Ihren verwalteten Knoten anzuzeigen.
Dieses Verfahren gilt für Patchvorgänge, die das `AWS-RunPatchBaseline`-Dokument verwenden. Weitere Informationen zum Anzeigen von Patch-Compliance-Informationen für Patch-Operationen, die das `AWS-RunPatchBaselineAssociation`-Dokument verwenden, finden Sie unter [Identifizieren von nicht konformen verwalteten Knoten](patch-manager-find-noncompliant-nodes.md).
**Anmerkung**
Die Patchscanvorgänge für das Dokument Quick Setup und die Explorer Verwendung des `AWS-RunPatchBaselineAssociation` Dokuments. Quick Setupund Explorer sind beide Tools in AWS Systems Manager.
**Identifizieren der Patch-Lösung für ein bestimmtes CVE-Problem (Linux)**
Für viele Linux-basierte Betriebssysteme geben die Patch-Compliance-Ergebnisse an, welche CVE (Common Vulnerabilities and Exposure) Bulletin-Probleme durch welche Patches behoben werden. Mithilfe dieser Informationen können Sie feststellen, wie dringend Sie einen fehlenden oder fehlgeschlagenen Patch installieren müssen.
CVE-Details sind für unterstützte Versionen der folgenden Betriebssystemtypen enthalten:
+ AlmaLinux
+ Amazon Linux 2
+ Amazon Linux 2023
+ Oracle Linux
+ Red Hat Enterprise Linux (RHEL)
+ Rocky Linux
**Anmerkung**
Standardmäßig stellt CentOS Stream keine CVE-Informationen zu Updates bereit. Sie können diese Unterstützung jedoch zulassen, indem Sie Repositorys von Drittanbietern wie das EPEL-Repository (EPEL), das von Fedora veröffentlicht wurde, verwenden. Weitere Informationen finden Sie unter [EPEL](https://fedoraproject.org/wiki/EPEL) im Fedora-Wiki.
Derzeit werden CVE-ID-Werte nur für Patches mit dem Status `Missing` oder `Failed` gemeldet.
Sie können CVE auch IDs zu Ihren Listen mit genehmigten oder abgelehnten Patches in Ihren Patch-Baselines hinzufügen, je nachdem, was die Situation und Ihre Patch-Ziele erfordern.
Weitere Informationen zum Arbeiten mit genehmigten und abgelehnten Patch-Listen finden Sie in den folgenden Themen:
+ [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md)
+ [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md)
+ [Funktionsweise von Patch-Baseline-Regeln auf Linux-basierten Systemen](patch-manager-linux-rules.md)
+ [Wie Patches installiert werden](patch-manager-installing-patches.md)
**Anmerkung**
In einigen Fällen veröffentlicht Microsoft Patches für Anwendungen, die kein aktualisiertes Datum und keine aktualisierte Uhrzeit angeben. In diesen Fällen wird ein aktualisiertes Datum und eine Uhrzeit von `01/01/1970` standardmäßig angegeben.
## Anzeigen der Patch-Compliance-Ergebnisse
Verwenden Sie die folgenden Verfahren, um Patch-Compliance-Ergebnisse in der AWS Systems Manager -Konsole anzuzeigen.
**Anmerkung**
Weitere Informationen zum Erstellen von Patch-Compliance-Berichten, die in einen Amazon Simple Storage Service (Amazon S3)-Bucket heruntergeladen werden, finden Sie unter [Generieren von Patch-Compliance-Berichten im .csv-Format](patch-manager-store-compliance-results-in-s3.md).
**Anzeigen der Patch-Compliance-Ergebnisse**
1. Führen Sie eine der folgenden Aufgaben aus.
**Option 1** (empfohlen) – Navigieren Sie von Patch Manager, einem Tool in AWS Systems Manager:
+ Wählen Sie im Navigationsbereich **Patch Manager** aus.
+ Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte).
+ Wählen Sie im Bereich **Details zum Knoten-Patching** die Knoten-ID des verwalteten Knotens aus, für den Sie die Ergebnisse der Patch-Compliance überprüfen möchten. Knoten, die hier angezeigt werden `stopped` oder nicht `terminated` angezeigt werden.
+ Wählen Sie im Bereich **Details** in der **Eigenschaftenliste** die Option **Patches** aus.
**Option 2** – Navigieren Sie ab Compliance, einem Tool in AWS Systems Manager:
+ Wählen Sie im linken Navigationsbereich **Compliance**.
+ Für **Zusammenfassung von Compliance-Ressourcen** wählen Sie in der Spalte für die Typen von Patch-Ressourcen, die Sie überprüfen möchten, z. B. **Nicht regelkonforme Ressourcen**, eine Zahl aus.
+ In der **Ressourcen**-Liste unten wählen Sie die ID des verwalteten Knoten aus, für den Sie die Patch-Compliance-Ergebnisse prüfen möchten.
+ Wählen Sie im Bereich **Details** in der **Eigenschaftenliste** die Option **Patches** aus.
**Option 3** – Navigieren Sie von Fleet Manager, einem Tool in AWS Systems Manager.
+ Wählen Sie im Navigationsbereich **Fleet Manager** aus.
+ Wählen Sie im Bereich **Verwaltete instances** die ID des verwalteten Knotens aus, für den Sie die Ergebnisse der Patch-Compliance überprüfen möchten.
+ Wählen Sie im Bereich **Details** in der **Eigenschaftenliste** die Option **Patches** aus.
1. (Optional) Wählen Sie im Suchfeld (![\[The Search icon\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/search-icon.png)) einen der verfügbaren Filter aus.
Wählen Sie zum Beispiel für Red Hat Enterprise Linux (RHEL) aus den folgenden Optionen aus:
+ Name
+ Klassifizierung
+ Status
+ Schweregrad
Wählen Sie für Windows Server eine der folgenden Optionen aus:
+ KB
+ Klassifizierung
+ Status
+ Schweregrad
1. Wählen Sie einen der verfügbaren Werte für den ausgewählten Filtertyp aus. Wenn Sie beispielsweise „**Status**“ ausgewählt haben, wählen Sie jetzt einen Konformitätsstatus wie **InstalledPendingReboot**„**Fehlgeschlagen**“ oder „**Fehlt“**.
**Anmerkung**
Derzeit werden CVE-ID-Werte nur für Patches mit dem Status `Missing` oder `Failed` gemeldet.
1. Abhängig vom Compliance-Zustand des verwalteten Knoten können Sie auswählen, welche Maßnahmen zum Beheben von nicht konformen Knoten ergriffen werden sollen.
Sie können beispielsweise wählen, dass Ihre nicht konformen verwalteten Knoten sofort gepatcht werden sollen. Informationen zum On-Demand-Patching Ihrer verwalteten Knoten finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).
Weitere Informationen zu Patch-Compliance-Status finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md).
# Generieren von Patch-Compliance-Berichten im .csv-Format
Sie können die AWS Systems Manager Konsole verwenden, um Patch-Compliance-Berichte zu erstellen, die als CSV-Datei in einem Amazon Simple Storage Service (Amazon S3) -Bucket Ihrer Wahl gespeichert werden. Sie können einen einzelnen On-Demand-Bericht erstellen oder einen Zeitplan für die automatische Generierung der Berichte angeben.
Berichte können für einen einzelnen verwalteten Knoten oder für alle verwalteten Knoten in Ihrem ausgewählten AWS-Konto und AWS-Region generiert werden. Für einen einzelnen Knoten enthält ein Bericht umfassende Details, einschließlich der Patches, die IDs sich auf die Nichtkonformität eines Knotens beziehen. Für einen Bericht über alle verwaltete Knoten werden nur zusammenfassende Informationen und die Anzahl der Patches von nicht konformen Knoten bereitgestellt.
Nachdem ein Bericht generiert wurde, können Sie ein Tool wie Amazon Quick verwenden, um die Daten zu importieren und zu analysieren. Quick ist ein Business Intelligence (BI) -Service, mit dem Sie Informationen in einer interaktiven visuellen Umgebung untersuchen und interpretieren können. Weitere Informationen finden Sie in der [Amazon-Kurzanleitung](https://docs.aws.amazon.com/quicksuite/latest/userguide/what-is.html).
**Anmerkung**
Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für Patches, die von dieser Patch-Baseline genehmigt wurden, einen Schweregrad für die Konformität angeben, beispielsweise `Critical` oder `High`. Wenn der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann ist der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline der von Ihnen angegebene Schweregrad.
Sie können auch ein Thema zum Amazon Simple Notification Service (Amazon SNS) angeben, um Benachrichtigungen zu senden, wenn ein Bericht erstellt wird.
**Servicerollen zum Generieren von Patch-Compliance-Berichten**
Wenn Sie zum ersten Mal einen Bericht erstellen, erstellt Systems Manager eine angenommene Automatisierungsrolle mit dem Namen `AWS-SystemsManager-PatchSummaryExportRole`, die für den Exportprozess zu S3 verwendet wird.
**Anmerkung**
Wenn Sie Compliance-Daten in einen verschlüsselten S3-Bucket exportieren, müssen Sie die zugehörige AWS KMS Schlüsselrichtlinie aktualisieren, um die erforderlichen Berechtigungen für bereitzustellen`AWS-SystemsManager-PatchSummaryExportRole`. Fügen Sie beispielsweise der AWS KMS Richtlinie Ihres S3-Buckets eine ähnliche Berechtigung hinzu:
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "role-arn"
}
```
*role-arn*Ersetzen Sie es durch den Amazon-Ressourcennamen (ARN) der in Ihrem Konto erstellten Datei im Format`arn:aws:iam::111222333444:role/service-role/AWS-SystemsManager-PatchSummaryExportRole`.
Weitere Informationen finden Sie unter [Schlüsselrichtlinien in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) im *Entwicklerhandbuch für AWS Key Management Service *.
Wenn Sie zum ersten Mal einen Bericht nach einem Zeitplan generieren, erstellt Systems Manager eine weitere Servicerolle mit dem Namen `AWS-EventBridge-Start-SSMAutomationRole` zusammen mit der Servicerolle `AWS-SystemsManager-PatchSummaryExportRole` (falls nicht bereits erstellt), die für den Exportvorgang verwendet werden soll. `AWS-EventBridge-Start-SSMAutomationRole`ermöglicht Amazon EventBridge , eine Automatisierung mit dem Runbook [AWS ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3) zu starten.
Es wird empfohlen, diese Richtlinien und Rollen zu ändern. Dies kann dazu führen, dass die Erstellung von Patch-Compliance-Berichten fehlschlägt. Weitere Informationen finden Sie unter [Problembehandlung bei der Erstellung von Patch-Compliance-Berichten](#patch-compliance-reports-troubleshooting).
**Topics**
+ [Was ist in einem generierten Patch-Compliance-Bericht enthalten?](#patch-compliance-reports-to-s3-examples)
+ [Generieren von Patch-Compliance-Berichten für einen einzelnen verwalteten Knoten](#patch-compliance-reports-to-s3-one-instance)
+ [Generieren von Patch-Compliance-Berichten für alle verwaltete Knoten](#patch-compliance-reports-to-s3-all-instances)
+ [Berichtsverlauf für Patch-Compliance anzeigen](#patch-compliance-reporting-history)
+ [Zeitpläne für Patch-Compliance-Berichte anzeigen](#patch-compliance-reporting-schedules)
+ [Problembehandlung bei der Erstellung von Patch-Compliance-Berichten](#patch-compliance-reports-troubleshooting)
## Was ist in einem generierten Patch-Compliance-Bericht enthalten?
Dieses Thema enthält Informationen zu den Inhaltstypen, die in den Patch-Compliance-Berichten enthalten sind, die generiert und in einen angegebenen S3-Bucket heruntergeladen werden.
### Berichtsformat für einen einzelnen verwalteten Knoten
Ein für einen einzelnen verwalteten Knoten generierter Bericht liefert sowohl zusammenfassende als auch detaillierte Informationen.
[Herunterladen eines Beispielberichts (einzelner Knoten)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-single-instance-patch-compliance-report.zip)
Zu den zusammenfassenden Informationen für einen einzelnen verwalteten Knoten gehört Folgendes:
+ Index
+ Instance-ID
+ Instance name
+ Instance IP
+ Plattformname
+ Version der Plattform
+ SSM Agent-Version
+ Patch-Baseline
+ Patch-Gruppe
+ Compliance status (Compliance-Status)
+ Compliance-Schweregrad
+ Anzahl nicht konformer Patches mit kritischem Schweregrad
+ Anzahl nicht konformer Patches mit hohem Schweregrad
+ Anzahl nicht konformer Patches mit der Schweregrad Mittel
+ Anzahl nicht konformer Patches mit niedrigem Schweregrad
+ Anzahl nicht konformer Patches mit informativen Schweregrad
+ Anzahl nicht konformer Patches mit nicht spezifiziertem Schweregrad
Zu den detaillierten Informationen für einen verwalteten einzelnen Knoten gehört Folgendes:
+ Index
+ Instance-ID
+ Instance name
+ Patch-Name
+ ID/Patch KB-ID
+ Patch-Status
+ Zeitpunkt des letzten Berichts
+ Compliance-Stufe
+ Patch-Schweregrad
+ Patch-Klassifizierung
+ CVE-ID
+ Patch-Baseline
+ Logs-URL
+ Instance IP
+ Plattformname
+ Version der Plattform
+ SSM Agent-Version
**Anmerkung**
Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie für Patches, die von dieser Patch-Baseline genehmigt wurden, einen Schweregrad für die Konformität angeben, beispielsweise `Critical` oder `High`. Wenn der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann ist der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline der von Ihnen angegebene Schweregrad.
### Berichtsformat für alle verwaltete Knoten
Ein für alle verwaltete Knoten generierter Bericht enthält nur zusammenfassende Informationen.
[Herunterladen eines Beispielberichts (alle verwaltete Knoten)](https://docs.aws.amazon.com/systems-manager/latest/userguide/samples/Sample-all-instances-patch-compliance-report.zip)
Zu den zusammenfassenden Informationen für alle verwaltete Knoten gehört Folgendes:
+ Index
+ Instance-ID
+ Instance name
+ Instance IP
+ Plattformname
+ Version der Plattform
+ SSM Agent-Version
+ Patch-Baseline
+ Patch-Gruppe
+ Compliance status (Compliance-Status)
+ Compliance-Schweregrad
+ Anzahl nicht konformer Patches mit kritischem Schweregrad
+ Anzahl nicht konformer Patches mit hohem Schweregrad
+ Anzahl nicht konformer Patches mit der Schweregrad Mittel
+ Anzahl nicht konformer Patches mit niedrigem Schweregrad
+ Anzahl nicht konformer Patches mit informativen Schweregrad
+ Anzahl nicht konformer Patches mit nicht spezifiziertem Schweregrad
## Generieren von Patch-Compliance-Berichten für einen einzelnen verwalteten Knoten
Gehen Sie wie folgt vor, um einen Patch-Zusammenfassungs-Bericht für einen einzelnen verwalteten Knoten in Ihrem AWS-Konto zu generieren. Der Bericht für einen einzelnen verwalteten Knoten enthält Details zu jedem Patch, der nicht konform ist, einschließlich Patch-Namen und IDs.
**So generieren Sie Patch-Compliance-Berichte für einen einzelnen verwalteten Knoten**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte) aus.
1. Wählen Sie die Schaltfläche für die Zeile des verwalteten Knoten aus, für den Sie einen Bericht erstellen möchten, und wählen Sie dann **View detail** (Detail anzeigen) aus.
1. Wählen Sie Abschnitt mit der **Patch-Zusammenfassung** **Exportieren nach S3** aus.
1. Für **Berichtname** geben Sie einen Namen ein, damit Sie den Bericht später leichter identifizieren können.
1. Für **Meldehäufigkeit** wählen Sie eine der folgenden Optionen aus:
+ **On Demand** – Erstellen Sie einen einmaligen Bericht. Fahren Sie mit Schritt 9 fort.
+ **Nach einem Plan** – Geben Sie einen wiederkehrenden Zeitplan für die automatische Erstellung von Berichten an. Fahren Sie fort mit Schritt 8.
1. Für den **Typ „Nach einem Plan“** geben Sie entweder einen Kursausdruck an, z. B. alle 3 Tage, oder geben Sie einen Cron-Ausdruck an, um die Berichtshäufigkeit festzulegen.
Informationen zu Cron-Ausdrücken finden Sie unter [Referenz: Cron- und Rate-Ausdrücke für System Manager](reference-cron-and-rate-expressions.md).
1. Für **Bucket-Name** wählen Sie den Namen eines S3-Buckets aus, in dem die CSV-Berichtsdateien gespeichert werden sollen.
**Wichtig**
Wenn Sie in einem System arbeiten AWS-Region , das nach dem 20. März 2019 gestartet wurde, müssen Sie einen S3-Bucket in derselben Region auswählen. Nach diesem Datum gestartete Regionen wurden standardmäßig deaktiviert. Weitere Informationen und eine Liste dieser Regionen finden Sie unter [Aktivieren einer Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) in der *Allgemeine Amazon Web Services-Referenz*.
1. (Optional) Um Benachrichtigungen zu senden, wenn der Bericht erstellt wird, erweitern Sie den Abschnitt **SNS-Thema** und wählen Sie dann aus **SNS-Thema Amazon-Ressourcenname (ARN)** ein vorhandenes Amazon-SNS-Thema aus.
1. Wählen Sie **Absenden** aus.
Informationen zum Anzeigen eines Verlaufs von generierten Berichten finden Sie unter [Berichtsverlauf für Patch-Compliance anzeigen](#patch-compliance-reporting-history).
Informationen zum Anzeigen von Details zu von Ihnen erstellten Berichtszeitplänen finden Sie unter [Zeitpläne für Patch-Compliance-Berichte anzeigen](#patch-compliance-reporting-schedules).
## Generieren von Patch-Compliance-Berichten für alle verwaltete Knoten
Gehen Sie wie folgt vor, um einen Patch-Zusammenfassungs-Bericht für alle verwaltete Knoten in Ihrem AWS-Konto zu generieren. Der Bericht für alle verwalteten Knoten zeigt an, welche Knoten nicht konform sind und wie viele Patches nicht konform sind. Es gibt keine Namen oder andere Bezeichner der Patches. Für diese zusätzlichen Details können Sie einen Patch-Compliance-Bericht für einen einzelnen verwalteten Knoten erstellen. Informationen finden Sie unter [Generieren von Patch-Compliance-Berichten für einen einzelnen verwalteten Knoten](#patch-compliance-reports-to-s3-one-instance) weiter vorne in diesem Thema.
**Generieren von Patch-Compliance-Berichten für alle verwaltete Knoten**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte) aus.
1. Klicken Sie auf **Export to S3** (Exportieren nach S3). (Wählen Sie nicht zuerst eine Knoten-ID aus.)
1. Für **Berichtname** geben Sie einen Namen ein, damit Sie den Bericht später leichter identifizieren können.
1. Für **Meldehäufigkeit** wählen Sie eine der folgenden Optionen aus:
+ **On Demand** – Erstellen Sie einen einmaligen Bericht. Fahren Sie mit Schritt 8 fort.
+ **Nach einem Plan** – Geben Sie einen wiederkehrenden Zeitplan für die automatische Erstellung von Berichten an. Fahren Sie fort mit Schritt 7.
1. Für den **Typ „Nach einem Plan“** geben Sie entweder einen Kursausdruck an, z. B. alle 3 Tage, oder geben Sie einen Cron-Ausdruck an, um die Berichtshäufigkeit festzulegen.
Informationen zu Cron-Ausdrücken finden Sie unter [Referenz: Cron- und Rate-Ausdrücke für System Manager](reference-cron-and-rate-expressions.md).
1. Für **Bucket-Name** wählen Sie den Namen eines S3-Buckets aus, in dem die CSV-Berichtsdateien gespeichert werden sollen.
**Wichtig**
Wenn Sie in einem System arbeiten AWS-Region , das nach dem 20. März 2019 gestartet wurde, müssen Sie einen S3-Bucket in derselben Region auswählen. Nach diesem Datum gestartete Regionen wurden standardmäßig deaktiviert. Weitere Informationen und eine Liste dieser Regionen finden Sie unter [Aktivieren einer Region](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable) in der *Allgemeine Amazon Web Services-Referenz*.
1. (Optional) Um Benachrichtigungen zu senden, wenn der Bericht erstellt wird, erweitern Sie den Abschnitt **SNS-Thema** und wählen Sie dann aus **SNS-Thema Amazon-Ressourcenname (ARN)** ein vorhandenes Amazon-SNS-Thema aus.
1. Wählen Sie **Absenden** aus.
Informationen zum Anzeigen eines Verlaufs von generierten Berichten finden Sie unter [Berichtsverlauf für Patch-Compliance anzeigen](#patch-compliance-reporting-history).
Informationen zum Anzeigen von Details zu von Ihnen erstellten Berichtszeitplänen finden Sie unter [Zeitpläne für Patch-Compliance-Berichte anzeigen](#patch-compliance-reporting-schedules).
## Berichtsverlauf für Patch-Compliance anzeigen
Mithilfe der Informationen in diesem Thema können Sie sich Details zu den Patch-Compliance-Berichten anzeigen lassen, die in Ihrem erstellt wurden AWS-Konto.
**Anzeigen des Berichtsverlaufs für Patch-Compliance**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte) aus.
1. Klicken Sie auf **Alle S3-Exporte anzeigen** und danach auf die Registerkarte **Exportieren des Verlaufs**.
## Zeitpläne für Patch-Compliance-Berichte anzeigen
Mithilfe der Informationen in diesem Thema können Sie sich Details zu den in Ihrem erstellten Zeitplan für die Erstellung von Berichten zur Patch-Konformität anzeigen lassen AWS-Konto.
**Anzeigen des Berichtsverlaufs für Patch-Compliance**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Compliance reporting** (Compliance-Berichte) aus.
1. Wählen Sie **View all S3 exports** (Alle S3-Exporte anzeigen) und danach die Registerkarte **Report schedule rules** (Regeln für die Berichtsplanung) aus.
## Problembehandlung bei der Erstellung von Patch-Compliance-Berichten
Im Folgenden finden Sie Informationen zur Behandlung von Problemen mit Patch-Compliance-Berichten in Patch Manager, einem Tool in AWS Systems Manager.
**Topics**
+ [Eine Nachricht meldet, dass die `AWS-SystemsManager-PatchManagerExportRolePolicy`-Richtlinie beschädigt ist](#patch-compliance-reports-troubleshooting-1)
+ [Nach dem Löschen von Patch-Compliance-Richtlinien oder -Rollen werden geplante Berichte nicht erfolgreich generiert](#patch-compliance-reports-troubleshooting-2)
### Eine Nachricht meldet, dass die `AWS-SystemsManager-PatchManagerExportRolePolicy`-Richtlinie beschädigt ist
**Problem**: Sie erhalten eine Fehlermeldung ähnlich der folgenden, die angibt, dass `AWS-SystemsManager-PatchManagerExportRolePolicy` beschädigt ist:
```
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.
```
+ **Lösung**: Verwenden Sie die Patch Manager Konsole oder löschen AWS CLI Sie die betroffenen Rollen und Richtlinien, bevor Sie einen neuen Patch-Compliance-Bericht erstellen.
**So löschen Sie die beschädigte Richtlinie über die Konsole**
1. Öffnen Sie unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) die IAM-Konsole.
1. Führen Sie eine der folgenden Aktionen aus:
**On-Demand-Berichte** – Wenn das Problem beim Generieren eines einmaligen On-Demand-Berichts aufgetreten ist, wählen Sie in der linken Navigation **Richtlinien** aus und suchen Sie nach `AWS-SystemsManager-PatchManagerExportRolePolicy`. Löschen Sie dann die Richtlinie. Wählen Sie anschließend **Rollen** aus, suchen Sie nach `AWS-SystemsManager-PatchSummaryExportRole` und löschen Sie sie.
**Geplante Berichte** – Wenn der Fehler während der Erstellung eines geplanten Berichts aufgetreten ist, wählen Sie in der linken Navigation **Richtlinien** aus, suchen Sie nacheinander nach `AWS-EventBridge-Start-SSMAutomationRolePolicy` und `AWS-SystemsManager-PatchManagerExportRolePolicy` und löschen Sie jede Richtlinie. Wählen Sie anschließend **Rollen** aus, schen Sie nacheinander nach `AWS-EventBridge-Start-SSMAutomationRole` und `AWS-SystemsManager-PatchSummaryExportRole` und löschen Sie jede Rolle.
**Um die beschädigte Richtlinie mit dem zu löschen AWS CLI**
Ersetzen Sie das *placeholder values* durch Ihre Konto-ID.
+ Wenn das Problem bei der Erstellung eines einmaligen On-Demand-Berichts aufgetreten ist, führen Sie die folgenden Befehle aus:
```
aws iam delete-policy --policy-arn arn:aws:iam::account-id:policy/AWS-SystemsManager-PatchManagerExportRolePolicy
```
```
aws iam delete-role --role-name AWS-SystemsManager-PatchSummaryExportRole
```
Wenn das Problem bei der Erstellung eines Zeitplanberichts auftritt, führen Sie die folgenden Befehle aus:
```
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
```
Nachdem Sie eines der beiden Verfahren abgeschlossen haben, folgen Sie den Schritten, um einen neuen Patch-Compliance-Bericht zu erstellen oder zu planen.
### Nach dem Löschen von Patch-Compliance-Richtlinien oder -Rollen werden geplante Berichte nicht erfolgreich generiert
**Problem**: Wenn Sie zum ersten Mal einen Bericht erstellen, erstellt Systems Manager eine Servicerolle und eine Richtlinie für den Exportprozess (`AWS-SystemsManager-PatchSummaryExportRole` und `AWS-SystemsManager-PatchManagerExportRolePolicy`). Wenn Sie zum ersten Mal einen geplanten Bericht erstellen, erstellt Systems Manager eine weitere Servicerolle und eine Richtlinie (`AWS-EventBridge-Start-SSMAutomationRole` und `AWS-EventBridge-Start-SSMAutomationRolePolicy`). Diese ermöglichen es Amazon, eine Automatisierung mithilfe des Runbooks [AWS ExportPatchReportToS3](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-exportpatchreporttos3) zu EventBridge starten.
Wenn Sie eine dieser Richtlinien oder Rollen löschen, gehen die Verbindungen zwischen Ihrem Zeitplan und Ihrem angegebenen S3-Bucket und Amazon SNS-Thema möglicherweise verloren.
+ **Lösung**: Um dieses Problem zu umgehen, empfehlen wir, den vorherigen Zeitplan zu löschen und einen neuen Zeitplan zu erstellen, um den zu ersetzen, bei dem Probleme aufgetreten sind.
# Behebung nicht konformer verwalteter Knoten mit Patch Manager
Die Themen in diesem Abschnitt enthalten eine Übersicht darüber, wie verwaltete Knoten, die die Patch-Compliance nicht erfüllen, identifiziert werden können und wie sie konform gemacht werden.
**Topics**
+ [Identifizieren von nicht konformen verwalteten Knoten](patch-manager-find-noncompliant-nodes.md)
+ [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md)
+ [Patchen nicht konformer verwalteter Knoten](patch-manager-compliance-remediation.md)
# Identifizieren von nicht konformen verwalteten Knoten
Out-of-compliance verwaltete Knoten werden identifiziert, wenn eines von zwei AWS Systems Manager Dokumenten (SSM-Dokumente) ausgeführt wird. Diese SSM-Dokumente verweisen auf die entsprechende Patch-Baseline für jeden verwalteten Knoten in Patch Manager, einem Tool in AWS Systems Manager. Anschließend werten sie den Patch-Zustand des verwalteten Knoten aus und stellen Ihnen dann Compliance-Ergebnisse zur Verfügung.
Es gibt zwei SSM-Dokumente, die verwendet werden, um nicht konforme verwaltete Knoten zu identifizieren oder zu aktualisieren: `AWS-RunPatchBaseline` und `AWS-RunPatchBaselineAssociation`. Jedes wird von verschiedenen Prozessen verwendet, und ihre Compliance-Ergebnisse sind über verschiedene Kanäle verfügbar. In der folgenden Tabelle werden die Unterschiede zwischen diesen Dokumenten aufgeführt.
**Anmerkung**
Daten zur Patch-Konformität von Patch Manager können an AWS Security Hub CSPM gesendet werden. Security Hub CSPM bietet Ihnen einen umfassenden Überblick über Ihre Sicherheitswarnungen mit hoher Priorität und den Compliance-Status. Er überwacht auch den Patching-Status Ihrer Flotte. Weitere Informationen finden Sie unter [Integrieren Patch Manager mit AWS Security Hub CSPM](patch-manager-security-hub-integration.md).
| | `AWS-RunPatchBaseline` | `AWS-RunPatchBaselineAssociation` |
| --- | --- | --- |
| Prozesse, die das Dokument verwenden | **On-Demand-Patchen** – Sie können verwaltete Knoten bei Bedarf scannen oder patchen, indem Sie die Option **Patch now** (Jetzt patchen) verwenden. Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md). **Quick Setup-Patch-Richtlinien von Systems Manager** – Sie können eine Patching-Konfiguration in Quick Setup, einem Tool in AWS Systems Manager, erstellen, die fehlende Patches in separaten Zeitplänen für eine gesamte Organisation, eine Teilmenge von Organisationseinheiten oder ein einzelnes AWS-Konto scannen oder installieren kann. Weitere Informationen finden Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md). **Einen Befehl ausführen** – Sie können `AWS-RunPatchBaseline` manuell in einem Vorgang in Run Command, einem Tool in AWS Systems Manager, ausführen. Weitere Informationen finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md). **Wartungsfenster** – Sie können ein Wartungsfenster erstellen, das das SSM-Dokument `AWS-RunPatchBaseline` in einem Run Command-Aufgabentyp verwendet. Weitere Informationen finden Sie unter [Tutorial: Erstellen Sie ein Wartungsfenster zum Patchen über die Konsole](maintenance-window-tutorial-patching.md). | **Quick Setup-Host-Verwaltung für Systems Manager** – Sie können eine Host-Management-Konfigurationsoption in Quick Setup aktivieren, um Ihre verwalteten Instances täglich auf Patch-Compliance zu scannen. Weitere Informationen finden Sie unter [Amazon-EC2-Host-Verwaltung mit Quick Setup einrichten](quick-setup-host-management.md). **Systems Manager [Explorer](Explorer.md)**— Wenn Sie es zulassenExplorer, scannt ein Tool Ihre verwalteten Instanzen regelmäßig auf Patch-Konformität und meldet die Ergebnisse im Explorer Dashboard. AWS Systems Manager |
| Format der Patch-Scan-Ergebnisdaten | Nach der Ausführung von `AWS-RunPatchBaseline` sendet Patch Manager ein `AWS:PatchSummary`-Objekt an Inventory, ein Tool in AWS Systems Manager. Dieser Bericht wird nur nach erfolgreichen Patch-Vorgängen generiert und enthält eine Erfassungszeit, anhand derer angegeben wird, wann der Compliance-Status berechnet wurde. | Nach der Ausführung von `AWS-RunPatchBaselineAssociation` sendet Patch Manager ein `AWS:ComplianceItem`-Objekt an Systems Manager Inventory. |
| So zeigen Sie aktuelle Compliance-Berichte in der Konsole an | Sie können Patch-Compliance-Informationen für Prozesse anzeigen, die `AWS-RunPatchBaseline` in [Systems Manager Compliance](systems-manager-compliance.md) und [Arbeiten mit verwalteten Knoten](fleet-manager-managed-nodes.md) verwenden. Weitere Informationen finden Sie unter [Anzeigen der Patch-Compliance-Ergebnisse](patch-manager-view-compliance-results.md). | Wenn Sie Quick Setup verwenden, um Ihre verwalteten Instances auf Patch-Compliance zu überprüfen, finden Sie den Compliance-Bericht unter [Systems Manager Fleet Manager](fleet-manager.md). Wählen Sie in der Fleet Manager-Konsole die Knoten-ID Ihres verwalteten Knotens aus. Wählen Sie im Menü **Allgemein** die Option **Konfigurationskonformität** aus. Wenn Sie Explorer verwenden, um Ihre verwalteten Instances auf Patch-Compliance zu überprüfen, finden Sie den Compliance-Bericht sowohl unter Explorer als auch unter [Systems Manager OpsCenter](OpsCenter.md). |
| AWS CLI Befehle zum Anzeigen der Patch-Konformitätsergebnisse | Für Prozesse, die dies verwenden`AWS-RunPatchBaseline`, können Sie die folgenden AWS CLI Befehle verwenden, um zusammenfassende Informationen zu Patches auf einem verwalteten Knoten anzuzeigen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) | Für Prozesse, die dies verwenden`AWS-RunPatchBaselineAssociation`, können Sie den folgenden AWS CLI Befehl verwenden, um zusammenfassende Informationen zu Patches auf einer Instanz anzuzeigen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-find-noncompliant-nodes.html) |
| Patch-Operationen | Für Prozesse, die `AWS-RunPatchBaseline` verwenden, geben Sie an, ob der Vorgang nur eine `Scan`-Operation oder eine `Scan and install`-Operation ausführen soll. Wenn Ihr Ziel darin besteht, nicht konforme verwaltete Knoten zu identifizieren und nicht zu beheben, führen Sie nur eine `Scan`-Operation durch. | Quick Setup- und Explorer-Prozesse, die AWS-RunPatchBaselineAssociation verwenden, führen nur eine Scan-Operation aus. |
| Weitere Informationen | [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md) | [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineAssociation`](patch-manager-aws-runpatchbaselineassociation.md) |
Informationen zu den verschiedenen Patch-Compliance-Status, die möglicherweise gemeldet werden, finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md)
Informationen zur Behebung verwalteter Knoten, die die Patch-Compliance nicht erfüllen, finden Sie unter [Patchen nicht konformer verwalteter Knoten](patch-manager-compliance-remediation.md).
# Statuswerte der Patch-Compliance
Zu den Informationen über Patches für einen verwalteten Knoten gehört ein Bericht über den Zustand oder den Status jedes einzelnen Patches.
**Tipp**
Wenn Sie einem verwalteten Knoten einen bestimmten Patch-Compliance-Status zuweisen möchten, können Sie den Befehl [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) AWS Command Line Interface (AWS CLI) oder die [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutComplianceItems.html)API-Operation verwenden. Das Zuweisen eines Compliance-Zustands wird in der Konsole nicht unterstützt.
Verwenden Sie die Informationen in den folgenden Tabellen, um zu ermitteln, warum ein verwalteter Knoten möglicherweise nicht die Patch-Compliance erfüllt.
## Patch-Compliance-Werte für Debian Server und Ubuntu Server
Für Debian Server und Ubuntu Server werden die Regeln für die Paketklassifizierung in verschiedene Compliance-Zustände in der folgenden Tabelle beschrieben.
**Anmerkung**
Beachten Sie bei der Auswertung der Statuswerte `INSTALLED`, `INSTALLED_OTHER` und `MISSING` Folgendes: Wenn Sie beim Erstellen oder Aktualisieren einer Patch-Baseline das Kontrollkästchen **Funktionsupdates einschließen** nicht aktivieren, sind Patch-Kandidaten-Versionen auf Patches in den folgenden Repositorys beschränkt:
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)
Wenn Sie die Option **Nicht sicherheitsrelevante Aktualisierungen einschließen** auswählen, werden auch Patches aus anderen Repositorys berücksichtigt.
| Patch-Status | Description | Compliance status (Compliance-Status) |
| --- | --- | --- |
| **`INSTALLED`** | Der Patch wird in der Patch-Baseline aufgeführt und ist auf dem verwalteten Knoten installiert. Er könnte entweder manuell von einer Person oder automatisch von Patch Manager installiert worden sein, wenn das `AWS-RunPatchBaseline`-Dokument auf dem verwalteten Knoten ausgeführt wurde. | Konform |
| **`INSTALLED_OTHER`** | Der Patch ist nicht in der Baseline enthalten oder wird von der Baseline nicht genehmigt, ist aber auf dem verwalteten Knoten installiert. Der Patch wurde möglicherweise manuell installiert, das Paket könnte eine erforderliche Abhängigkeit von einem anderen genehmigten Patch sein, oder der Patch war möglicherweise Teil eines InstallOverrideList Vorgangs. Wenn Sie `Block` nicht als die **Zurückgewiesene Patches**-Aktion angeben, schließt `INSTALLED_OTHER` auch installiert, aber abgelehnte Patches ein. | Konform |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` kann eines von zwei Dingen bedeuten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-compliance-states.html) In keinem Fall bedeutet dies, dass ein Patch mit diesem Status einen Neustart *erfordert*, sondern nur, dass der Knoten seit der Installation des Patches nicht neu gestartet wurde. | Nicht konform |
| **`INSTALLED_REJECTED`** | Der Patch wird auf dem verwalteten Knoten installiert, jedoch in einer Liste der **Rejected patches** (Abgelehnte Patches) angegeben. Dies bedeutet normalerweise, dass der Patch installiert wurde, bevor er einer Liste der abgelehnten Patches hinzugefügt wurde. | Nicht konform |
| **`MISSING`** | Der Patch wurde in der Baseline genehmigt, aber nicht auf dem verwalteten Knoten installiert. Wenn Sie die `AWS-RunPatchBaseline`-Dokumentaufgabe zum Scannen (nicht Installieren) konfigurieren, meldet das System diesen Status bei Patches, die beim Scan gefunden wurden, aber noch nicht installiert sind. | Nicht konform |
| **`FAILED`** | Der Patch wurde an der Baseline genehmigt, konnte aber nicht installiert werden. Zum Beheben dieses Problems überprüfen Sie die Befehlsausgabe auf Informationen, die Ihnen helfen, das Problem zu verstehen. | Nicht konform |
## Patch-Compliance-Werte für andere Betriebssysteme
Für alle Betriebssysteme außer Debian Server und Ubuntu Server werden die Regeln für die Paketklassifizierung in verschiedene Compliance-Zustände in der folgenden Tabelle beschrieben.
| Patch-Status | Description | Compliancewert |
| --- | --- | --- |
| **`INSTALLED`** | Der Patch wird in der Patch-Baseline aufgeführt und ist auf dem verwalteten Knoten installiert. Er könnte entweder manuell von einer Person oder automatisch von Patch Manager installiert worden sein, als das `AWS-RunPatchBaseline`-Dokument auf dem Knoten ausgeführt wurde. | Konform |
| **`INSTALLED_OTHER`**¹ | Der Patch befindet sich nicht an der Baseline, ist aber auf dem verwalteten Knoten installiert. Hierfür gibt es zwei mögliche Gründe: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-compliance-states.html) | Konform |
| **`INSTALLED_REJECTED`** | Der Patch wird auf dem verwalteten Knoten installiert, jedoch in einer Liste der abgelehnten Patches angegeben. Dies bedeutet normalerweise, dass der Patch installiert wurde, bevor er einer Liste der abgelehnten Patches hinzugefügt wurde. | Nicht konform |
| **`INSTALLED_PENDING_REBOOT`** | `INSTALLED_PENDING_REBOOT` kann eines von zwei Dingen bedeuten: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/patch-manager-compliance-states.html) In keinem Fall bedeutet dies, dass ein Patch mit diesem Status einen Neustart *erfordert*, sondern nur, dass der Knoten seit der Installation des Patches nicht neu gestartet wurde. | Nicht konform |
| **`MISSING`** | Der Patch wurde in der Baseline genehmigt, aber nicht auf dem verwalteten Knoten installiert. Wenn Sie die `AWS-RunPatchBaseline`-Dokumentaufgabe zum Scannen (nicht Installieren) konfigurieren, meldet das System diesen Status bei Patches, die beim Scan gefunden wurden, aber noch nicht installiert sind. | Nicht konform |
| **`FAILED`** | Der Patch wurde an der Baseline genehmigt, konnte aber nicht installiert werden. Zum Beheben dieses Problems überprüfen Sie die Befehlsausgabe auf Informationen, die Ihnen helfen, das Problem zu verstehen. | Nicht konform |
| **`NOT_APPLICABLE`**¹ | *Dieser Compliance-Status wird nur in Windows Server-Betriebssystemen gemeldet.* Der Patch wurde in der Baseline genehmigt, der Service oder dem Feature, die den Patch verwendet, wurde aber auf dem verwalteten Knoten nicht installiert. Beispielsweise würde ein Patch für einen Webserver-Service wie Internet Information Services (IIS) `NOT_APPLICABLE` anzeigen, wenn er in der Baseline genehmigt wurde, der Webservice jedoch nicht auf dem verwalteten Knoten installiert ist. Ein Patch kann auch als `NOT_APPLICABLE` markiert sein, wenn er durch ein nachfolgendes Update ersetzt wurde. Dies bedeutet, dass das spätere Update installiert ist und das `NOT_APPLICABLE`-Update nicht mehr benötigt wird. | Nicht zutreffend |
| AVAILABLE\$1SECURITY\$1UPDATES | *Dieser Compliance-Status wird nur in Windows Server-Betriebssystemen gemeldet.* Ein verfügbarer Sicherheitsupdate-Patch, der nicht von der Patch-Baseline genehmigt wurde, kann den Konformitätswert `Compliant` oder `Non-Compliant` haben, wie in einer benutzerdefinierten Patch-Baseline definiert. Wenn Sie eine Patch-Baseline erstellen oder aktualisieren, wählen Sie den Status, den Sie Sicherheitspatches zuweisen möchten, die zwar verfügbar, aber nicht genehmigt sind, weil sie die in der Patch-Baseline angegebenen Installationskriterien nicht erfüllen. Beispielsweise können Sicherheitspatches, die Sie möglicherweise installieren möchten, übersprungen werden, wenn Sie eine lange Wartezeit für die Installation nach der Veröffentlichung eines Patches angegeben haben. Wenn während der von Ihnen angegebenen Wartezeit ein Update für den Patch veröffentlicht wird, beginnt die Wartezeit für die Installation des Patches von vorne. Wenn die Wartezeit zu lang ist, können mehrere Versionen des Patches veröffentlicht, aber nie installiert werden. Bei der Anzahl der Patch-Zusammenfassungen gilt: Wenn ein Patch als `AvailableSecurityUpdate` gemeldet wird, ist er immer in `AvailableSecurityUpdateCount` enthalten. Wenn die Baseline so konfiguriert ist, dass diese Patches als `NonCompliant` gemeldet werden, ist sie auch in `SecurityNonCompliantCount` enthalten. Wenn die Baseline so konfiguriert ist, dass diese Patches als `Compliant` gemeldet werden, sind sie nicht in `SecurityNonCompliantCount` enthalten. Diese Patches werden immer mit einem nicht spezifizierten Schweregrad gemeldet und sind niemals in `CriticalNonCompliantCount` enthalten. | Konform oder nicht konform, je nachdem, welche Option für verfügbare Sicherheitsupdates ausgewählt wurde. Wenn Sie die Konsole verwenden, um eine Patch-Baseline zu erstellen oder zu aktualisieren, geben Sie diese Option im Feld **Compliance-Status für verfügbare Sicherheitsupdates** an. Mit dem [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)Befehl AWS CLI to run the [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)or geben Sie diese Option im `available-security-updates-compliance-status` Parameter an. |
¹ Für Patches mit dem Status `INSTALLED_OTHER` und `NOT_APPLICABLE`, lässt Patch Manager einige Daten aus Abfrageergebnissen aus, die auf dem Befehl [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) basieren, z. B. die Werte für `Classification` und `Severity`. Dies geschieht, um zu verhindern, dass das Datenlimit für einzelne Knoten in Inventory, einem Tool in AWS Systems Manager, überschritten wird. Um alle Patch-Details anzuzeigen, können Sie den Befehl [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) nutzen.
# Patchen nicht konformer verwalteter Knoten
Viele der AWS Systems Manager Tools und Prozesse, mit denen Sie verwaltete Knoten auf Patch-Konformität überprüfen können, können auch verwendet werden, um Knoten an die Patch-Regeln anzupassen, die derzeit für sie gelten. Um verwaltete Knoten in die Patch-Konformität zu bringen AWS Systems Manager, muss ein Tool einen `Scan and install` Vorgang ausführen. Patch Manager (Wenn es Ihr Ziel ist, nicht konforme verwaltete Knoten nur zu identifizieren und sie nicht zu beheben, führen Sie stattdessen eine `Scan`-Operation aus. Weitere Informationen finden Sie unter [Identifizieren von nicht konformen verwalteten Knoten](patch-manager-find-noncompliant-nodes.md).)
**Installieren von Patches mit Systems Manager**
Sie können aus mehreren Tools wählen, um eine `Scan and install`-Operation auszuführen:
+ (Empfohlen) Konfigurieren Sie eine Patch-Richtlinie in Quick Setup, einem Tool in Systems Manager, mit dem Sie fehlende Patches nach einem Zeitplan für eine gesamte Organisation, eine Teilmenge von Organisationseinheiten oder ein einzelnes AWS-Konto installieren können. Weitere Informationen finden Sie unter [Das Patchen für Instances in einer Organisation mithilfe einer Patch-Richtlinie für Quick Setup konfigurieren](quick-setup-patch-manager.md).
+ Erstellen Sie ein Wartungsfenster, das das Systems Manager-Dokument (SSM-Dokument) `AWS-RunPatchBaseline` in einem Run Command-Aufgabentyp verwendet. Weitere Informationen finden Sie unter [Tutorial: Erstellen Sie ein Wartungsfenster zum Patchen über die Konsole](maintenance-window-tutorial-patching.md).
+ Führen Sie `AWS-RunPatchBaseline` manuell in einer Run Command-Operation aus. Weitere Informationen finden Sie unter [Ausführen von Befehlen über die Konsole](running-commands-console.md).
+ Installieren Sie Patches bei Bedarf mithilfe der Option **Patch now** (Jetzt patchen). Weitere Informationen finden Sie unter [On-Demand-Patchen von verwalteten Knoten](patch-manager-patch-now-on-demand.md).
# Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat
Die Patch-Compliance-Daten stellen eine point-in-time Momentaufnahme des letzten erfolgreichen Patch-Vorgangs dar. Jeder Konformitätsbericht enthält sowohl eine Ausführungs-ID als auch eine Erfassungszeit, anhand derer Sie feststellen können, welcher Vorgang die Konformitätsdaten erstellt hat und wann sie generiert wurden.
Wenn Sie mehrere Arten von Vorgängen zum Scannen Ihrer Instances auf Patch-Compliance haben, überschreibt jeder Scan die Patch-Compliance-Daten vorheriger Scans. Dies kann zu unerwarteten Ergebnissen in Ihren Patch-Compliance-Daten führen.
Nehmen wir an, Sie erstellen eine Patch-Richtlinie, die jeden Tag um 02:00 Uhr Ortszeit auf Patch-Compliance scannt. Diese Patch-Richtlinie verwendet eine Patch-Baseline, die Patches als Ziel haben, deren Schweregrad mit `Critical`, `Important` und `Moderate` gekennzeichnet ist. Diese Patch-Baseline gibt auch einige speziell abgelehnte Patches an.
Nehmen Sie außerdem an, dass Sie bereits ein Wartungsfenster eingerichtet haben, um jeden Tag um 04:00 Uhr Ortszeit denselben Satz verwalteter Knoten zu scannen, die Sie nicht löschen oder deaktivieren. Die Aufgabe dieses Wartungsfensters verwendet eine andere Patch-Baseline, eine, die nur Patches mit dem Schweregrad `Critical` als Ziel hat und keine bestimmten Patches ausschließt.
Wenn dieser zweite Scan vom Wartungsfenster durchgeführt wird, werden die Patch-Compliance-Daten des ersten Scans gelöscht und durch die Patch-Compliance des zweiten Scans ersetzt.
Daher empfehlen wir dringend, nur eine automatisierte Methode zum Scannen und Installieren in Ihren Patching-Vorgängen zu verwenden. Wenn Sie Patch-Richtlinien einrichten, sollten Sie andere Methoden zum Scannen auf Patch-Compliance löschen oder deaktivieren. Weitere Informationen finden Sie unter den folgenden Themen:
+ So entfernen Sie eine Patching-Aufgabe aus einem Wartungsfenster – [Aktualisieren oder Abmelden von Wartungsfenster-Aufgaben mithilfe der Konsole](sysman-maintenance-update.md#sysman-maintenance-update-tasks)
+ So löschen Sie eine State Manager-Zuordnung – [Löschen von Zuordnungen](systems-manager-state-manager-delete-association.md).
Um tägliche Patch-Compliance-Scans in einer Host-Verwaltungskonfiguration zu deaktivieren, gehen Sie in Quick Setup wie folgt vor:
1. Wählen Sie im Navigationsbereich **Quick Setup** aus.
1. Wählen Sie die zu aktualisierende Host-Management-Konfiguration aus.
1. Wählen Sie **Actions, Edit configuration** (Aktionen, Konfiguration bearbeiten) aus.
1. Deaktivieren Sie das Kontrollkästchen **Scan instances for missing patches daily** (Instances täglich auf fehlende Patches scannen).
1. Wählen Sie **Aktualisieren** aus.
**Anmerkung**
Die Verwendung von **Patch now** (Jetzt patchen) zum Überprüfen eines verwalteten Knotens auf Compliance führt auch zu einem Überschreiben von Patch-Compliance-Daten.
# On-Demand-Patchen von verwalteten Knoten
Verwenden Sie die Option **Jetzt patchen** in Patch Manager, einem Tool in AWS Systems Manager, um Patching-Vorgänge auf Abruf über die Systems-Manager-Konsole auszuführen. Dies bedeutet, dass Sie keinen Zeitplan erstellen müssen, um den Compliance-Status Ihrer verwalteten Knoten zu aktualisieren oder Patches auf nicht kompatiblen Knoten zu installieren. Sie müssen die Systems Manager Manager-Konsole auch nicht zwischen Patch Manager undMaintenance Windows, einem Tool in AWS Systems Manager, umschalten, um ein geplantes Patch-Fenster einzurichten oder zu ändern.
**Patch now** (Jetzt patchen) ist besonders nützlich, wenn Sie so schnell wie möglich Zero-Day-Updates anwenden oder andere kritische Patches auf Ihren verwalteten Knoten installieren müssen.
**Anmerkung**
Patching auf Abruf wird jeweils für ein AWS-Konto einzelnes AWS-Region Paar unterstützt. Es kann nicht mit Patching-Vorgängen verwendet werden, die auf *Patch-Richtlinien* basieren. Wir empfehlen die Verwendung von Patch-Richtlinien, um sicherzustellen, dass alle Ihre verwalteten Knoten die Compliance einhalten. Weitere Informationen zur Arbeit mit Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).
**Topics**
+ [So funktioniert „Patch now“ (Jetzt patchen)](#patch-on-demand-how-it-works)
+ [Ausführen von „Patch now“ (Jetzt patchen)](#run-patch-now)
## So funktioniert „Patch now“ (Jetzt patchen)
Um **Patch now** (Jetzt patchen) auszuführen, müssen Sie nur zwei erforderliche Einstellungen angeben:
+ Ob nur nach fehlenden Patches gescannt werden soll oder ob Patches auf Ihren verwalteten Knoten gescannt *und* installiert werden sollen
+ Auf welchen verwalteten Knoten die Operation ausgeführt werden soll
Wenn die Operation **Patch now** (Jetzt patchen) läuft, bestimmt sie, welche Patch-Baseline auf die gleiche Weise verwendet werden soll, wie eine für andere Patching-Operationen ausgewählt wird. Wenn ein verwalteter Knoten einer Patch-Gruppe zugeordnet ist, wird die für diese Gruppe angegebene Patch-Baseline verwendet. Wenn der verwaltete Knoten nicht einer Patch-Gruppe zugeordnet ist, verwendet die Operation die Patch-Baseline, die derzeit als Standard für den Betriebssystemtyp des verwalteten Knotens festgelegt ist. Dabei kann es sich um eine vordefinierte Baseline oder um die benutzerdefinierte Baseline handeln, die Sie als Standard festgelegt haben. Weitere Informationen zur Patch-Baseline-Auswahl finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md).
Zu den Optionen, die Sie für **Patch now** (Jetzt patchen) angeben können, gehört, ob verwaltete Knoten nach dem Patchen neu gestartet werden sollen, indem Sie einen Amazon Simple Storage Service (Amazon S3)-Bucket zum Speichern von Protokolldaten für den Patchvorgang angeben und Systems-Manager-Dokumente (SSM-Dokumente) als Lebenszyklus-Hooks während des Patchings ausführen.
### Parallelitäts- und Fehlerschwellenwerte für „Patch now“ (Jetzt patchen)
Für **Patch now**-Operationen (Jetzt patchen) werden Optionen für Parallelitäts- und Fehlerschwellen von Patch Manager gehandhabt. Sie müssen weder angeben, wie viele verwaltete Knoten gleichzeitig gepatcht werden sollen, noch wie viele Fehler zulässig sind, bevor die Operation fehlschlägt. Patch Manager wendet die Einstellungen für Parallelitäts- und Fehlerschwellenwert an, die in den folgenden Tabellen beschrieben werden, wenn Sie On-Demand-Patches anwenden.
**Wichtig**
Die folgenden Schwellenwerte gelten für nur für `Scan and install`-Operationen. Für `Scan`-Operationen versucht Patch Manager bis zu 1.000 Knoten gleichzeitig zu scannen und weiter zu scannen, bis bis zu 1.000 Fehler aufgetreten sind.
**Gleichzeitigkeit: Installationsvorgänge**
| Die Gesamtanzahl von verwalteten Knoten in der Operation **Patch now** (Jetzt patchen) | Anzahl der gleichzeitig gescannten oder gepatchten verwalteten Knoten |
| --- | --- |
| Weniger als 25 | 1 |
| 25–100 | 5 % |
| 101 bis 1.000 | 8% |
| Mehr als 1.000 | 10 % |
**Fehlerschwellenwert: Installationsvorgänge**
| Die Gesamtanzahl von verwalteten Knoten in der Operation **Patch now** (Jetzt patchen) | Anzahl der zulässigen Fehler, bevor der Vorgang fehlschlägt |
| --- | --- |
| Weniger als 25 | 1 |
| 25–100 | 5 |
| 101 bis 1.000 | 10 |
| Mehr als 1.000 | 10 |
### Verwenden von „Patch now“ (Jetzt patchen)-Lebenszyklus-Hooks
**Patch now** (Jetzt patchen) bietet Ihnen die Möglichkeit, SSM Command-Dokumente als Lebenszyklus-Hooks während eines `Install`-Patch-Vorgang auszuführen. Sie können diese Hooks für Aufgaben wie das Herunterfahren von Anwendungen vor dem Patchen oder Ausführen von Zustandsprüfungen für Ihre Anwendungen nach dem Patchen oder nach einem Neustart verwenden.
Weitere Informationen über das Verwenden von Lebenszyklus-Hooks finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaselineWithHooks`](patch-manager-aws-runpatchbaselinewithhooks.md).
In der folgenden Tabelle werden die Lebenszyklus-Hooks aufgeführt, die für jede der drei **Patch now**-Neustartoptionen (Jetzt patchen) aufgelistet sowie Beispielanwendungen für jeden Hook.
**Lebenszyklus-Hooks und Beispielanwendungen**
| Neustartoption | Hook: Vor Installation | Hook: Nach Installation | Hook: Beim Verlassen | Hook: Nach geplantem Neustart |
| --- | --- | --- | --- | --- |
| Bei Bedarf neu starten | Führen Sie ein SSM-Dokument aus, bevor das Patchen beginnt. Anwendungsbeispiel: Fahren Sie Anwendungen sicher herunter, bevor der Patchvorgang beginnt. | Führen Sie ein SSM-Dokument am Ende der Patching-Operation und vor dem Neustart des verwalteten Knoten aus. Anwendungsbeispiel: Führen Sie Vorgänge wie die Installation von Drittanbieter-Anwendungen vor einem potenziellen Neustart aus. | Führen Sie ein SSM-Dokument aus, nachdem die Patching-Operation abgeschlossen und die Instances neu gestartet wurden. Anwendungsbeispiel: Stellen Sie sicher, dass Anwendungen nach dem Patchen wie erwartet ausgeführt werden. | Nicht verfügbar |
| Meine Instances nicht neu starten | Wie oben. | Führen Sie ein SSM-Dokument am Ende des Patching-Vorgangs aus. Anwendungsbeispiel: Stellen Sie sicher, dass Anwendungen nach dem Patchen wie erwartet ausgeführt werden. | *Nicht verfügbar* | *Nicht verfügbar* |
| Neustartzeit planen | Wie oben. | Dasselbe wie für Meine Instances nicht neu starten. | Nicht verfügbar | Führen Sie sofort nach Abschluss eines geplanten Neustarts ein SSM-Dokument aus. Anwendungsbeispiel: Stellen Sie sicher, dass Anwendungen nach dem Neustart wie erwartet ausgeführt werden. |
## Ausführen von „Patch now“ (Jetzt patchen)
Mit dem folgenden Verfahren können Sie On-Demand-Patches auf Ihre verwalteten Knoten anwenden.
**So führen Sie „Patch now“ (Jetzt patchen) aus**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie **Patch now** (Jetzt patchen) aus.
1. Für **Patch-Operation** wählen Sie eine der folgenden Optionen aus:
+ **Scan** (Scannen): Patch Manager findet die Patches, die in Ihren verwalteten Knoten fehlen, installiert sie aber nicht. Sie können die Ergebnisse im **Compliance**-Dashboard oder in anderen Tools, die Sie zum Anzeigen der Patch-Compliance verwenden, anzeigen.
+ **Scan and install** (Scannen und installieren): Patch Manager findet die Patches, die in Ihren verwalteten Knoten fehlen, und installiert sie.
1. Führen Sie diesen Schritt nur aus, wenn Sie im vorherigen Schritt **Scan und Installation** ausgewählt haben. Wählen Sie bei **Neustartoption** eine der folgenden Optionen aus:
+ **Reboot if needed** (Bei Bedarf neu starten): Nach der Installation startet Patch Manager verwaltete Knoten nur dann neu, wenn dies zum Abschluss einer Patch-Installation erforderlich ist.
+ **Don‘t reboot my instances** (Meine Instances nicht neu starten): Nach der Installation startet Patch Manager verwaltete Knoten nicht neu. Sie können verwaltete Knoten manuell neu starten, wenn Sie Neustarts außerhalb von Patch Manager auswählen oder verwalten.
+ **Schedule a reboot time** (Neustartzeit planen): Geben Sie das Datum, die Uhrzeit und die UTC-Zeitzone an, wenn Patch Manager Ihre verwalteten Knoten neu starten sollen. Nachdem Sie den **Patch now** (Jetzt patchen)-Vorgang ausgeführt haben, wird der geplante Neustart als Zuordnung in State Manager mit dem Namen `AWS-PatchRebootAssociation` gelistet.
**Wichtig**
Wenn Sie den Hauptpatchvorgang abbrechen, nachdem er gestartet wurde, State Manager wird die `AWS-PatchRebootAssociation` Zuordnung NICHT automatisch abgebrochen. Um unerwartete Neustarts zu verhindern, müssen Sie manuell `AWS-PatchRebootAssociation` löschen, State Manager falls der geplante Neustart nicht mehr stattfinden soll. Andernfalls kann es zu ungeplanten Systemneustarts kommen, die sich auf die Produktionsauslastung auswirken können. Sie finden diese Zuordnung in der Systems Manager Manager-Konsole unter **State Manager**> **Verknüpfungen**.
1. Wählen Sie unter **Instances to patch (Zu patchende Instances)** eine der folgenden Optionen aus:
+ **Alle Instanzen patchen**: Patch Manager Führt den angegebenen Vorgang auf allen verwalteten Knoten AWS-Konto in Ihrer aktuellen Version aus AWS-Region.
+ **Patch only the target instances I specify** (Nur die von mir angegebenen Ziel-Instances patchen): Sie geben im nächsten Schritt an, welche verwalteten Knoten anvisiert werden sollen.
1. Führen Sie diesen Schritt nur aus, wenn Sie im vorherigen Schritt **Nur die von mir angegebenen Ziel-Instances patchen** ausgewählt haben. Identifizieren Sie für den Abschnitt **Target selection** (Zielauswahl) die Knoten, auf denen Sie diese Operation ausführen möchten, indem Sie Tags angeben, Knoten manuell auswählen oder eine Ressourcengruppe angeben.
**Anmerkung**
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
Wenn Sie sich für eine Ressourcengruppe entscheiden, beachten Sie, dass Ressourcengruppen, die auf einem AWS CloudFormation Stack basieren, trotzdem mit dem `aws:cloudformation:stack-id` Standard-Tag gekennzeichnet werden müssen. Wenn es entfernt wurde, kann Patch Manager möglicherweise nicht ermitteln, welche verwalteten Knoten zur Ressourcengruppe gehören.
1. (Optional) Für **Patch-Protokollspeicher** wählen Sie, wenn Sie Protokolle aus diesem Patchvorgang erstellen und speichern möchten, den S3-Bucket zum Speichern der Protokolle aus.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind diejenigen des Instance-Profils (für EC2-Instances) oder der IAM-Servicerolle (hybrid-aktivierte Maschinen), die der Instance zugewiesen sind, und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Die für Systems Manager erforderlichen Instance-Berechtigungen konfigurieren](setup-instance-permissions.md) oder [Die für Systems Manager erforderliche IAM-Servicerolle in Hybrid- und Multi-Cloud-Umgebungen erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen befindet, stellen Sie außerdem sicher AWS-Konto, dass das Instanzprofil oder die IAM-Dienstrolle, die dem verwalteten Knoten zugeordnet sind, über die erforderlichen Berechtigungen verfügt, um in diesen Bucket zu schreiben.
1. (Optional) Wenn Sie SSM-Dokumente als Lebenszyklus-Hooks an bestimmten Punkten des Patching-Vorgangs ausführen möchten, gehen Sie wie folgt vor:
+ Klicken Sie auf **Verwenden von Lebenszyklus-Hooks**.
+ Wählen Sie für jeden verfügbaren Hook das SSM-Dokument aus, das am angegebenen Punkt des Vorgangs ausgeführt werden soll:
+ Vor Installation
+ Nach Installation
+ Beim Verlassen
+ Nach geplantem Neustart
**Anmerkung**
Das Standarddokument, `AWS-Noop`, führt keine Vorgänge aus.
1. Wählen Sie **Patch now** (Jetzt patchen) aus.
Die Seite **Association execution summary (Zusammenfassung der Zuordnungsausführung)** wird geöffnet. (Jetzt patchen verwendet jetzt Zuordnungen in State Manager, einem Tool in AWS Systems Manager, für seine Vorgänge.) Im Bereich **Operation summary** (Operationsübersicht) können Sie den Scan- oder Patch-Status auf den von Ihnen angegebenen verwalteten Knoten überwachen.
# Arbeiten mit Patch-Baselines
Eine Patch-Baseline in Patch Manager, einem Tool in AWS Systems Manager, definiert, welche Patches für die Installation in Ihren verwalteten Knoten genehmigt sind. Sie können für Patches einzeln angeben, ob sie genehmigt oder abgelehnt werden. Sie können auch automatische Genehmigungsregeln erstellen, um festzulegen, dass bestimmte Arten von Updates (z. B. wichtige Updates), automatisch genehmigt werden. Die Liste mit den Ablehnungen setzt sowohl die Regeln als auch die Liste mit Genehmigungen außer Kraft. Wenn Sie ausschließlich eine Liste mit genehmigten Patches verwenden möchten, um spezifische Pakete zu installieren, entfernen Sie erst alle automatischen Genehmigungsregeln. Wenn Sie explizit einen Patch als abgelehnt kennzeichnen, wird er nicht genehmigt oder installiert, selbst wenn er mit allen Kriterien in einer automatischen Genehmigungsregel übereinstimmt. Außerdem wird ein Patch nur dann auf einem verwalteten Knoten installiert, wenn er für die Software auf dem Knoten geeignet ist, auch wenn der Patch anderweitig für den verwalteten Knoten genehmigt wurde.
**Topics**
+ [AWS Vordefinierte Patch-Baselines anzeigen](patch-manager-view-predefined-patch-baselines.md)
+ [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md)
+ [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md)
**Weitere Informationen**
+ [Patch-Baselines](patch-manager-patch-baselines.md)
# AWS Vordefinierte Patch-Baselines anzeigen
Patch Manager, ein Tool in AWS Systems Manager, enthält eine vordefinierte Patch-Baseline für jedes Betriebssystem, das von unterstützt wird. Patch Manager Sie können diese Patch-Baselines verwenden (Sie können sie jedoch nicht anpassen) oder Sie können eine eigene Patch-Baseline erstellen. Nachfolgend wird beschrieben, wie Sie eine vordefinierte Patch-Baseline anzeigen, um sie auf Ihre Anforderungen hin zu überprüfen. Weitere Informationen zu Patch-Baselines finden Sie unter [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md).
**So zeigen Sie AWS vordefinierte Patch-Baselines an**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie in der Liste der Patch-Baselines die Baseline-ID einer der vordefinierten Patch-Baselines aus.
–oder–
Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen**, wählen Sie die Registerkarte **Patch-Baselines** und wählen Sie dann die Baseline-ID einer der vordefinierten Patch-Baselines.
**Anmerkung**
Für Windows Server werden drei vordefinierte Patch-Baselines bereitgestellt. Die Patch-Baselines `AWS-DefaultPatchBaseline` und `AWS-WindowsPredefinedPatchBaseline-OS` unterstützen nur Betriebssystemupdates auf dem Windows-Betriebssystem selbst. `AWS-DefaultPatchBaseline` wird als Standard-Patch-Baseline für von Windows Server verwalteten Knoten verwendet, es sei denn, Sie geben eine andere Patch-Baseline an. Die Konfigurationseinstellungen in diesen beiden Patch-Baselines sind identisch. Die neuere der beiden, `AWS-WindowsPredefinedPatchBaseline-OS`, wurde erstellt, um sie von der dritten vordefinierten Patch-Baseline für Windows Server zu unterscheiden. Diese Patch-Baseline, `AWS-WindowsPredefinedPatchBaseline-OS-Applications`, kann verwendet werden, um Patches sowohl auf das Windows Server-Betriebssystem als auch auf unterstützte Anwendungen, die von Microsoft veröffentlicht wurden, anzuwenden.
Weitere Informationen finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).
1. Im Abschnitt **Genehmigungsregel**n überprüfen Sie die Konfiguration der Patch-Baseline-Konfiguration.
1. Wenn die Konfiguration für Ihre verwalteten Knoten geeignet ist, können Sie direkt mit dem Verfahren [Erstellen und Verwalten von Patch-Gruppen](patch-manager-tag-a-patch-group.md) fortfahren.
–oder–
Fahren Sie zum Erstellen einer eigenen Standard-Patch-Baseline mit dem Thema [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md) fort.
# Arbeiten mit benutzerdefinierten Patch-Baselines
Patch Manager, ein Tool in AWS Systems Manager, enthält eine vordefinierte Patch-Baseline für jedes Betriebssystem, das von unterstützt wirdPatch Manager. Sie können diese Patch-Baselines verwenden (Sie können sie jedoch nicht anpassen) oder Sie können eine eigene Patch-Baseline erstellen.
In den folgenden Verfahren wird beschrieben, wie Sie eigene benutzerdefinierte Patch-Baselines erstellen, aktualisieren und löschen. Weitere Informationen zu Patch-Baselines finden Sie unter [Vordefinierte und benutzerdefinierte Patch-Baselines](patch-manager-predefined-and-custom-patch-baselines.md).
**Topics**
+ [So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux](patch-manager-create-a-patch-baseline-for-linux.md)
+ [Erstellen einer benutzerdefinierten Patch-Baseline für macOS](patch-manager-create-a-patch-baseline-for-macos.md)
+ [Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md)
+ [Aktualisieren oder Löschen einer benutzerdefinierten Patch-Baseline](patch-manager-update-or-delete-a-patch-baseline.md)
# So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux
Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte Patch-Baseline für Linux-verwaltete Knoten in Patch Manager, einem Tool in AWS Systems Manager, zu erstellen.
Informationen zum Erstellen einer Patch-Baseline für macOS-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für macOS](patch-manager-create-a-patch-baseline-for-macos.md). Informationen zum Erstellen einer Patch-Baseline für Windows-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md).
**So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux-verwaltete Knoten**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Patch-Baselines** und dann **Patch-Baseline erstellen** aus.
–oder–
Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen**, wechseln Sie zur Registerkarte **Patch-Baselines** und wählen Sie dann **Patch-Baseline** erstellen.
1. Geben Sie im Feld **Name** einen Namen für die neue Patch-Baseline ein, z. B. `MyRHELPatchBaseline`.
1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für diese Patch-Baseline ein.
1. Wählen Sie unter **Operating system (Betriebssystem)** ein Betriebssystem aus, z. B. `Red Hat Enterprise Linux`.
1. Wenn Sie diese Patch-Baseline sofort nach der Erstellung als Standard für das ausgewählte Betriebssystem verwenden möchten, aktivieren Sie das Kontrollkästchen neben **Diese Patch-Baseline als Standard-Patch-Baseline für *operating system name* Instances festlegen**.
**Anmerkung**
Diese Option ist nur verfügbar, wenn Sie vor der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.
Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).
1. Erstellen Sie im Abschnitt **Genehmigungsregeln für Betriebssysteme** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
+ **Produkte**: Die Version der Betriebssysteme, auf die sich die Genehmigungsregel bezieht, z. B. `RedhatEnterpriseLinux7.4`. Die Standardauswahl ist `All`.
+ **Classification (Klassifizierung)**: Der Typ der Patches, auf die sich die Genehmigungsregel bezieht, z. B. `Security` oder `Enhancement`. Die Standardauswahl ist `All`.
**Tipp**
Sie können eine Patch-Baseline konfigurieren, um zu steuern, ob Nebenversions-Upgrades für Linux installiert werden, z. B. RHEL 7.8. Nebenversionsupgrades können vom Patch Manager automatisch installiert werden, wenn das Update im entsprechenden Repository verfügbar ist.
Im Fall von Linux-Betriebssystemen werden Nebenversionsupgrades nicht konsistent klassifiziert. Sie können als Fehlerbehebungen oder Sicherheitsupdates klassifiziert (oder nicht klassifiziert) werden, selbst innerhalb derselben Kernel-Version. Im Folgenden werden einige Optionen aufgelistet, mit denen Sie steuern können, ob sie von einer Patch-Baseline installiert werden.
**Option 1**: Die umfassendste Genehmigungsregel, die sicherzustellt, dass Nebenversionsupgrades installiert werden, wenn verfügbar, besteht in der Angabe von **Classification (Klassifizierung)** als `All` (\$1) und der Auswahl der Option **Include nonsecurity updates (Auch andere Updates als Sicherheitsupdates einschließen)**.
**Option 2**: Um die Installation von Patches für eine Betriebssystemversion sicherzustellen, können Sie ein Platzhalterzeichen (\$1) verwenden, um das Kernel-Format im Abschnitt **Patch exceptions (Patch-Ausnahmen)** der Baseline anzugeben. Zum Beispiel ist das Kernel-Format für RHEL 7.\$1 `kernel-3.10.0-*.el7.x86_64`.
Geben Sie `kernel-3.10.0-*.el7.x86_64` in der Liste **Approved patches** (Genehmigte Patches) in Ihrer Patch-Baseline ein, um die Anwendung aller Patches einschließlich Nebenversionsupgrades auf Ihren von RHEL 7.\$1 verwalteten Knoten sicherzustellen. (Wenn Sie den genauen Paketnamen eines Nebenversionspatches kennen, können Sie diesen stattdessen eingeben.)
**Option 3**: Mithilfe des [InstallOverrideList](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-installoverridelist)Parameters im `AWS-RunPatchBaseline` Dokument haben Sie die größtmögliche Kontrolle darüber, welche Patches auf Ihre verwalteten Knoten angewendet werden, einschließlich kleinerer Versions-Upgrades. Weitere Informationen finden Sie unter [SSM-Befehlsdokument zum Patchen: `AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md).
+ **Schweregrad**: Der Schweregradwert von Patches, auf den die Regel anzuwenden ist, z. B. `Critical`. Die Standardauswahl ist `All`.
+ **Automatische Genehmigung**: Die Methode zum Auswählen von Patches für die automatische Genehmigung.
**Anmerkung**
Da es nicht möglich ist, die Veröffentlichungsdaten von Updatepaketen für Ubuntu Server zuverlässig zu bestimmen, werden die Optionen für die automatische Genehmigung für dieses Betriebssystem nicht unterstützt.
+ **Approve patches after a specified number of days** (Patches nach einer bestimmten Anzahl von Tagen genehmigen): Die Anzahl der Tage, die der Patch Manager warten muss, nachdem ein Patch veröffentlicht oder zuletzt aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten.
+ **Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden**: Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 7. Juli 2023 angeben, werden Patches, die am oder nach dem 8. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert.
+ (Optional) **Konformitätsbericht **: Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. `Critical` oder `High`).
**Anmerkung**
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.
+ **Include non-security updates (Nicht sicherheitsrelevante Updates einbeziehen)**: Aktivieren Sie das Kontrollkästchen zum Installieren von nicht sicherheitsrelevanten Linux-Betriebssystem-Patches, die im Quell-Repository verfügbar gemacht wurden, zusätzlich zu den sicherheitsrelevanten Patches.
Weitere Informationen zum Arbeiten mit Genehmigungsregeln in einer benutzerdefinierten Patch-Baseline finden Sie unter [Benutzerdefinierte Baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).
1. Wenn Sie zusätzlich zu den Patches, die Ihren Genehmigungsregeln entsprechen, alle Patches ausdrücklich genehmigen möchten, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
+ Geben Sie im Feld **Genehmigte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie genehmigen möchten.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
+ (Optional) Weisen Sie in der Liste **Compliance-Stufe genehmigter Patches** den Patches in der Liste eine Compliance-Stufe zu.
+ Wenn genehmigte Patches, die Sie angeben, nicht sicherheitsbezogen sind, wählen Sie das Kästchen **Genehmigte Patches umfassen nicht sicherheitsrelevante Updates** aus, damit diese Patches ebenfalls auf Ihrem Linux-Betriebssystem installiert werden.
1. Wenn Sie Patches ablehnen möchten, die ansonsten Ihren Genehmigungsregeln entsprechen, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
+ Geben Sie im Feld **Abgelehnte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie ablehnen möchten.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
+ Wählen Sie in der Liste **Aktion für abgelehnte Patches** die Aktion aus, die Patch Manager für Patches in der Liste **Abgelehnte Patches** ausführen soll.
+ **Als Abhängigkeit zulassen**: Ein Paket in der Liste **Abgelehnte Patches** wird nur installiert, wenn es sich um eine Abhängigkeit eines anderen Pakets handelt. Es gilt als konform mit der Patch-Baseline und sein Status wird als gemeldet *InstalledOther*. Dies ist die Standardaktion, wenn keine Option ausgewählt ist.
+ **Blockieren**: Pakete in der Liste **Abgelehnte Patches** und Pakete, die diese als Abhängigkeiten enthalten, werden unter keinen Umständen von Patch Manager installiert. Wenn ein Paket installiert wurde, bevor es zur Liste der **abgelehnten Patches** hinzugefügt wurde, oder danach außerhalb von Patch Manager installiert wird, gilt es als nicht konform mit der Patch-Baseline und sein Status wird als *InstalledRejected* gemeldet.
**Anmerkung**
Patch Manager sucht rekursiv nach Patch-Abhängigkeiten.
1. **(Optional) Wenn Sie alternative Patch-Repositorys für verschiedene Versionen eines Betriebssystems angeben möchten, z. B. *AmazonLinux2016.03 und *AmazonLinux2017.09**, gehen Sie für jedes Produkt im Abschnitt Patch-Quellen wie folgt vor:**
+ Geben Sie in **Name (Name)** einen Namen ein, um Sie bei der Identifizierung der Quellkonfiguration zu unterstützen.
+ Wählen Sie unter **Product (Produkt)** die Version der Betriebssysteme aus, für die das Patch-Quell-Repository bestimmt ist, z. B. `RedhatEnterpriseLinux7.4`.
+ Geben Sie unter **Konfiguration** den Wert der zu verwendenden Repository-Konfiguration im entsprechenden Format ein:
------
#### [ Example for yum repositories ]
```
[main]
name=MyCustomRepository
baseurl=https://my-custom-repository
enabled=1
```
**Tipp**
Informationen zu anderen Optionen für Ihre Yum-Repository-Konfiguration finden Sie unter [dnf.conf (5)](https://man7.org/linux/man-pages/man5/dnf.conf.5.html).
------
#### [ Examples for Ubuntu Server and Debian Server ]
`deb http://security.ubuntu.com/ubuntu jammy main`
`deb https://site.example.com/debian distribution component1 component2 component3`
Repository-Informationen für Ubuntu Server-Repositorys müssen in einer einzigen Zeile angegeben werden. Weitere Beispiele und Informationen finden Sie unter [jammy (5) sources.list.5.gz](https://manpages.ubuntu.com/manpages/jammy/man5/sources.list.5.html) auf der Website *Ubuntu Server Manuals* und unter [sources.list-Format](https://wiki.debian.org/SourcesList#sources.list_format) im *Debian-Wiki*.
------
Wählen Sie **Add another source** aus, um ein Quell-Repository für jede zusätzliche Betriebssystemversion anzugeben, bis maximal 20.
Weitere Informationen über alternative Quell-Patch-Repositorys finden Sie unter [So geben Sie ein alternatives Patch-Quell-Repository an (Linux)](patch-manager-alternative-source-repository.md).
1. (Optional) Wenden Sie unter **Tags verwalten** ein oder mehrere name/value Tag-Schlüsselpaare auf die Patch-Baseline an.
Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Sie können beispielsweise eine Patch-Baseline kennzeichnen, um den Schweregrad der angegebenen Patches, die Betriebssystemfamilie, auf die sie sich bezieht, und den Umgebungstyp zu identifizieren. In diesem Fall könnten Sie Tags angeben, die den folgenden name/value Schlüsselpaaren ähneln:
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. Wählen Sie die Option **Patch-Baseline erstellen**.
# Erstellen einer benutzerdefinierten Patch-Baseline für macOS
Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte Patch-Baseline für macOS-verwaltete Knoten in Patch Manager zu erstellen, einem Tool in AWS Systems Manager.
Informationen zum Erstellen einer Patch-Baseline für Windows Server-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server](patch-manager-create-a-patch-baseline-for-windows.md). Informationen zum Erstellen einer Patch-Baseline für Linux-verwaltete Knoten finden Sie unter [So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux](patch-manager-create-a-patch-baseline-for-linux.md).
**Anmerkung**
macOSwird nicht in allen unterstützt AWS-Regionen. Weitere Informationen zur Amazon-EC2-Unterstützung für macOS finden Sie unter [Amazon-EC2-Mac-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-mac-instances.html) im *Amazon-EC2-Benutzerhandbuch*.
**So erstellen Sie eine benutzerdefinierte Patch-Baseline für macOS-verwaltete Knoten**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Patch-Baselines** und dann **Patch-Baseline erstellen** aus.
–oder–
Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen**, wechseln Sie zur Registerkarte **Patch-Baselines** und wählen Sie dann **Patch-Baseline** erstellen.
1. Geben Sie im Feld **Name** einen Namen für die neue Patch-Baseline ein, z. B. `MymacOSPatchBaseline`.
1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für diese Patch-Baseline ein.
1. Wählen Sie unter **Betriebssystem** die Option macOS aus.
1. Wenn Sie die Patch-Baseline direkt nach dem Erstellen als Standard für macOS verwenden möchten, aktivieren Sie das Kontrollkästchen **Set this patch baseline as the default patch baseline for macOS instances (Diese Patch-Baseline als Standard-Patch-Baseline für macOs-Instances festlegen)**.
**Anmerkung**
Diese Option ist nur verfügbar, wenn Sie vor der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.
Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).
1. Erstellen Sie im Abschnitt **Genehmigungsregeln für Betriebssysteme** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
+ **Produkte**: Die Version der Betriebssysteme, auf die sich die Genehmigungsregel bezieht, z. B. `BigSur11.3.1` oder `Ventura13.7`. Die Standardauswahl ist `All`.
+ **Klassifizierung**: Der oder die Paketmanager, auf den/die während des Patchvorgangs Pakete angewendet werden sollen. Sie können aus den folgenden Optionen auswählen:
+ softwareupdate
+ installer
+ brew
+ brew cask
Die Standardauswahl ist `All`.
+ (Optional) **Konformitätsbericht **: Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. `Critical` oder `High`).
**Anmerkung**
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.
Weitere Informationen zum Arbeiten mit Genehmigungsregeln in einer benutzerdefinierten Patch-Baseline finden Sie unter [Benutzerdefinierte Baselines](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom).
1. Wenn Sie zusätzlich zu den Patches, die Ihren Genehmigungsregeln entsprechen, alle Patches ausdrücklich genehmigen möchten, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
+ Geben Sie im Feld **Genehmigte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie genehmigen möchten.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
+ (Optional) Weisen Sie in der Liste **Compliance-Stufe genehmigter Patches** den Patches in der Liste eine Compliance-Stufe zu.
1. Wenn Sie Patches ablehnen möchten, die ansonsten Ihren Genehmigungsregeln entsprechen, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
+ Geben Sie im Feld **Abgelehnte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie ablehnen möchten.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
+ Wählen Sie in der Liste **Aktion für abgelehnte Patches** die Aktion aus, die Patch Manager für Patches in der Liste **Abgelehnte Patches** ausführen soll.
+ **Als Abhängigkeit zulassen**: Ein Paket in der Liste **Abgelehnte Patches** wird nur installiert, wenn es sich um eine Abhängigkeit eines anderen Pakets handelt. Es gilt als konform mit der Patch-Baseline und sein Status wird als gemeldet *InstalledOther*. Dies ist die Standardaktion, wenn keine Option ausgewählt ist.
+ **Blockieren**: Pakete in der Liste **Abgelehnte Patches** und Pakete, die diese als Abhängigkeiten enthalten, werden unter keinen Umständen von Patch Manager installiert. Wenn ein Paket installiert wurde, bevor es zur Liste der **abgelehnten Patches** hinzugefügt wurde, oder danach außerhalb von Patch Manager installiert wird, gilt es als nicht konform mit der Patch-Baseline und sein Status wird als *InstalledRejected* gemeldet.
1. (Optional) Wenden **Sie unter Tags verwalten** ein oder mehrere name/value Tag-Schlüsselpaare auf die Patch-Baseline an.
Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Sie können beispielsweise eine Patch-Baseline kennzeichnen, um den Schweregrad der angegebenen Patches, den Paketmanager, auf den sie sich bezieht, und den Umgebungstyp zu identifizieren. In diesem Fall könnten Sie Tags angeben, die den folgenden name/value Schlüsselpaaren ähneln:
+ `Key=PatchSeverity,Value=Critical`
+ `Key=PackageManager,Value=softwareupdate`
+ `Key=Environment,Value=Production`
1. Wählen Sie die Option **Patch-Baseline erstellen**.
# Erstellen einer benutzerdefinierten Patch-Baseline für Windows Server
Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte Patch-Baseline für Windows-verwaltete Knoten in Patch Manager zu erstellen, einem Tool in AWS Systems Manager.
Informationen zum Erstellen einer Patch-Baseline für Linux-verwaltete Knoten finden Sie unter [So erstellen Sie eine benutzerdefinierte Patch-Baseline für Linux](patch-manager-create-a-patch-baseline-for-linux.md). Informationen zum Erstellen einer Patch-Baseline für macOS-verwaltete Knoten finden Sie unter [Erstellen einer benutzerdefinierten Patch-Baseline für macOS](patch-manager-create-a-patch-baseline-for-macos.md).
Ein Beispiel für das Erstellen einer Patch-Baseline, die auf die Installation von Windows Service Packs eingeschränkt ist, finden Sie unter [So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs mithilfe der Konsole](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
**So erstellen Sie eine benutzerdefinierte Patch-Baseline (Windows)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Patch-Baselines** und dann **Patch-Baseline erstellen** aus.
–oder–
Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen**, wechseln Sie zur Registerkarte **Patch-Baselines** und wählen Sie dann **Patch-Baseline** erstellen.
1. Geben Sie im Feld **Name** einen Namen für die neue Patch-Baseline ein, z. B. `MyWindowsPatchBaseline`.
1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für diese Patch-Baseline ein.
1. Wählen Sie unter **Betriebssystem** die Option `Windows` aus.
1. Wählen Sie unter **Compliance-Status für verfügbare Sicherheitsupdates** den Status aus, den Sie Sicherheitspatches zuweisen möchten, die zwar verfügbar, aber nicht genehmigt sind, weil sie die in der Patch-Baseline angegebenen Installationskriterien (**Nicht konform** oder **Konform**) nicht erfüllen.
Beispielszenario: Sicherheitspatches, die Sie möglicherweise installieren möchten, können übersprungen werden, wenn Sie eine lange Wartezeit für die Installation nach der Veröffentlichung eines Patches angegeben haben. Wenn während der von Ihnen angegebenen Wartezeit ein Update für den Patch veröffentlicht wird, beginnt die Wartezeit für die Installation des Patches von vorne. Wenn die Wartezeit zu lang ist, können mehrere Versionen des Patches veröffentlicht, aber nie installiert werden.
1. Wenn Sie diese Patch-Baseline direkt nach dem Erstellen als Standard für Windows verwenden möchten, wählen Sie **Set this patch baseline as the default patch baseline for Windows Server instances (Diese Patch-Baseline als Standard-Patch-Baseline für Windows Server-Instances festlegen)** aus.
**Anmerkung**
Diese Option ist nur verfügbar, wenn Sie vor der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.
Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).
1. Erstellen Sie im Abschnitt **Approval Rules for operating-systems (Genehmigungsregeln für Betriebssysteme)** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
+ **Produkte**: Die Version der Betriebssysteme, auf die sich die Genehmigungsregel bezieht, z. B. `WindowsServer2012`. Die Standardauswahl ist `All`.
+ **Classification (Klassifizierung)**: Der Typ der Patches, auf die sich die Genehmigungsregel bezieht, z. B. `CriticalUpdates`, `Drivers` und `Tools`. Die Standardauswahl ist `All`.
**Tipp**
Sie können Windows Service Pack-Installationen in die Genehmigungsregeln einschließen, indem Sie die `ServicePacks` einschließen oder `All` in der Liste **Classification (Klassifizierung)** auswählen. Ein Beispiel finden Sie unter [So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs mithilfe der Konsole](patch-manager-windows-service-pack-patch-baseline-tutorial.md).
+ **Schweregrad**: Der Schweregradwert von Patches, auf den die Regel anzuwenden ist, z. B. `Critical`. Die Standardauswahl ist `All`.
+ **Automatische Genehmigung**: Die Methode zum Auswählen von Patches für die automatische Genehmigung.
+ **Patches nach einer bestimmten Anzahl von Tagen genehmigen**: Die Anzahl der Tage, die der Patch Manager warten muss, nachdem ein Patch veröffentlicht oder aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten.
+ **Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden**: Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 07. Juli 2023 angeben, werden Patches, die am oder nach dem 08. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert.
+ (Optional) **Compliance-Bericht **: Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. `High`).
**Anmerkung**
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.
1. (Optional) Erstellen Sie im Abschnitt **Approval Rules for applications (Genehmigungsregeln für Anwendungen)** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
**Anmerkung**
Anstatt Genehmigungsregeln anzugeben, können Sie Listen genehmigter und abgelehnter Patches als Patch-Ausnahmen angeben. Siehe Schritte 10 und 11.
+ **Product family (Produktfamilie)**: Die allgemeine Microsoft-Produktfamilie, für die Sie eine Regel festlegen möchten, z. B. `Office` oder `Exchange Server`.
+ **Produkte**: Die Version der Anwendung, auf die sich die Genehmigungsregel bezieht, z. B. `Office 2016` oder `Active Directory Rights Management Services Client 2.0 2016`. Die Standardauswahl ist `All`.
+ **Classification (Klassifikation)**: Der Typ der Patches, auf die sich die Genehmigungsregel bezieht, z. B. `CriticalUpdates`. Die Standardauswahl ist `All`.
+ **Severity (Schweregrad)**: Der Schweregradwert von Patches, auf den die Regel anzuwenden ist, z. B. `Critical`. Die Standardauswahl ist `All`.
+ **Automatische Genehmigung**: Die Methode zum Auswählen von Patches für die automatische Genehmigung.
+ **Patches nach einer bestimmten Anzahl von Tagen genehmigen**: Die Anzahl der Tage, die der Patch Manager warten muss, nachdem ein Patch veröffentlicht oder aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten.
+ **Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden**: Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 7. Juli 2023 angeben, werden Patches, die am oder nach dem 8. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert.
+ (Optional) **Konformitätsbericht **: Der Schweregrad, den Sie Patches zuweisen möchten, die von der Baseline genehmigt wurden (z. B. `Critical` oder `High`).
**Anmerkung**
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Patches als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.
1. (Optional) Wenn Sie Patches explizit genehmigen möchten, anstatt Patches gemäß Genehmigungsregeln auszuwählen, gehen Sie im Abschnitt **Patch-Ausnahmen** folgendermaßen vor:
+ Geben Sie im Feld **Genehmigte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie genehmigen möchten.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
+ (Optional) Weisen Sie in der Liste **Compliance-Stufe genehmigter Patches** den Patches in der Liste eine Compliance-Stufe zu.
1. Wenn Sie Patches ablehnen möchten, die ansonsten Ihren Genehmigungsregeln entsprechen, gehen Sie im Abschnitt **Patch-Ausnahmen** wie folgt vor:
+ Geben Sie im Feld **Abgelehnte Patches** eine durch Komma getrennte Liste der Patches ein, die Sie ablehnen möchten.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](patch-manager-approved-rejected-package-name-formats.md).
+ Wählen Sie in der Liste **Aktion für abgelehnte Patches** die Aktion aus, die Patch Manager für Patches in der Liste **Abgelehnte Patches** ausführen soll.
+ **Als Abhängigkeit zulassen**: unterstützt das Konzept der Paketabhängigkeiten Windows Server nicht. Wenn ein Paket in der Liste der **abgelehnten Patches** enthalten ist und bereits auf dem Knoten installiert ist, wird sein Status als `INSTALLED_OTHER` gemeldet. Jedes Paket, das noch nicht auf dem Knoten installiert ist, wird übersprungen.
+ **Blockieren**: Pakete in der Liste der **abgelehnten Patches** werden von Patch Manager unter keinen Umständen installiert. Wenn ein Paket installiert wurde, bevor es zur Liste der **abgelehnten Patches** hinzugefügt wurde, oder danach außerhalb von Patch Manager installiert wird, gilt es als nicht konform mit der Patch-Baseline und sein Status wird als `INSTALLED_REJECTED` gemeldet.
Weitere Informationen zu Aktionen für abgelehnte Pakete finden Sie unter [Optionen für die Liste abgelehnter Patches in benutzerdefinierten Patch-Baselines](patch-manager-windows-and-linux-differences.md#rejected-patches-diff).
1. (Optional) Wenden **Sie unter Tags verwalten** ein oder mehrere name/value Tag-Schlüsselpaare auf die Patch-Baseline an.
Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Sie können beispielsweise eine Patch-Baseline kennzeichnen, um den Schweregrad der angegebenen Patches, die Betriebssystemfamilie, auf die sie sich bezieht, und den Umgebungstyp zu identifizieren. In diesem Fall könnten Sie Tags angeben, die den folgenden name/value Schlüsselpaaren ähneln:
+ `Key=PatchSeverity,Value=Critical`
+ `Key=OS,Value=RHEL`
+ `Key=Environment,Value=Production`
1. Wählen Sie die Option **Patch-Baseline erstellen**.
# Aktualisieren oder Löschen einer benutzerdefinierten Patch-Baseline
Sie können eine benutzerdefinierte Patch-Baseline, die Sie erstellt haben, in Patch Manager, einem Tool in AWS Systems Manager, aktualisieren oder löschen. Wenn Sie eine Patch-Baseline aktualisieren, können Sie deren Namen oder Beschreibung, die Genehmigungsregeln sowie die Ausnahmen für genehmigte und abgelehnte Patches ändern. Sie können auch die Tags aktualisieren, die auf die Patch-Baseline angewendet werden. Sie können den Betriebssystemtyp, für den eine Patch-Baseline erstellt wurde, nicht ändern, und Sie können keine Änderungen an einer vordefinierten Patch-Baseline vornehmen, die von bereitgestellt wird AWS.
## Aktualisieren oder Löschen einer Patch-Baseline
Gehen Sie wie folgt vor, um eine Patch-Baseline zu aktualisieren oder zu löschen.
**Wichtig**
Gehen Sie vorsichtig vor, wenn Sie eine benutzerdefinierte Patch-Baseline löschen, die möglicherweise von einer Patch-Richtlinienkonfiguration in Quick Setup verwendet wird.
Wenn Sie eine [Patch-Richtlinienkonfiguration](patch-manager-policies.md) in Quick Setup verwenden, werden Aktualisierungen, die Sie an benutzerdefinierten Patch-Baselines vornehmen, einmal pro Stunde mit Quick Setup synchronisiert.
Wenn eine benutzerdefinierte Patch-Baseline gelöscht wird, auf die in einer Patch-Richtlinie verwiesen wurde, wird auf der Seite mit den Quick Setup-**Konfigurationsdetails** ein Banner für Ihre Patch-Richtlinie angezeigt. Das Banner informiert Sie darüber, dass die Patch-Richtlinie auf eine nicht mehr vorhandene Patch-Baseline verweist und nachfolgende Patching-Vorgänge fehlschlagen werden. Kehren Sie in diesem Fall zur Seite Quick Setup-**Konfigurationen** zurück, wählen Sie die Patch Manager-Konfiguration aus und wählen Sie **Aktionen**, **Konfiguration bearbeiten**. Der Name der gelöschten Patch-Baseline wird hervorgehoben, und Sie müssen eine neue Patch-Baseline für das betroffene Betriebssystem auswählen.
**So aktualisieren oder löschen Sie eine Patch-Baseline**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Patch-Baseline aus, die Sie aktualisieren oder löschen möchten, und führen Sie dann einen der folgenden Schritte aus:
+ Um die Patch-Baseline aus Ihrem zu entfernen AWS-Konto, wählen Sie **Löschen**. Sie werden aufgefordert, Ihre Aktionen zu bestätigen.
+ Wenn Sie den Namen oder die Beschreibung, die Genehmigungsregeln oder Patch-Ausnahmen der Patch-Baseline ändern möchten, wählen Sie **Edit (Bearbeiten)** aus. Nehmen Sie auf der Seite **Edit patch baseline (Patch-Baseline bearbeiten)** die gewünschten Änderungen vor und klicken Sie dann auf **Save changes (Änderungen speichern)**.
+ Wenn Sie auf die Patch-Baseline angewendete Tags hinzufügen, ändern oder löschen möchten, klicken Sie auf die Registerkarte **Tags (Tags)** und dann auf **Edit tags (Tags bearbeiten)**. Nehmen Sie auf der Seite **Edit patch baseline tags (Patch-Baseline-Tags bearbeiten)** die gewünschten Änderungen vor und klicken Sie dann auf **Save changes (Änderungen speichern)**.
Weitere Informationen zu den Konfigurationsoptionen, die Sie ausführen können, finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).
# Festlegen einer vorhandenen Patch-Baseline als Standard
**Wichtig**
Alle hier getroffenen Standardauswahlen für die Patch-Baseline gelten nicht für Patching-Vorgänge, die auf einer Patch-Richtlinie basieren. Patch-Richtlinien verwenden ihre eigenen Patch-Baseline-Spezifikationen. Weitere Informationen zu Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).
Bereits beim Erstellen einer benutzerdefinierten Patch-Baseline in Patch Manager, einem Tool in AWS Systems Manager, können Sie die Baseline als Standard für den zugehörigen Betriebssystemtyp festlegen. Weitere Informationen finden Sie unter [Arbeiten mit benutzerdefinierten Patch-Baselines](patch-manager-manage-patch-baselines.md).
Sie können auch eine vorhandene Patch-Baseline als Standard für einen Betriebssystemtyp festlegen.
**Anmerkung**
Welche Schritte Sie ausführen, hängt davon ab, ob Sie vor oder nach der Veröffentlichung der Patch-Richtlinien am 22. Dezember 2022 auf Patch Manager zugegriffen haben. Wenn Sie Patch Manager vor diesem Datum verwendet haben, können Sie das Konsolenverfahren verwenden. Verwenden Sie andernfalls das AWS CLI Verfahren. Das Menü **Aktionen**, auf das im Konsolenverfahren verwiesen wird, wird in Regionen, in denen Patch Manager vor der Veröffentlichung der Patch-Richtlinien nicht verwendet wurde, nicht angezeigt.
**So legen Sie eine Patch-Baseline als Standard fest**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Patch-Baselines** aus.
1. Wählen Sie in der Liste der Patch-Baselines die Schaltfläche einer Patch-Baseline aus, die derzeit nicht als Standard für ein Betriebssystem festgelegt ist.
Die Spalte **Default baseline (Standard-Baseline)** gibt an, welche Baselines derzeit als Standardwerte festgelegt sind.
1. Wählen Sie im Menü **Actions (Aktionen)** die Option **Set default patch baseline (Standard-Patch-Baseline festlegen)** aus.
**Wichtig**
Das **Aktionsmenü** ist nicht verfügbar, wenn Sie nicht vor dem 22. Dezember 2022 mit Patch Manager in der aktuellen Version AWS-Konto und in der Region gearbeitet haben. Weitere Informationen finden Sie in der **Anmerkung** weiter oben in diesem Thema.
1. Wählen Sie im Bestätigungsdialogfeld **Set default (Als Standard festlegen)** aus.
**So legen Sie eine Patch-Baseline als Standard fest (AWS CLI)**
1. Führen Sie den [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)Befehl aus, um eine Liste der verfügbaren Patch-Baselines IDs und ihrer Amazon-Ressourcennamen () ARNs anzuzeigen.
```
aws ssm describe-patch-baselines
```
1. Führen Sie den Befehl [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) aus, um eine Baseline als Standard für das Betriebssystem festzulegen, mit dem sie verknüpft ist. *baseline-id-or-ARN*Ersetzen Sie ihn durch die ID der benutzerdefinierten Patch-Baseline oder der vordefinierten Baseline, die verwendet werden soll.
------
#### [ Linux & macOS ]
```
aws ssm register-default-patch-baseline \
--baseline-id baseline-id-or-ARN
```
Im Folgenden finden Sie ein Beispiel für die Festlegung einer benutzerdefinierten Baseline als Standard.
```
aws ssm register-default-patch-baseline \
--baseline-id pb-abc123cf9bEXAMPLE
```
Im Folgenden finden Sie ein Beispiel für die Einstellung einer vordefinierten Baseline, die AWS standardmäßig verwaltet wird.
```
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
```
Im Folgenden finden Sie ein Beispiel für die Festlegung einer benutzerdefinierten Baseline als Standard.
```
aws ssm register-default-patch-baseline ^
--baseline-id pb-abc123cf9bEXAMPLE
```
Im Folgenden finden Sie ein Beispiel für die Einstellung einer vordefinierten Baseline, die AWS standardmäßig verwaltet wird.
```
aws ssm register-default-patch-baseline ^
--baseline-id arn:aws:ssm:us-east-2:733109147000:patchbaseline/pb-071da192df1226b63
```
------
# Anzeigen verfügbarer Patches
MitPatch Manager, einem Tool in AWS Systems Manager, können Sie alle verfügbaren Patches für ein bestimmtes Betriebssystem und optional eine bestimmte Betriebssystemversion anzeigen.
**Tipp**
Um eine Liste verfügbarer Patches zu generieren und diese in einer Datei zu speichern, können Sie den Befehl [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) verwenden und Ihre bevorzugte [Ausgabe](https://docs.aws.amazon.com/cli/latest/reference/ssm/cli-usage-output.html) angeben.
**Anzeigen verfügbarer Patches**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Patches** aus.
–oder–
Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen** und dann die Registerkarte **Patches** aus.
**Anmerkung**
Für Windows Server zeigt die Registerkarte **Patches** Updates an, die vom Windows Server Update Service (WSUS) verfügbar sind.
1. Für **Betriebssystem** wählen Sie das Betriebssystem aus, für das Sie verfügbare Patches anzeigen möchten, z. B. `Windows` oder `Amazon Linux`.
1. (Optional) Für **Product (Produkt)** wählen Sie eine Betriebssystemversion aus, z. B. `WindowsServer2019` oder `AmazonLinux2018.03`.
1. (Optional) Um Informationsspalten für Ihre Ergebnisse hinzuzufügen oder zu entfernen, wählen Sie die Konfigurationsschaltfläche (![\[The icon to view configuration settings.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/configure-button.png)) oben rechts in der Liste **Patches** aus. (Standardmäßig zeigt die Registerkarte **Patches** nur Spalten für einige der verfügbaren Patch-Metadaten an.)
Informationen zu den Arten von Metadaten, die Sie Ihrer Ansicht hinzufügen können, finden Sie unter [Patch](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_Patch.html) in der *AWS Systems Manager -API-Referenz*.
# Erstellen und Verwalten von Patch-Gruppen
Wenn Sie in Ihrem Betrieb *keine* Patching-Richtlinien verwenden, können Sie Ihre Patching-Aufgaben organisieren, indem Sie verwaltete Knoten mithilfe von Tags zu Patch-Gruppen hinzufügen.
**Anmerkung**
Patch-Gruppen werden nicht in Patch-Vorgängen verwendet, die auf *Patch-Richtlinien* basieren. Weitere Informationen zur Arbeit mit Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).
Die Patchgruppenfunktion wird in der Konsole für Konto-Regionen-Paare nicht unterstützt, die vor der Veröffentlichung der Patch-Richtlinienunterstützung am 22. Dezember 2022 noch keine Patchgruppen verwendet haben. Die Patchgruppenfunktion ist weiterhin für Konto-Regionen-Paare verfügbar, die vor diesem Datum mit der Verwendung von Patchgruppen begonnen haben.
Um Tags bei Patching-Operationen zu verwenden, müssen Sie den Tag-Schlüssel `Patch Group` oder `PatchGroup` auf Ihre verwalteten Knoten anwenden. Sie müssen auch den Namen, den Sie der Patch-Gruppe geben möchten, als Wert des Tags angeben. Sie können einen beliebigen Tag-Wert angeben, aber der Tag-Schlüssel muss `Patch Group` oder `PatchGroup` lauten.
`PatchGroup` (ohne Leerzeichen) ist erforderlich, wenn Sie [Tags in EC2-Instance-Metadaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS) zugelassen haben.
Nachdem Sie Ihre verwalteten Knoten mithilfe von Tags gruppiert haben, fügen Sie den Patch-Gruppenwert einer Patch-Baseline hinzu. Mit der Registrierung der Patch-Gruppe für eine Patch-Baseline können Sie sicherstellen, dass beim Einspielen von Patches die richtigen Patches installiert werden. Weitere Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md).
Führen Sie die Aufgaben in diesem Thema aus, um Ihre verwalteten Knoten für das Patching vorzubereiten, indem Sie Tags mit Ihren Knoten und der Patch-Baseline verwenden. Aufgabe 1 ist nur erforderlich, wenn Sie Amazon-EC2-Instances patchen. Aufgabe 2 ist nur erforderlich, wenn Sie Nicht-EC2-Instances in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) patchen. Aufgabe 3 ist für alle verwalteten Knoten erforderlich.
**Tipp**
Sie können verwalteten Knoten auch Tags hinzufügen, indem Sie den AWS CLI Befehl `[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)` oder den Systems Manager API-Vorgang ssm-agent-minimum-s `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_AddTagsToResource.html)` 3-permissions-required verwenden.
**Topics**
+ [Aufgabe 1: Hinzufügen von EC2-Instances zu einer Patch-Gruppe mithilfe von Tags](#sysman-patch-group-tagging-ec2)
+ [Aufgabe 2: Hinzufügen von verwalteten Knoten zu einer Patch-Gruppe mithilfe von Tags](#sysman-patch-group-tagging-managed)
+ [Aufgabe 3: Hinzufügen einer Patch-Gruppe zu einer Patch-Baseline](#sysman-patch-group-patchbaseline)
## Aufgabe 1: Hinzufügen von EC2-Instances zu einer Patch-Gruppe mithilfe von Tags
Sie können EC2-Instances über die Systems-Manager-Konsole oder die Amazon-EC2-Konsole Tags hinzufügen. Diese Aufgabe ist nur erforderlich, wenn Sie Amazon-EC2-Instances patchen.
**Wichtig**
Sie können das `Patch Group`-Tag (mit einem Leerzeichen) nicht auf eine Amazon-EC2-Instance anwenden, wenn die Option **Allow tags in instance metadata** (Tags in Instance-Metadaten zulassen) auf der Instance aktiviert ist. Durch das Zulassen von Tags in Instance-Metadaten wird verhindert, dass Tag-Schlüsselnamen Leerzeichen enthalten. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie den Tag-Schlüssel `PatchGroup` (ohne Leerzeichen) verwenden.
**Option 1: So fügen Sie EC2-Instances zu einer Patch-Gruppe hinzu (Systems-Manager-Konsole)**
1. Öffnen Sie die Konsole unter. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie in der Liste **Verwaltete Knoten** die ID einer verwalteten EC2-Instance, die Sie für das Patching konfigurieren möchten. Knoten-IDs für EC2-Instances beginnen mit `i-`.
**Anmerkung**
Wenn Sie die Amazon EC2 EC2-Konsole und verwenden AWS CLI, ist es möglich, `Key = PatchGroup` Or-Tags auf Instances anzuwenden`Key = Patch Group`, die noch nicht für die Verwendung mit Systems Manager konfiguriert sind.
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
1. Wählen Sie die Registerkarte **Tags** und dann **Bearbeiten** aus.
1. Geben Sie in der linken Spalte **Patch Group** oder **PatchGroup** ein. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie `PatchGroup` (ohne Leerzeichen) verwenden.
1. Geben Sie in der rechten Spalte einen Tag-Wert ein, der als Name für die Patch-Gruppe dienen soll.
1. Wählen Sie **Speichern**.
1. Wiederholen Sie dieses Verfahren, um andere EC2-Instances zur selben Patch-Gruppe hinzuzufügen.
**Option 2: So fügen Sie EC2-Instances einer Patch-Gruppe hinzu (Amazon EC2-Konsole)**
1. Öffnen Sie im Navigationsbereich die [Amazon EC2-Konsole](https://console.aws.amazon.com/ec2/) und wählen Sie die Option **Instances** aus.
1. Wählen Sie in der Liste der Instances eine Instance aus, die Sie für das Einspielen von Patches konfigurieren möchten.
1. Wählen Sie im Menü **Aktionen** die Option **Instance-Einstellungen**, **Tags verwalten** aus.
1. Wählen Sie **Neues Tag hinzufügen** aus.
1. Geben Sie für **Key** (Schlüssel) **Patch Group** oder **PatchGroup** ein. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie `PatchGroup` (ohne Leerzeichen) verwenden.
1. Geben Sie für **Wert** einen Wert ein, der als Name für die Patch-Gruppe dienen soll.
1. Wählen Sie **Speichern**.
1. Wiederholen Sie dieses Verfahren, um andere Instances zur selben Patch-Gruppe hinzuzufügen.
## Aufgabe 2: Hinzufügen von verwalteten Knoten zu einer Patch-Gruppe mithilfe von Tags
Folgen Sie den Schritten in diesem Thema, um Tags zu AWS IoT Greengrass Kerngeräten und verwalteten Knoten (mi-\$1) ohne EC2-Hybrid-Aktivierung hinzuzufügen. Diese Aufgabe ist nur erforderlich, wenn Sie Nicht-EC2 Instances in einer Hybrid- und Multi-Cloud-Umgebung patchen.
**Anmerkung**
Sie können über die Amazon-EC2-Konsole keine Tags für Nicht-EC2-verwaltete Knoten hinzufügen.
**So fügen Sie Nicht-EC2-verwaltete Knoten einer Patch-Gruppe hinzu (Systems-Manager-Konsole)**
1. Öffnen Sie die Konsole unter. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Fleet Manager** aus.
1. Wählen Sie in der Liste der **verwalteten Knoten** einen verwalteten Knoten, für den Sie das Patching konfigurieren möchten.
**Anmerkung**
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
1. Wählen Sie die Registerkarte **Tags** und dann **Bearbeiten** aus.
1. Geben Sie in der linken Spalte **Patch Group** oder **PatchGroup** ein. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie `PatchGroup` (ohne Leerzeichen) verwenden.
1. Geben Sie in der rechten Spalte einen Tag-Wert ein, der als Name für die Patch-Gruppe dienen soll.
1. Wählen Sie **Speichern**.
1. Wiederholen Sie dieses Verfahren, um andere verwaltete Knoten zur selben Patch-Gruppe hinzuzufügen.
## Aufgabe 3: Hinzufügen einer Patch-Gruppe zu einer Patch-Baseline
Um Ihren verwalteten Knoten eine bestimmte Patch-Baseline zuzuordnen, müssen Sie den Patch-Gruppenwert der Patch-Baseline hinzufügen. Mit der Registrierung der Patch-Gruppe für eine Patch-Baseline können Sie sicherstellen, dass beim Einspielen von Patches die richtigen Patches installiert werden. Diese Aufgabe ist unabhängig davon erforderlich, ob Sie EC2-Instances, verwaltete Nicht-EC2-Knoten oder beides patchen.
Weitere Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md).
**Anmerkung**
Welche Schritte Sie ausführen, hängt davon ab, ob Sie vor oder nach der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.
**So fügen Sie eine Patch-Gruppe einer Patch-Baseline hinzu (Systems-Manager-Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wenn Sie auf Patch Manager zum ersten Mal in der aktuellen AWS-Region zugreifen und sich die Patch Manager-Startseite öffnet, wählen Sie **Mit einer Übersicht beginnen**.
1. Wählen Sie die Registerkarte **Patch-Baselines** und wählen Sie dann in der Liste **Patch-Baselines** den Namen der Patch-Baseline, die Sie für Ihre Patch-Gruppe konfigurieren möchten.
Wenn Sie erst nach der Veröffentlichung der Patch-Richtlinien auf Patch Manager zugegriffen haben, müssen Sie eine von Ihnen erstellte benutzerdefinierte Baseline wählen.
1. Wenn die Detailseite der **Baseline-ID** ein Menü **Aktionen** enthält, gehen Sie wie folgt vor:
+ Wählen Sie **Actions (Aktionen)** und dann **Modify patch groups (Patch-Gruppen modifizieren)** aus.
+ Geben Sie den *Tag-Wert*, den Sie Ihren verwalteten Knoten in [Aufgabe 2: Hinzufügen von verwalteten Knoten zu einer Patch-Gruppe mithilfe von Tags](#sysman-patch-group-tagging-managed) hinzugefügt haben, und wählen Sie dann **Hinzufügen**.
Wenn die Detailseite der **Baseline-ID** *kein* Menü **Aktionen** enthält, können Patch-Gruppen in der Konsole nicht konfiguriert werden. Sie können stattdessen eine der folgenden Aktionen ausführen:
+ (Empfohlen) Richten Sie eine Patch-Richtlinie in Quick Setup, einem Tool in AWS Systems Manager, ein, um eine Patch-Baseline einer oder mehreren EC2-Instances zuzuordnen.
Weitere Informationen finden Sie unter [Verwenden von Quick Setup-Patch-Richtlinien](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) und [Automatisieren des unternehmensweiten Patchen mithilfe einer Quick Setup-Patch-Richtlinie](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
+ Verwenden Sie den [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)Befehl in AWS Command Line Interface (AWS CLI), um eine Patchgruppe zu konfigurieren.
# Integrieren Patch Manager mit AWS Security Hub CSPM
[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)bietet Ihnen einen umfassenden Überblick über Ihren Sicherheitsstatus in. AWS Security Hub CSPM sammelt Sicherheitsdaten von allen AWS-Konten und unterstützten Produkten von Drittanbietern. AWS-Services Mit Security Hub CSPM können Sie Ihre Umgebung anhand von Branchenstandards und Best Practices überprüfen. Security Hub CSPM hilft Ihnen dabei, Ihre Sicherheitstrends zu analysieren und Sicherheitsprobleme mit der höchsten Priorität zu identifizieren.
Mithilfe der Integration zwischenPatch Manager, einem Tool in AWS Systems Manager und Security Hub CSPM können Sie Erkenntnisse über nicht konforme Knoten von Patch Manager an Security Hub CSPM senden. Ein Ergebnis ist der beobachtbare Datensatz einer Sicherheitsprüfung oder sicherheitsrelevanten Erkennung. Security Hub CSPM kann diese patch-bezogenen Ergebnisse dann in die Analyse Ihres Sicherheitsstatus einbeziehen.
Die Informationen in den folgenden Themen gelten unabhängig davon, welche Methode oder Art der Konfiguration Sie für Ihre Patching-Vorgänge verwenden:
+ Eine in Quick Setup konfigurierte Patch-Richtlinie
+ Eine in Quick Setup konfigurierte Host-Management-Option
+ Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
+ Ein On-Demand-**Jetzt patchen**-Vorgang
**Contents**
+ [So sendet Patch Manager Erkenntnisse an Security Hub CSPM](#securityhub-integration-sending-findings)
+ [Arten von Erkenntnissen, die Patch Manager sendet](#securityhub-integration-finding-types)
+ [Latenz für das Senden von Erkenntnissen](#securityhub-integration-finding-latency)
+ [Wiederholung, wenn Security Hub CSPM nicht verfügbar ist](#securityhub-integration-retry-send)
+ [Ergebnisse in Security Hub CSPM anzeigen](#securityhub-integration-view-findings)
+ [Typische Erkenntnis von Patch Manager](#securityhub-integration-finding-example)
+ [Aktivieren und Konfigurieren der Integration](#securityhub-integration-enable)
+ [So beenden Sie das Senden von Ergebnissen](#securityhub-integration-disable)
## So sendet Patch Manager Erkenntnisse an Security Hub CSPM
In Security Hub CSPM werden Sicherheitsprobleme als Erkenntnisse verfolgt. Einige Ergebnisse stammen aus Problemen, die von anderen AWS-Services oder von Drittanbietern entdeckt wurden. Security Hub CSPM verfügt außerdem über eine Reihe von Regeln, anhand derer Sicherheitsprobleme erkannt und Ergebnisse generiert werden.
Patch Managerist eines der Systems Manager Manager-Tools, das Ergebnisse an Security Hub CSPM sendet. Nachdem Sie einen Patchvorgang durchgeführt haben, indem Sie ein SSM-Dokument (`AWS-RunPatchBaseline`,, oder`AWS-RunPatchBaselineWithHooks`) ausführen`AWS-RunPatchBaselineAssociation`, werden die Patching-Informationen an Inventory oder Compliance, Tools in oder an beide gesendet. AWS Systems Manager Nachdem Inventory, Compliance oder beide die Daten erhalten haben, erhält Patch Manager eine Benachrichtigung. Dann wertet Patch Manager die Daten auf Genauigkeit, Formatierung und Compliance aus. Wenn alle Bedingungen erfüllt sind, werden die Daten an Security Hub CSPM Patch Manager weitergeleitet.
Security Hub CSPM bietet Tools zur Verwaltung von Erkenntnissen aus all diesen Quellen. Sie können Listen mit Erkenntnissen anzeigen und filtern und Details zu einer Erkenntnis anzeigen. Weitere Informationen finden Sie unter [Anzeigen der Erkenntnisse](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-viewing.html) im *AWS Security Hub -Benutzerhandbuch*. Sie können auch den Status einer Untersuchung zu einer Erkenntnis nachverfolgen. Weitere Informationen finden Sie unter [Ergreifen von Maßnahmen zu Erkenntnissen](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-taking-action.html) im *AWS Security Hub -Benutzerhandbuch*.
Alle Ergebnisse in Security Hub CSPM verwenden ein standardmäßiges JSON-Format, das AWS Security Finding Format (ASFF). Das ASFF enthält Details über die Ursache des Problems, die betroffenen Ressourcen und den aktuellen Status der Erkenntnis. Weitere Informationen finden Sie unter [AWS -Security Finding-Format (ASFF)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.htm) im *AWS Security Hub -Benutzerhandbuch*.
### Arten von Erkenntnissen, die Patch Manager sendet
Patch Managersendet die Ergebnisse mithilfe des Security [Finding Formats (ASFF) an AWS Security](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) Hub CSPM. In ASFF gibt das `Types`-Feld die Art der Erkenntnis an. Die Ergebnisse von Patch Manager können den folgenden Wert für `Types` haben:
+ Software- und Konfigurationsmanagement Checks/Patch
Patch Manager sendet ein Ergebnis pro nicht konformen verwalteten Knoten. Das Ergebnis wird mit dem Ressourcentyp gemeldet, [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)sodass die Ergebnisse mit anderen Security Hub CSPM-Integrationen, die Ressourcentypen melden, korreliert werden können. `AwsEc2Instance` Patch Managerleitet ein Ergebnis nur dann an Security Hub CSPM weiter, wenn bei dem Vorgang festgestellt wurde, dass der verwaltete Knoten nicht konform ist. Das Ergebnis enthält die Ergebnisse der Patch-Zusammenfassung.
**Anmerkung**
Nach der Meldung eines nicht konformen Knotens an Security Hub CSPM. Patch Managersendet kein Update an Security Hub CSPM, nachdem der Knoten konform gemacht wurde. Sie können die Ergebnisse in Security Hub CSPM manuell beheben, nachdem die erforderlichen Patches auf den verwalteten Knoten angewendet wurden.
Weitere Informationen zu Compliance-Definitionen finden Sie unter [Statuswerte der Patch-Compliance](patch-manager-compliance-states.md). Weitere Informationen zu `PatchSummary` finden Sie [PatchSummary](https://docs.aws.amazon.com//securityhub/1.0/APIReference/API_PatchSummary.html)in der *AWS Security Hub API-Referenz*.
### Latenz für das Senden von Erkenntnissen
Wenn ein neues Ergebnis Patch Manager erstellt wird, wird es normalerweise innerhalb weniger Sekunden bis 2 Stunden an Security Hub CSPM gesendet. Die Geschwindigkeit hängt vom Verkehr zu diesem Zeitpunkt in der AWS-Region verarbeiteten Verkehr ab.
### Wiederholung, wenn Security Hub CSPM nicht verfügbar ist
Bei einem Dienstausfall wird eine AWS Lambda Funktion ausgeführt, mit der die Nachrichten wieder in die Hauptwarteschlange verschoben werden, nachdem der Dienst wieder ausgeführt wird. Nachdem sich die Nachrichten in der Hauptwarteschlange befinden, erfolgt die Wiederholung automatisch.
Wenn Security Hub CSPM nicht verfügbar ist, Patch Manager versucht es erneut, die Ergebnisse zu senden, bis sie empfangen werden.
### Ergebnisse in Security Hub CSPM anzeigen
In diesem Verfahren wird beschrieben, wie Sie in Security Hub CSPM Ergebnisse zu verwalteten Knoten in Ihrer Flotte einsehen können, die nicht mehr patch-konform sind.
**Um die CSPM-Ergebnisse von Security Hub auf Patch-Konformität zu überprüfen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Security Hub CSPM Konsole unter. [https://console.aws.amazon.com/securityhub/](https://console.aws.amazon.com/securityhub/)
1. Wählen Sie im Navigationsbereich **Findings** aus.
1. Wählen Sie das Feld **Filter hinzufügen** (![\[The Search icon\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/search-icon.png)).
1. Wählen Sie im Menü unter **Filter** die Option **Produktname** aus.
1. Wählen Sie in dem sich öffnenden Dialogfeld im ersten Feld die Option **ist** und geben Sie dann **Systems Manager Patch Manager** im zweiten Feld ein.
1. Wählen Sie **Anwenden** aus.
1. Fügen Sie weitere Filter hinzu, um Ihre Ergebnisse einzugrenzen.
1. Wählen Sie in der Ergebnisliste den Titel eines Erkenntnisses aus, zu dem Sie weitere Informationen wünschen.
Auf der rechten Seite des Bildschirms wird ein Bereich mit weiteren Informationen zur Ressource, dem erkannten Problem und einer empfohlenen Lösung geöffnet.
**Wichtig**
Derzeit meldet Security Hub CSPM den Ressourcentyp aller verwalteten Knoten als. `EC2 Instance` Dazu gehören lokale Server und virtuelle Maschinen (VMs), die Sie für die Verwendung mit Systems Manager registriert haben.
**Schweregradklassifizierungen**
Die Liste der Erkenntnisse für **Systems Manager Patch Manager** enthält einen Bericht über den Schweregrad des Befundes. Zu den **Schweregraden** gehören die folgenden, vom niedrigsten zum höchsten:
+ **INFORMATIV** – Es wurde kein Problem gefunden.
+ **NIEDRIG** — Das Problem muss nicht behoben werden.
+ **MITTEL** – Das Problem muss angegangen werden, aber ist nicht dringend.
+ **HOCH** – Das Problem muss vorrangig behandelt werden.
+ **KRITISCH** – Das Problem muss sofort behoben werden, um eine Eskalation zu vermeiden.
Der Schweregrad wird durch das schwerwiegendste nicht konforme Paket auf einer Instance bestimmt. Da Sie mehrere Patch-Baselines mit verschiedenen Schweregraden haben können, wird der höchste Schweregrad von allen nicht konformen Paketen gemeldet. Nehmen wir zum Beispiel an, Sie haben zwei nicht konforme Pakete, wobei der Schweregrad von Paket A „Kritisch“ und der von Paket B „Gering“ ist. „Kritisch“ wird als Schweregrad angegeben werden.
Beachten Sie, dass das Schweregradfeld direkt mit dem Feld Patch Manager `Compliance` korreliert. Dies ist ein Feld, das Sie einzelnen Patches zuweisen, die der Regel entsprechen. Da dieses `Compliance`-Feld einzelnen Patches zugewiesen ist, wird es nicht auf der Ebene der Patch-Zusammenfassung wiedergegeben.
**Verwandter Inhalt**
+ [Erkenntnisse](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings.html) im *AWS Security Hub -Benutzerhandbuch*
+ [Multi-Account Patch-Compliance mit Patch Manager und Security Hub](https://aws.amazon.com/blogs/mt/multi-account-patch-compliance-with-patch-manager-and-security-hub/) im *AWS -Management & Governance Blog*
## Typische Erkenntnis von Patch Manager
Patch Managersendet Ergebnisse mithilfe des Security [Finding Formats (ASFF) an AWS Security](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) Hub CSPM.
Hier ist ein Beispiel für ein typisches Ergebnis von 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"
}
}
```
## Aktivieren und Konfigurieren der Integration
Um die Patch Manager Integration mit Security Hub CSPM zu verwenden, müssen Sie Security Hub CSPM aktivieren. *Informationen zum Aktivieren von Security Hub CSPM finden Sie unter [Security Hub CSPM einrichten im Benutzerhandbuch](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html).AWS Security Hub *
Das folgende Verfahren beschreibt, wie Security Hub CSPM integriert Patch Manager wird, wenn Security Hub CSPM bereits aktiv, aber die Patch Manager Integration ausgeschaltet ist. Sie müssen diesen Vorgang nur abschließen, wenn die Integration manuell deaktiviert wurde.
**Um die CSPM-Integration Patch Manager zur Security Hub hinzuzufügen**
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Einstellungen**.
–oder–
Wenn Sie in der aktuellen AWS-Region zum ersten Mal auf Patch Manager zugreifen, wählen Sie **Mit einer Übersicht beginnen** und dann die Registerkarte **Einstellungen** aus.
1. **Wählen Sie im Abschnitt **Export to Security Hub CSPM** rechts neben Die **Ergebnisse der Patch-Konformität werden nicht nach Security Hub exportiert die** Option Aktivieren aus.**
## So beenden Sie das Senden von Ergebnissen
Um anzugeben, dass keine Erkenntnisse mehr an Security Hub CSPM gesendet werden, können Sie entweder die Konsole von Security Hub CSPM oder die API verwenden.
Weitere Informationen finden Sie in folgenden Themen im *AWS Security Hub -Benutzerhandbuch*:
+ [Deaktivieren und Aktivieren des Flows von Ergebnissen aus einer Integration (Konsole)](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-console)
+ [Deaktivierung des Flusses von Erkenntnissen aus einer Integration (Security Hub CSPM API,) AWS CLI](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-integrations-managing.html#securityhub-integration-findings-flow-disable-api)
# Arbeiten mit Patch Manager-Ressourcen unter Verwendung der AWS CLI
Der Abschnitt enthält Beispiele für AWS Command Line Interface (AWS CLI) -Befehle, mit denen Sie Konfigurationsaufgaben für Patch Manager ein Tool in ausführen können AWS Systems Manager.
Eine Veranschaulichung der Verwendung von AWS CLI zum Patchen einer Serverumgebung mithilfe einer benutzerdefinierten Patch-Baseline finden Sie unter[Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md).
Weitere Informationen zur Verwendung von AWS CLI for AWS Systems Manager Tasks finden Sie im [AWS Systems Manager Abschnitt der AWS CLI Befehlsreferenz](https://docs.aws.amazon.com/cli/latest/reference/ssm/index.html).
**Topics**
+ [AWS CLI Befehle für Patch-Baselines](#patch-baseline-cli-commands)
+ [AWS CLI Befehle für Patchgruppen](#patch-group-cli-commands)
+ [AWS CLI Befehle zum Anzeigen von Patch-Zusammenfassungen und Details](#patch-details-cli-commands)
+ [AWS CLI Befehle zum Scannen und Patchen verwalteter Knoten](#patch-operations-cli-commands)
## AWS CLI Befehle für Patch-Baselines
**Topics**
+ [Erstellen einer Patch-Baseline](#patch-manager-cli-commands-create-patch-baseline)
+ [Erstellen einer Patch-Baseline mit benutzerdefinierten Repositorys für verschiedene Betriebssystemversionen](#patch-manager-cli-commands-create-patch-baseline-mult-sources)
+ [Aktualisieren einer Patch-Baseline](#patch-manager-cli-commands-update-patch-baseline)
+ [Umbenennen einer Patch-Baseline](#patch-manager-cli-commands-rename-patch-baseline)
+ [Löschen einer Patch-Baseline](#patch-manager-cli-commands-delete-patch-baseline)
+ [Auflisten aller Patch-Baselines](#patch-manager-cli-commands-describe-patch-baselines)
+ [Listet alle von AWS-bereitgestellten Patch-Baselines auf](#patch-manager-cli-commands-describe-patch-baselines-aws)
+ [Auflisten der eigenen Patch-Baselines](#patch-manager-cli-commands-describe-patch-baselines-custom)
+ [Anzeigen einer Patch-Baseline](#patch-manager-cli-commands-get-patch-baseline)
+ [Abrufen einer Standard-Patch-Baseline](#patch-manager-cli-commands-get-default-patch-baseline)
+ [Eine benutzerdefinierte Patch-Baseline als Standard festlegen](#patch-manager-cli-commands-register-default-patch-baseline)
+ [Setzen Sie eine AWS Patch-Baseline als Standard zurück](#patch-manager-cli-commands-register-aws-patch-baseline)
+ [Markieren einer Patch-Baseline](#patch-manager-cli-commands-add-tags-to-resource)
+ [Auflisten aller Tags für eine Patch-Baseline](#patch-manager-cli-commands-list-tags-for-resource)
+ [Entfernen eines Tags aus einer Patch-Baseline](#patch-manager-cli-commands-remove-tags-from-resource)
### Erstellen einer Patch-Baseline
Der folgende Befehl erstellt eine Patch-Baseline, die alle kritischen und wichtigen Sicherheitsaktualisierungen für Windows Server 2012 R2 fünf Tage nach ihrer Veröffentlichung genehmigt. Patches wurden auch für die Listen „Genehmigt“ und „Zurückgewiesen“ angegeben. Darüber hinaus wurde die Patch-Baseline mit Tags versehen, um sie für die Produktionsumgebung freizugeben.
------
#### [ 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}]"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Erstellen einer Patch-Baseline mit benutzerdefinierten Repositorys für verschiedene Betriebssystemversionen
Gilt nur für Linux-verwaltete Knoten. Der folgende Befehl zeigt, wie das Patch-Repository für eine bestimmte Version des Amazon Linux-Betriebssystems anzugeben ist. Dieses Beispiel verwendet ein standardmäßig aktiviertes Quell-Repository auf Amazon Linux 2017.09, könnte aber auf ein anderes Quell-Repository angepasst werden, das Sie für einen verwalteten Knoten konfiguriert haben.
**Anmerkung**
Um diesen komplexeren Befehl besser zu erklären, wird die Option `--cli-input-json` mit zusätzlichen, in einer externen JSON-Datei gespeicherten Optionen verwendet.
1. Erstellen Sie eine JSON-Datei mit einem Namen wie `my-patch-repository.json` und fügen Sie den folgenden Inhalt hinzu.
```
{
"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. Führen Sie im Verzeichnis, in dem Sie die Datei gespeichert haben, den folgenden Befehl aus.
```
aws ssm create-patch-baseline --cli-input-json file://my-patch-repository.json
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### Aktualisieren einer Patch-Baseline
Mit dem folgenden Befehl werden zwei Patches abgelehnt und ein weiterer Patch für eine vorhandenen Patch-Baseline genehmigt.
Weitere Informationen zu akzeptierten Formaten für Listen genehmigter und abgelehnter Patches finden Sie unter [Paketnamen-Formate für genehmigte und abgelehnte Patch-Listen](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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
```
### Umbenennen einer Patch-Baseline
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
```
### Löschen einer Patch-Baseline
```
aws ssm delete-patch-baseline --baseline-id "pb-0c10e65780EXAMPLE"
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Auflisten aller Patch-Baselines
```
aws ssm describe-patch-baselines
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
]
}
```
Nachstehend finden Sie einen weiteren Befehl zur Auflistung aller Patch-Baselines in einer AWS-Region.
------
#### [ 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]"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
]
}
```
### Listet alle von AWS-bereitgestellten Patch-Baselines auf
------
#### [ 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]"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"BaselineIdentities":[
{
"BaselineName":"AWS-DefaultPatchBaseline",
"DefaultBaseline":true,
"BaselineDescription":"Default Patch Baseline Provided by AWS.",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
]
}
```
### Auflisten der eigenen Patch-Baselines
------
#### [ 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]"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"BaselineIdentities":[
{
"BaselineName":"Windows-Server-2012R2",
"DefaultBaseline":false,
"BaselineDescription":"Windows Server 2012 R2, Important and Critical security updates",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
]
}
```
### Anzeigen einer Patch-Baseline
```
aws ssm get-patch-baseline --baseline-id pb-0c10e65780EXAMPLE
```
**Anmerkung**
Bei benutzerdefinierten Patch-Baselines können Sie entweder die Patch-Baseline-ID oder den vollständigen Amazon-Ressourcennamen (ARN) angeben. Für eine von AWS-bereitgestellte Patch-Baseline müssen Sie den vollständigen ARN angeben. Beispiel, `arn:aws:ssm:us-east-2:075727635805:patchbaseline/pb-0c10e65780EXAMPLE`.
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
```
### Abrufen einer Standard-Patch-Baseline
```
aws ssm get-default-patch-baseline --region us-east-2
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### Eine benutzerdefinierte Patch-Baseline als Standard festlegen
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Setzen Sie eine AWS Patch-Baseline als Standard zurück
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Markieren einer Patch-Baseline
------
#### [ 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"
```
------
### Auflisten aller Tags für eine Patch-Baseline
------
#### [ 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"
```
------
### Entfernen eines Tags aus einer Patch-Baseline
------
#### [ 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 CLI Befehle für Patchgruppen
**Topics**
+ [Erstellen einer Patch-Gruppe](#patch-manager-cli-commands-create-patch-group)
+ [Registrieren einer Patch-Gruppe „Webserver“ für eine Patch-Baseline](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-web-servers)
+ [Registrieren Sie eine Patch-Gruppe „Backend“ mit der bereitgestellten AWS Patch-Baseline](#patch-manager-cli-commands-register-patch-baseline-for-patch-group-backend)
+ [Anzeigen der Registrierungen für Patch-Gruppen](#patch-manager-cli-commands-describe-patch-groups)
+ [Aufheben der Registrierung einer Patch-Gruppe für eine Patch-Baseline](#patch-manager-cli-commands-deregister-patch-baseline-for-patch-group)
### Erstellen einer Patch-Gruppe
**Anmerkung**
Patch-Gruppen werden nicht in Patch-Vorgängen verwendet, die auf *Patch-Richtlinien* basieren. Weitere Informationen zur Arbeit mit Patch-Richtlinien finden Sie unter [Patch-Richtlinienkonfigurationen in Quick Setup](patch-manager-policies.md).
Um das Organisieren Ihrer Patching-Aufgaben zu erleichtern, empfehlen wir, dass Sie verwaltete Knoten mithilfe von Tags zu Patch-Gruppen hinzufügen. Patch-Gruppen erfordern die Nutzung des Tag-Schlüssels `Patch Group` oder `PatchGroup`. Wenn Sie [Tags in EC2-Instance-Metadaten zugelassen haben](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#allow-access-to-tags-in-IMDS), müssen Sie `PatchGroup` (ohne Leerzeichen) verwenden. Sie können einen beliebigen Tag-Wert angeben, aber der Tag-Schlüssel muss `Patch Group` oder `PatchGroup` lauten. Weitere Informationen zu Patch-Gruppen finden Sie unter [Patch-Gruppen](patch-manager-patch-groups.md).
Nachdem Sie Ihre verwalteten Knoten mithilfe von Tags gruppiert haben, fügen Sie den Patch-Gruppenwert einer Patch-Baseline hinzu. Mit der Registrierung der Patch-Gruppe für eine Patch-Baseline können Sie sicherstellen, dass beim Einspielen von Patches die richtigen Patches installiert werden.
#### Aufgabe 1: Hinzufügen von EC2-Instances zu einer Patch-Gruppe mithilfe von Tags
**Anmerkung**
Wenn Sie die Amazon Elastic Compute Cloud (Amazon EC2) -Konsole und verwenden AWS CLI, ist es möglich, `Key = PatchGroup` Or-Tags auf Instances anzuwenden`Key = Patch Group`, die noch nicht für die Verwendung mit Systems Manager konfiguriert sind. Wenn eine EC2-Instance, die Sie in Patch Manager erwarten, nach dem Anwenden des `Patch Group`-oder `Key = PatchGroup`-Tag nicht aufgeführt ist, finden Sie Tipps zur Fehlerbehebung unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md).
Führen Sie den folgenden Befehl aus, um das Tag `PatchGroup` einer EC2-Instance hinzuzufügen.
```
aws ec2 create-tags --resources "i-1234567890abcdef0" --tags "Key=PatchGroup,Value=GroupValue"
```
#### Aufgabe 2: Hinzufügen von verwalteten Knoten zu einer Patch-Gruppe mithilfe von Tags
Führen Sie den folgenden Befehl aus, um das Tag `PatchGroup` einem verwalteten Knoten hinzuzufügen.
------
#### [ 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"
```
------
#### Aufgabe 3: Hinzufügen einer Patch-Gruppe zu einer Patch-Baseline
Führen Sie den folgenden Befehl aus, um der angegebenen Patch-Baseline einen `PatchGroup`-Tag-Wert zuzuordnen.
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"PatchGroup": "Development",
"BaselineId": "pb-0c10e65780EXAMPLE"
}
```
### Registrieren einer Patch-Gruppe „Webserver“ für eine Patch-Baseline
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"PatchGroup":"Web Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
### Registrieren Sie eine Patch-Gruppe „Backend“ mit der bereitgestellten AWS Patch-Baseline
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"PatchGroup":"Backend",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
### Anzeigen der Registrierungen für Patch-Gruppen
```
aws ssm describe-patch-groups --region us-east-2
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
}
]
}
```
### Aufheben der Registrierung einer Patch-Gruppe für eine Patch-Baseline
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"PatchGroup":"Production",
"BaselineId":"arn:aws:ssm:us-east-2:111122223333:patchbaseline/pb-0c10e65780EXAMPLE"
}
```
## AWS CLI Befehle zum Anzeigen von Patch-Zusammenfassungen und Details
**Topics**
+ [Abrufen aller Patches, die in einer bestimmten Patch-Baseline definiert sind](#patch-manager-cli-commands-describe-effective-patches-for-patch-baseline)
+ [Holen Sie sich alle Patches für AmazonLinux 2018.03 mit einer Klassifizierung `SECURITY` und einem Schweregrad von `Critical`](#patch-manager-cli-commands-describe-available-patches-linux)
+ [Abrufen aller Patches für Windows Server 2012 mit einem MSRC-Schweregrad von `Critical`](#patch-manager-cli-commands-describe-available-patches)
+ [Abrufen aller verfügbaren Patches](#patch-manager-cli-commands-describe-available-patches)
+ [Abrufen der zusammengefassten Patch-Zustände pro verwalteten Knoten](#patch-manager-cli-commands-describe-instance-patch-states)
+ [Abrufen der Patch-Compliance-Details für einen verwalteten Knoten](#patch-manager-cli-commands-describe-instance-patches)
+ [Anzeigen der Patch-Compliance-Ergebnisse (AWS CLI)](#viewing-patch-compliance-results-cli)
### Abrufen aller Patches, die in einer bestimmten Patch-Baseline definiert sind
**Anmerkung**
Dieser Befehl wird nur für Windows Server-Patch-Baselines unterstützt.
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
```
### Holen Sie sich alle Patches für AmazonLinux 2018.03 mit einer Klassifizierung `SECURITY` und einem Schweregrad von `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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
```
### Abrufen aller Patches für Windows Server 2012 mit einem MSRC-Schweregrad von `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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
```
### Abrufen aller verfügbaren Patches
```
aws ssm describe-available-patches --region us-east-2
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
```
### Abrufen der zusammengefassten Patch-Zustände pro verwalteten Knoten
Die Zusammenfassung pro verwaltetem Knoten gibt Ihnen die Anzahl der Patches in den folgenden Zuständen pro Knoten an: "NotApplicable„, „Fehlend“, „Fehlgeschlagen“, "InstalledOther" und „Installiert“.
------
#### [ 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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
```
### Abrufen der Patch-Compliance-Details für einen verwalteten Knoten
```
aws ssm describe-instance-patches --instance-id i-08ee91c0b17045407
```
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
```
### Anzeigen der Patch-Compliance-Ergebnisse (AWS CLI)
**Anzeigen von Patch-Compliance-Ergebnissen für einen einzelnen verwalteten Knoten**
Führen Sie den folgenden Befehl in AWS Command Line Interface (AWS CLI) aus, um die Ergebnisse der Patch-Konformität für einen einzelnen verwalteten Knoten anzuzeigen.
```
aws ssm describe-instance-patch-states --instance-id instance-id
```
*instance-id*Ersetzen Sie ihn durch die ID des verwalteten Knotens, für den Sie Ergebnisse anzeigen möchten, im Format `i-02573cafcfEXAMPLE` oder`mi-0282f7c436EXAMPLE`.
Das System gibt unter anderem folgende Informationen zurück.
```
{
"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"
}
]
}
```
**So zeigen Sie eine Patch-Anzahl-Zusammenfassung für alle EC2-Instances in einer Region an**
Der `describe-instance-patch-states` unterstützt das Abrufen von Ergebnissen für jeweils eine verwaltete Instance. Wenn Sie jedoch ein benutzerdefiniertes Skript mit dem `describe-instance-patch-states`-Befehl verwenden, können Sie einen detaillierteren Bericht erstellen.
Wenn zum Beispiel das [jq filter tool](https://stedolan.github.io/jq/download/) auf Ihrem lokalen Computer installiert ist, können Sie den folgenden Befehl ausführen, um zu ermitteln, welche Ihrer EC2-Instances in einer bestimmten AWS-Region einen Status von `InstalledPendingReboot` haben.
```
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*stellt den Bezeichner für eine Region dar AWS Systems Manager, die von AWS-Region unterstützt wird, z. B. `us-east-2` für die Region USA Ost (Ohio). Eine Liste der unterstützten *region* Werte finden Sie in der Spalte **Region** der [Systems Manager Manager-Dienstendpunkte](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) in der *Allgemeine Amazon Web Services-Referenz*.
Beispiel:
```
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}'
```
Das System gibt unter anderem folgende Informationen zurück
```
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
```
Zusätzlich zu `InstalledPendingRebootCount` können Sie nach den folgenden Anzahltypen suchen:
+ `CriticalNonCompliantCount`
+ `SecurityNonCompliantCount`
+ `OtherNonCompliantCount`
+ `UnreportedNotApplicableCount `
+ `InstalledPendingRebootCount`
+ `FailedCount`
+ `NotApplicableCount`
+ `InstalledRejectedCount`
+ `InstalledOtherCount`
+ `MissingCount`
+ `InstalledCount`
## AWS CLI Befehle zum Scannen und Patchen verwalteter Knoten
Nachdem Sie die folgenden Befehle ausgeführt haben, um nach Patch-Compliance zu scannen oder Patches zu installieren, können Sie mit Befehlen im [AWS CLI Befehle zum Anzeigen von Patch-Zusammenfassungen und Details](#patch-details-cli-commands)-Abschnitt Informationen zu Patch-Status und -Compliance anzeigen.
**Topics**
+ [Verwaltete Knoten auf Patch-Compliance scannen (AWS CLI)](#patch-operations-scan)
+ [Installieren von Patches auf verwalteten Knoten (AWS CLI)](#patch-operations-install-cli)
### Verwaltete Knoten auf Patch-Compliance scannen (AWS CLI)
**So scannen Sie spezifische verwaltete Knoten auf Patch-Compliance**
Führen Sie den folgenden Befehl aus.
------
#### [ 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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
}
}
```
**So scannen Sie verwaltete Knoten nach Patch-Gruppentag auf Patch-Compliance**
Führen Sie den folgenden Befehl aus.
------
#### [ 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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
}
}
```
### Installieren von Patches auf verwalteten Knoten (AWS CLI)
**So installieren Sie Patches auf spezifischen verwalteten Knoten**
Führen Sie den folgenden Befehl aus.
**Anmerkung**
Die anvisierten verwalteten Knoten werden nach Bedarf neu gestartet, um die Patch-Installation abzuschließen. Weitere Informationen finden Sie unter [SSM-Befehlsdokument zum Patchen: `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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
}
}
```
**So installieren Sie Patches auf verwalteten Knoten in einer spezifischen Patch-Gruppe**
Führen Sie den folgenden Befehl aus.
------
#### [ 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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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---
}
}
```
# AWS Systems Manager Patch Manager Tutorials
Die Tutorials in diesem Abschnitt zeigenPatch Manager, wie Sie ein Tool in AWS Systems Manager verschiedenen Patch-Szenarien verwenden können.
**Topics**
+ [Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen](patch-manager-server-patching-iPv6-tutorial.md)
+ [So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs mithilfe der Konsole](patch-manager-windows-service-pack-patch-baseline-tutorial.md)
+ [Tutorial: Aktualisieren von Anwendungsabhängigkeiten, Patchen eines verwalteten Knotens und Durchführen einer anwendungsspezifischen Zustandsprüfung mithilfe der Konsole](aws-runpatchbaselinewithhooks-tutorial.md)
+ [Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md)
# Tutorial: Einen Server in einer IPv6 einzigen Umgebung patchen
Patch Managerunterstützt das Patchen von Knoten in Umgebungen, in denen nur IPv6 Durch die Aktualisierung der SSM Agent Konfiguration können Patch-Vorgänge so konfiguriert werden, dass nur Aufrufe an IPv6 Dienstendpunkte getätigt werden.
**Um einen Server in einer IPv6 reinen Umgebung zu patchen**
1. Stellen Sie sicher, dass SSM Agent Version 3.3270.0 oder höher auf dem verwalteten Knoten installiert ist.
1. Navigieren Sie auf dem verwalteten Knoten zur Konfigurationsdatei. SSM Agent Sie finden die `amazon-ssm-agent.json` Datei in den folgenden Verzeichnissen:
+ Linux: `/etc/amazon/ssm/`
+ macOS: `/opt/aws/ssm/`
+ Windows Server: `C:\Program Files\Amazon\SSM`
Falls sie noch nicht `amazon-ssm-agent.json` existiert, kopieren Sie den Inhalt von `amazon-ssm-agent.json.template` unter demselben Verzeichnis nach`amazon-ssm-agent.json`.
1. Aktualisieren Sie den folgenden Eintrag, um die richtige Region festzulegen, und stellen Sie ihn `UseDualStackEndpoint` auf ein`true`:
```
{
--------
"Agent": {
"Region": "region",
"UseDualStackEndpoint": true
},
--------
}
```
1. Starten Sie den SSM Agent Dienst mit dem entsprechenden Befehl für Ihr Betriebssystem neu:
+ Linux: `sudo systemctl restart amazon-ssm-agent`
+ Ubuntu Servermit Snap: `sudo snap restart amazon-ssm-agent`
+ macOS: `sudo launchctl stop com.amazon.aws.ssm` gefolgt von `sudo launchctl start com.amazon.aws.ssm`
+ Windows Server: `Stop-Service AmazonSSMAgent` gefolgt von `Start-Service AmazonSSMAgent`
Die vollständige Liste der Befehle pro Betriebssystem finden Sie unter[Prüfen des SSM Agent-Status und Starten des Agenten](ssm-agent-status-and-restart.md).
1. Führen Sie einen beliebigen Patchvorgang aus, um sicherzustellen, dass die Patchvorgänge in Ihrer reinen Umgebung erfolgreich sind IPv6. Stellen Sie sicher, dass die Knoten, für die gepatcht wird, eine Verbindung zur Patch-Quelle haben. Sie können die Run Command Ausgabe der Patching-Ausführung überprüfen, um nach Warnungen zu unzugänglichen Repositorys zu suchen. Achten Sie beim Patchen eines Knotens, der in einer IPv6 reinen Umgebung läuft, darauf, dass der Knoten mit der Patch-Quelle verbunden ist. Sie können die Run Command Ausgabe der Patching-Ausführung überprüfen, um nach Warnungen zu unzugänglichen Repositorys zu suchen. Für DNF-basierte Betriebssysteme ist es möglich, nicht verfügbare Repositorys so zu konfigurieren, dass sie beim Patchen übersprungen werden, wenn die Option auf unter gesetzt ist. `skip_if_unavailable` `True` `/etc/dnf/dnf.conf` Zu den DNF-basierten Betriebssystemen gehören Amazon Linux 2023, Red Hat Enterprise Linux 8 und spätere Versionen, Oracle Linux Rocky Linux AlmaLinux, und CentOS 8 und spätere Versionen. Unter Amazon Linux 2023 ist die `skip_if_unavailable` Option `True` standardmäßig auf eingestellt.
**Anmerkung**
Wenn Sie die Funktionen Install Override List oder Baseline Override verwenden, stellen Sie sicher, dass die angegebene URL vom Knoten aus erreichbar ist. Wenn die SSM Agent Konfigurationsoption auf gesetzt `UseDualStackEndpoint` ist`true`, wird ein Dual-Stack-S3-Client verwendet, wenn eine S3-URL bereitgestellt wird.
# So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs mithilfe der Konsole
Wenn Sie eine benutzerdefinierte Patch-Baseline erstellen, können Sie angeben, ob alle, einige oder nur ein einziger unterstützter Patch-Typ installiert wird.
In den Patch-Baselines für Windows können Sie `ServicePacks` als einzige **Klassifizierungsoption** auswählen, um Patching-Updates auf Service Packs einzuschränken. Service Packs können automatisch mit Patch Manager einem Tool in installiert werden AWS Systems Manager, sofern das Update in Windows Update oder Windows Server Update Services (WSUS) verfügbar ist.
Sie können eine Patch-Baseline konfigurieren, um festzulegen, ob Service Packs für alle Windows-Versionen oder nur für bestimmte Windows-Versionen installiert werden, z. B. Windows 7 oder Windows Server 2016.
Gehen Sie wie folgt vor, um eine benutzerdefinierte Patch-Baseline zu erstellen, die ausschließlich für die Installation aller Service Packs auf Ihren Windows-verwalteten Knoten verwendet wird.
**So erstellen Sie eine Patch-Baseline für die Installation von Windows Service Packs (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Patch-Baselines** und dann **Patch-Baseline erstellen** aus.
1. Geben Sie im Feld **Name** einen Namen für die neue Patch-Baseline ein, z. B. `MyWindowsServicePackPatchBaseline`.
1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für diese Patch-Baseline ein.
1. Wählen Sie unter **Betriebssystem** die Option `Windows` aus.
1. Wenn Sie diese Patch-Baseline direkt nach dem Erstellen als Standard für Windows verwenden möchten, wählen Sie **Set this patch baseline as the default patch baseline for Windows Server instances (Diese Patch-Baseline als Standard-Patch-Baseline für Windows Server-Instances festlegen)** aus.
**Anmerkung**
Diese Option ist nur verfügbar, wenn Sie vor der Veröffentlichung der [Patch-Richtlinien](patch-manager-policies.md) am 22. Dezember 2022 zum ersten Mal auf Patch Manager zugegriffen haben.
Weitere Informationen zum Festlegen einer vorhandenen Patch-Baseline als Standard finden Sie unter [Festlegen einer vorhandenen Patch-Baseline als Standard](patch-manager-default-patch-baseline.md).
1. Erstellen Sie im Abschnitt **Approval Rules for operating-systems (Genehmigungsregeln für Betriebssysteme)** unter Verwendung der Felder ein oder mehrere automatische Genehmigungsregeln.
+ **Produkte**: Die Betriebssystemversionen, auf die sich die Genehmigungsregel bezieht, z. B. `WindowsServer2012`. Sie können eine, mehr als eine oder alle unterstützten Windows-Versionen auswählen. Die Standardauswahl ist `All`.
+ **Classification (Klassifizierung)**: Wählen Sie `ServicePacks` aus.
+ **Severity (Schweregrad)**: Der Schweregradwert der Patches, auf die die Regel angewendet werden soll. Um sicherzustellen, dass alle Service Packs von der Regel eingeschlossen werden, wählen Sie `All` aus.
+ **Automatische Genehmigung**: Die Methode zum Auswählen von Patches für die automatische Genehmigung.
+ **Patches nach einer bestimmten Anzahl von Tagen genehmigen**: Die Anzahl der Tage, die der Patch Manager warten muss, nachdem ein Patch veröffentlicht oder aktualisiert wurde, bevor ein Patch automatisch genehmigt wird. Sie können jede Ganzzahl von Null (0) bis 360 eingeben. Für die meisten Szenarien empfehlen wir, nicht länger als 100 Tage zu warten.
+ **Patches genehmigen, die bis zu einem bestimmten Datum veröffentlicht wurden**: Das Datum der Patch-Veröffentlichung, an dem der Patch Manager automatisch alle Patches anwendet, die bis zu diesem Datum veröffentlicht oder aktualisiert wurden. Wenn Sie beispielsweise den 07. Juli 2023 angeben, werden Patches, die am oder nach dem 08. Juli 2023 veröffentlicht oder zuletzt aktualisiert wurden, nicht automatisch installiert.
+ (Optional) **Compliance reporting (Compliance-Berichte)**: Der Schweregrad, den Sie Service Packs zuweisen möchten, die von der Baseline genehmigt wurden, z. B. `High`.
**Anmerkung**
Wenn Sie eine Konformitätsberichtsstufe angeben und der Patch-Status eines genehmigten Service-Packs als `Missing` gemeldet wird, dann entspricht der insgesamt gemeldete Konformitätsschweregrad der Patch-Baseline dem von Ihnen angegebenen Schweregrad.
1. (Optional) Wenden **Sie unter Tags verwalten** ein oder mehrere name/value Tag-Schlüsselpaare auf die Patch-Baseline an.
Tags sind optionale Metadaten, die Sie einer Ressource zuweisen. Mithilfe von Tags können Sie eine Ressource unterschiedlich kategorisieren, beispielsweise nach Zweck, Besitzer oder Umgebung. Für diese Patch-Baseline, die der Aktualisierung von Service Packs gewidmet ist, könnten Sie Schlüssel-Wert-Paare angeben, z. B.:
+ `Key=OS,Value=Windows`
+ `Key=Classification,Value=ServicePacks`
1. Wählen Sie die Option **Patch-Baseline erstellen**.
# Tutorial: Aktualisieren von Anwendungsabhängigkeiten, Patchen eines verwalteten Knotens und Durchführen einer anwendungsspezifischen Zustandsprüfung mithilfe der Konsole
In vielen Fällen muss ein verwalteter Knoten neu gestartet werden, nachdem er mit dem neuesten Softwareupdate gepatcht wurde. Ein Neustart eines verwalteten Knotens in der Produktion ohne vorhandene Sicherheitsvorkehrungen kann jedoch mehrere Probleme verursachen, z. B. das Aufrufen von Alarmen, das Aufzeichnen falscher Metrikdaten und das Unterbrechen von Datensynchronisationen.
Diese Anleitung zeigt, wie Sie Probleme wie diese vermeiden können, indem Sie das AWS Systems Manager -Dokument (SSM-Dokument) `AWS-RunPatchBaselineWithHooks` verwenden, um einen komplexen, mehrstufigen Patchvorgang zu erreichen, der Folgendes ausführt:
1. Verhindern neuer Verbindungen mit der Anwendung
1. Installieren von Betriebssystem-Updates
1. Aktualisieren der Paketabhängigkeiten der Anwendung
1. Neustart des Systems
1. Durchführen einer anwendungsspezifischen Zustandsprüfung
Für dieses Beispiel haben wir unsere Infrastruktur auf diese Weise eingerichtet:
+ Die anvisierten virtuellen Maschinen werden als verwaltete Knoten mit Systems Manager registriert.
+ `Iptables` wird als lokale Firewall verwendet.
+ Die auf den verwalteten Knoten gehostete Anwendung wird auf Port 443 ausgeführt.
+ Die Anwendung, die auf den verwalteten Knoten gehostet wird, ist eine `nodeJS`-Anwendung.
+ Die auf den verwalteten Knoten gehostete Anwendung wird vom pm2-Prozessmanager verwaltet.
+ Die Anwendung verfügt bereits über einen angegebenen Zustandsprüfungs-Endpunkt.
+ Der Endpunkt der Zustandsprüfung der Anwendung erfordert keine Endbenutzerauthentifizierung. Der Endpunkt ermöglicht eine Zustandsprüfung, die die Anforderungen der Organisation beim Festlegen der Verfügbarkeit erfüllt. (In Ihrer Umgebung reicht es möglicherweise aus, sicherzustellen, dass die `nodeJS`-Anwendung ausgeführt wird und in der Lage ist, auf Anfragen zu warten. In anderen Fällen möchten Sie möglicherweise überprüfen, ob bereits eine Verbindung zur Caching-Ebene oder zur Datenbankebene hergestellt wurde).
Die Beispiele in dieser Anleitung dienen nur zu Demonstrationszwecken und sind nicht dafür gedacht, in Produktionsumgebungen implementiert zu werden. Beachten Sie auch, dass das Lebenszyklus-Hook-Feature von Patch Manager, einem Tool in Systems Manager, mit dem `AWS-RunPatchBaselineWithHooks`-Dokument zahlreiche andere Szenarien unterstützen kann. Im Folgenden finden Sie einige Beispiele.
+ Stoppen Sie einen Metriken meldenden Agenten, bevor Sie ihn patchen und neu starten, nachdem der verwaltete Knoten neu gestartet wurde.
+ Trennen Sie den verwalteten Knoten vor dem Patchen von einem CRM- oder PCS-Cluster und fügen Sie sie nach dem Neustart des Knoten erneut an.
+ Aktualisieren Sie Software von Drittanbietern (z. B. Java, Tomcat, Adobe-Anwendungen usw.) auf Windows Server-Maschinen nach dem Anwenden von Betriebssystem-Updates, jedoch vor dem Neustart des verwalteten Knoten.
**So aktualisieren Sie Anwendungsabhängigkeite, patchen einen verwalteten Knoten und führen eine anwendungsspezifische Zustandsprüfung durch**
1. Erstellen Sie ein SSM-Dokument für Ihr Vorinstallations-Skript mit dem folgenden Inhalt und geben Sie ihm den Namen `NodeJSAppPrePatch`. Ersetzen Sie *your\$1application* mit dem Namen Ihrer Anwendung.
Dieses Skript blockiert sofort neue eingehende Anforderungen und lässt fünf Sekunden, damit bereits aktive Anforderungen abgeschlossen werden können, bevor der Patchvorgang gestartet wird. Für die `sleep`-Option geben Sie einen Wert in Sekunden an, der größer ist als die Dauer, bis eingehende Anforderungen normalerweise abgeschlossen werden.
```
# 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
```
Informationen zum Erstellen von SSM-Dokumenten finden Sie unter [Erstellen von SSM-Dokumentinhalten](documents-creating-content.md).
1. Erstellen Sie ein weiteres SSM-Dokument mit folgendem Inhalt für Ihr Postinstall-Skript, um Ihre Anwendungsabhängigkeiten zu aktualisieren, und nennen Sie es `NodeJSAppPostPatch`. Ersetzen Sie es */your/application/path* durch den Pfad zu Ihrer Anwendung.
```
cd /your/application/path
npm update
# you can use npm-check-updates if you want to upgrade major versions
```
1. Erstellen Sie ein weiteres SSM-Dokument mit folgendem Inhalt für Ihr `onExit`-Skript, um Ihre Anwendung zu sichern und eine Zustandsprüfung durchzuführen. Nennen Sie dieses SSM-Dokument `NodeJSAppOnExitPatch`. Ersetzen Sie *your\$1application* mit dem Namen Ihrer Anwendung.
```
# 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. Erstellen Sie eine Zuordnung in State Manager, einem Tool in AWS Systems Manager, um mithilfe der folgenden Schritte den Vorgang auszuführen:
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **State Manager** und anschließend **Zuordnung erstellen** aus.
1. Für **Name** geben Sie einen Namen ein, um den Zweck der Zuordnung zu identifizieren.
1. Wählen Sie in der Liste **Dokument** die Option `AWS-RunPatchBaselineWithHooks` aus.
1. Wählen Sie für **Operation** die Option **Install (Installieren)** aus.
1. (Optional) Für **Snapshot-ID**, stellen Sie eine GUID bereit, die Sie generieren, um den Vorgang zu beschleunigen und Konsistenz zu gewährleisten. Der GUID-Wert kann so einfach sein wie `00000000-0000-0000-0000-111122223333`.
1. Für **Pre Install Hook Doc Name** geben Sie `NodeJSAppPrePatch` ein.
1. Für **Post Install Hook Doc Name** geben Sie `NodeJSAppPostPatch` ein.
1. Geben **Sie für On ExitHook Doc-Name** den Wert ein`NodeJSAppOnExitPatch`.
1. Für **Targets** (Ziele), identifizieren Sie Ihre verwalteten Knoten, indem Sie Tags angeben, Knoten manuell auswählen, eine Ressourcengruppe auswählen oder alle verwaltete Knoten auswählen.
1. Für **Specify schedule (Zeitplan angeben)** geben Sie an, wie oft die Zuordnung ausgeführt werden soll. Für einen verwalteten Knoten ist das Patchen einmal pro Woche beispielsweise eine übliche Kadenz.
1. Wählen Sie im Abschnitt **Rate control** (Ratensteuerung) Optionen für die Ausführung der Zuordnung auf mehreren verwalteten Knoten aus. Stellen Sie sicher, dass nur ein Teil der verwalteten Knoten gleichzeitig aktualisiert wird. Andernfalls könnte die gesamte oder die meisten Ihrer Flotte gleichzeitig offline geschaltet werden. Weitere Informationen zu Ratensteuerungen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben der Ausgabe in S3 aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind die Berechtigungen des dem verwalteten Knoten zugewiesenen Instance-Profils und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
1. Wählen Sie **Zuordnung erstellen**.
# Tutorial: Patchen Sie eine Serverumgebung mit dem AWS CLI
In der folgenden Prozedur wird beschrieben, wie Sie eine Serverumgebung mithilfe einer angepassten Patch-Baseline, Patch-Gruppen und einem Wartungsfenster patchen.
**Bevor Sie beginnen**
+ Installieren oder Aktualisieren des SSM Agent auf Ihren verwalteten Knoten. Um von Linux verwaltete Knoten zu patchen, müssen Ihre Knoten SSM Agent der Version 2.0.834.0 oder höher ausführen. Weitere Informationen finden Sie unter [Aktualisierung von SSM Agent mithilfe von Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
+ Konfigurieren Sie Rollen und Berechtigungen für Maintenance Windows ein Tool in AWS Systems Manager. Weitere Informationen finden Sie unter [Einrichten von Maintenance Windows](setting-up-maintenance-windows.md).
+ Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**So konfigurieren Sie Patch Manager und spielen Patches für verwaltete Knoten ein (Befehlszeile)**
1. Führen Sie den folgenden Befehl aus, um eine Patch-Baseline für Windows mit dem Namen `Production-Baseline` zu erstellen. Diese Patch-Baseline genehmigt Patches für eine Produktionsumgebung sieben Tage nach ihrer Veröffentlichung oder letzten Aktualisierung. Darüber hinaus wurde die Patch-Baseline markiert, um anzuzeigen, dass sie für eine Produktionsumgebung bestimmt ist.
**Anmerkung**
Der `OperatingSystem`-Parameter und `PatchFilters` variieren je nach Betriebssystem der anvisierten verwalteten Knoten, für die die Patch-Baseline gilt. Weitere Informationen erhalten Sie unter [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) und [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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Führen Sie die folgenden Befehle aus, um die Patch-Baseline „Production-Baseline“ für zwei Patchgruppen zu registrieren. Die Gruppen heißen „Datenbankserver“ und „Front-End-Server“.
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"PatchGroup":"Front-End Servers",
"BaselineId":"pb-0c10e65780EXAMPLE"
}
```
1. Führen Sie die folgenden Befehle aus, um zwei Wartungsfenster für die Produktionsserver zu erstellen. Das erste Zeitfenster beginnt jeden Dienstag um 22:00 Uhr. Das zweite Zeitfenster beginnt jeden Samstag um 22:00 Uhr. Darüber hinaus wird das Wartungsfenster mit Tags versehen, um anzugeben, das es für eine Produktionsumgebung vorgesehen ist.
------
#### [ 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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"WindowId":"mw-9a8b7c6d5eEXAMPLE"
}
```
1. Führen Sie die folgenden Befehle aus, um die Server-Patch-Gruppen `Database` und `Front-End` mit ihren jeweiligen Wartungsfenstern zu registrieren.
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE"
}
```
1. Führen Sie die folgenden Befehle aus, um eine Patch-Aufgabe zu registrieren, die während der entsprechenden Wartungsfenster fehlende Updates auf den Servern `Database` und `Front-End` installiert.
------
#### [ 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}}"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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}}"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE"
}
```
1. Führen Sie den folgenden Befehl aus, um für eine Patch-Gruppe eine allgemeine Zusammenfassung zur Patch-Compliance abzurufen. Die allgemeine Zusammenfassung der Patch-Compliance enthält die Anzahl der verwalteten Knoten mit Patches in den jeweiligen Patch-Zuständen.
**Anmerkung**
Es werden Nullen für die Anzahl der verwalteten Knoten in der Zusammenfassung erwartet, bis die Patch-Aufgabe während des ersten Wartungsfensters ausgeführt wird.
------
#### [ Linux & macOS ]
```
aws ssm describe-patch-group-state \
--patch-group "Database Servers"
```
------
#### [ Windows Server ]
```
aws ssm describe-patch-group-state ^
--patch-group "Database Servers"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"Instances": number,
"InstancesWithFailedPatches": number,
"InstancesWithInstalledOtherPatches": number,
"InstancesWithInstalledPatches": number,
"InstancesWithInstalledPendingRebootPatches": number,
"InstancesWithInstalledRejectedPatches": number,
"InstancesWithMissingPatches": number,
"InstancesWithNotApplicablePatches": number,
"InstancesWithUnreportedNotApplicablePatches": number
}
```
1. Führen Sie den folgenden Befehl aus, um für eine Patch-Gruppe eine Übersicht über den Patch-Zustand auf der Ebene einzelner verwalteter Knoten abzurufen. Die Zusammenfassung pro verwalteter Knoten enthält eine Anzahl von Patches in den jeweiligen Patch-Zuständen pro verwalteten Knoten für eine Patch-Gruppe.
------
#### [ 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"
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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
}
]
}
```
Beispiele für andere AWS CLI Befehle, die Sie für Ihre Patch Manager Konfigurationsaufgaben verwenden können, finden Sie unter[Arbeiten mit Patch Manager-Ressourcen unter Verwendung der AWS CLI](patch-manager-cli-commands.md).
# Fehlerbehebung für Patch Manager
Im Folgenden finden Sie Informationen zur Behandlung von Problemen mit Patch Manager, einem Tool in AWS Systems Manager.
**Topics**
+ [Problem: Fehler „Invoke-PatchBaselineOperation : Zugriff verweigert“ oder Fehler „Datei kann nicht von S3 heruntergeladen werden“ für `baseline_overrides.json`](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [Problem: Das Patchen schlägt fehl, ohne dass eine offensichtliche Ursache oder Fehlermeldung vorliegt](#race-condition-conflict)
+ [Problem: Unerwartete Patch-Compliance-Ergebnisse](#patch-manager-troubleshooting-compliance)
+ [Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Linux](#patch-manager-troubleshooting-linux)
+ [Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Windows Server](#patch-manager-troubleshooting-windows)
+ [Fehler bei der Ausführung `AWS-RunPatchBaseline` auf macOS](#patch-manager-troubleshooting-macos)
+ [Verwenden von Automation-Runbooks AWS Support](#patch-manager-troubleshooting-using-support-runbooks)
+ [Kontaktaufnahme AWS Support](#patch-manager-troubleshooting-contact-support)
## Problem: Fehler „Invoke-PatchBaselineOperation : Zugriff verweigert“ oder Fehler „Datei kann nicht von S3 heruntergeladen werden“ für `baseline_overrides.json`
**Problem**: Wenn die von Ihrer Patch-Richtlinie festgelegten Patching-Vorgänge ausgeführt werden, erhalten Sie eine Fehlermeldung ähnlich dem folgenden Beispiel.
------
#### [ 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.
```
------
**Ursache**: Sie haben eine Patch-Richtlinie in Quick Setup erstellt, und einige Ihrer verwalteten Knoten waren bereits mit einem Instance-Profil (für EC2-Instances) oder einer Servicerolle (für Nicht-EC2-Maschinen) versehen.
Sie haben jedoch das Kontrollkästchen **Erforderliche IAM-Richtlinien zu vorhandenen Instance-Profilen hinzufügen, die an Ihre Instances angehängt** sind, nicht aktiviert, wie in der folgenden Abbildung dargestellt.
![\[\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
Wenn Sie eine Patch-Richtlinie erstellen, wird auch ein Amazon-S3-Bucket erstellt, in dem die `baseline_overrides.json` Konfigurationsdatei der Richtlinie gespeichert wird. Wenn Sie bei der Erstellung der Richtlinie das Kontrollkästchen **Erforderliche IAM-Richtlinien zu bestehenden Instance-Profilen hinzufügen, die mit Ihren Instances verbunden sind**, nicht aktivieren, werden die IAM-Richtlinien und Ressourcen-Tags, die für den Zugriff auf `baseline_overrides.json` im S3-Bucket erforderlich sind, nicht automatisch zu Ihren bestehenden IAM-Instance-Profilen und Servicerollen hinzugefügt.
**Lösung 1**: Löschen Sie die bestehende Patch-Richtlinienkonfiguration und erstellen Sie dann eine neue. Aktivieren Sie dabei das Kontrollkästchen **Erforderliche IAM-Richtlinien zu bestehenden Instance-Profilen hinzufügen, die mit Ihren Instances verbunden** sind. Diese Auswahl wendet die mit dieser Quick Setup-Konfiguration erstellten IAM-Richtlinien auf Knoten an, denen bereits ein Instance-Profil oder eine Servicerolle zugewiesen ist. (Quick Setup fügt standardmäßig die erforderlichen Richtlinien zu Instances und Knoten hinzu, die *noch nicht* über Instance-Profile oder Servicerollen verfügen.) Weitere Informationen finden Sie unter [Automatisieren von unternehmensweitem Patching mithilfe einer Quick Setup-Patch-Richtlinie](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
**Lösung 2**: Fügen Sie die erforderlichen Berechtigungen und Tags manuell zu jedem IAM-Instance-Profil und jeder IAM-Servicerolle hinzu, die Sie mit Quick Setup verwenden. Detaillierte Anweisungen finden Sie unter [Berechtigungen für den S3-Bucket mit der Patch-Richtlinie](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions).
## Problem: Das Patchen schlägt fehl, ohne dass eine offensichtliche Ursache oder Fehlermeldung vorliegt
**Problem**: Ein Patch-Vorgang schlägt fehl, ohne dass eine Fehlermeldung zurückgegeben wird.
**Mögliche Ursache**: Beim Patchen verwalteter Knoten kann die Ausführung des Dokuments unterbrochen und als fehlgeschlagen markiert werden, obwohl die Patches erfolgreich installiert wurden. Dies kann der Fall sein, wenn das System während des Patchvorgangs einen unerwarteten Neustart einleitet (z. B. um Firmware-Updates oder Funktionen wie) anzuwenden. SecureBoot Der SSM-Agent kann den Status der Dokumentausführung bei externen Neustarts nicht beibehalten und wieder aufnehmen, was dazu führt, dass die Ausführung als fehlgeschlagen gemeldet wird.
**Lösung**: Um den Status der Patch-Installation nach einer fehlgeschlagenen Ausführung zu überprüfen, führen Sie einen `Scan` Patch-Vorgang aus und überprüfen Sie anschließend die Patch-Kompatibilitätsdaten in Patch Manager, um den aktuellen Konformitätsstatus zu beurteilen.
Wenn Sie feststellen, dass externe Neustarts in diesem Szenario nicht die Ursache für den Fehler waren, empfehlen wir Ihnen, sich an uns zu wenden. [AWS Support](#patch-manager-troubleshooting-contact-support)
## Problem: Unerwartete Patch-Compliance-Ergebnisse
**Problem**: Bei der Überprüfung der nach einem `Scan`-Vorgang generierten Details zur Patching-Compliance enthalten die Ergebnisse Informationen, die nicht die in Ihrer Patch-Baseline festgelegten Regeln widerspiegeln. Beispielsweise wird eine Ausnahme, die Sie der Liste **Rejected patches** (Abgelehnte Patches) in einer Patch-Baseline hinzugefügt haben, als `Missing` aufgeführt. Oder als `Important` klassifizierte Patches werden als fehlend aufgeführt, obwohl Ihre Patch-Baseline nur `Critical`-Patches angibt.
**Ursache**: Patch Manager unterstützt derzeit mehrere Methoden zum Ausführen von `Scan`-Operationen:
+ Eine in Quick Setup konfigurierte Patch-Richtlinie
+ Eine in Quick Setup konfigurierte Host-Management-Option
+ Ein Wartungsfenster zum Ausführen eines Patch-`Scan` oder einer `Install`-Aufgabe
+ Eine On-Demand **Patch now**-Operation (Jetzt patchen)
Wenn eine `Scan`-Operation ausgeführt wird, überschreibt dies die Compliance-Details aus dem letzten Scan. Wenn Sie mehr als eine Methode zum Ausführen einer `Scan`-Operation eingerichtet haben und diese unterschiedliche Patch-Baselines mit unterschiedlichen Regeln verwenden, führt dies zu unterschiedlichen Patch-Compliance-Ergebnissen.
**Lösung**: Um unerwartete Patch-Compliance-Ergebnisse zu vermeiden, empfehlen wir, jeweils nur eine Methode zum Ausführen der Patch Manager `Scan`-Operation zu verwenden. Weitere Informationen finden Sie unter [Identifizieren der Ausführung, die Patch-Compliance-Daten erstellt hat](patch-manager-compliance-data-overwrites.md).
## Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Linux
**Topics**
+ [Problem: Fehler 'No such file or directory'](#patch-manager-troubleshooting-linux-1)
+ [Problem: Fehler 'another process has acquired yum lock'](#patch-manager-troubleshooting-linux-2)
+ [Problem: Fehler 'Permission denied / failed to run commands'](#patch-manager-troubleshooting-linux-3)
+ [Problem: Fehler 'Unable to download payload'](#patch-manager-troubleshooting-linux-4)
+ [Problem: Fehler 'unsupported package manager and python version combination'](#patch-manager-troubleshooting-linux-5)
+ [Problem: Patch Manager wendet keine Regeln an, die zum Ausschließen bestimmter Pakete angegeben sind](#patch-manager-troubleshooting-linux-6)
+ [Problem: Patching schlägt fehl und Patch Manager meldet, dass die Erweiterung „Servername Indication“ für TLS nicht verfügbar ist](#patch-manager-troubleshooting-linux-7)
+ [Problem: Patch Manager meldet 'No more mirrors to try'](#patch-manager-troubleshooting-linux-8)
+ [Problem: Patching schlägt fehl mit 'Error code returned from curl is 23'](#patch-manager-troubleshooting-linux-9)
+ [Problem: Patching schlägt mit der Meldung 'Error unpacking rpm package...' fehl](#error-unpacking-rpm)
+ [Problem: Patching schlägt fehl mit 'Fehler auf Serviceseite beim Hochladen des Inventars'](#inventory-upload-error)
+ [Problem: Das Patchen schlägt fehl und die Meldung „Beim Herunterladen von Paketen sind Fehler aufgetreten“ wird angezeigt](#errors-while-downloading)
+ [Problem: Das Patchen schlägt mit einem OOM-Fehler (Out of Memory) fehl](#patch-manager-troubleshooting-linux-oom)
+ [Problem: Patching schlägt fehl mit der Meldung 'Die folgenden Signaturen konnten nicht verifiziert werden, da der öffentliche Schlüssel nicht verfügbar ist'](#public-key-unavailable)
+ [Problem: Das Patchen schlägt fehl und die Meldung '' NoMoreMirrorsRepoError wird angezeigt](#no-more-mirrors-repo-error)
+ [Problem: Das Patchen schlägt mit der Meldung „Payload kann nicht heruntergeladen werden“ fehl](#payload-download-error)
+ [Problem: Das Patchen schlägt fehl und es wird die Meldung „Installationsfehler: dpkg: Fehler:dpkg-Frontend ist durch einen anderen Prozess gesperrt“ angezeigt](#dpkg-frontend-locked)
+ [Problem: Das Patchen auf Ubuntu Server schlägt fehl und es wird der Fehler „dpkg wurde unterbrochen“ angezeigt](#dpkg-interrupted)
+ [Problem: Das Paketmanager-Dienstprogramm kann eine Paketabhängigkeit nicht auflösen](#unresolved-dependency)
+ [Problem: Fehler bei der Abhängigkeit von Zypper-Paketsperren auf verwalteten SLES-Knoten](#patch-manager-troubleshooting-linux-zypper-locks)
+ [Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.](#patch-manager-troubleshooting-linux-concurrent-lock)
### Problem: Fehler 'No such file or directory'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit einem der folgenden Fehler fehl.
```
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
```
**Ursache 1**: Zwei Befehle zum Ausführen von `AWS-RunPatchBaseline` wurden gleichzeitig auf demselben verwalteten Knoten ausgeführt. Dies erzeugt eine Race-Bedingung, die in der temporären `file patch-baseline-operations*` nicht richtig erstellt oder auf die nicht richtig zugegriffen wird.
**Ursache 2**: Unzureichender Speicherplatz verbleibt im `/var`-Verzeichnis.
**Lösung 1**: Stellen Sie sicher, dass kein Wartungsfenster zwei oder mehr Run Command Aufgaben umfasst, die `AWS-RunPatchBaseline` mit derselben Prioritätsstufe und auf demselben Ziel IDs ausgeführt werden. Wenn dies der Fall ist, ordnen Sie die Priorität neu an. Run Commandist ein Tool in AWS Systems Manager.
**Lösung 2**: Stellen Sie sicher, dass jeweils nur ein Wartungsfenster Run Command-Aufgaben ausführt, die `AWS-RunPatchBaseline` auf denselben Zielen und nach demselben Zeitplan verwenden. Ändern Sie in diesem Fall den Zeitplan.
**Lösung 3**: Stellen Sie sicher, dass nur eine State Manager-Zuordnung `AWS-RunPatchBaseline` nach demselben Zeitplan ausführt und die gleichen verwalteten Knoten anvisiert. State Manager ist ein Tool in AWS Systems Manager.
**Lösung 4**: Machen Sie genügend Speicherplatz im `/var`-Verzeichnis für die Update-Pakete. frei
### Problem: Fehler 'another process has acquired yum lock'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**Ursache**: Das `AWS-RunPatchBaseline`-Dokument wurde auf einem verwalteten Knoten ausgeführt, in dem es bereits in einer anderen Operation ausgeführt wird und den `yum`-Paketmanager-Prozess erhalten hat.
**Lösung**: Stellen Sie sicher, dass keine State Manager-Zuordnung, Aufgaben im Wartungsfenster oder andere Konfigurationen, die `AWS-RunPatchBaseline`nach einem Zeitplan ausführen, ungefähr zur gleichen Zeit denselben verwalteten Knoten als Ziel haben.
### Problem: Fehler 'Permission denied / failed to run commands'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**Ursache**: `/var/lib/amazon/` könnte mit `noexec`-Berechtigungen gemountet sein. Dies ist ein Problem, weil SSM Agent Payload-Skripte auf `/var/lib/amazon/ssm` herunterlädt und sie von diesem Speicherort ausführt.
**Lösung**: Stellen Sie sicher, dass Sie exklusive Partitionen für `/var/log/amazon` und `/var/lib/amazon` konfiguriert haben und sind mit `exec`-Berechtigungen gemountet sind.
### Problem: Fehler 'Unable to download payload'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.
```
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
```
**Ursache**: Der verwaltete Knoten verfügt nicht über die erforderlichen Berechtigungen für den Zugriff auf den angegebenen Amazon Simple Storage Service (Amazon S3)-Bucket.
**Lösung**: Aktualisieren Sie Ihre Netzwerkkonfiguration so, dass S3-Endpunkte erreichbar sind. Weitere Informationen finden Sie unter den Informationen zum erforderlichen Zugriff auf S3-Buckets für Patch Manager in [SSM AgentKommunikation mit AWS verwalteten S3-Buckets](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
### Problem: Fehler 'unsupported package manager and python version combination'
**Problem**: Wenn Sie `AWS-RunPatchBaseline` ausführen, schlägt das Patchen mit dem folgenden Fehler fehl.
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**Ursache**: Eine unterstützte Version von Python3 ist nicht auf der Instance Debian Server oder Ubuntu Server installiert.
**Lösung**: Installieren Sie eine unterstützte Version von python3 (3.0–3.12) auf dem Server, die für verwaltete Debian Server- und Ubuntu Server-Knoten erforderlich ist.
### Problem: Patch Manager wendet keine Regeln an, die zum Ausschließen bestimmter Pakete angegeben sind
**Problem**: Sie haben versucht, bestimmte Pakete auszuschließen, indem Sie sie in der `/etc/yum.conf`-Datei im Format `exclude=package-name` angeben, aber sie werden nicht während der Patch Manager-Operation `Install` ausgeschlossen.
**Ursache**: Patch Manager enthält keine Ausschlüsse, die in der `/etc/yum.conf`-Datei angegeben sind.
**Lösung**: Um bestimmte Pakete auszuschließen, erstellen Sie eine benutzerdefinierte Patch-Baseline und eine Regel, um die Pakete auszuschließen, die nicht installiert werden sollen.
### Problem: Patching schlägt fehl und Patch Manager meldet, dass die Erweiterung „Servername Indication“ für TLS nicht verfügbar ist
**Problem**: Der Patchvorgang gibt die folgende Meldung aus.
```
/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
```
**Ursache**: Diese Meldung zeigt keinen Fehler an. Stattdessen ist dies eine Warnung, dass die ältere Version von Python, die mit dem Betriebssystem vertrieben wird, TLS Server Name Indication nicht unterstützt. Das Systems Manager Manager-Patch-Payload-Skript gibt diese Warnung aus, wenn eine Verbindung zu AWS APIs diesem unterstützenden SNI hergestellt wird.
**Lösung**: Um Patching-Fehler zu beheben, wenn diese Meldung gemeldet wird, überprüfen Sie den Inhalt der `stdout`- und `stderr`-Dateien. Wenn Sie die Patch-Baseline nicht so konfiguriert haben, dass diese Dateien in einem S3-Bucket oder in Amazon CloudWatch Logs gespeichert werden, können Sie die Dateien am folgenden Speicherort auf Ihrem verwalteten Linux-Node finden.
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### Problem: Patch Manager meldet 'No more mirrors to try'
**Problem**: Der Patchvorgang gibt die folgende Meldung aus.
```
[Errno 256] No more mirrors to try.
```
**Ursache**: Die auf dem verwalteten Knoten konfigurierten Repositorys funktionieren nicht richtig. Mögliche Gründe hierfür sind:
+ Das `yum`-Cache ist beschädigt.
+ Eine Repository-URL kann aufgrund von Netzwerkproblemen nicht erreicht werden.
**Lösung**: Patch Manager verwendet den Standard-Paketmanager des verwalteten Knoten, um die Patching-Operation durchzuführen. Überprüfen Sie, ob Repositorys richtig konfiguriert sind und funktionieren.
### Problem: Patching schlägt fehl mit 'Error code returned from curl is 23'
**Problem**: Eine Patching-Operation, die `AWS-RunPatchBaseline` verwendet, schlägt mit einer Fehlermeldung ähnlich der folgenden fehl:
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**Ursache**: Das auf Ihren Systemen verwendete Curl-Tool verfügt nicht über die erforderlichen Rechte, um in das Dateisystem zu schreiben. Dies kann vorkommen, wenn das Standard-Curl-Tool des Paketmanagers durch eine andere Version ersetzt wurde, beispielsweise durch eine, die mit snap installiert wurde.
**Lösung**: Wenn die vom Paketmanager bereitgestellte curl-Version deinstalliert wurde, während eine andere Version installiert wurde, installieren Sie sie erneut.
Wenn Sie mehrere curl-Versionen installiert halten müssen, stellen Sie sicher, dass sich die mit dem Paketmanager verknüpfte Version im ersten in der `PATH`-Variable aufgeführten Verzeichnis befindet. Sie können dies überprüfen, indem Sie den Befehl `echo $PATH` ausführen, um die aktuelle Reihenfolge der Verzeichnisse zu sehen, die auf Ihrem System auf ausführbare Dateien überprüft werden.
### Problem: Patching schlägt mit der Meldung 'Error unpacking rpm package...' fehl
**Problem**: Ein Patch-Vorgang schlägt mit einem Fehler ähnlich dem folgenden fehl:
```
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
```
**Ursache 1**: Wenn ein bestimmtes Paket in mehreren Paket-Installationsprogrammen vorhanden ist, z. B. sowohl in `pip` als auch in `yum` oder `dnf`, kann es bei der Verwendung des Standard-Paketmanagers zu Konflikten kommen.
Ein häufiges Beispiel ist das `urllib3`-Paket, das sich in `pip`, `yum` und `dnf` befindet.
**Ursache 2**: Das `python-urllib3`-Paket ist beschädigt. Dies kann passieren, wenn die Paketdateien von `pip` installiert oder aktualisiert wurden, nachdem das `rpm`-Paket zuvor von `yum` oder `dnf` installiert wurde.
**Lösung**: Entfernen Sie das `python-urllib3`-Paket aus Pip, indem Sie den Befehl `sudo pip uninstall urllib3` ausführen, und behalten Sie das Paket nur im Standard-Paketmanager (`yum` oder `dnf`) bei.
### Problem: Patching schlägt fehl mit 'Fehler auf Serviceseite beim Hochladen des Inventars'
**Problem**: Beim Ausführen des `AWS-RunPatchBaseline`-Dokuments erhalten Sie die folgende Fehlermeldung:
```
Encounter service side error when uploading the inventory
```
**Ursache**: Zwei Befehle zum Ausführen von `AWS-RunPatchBaseline` wurden gleichzeitig auf demselben verwalteten Knoten ausgeführt. Dies führt zu einer Race-Bedingung, wenn der Boto3-Client während Patch-Vorgängen initialisiert wird.
**Lösung**: Stellen Sie sicher, dass keine State Manager-Zuordnung, Aufgaben im Wartungsfenster oder andere Konfigurationen, die `AWS-RunPatchBaseline`nach einem Zeitplan ausführen, ungefähr zur gleichen Zeit denselben verwalteten Knoten als Ziel haben.
### Problem: Das Patchen schlägt fehl und die Meldung „Beim Herunterladen von Paketen sind Fehler aufgetreten“ wird angezeigt
**Problem**: Beim Patchen erhalten Sie eine Fehlermeldung, die der folgenden ähnelt:
```
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',
```
**Ursache**: Dieser Fehler kann auftreten, wenn auf einem verwalteten Knoten nicht genügend Speicher verfügbar ist.
**Lösung**: Konfigurieren Sie den Swap-Speicher oder aktualisieren Sie die Instance auf einen anderen Typ, um die Speicherunterstützung zu erhöhen. Starten Sie dann einen neuen Patch-Vorgang.
### Problem: Das Patchen schlägt mit einem OOM-Fehler (Out of Memory) fehl
**Problem**: Bei der Ausführung schlägt der Patchvorgang fehl`AWS-RunPatchBaseline`, da auf dem verwalteten Knoten nicht genügend Arbeitsspeicher zur Verfügung steht. Möglicherweise werden Fehler wie `Cannot allocate memory` `Killed` (vom Linux-OOM-Killer) angezeigt, oder der Vorgang schlägt unerwartet fehl. Dieser Fehler tritt eher bei Instanzen mit weniger als 1 GB RAM auf, kann sich aber auch auf Instanzen mit mehr Arbeitsspeicher auswirken, wenn eine große Anzahl von Updates verfügbar ist.
**Ursache**: Patch Manager führt Patchvorgänge mithilfe des systemeigenen Paketmanagers auf dem verwalteten Knoten aus. Der während eines Patchvorgangs benötigte Speicher hängt von mehreren Faktoren ab, darunter:
+ Die Anzahl der installierten Pakete und die verfügbaren Updates auf dem verwalteten Knoten.
+ Der verwendete Paketmanager und seine Speichereigenschaften.
+ Andere Prozesse, die zum Zeitpunkt des Patchvorgangs auf dem verwalteten Knoten ausgeführt werden.
Verwaltete Knoten mit einer großen Anzahl installierter Pakete oder einer großen Anzahl verfügbarer Updates benötigen während der Patchvorgänge mehr Arbeitsspeicher. Wenn der verfügbare Speicher nicht ausreicht, schlägt der Patchvorgang fehl und wird mit einem Fehler beendet. Das Betriebssystem kann den Patchvorgang auch beenden.
**Lösung**: Probieren Sie eine oder mehrere der folgenden Optionen aus:
+ Planen Sie Patch-Vorgänge in Zeiten geringer Arbeitsauslastung auf dem verwalteten Knoten, z. B. mithilfe von Wartungsfenstern.
+ Führen Sie ein Upgrade der Instanz auf einen Typ mit mehr Arbeitsspeicher durch.
+ Konfigurieren Sie den Swap-Speicher auf dem verwalteten Knoten. Beachten Sie, dass bei Instances mit begrenztem EBS-Durchsatz eine starke Swap-Nutzung zu Leistungseinbußen führen kann.
+ Überprüfen und reduzieren Sie die Anzahl der Prozesse, die während der Patching-Vorgänge auf dem verwalteten Knoten ausgeführt werden.
### Problem: Patching schlägt fehl mit der Meldung 'Die folgenden Signaturen konnten nicht verifiziert werden, da der öffentliche Schlüssel nicht verfügbar ist'
**Problem**: Das Patchen schlägt bei Ubuntu Server mit einer Fehlermeldung ähnlich der folgenden fehl:
```
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
```
**Ursache**: Der Schlüssel für GNU Privacy Guard (GPG) ist abgelaufen oder fehlt.
**Lösung**: Aktualisieren Sie den GPG-Schlüssel, oder fügen Sie den Schlüssel erneut hinzu.
Anhand des zuvor gezeigten Fehlers sehen wir zum Beispiel, dass der `467B942D3A79BD29`-Schlüssel fehlt und hinzugefügt werden muss. Führen Sie dazu einen der folgenden Befehle aus:
```
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
```
Oder, um alle Schlüssel zu aktualisieren, führen Sie den folgenden Befehl aus:
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
Wenn der Fehler danach weiterhin auftritt, empfehlen wir, das Problem an die Organisation zu melden, die das Repository verwaltet. Bis ein Fix verfügbar ist, können Sie die `/etc/apt/sources.list`-Datei so bearbeiten, dass das Repository während des Patchvorgangs ausgelassen wird.
Öffnen Sie dazu die `sources.list`-Datei zur Bearbeitung, suchen Sie die Zeile für das Repository und fügen Sie am Anfang der Zeile ein `#`-Zeichen ein, um sie auszukommentieren. Speichern und schließen Sie dann die Datei.
### Problem: Das Patchen schlägt fehl und die Meldung '' NoMoreMirrorsRepoError wird angezeigt
**Problem:** Sie erhalten eine Fehlermeldung ähnlich der folgenden:
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**Ursache**: Im Quell-Repository ist ein Fehler aufgetreten.
**Lösung**: Wir empfehlen, das Problem der Organisation zu melden, die das Repository verwaltet. Bis der Fehler behoben ist, können Sie das Repository auf Betriebssystemebene deaktivieren. Führen Sie dazu den folgenden Befehl aus und ersetzen Sie den Wert für *repo-name* durch Ihren Repository-Namen:
```
yum-config-manager --disable repo-name
```
Im Folgenden sehen Sie ein Beispiel.
```
yum-config-manager --disable pgdg94
```
Nachdem Sie diesen Befehl ausgeführt haben, führen Sie einen weiteren Patch-Vorgang aus.
### Problem: Das Patchen schlägt mit der Meldung „Payload kann nicht heruntergeladen werden“ fehl
**Problem:** Sie erhalten eine Fehlermeldung ähnlich der folgenden:
```
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
```
**Ursache**: Die Konfiguration des verwalteten Knotens ist fehlerhaft oder unvollständig.
**Lösung**: Versichern Sie sich, dass der verwaltete Knoten wie folgt konfiguriert ist:
+ Ausgehende TCP-443-Regel in der Sicherheitsgruppe.
+ Ausgehende TCP-443-Regel in NACL.
+ TCP-Regel 1024-65535 für eingehenden Datenverkehr in NACL.
+ NAT/IGW in der Routing-Tabelle, um Konnektivität zu einem S3-Endpunkt bereitzustellen. Wenn die Instance keinen Internetzugang hat, stellen Sie ihr Konnektivität mit dem S3-Endpunkt zur Verfügung. Fügen Sie dazu einen S3-Gateway-Endpunkt in der VPC hinzu und integrieren Sie ihn in die Routing-Tabelle des verwalteten Knotens.
### Problem: Das Patchen schlägt fehl und es wird die Meldung „Installationsfehler: dpkg: Fehler:dpkg-Frontend ist durch einen anderen Prozess gesperrt“ angezeigt
**Problem**: Das Patchen schlägt mit einem Fehler ähnlich dem folgenden fehl:
```
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
```
**Ursache**: Der Paketmanager führt bereits einen anderen Prozess auf einem verwalteten Knoten auf Betriebssystemebene aus. Wenn der Abschluss dieses anderen Prozesses viel Zeit in Anspruch nimmt, kann es bei der Patch-Operation von Patch Manager zu einem Timeout kommen und ein Fehler auftreten.
**Lösung**: Führen Sie nach Abschluss des anderen Prozesses, der den Paketmanager verwendet, einen neuen Patchvorgang aus.
### Problem: Das Patchen auf Ubuntu Server schlägt fehl und es wird der Fehler „dpkg wurde unterbrochen“ angezeigt
**Problem**: Auf Ubuntu Server schlägt das Patchen mit einem Fehler ähnlich dem folgenden fehl:
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**Ursache**: Ein oder mehrere Pakete sind falsch konfiguriert.
**Lösung**: Führen Sie die folgenden Schritte aus:
1. Prüfen Sie, welche Pakete betroffen sind und welche Probleme bei den einzelnen Paketen bestehen, indem Sie nacheinander die folgenden Befehle ausführen:
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. Korrigieren Sie die fehlerhaften Pakete, indem Sie den folgenden Befehl ausführen:
```
sudo dpkg --configure -a
```
1. Wenn der vorherige Befehl das Problem nicht vollständig behoben hat, führen Sie den folgenden Befehl aus:
```
sudo apt --fix-broken install
```
### Problem: Das Paketmanager-Dienstprogramm kann eine Paketabhängigkeit nicht auflösen
**Problem**: Der native Paketmanager auf dem verwalteten Knoten kann eine Paketabhängigkeit nicht auflösen und das Patchen schlägt fehl. Das folgende Beispiel für eine Fehlermeldung weist auf diese Art von Fehler auf einem Betriebssystem hin, das `yum` als Paketmanager verwendet.
```
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']
```
**Ursache**: Patch Manager verwendet auf Linux-Betriebssystemen den systemeigenen Paketmanager auf der Maschine, um Patch-Operationen wie `yum`, `dnf`, `apt` und `zypper` auszuführen. Die Anwendungen erkennen, installieren, aktualisieren oder entfernen abhängige Pakete bei Bedarf automatisch. Einige Bedingungen können jedoch dazu führen, dass der Paketmanager einen Abhängigkeitsvorgang nicht abschließen kann, wie zum Beispiel:
+ Auf dem Betriebssystem sind mehrere widersprüchliche Repositorys konfiguriert.
+ Auf eine Remote-Repository-URL kann aufgrund von Netzwerkproblemen nicht zugegriffen werden.
+ Im Repository wurde ein Paket für die falsche Architektur gefunden.
**Lösung**: Das Patchen kann aufgrund eines Abhängigkeitsproblems aus einer Vielzahl von Gründen fehlschlagen. Wir empfehlen Ihnen daher, sich an uns AWS Support zu wenden, um Ihnen bei der Problembehebung behilflich zu sein.
### Problem: Fehler bei der Abhängigkeit von Zypper-Paketsperren auf verwalteten SLES-Knoten
**Problem**: Wenn Sie `AWS-RunPatchBaseline` mit dem `Install`-Vorgang auf SUSE Linux Enterprise Server-Instances ausführen, schlägt das Patchen fehl und es treten Fehler bei der Abhängigkeitsprüfung auf, die mit Paketsperren zusammenhängen. Sie könnten Fehlermeldungen ähnlich der folgenden erhalten:
```
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
```
In diesem Beispiel ist das Paket `mock-pkg-standalone` gesperrt, was Sie überprüfen könnten, indem Sie `sudo zypper locks` ausführen und in der Ausgabe nach diesem Paketnamen suchen.
Oder Sie sehen möglicherweise Protokolleinträge, die auf Fehlschläge bei der Abhängigkeitsprüfung hinweisen:
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**Anmerkung**
Dieses Problem tritt nur während `Install`-Vorgängen auf. `Scan`-Vorgänge wenden keine Paketsperren an und sind auch nicht von vorhandenen Sperren betroffen.“
**Ursache**: Dieser Fehler tritt auf, wenn Zypper-Paketsperren die Installation oder Aktualisierung von Paketen aufgrund von Abhängigkeitskonflikten verhindern. Paketsperren können aus verschiedenen Gründen vorhanden sein:
+ **Vom Kunden angewendete Sperren**: Sie oder Ihr Systemadministrator haben Pakete manuell mithilfe von Zypper-Befehlen gesperrt, wie z. B. `zypper addlock`.
+ **Von Patch Manager abgelehnte Patches**: Patch Manager wendet automatisch Paketsperren an, wenn Sie Pakete in der Liste der **abgelehnten Patches** Ihrer Patch-Baseline angeben, um deren Installation zu verhindern.
+ **Restsperren aufgrund unterbrochener Vorgänge**: In seltenen Fällen, in denen ein Patch-Vorgang unterbrochen wurde (z. B. durch einen Systemneustart), konnte zuvor Patch Manager temporäre Sperren aufheben, restliche Paketsperren verblieben jedoch eventuell auf Ihrem verwalteten Knoten.
**Lösung**: Gehen Sie je nach Ursache folgendermaßen vor, um Probleme mit der Zypper-Paketsperre zu beheben:
**Schritt 1: Identifizieren gesperrter Pakete**
Verbinden Sie sich mit Ihrem verwalteten SLES-Knoten und führen Sie den folgenden Befehl aus, um alle derzeit gesperrten Pakete aufzulisten:
```
sudo zypper locks
```
**Schritt 2: Ermitteln der Quelle der Sperren**
+ Wenn es sich bei den gesperrten Paketen um Pakete handelt, die Sie aus Gründen der Systemstabilität absichtlich gesperrt haben, sollten Sie überlegen, ob sie gesperrt bleiben müssen oder ob sie für das Patching vorübergehend entsperrt werden können.
+ Wenn die gesperrten Pakete mit Einträgen in der Liste der **abgelehnten Patches** Ihrer Patch-Baseline übereinstimmen, handelt es sich wahrscheinlich um Restsperren, die auf einen unterbrochenen Patch-Vorgang zurückzuführen sind. Patch Manager wendet diese Sperren während des normalen Betriebs vorübergehend an und entfernt sie automatisch, wenn der Vorgang abgeschlossen ist. Sie können die Pakete entweder aus der Liste der abgelehnten Pakete entfernen oder Ihre Patch-Baseline-Regeln ändern.
+ Wenn Sie die gesperrten Pakete nicht erkennen und sie nicht absichtlich gesperrt wurden, handelt es sich möglicherweise um Restsperren aus einem zuvor unterbrochenen Patch-Vorgang.
**Schritt 3: Entfernen von Sperren nach Notwendigkeit**
Mit diesem Befehl können Sie bestimmte Paketsperren entfernen:
```
sudo zypper removelock package-name
```
Um alle Paketsperren zu entfernen (mit Vorsicht verwenden), führen Sie folgenden Befehl aus:
```
sudo zypper cleanlocks
```
**Schritt 4: Aktualisieren Ihrer Patch-Baseline (falls zutreffend)**
Wenn die Sperren durch abgelehnte Patches in Ihrer Patch-Baseline verursacht wurden:
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Patch Manager** aus.
1. Wählen Sie die Registerkarte **Patch-Baselines** und dann Ihre benutzerdefinierte Patch-Baseline aus.
1. Wählen Sie **Aktionen**, **Patch-Baseline ändern** aus.
1. Überprüfen Sie im Abschnitt **Abgelehnte Patches** die aufgelisteten Pakete und entfernen Sie alle Pakete, deren Installation zulässig sein sollte.
1. Wählen Sie **Änderungen speichern ** aus.
**Schritt 5: Wiederholen des Patch-Vorgangs**
Nachdem Sie die problematischen Sperren entfernt und gegebenenfalls Ihre Patch-Baseline aktualisiert haben, führen Sie das `AWS-RunPatchBaseline`-Dokument erneut aus.
**Anmerkung**
Wenn während der `Install`-Vorgänge Patch Manager Sperren für abgelehnte Patches anwendet, ist es so konzipiert, dass diese Sperren nach Abschluss des Patch-Vorgangs automatisch aufgehoben werden. Wenn Sie diese Sperren bei der Ausführung von `sudo zypper locks` sehen, bedeutet das, dass ein früherer Patch-Vorgang unterbrochen wurde, bevor die Aufhebung durchgeführt werden konnte. Wenn ein Patch-Vorgang jedoch unterbrochen wird, ist möglicherweise eine manuelle Aufhebung erforderlich, wie in diesem Verfahren beschrieben.
**Prävention**: Vermeiden Sie zukünftige Zypper-Sperrkonflikte wie folgt:
+ Prüfen Sie die Liste der abgelehnten Patches Ihrer Patch-Baseline sorgfältig, um sicherzustellen, dass sie nur Pakete enthält, die Sie wirklich ausschließen möchten.
+ Vermeiden Sie es, Pakete, die möglicherweise als Abhängigkeiten für Sicherheitsupdates benötigt werden, manuell zu sperren.
+ Wenn Sie Pakete manuell sperren müssen, dokumentieren Sie die Gründe dafür und überprüfen Sie die Sperren regelmäßig.
+ Stellen Sie sicher, dass die Patch-Vorgänge erfolgreich abgeschlossen werden und nicht durch Systemneustarts oder andere Faktoren unterbrochen werden.
+ Überwachen Sie Patch-Vorgänge bis zum Abschluss und vermeiden Sie es, sie durch Systemneustarts oder andere Aktionen zu unterbrechen, die das ordnungsgemäße Löschen temporärer Sperren verhindern könnten.
### Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.
**Problem**: Beim Ausführen `AWS-RunPatchBaseline` schlägt das Patchen mit Fehlercode 4 und der folgenden Fehlermeldung fehl.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Ursache**: Dieser Fehler tritt auf, wenn mehrere Patch-Operationen versuchen, auf demselben verwalteten Knoten gleichzeitig auszuführen. Die Sperrdatei verhindert gleichzeitige Patch-Vorgänge, um Konflikte zu vermeiden und die Systemstabilität zu gewährleisten.
**Lösung**: Stellen Sie sicher, dass Patchvorgänge nicht so geplant sind, dass sie gleichzeitig auf demselben verwalteten Knoten ausgeführt werden. Überprüfen Sie die folgenden Konfigurationen, um Planungskonflikte zu identifizieren und zu lösen:
+ **Patch-Richtlinien**: Überprüfen Sie Ihre Quick Setup-Patchrichtlinien-Konfigurationen, um sicherzustellen, dass sie sich nicht mit anderen Patch-Zeitplänen überschneiden.
+ **Wartungsfenster**: Überprüfen Sie die Zuordnungen Ihrer Wartungsfenster, um sicherzustellen, dass nicht mehrere Fenster auf dieselben verwalteten Knoten abzielen, wobei sich die Patch-Aufgaben zu überschneidenden Zeiten befinden.
+ **Manuelle Patch-Now-Operationen**: Vermeiden Sie es, manuelle **Patch-Now-Operationen** zu initiieren, während das geplante Patchen ausgeführt wird.
## Fehler beim Ausführen von `AWS-RunPatchBaseline` unter Windows Server
**Topics**
+ [Problem: Nicht übereinstimmende Produktpaare family/product](#patch-manager-troubleshooting-product-family-mismatch)
+ [Problem: `AWS-RunPatchBaseline`-Ausgabe gibt einen `HRESULT` (Windows Server) zurück](#patch-manager-troubleshooting-hresult)
+ [Problem: Der verwaltete Knoten hat keinen Zugriff auf Windows Update Catalog oder WSUS](#patch-manager-troubleshooting-instance-access)
+ [Problem: PatchBaselineOperations PowerShell Das Modul kann nicht heruntergeladen werden](#patch-manager-troubleshooting-module-not-downloadable)
+ [Problem: fehlende Patches](#patch-manager-troubleshooting-missing-patches)
+ [Problem: Die Sperre kann nicht erworben werden. Ein weiterer Patch-Vorgang ist im Gange.](#patch-manager-troubleshooting-windows-concurrent-lock)
### Problem: Nicht übereinstimmende Produktpaare family/product
**Problem**: Wenn Sie eine Patch-Baseline in der Systems Manager-Konsole erstellen, geben Sie eine Produktfamilie und ein Produkt an. Beispiel:
+ **Product Family (Produktfamilie)**: `Office`
**Produkt**: `Office 2016`
**Ursache**: Wenn Sie versuchen, eine Patch-Baseline mit einem nicht übereinstimmenden family/product Produktpaar zu erstellen, wird eine Fehlermeldung angezeigt. Dies kann folgende Ursachen haben:
+ Sie haben eine gültige Kombination aus Produktfamilie und Produktpaar ausgewählt, dann jedoch die Auswahl der Produktfamilie entfernt.
+ Sie haben ein Produkt aus der Unterliste **Obsolete or mismatched options (Veraltete oder nicht übereinstimmende Optionen)** statt aus der Unterliste **Available and matching options (Verfügbare und übereinstimmende Optionen)** ausgewählt.
Artikel in der Produktunterliste **Veraltete oder nicht übereinstimmende Optionen** wurden möglicherweise fälschlicherweise über ein SDK oder AWS Command Line Interface den Befehl () eingegeben.AWS CLI`create-patch-baseline` Dadurch kann es zu einem Schreibfehler oder einer falschen Zuordnung eines Produkts zu einer Produktfamilie kommen. Ein Produkt kann auch in der Unterliste **Obsolete or mismatched options (Veraltete oder nicht übereinstimmende Optionen)** enthalten sein, wenn es für eine vorherige Patch-Baseline angegeben wurde, aber keine Patches für das Produkt von Microsoft verfügbar sind.
**Lösung**: Um dieses Problem in der Konsole zu vermeiden, wählen Sie immer Optionen aus den Unterlisten **Currently available options (Derzeit verfügbare Optionen)** aus.
Um diejenigen Produkte anzuzeigen, für die Patches verfügbar sind, können Sie auch den Befehl `[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)` in der AWS CLI oder den API-Befehl `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)` verwenden.
### Problem: `AWS-RunPatchBaseline`-Ausgabe gibt einen `HRESULT` (Windows Server) zurück
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
----------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
```
**Ursache**: Diese Ausgabe weist darauf hin, dass das systemeigene Windows Update die Patchvorgänge nicht ausführen APIs konnte.
**Lösung**: Überprüfen Sie den `HResult`-Code in den folgenden Themen auf microsoft.com, um Schritte zur Fehlerbehebung zum Beheben des Fehlers zu ermitteln:
+ [Windows-Update-Fehlercodes nach Komponenten](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Häufige Fehler und Abhilfemaßnahmen für Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### Problem: Der verwaltete Knoten hat keinen Zugriff auf Windows Update Catalog oder WSUS
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
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----
```
**Ursache**: Dieser Fehler kann mit den Windows Update-Komponenten oder einer fehlenden Konnektivität zum Windows Update Catalog oder Windows Server Update Services (WSUS) zusammenhängen.
**Lösung**: Bestätigen Sie, dass der verwaltete Knoten über ein Internet-Gateway, ein NAT-Gateway oder eine NAT-Instance eine Verbindung zum [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) hergestellt hat. Wenn Sie WSUS verwenden, bestätigen Sie, dass der verwaltete Knoten eine Verbindung zum WSUS-Server in Ihrer Umgebung hat. Wenn Konnektivität für das beabsichtigte Ziel verfügbar ist, überprüfen Sie die Microsoft-Dokumentation auf andere mögliche Ursachen für `HResult 0x80072EE2`. Dies kann auf ein Problem auf Betriebssystemebene hinweisen.
### Problem: PatchBaselineOperations PowerShell Das Modul kann nicht heruntergeladen werden
**Problem:** Sie haben eine Fehlermeldung wie die folgende erhalten.
```
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
```
**Lösung**: Überprüfen Sie die Konnektivität und Berechtigungen für Amazon Simple Storage Service (Amazon S3) des verwalteten Knoten. Für die Rolle des verwalteten Knotens AWS Identity and Access Management (IAM) müssen die unter angegebenen Mindestberechtigungen verwendet werden. [SSM AgentKommunikation mit AWS verwalteten S3-Buckets](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions) Der Knoten muss über den Amazon-S3-Gateway-Endpunkt, das NAT-Gateway oder das Internet-Gateway mit dem Amazon-S3-Endpunkt kommunizieren. Weitere Informationen zu den VPC-Endpunktanforderungen für AWS Systems Manager SSM Agent (SSM Agent) finden Sie unter[Die Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für Systems Manager verbessern](setup-create-vpc.md).
### Problem: fehlende Patches
**Problem**: `AWS-RunPatchbaseline` wurde erfolgreich abgeschlossen, aber es fehlen einige Patches.
Nachfolgend finden Sie einige häufige Auslöser und deren Lösungen.
**Ursache 1**: Die Baseline ist nicht effektiv.
**Lösung 1**: Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies die Ursache ist.
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie die Registerkarte **Befehlsverlauf** und dann den Befehl aus, dessen Baseline Sie überprüfen möchten.
1. Wählen Sie den verwalteten Knoten aus, dem Patches fehlen.
1. Wählen Sie **Schritt 1 – Ausgabe** aus und finden Sie den `BaselineId`-Wert.
1. Aktivieren Sie die zugewiesene [Patch-Baseline-Konfiguration](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom), d. h. Betriebssystem, Produktname, Klassifizierung und Schweregrad für die Patch-Baseline.
1. Rufen Sie den [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) auf.
1. Suchen Sie im Artikel der Microsoft Knowledge Base IDs (KB) (z. B. KB3216916).
1. Stellen Sie sicher, dass der Wert unter **Product** (Produkt) dem Ihres verwalteten Knotens entspricht, und wählen Sie den entsprechenden **Title** (Titel) aus. Ein neues Fenser **Details aktualisieren** wird geöffnet.
1. In der Registerkarte **Übersicht** müssen **Klassifizierung** und **Schweregrad des MSRC** der Patch-Baseline-Konfiguration entsprechen, die Sie zuvor gefunden haben.
**Ursache 2**: Das Patch wurde ersetzt.
**Lösung 2**: Führen Sie die folgenden Schritte aus, um zu überprüfen, ob dies der Fall ist.
1. Rufen Sie den [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/home.aspx) auf.
1. Suchen Sie im Artikel der Microsoft Knowledge Base IDs (KB) (z. B. KB3216916).
1. Stellen Sie sicher, dass der Wert unter **Product** (Produkt) dem Ihres verwalteten Knotens entspricht, und wählen Sie den entsprechenden **Title** (Titel) aus. Ein neues Fenser **Details aktualisieren** wird geöffnet.
1. Gehen Sie zur Registerkarte **Paketdetails**. Suchen Sie nach einem Eintrag unter dem Header **Dieses Update wurde durch die folgenden Updates ersetzt:**.
**Ursache 3**: Dasselbe Patch hat möglicherweise unterschiedliche KB-Nummern, da die WSUS- und Windows-Online-Updates von Microsoft als unabhängige Versionskanäle behandelt werden.
**Lösung 3**: Überprüfen Sie die Berechtigung des Patches. Wenn das Paket unter WSUS nicht verfügbar ist, installieren Sie [OS Build 14393.3115](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57). Wenn das Paket für alle Betriebssystem-Builds verfügbar ist, installieren Sie [OS-Builds 18362.1256 und 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9).
### Problem: Die Sperre kann nicht erworben werden. Ein weiterer Patch-Vorgang ist im Gange.
**Problem**: Beim Ausführen `AWS-RunPatchBaseline` schlägt das Patchen mit Fehlercode 4 und der folgenden Fehlermeldung fehl.
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Ursache**: Dieser Fehler tritt auf, wenn mehrere Patch-Operationen versuchen, auf demselben verwalteten Knoten gleichzeitig auszuführen. Die Sperrdatei verhindert gleichzeitige Patch-Vorgänge, um Konflikte zu vermeiden und die Systemstabilität zu gewährleisten.
**Lösung**: Stellen Sie sicher, dass Patchvorgänge nicht so geplant sind, dass sie gleichzeitig auf demselben verwalteten Knoten ausgeführt werden. Überprüfen Sie die folgenden Konfigurationen, um Planungskonflikte zu identifizieren und zu lösen:
+ **Patch-Richtlinien**: Überprüfen Sie Ihre Quick Setup-Patchrichtlinien-Konfigurationen, um sicherzustellen, dass sie sich nicht mit anderen Patch-Zeitplänen überschneiden.
+ **Wartungsfenster**: Überprüfen Sie die Zuordnungen Ihrer Wartungsfenster, um sicherzustellen, dass nicht mehrere Fenster auf dieselben verwalteten Knoten abzielen, wobei sich die Patch-Aufgaben zu überschneidenden Zeiten befinden.
+ **Manuelle Patch-Now-Operationen**: Vermeiden Sie es, manuelle **Patch-Now-Operationen** zu initiieren, während das geplante Patchen ausgeführt wird.
## Fehler bei der Ausführung `AWS-RunPatchBaseline` auf macOS
**Topics**
+ [Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.](#patch-manager-troubleshooting-macos-concurrent-lock)
### Problem: Die Sperre kann nicht abgerufen werden. Ein weiterer Patch-Vorgang ist im Gange.
**Problem**: Beim Ausführen `AWS-RunPatchBaseline` schlägt das Patchen mit Fehlercode 4 und der folgenden Fehlermeldung fehl.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Ursache**: Dieser Fehler tritt auf, wenn mehrere Patch-Operationen versuchen, auf demselben verwalteten Knoten gleichzeitig auszuführen. Die Sperrdatei verhindert gleichzeitige Patch-Vorgänge, um Konflikte zu vermeiden und die Systemstabilität zu gewährleisten.
**Lösung**: Stellen Sie sicher, dass Patchvorgänge nicht so geplant sind, dass sie gleichzeitig auf demselben verwalteten Knoten ausgeführt werden. Überprüfen Sie die folgenden Konfigurationen, um Planungskonflikte zu identifizieren und zu lösen:
+ **Patch-Richtlinien**: Überprüfen Sie Ihre Quick Setup-Patchrichtlinien-Konfigurationen, um sicherzustellen, dass sie sich nicht mit anderen Patch-Zeitplänen überschneiden.
+ **Wartungsfenster**: Überprüfen Sie die Zuordnungen Ihrer Wartungsfenster, um sicherzustellen, dass nicht mehrere Fenster auf dieselben verwalteten Knoten abzielen, wobei sich die Patch-Aufgaben zu überschneidenden Zeiten befinden.
+ **Manuelle Patch-Now-Operationen**: Vermeiden Sie es, manuelle **Patch-Now-Operationen** zu initiieren, während das geplante Patchen ausgeführt wird.
## Verwenden von Automation-Runbooks AWS Support
AWS Support stellt zwei Automation-Runbooks bereit, mit denen Sie bestimmte Probleme im Zusammenhang mit Patches beheben können.
+ `AWSSupport-TroubleshootWindowsUpdate` – Das [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)-Runbook wird verwendet, um Probleme zu identifizieren, bei denen die Windows Server-Updates für Amazon Elastic Compute Cloud (Amazon EC2) Windows Server-Instances fehlschlagen könnten.
+ `AWSSupport-TroubleshootPatchManagerLinux` – Das [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)-Runbook behebt häufig auftretende Probleme, die zu einem Patch-Fehler auf Linux-basierten verwalteten Knoten führen können, mithilfe von Patch Manager. Das Hauptziel dieses Runbooks besteht darin, die Hauptursache des Fehlers beim Patch-Befehl zu ermitteln und einen Plan zur Behebung vorzuschlagen.
**Anmerkung**
Für die Ausführung von Automation-Runbooks fallen Gebühren an. Weitere Informationen finden Sie unter [AWS Systems Manager Preise für Automatisierung](https://aws.amazon.com/systems-manager/pricing/#Automation).
## Kontaktaufnahme AWS Support
Wenn Sie Problembehandlungs-Lösungen in diesem Abschnitt oder im bschnitt zu Systems-Manager-Problemen in [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager) nicht finden können und einen [Developer-, Business- oder Enterprise- Support -Plan](https://aws.amazon.com/premiumsupport/plans) haben, können Sie unter [AWS Support](https://aws.amazon.com/premiumsupport/) einen technischen Supportfall erstellen.
Sammeln Sie die folgenden Artikel Support, bevor Sie Kontakt aufnehmen:
+ [SSM-Agent-Protokolle](ssm-agent-logs.md)
+ Run Command-Befehls-ID, Wartungsfenster-ID oder Automatisierungsausführungs-ID
+ Sammeln Sie für von Windows Server verwaltete Knoten auch Folgendes:
+ `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs`, wie auf der **Windows**-Registerkarte von [Wie Patches installiert werden](patch-manager-installing-patches.md) beschrieben
+ Windows Update-Protokolle: Für Windows Server 2012 R2 und älter verwenden Sie `%windir%/WindowsUpdate.log`. Führen Sie für Windows Server 2016 und neuere Versionen zuerst den PowerShell Befehl aus, [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)bevor Sie `%windir%/WindowsUpdate.log`
+ Sammeln Sie für Linux-verwaltete Knoten auch Folgendes:
+ Der Inhalt des Verzeichnisses `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
# AWS Systems Manager Run Command
Mithilfe Run Command eines Tools in AWS Systems Manager können Sie die Konfiguration Ihrer verwalteten Knoten remote und sicher verwalten. Ein *verwalteter Knoten* ist jede Amazon Elastic Compute Cloud (Amazon EC2) -Instanz oder EC2 Nicht-Maschine in Ihrer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types), die für Systems Manager konfiguriert wurde. Run Commandermöglicht es Ihnen, allgemeine Verwaltungsaufgaben zu automatisieren und einmalige Konfigurationsänderungen in großem Umfang durchzuführen. Sie können Run Command von AWS-Managementkonsole, dem AWS Command Line Interface (AWS CLI) AWS Tools for Windows PowerShell, oder dem verwenden AWS SDKs. Run Commandwird ohne zusätzliche Kosten angeboten. Um mit Run Command zu beginnen, öffnen Sie die [Systems-Manager-Konsole](https://console.aws.amazon.com//systems-manager/run-command). Wählen Sie im Navigationsbereich **Run Command** aus.
Administratoren verwenden Run Command zum Installieren oder Bootstrapping von Anwendungen, Entwickeln einer Bereitstellungs-Pipeline, Erfassen von Protokolldateien nach Entfernung einer Instance aus einer Auto-Scaling-Gruppe, zum Anschließen von Instances an eine Windows-Domain und noch mehr.
Aufgrund der verteilten Natur des Systems, das die API unterstützt, folgt die Run Command-API einem eventuellen Konsistenzmodell. Dies bedeutet, dass das Ergebnis eines von Ihnen ausgeführten API-Befehls, der sich auf Ihre Ressourcen auswirkt, möglicherweise nicht sofort für alle nachfolgenden Befehle, die Sie ausführen, sichtbar ist. Sie sollten dies berücksichtigen, wenn Sie einen API-Befehl ausführen, der unmittelbar auf einen vorherigen API-Befehl folgt.
**Erste Schritte**
Die folgende Tabelle enthält Informationen, die Ihnen bei den ersten Schritten mit Run Command helfen werden.
****
| Thema | Details |
| --- | --- |
| [Einrichtung verwalteter Knoten für AWS Systems Manager](systems-manager-setting-up-nodes.md) | Stellen Sie sicher, dass Sie die Einrichtungsvoraussetzungen für Ihre Amazon Elastic Compute Cloud (Amazon EC2) -Instances und EC2 Nicht-Maschinen in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) erfüllt haben. |
| [Verwalten von Knoten in Hybrid- und Multi-Cloud-Umgebungen mit Systems Manager](systems-manager-hybrid-multicloud.md) | (Optional) Registrieren Sie lokale Server und VMs mit, AWS damit Sie sie mithilfe von verwalten können. Run Command |
| [Verwalten von Edge-Geräten mit Systems Manager](systems-manager-setting-up-edge-devices.md) | (Optional) Konfigurieren Sie Edge-Geräte, damit Sie sie mit Run Command verwalten können. |
| [Ausführen von Befehlen auf verwalteten Knoten](running-commands.md) | Erfahren Sie, wie Sie mit der AWS-Managementkonsole einen Befehl ausführen, der einen oder mehrere verwaltete Knoten anvisiert. |
| [Walkthroughs für Run Command](run-command-walkthroughs.md) | Erfahren Sie, wie Sie Befehle entweder mit Tools für Windows PowerShell oder mit dem AWS CLI ausführen. |
**EventBridge Unterstützung**
Dieses Systems Manager Manager-Tool wird in EventBridge Amazon-Regeln sowohl als *Ereignistyp* als auch als *Zieltyp* unterstützt. Weitere Informationen finden Sie unter [Überwachung von Systems Manager Manager-Ereignissen mit Amazon EventBridge](monitoring-eventbridge-events.md) und [Referenz: EventBridge Amazon-Ereignistypen und -muster für Systems Manager](reference-eventbridge-events.md).
**Weitere Informationen**
+ [Aus Run Command der Ferne auf einer EC2 Instance (10-minütiges Tutorial)](https://aws.amazon.com/getting-started/hands-on/remotely-run-commands-ec2-instance-systems-manager/)
+ [Systems Manager-Service Quotas](https://docs.aws.amazon.com/general/latest/gr/ssm.html#limits_ssm) im *Allgemeine Amazon Web Services-Referenz*
+ [AWS Systems Manager API Reference](https://docs.aws.amazon.com/systems-manager/latest/APIReference/)
**Topics**
+ [Einrichten von Run Command](run-command-setting-up.md)
+ [Ausführen von Befehlen auf verwalteten Knoten](running-commands.md)
+ [Verwendung von Beendigungscodes in Befehlen](run-command-handle-exit-status.md)
+ [Grundlegendes zu Befehlsstatus](monitor-commands.md)
+ [Walkthroughs für Run Command](run-command-walkthroughs.md)
+ [Fehlerbehebung von Systems Manager Run Command](troubleshooting-remote-commands.md)
# Einrichten von Run Command
Bevor Sie Knoten mithilfe eines Tools in verwalten können Run Command AWS Systems Manager, konfigurieren Sie eine AWS Identity and Access Management (IAM-) Richtlinie für jeden Benutzer, der Befehle ausführt. Wenn Sie in Ihren IAM-Richtlinien globale Bedingungsschlüssel für die `SendCommand`-Aktion verwenden, müssen Sie den `aws:ViaAWSService`-Bedingungsschlüssel angeben und den booleschen Wert auf `true` setzen. Im Folgenden wird ein -Beispiel gezeigt.
------
#### [ 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"
}
}
}
]
}
```
------
Sie müssen Ihre Knoten auch für Systems Manager konfigurieren. Weitere Informationen finden Sie unter [Einrichtung verwalteter Knoten für AWS Systems Manager](systems-manager-setting-up-nodes.md).
Wir empfehlen, die folgenden optionalen Einrichtungsaufgaben durchzuführen, um den Sicherheitsstatus und die day-to-day Verwaltung Ihrer verwalteten Knoten zu minimieren.
Überwachen Sie Befehlsausführungen mit Amazon EventBridge
Sie können es verwenden EventBridge , um Statusänderungen der Befehlsausführung zu protokollieren. Sie können eine Regel erstellen, die ausgeführt wird, sobald ein Statusübergang oder ein Übergang zu einem oder mehreren Status stattfindet, die für sie von Interesse sind. Sie können auch Run Command als Zielaktion angeben, wann ein EventBridge Ereignis eintritt. Weitere Informationen finden Sie unter [Konfiguration EventBridge für Systems Manager Manager-Ereignisse](monitoring-systems-manager-events.md).
Überwachen Sie Befehlsausführungen mithilfe von Amazon Logs CloudWatch
Sie können so konfigurierenRun Command, dass alle Befehlsausgaben und Fehlerprotokolle regelmäßig an eine CloudWatch Amazon-Protokollgruppe gesendet werden. Sie können diese Ausgabeprotokolle nahezu in Echtzeit überwachen, nach bestimmten Phrasen, Werten oder Mustern suchen und auf der Grundlage der Suche Warnungen erstellen. Weitere Informationen finden Sie unter [Konfiguration von Amazon CloudWatch Logs für Run Command](sysman-rc-setting-up-cwlogs.md).
Den Zugriff von Run Command auf bestimmte verwaltete Knoten beschränken
Sie können die Fähigkeit eines Benutzers einschränken, Befehle auf verwalteten Knoten auszuführen, indem Sie AWS Identity and Access Management (IAM) verwenden. Insbesondere können Sie eine IAM-Richtlinie mit der Bedingung erstellen, dass der Benutzer nur Befehle auf verwalteten Knoten ausführen kann, die mit bestimmten Tags gekennzeichnet sind. Weitere Informationen finden Sie unter [Den Zugriff von Run Command anhand von Tags beschränken](#tag-based-access).
## Den Zugriff von Run Command anhand von Tags beschränken
In diesem Abschnitt wird beschrieben, wie die Fähigkeit eines Benutzers eingeschränkt werden kann, Befehle für verwaltete Knoten auszuführen, indem eine Tag-Bedingung in einer IAM-Richtlinie angegeben wird. Zu den verwalteten Knoten gehören EC2 Amazon-Instances und EC2 Nicht-Knoten in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types), die für Systems Manager konfiguriert sind. Die Informationen werden zwar nicht explizit dargestellt, Sie können aber auch den Zugriff auf verwaltete AWS IoT Greengrass Kerngeräte einschränken. Zuerst müssen Sie Ihre AWS IoT Greengrass -Geräte markieren. Weitere Informationen finden Sie unter [Markieren Ihrer AWS IoT Greengrass Version 2 -Ressourcen](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) im *AWS IoT Greengrass Version 2 -Entwicklerhandbuch*.
Sie können die Befehlsausführung auf bestimmte verwaltete Knoten beschränken, indem Sie eine IAM-Richtlinie erstellen, die eine Bedingung enthält, dass der Benutzer Befehle nur auf Knoten mit bestimmten Tags ausführen kann. Im folgenden Beispiel darf der Benutzer () verwenden, indem er ein beliebiges SSM-Dokument Run Command (`Effect: Allow, Action: ssm:SendCommand`) auf einem beliebigen Knoten (`Resource: arn:aws:ssm:*:*:document/*``Resource: arn:aws:ec2:*:*:instance/*`) verwendet, unter der Bedingung, dass es sich bei dem Knoten um einen Finanzknoten WebServer (`ssm:resourceTag/Finance: WebServer`) handelt. Wenn der Benutzer einen Befehl an einen Knoten sendet, der nicht markiert ist oder ein anderes Tag als `Finance: WebServer` hat, zeigen die Ausführungsergebnisse `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"
]
}
}
}
]
}
```
------
Sie können IAM-Richtlinien erstellen, die es einem Benutzer erlauben, Befehle auf verwalteten Knoten auszuführen, die mit mehreren Tags markiert sind. Mit der folgenden Richtlinie hat der Benutzer die Möglichkeit, Befehle auf verwalteten Knoten auszuführen, die über zwei Tags verfügen. Wenn ein Benutzer einen Befehl an einen verwalteten Knoten sendet, der nicht mit beiden dieser Tags markiert ist, zeigen die Ausführungsergebnisse `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":"*"
}
]
}
```
------
Sie können auch IAM-Richtlinien erstellen, die es einem Benutzer erlauben, Befehle auf mehreren Gruppen von markierten verwalteten Knoten auszuführen. Die folgende Beispiel-Richtlinie erlaubt dem Benutzer die Ausführung von Befehlen entweder für eine der Gruppen von markierten Knoten oder für beide Gruppen.
------
#### [ 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":"*"
}
]
}
```
------
Weitere Informationen zum Erstellen von IAM-Richtlinien finden Sie unter [Verwaltete Richtlinien und eingebundene Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) im *IAM-Benutzerhandbuch*. Weitere Informationen über das Markieren verwalteter Knoten finden Sie unter [Tag-Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) im *AWS -Ressourcengruppen -Benutzerhandbuch*.
# Ausführen von Befehlen auf verwalteten Knoten
Dieser Abschnitt enthält Informationen darüber, wie Befehle aus der AWS Systems Manager -Konsole zu verwalteten Knoten gesendet werden. Dieser Abschnitt enthält auch Informationen zum Abbrechen eines Befehls.
Beachten Sie, dass Run Command Befehle nicht erfolgreich ausführen kann, wenn Ihr Knoten mit der `noexec`-Mount-Option für das Verzeichnis var konfiguriert ist.
**Wichtig**
Wenn Sie einen Befehl mit Run Command senden, schließen Sie keine vertraulichen Informationen ein, die als Klartext formatiert sind, z. B. Passwörter, Konfigurationsdaten oder andere Geheimnisse. Alle Systems Manager Manager-API-Aktivitäten in Ihrem Konto werden in einem S3-Bucket für AWS CloudTrail Protokolle protokolliert. Dies bedeutet, dass jeder Benutzer mit Zugriff auf den S3-Bucket die Klartextwerte dieser Geheimnisse anzeigen kann. Aus diesem Grund empfehlen wir, `SecureString`-Parameter zu erstellen und zu verwenden, um die sensiblen Daten zu verschlüsseln, die Sie in Ihren Systems-Manager-Operationen verwenden.
Weitere Informationen finden Sie unter [Einschränken des Zugriffs auf Parameter Store-Parameter mithilfe von IAM-Richtlinien](sysman-paramstore-access.md).
**Aufbewahrung des Ausführungsverlaufs**
Der Verlauf der einzelnen Befehle steht für bis zu 30 Tage zur Verfügung. Außerdem können Sie eine Kopie aller Protokolldateien in Amazon Simple Storage Service speichern oder einen Audit-Trail aller API-Aufrufe in AWS CloudTrail aufzeichnen.
**Ähnliche Informationen**
Weitere Informationen zum Ausführen von Befehlen über andere Tools finden Sie in den folgenden Themen:
+ [Exemplarische Vorgehensweise: Verwenden Sie das mit AWS Tools for Windows PowerShell Run Command](walkthrough-powershell.md)oder die Beispiele im [AWS Systems Manager Abschnitt der AWS -Tools für PowerShell Cmdlet-Referenz](https://docs.aws.amazon.com/powershell/latest/reference/items/AWS_Systems_Manager_cmdlets.html).
+ [Exemplarische Vorgehensweise: Verwenden Sie das mit AWS CLI Run Command](walkthrough-cli.md) oder die Beispiele in der [SSM-CLI-Referenz](https://docs.aws.amazon.com/cli/latest/reference/ssm/)
**Topics**
+ [Ausführen von Befehlen über die Konsole](running-commands-console.md)
+ [Ausführen von Befehlen mit einer bestimmten Dokumentversion](run-command-version.md)
+ [Ausführen von Befehlen in großem Maßstab](send-commands-multiple.md)
+ [Stornieren eines Befehls](cancel-run-command.md)
# Ausführen von Befehlen über die Konsole
Sie können ein Tool inRun Command, von verwenden AWS Systems Manager, um verwaltete Knoten AWS-Managementkonsole zu konfigurieren, ohne sich bei ihnen anmelden zu müssen. Dieses Thema enthält ein Beispiel für die Ausführung eines [SSM Agent-Updates](run-command-tutorial-update-software.md#rc-console-agentexample) auf einem verwalteten Knoten mithilfe von Run Command.
**Bevor Sie beginnen**
Bevor Sie einen Befehl mit Run Command senden, müssen Sie überprüfen, ob Ihre verwalteten Knoten die Systems-Manager-[Einrichtungs-Anforderungen](systems-manager-setting-up-nodes.md) erfüllen.
**So senden Sie einen Befehl mittels Run Command**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste **Befehlsdokument** ein Systems Manager-Dokument.
1. Geben Sie im Abschnitt **Befehlsparameter** Werte für erforderliche Parameter an.
1. Identifizieren Sie für den Abschnitt **Targets** (Ziele) die verwalteten Knoten, auf denen Sie diese Operation ausführen möchten, indem Sie Tags angeben, Instances oder Edge-Geräte manuell auswählen oder eine Ressourcengruppe angeben.
**Tipp**
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
1. Für **Weitere Parameter**:
+ Geben Sie im Feld **Kommentar** Informationen zu diesem Befehl ein.
+ Geben Sie für **Timeout (Sekunden)** in Sekunden an, wie lange gewartet werden soll, bis für die gesamte Befehlsausführung ein Fehler auftritt.
1. Für **Ratenregelung**:
+ Geben Sie unter **Nebenläufigkeit** entweder eine Zahl oder einen Prozentsatz der verwalteten Knoten an, auf denen der Befehl gleichzeitig ausgeführt werden soll.
**Anmerkung**
Wenn Sie Ziele ausgewählt haben, indem Sie Tags für verwaltete Knoten oder AWS Ressourcengruppen angegeben haben und Sie sich nicht sicher sind, wie viele verwaltete Knoten das Ziel sind, schränken Sie die Anzahl der Ziele ein, die das Dokument gleichzeitig ausführen können, indem Sie einen Prozentsatz angeben.
+ Geben Sie unter **Fehlerschwellenwert** an, wann die Ausführung des Befehls auf anderen verwalteten Knoten beendet werden soll, nachdem dafür entweder auf einer bestimmten Anzahl oder einem Prozentsatz von Knoten ein Fehler aufgetreten ist. Falls Sie beispielsweise drei Fehler angeben, sendet Systems Manager keinen Befehl mehr, wenn der vierte Fehler empfangen wird. Von verwalteten Knoten, auf denen der Befehl noch verarbeitet wird, werden unter Umständen ebenfalls Fehler gesendet.
1. (Optional) Wählen Sie einen CloudWatch Alarm aus, der auf Ihren Überwachungsbefehl angewendet werden soll. Um Ihrem Befehl einen CloudWatch Alarm hinzuzufügen, muss der IAM-Principal, der den Befehl ausführt, über die entsprechende Berechtigung verfügen`iam:createServiceLinkedRole`. Weitere Informationen zu CloudWatch Alarmen finden Sie unter [ CloudWatch Amazon-Alarme verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Beachten Sie, dass ausstehende Befehlsaufrufe nicht ausgeführt werden, wenn Ihr Alarm aktiviert wird.
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben in einen S3-Bucket aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Bei den S3-Berechtigungen, die das Schreiben der Daten in einen S3-Bucket ermöglichen, handelt es sich um die Berechtigungen des Instance-Profils (für EC2 Instances) oder der IAM-Servicerolle (hybridaktivierte Maschinen), die der Instance zugewiesen wurden, nicht um die des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
1. Aktivieren Sie das Kontrollkästchen **SNS-Benachrichtigungen aktivieren** im Abschnitt **SNS-Benachrichtigungen**, wenn Sie über den Status der Befehlsausführung benachrichtigt werden möchten,
Weitere Informationen zum Konfigurieren von Amazon-SNS-Benachrichtigungen für Run Command finden Sie unter [Überwachung von Systems Manager-Statusänderungen mit Amazon SNS-Benachrichtigungen](monitoring-sns-notifications.md).
1. Klicken Sie auf **Ausführen**.
Weitere Informationen zum Abbrechen eines Befehls finden Sie unter [Stornieren eines Befehls](cancel-run-command.md).
## Erneutes Ausführen von Befehlen
Systems Manager enthält zwei Optionen, mit denen Sie einen Befehl auf der Seite **Run Command (Befehl ausführen)** in der Systems Manager-Konsole erneut ausführen können.
+ **Rerun (Erneut ausführen)**: Über diese Schaltfläche können Sie denselben Befehl ausführen, ohne Änderungen daran vorzunehmen.
+ **In neu kopieren**: Über diese Schaltfläche kopieren Sie die Einstellungen eines Befehls in einen neuen Befehl und erhalten die Möglichkeit, diese Einstellungen zu bearbeiten, bevor Sie den Befehl ausführen.
**So führen Sie einen Befehl erneut aus**
1. Öffnen Sie die Konsole unter. AWS Systems Manager [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie einen Befehl aus, der erneut ausgeführt werden soll. Sie können einen Befehl unmittelbar nach der Ausführung von der Befehlsdetailseite aus erneut ausführen. Sie können auch einen Befehl auswählen, den Sie zuvor auf der Registerkarte **Command history (Befehlsverlauf)** ausgeführt haben.
1. Wählen Sie entweder **Rerun (Erneut ausführen)** aus, um denselben Befehl ohne Änderungen auszuführen, oder wählen Sie **Copy to new (In neuen kopieren)** aus, um die Befehlseinstellungen zu bearbeiten, bevor Sie den Befehl ausführen.
# Ausführen von Befehlen mit einer bestimmten Dokumentversion
Sie können den Dokumentversionsparameter verwenden, um anzugeben, welche Version eines AWS Systems Manager -Dokuments verwendet werden soll, wenn der Befehl ausgeführt wird. Sie können eine der folgenden Optionen für diesen Parameter festlegen:
+ \$1DEFAULT
+ \$1LATEST
+ Versionsnummer:
Gehen Sie wie folgt vor, um einen Befehl unter Verwendung des Dokumentversionsparameters auszuführen.
------
#### [ Linux ]
**Um Befehle mit dem AWS CLI auf lokalen Linux-Computern auszuführen**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Listen Sie alle verfügbaren Dokumente auf
Dieser Befehl listet alle für Ihr Konto verfügbaren Dokumente auf der Grundlage von AWS Identity and Access Management (IAM-) Berechtigungen auf.
```
aws ssm list-documents
```
1. Verwenden Sie den folgenden Befehl, um die verschiedenen Versionen eines Dokuments anzuzeigen. Ersetzen Sie es *document name* durch Ihre eigenen Informationen.
```
aws ssm list-document-versions \
--name "document name"
```
1. Führen Sie mit dem folgenden Befehl einen Befehl aus, der eine SSM-Dokumentversion verwendet. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
```
aws ssm send-command \
--document-name "AWS-RunShellScript" \
--parameters commands="echo Hello" \
--instance-ids instance-ID \
--document-version '$LATEST'
```
------
#### [ Windows ]
**Um Befehle mit dem AWS CLI auf lokalen Windows-Computern auszuführen**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Listen Sie alle verfügbaren Dokumente auf
Dieser Befehl listet alle für Ihr Konto verfügbaren Dokumente auf der Grundlage von AWS Identity and Access Management (IAM-) Berechtigungen auf.
```
aws ssm list-documents
```
1. Verwenden Sie den folgenden Befehl, um die verschiedenen Versionen eines Dokuments anzuzeigen. Ersetzen Sie es *document name* durch Ihre eigenen Informationen.
```
aws ssm list-document-versions ^
--name "document name"
```
1. Führen Sie mit dem folgenden Befehl einen Befehl aus, der eine SSM-Dokumentversion verwendet. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
```
aws ssm send-command ^
--document-name "AWS-RunShellScript" ^
--parameters commands="echo Hello" ^
--instance-ids instance-ID ^
--document-version "$LATEST"
```
------
#### [ PowerShell ]
**Um Befehle mit den Tools für auszuführen PowerShell**
1. Installieren und konfigurieren Sie die AWS -Tools für PowerShell (Tools für Windows PowerShell), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren des AWS -Tools für PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Listen Sie alle verfügbaren Dokumente auf
Dieser Befehl listet alle für Ihr Konto verfügbaren Dokumente auf der Grundlage von AWS Identity and Access Management (IAM-) Berechtigungen auf.
```
Get-SSMDocumentList
```
1. Verwenden Sie den folgenden Befehl, um die verschiedenen Versionen eines Dokuments anzuzeigen. Ersetzen Sie es *document name* durch Ihre eigenen Informationen.
```
Get-SSMDocumentVersionList `
-Name "document name"
```
1. Führen Sie mit dem folgenden Befehl einen Befehl aus, der eine SSM-Dokumentversion verwendet. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
```
Send-SSMCommand `
-DocumentName "AWS-RunShellScript" `
-Parameter @{commands = "echo helloWorld"} `
-InstanceIds "instance-ID" `
-DocumentVersion $LATEST
```
------
# Ausführen von Befehlen in großem Maßstab
Sie könnenRun Command, ein Tool in AWS Systems Manager, verwenden, um Befehle auf einer Flotte verwalteter Knoten auszuführen, indem Sie den verwenden`targets`. Der `targets`-Parameter nimmt eine `Key,Value`-Kombination basierend auf Tags an, die Sie für Ihre verwalteten Knoten angegeben haben. Wenn Sie den Befehl ausführen, versucht das System, den Befehl auf allen verwalteten Knoten auszuführen, die den angegebenen Tags entsprechen. Weitere Informationen zum Taggen verwalteter Instances finden Sie unter [Tagging Your AWS Resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-editor.html) im *Tagging AWS Resources* User Guide. Informationen zum Taggen Ihrer verwalteten IoT-Geräte finden Sie unter [Taggen Ihrer AWS IoT Greengrass Version 2 Ressourcen](https://docs.aws.amazon.com/greengrass/v2/developerguide/tag-resources.html) im *AWS IoT Greengrass Version 2 Entwicklerhandbuch*.
Sie können den `targets` Parameter auch verwenden, um eine Liste bestimmter verwalteter Knoten als Ziel IDs festzulegen, wie im nächsten Abschnitt beschrieben.
Zur Steuerung der Befehlsausführung auf Hunderten und Tausenden von verwalteten Knoten umfasst Run Command auch Parameter für die Einschränkung, wie viele Knoten gleichzeitig eine Anforderung verarbeitet können, und wie viele Fehler durch einen Befehl ausgelöst werden können, bevor der Befehl beendet wird.
**Topics**
+ [Mehrere verwaltete Knoten anvisieren](#send-commands-targeting)
+ [Verwenden von Ratensteuerungen](#send-commands-rate)
## Mehrere verwaltete Knoten anvisieren
Sie können einen Befehl ausführen und auf verwaltete Knoten abzielen, indem Sie Tags, AWS Ressourcengruppennamen oder verwaltete Knoten angeben IDs.
Die folgenden Beispiele zeigen das Befehlsformat bei der Verwendung Run Command von from the AWS Command Line Interface (AWS CLI ). Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen. Die Beispielbefehle werden in diesem Abschnitt sind mit `[...]` abgeschnitten.
**Beispiel 1: Angabe von Tags als Ziel**
------
#### [ 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 ^
[...]
```
------
**Beispiel 2: Eine AWS Ressourcengruppe anhand des Namens als Zielgruppenadressierung**
Sie können maximal einen Ressourcengruppenamen pro Befehlsaufruf angeben. Wenn Sie eine Ressourcengruppe erstellen, empfehlen wir, `AWS::SSM:ManagedInstance` und `AWS::EC2::Instance` als Ressourcentypen in dem Gruppierungskriterium aufzunehmen.
**Anmerkung**
Um Befehle senden zu können, die auf eine Ressourcengruppe abzielen, müssen Ihnen AWS Identity and Access Management (IAM) Berechtigungen zum Auflisten oder Anzeigen der Ressourcen, die zu dieser Gruppe gehören, erteilt worden sein. Weitere Informationen finden Sie unter [Einrichten von Berechtigungen](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions) im *AWS -Ressourcengruppen -Benutzerhandbuch*.
------
#### [ 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 ^
[...]
```
------
**Beispiel 3: Ausrichtung auf eine AWS Ressourcengruppe nach Ressourcentyp**
Sie können maximal fünf Ressourcengruppentypen pro Befehlsaufruf angeben. Wenn Sie eine Ressourcengruppe erstellen, empfehlen wir, `AWS::SSM:ManagedInstance` und `AWS::EC2::Instance` als Ressourcentypen in dem Gruppierungskriterium aufzunehmen.
**Anmerkung**
Zum Senden von Befehlen mit einer Ressourcengruppe als Ziel benötigen Sie IAM-Berechtigungen zum Auflisten oder Anzeigen der Ressourcen, die zu der Gruppe gehören. Weitere Informationen finden Sie unter [Einrichten von Berechtigungen](https://docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-prereqs.html#gettingstarted-prereqs-permissions) im *AWS -Ressourcengruppen -Benutzerhandbuch*.
------
#### [ 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 ^
[...]
```
------
**Beispiel 4: Zielinstanz IDs**
Die folgenden Beispiele veranschaulichen, wie verwaltete Knoten mithilfe des `instanceids`-Schlüssels mit dem `targets`-Parameter anvisiert werden können. Sie können diesen Schlüssel verwenden, um verwaltete AWS IoT Greengrass Kerngeräte als Ziel zu verwenden, da jedem Gerät ein Mi- zugewiesen ist*ID\$1number*. Sie können das Gerät IDs in anzeigenFleet Manager, ein Tool in 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 ^
[...]
```
------
Wenn Sie verwaltete Knoten für unterschiedliche Umgebungen mit einem `Key` namens `Environment` und `Values` von `Development`, `Test`, `Pre-production` und`Production` markiert haben, könnten Sie einen Befehl an alle verwalteten Knoten in *einer* dieser Umgebungen mit dem `targets`-Parameter mit der folgenden Syntax senden.
------
#### [ 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 ^
[...]
```
------
Sie könnten weitere verwaltete Knoten in anderen Umgebungen auswählen, indem Sie sie zur `Values`-Liste hinzufügen. Trennen Sie die Elemente durch Kommas.
------
#### [ 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 ^
[...]
```
------
**Variation**: Anpassung Ihrer Ziele mit mehreren `Key`-Kriterien
Sie können die Anzahl der Ziele für Ihren Befehl verfeinern, indem Sie mehrere `Key` Kriterien berücksichtigen. Wenn Sie mehr als ein `Key`-Kriterium einschließen, wird das System verwaltete Knoten anvisieren, die *alle* Kriterien erfüllen. Mit dem folgenden Befehl werden alle verwaltete Knoten anvisiert, die für die Finanzabteilung *und* für die Datenbankserver-Rolle markiert sind.
------
#### [ 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 ^
[...]
```
------
**Variation**: Verwenden mehrerer `Key`- und `Value`-Kriterien
Aufbauend auf dem vorherigen Beispiel können Sie mehrere Abteilungen und mehrere Server-Rollen auswählen, indem zusätzliche Elemente in die `Values` Kriterien einfügen.
------
#### [ 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 ^
[...]
```
------
**Variation**: Anvisieren markierter verwalteter Knoten mithilfe von mehreren `Values`-Kriterien
Wenn Sie verwaltete Knoten für unterschiedliche Umgebungen mit einem `Key` namens `Department` und `Values` von `Sales` und `Finance` markiert haben, könnten Sie einen Befehl an alle Knoten in diesen Umgebungen mit dem `targets`-Parameter mit der folgenden Syntax senden.
------
#### [ 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 ^
[...]
```
------
Sie können maximal fünf Schlüssel und fünf Werte für jeden Schlüssel angeben.
Wenn entweder ein Tag-Schlüssel (der Variablenname) oder eine Tag-Wert Leerzeichen enthält, setzen Sie den Tagschlüssel oder den Wert in Anführungszeichen, wie in den folgenden Beispielen gezeigt.
**Beispiel**: Leerzeichen in `Value`-Tag
------
#### [ 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" ^
[...]
```
------
**Beispiel**: Leerzeichen in `tag`-Schlüssel und `Value`
------
#### [ 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" ^
[...]
```
------
**Beispiel**: Leerzeichen in einem Element in einer Liste von `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" ^
[...]
```
------
## Verwenden von Ratensteuerungen
Sie können das Tempo steuern, mit dem Befehle an verwaltete Knoten in einer Gruppe gesendet werden, indem Sie *Nebenläufigkeits-Kontrollen* und *Fehlerkontrollen* verwenden.
**Topics**
+ [Verwenden von Gleichzeitigkeitssteuerungen](#send-commands-velocity)
+ [Verwenden von Fehlersteuerungen](#send-commands-maxerrors)
### Verwenden von Gleichzeitigkeitssteuerungen
Sie können die Anzahl der verwalteten Knoten steuern, die einen Befehl gleichzeitig ausführen, indem Sie den `max-concurrency`-Parameter verwenden (die **Concurrency** (Nebenläufigkeit)-Optionen auf der Seite **Run a command** (Befehl ausführen). Sie können entweder eine absolute Anzahl an verwalteten Knoten, z. B. **10**, oder einen Prozentsatz des festgelegten Ziels, beispielsweise **10%**, angeben. Das Warteschlangensystem liefert den Befehl an einen einzelnen Knoten und wartet, bis das System den ersten Aufruf bestätigt hat, bevor der Befehl an zwei weitere Knoten gesendet wird. Das System sendet exponentiell Befehle an mehrere Knoten, bis das System den Wert `max-concurrency` erreicht hat. Der Standardwert `max-concurrency` beträgt 50. Die folgenden Beispiele zeigen, wie Sie Werte für den Parameter `max-concurrency` angeben.
------
#### [ 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 ^
[...]
```
------
### Verwenden von Fehlersteuerungen
Sie können auch die Ausführung eines Befehls auf Hunderten oder Tausenden von verwalteten Knoten steuern, indem Sie eine Fehlerbegrenzung mit den `max-errors`-Parametern einstellen (das Feld **Error threshold** (Fehlerschwelle) auf der Seite **Run a command** (Befehl ausführen)). Der Parameter gibt an, wie viele Fehler zulässig sind, bevor das System keinen Befehl mehr an zusätzliche verwaltete Knoten sendet. Sie können entweder eine absolute Anzahl an Fehlern, z. B. **10**, oder einen Prozentsatz des festgelegten Ziels, beispielsweise **10%**, festlegen. Wenn Sie z. B. **3** angeben, sendet das System keinen Befehl mehr, wenn der vierte Fehler empfangen wird. Wenn Sie **0** angeben, sendet das System keinen weiteren Befehl an zusätzliche verwaltete Knoten, nachdem das erste Fehlerergebnis zurückgegeben wird. Wenn Sie einen Befehl an 50 verwaltete Knoten senden und `max-errors` auf **10%** einstellen, sendet das System keinen Befehl mehr an weitere Knoten, wenn der sechste Fehler empfangen wird.
Aufrufe, die bereits einen Befehl ausführen, wenn `max-errors` erreicht ist, dürfen abgeschlossen werden, jedoch können einige dieser Aufrufe ebenso fehlschlagen. Wenn Sie sicherstellen müssen, dass es nicht mehr als `max-errors` fehlgeschlagene Aufrufe geben wird, setzen Sie `max-concurrency` auf **1**, sodass die Aufrufe jeweils um eins fortfahren. Die Standardwert für max-errors ist 0. Die folgenden Beispiele zeigen, wie Sie Werte für den Parameter `max-errors` angeben.
------
#### [ 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 ^
[...]
```
------
# Stornieren eines Befehls
Sie können versuchen, einen Befehl abzubrechen, solange der Service entweder im Ausstehenden oder Ausführenden Status angezeigt wird. Wenn jedoch ein Befehl sich nach wie vor in einem dieser Zustände befindet, können wir nicht garantieren, dass der Befehl beendet wird und der zugrunde liegenden Prozess gestoppt wurde.
**So stornieren Sie einen Befehl mithilfe der Konsole**
1. Öffnen Sie die AWS Systems Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie den Befehlsaufruf, den Sie stornieren möchten.
1. Wählen Sie **Cancel Command**.
**So stornieren Sie einen Befehl mithilfe der AWS CLI**
Führen Sie den folgenden Befehl aus. Ersetzen Sie jeden *Beispiel Platzhalter für Ressourcen* mit Ihren eigenen Informationen.
------
#### [ 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"
```
------
Weitere Informationen über den Status eines stornierten Befehls finden Sie unter [Grundlegendes zu Befehlsstatus](monitor-commands.md).
# Verwendung von Beendigungscodes in Befehlen
In einigen Fällen müssen Sie möglicherweise mithilfe von Beendigungscodes verwalten, wie Ihre Befehle verarbeitet werden.
## Angabe von Beendigungscodes in Befehlen
Mit Run Command, einem Tool in AWS Systems Manager, können Sie Beendigungscodes angeben, um festzulegen, wie Befehle verarbeitet werden. Standardmäßig wird der Beendigungscode des letzten in einem Skript ausgeführten Befehls als Beendigungscode für das gesamte Skript gemeldet. Sie haben beispielsweise ein Skript, das drei Befehle enthält. Der erste schlägt fehl, die folgenden werden jedoch erfolgreich ausgeführt. Da der letzte Befehl erfolgreich war, wird der Status der Ausführung als `succeeded` gemeldet.
**Shell-Skripts**
Damit das gesamte Skript beim ersten Befehlsfehler fehlschlägt, können Sie eine bedingte Shell-Anweisung einschließen, sodass das Skript beendet wird, wenn ein Befehl vor dem letzten Befehl fehlschlägt. Gehen Sie wie folgt vor.
```
if [ $? != 0 ]
then
exit
fi
```
Im folgenden Beispiel schlägt das gesamte Skript fehl, wenn der erste Befehl fehlschlägt.
```
cd /test
if [ $? != 0 ]
then
echo "Failed"
exit 1
fi
date
```
**PowerShell-Skripts**
PowerShell erfordert, dass Sie `exit` explizit in Ihren Skripts aufrufen, damit Run Command den Beendigungscode erfolgreich erfassen kann.
```
if ($?) {}
else {exit }
exit
```
Ein Beispiel:
```
cd C:\
if ($?) {echo "Success"}
else {exit 1}
date
```
# Umgang mit Neustarts beim Ausführen von Befehlen
Wenn Sie ein Tool in verwenden Run Command AWS Systems Manager, um Skripts auszuführen, die verwaltete Knoten neu starten, empfehlen wir, dass Sie in Ihrem Skript einen Exit-Code angeben. Wenn Sie versuchen, einen Knoten von einem Skript aus mit einem anderen Verfahren neu zu starten, wird der Ausführungsstatus des Skripts möglicherweise nicht korrekt aktualisiert. Dies passiert auch dann, wenn der Neustart der letzte Schritt in Ihrem Skript ist. Für Windows-verwaltete Knoten geben Sie `exit 3010` in Ihrem Skript an. Für Linux- und macOS-verwaltete Knoten geben Sie `exit 194` an. Der Exit-Code weist AWS Systems Manager Agent (SSM Agent) an, den verwalteten Knoten neu zu starten und das Skript nach Abschluss des Neustarts neu zu starten. Vor dem Neustart informiert SSM Agent den Systems Manager-Service in der Cloud, dass die Kommunikation während des Serverneustarts unterbrochen werden wird.
**Anmerkung**
Das Neustartskript kann nicht Teil eines `aws:runDocument`-Plugins sein. Wenn ein Dokument das Neustartskript enthält und ein anderes Dokument versucht, dieses Dokument über das `aws:runDocument`-Plugin auszuführen, gibt SSM Agent einen Fehler zurück.
**Idempotente Skripts erstellen**
Bei der Entwicklung von Skripts, die verwaltete Knoten neu starten, machen Sie die Skripts idempotent, damit die Skriptausführung nach dem Neustart an der Stelle fortgesetzt wird, wo sie unterbrochen wurde. Idempotente Skripts verwalten den Status und prüfen, ob die Aktion ausgeführt wurde oder nicht. Dadurch wird verhindert, dass ein Schritt mehrmals ausgeführt wird, wenn er nur einmal ausgeführt werden soll.
Hier finden Sie ein Beispiel für ein idempotentes Skript, das einen verwalteten Knoten mehrfach neu startet.
```
$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
}
```
**Beispiele**
Die folgenden Skript-Beispiele verwenden Beendigungscodes für den Neustart von verwalteten Knoten. Das Linux-Beispiel installiert Paket-Updates auf Amazon Linux und startet den Knoten dann neu. Das Windows Server-Beispiel installiert den Telnet-Client auf dem Knoten und startet ihn dann neu.
------
#### [ 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
}
```
------
# Grundlegendes zu Befehlsstatus
Run Command, ein Tool in AWS Systems Manager, meldet detaillierte Statusinformationen zu den verschiedenen Zuständen, die ein Befehl während der Verarbeitung erlebt, und für jeden verwalteten Knoten, der den Befehl verarbeitet hat. Sie können Befehlsstatus mithilfe der folgenden Methoden überwachen:
+ Wählen Sie das Symbol **Refresh** (Aktualisieren) auf der Registerkarte **Commands** (Befehle) in der Run Command-Konsolenschnittstelle.
+ Rufen Sie [list-commands](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-commands.html) auf oder [list-command-invocations](https://docs.aws.amazon.com/cli/latest/reference/ssm/list-command-invocations.html)verwenden Sie die AWS Command Line Interface ()AWS CLI. Oder rufen Sie [Get- SSMCommand](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommand.html) oder [Get- SSMCommand Invocation](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-SSMCommandInvocation.html) auf mit. AWS Tools for Windows PowerShell
+ Konfigurieren Sie Amazon so EventBridge , dass es auf Status- oder Statusänderungen reagiert.
+ Konfigurieren Sie Amazon Simple Notification Service (Amazon SNS), um Benachrichtigungen für alle Statusänderungen oder bestimmte Status wie `Failed` oder `TimedOut` zu senden.
## Run Command-Status
Run Command berichtet Statusdetails für drei Bereiche: Plugins, Aufrufe und eine allgemeinen Compliance-Befehl. Ein *Plugin* ist ein Code-Ausführungsblock, der im SSM-Dokument des Befehls definiert ist. Weitere Informationen zu den Plugins finden Sie unter [Referenz für Befehlsdokument-Plugins](documents-command-ssm-plugin-reference.md).
Wenn Sie einen Befehl an mehrere verwaltete Knoten gleichzeitig senden, ist jede Kopie des Befehls, die jeden Knoten anvisiert, ein *Befehlsaufruf*. Wenn Sie z. B. das `AWS-RunShellScript`-Dokument verwenden und einen `ifconfig`-Befehl an 20 Linux-Instances senden, hat dieser Befehl 20 Aufrufe. Jeder Befehlsaufruf berichtet einzeln einen Status. Die Plugins für einen bestimmten Befehlsaufruf berichten ebenfalls einzeln einen Berichtstatus.
Schließlich umfasst Run Command einen zusammenfassenden Befehlsstatus für alle Plugins und Aufrufe. Der aggregierte Befehlsstatus kann von dem Status, der von Plugins oder Aufrufen gemeldet wird, wie in den folgenden Tabellen gezeigt, abweichen.
**Anmerkung**
Wenn Sie Befehle mit den Parametern `max-concurrency` oder `max-errors` für eine großen Anzahl von verwalteten Knoten ausführen, spiegelt der Befehlsstatus die durch diese Parameter auferlegten Grenzen wider, wie in den folgenden Tabellen beschrieben. Weitere Informationen zu diesen Parametern finden Sie unter [Ausführen von Befehlen in großem Maßstab](send-commands-multiple.md).
**Detaillierter Status für Befehls-Plugins und Aufrufe**
| Status | Details |
| --- | --- |
| Ausstehend | Der Befehl wurde noch nicht an den verwalteten Knoten gesendet oder wurde nicht vom SSM Agent empfangen. Wird der Befehl nicht vor Ablauf der Zeitspanne, die der Summe aus dem Parameter Timeout (seconds) und dem Parameter Execution timeout entspricht, vom Agenten empfangen, ändert sich der Status in Delivery Timed Out. |
| InProgress | Systems Manager versucht, den Befehl an den verwalteten Knoten zu senden, oder der Befehl wurde vom SSM Agent empfangen und wird auf der Instance ausgeführt. Je nach Ergebnis aller Befehls-Plugins ändert sich der Status in Success, Failed, Delivery Timed Out, oder Execution Timed Out. Ausnahme: Wenn der Agent nicht ausgeführt oder auf dem Knoten nicht verfügbar ist, bleibt der Befehlsstatus bei In Progress, bis der Agent wieder verfügbar ist oder bis das Ausführungs-Timeout-Limit erreicht ist. Der Status wechselt dann in einen Terminal-Status. |
| Verzögert | Das System versuchte, den Befehl an den verwalteten Knoten zu senden, war jedoch nicht erfolgreich. Das System startet einen erneuten Versuch. |
| Herzlichen Glückwunsch | Dieser Status wird unter verschiedenen Bedingungen zurückgegeben. Dieser Status bedeutet nicht, dass der Befehl auf dem Knoten verarbeitet wurde. Der Befehl kann beispielsweise SSM Agent auf dem verwalteten Knoten empfangen werden und den Exit-Code Null zurückgeben, wenn Sie die Ausführung des Befehls PowerShell ExecutionPolicy verhindern. Diese ist ein Terminalstatus. Bedingungen, die dazu führen, dass ein Befehl einen Success Status zurückgibt, sind: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/monitor-commands.html) Dieselben Bedingungen gelten für die Ausrichtung auf Ressourcengruppen. Um Fehler zu beheben oder weitere Informationen über die Befehlsausführung zu erhalten, senden Sie einen Befehl, der Fehler oder Ausnahmen handhabt, indem er entsprechende Beendigungscodes (Ausgangscodes für fehlgeschlagenen Befehl (nicht null)) zurückgibt. |
| DeliveryTimedOut | Der Befehl wurde nicht an den verwalteten Knoten übermittelt, bevor die gesamte Zeitbeschränkung abgelaufen ist. Gesamtausfälle werden nicht auf die übergeordnete Befehlsbegrenzung angerechnet max-errors, aber sie tragen dazu bei, ob der übergeordnete Befehlsstatus Success, Incomplete oder Delivery Timed Out ist. Diese ist ein Terminalstatus. |
| ExecutionTimedOut | Die Befehlsautomatisierung begann auf dem verwalteten Knoten, aber der Befehl wurde vor Ablauf des Ausführungs-Timeouts nicht abgeschlossen. Ausführungs-Timeouts zählen als Fehler, wodurch eine Antwort ungleich Null gesendet wird, und Systems Manager beendet den Versuch, die Befehlsautomatisierung auszuführen, und meldet einen Fehlerstatus. |
| Fehlgeschlagen | Der Befehl war auf dem verwalteten Knoten nicht erfolgreich. Für ein Plugin bedeutet dies, dass der Ergebniscode nicht null war. Für einen Befehlsaufruf bedeutet dies, dass der Ergebniscode für ein oder mehrere Plugins nicht null war. Zeitüberschreitungen beim Aufrufen werden auf das max-errors Limit des übergeordneten Befehls angerechnet. Diese ist ein Terminalstatus. |
| Abgebrochen | Der Befehl wurde beendet, bevor er abgeschlossen wurde. Diese ist ein Terminalstatus. |
| Unzustellbar | Der Befehl kann nicht an den verwalteten Knoten übermittelt werden. Der Knoten existiert möglicherweise nicht oder antwortet nicht. Unzustellbare Aufrufe werden nicht auf die übergeordnete Befehlsbegrenzung angerechnet max-errors, aber sie tragen dazu bei, ob der übergeordnete Befehlsstatus Success oder Incomplete ist. Wenn beispielsweise alle Aufrufe in einem Befehl den Status Undeliverable haben, lautet der zurückgegebene Befehlsstatus Failed. Wenn ein Befehl jedoch fünf Aufrufe hat, von denen vier den Status Undeliverable zurückgeben und einer den Status Success zurückgibt, lautet der Status des übergeordneten Befehls Success. Diese ist ein Terminalstatus. |
| Beendet | Der übergeordnete Befehl hat sein Limit max-errors überschritten, und nachfolgende Befehlsaufrufe wurden vom System abgebrochen. Diese ist ein Terminalstatus. |
| InvalidPlatform | Der Befehl wurde an einen verwalteten Knoten gesendet, der nicht den erforderlichen Plattformen entspricht, wie sie im ausgewählten Dokument festgelegt wurden. Invalid Platform wird nicht auf die maximale Fehlerbegrenzung des übergeordneten Befehls angerechnet, aber es trägt dazu bei, ob der übergeordnete Befehlsstatus Success oder Failed lautet. Wenn beispielsweise alle Aufrufe in einem Befehl den Status Invalid Platform haben, lautet der zurückgegebene Befehlsstatus Failed. Wenn ein Befehl jedoch fünf Aufrufe hat, von denen vier den Status Invalid Platform zurückgeben und einer den Status Success zurückgibt, lautet der Status des übergeordneten Befehls Success. Diese ist ein Terminalstatus. |
| AccessDenied | Der AWS Identity and Access Management (IAM-) Benutzer oder die Rolle, die den Befehl initiiert hat, hat keinen Zugriff auf den verwalteten Zielknoten. Access Deniedwird nicht auf das max-errors Limit des übergeordneten Befehls angerechnet, trägt aber dazu bei, ob der Status des übergeordneten Befehls oder lautetSuccess. Failed Wenn beispielsweise alle Aufrufe in einem Befehl den Status Access Denied haben, lautet der zurückgegebene Befehlsstatus Failed. Wenn ein Befehl jedoch fünf Aufrufe hat, von denen vier den Status Access Denied zurückgeben und einer den Status Success zurückgibt, lautet der Status des übergeordneten Befehls Success. Diese ist ein Terminalstatus. |
**Detaillierter Status für einen Befehl**
| Status | Details |
| --- | --- |
| Ausstehend | Der Befehl wurde noch von keinem Agenten auf einem verwalteten Knoten empfangen. |
| InProgress | Der Befehl wurde an mindestens einen verwalteten Knoten gesendet, hat aber keinen endgültigen Status auf allen Knoten erreicht. |
| Verzögert | Das System versuchte, den Befehl an den Knoten zu senden, war jedoch nicht erfolgreich. Das System startet einen erneuten Versuch. |
| Herzlichen Glückwunsch | Der Befehl wurde vom SSM Agent auf allen angegebenen oder anvisierten verwalteten Knoten empfangen und ein Ausgangscode von null wurde zurückgegeben. Alle Befehlsaufrufe haben einen endgültigen Status erreicht, und der Wert von max-errors wurde nicht erreicht. Dieser Status bedeutet nicht, dass der Befehl auf allen angegebenen oder anvisierten verwalteten Knoten erfolgreich verarbeitet wurde. Diese ist ein Terminalstatus. Um Fehler zu beheben oder weitere Informationen über die Befehlsausführung zu erhalten, senden Sie einen Befehl, der Fehler oder Ausnahmen handhabt, indem er entsprechende Beendigungscodes (Ausgangscodes für fehlgeschlagenen Befehl (nicht null)) zurückgibt. |
| DeliveryTimedOut | Der Befehl wurde nicht an den verwalteten Knoten übermittelt, bevor die gesamte Zeitbeschränkung abgelaufen ist. Der Wert max-errors oder weitere Befehlsaufrufe zeigen den Status Delivery Timed Out. Diese ist ein Terminalstatus. |
| Fehlgeschlagen | Der Befehl war auf dem verwalteten Knoten nicht erfolgreich. Der Wert `max-errors` oder weitere Befehlsaufrufe zeigen den Status `Failed`. Diese ist ein Terminalstatus. |
| Unvollständig | Der Befehl wurde auf allen verwalteten Knoten versucht und einer oder mehrere der Aufrufe haben nicht den Wert Success. Jedoch sind nicht genügend Aufrufe fehlgeschlagen für den Status Failed. Diese ist ein Terminalstatus. |
| Abgebrochen | Der Befehl wurde beendet, bevor er abgeschlossen wurde. Diese ist ein Terminalstatus. |
| RateExceeded | Die Anzahl der verwalteten Knoten, die durch den Befehl anvisiert wurden, überschritt das Kontingent Ihres Kontos für ausstehende Aufrufe. Das System hat den Befehl vor der Ausführung auf einem Knoten abgebrochen. Diese ist ein Terminalstatus. |
| AccessDenied | Der Benutzer oder die Rolle, der oder die den Befehl initiiert, hat keinen Zugriff auf die Zielressourcengruppe. AccessDenied zählt nicht zum max-errors-Limit des übergeordneten Befehls, trägt aber dazu bei, ob der Status des übergeordneten Befehls Success oder Failed ist. (Wenn beispielsweise alle Aufrufe in einem Befehl den Status AccessDenied haben, dann lautet der zurückgegebene Befehlsstatus Failed. Wenn ein Befehl jedoch 5 Aufrufe hat, von denen 4 den Status AccessDenied anzeigen und 1 davon den Status Success anzeigt, dann lautet der Status des übergeordneten Befehls Success.) Diese ist ein Terminalstatus. |
| Keine Instances im Tag | Der Tag-Schlüsselpaar-Wert oder die Ressourcengruppe, auf die der Befehl ausgerichtet ist, stimmt mit keinem verwalteten Knoten überein. Diese ist ein Terminalstatus. |
## Informationen zu Timeout-Werten von Befehlen
Systems Manager erzwingt die folgenden Timeout-Werte bei der Ausführung von Befehlen.
**Gesamt-Timeout**
Geben Sie in der Systems-Manager-Konsole den Zeitbeschränkungs-Wert im Feld **Timeout (seconds)** (Zeitbeschränkung (Sekunden)) ein. Nachdem ein Befehl gesendet wurde, prüft Run Command, ob der Befehl abgelaufen ist oder nicht. Wenn ein Befehl das Ablauflimit des Befehls (Gesamtzeitlimit) erreicht, ändert er den Status in `DeliveryTimedOut` für alle Aufrufe, die den Status `InProgress`, `Pending` oder `Delayed` haben.
![\[Das Feld Timeout (seconds) in der Systems Manager-Konsole\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/run-command-delivery-time-out-time-out-seconds.png)
Technisch gesehen ist die gesamte Zeitbeschränkung (**Timeout (Sekunden)**) eine Kombination aus zwei Timeout-Werten, wie hier gezeigt:
`Total timeout = "Timeout(seconds)" from the console + "timeoutSeconds": "{{ executionTimeout }}" from your SSM document`
Beispielsweise beträgt der Standardwert von **Timeout (seconds) (Timeout (Sekunden))** 600 Sekunden in der Systems Manager-Konsole. Wenn Sie einen Befehl mit dem `AWS-RunShellScript`-SSM-Dokument ausführen, beträgt der Standardwert von **„timeoutSeconds“: „\$1\$1executionTimeout\$1\$1“** 3600 Sekunden, wie im folgenden Dokumentbeispiel gezeigt:
```
"executionTimeout": {
"type": "String",
"default": "3600",
"runtimeConfig": {
"aws:runShellScript": {
"properties": [
{
"timeoutSeconds": "{{ executionTimeout }}"
```
Das bedeutet, dass der Befehl 4 200 Sekunden (70 Minuten) lang ausgeführt wird, bevor das System den Befehlsstatus auf `DeliveryTimedOut` setzt.
**Execution Timeout**
In der Systems Manager-Konsole geben Sie den Wert für die Ausführungszeitüberschreitung im Feld **Execution Timeout** an, sofern verfügbar. Nicht alle SSM-Dokumente erfordern die Angabe eines Ausführungs-Timeout. Das Feld **Execution Timeout** (Ausführungszeitlimit) wird nur angezeigt, wenn ein entsprechender Eingabeparameter im SSM-Dokument definiert wurde. Falls angegeben, muss der Befehl innerhalb dieser Zeitspanne abgeschlossen werden.
**Anmerkung**
Run Command stützt sich auf die SSM Agent-Dokument-Terminalantwort, um zu bestimmen, ob der Befehl an den Agenten übermittelt wurde oder nicht. SSM Agent muss ein `ExecutionTimedOut`-Signal senden, damit ein Aufruf oder Befehl als `ExecutionTimedOut` markiert wird.
![\[Das Feld Execution Timeout (Ausführungs-Timeout) in der Systems Manager-Konsole\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/run-command-execution-timeout-console.png)
**Standard-Ausführungs-Timeout**
Wenn ein SSM-Dokument nicht erfordert, dass Sie explizit einen Ausführungs-Timeout-Wert angeben, erzwingt Systems Manager den fest programmierten Standard-Ausführungs-Timeout.
**Wie Systems Manager Timeouts meldet**
Empfängt Systems Manager eine `execution timeout`-Antwort von SSM Agent auf einem Ziel, dann markiert Systems Manager den Befehlsaufruf als `executionTimeout`.
Erhält Run Command keine Dokumentterminalantwort von SSM Agent, wird der Befehlsaufruf als `deliveryTimeout`gekennzeichnet.
Um den Timeout-Status für ein Ziel zu bestimmen, kombiniert SSM Agent alle Parameter und den Inhalt des SSM-Dokuments, um `executionTimeout` zu berechnen. Wenn SSM Agent feststellt, dass ein Befehl einen Timeout hat, sendet es `executionTimeout` an den Service.
Der Standardwert für **Timeout (seconds) (Timeout (Sekunden))** beträgt 3600 Sekunden. Der Standardwert für **Execution Timeout** beträgt ebenfalls 3600 Sekunden. Daher beträgt die gesamte Standard-Timeout für einen Befehl 7200 Sekunden.
**Anmerkung**
SSM Agent verarbeitet `executionTimeout` unterschiedlich, je nach Art des SSM-Dokuments und der Dokumentversion.
# Walkthroughs für Run Command
Die Anleitungen in diesem Abschnitt zeigen die Ausführung von Befehlen mit Run Command, einem Tool in AWS Systems Manager, über die AWS Command Line Interface (AWS CLI) oder AWS Tools for Windows PowerShell.
**Topics**
+ [Aktualisierung von Software mithilfe von Run Command](run-command-tutorial-update-software.md)
+ [Exemplarische Vorgehensweise: Verwenden Sie das mit AWS CLI Run Command](walkthrough-cli.md)
+ [Exemplarische Vorgehensweise: Verwenden Sie das mit AWS Tools for Windows PowerShell Run Command](walkthrough-powershell.md)
Sie können auch Beispiele für Befehle in den folgenden Referenzen anzeigen.
+ [Systems ManagerAWS CLI-Referenz](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)
# Aktualisierung von Software mithilfe von Run Command
In den folgenden Verfahren wird beschrieben, wie Sie Software auf Ihren verwalteten Knoten aktualisieren.
## Aktualisierung von SSM Agent mithilfe von Run Command
Im folgenden Verfahren wird beschrieben, wie Sie den SSM Agent auf Ihren verwalteten Knoten aktualisieren können. Sie können entweder auf die neueste Version des SSM Agent aktualisieren oder ein Downgrade auf eine ältere Version durchführen. Wenn Sie den Befehl ausführen, lädt das System die Version von herunter AWS, installiert sie und deinstalliert dann die Version, die vor der Ausführung des Befehls vorhanden war. Wenn während dieses Prozesses ein Fehler auftritt, wird das System auf die Version auf dem Server zurückgesetzt, bevor der Befehl ausgeführt wurde, und der Befehlsstatus zeigt, dass der Befehl fehlgeschlagen ist.
**Anmerkung**
Wenn auf einer Instance macOS-Version 13.0 (Ventura) oder höher ausgeführt wird, muss die Instance über die SSM Agent-Version 3.1.941.0 oder höher verfügen, um das AWS-UpdateSSMAgent-Dokument auszuführen. Wenn auf der Instance eine Version von SSM Agent ausgeführt wird, die vor 3.1.941.0 veröffentlicht wurde, können Sie Ihr SSM Agent aktualisieren, um das AWS-UpdateSSMAgent-Dokument auszuführen, indem Sie die `brew update`- und `brew upgrade amazon-ssm-agent`-Befehle ausführen.
Wenn Sie über SSM Agent-Aktualisierungen benachrichtigt werden möchten, abonnieren Sie die Seite [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) auf GitHub.
**So aktualisieren Sie SSM Agent mittels Run Command**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste **Befehlsdokument** die Option **`AWS-UpdateSSMAgent`** aus.
1. Geben Sie im Abschnitt **Command parameters** ggf. Werte für die folgenden Parameter an:
1. (Optional) Geben Sie in **Version (Version)** die zu installierende SSM Agent-Version ein. Sie können [ältere Versionen](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) des Agenten installieren. Wenn Sie keine Version angeben, installiert der Service die neueste Version.
1. (Optional) Wählen Sie in **Allow Downgrade (Downgrade erlauben)** die Option **true (wahr)** aus, um eine frühere SSM Agent-Version zu installieren. Wenn Sie diese Option auswählen, geben Sie die [frühere](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md) Versionsnummer an. Wählen Sie **false**, um nur die neueste Version des Dienstes zu installieren.
1. Identifizieren Sie für den Abschnitt **Targets** (Ziele) die verwalteten Knoten, auf denen Sie diese Operation ausführen möchten, indem Sie Tags angeben, Instances oder Edge-Geräte manuell auswählen oder eine Ressourcengruppe angeben.
**Tipp**
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
1. Für **Weitere Parameter**:
+ Geben Sie im Feld **Kommentar** Informationen zu diesem Befehl ein.
+ Geben Sie für **Timeout (Sekunden)** in Sekunden an, wie lange gewartet werden soll, bis für die gesamte Befehlsausführung ein Fehler auftritt.
1. Für **Ratenregelung**:
+ Geben Sie unter **Nebenläufigkeit** entweder eine Zahl oder einen Prozentsatz der verwalteten Knoten an, auf denen der Befehl gleichzeitig ausgeführt werden soll.
**Anmerkung**
Wenn Sie Ziele ausgewählt haben, indem Sie Tags für verwaltete Knoten oder AWS Ressourcengruppen angegeben haben und Sie sich nicht sicher sind, wie viele verwaltete Knoten das Ziel sind, schränken Sie die Anzahl der Ziele ein, die das Dokument gleichzeitig ausführen können, indem Sie einen Prozentsatz angeben.
+ Geben Sie unter **Fehlerschwellenwert** an, wann die Ausführung des Befehls auf anderen verwalteten Knoten beendet werden soll, nachdem dafür entweder auf einer bestimmten Anzahl oder einem Prozentsatz von Knoten ein Fehler aufgetreten ist. Falls Sie beispielsweise drei Fehler angeben, sendet Systems Manager keinen Befehl mehr, wenn der vierte Fehler empfangen wird. Von verwalteten Knoten, auf denen der Befehl noch verarbeitet wird, werden unter Umständen ebenfalls Fehler gesendet.
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben in einen S3-Bucket aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind diejenigen des Instance-Profils (für EC2-Instances) oder der IAM-Servicerolle (hybrid-aktivierte Maschinen), die der Instance zugewiesen sind, und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
1. Aktivieren Sie das Kontrollkästchen **SNS-Benachrichtigungen aktivieren** im Abschnitt **SNS-Benachrichtigungen**, wenn Sie über den Status der Befehlsausführung benachrichtigt werden möchten,
Weitere Informationen zum Konfigurieren von Amazon-SNS-Benachrichtigungen für Run Command finden Sie unter [Überwachung von Systems Manager-Statusänderungen mit Amazon SNS-Benachrichtigungen](monitoring-sns-notifications.md).
1. Klicken Sie auf **Ausführen**.
## Aktualisierung PowerShell mit Run Command
Im folgenden Verfahren wird beschrieben, wie Sie auf Ihren verwalteten R2-Knoten Windows Server 2012 und 2012 auf Version 5.1 aktualisieren PowerShell . Das in diesem Verfahren bereitgestellte Skript lädt das Update für Windows Management Framework (WMF) Version 5.1 herunter und startet die Installation des Updates. Der Knoten wird während dieses Prozesses neu gestartet, da dies bei der Installation von WMF 5.1 erforderlich ist. Download und Installation des Updates dauern insgesamt etwa fünf Minuten.
**Um zu aktualisieren PowerShell mit Run Command**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Run Command** aus.
1. Wählen Sie **Befehl ausführen** aus.
1. Wählen Sie in der Liste **Command document (Befehlsdokument)** die Option **`AWS-RunPowerShellScript`** aus.
1. Fügen Sie die folgenden Befehle für Ihr Betriebssystem im Abschnitt **Befehle** ein.
------
#### [ 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. Identifizieren Sie für den Abschnitt **Targets** (Ziele) die verwalteten Knoten, auf denen Sie diese Operation ausführen möchten, indem Sie Tags angeben, Instances oder Edge-Geräte manuell auswählen oder eine Ressourcengruppe angeben.
**Tipp**
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
1. Für **Weitere Parameter**:
+ Geben Sie im Feld **Kommentar** Informationen zu diesem Befehl ein.
+ Geben Sie für **Timeout (Sekunden)** in Sekunden an, wie lange gewartet werden soll, bis für die gesamte Befehlsausführung ein Fehler auftritt.
1. Für **Ratenregelung**:
+ Geben Sie unter **Nebenläufigkeit** entweder eine Zahl oder einen Prozentsatz der verwalteten Knoten an, auf denen der Befehl gleichzeitig ausgeführt werden soll.
**Anmerkung**
Wenn Sie Ziele ausgewählt haben, indem Sie Tags für verwaltete Knoten oder AWS Ressourcengruppen angegeben haben und Sie sich nicht sicher sind, wie viele verwaltete Knoten das Ziel sind, schränken Sie die Anzahl der Ziele ein, die das Dokument gleichzeitig ausführen können, indem Sie einen Prozentsatz angeben.
+ Geben Sie unter **Fehlerschwellenwert** an, wann die Ausführung des Befehls auf anderen verwalteten Knoten beendet werden soll, nachdem dafür entweder auf einer bestimmten Anzahl oder einem Prozentsatz von Knoten ein Fehler aufgetreten ist. Falls Sie beispielsweise drei Fehler angeben, sendet Systems Manager keinen Befehl mehr, wenn der vierte Fehler empfangen wird. Von verwalteten Knoten, auf denen der Befehl noch verarbeitet wird, werden unter Umständen ebenfalls Fehler gesendet.
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben in einen S3-Bucket aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind diejenigen des Instance-Profils (für EC2-Instances) oder der IAM-Servicerolle (hybrid-aktivierte Maschinen), die der Instance zugewiesen sind, und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
1. Aktivieren Sie das Kontrollkästchen **SNS-Benachrichtigungen aktivieren** im Abschnitt **SNS-Benachrichtigungen**, wenn Sie über den Status der Befehlsausführung benachrichtigt werden möchten,
Weitere Informationen zum Konfigurieren von Amazon-SNS-Benachrichtigungen für Run Command finden Sie unter [Überwachung von Systems Manager-Statusänderungen mit Amazon SNS-Benachrichtigungen](monitoring-sns-notifications.md).
1. Klicken Sie auf **Ausführen**.
Nachdem der verwaltete Knoten neu gestartet wurde und die Installation des Updates abgeschlossen ist, stellen Sie eine Verbindung zu Ihrem Knoten her, um zu überprüfen, ob das Upgrade auf Version 5.1 PowerShell erfolgreich war. Um die Version von PowerShell auf Ihrem Node zu überprüfen, öffnen Sie die Datei PowerShell und geben Sie die Eingabetaste ein`$PSVersionTable`. Der `PSVersion`-Wert in der Ausgabetabelle zeigt 5.1, wenn das Upgrade erfolgreich war.
Wenn der `PSVersion`-Wert nicht 5.1 ist, zum Beispiel 3.0 oder 4.0, überprüfen Sie die **Setup**-Protokolle im Event Viewer unter **Windows-Protokolle**. Diese Protokolle geben an, warum die Update-Installation fehlgeschlagen ist.
# Exemplarische Vorgehensweise: Verwenden Sie das mit AWS CLI Run Command
In der folgenden exemplarischen Vorgehensweise wird gezeigt, wie Sie mithilfe von AWS Command Line Interface (AWS CLI) Informationen zu Befehlen und Befehlsparametern anzeigen, Befehle ausführen und den Status dieser Befehle anzeigen können.
**Wichtig**
Nur vertrauenswürdige Administratoren sollten die in diesem Thema aufgeführten AWS Systems Manager vorkonfigurierten Dokumente verwenden dürfen. Die in Systems-Manager-Dokumenten festgelegten Befehle oder Skripts werden mit Administratorberechtigungen auf Ihren verwalteten Knoten ausgeführt. Wenn ein Benutzer über die Berechtigung zum Ausführen der vordefinierten Systems-Manager-Dokumente (alle Dokumente, die mit `AWS-` beginnen) verfügt, hat dieser Benutzer auch Administratorzugriff auf den Knoten. Für alle anderen Benutzer sollten Sie restriktive Dokumente erstellen und sie mit bestimmten Benutzern teilen.
**Topics**
+ [Schritt 1: Erste Schritte](#walkthrough-cli-settings)
+ [Schritt 2: Ausführen von Shell-Skripten zum Anzeigen von Ressourcendetails](#walkthrough-cli-run-scripts)
+ [Schritt 3: Senden einfacher Befehle mit dem `AWS-RunShellScript`-Dokument](#walkthrough-cli-example-1)
+ [Schritt 4: Ausführen eines einfachen Python-Skripts mit Run Command](#walkthrough-cli-example-2)
+ [Schritt 5: Führen Sie ein Bash-Skript mit Run Command aus](#walkthrough-cli-example-3)
## Schritt 1: Erste Schritte
Sie müssen entweder über Administratorberechtigungen auf dem verwalteten Knoten verfügen, den Sie konfigurieren möchten, oder Sie müssen über die geeignete Berechtigung in AWS Identity and Access Management (IAM) verfügen. Beachten Sie auch, dass in diesem Beispiel die Region USA Ost (Ohio) (us-east-2) verwendet wird. Run Commandist in den in [Systems Manager AWS-Regionen aufgelisteten Dienstendpunkten](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) in der *Allgemeine Amazon Web Services-Referenz*verfügbar. Weitere Informationen finden Sie unter [Einrichtung verwalteter Knoten für AWS Systems Manager](systems-manager-setting-up-nodes.md).
**Um Befehle mit dem auszuführen AWS CLI**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Listen Sie alle verfügbaren Dokumente auf.
Mit diesem Befehl werden alle verfügbaren Dokumente für Ihr Konto basierend auf IAM-Berechtigungen ausgeführt.
```
aws ssm list-documents
```
1. Überprüfen Sie, ob ein verwalteter Knoten zum Empfangen von Befehlen bereit ist.
Die Ausgabe des folgenden Befehls zeigt, ob verwaltete Knoten online sind.
------
#### [ Linux & macOS ]
```
aws ssm describe-instance-information \
--output text --query "InstanceInformationList[*]"
```
------
#### [ Windows ]
```
aws ssm describe-instance-information ^
--output text --query "InstanceInformationList[*]"
```
------
1. Verwenden Sie den folgenden Befehl, um weitere Details zu einem bestimmten verwalteten Knoten anzuzeigen.
**Anmerkung**
Um die Befehle in dieser exemplarischen Vorgehensweise auszuführen, ersetzen Sie die Instanz und den Befehl IDs. Verwenden Sie für verwaltete AWS IoT Greengrass Core-Geräte die Instanz-ID mi- *ID\$1number* for. Die Befehls-ID wird als Antwort an **send-command** zurückgegeben. Instanzen IDs sind verfügbar unterFleet Manager, einem Tool in 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
```
------
## Schritt 2: Ausführen von Shell-Skripten zum Anzeigen von Ressourcendetails
Mit Run Command und dem `AWS-RunShellScript`-Dokument können Sie Befehle oder Skripts auf einem verwalteten Knoten ausführen, als ob Sie lokal angemeldet wären.
**Die Beschreibung und verfügbare Parameter anzeigen**
Führen Sie den folgenden Befehl aus, um eine Beschreibung des Systems Manager JSON-Dokuments anzuzeigen.
------
#### [ 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]"
```
------
Führen Sie den folgenden Befehl aus, um die verfügbaren Parameter und Details zu diesen Parametern anzuzeigen.
------
#### [ Linux & macOS ]
```
aws ssm describe-document \
--name "AWS-RunShellScript" \
--query "Document.Parameters[*]"
```
------
#### [ Windows ]
```
aws ssm describe-document ^
--name "AWS-RunShellScript" ^
--query "Document.Parameters[*]"
```
------
## Schritt 3: Senden einfacher Befehle mit dem `AWS-RunShellScript`-Dokument
Führen Sie den folgenden Befehl aus, um IP-Informationen für einen Linux-verwalteten Knoten abzurufen.
Wenn Sie einen von Windows Server verwalteten Knoten anvisieren, ändern Sie den `document-name` zu `AWS-RunPowerShellScript` und ändern Sie den `command` von `ifconfig` zu `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
```
------
**Abrufen der Befehlsinformation mit Antwortdaten**
Mit dem folgenden Befehl wird die Befehls-ID verwendet, die vom vorherigen Befehl zurückgegeben wurde, um die Details und Antwortdaten der Ausführung des Befehls abzurufen. Das System gibt die Antwortdaten zurück, wenn der Befehl abgeschlossen ist. Wenn die Befehlsausführung `"Pending"` oder `"InProgress"` anzeigt, führen Sie diesen Befehl erneut aus, um die Antwortdaten zu sehen.
------
#### [ 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
```
------
**Benutzer identifizieren**
Mit dem folgenden Befehl wird der Standard-Benutzer angezeigt, der die Befehle ausführt.
------
#### [ 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")
```
------
**Abrufen des Befehlsstatus**
Mit dem folgenden Befehl wird die Befehls-ID verwendet, um den Status der Befehlsausführung auf dem verwalteten Knoten abzurufen. In diesem Beispiel wird die Befehls-ID verwendet, die im vorherigen Befehl zurückgegeben wurde.
------
#### [ Linux & macOS ]
```
aws ssm list-commands \
--command-id "command-ID"
```
------
#### [ Windows ]
```
aws ssm list-commands ^
--command-id "command-ID"
```
------
**Abrufen der Befehlsdetails**
Mit dem folgenden Befehl wird die Befehls-ID vom vorherigen Befehl verwendet, um den Status der Befehlsausführung pro verwalteten Knoten abzurufen.
------
#### [ Linux & macOS ]
```
aws ssm list-command-invocations \
--command-id "command-ID" \
--details
```
------
#### [ Windows ]
```
aws ssm list-command-invocations ^
--command-id "command-ID" ^
--details
```
------
**Abrufen von Befehlsinformationen mit Antwortdaten für einen bestimmten verwalteten Knoten**
Mit dem folgenden Befehl wird die Ausgabe der ursprünglichen `aws ssm send-command`-Anforderung für einen bestimmten verwalteten Knoten zurückgegeben.
------
#### [ 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
```
------
**Anzeigen der Python-Version**
Mit dem folgenden Befehl wird die Version von Python zurückgegeben, die auf einem Knoten ausgeführt wird.
------
#### [ 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}"'
```
------
## Schritt 4: Ausführen eines einfachen Python-Skripts mit Run Command
Mit dem folgenden Befehl wird ein einfaches Python-Skript „Hello World“ unter Verwendung von Run Command ausgeführt.
------
#### [ 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}"'
```
------
## Schritt 5: Führen Sie ein Bash-Skript mit Run Command aus
Die Beispiele in diesem Abschnitt zeigen, wie Sie das folgende Bash-Skript mit Run Commandausführen.
Für Beispiele für die Verwendung von Run Command, um Skripts auszuführen, die an Remote-Speicherorten gespeichert sind, siehe [Ausführen von Skripts von Amazon S3](integration-s3.md) und [Ausführen von Skripts von 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
```
Dieses Skript installiert den AWS CodeDeploy Agenten auf Amazon Linux- und Red Hat Enterprise Linux (RHEL) -Instances, wie unter [Amazon EC2 EC2-Instance erstellen für CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/instances-ec2-create.html) im *AWS CodeDeploy Benutzerhandbuch* beschrieben.
Das Skript installiert den CodeDeploy Agenten aus einem AWS verwalteten S3-Bucket in der Region USA Ost (Ohio) (us-east-2),. `aws-codedeploy-us-east-2`
**Führen Sie ein Bash-Skript in einem Befehl aus AWS CLI **
Das folgende Beispiel zeigt, wie Sie das Bash-Skript mit der Option `--parameters` in einen CLI-Befehl einbinden.
------
#### [ 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"]}'
```
------
**Führen Sie ein Bash-Skript in einer JSON-Datei aus**
Im folgenden Beispiel wird der Inhalt des Bash-Skripts in einer JSON-Datei gespeichert, und die Datei wird mit der Option `--cli-input-json` in den Befehl aufgenommen.
------
#### [ 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
```
------
Der Inhalt der referenzierten `installCodeDeployAgent.json`-Datei ist im folgenden Beispiel dargestellt.
```
{
"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"
]
}
}
```
# Exemplarische Vorgehensweise: Verwenden Sie das mit AWS Tools for Windows PowerShell Run Command
In den folgenden Beispielen wird gezeigt, wie Sie mithilfe von Informationen AWS Tools for Windows PowerShell zu Befehlen und Befehlsparametern anzeigen, Befehle ausführen und den Status dieser Befehle anzeigen können. Diese Anleitung umfasst ein Beispiel für jedes der vordefinierten AWS Systems Manager -Dokumente.
**Wichtig**
Nur vertrauenswürdige Administratoren sollten Systems Manager-vorkonfigurierte Dokumente in diesem Thema verwenden dürfen. Die in Systems-Manager-Dokumenten festgelegten Befehle oder Skripts werden mit einer Administratorberechtigung auf Ihren verwalteten Knoten ausgeführt. Wenn ein Benutzer berechtigt ist, eines der vordefinierten Systems Manager Manager-Dokumente (jedes Dokument, das mit beginnt AWS) auszuführen, hat dieser Benutzer auch Administratorzugriff auf den Knoten. Für alle anderen Benutzer sollten Sie restriktive Dokumente erstellen und sie mit bestimmten Benutzern teilen.
**Topics**
+ [Konfigurieren Sie die AWS Tools for Windows PowerShell Sitzungseinstellungen](#walkthrough-powershell-settings)
+ [Listen Sie alle verfügbaren Dokumente auf](#walkthrough-powershell-all-documents)
+ [Führen Sie PowerShell Befehle oder Skripts aus](#walkthrough-powershell-run-script)
+ [Installieren einer Anwendung mithilfe des `AWS-InstallApplication`-Dokuments](#walkthrough-powershell-install-application)
+ [Installieren Sie ein PowerShell Modul mithilfe des `AWS-InstallPowerShellModule` JSON-Dokuments](#walkthrough-powershell-install-module)
+ [Verbinden eines verwalteten Knotens mit einer Domain mithilfe des `AWS-JoinDirectoryServiceDomain`-JSON-Dokuments](#walkthrough-powershell-domain-join)
+ [Senden Sie Windows-Metriken mithilfe des `AWS-ConfigureCloudWatch` Dokuments an Amazon CloudWatch Logs](#walkthrough-powershell-windows-metrics)
+ [Aktivieren oder deaktivieren Sie die automatische Windows-Aktualisierung mithilfe des `AWS-ConfigureWindowsUpdate`-Dokuments.](#walkthrough-powershell-enable-windows-update)
+ [Verwalten von Windows-Updates mit Run Command](#walkthough-powershell-windows-updates)
## Konfigurieren Sie die AWS Tools for Windows PowerShell Sitzungseinstellungen
**Angeben Ihrer Anmeldeinformationen**
Öffnen Sie **Tools für Windows PowerShell** auf Ihrem lokalen Computer und führen Sie den folgenden Befehl aus, um Ihre Anmeldeinformationen anzugeben. Sie müssen entweder über Administratorrechte für die verwalteten Knoten verfügen, die Sie konfigurieren möchten, oder Ihnen müssen die entsprechenden Berechtigungen in AWS Identity and Access Management (IAM) erteilt worden sein. Weitere Informationen finden Sie unter [Einrichtung verwalteter Knoten für AWS Systems Manager](systems-manager-setting-up-nodes.md).
```
Set-AWSCredentials –AccessKey key-name –SecretKey key-name
```
**Legen Sie einen Standard fest AWS-Region**
Führen Sie den folgenden Befehl aus, um die Region für Ihre PowerShell Sitzung festzulegen. Das Beispiel verwendet die Region USA Ost (Ohio) (us-east-2). Run Commandist in den in [Systems Manager AWS-Regionen aufgelisteten Dienstendpunkten](https://docs.aws.amazon.com/general/latest/gr/ssm.html#ssm_region) in der *Allgemeine Amazon Web Services-Referenz*verfügbar.
```
Set-DefaultAWSRegion `
-Region us-east-2
```
## Listen Sie alle verfügbaren Dokumente auf
Mit diesem Befehl werden alle verfügbaren Dokumente für Ihrem Konto aufgelistet.
```
Get-SSMDocumentList
```
## Führen Sie PowerShell Befehle oder Skripts aus
Mit Run Command und dem `AWS-RunPowerShell`-Dokument können Sie Befehle oder Skripts auf einem verwalteten Knoten ausführen, als ob Sie lokal angemeldet wären. Sie können Befehle ausgeben oder einen Pfad zu einem lokalen Skript eingeben, um den Befehl auszuführen.
**Anmerkung**
Informationen zum Neustarten von verwalteten Knoten bei Verwendung von Run Command für den Aufruf von Skripts finden Sie unter [Umgang mit Neustarts beim Ausführen von Befehlen](send-commands-reboot.md).
**Die Beschreibung und verfügbare Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript"
```
**Weitere Informationen über Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-RunPowerShellScript" | Select -ExpandProperty Parameters
```
### Senden Sie einen Befehl mithilfe des `AWS-RunPowerShellScript`-Dokuments
Mit dem folgenden Befehl werden der Inhalt des `"C:\Users"`-Verzeichnisses und der Inhalt des `"C:\"`-Verzeichnisses auf zwei verwalteten Knoten angezeigt.
```
$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:\')}
```
**Abrufen der Befehlsabfragedetails**
Mit dem folgenden Befehl wird die `CommandId` verwendet, um den Status der Befehlsausführung auf beiden verwalteten Knoten abzurufen. In diesem Beispiel wird die `CommandId` verwendet, die im vorherigen Befehl zurückgegeben wurde.
```
Get-SSMCommand `
-CommandId $runPSCommand.CommandId
```
Der Status des Befehls in diesem Beispiel kann „Erfolgreich“, „Ausstehend“ oder „Ausstehend“ lauten InProgress.
**Abrufen von Befehlsinformationen pro verwalteter Knoten**
Mit dem folgenden Befehl wird die `CommandId` vom vorherigen Befehl verwendet, um den Status der Befehlsausführung pro verwalteten Knoten abzurufen.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId
```
**Abrufen von Befehlsinformationen mit Antwortdaten für einen bestimmten verwalteten Knoten**
Mit dem folgenden Befehl wird die Ausgabe des ursprünglichen `Send-SSMCommand` für einen bestimmten verwalteten Knoten zurückgegeben.
```
Get-SSMCommandInvocation `
-CommandId $runPSCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### Abbrechen eines Befehls
Mit dem folgenden Befehl wird `Send-SSMCommand` für das `AWS-RunPowerShellScript`-Dokument abgebrochen.
```
$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
```
**Überprüfen des Befehlsstatus**
Mit dem folgenden Befehl wird der Status des `Cancel`-Befehls überprüft
```
Get-SSMCommand `
-CommandId $cancelCommand.CommandId
```
## Installieren einer Anwendung mithilfe des `AWS-InstallApplication`-Dokuments
Mit Run Command und dem `AWS-InstallApplication`-Dokument können Sie Anwendungen auf verwalteten Knoten installieren, reparieren oder deinstallieren. Der Befehl erfordert den Pfad oder die Adresse für ein MSI.
**Anmerkung**
Informationen zum Neustarten von verwalteten Knoten bei Verwendung von Run Command für den Aufruf von Skripts finden Sie unter [Umgang mit Neustarts beim Ausführen von Befehlen](send-commands-reboot.md).
**Die Beschreibung und verfügbare Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication"
```
**Weitere Informationen über Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallApplication" | Select -ExpandProperty Parameters
```
### Senden Sie einen Befehl mithilfe des `AWS-InstallApplication`-Dokuments
Mit dem folgenden Befehl wird eine Version von Python auf Ihrerm verwalteten Knoten im unbeaufsichtigten Modus installiert und die Ausgabe in einer lokalen Textdatei auf dem Laufwerk `C:` protokolliert.
```
$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'}
```
**Abrufen von Befehlsinformationen pro verwalteter Knoten**
Mit dem folgenden Befehl wird die `CommandId` verwendet, um den Status der Befehlsausführung abzurufen.
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true
```
**Abrufen von Befehlsinformationen mit Antwortdaten für einen bestimmten verwalteten Knoten**
Mit dem folgenden Befehl werden die Ergebnisse der Python-Installation zurückgegeben.
```
Get-SSMCommandInvocation `
-CommandId $installAppCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
## Installieren Sie ein PowerShell Modul mithilfe des `AWS-InstallPowerShellModule` JSON-Dokuments
Sie können es verwendenRun Command, um PowerShell Module auf verwalteten Knoten zu installieren. Weitere Informationen zu PowerShell Modulen finden Sie unter [ PowerShell Windows-Module](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_modules?view=powershell-6).
**Die Beschreibung und verfügbare Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule"
```
**Weitere Informationen über Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-InstallPowerShellModule" | Select -ExpandProperty Parameters
```
### Installieren Sie ein PowerShell Modul
Mit dem folgenden Befehl wird die EZOut ZIP-Datei heruntergeladen, installiert und anschließend ein zusätzlicher Befehl zur Installation des XPS-Viewers ausgeführt. Schließlich wird die Ausgabe dieses Befehls auf einen S3-Bucket mit dem Namen „amzn-s3-demo-bucket“ hochgeladen.
```
$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
```
**Abrufen von Befehlsinformationen pro verwalteter Knoten**
Mit dem folgenden Befehl wird die `CommandId` verwendet, um den Status der Befehlsausführung abzurufen.
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true
```
**Abrufen von Befehlsinformationen mit Antwortdaten für den verwalteten Knoten**
Mit dem folgenden Befehl wird die Ausgabe des ursprünglichen `Send-SSMCommand`-Befehls für die spezielle `CommandId` zurückgegeben.
```
Get-SSMCommandInvocation `
-CommandId $installPSCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## Verbinden eines verwalteten Knotens mit einer Domain mithilfe des `AWS-JoinDirectoryServiceDomain`-JSON-Dokuments
Mit Run Command dieser Option können Sie einen verwalteten Knoten schnell einer Domäne hinzufügen. AWS Directory Service [Erstellen Sie ein Verzeichnis](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html) vor dem Ausführen dieses Befehls. Wir empfehlen außerdem, sich mit der Directory Service besser vertraut zu machen. Weitere Informationen finden Sie im [Administrationshandbuch zu AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/).
Sie können nur einen verwalteten Knoten mit einer Domain verbinden. Sie können keinen Knoten aus einer Domain entfernen.
**Anmerkung**
Informationen zu verwalteten Knoten bei Verwendung von Run Command für den Aufruf von Skripts finden Sie unter [Umgang mit Neustarts beim Ausführen von Befehlen](send-commands-reboot.md).
**Die Beschreibung und verfügbare Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain"
```
**Weitere Informationen über Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-JoinDirectoryServiceDomain" | Select -ExpandProperty Parameters
```
### Verbinden eines verwalteten Knotens mit einer Domain
Der folgende Befehl verbindet einen verwalteten Knoten mit der angegebenen Directory Service Domain und lädt alle generierten Ausgaben in den Amazon Simple Storage Service (Amazon S3) -Beispiel-Bucket hoch.
```
$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
```
**Abrufen von Befehlsinformationen pro verwalteter Knoten**
Mit dem folgenden Befehl wird die `CommandId` verwendet, um den Status der Befehlsausführung abzurufen.
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true
```
**Abrufen von Befehlsinformationen mit Antwortdaten für den verwalteten Knoten**
Dieser Befehl gibt die Ausgabe des ursprünglichen `Send-SSMCommand` für die spezifische `CommandId` zurück.
```
Get-SSMCommandInvocation `
-CommandId $domainJoinCommand.CommandId `
-Details $true | Select -ExpandProperty CommandPlugins
```
## Senden Sie Windows-Metriken mithilfe des `AWS-ConfigureCloudWatch` Dokuments an Amazon CloudWatch Logs
Sie können Windows Server Nachrichten in den Anwendungs-, System-, Sicherheits- und Event Tracing for Windows (ETW) -Protokollen an Amazon CloudWatch Logs senden. Wenn Sie die Protokollierung zum ersten Mal aktivieren, sendet Systems Manager alle Protokolle, die innerhalb von 1 Minute generiert werden, sobald Sie mit dem Hochladen von Protokollen für die Anwendungs-, System-, Sicherheits- und ETW-Protokolle beginnen. Protokolle, die davor auftraten, werden nicht berücksichtigt. Wenn Sie die Protokollierung deaktivieren und später wieder aktivieren, sendet Systems Manager Protokolle ab dem Zeitpunkt, an dem die Unterbrechung stattfand. Für alle benutzerdefinierten Protokolldateien und IIS- (Internet Information Services)-Protokolle liest Systems Manager die Protokolldateien von Anfang an. Darüber hinaus kann Systems Manager auch Leistungsindikatordaten an CloudWatch Logs senden.
Wenn Sie zuvor die CloudWatch Integration in EC2 Config aktiviert haben, überschreiben die Systems Manager Manager-Einstellungen alle Einstellungen, die lokal auf dem verwalteten Knoten in der `C:\Program Files\Amazon\EC2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json` Datei gespeichert sind. Weitere Informationen zur Verwendung von EC2 Config zur Verwaltung von Leistungsindikatoren und Protokollen auf einem einzelnen verwalteten Knoten finden Sie unter [Sammeln von Metriken und Protokollen von Amazon EC2 EC2-Instances und lokalen Servern mit dem CloudWatch Agenten im * CloudWatch Amazon-Benutzerhandbuch*](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html).
**Die Beschreibung und verfügbare Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch"
```
**Weitere Informationen über Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureCloudWatch" | Select -ExpandProperty Parameters
```
### Senden Sie Anwendungsprotokolle an CloudWatch
Mit dem folgenden Befehl wird der verwaltete Knoten konfiguriert und die Windows-Anwendungsprotokolle dorthin CloudWatch verschoben.
```
$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"]}}}'}
```
**Abrufen von Befehlsinformationen pro verwalteter Knoten**
Mit dem folgenden Befehl wird die `CommandId` verwendet, um den Status der Befehlsausführung abzurufen.
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true
```
**Abrufen von Befehlsinformationen mit Antwortdaten für einen bestimmten verwalteten Knoten**
Der folgende Befehl gibt die Ergebnisse der CloudWatch Amazon-Konfiguration zurück.
```
Get-SSMCommandInvocation `
-CommandId $cloudWatchCommand.CommandId `
-Details $true `
-InstanceId instance-ID | Select -ExpandProperty CommandPlugins
```
### Senden Sie Leistungsindikatoren an die CloudWatch Verwendung des Dokuments `AWS-ConfigureCloudWatch`
Mit dem folgenden Demonstrationsbefehl werden Leistungsindikatoren in hochgeladen. CloudWatch Weitere Informationen finden Sie im *[ CloudWatch Amazon-Benutzerhandbuch](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"]}}}'}
```
## Aktivieren oder deaktivieren Sie die automatische Windows-Aktualisierung mithilfe des `AWS-ConfigureWindowsUpdate`-Dokuments.
Mit Run Command und dem `AWS-ConfigureWindowsUpdate`-Dokument können Sie automatische Windows-Updates auf Ihren von Windows Server verwalteten Knoten aktivieren oder deaktivieren. Mit diesem Befehl wird der Windows Update-Agent konfiguriert, um Windows-Updates an dem Tag und in der Stunde, die Sie angeben, herunterzuladen und zu installieren. Wenn ein Update einen Neustart erfordert, startet der verwaltete Knoten automatisch 15 Minuten nach der Installation der Updates neu. Mit diesem Befehl können Sie konfigurieren, dass Windows Update auf Updates prüft, diese aber nicht installiert. Das Dokument `AWS-ConfigureWindowsUpdate` wird in Windows Server 2012 und späteren Versionen offiziell unterstützt.
**Die Beschreibung und verfügbare Parameter anzeigen**
```
Get-SSMDocumentDescription `
–Name "AWS-ConfigureWindowsUpdate"
```
**Weitere Informationen über Parameter anzeigen**
```
Get-SSMDocumentDescription `
-Name "AWS-ConfigureWindowsUpdate" | Select -ExpandProperty Parameters
```
### Aktivieren des automatischen Windows Updates
Mit dem folgenden Befehl wird Windows Update konfiguriert, um Updates automatisch täglich um 22.00 Uhr herunterzuladen und zu installieren.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='InstallUpdatesAutomatically'; 'scheduledInstallDay'='Daily'; 'scheduledInstallTime'='22:00'}
```
**Anzeigen des Befehlsstatus zum Aktivieren von automatischen Windows Updates**
Mit dem folgenden Befehl wird die `CommandId` verwendet, um den Status der Befehlsausführung für die Aktivierung von Windows Automatic Updates abzurufen.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
### Deaktivieren des automatischen Windows Updates
Mit dem folgenden Befehl wird die Windows-Update-Benachrichtigungsebene herabgesetzt, damit das System prüft, ob Updates vorliegen, diese jedoch nicht automatisch auf dem verwalteten Knoten installiert.
```
$configureWindowsUpdateCommand = Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-ConfigureWindowsUpdate" `
-Parameters @{'updateLevel'='NeverCheckForUpdates'}
```
**Anzeigen des Befehlsstatus zum Deaktivieren von automatischen Windows Updates**
Mit dem folgenden Befehl wird die `CommandId` verwendet, um den Status der Befehlsausführung für die Aktivierung von Windows Automatic Updates abzurufen.
```
Get-SSMCommandInvocation `
-Details $true `
-CommandId $configureWindowsUpdateCommand.CommandId | Select -ExpandProperty CommandPlugins
```
## Verwalten von Windows-Updates mit Run Command
Mit Run Command und dem `AWS-InstallWindowsUpdates`-Dokument können Sie Updates für von Windows Server verwaltete Knoten verwalten. Dieser Befehl scannt nach oder installiert fehlende Updates auf Ihren verwalteten Knoten und führt nach der Installation optional einen Neustart durch. Sie können auch die entsprechenden Klassifizierungen und Schweregrade für Aktualisierungen angeben, die in Ihrer Umgebung installiert werden sollen.
**Anmerkung**
Informationen zum Neustarten von verwalteten Knoten bei Verwendung von Run Command für den Aufruf von Skripts finden Sie unter [Umgang mit Neustarts beim Ausführen von Befehlen](send-commands-reboot.md).
Die folgenden Beispiele zeigen, wie Sie die angegebenen Windows Update-Verwaltungsaufgaben durchführen.
### Suche nach allen fehlenden Windows-Updates
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Scan'}
```
### Installieren von bestimmten Windows-Updates
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'IncludeKbs'='kb-ID-1,kb-ID-2,kb-ID-3';'AllowReboot'='True'}
```
### Installieren wichtiger fehlender Windows-Updates
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'SeverityLevels'='Important';'AllowReboot'='True'}
```
### Installieren fehlender Windows-Updates mit bestimmten Ausschlüssen
```
Send-SSMCommand `
-InstanceId instance-ID `
-DocumentName "AWS-InstallWindowsUpdates" `
-Parameters @{'Action'='Install';'ExcludeKbs'='kb-ID-1,kb-ID-2';'AllowReboot'='True'}
```
# Fehlerbehebung von Systems Manager Run Command
Run Command, ein Tool in AWS Systems Manager, bietet Statusdetails zu jeder Befehlsausführung. Weitere Informationen zu den Befehlsstatus-Details finden Sie unter [Grundlegendes zu Befehlsstatus](monitor-commands.md). Sie können auch die Informationen in diesem Thema verwenden, um Probleme mit Run Command zu beheben.
**Topics**
+ [Einige meiner verwalteten Knoten fehlen](#where-are-instances)
+ [Ein Schritt in meinem Skript ist fehlgeschlagen, der Gesamtstatus wird jedoch als "Succeeded" (Erfolgreich) angezeigt.](#ts-exit-codes)
+ [SSM Agent wird nicht ordnungsgemäß ausgeführt.](#ts-ssmagent-linux)
## Einige meiner verwalteten Knoten fehlen
Auf der Seite **Run a command** (Einen Befehl ausführen) können Sie, nachdem Sie ein auszuführendes SSM-Dokument ausgewählt und im Abschnitt **Targets** (Ziele) die **manuelle Auswahl von Instances** gewählt haben, wird eine Liste von verwalteten Knoten angezeigt, die Sie für die Ausführung des Befehls auswählen können.
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
Nachdem Sie einen verwalteten Knoten erstellt, aktiviert, neu gestartet oder neu gestartet, Run Command auf einem Knoten installiert oder ein AWS Identity and Access Management (IAM-) Instanzprofil an einen Knoten angehängt haben, kann es einige Minuten dauern, bis der verwaltete Knoten der Liste hinzugefügt wird.
## Ein Schritt in meinem Skript ist fehlgeschlagen, der Gesamtstatus wird jedoch als "Succeeded" (Erfolgreich) angezeigt.
Mit Run Command können Sie festlegen, wie Ihre Skripte mit Exit-Codes umgehen. Standardmäßig wird der Beendigungscode des letzten in einem Skript ausgeführten Befehls als Beendigungscode für das gesamte Skript gemeldet. Sie können jedoch eine bedingte Anweisung einschließen, damit das Skript beendet wird, wenn ein Befehl vor dem letzten Befehl fehlschlägt. Weitere Informationen und Beispiele finden Sie unter [Angabe von Beendigungscodes in Befehlen](run-command-handle-exit-status.md#command-exit-codes).
## SSM Agent wird nicht ordnungsgemäß ausgeführt.
Bei Problemen beim Ausführen von Befehlen mittels Run Command liegt möglicherweise ein Problem mit SSM Agent vor. Informationen zum Untersuchen von Problemen mit SSM Agent finden Sie unter [Fehlerbehebung für SSM Agent](troubleshooting-ssm-agent.md).
# AWS Systems Manager Session Manager
Session Managerist ein vollständig verwaltetes AWS Systems Manager Tool. Mit Session Manager können Sie Ihre Amazon Elastic Compute Cloud (Amazon EC2) -Instances, Edge-Geräte, lokalen Server und virtuellen Maschinen (VMs) verwalten. Sie können entweder eine interaktive browserbasierte Shell mit einem Klick oder die () verwenden. AWS Command Line Interface AWS CLISession Managerbietet sicheres Knotenmanagement, ohne dass eingehende Ports geöffnet, Bastion-Hosts verwaltet oder SSH-Schlüssel verwaltet werden müssen. Session Managerermöglicht Ihnen außerdem die Einhaltung von Unternehmensrichtlinien, die einen kontrollierten Zugriff auf verwaltete Knoten, strenge Sicherheitspraktiken und Protokolle mit Knotenzugriffsdetails vorschreiben, und bietet Endbenutzern gleichzeitig einen einfachen plattformübergreifenden Zugriff mit nur einem Klick auf Ihre verwalteten Knoten. Um mit Session Manager zu beginnen, öffnen Sie die [Systems-Manager-Konsole](https://console.aws.amazon.com/systems-manager/session-manager). Wählen Sie im Navigationsbereich **Session Manager** aus.
## Welche Vorteile bietet Session Manager meiner Organisation?
Session Manager bietet die folgenden Vorteile:
+ **Zentralisierte Kontrolle des Zugriffs auf verwaltete Knoten mit IAM-Richtlinien**
Administratoren erhalten eine zentrale Stelle zum Erteilen und Widerrufen des Zugriffs auf verwaltete Knoten. Wenn Sie ausschließlich AWS Identity and Access Management (IAM-) Richtlinien verwenden, können Sie steuern, welche einzelnen Benutzer oder Gruppen in Ihrem Unternehmen Zugriff darauf haben Session Manager und auf welche verwalteten Knoten sie zugreifen können.
+ **Keine offenen Ports für eingehenden Datenverkehr und keine Notwendigkeit für die Verwaltung von Bastion-Hosts oder SSH-Ports**
Wenn Sie SSH-Ports für eingehenden Datenverkehr und PowerShell-Remote Ports auf Ihren verwalteten Knoten geöffnet lassen, besteht ein höheres Risiko, dass juristische Stellen nicht autorisierte oder böswillige Befehle auf den verwalteten Knoten ausführen. Session Manager unterstützt Sie bei der Verbesserung des Sicherheitsstatus, da Sie diese Ports für eingehenden Datenverkehr schließen können. Dies befreit Sie von der Notwendigkeit, SSH-Schlüssel und -Zertifikate, Bastion-Hosts und Jumpboxes verwalten zu müssen.
+ **One-Click-Zugriff auf verwaltete Knoten über die Konsole und die CLI**
Mit der AWS Systems Manager Konsole oder der Amazon EC2 EC2-Konsole können Sie eine Sitzung mit einem einzigen Klick starten. Mit dem AWS CLI können Sie auch eine Sitzung starten, die einen einzelnen Befehl oder eine Befehlsfolge ausführt. Da Berechtigungen für verwaltete Knoten durch IAM-Richtlinien und nicht von SSH-Schlüsseln oder anderen Mechanismen bereitgestellt werden, wird die Verbindungszeit stark reduziert.
+ **Herstellen einer Verbindung mit Amazon-EC2-Instances und Nicht-EC2-verwalteten Knoten in [Hybrid- und Multi-Cloud](operating-systems-and-machine-types.md#supported-machine-types)-Umgebungen**
Sie können sich sowohl mit Instances der Amazon Elastic Compute Cloud (Amazon EC2) als auch mit Nicht-EC2-Knoten in Ihrer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) verbinden.
Um über Session Manager eine Verbindung zu Nicht-EC2-Knoten herzustellen, müssen Sie zunächst die Advanced-Instances-Kontingente aktivieren. **Die Nutzung des Advanced-Instances-Kontingents ist kostenpflichtig.** Für die Verbindung mit EC2-Instances über Session Manager fallen jedoch keine zusätzlichen Gebühren an. Weitere Informationen finden Sie unter [Konfigurieren von Instance-Kontingenten](fleet-manager-configure-instance-tiers.md).
+ **Port-Weiterleitung**
Leiten Sie jeden Port in Ihrem verwalteten Knoten an einen lokalen Port auf einem Client um. Stellen Sie danach eine Verbindung mit dem lokalen Port her und greifen Sie auf die Serveranwendung zu, die in dem Knoten ausgeführt wird.
+ **Plattformübergreifende Unterstützung für Windows, Linux und macOS**
Session Manager unterstützt in einem einzigen Tool sowohl Windows, Linux als auch macOS. Sie müssen beispielsweise keinen SSH-Client für Linux- und macOS-verwaltete Knoten oder eine RDP-Verbindung für Windows Server-verwaltete Knoten verwenden.
+ **Protokollieren von Sitzungsaktivitäten**
Um betriebs- oder sicherheitsbezogene Anforderungen in Ihrer Organisation zu erfüllen, müssen Sie möglicherweise eine Aufzeichnung der Verbindungen bereitstellen, die mit Ihren verwalteten Knoten hergestellt wurden, und der Befehle, die auf ihnen ausgeführt wurden. Sie können auch Benachrichtigungen empfangen, wenn ein Benutzer in Ihrer Organisation Sitzungsaktivitäten startet oder beendet.
Die Funktionen für Protokollierung werden durch die Integration mit den folgenden AWS-Services bereitgestellt:
+ **AWS CloudTrail**— AWS CloudTrail erfasst Informationen über Session Manager API-Aufrufe in Ihrem AWS-Konto und schreibt sie in Protokolldateien, die in einem von Ihnen angegebenen Amazon Simple Storage Service (Amazon S3) -Bucket gespeichert werden. Ein Bucket wird für alle CloudTrail Protokolle Ihres Kontos verwendet. Weitere Informationen finden Sie unter [AWS Systems Manager API-Aufrufe protokollieren mit AWS CloudTrail](monitoring-cloudtrail-logs.md).
+ **Amazon Simple Storage Service** – Sie können Sitzungsprotokolldaten zu Debugging-Zwecken in einem Amazon S3-Bucket Ihrer Wahl speichern. Protokolldaten können mit oder ohne Verschlüsselung über Ihren AWS KMS key an Ihren Amazon S3-Bucket gesendet werden. Weitere Informationen finden Sie unter [Protokollieren von Sitzungsdaten mithilfe von Amazon S3 (Konsole)](session-manager-logging-s3.md).
+ **Amazon CloudWatch Logs** — CloudWatch Logs ermöglicht es Ihnen, Protokolldateien aus verschiedenen Quellen zu überwachen, zu speichern und darauf zuzugreifen AWS-Services. Sie können Sitzungsprotokolldaten zu Debugging- und Fehlerbehebungszwecken an eine CloudWatch Logs-Protokollgruppe senden. Protokolldaten können mit oder ohne AWS KMS Verschlüsselung mit Ihrem KMS-Schlüssel an Ihre Protokollgruppe gesendet werden. Weitere Informationen finden Sie unter [Protokollierung von Sitzungsdaten mit Amazon CloudWatch Logs (Konsole)](session-manager-logging-cloudwatch-logs.md).
+ **Amazon EventBridge** und **Amazon Simple Notification Service** — EventBridge ermöglicht es Ihnen, Regeln einzurichten, um zu erkennen, wann Änderungen an den von Ihnen angegebenen AWS Ressourcen vorgenommen werden. Sie können eine Regel erstellen, um zu erkennen, wenn ein Benutzer in Ihrer Organisation eine Sitzung startet oder anhält. Anschließend können Sie über Amazon SNS eine Benachrichtigung (z. B. eine Text- oder E-Mail-Nachricht) über das Ereignis erhalten. Sie können ein CloudWatch Ereignis auch so konfigurieren, dass es andere Antworten auslöst. Weitere Informationen finden Sie unter [Überwachung der Sitzungsaktivität mit Amazon EventBridge (Konsole)](session-manager-auditing.md#session-manager-auditing-eventbridge-events).
**Anmerkung**
Protokollieren ist für Session Manager-Sitzungen, die eine Verbindung über Port-Weiterleitung oder SSH herstellen, nicht verfügbar. Dies liegt daran, dass SSH alle Sitzungsdaten innerhalb der sicheren TLS-Verbindung zwischen den Endpunkten AWS CLI und den Session Manager Endpunkten verschlüsselt und Session Manager nur als Tunnel für SSH-Verbindungen dient.
## An wen richtet sich Session Manager?
+ Jeder AWS Kunde, der seine Sicherheitslage verbessern, den betrieblichen Aufwand durch die Zentralisierung der Zugriffskontrolle auf verwalteten Knoten reduzieren und den eingehenden Knotenzugriff reduzieren möchte.
+ Datensicherheitsexperten, die den Zugriff auf und die Aktivität von verwalteten Knoten überwachen und verfolgen möchten, Ports für eingehenden Datenverkehr auf verwalteten Knoten schließen möchten oder Verbindungen mit verwalteten Knoten ohne öffentliche IP-Adresse ermöglichen möchten.
+ Administratoren, die den Zugriff über eine zentrale Stelle gewähren und widerrufen möchten und Benutzern eine einzige Lösung für von Linux, macOS und Windows Server verwaltete Knoten bereitstellen möchten.
+ Benutzer, die mit nur einem Klick im Browser oder AWS CLI ohne Angabe von SSH-Schlüsseln eine Verbindung zu einem verwalteten Knoten herstellen möchten.
## Was sind die Hauptfeatures von Session Manager?
+ **Support für von Windows Server-, Linux- und macOS- verwaltete Knoten**
Session Managerermöglicht es Ihnen, sichere Verbindungen zu Ihren Amazon Elastic Compute Cloud (EC2) -Instances, Edge-Geräten, lokalen Servern und virtuellen Maschinen (VMs) herzustellen. Eine Liste der unter den jeweiligen Betriebssystemen unterstützten Typen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
**Anmerkung**
Session Manager-Support für On-Premises-Server wird nur für das Advanced-Instances-Kontingent bereitgestellt. Weitere Informationen finden Sie unter [Aktivieren des Kontingents für erweiterte Instances](fleet-manager-enable-advanced-instances-tier.md).
+ **Zugriff auf Session Manager-Funktionen über Konsole, CLI und SDK**
Sie können Session Manager wie folgt nutzen:
Die **AWS Systems Manager -Konsole** bietet sowohl Administratoren als auch Endbenutzern Zugriff auf alle Session Manager-Funktionen. Sie können über die Systems Manager-Konsole jede Aufgabe im Zusammenhang mit Ihren Sitzungen ausführen.
Die Amazon-EC2-Konsole bietet Endbenutzern die Möglichkeit, eine Verbindung zu den EC2-Instances herzustellen, für die sie Sitzungsberechtigungen erhalten haben.
Die **AWS CLI** beinhaltet den Zugriff auf Session Manager-Funktionen für Endbenutzer. Sie können eine Sitzung starten, eine Liste von Sitzungen anzeigen und eine Sitzung dauerhaft beenden, indem Sie die verwenden. AWS CLI
**Anmerkung**
Um die Befehle AWS CLI to run session verwenden zu können, müssen Sie Version 1.16.12 der CLI (oder höher) verwenden und das Session Manager Plugin auf Ihrem lokalen Computer installiert haben. Weitere Informationen finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md). Informationen zum Anzeigen des Plug-ins finden Sie GitHub unter. [session-manager-plugin](https://github.com/aws/session-manager-plugin)
+ **IAM-Zugriffskontrolle**
Mithilfe von IAM-Richtlinien können Sie steuern, welche Mitglieder Ihrer Organisation Sitzungen mit verwalteten Knoten starten können und auf welche Knoten sie zugreifen können. Sie können auch einen temporären Zugriff auf Ihre verwalteten Knoten bereitstellen. Beispielsweise könnten Sie einem Techniker auf Aufruf (oder einer Gruppe von Technikern auf Abruf) nur für die Dauer ihrer Schicht Zugriff auf Produktionsserver geben.
+ **Unterstützung für Protokollierung**
Session Manager stellt Ihnen für die Protokollierung von Sitzungsverläufen in Ihrem AWS-Konto durch die Integration mit einer Reihe anderer AWS-Services verschiedene Optionen bereit. Weitere Informationen erhalten Sie unter [Protokollieren von Sitzungsaktivitäten](session-manager-auditing.md) und [Protokollierung von Sitzungen aktivieren und deaktivieren](session-manager-logging.md).
+ **Konfigurierbare Shell-Profile**
Session Manager bietet Ihnen Optionen zum Konfigurieren von Voreinstellungen innerhalb von Sitzungen. Mit diesen anpassbaren Profilen können Sie Voreinstellungen wie Shell-Einstellungen, Umgebungsvariablen, Arbeitsverzeichnisse und das Ausführen mehrerer Befehle definieren, wenn eine Sitzung gestartet wird.
+ **Support für die Datenverschlüsselung mit dem Kundenschlüssel**
Sie können so konfigurierenSession Manager, dass die Sitzungsdatenprotokolle, die Sie an einen Amazon Simple Storage Service (Amazon S3) -Bucket senden oder in eine CloudWatch Logs-Protokollgruppe streamen, verschlüsselt werden. Sie können Session Manager auch so konfigurieren, dass die Daten, die zwischen Client-Maschinen und Ihren verwalteten Knoten während der Sitzungen übertragen werden, weiter verschlüsselt werden. Weitere Informationen finden Sie unter [Protokollierung von Sitzungen aktivieren und deaktivieren](session-manager-logging.md) und [Konfigurieren von Sitzungspräferenzen](session-manager-getting-started-configure-preferences.md).
+ **AWS PrivateLink Unterstützung für verwaltete Knoten ohne öffentliche IP-Adressen**
Sie können auch VPC-Endpunkte für Systems Manager einrichten, um Ihre Sitzungen weiter AWS PrivateLink zu sichern. AWS PrivateLink begrenzt den gesamten Netzwerkverkehr zwischen Ihren verwalteten Knoten, Systems Manager und Amazon EC2 auf das Amazon-Netzwerk. Weitere Informationen finden Sie unter [Verbessern der Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten für](setup-create-vpc.md) Systems Manager.
+ **Tunneling**
Verwenden Sie in einer Sitzung ein Dokument vom Typ Sitzung AWS Systems Manager (SSM), um den Datenverkehr, z. B. http oder ein benutzerdefiniertes Protokoll, zwischen einem lokalen Port auf einem Client-Computer und einem Remote-Port auf einem verwalteten Knoten zu tunneln.
+ **Interaktive Befehle**
Erstellen Sie ein SSM-Dokument vom Typ Session, das eine Sitzung verwendet, um interaktiv einen einzelnen Befehl auszuführen, sodass Sie verwalten können, was Benutzer auf einem verwalteten Knoten tun können.
## Was ist eine Sitzung?
Eine Sitzung ist eine Verbindung zu einem verwalteten Knoten mit Session Manager. Sitzungen basieren auf einem sicheren bidirektionalen Kommunikationskanal zwischen dem Client (Sie) und dem remote verwalteten Knoten, der Eingaben und Ausgaben für Befehle streamt. Der Datenverkehr zwischen einem Client und einem verwalteten Knoten wird mit TLS 1.2 verschlüsselt. Anforderungen zum Aufbau der Verbindung werden mit Sigv4 signiert. Diese bidirektionale Kommunikation ermöglicht interaktive Bash und PowerShell den Zugriff auf verwaltete Knoten. Sie können auch einen AWS Key Management Service (AWS KMS) -Schlüssel verwenden, um Daten über die standardmäßige TLS-Verschlüsselung hinaus weiter zu verschlüsseln.
Angenommen, John ist ein Techniker auf Abruf in Ihrer IT-Abteilung. Er erhält eine Benachrichtigung zu einem Problem, für dessen Bearbeitung er eine Remote-Verbindung mit einem verwalteten Knoten herstellen muss, beispielsweise einem Ausfall, der behoben werden muss, oder eine Anweisung, eine einfache Konfigurationsoption für einen Knoten zu ändern. Mithilfe der AWS Systems Manager Konsole, der Amazon EC2 EC2-Konsole oder der startet John eine Sitzung AWS CLI, die ihn mit dem verwalteten Knoten verbindet, führt Befehle auf dem Knoten aus, die für die Ausführung der Aufgabe erforderlich sind, und beendet dann die Sitzung.
Wenn John den Befehl zum Starten der Sitzung sendet, authentifiziert der Session Manager-Service seine ID, überprüft die ihm von einer IAM-Richtlinie gewährten Berechtigungen, prüft Konfigurationseinstellungen (z. B. die zulässigen Limits für die Sitzungen) und sendet eine Nachricht an, SSM Agent, um die Zwei-Wege-Verbindung zu öffnen. Nach der Herstellung der Verbindung und der Eingabe des nächsten Befehls durch John wird die Befehlsausgabe aus SSM Agent zu diesem Kommunikationskanal hochgeladen und zurück an Johns lokalen Computer gesendet.
**Topics**
+ [Welche Vorteile bietet Session Manager meiner Organisation?](#session-manager-benefits)
+ [An wen richtet sich Session Manager?](#session-manager-who)
+ [Was sind die Hauptfeatures von Session Manager?](#session-manager-features)
+ [Was ist eine Sitzung?](#what-is-a-session)
+ [Einrichten von Session Manager](session-manager-getting-started.md)
+ [Arbeiten mit Session Manager](session-manager-working-with.md)
+ [Protokollieren von Sitzungsaktivitäten](session-manager-auditing.md)
+ [Protokollierung von Sitzungen aktivieren und deaktivieren](session-manager-logging.md)
+ [Schema des Sitzungsdokuments](session-manager-schema.md)
+ [Fehlerbehebung für Session Manager](session-manager-troubleshooting.md)
# Einrichten von Session Manager
Führen Sie die Schritte in den folgenden Themen aus, bevor Sie AWS Systems Manager Session Manager für die Verbindung mit den verwalteten Knoten in Ihrem Konto verwenden.
**Topics**
+ [Schritt 1: Erfüllen der Session Manager-Voraussetzungen](session-manager-prerequisites.md)
+ [Schritt 2: Überprüfen oder Hinzufügen von Instance-Berechtigungen für Session Manager](session-manager-getting-started-instance-profile.md)
+ [Schritt 3: Steuern des Sitzungs-Zugriffs auf verwaltete Knoten](session-manager-getting-started-restrict-access.md)
+ [Schritt 4: Konfigurieren von Sitzungspräferenzen](session-manager-getting-started-configure-preferences.md)
+ [Schritt 5: (Optional) Beschränken des Zugriffs auf Befehle in einer Sitzung](session-manager-restrict-command-access.md)
+ [Schritt 6: (Optional) Verwenden Sie diese Option AWS PrivateLink , um einen VPC-Endpunkt einzurichten für Session Manager](session-manager-getting-started-privatelink.md)
+ [Schritt 7: (Optional) Deaktivieren oder Aktivieren der Administratorberechtigungen für das SSM-Benutzerkonto](session-manager-getting-started-ssm-user-permissions.md)
+ [Schritt 8: (Optional) Berechtigungen für SSH-Verbindungen über Session Manager zulassen und steuern](session-manager-getting-started-enable-ssh-connections.md)
# Schritt 1: Erfüllen der Session Manager-Voraussetzungen
Stellen Sie vor der Verwendung von Session Manager sicher, dass Ihre Umgebung den folgenden Anforderungen entspricht.
**Session Manager-Voraussetzungen**
| Anforderung | Description |
| --- | --- |
| Unterstützte Betriebssysteme | Session Manager unterstützt die Verbindung zu Amazon Elastic Compute Cloud (Amazon EC2)-Instances und Nicht-EC2-Maschinen in Ihrer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types), die das *Advanced-Instances-Kontingent* verwenden. Session Manager unterstützt die folgenden Betriebssystemversionen: Session Manager*unterstützt EC2-Instances, Edge-Geräte sowie lokale Server und virtuelle Maschinen (VMs) in Ihrer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types), die die Advanced-Instance-Stufe verwenden.* Weitere Informationen über erweiterte Instances finden Sie unter [Konfigurieren von Instance-Kontingenten](fleet-manager-configure-instance-tiers.md). **Linux und **macOS**** Session Managerunterstützt alle Versionen von Linux undmacOS, die von unterstützt werden. AWS Systems Manager Weitere Informationen finden Sie unter [Unterstützte Betriebssysteme und Maschinentypen](operating-systems-and-machine-types.md). ** Windows ** Session Manager unterstützt Windows Server 2012 und höher. Microsoft Windows Server 2016 Nano wird nicht unterstützt. |
| SSM Agent | Auf den verwalteten Knoten, zu denen Sie über Sitzungen eine Verbindung herstellen möchten, muss mindestens AWS Systems Manager SSM Agent Version 2.3.68.0 oder höher installiert sein. Um die Option zum Verschlüsseln von Sitzungsdaten mithilfe eines in AWS Key Management Service (AWS KMS) erstellten Schlüssels verwenden zu können, SSM Agent muss Version 2.3.539.0 oder höher auf dem verwalteten Knoten installiert sein. Um Shell-Profile in einer Sitzung zu verwenden, muss SSM Agent Version 3.0.161.0 oder höher auf dem verwalteten Knoten installiert sein. Um eine Session Manager-Port-Weiterleitung oder SSH-Sitzung zu starten, muss SSM Agent Version 3.0.222.0 oder höher auf dem verwalteten Knoten installiert sein. Um Sitzungsdaten mit Amazon CloudWatch Logs zu streamen, muss SSM Agent Version 3.0.284.0 oder höher auf dem verwalteten Knoten installiert sein. Informationen zum Ermitteln der auf einer Instance ausgeführten Versionsnummer finden Sie unter [Überprüfen der SSM Agent-Versionsnummer](ssm-agent-get-version.md). Informationen über das manuelle Installieren oder automatische Aktualisieren von SSM Agent finden Sie unter [Arbeiten mit SSM Agent](ssm-agent.md). Über das ssm-user-Konto Beginnend mit Version 2.3.50.0 von SSM Agent erstellt der Agent unter Verwendung der Root- oder Administratorberechtigungen ein Benutzerkonto auf dem verwalteten Knoten, das `ssm-user` genannt wird. (Auf Versionen vor 2.3.612.0 wird das Konto erstellt, wenn SSM Agent startet oder neu startet. Auf Version 2.3.612.0 und höher wird `ssm-user` erstellt, wenn eine Sitzung auf dem verwalteten Knoten zum ersten Mal gestartet wird.) Sitzungen werden mittels der Anmeldeinformationen für dieses Benutzerkonto gestartet. Weitere Informationen zum Einschränken der administrativen Kontrolle für dieses Konto finden Sie unter [Deaktivieren oder Aktivieren der Administratorberechtigungen für das SSM-Benutzerkonto](session-manager-getting-started-ssm-user-permissions.md). ssm-user auf Windows Server-Domain-Controller Ab SSM Agent Version 2.3.612.0 wird das `ssm-user`-Konto nicht automatisch auf verwalteten Knoten erstellt, die als Windows Server-Domain-Controller verwendet werden. Um Session Manager auf einer Windows Server-Maschine zu verwenden, die als Domain-Controller verwendet wird, erstellen Sie das `ssm-user`-Konto manuell, sofern es noch nicht vorhanden ist, und weisen dem Benutzer Domain-Administratorberechtigungen zu. Unter Windows Server legt SSM Agent bei jedem Start einer Sitzung ein neues Passwort für das `ssm-user`-Konto fest. Es ist also nicht erforderlich, ein Passwort anzugeben, wenn Sie das Konto erstellen. |
| Konnektivität mit Endpunkten | In diesem Fall müssen die verwalteten Knoten auch ausgehenden HTTPS-Datenverkehr (Port 443) zu den folgenden Endpunkten zulassen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/session-manager-prerequisites.html) Weitere Informationen finden Sie unter den folgenden Themen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/session-manager-prerequisites.html) Alternativ können Sie sich über Schnittstellenendpunkte mit den erforderlichen Endpunkten verbinden. Weitere Informationen finden Sie unter [Schritt 6: (Optional) Verwenden Sie diese Option AWS PrivateLink , um einen VPC-Endpunkt einzurichten für Session Manager](session-manager-getting-started-privatelink.md). |
| AWS CLI | (Optional) Wenn Sie AWS Command Line Interface (AWS CLI) verwenden, um Ihre Sitzungen zu starten (anstatt die AWS Systems Manager Konsole oder die Amazon EC2 EC2-Konsole zu verwenden), muss Version 1.16.12 oder höher der CLI auf Ihrem lokalen Computer installiert sein. Zum Überprüfen der Version können Sie den Befehl `aws --version` aufrufen. Wenn Sie die CLI installieren oder aktualisieren müssen, finden Sie [weitere Informationen unter Installation von AWS Command Line Interface im](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) AWS Command Line Interface Benutzerhandbuch. Wenn Systems Manager neue Tools hinzugefügt oder Aktualisierungen an den vorhandenen Tools vorgenommen werden, wird eine neue Version von SSM Agent veröffentlicht. Wenn Sie nicht die neueste Version des Agenten verwenden, kann dies dazu führen, dass der verwaltete Knoten nicht die zahlreichen Tools und Features von Systems Manager verwendet. Aus diesem Grund empfehlen wir, dass Sie den Prozess zur Aktualisierung von SSM Agent in Ihren Maschinen automatisieren. Weitere Informationen finden Sie unter [Automatisieren von Updates für SSM Agent](ssm-agent-automatic-updates.md). Abonnieren Sie die [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)-Seite in GitHub, um Benachrichtigungen über SSM Agent-Updates zu erhalten. Um die CLI zur Verwaltung Ihrer Knoten mit Session Manager verwenden zu können, müssen Sie zunächst das Session Manager-Plugin auf Ihrer lokalen Maschine installieren. Weitere Informationen finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md). |
| Aktivieren des Advanced-Instances-Kontingents ([Hybrid- und Multi-Cloud-Umgebungen](operating-systems-and-machine-types.md#supported-machine-types)) | Um eine Verbindung zu Nicht-EC2-Computern herzustellenSession Manager, müssen Sie die Stufe Advanced-Instances in dem Bereich aktivieren, in AWS-Region dem AWS-Konto Sie Hybrid-Aktivierungen erstellen, um Nicht-EC2-Computer als verwaltete Knoten zu registrieren. Die Nutzung des Advanced-Instances-Kontingents ist kostenpflichtig. Weitere Informationen zum Aktivieren des Advanced-Instances-Kontingent finden Sie unter [Konfigurieren von Instance-Kontingenten](fleet-manager-configure-instance-tiers.md). |
| Überprüfen der Berechtigungen für IAM-Servicerollen ([Hybrid- und Multi-Cloud-Umgebungen](operating-systems-and-machine-types.md#supported-machine-types)) | Hybrid-aktivierte Knoten verwenden die in der Hybrid-Aktivierung angegebene Dienstrolle AWS Identity and Access Management (IAM), um mit Systems Manager Manager-API-Vorgängen zu kommunizieren. Diese Servicerolle muss die Berechtigungen enthalten, die zum Herstellen einer Verbindung mit Ihren [Hybrid- und Multi-Cloud-Maschinen](operating-systems-and-machine-types.md#supported-machine-types) mit Session Manager erforderlich sind. Wenn Ihre Servicerolle die AWS verwaltete Richtlinie enthält`AmazonSSMManagedInstanceCore`, Session Manager sind die erforderlichen Berechtigungen für bereits bereitgestellt. Wenn Sie feststellen, dass die Servicerolle nicht die erforderlichen Berechtigungen enthält, müssen Sie die verwaltete Instance abmelden und sie bei einer neuen Hybrid-Aktivierung registrieren, die eine IAM-Servicerolle mit den erforderlichen Berechtigungen verwendet. Informationen über das Abmelden verwalteter Instances finden Sie unter [Aufheben der Registrierung von verwalteten Knoten in einer Hybrid- und Multi-Cloud-Umgebung](fleet-manager-deregister-hybrid-nodes.md). Weitere Informationen zum Erstellen von IAM-Richtlinien mit Session Manager-Berechtigungen finden Sie unter [Schritt 2: Überprüfen oder Hinzufügen von Instance-Berechtigungen für Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-instance-profile.html). |
# Schritt 2: Überprüfen oder Hinzufügen von Instance-Berechtigungen für Session Manager
Hat standardmäßig AWS Systems Manager keine Berechtigung, Aktionen auf Ihren Instances durchzuführen. Sie können Instance-Berechtigungen auf Kontoebene mithilfe einer AWS Identity and Access Management (IAM)-Rolle oder auf Instance-Ebene mithilfe eines Instance-Profils bereitstellen. Wenn Ihr Anwendungsfall dies zulässt, empfehlen wir, mithilfe der Standardkonfiguration für die Host-Verwaltung Zugriff auf Kontoebene zu gewähren. Wenn Sie die Standardkonfiguration für die Host-Verwaltung für Ihr Konto bereits mithilfe der `AmazonSSMManagedEC2InstanceDefaultPolicy`-Richtlinie eingerichtet haben, können Sie mit dem nächsten Schritt fortfahren. Weitere Informationen über die Standardkonfiguration für die Host-Verwaltung finden Sie unter [Automatisches Verwalten von EC2-Instances mit der Standard-Host-Management-Konfiguration](fleet-manager-default-host-management-configuration.md).
Alternativ können Sie auch Instance-Profile verwenden, um Ihren Instances die erforderlichen Berechtigungen zu erteilen. Ein Instance-Profil übergibt eine IAM-Rolle an eine Amazon-EC2-Instance. Sie können ein IAM-Instance-Profil einer Amazon-EC2-Instance beim Starten anfügen oder einer zuvor gestarteten Instance anfügen. Weitere Informationen finden Sie unter [Verwenden von Instance-Profilen](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-usingrole-instanceprofile.html).
Für lokale Server oder virtuelle Maschinen (VMs) werden die Berechtigungen von der IAM-Dienstrolle bereitgestellt, die mit der Hybridaktivierung verknüpft ist, die zur Registrierung Ihrer lokalen Server verwendet wird, und VMs von Systems Manager. Lokale Server und verwenden VMs keine Instanzprofile.
Wenn Sie bereits andere Systems-Manager-Tools wie Run Command oder Parameter Store verwenden, ist Ihren Amazon-EC2-Instances möglicherweise bereits ein Instance-Profil mit den für Session Manager erforderlichen Grundberechtigungen angefügt. Wenn ein Instanzprofil, das die AWS verwaltete Richtlinie enthält, bereits an Ihre Instanzen angehängt `AmazonSSMManagedInstanceCore` ist, Session Manager sind die erforderlichen Berechtigungen für bereits bereitgestellt. Dies gilt auch, wenn die bei Ihrer Hybrid-Aktivierung verwendete IAM-Servicerolle die verwaltete Richtlinie `AmazonSSMManagedInstanceCore` enthält.
In einigen Fällen müssen Sie jedoch möglicherweise die Berechtigungen ändern, die Ihrem Instance-Profil zugeordnet sind. Sie möchten beispielsweise einen engeren Satz von Instance-Berechtigungen bereitstellen, Sie haben eine benutzerdefinierte Richtlinie für Ihr Instance-Profil erstellt oder Sie möchten die Verschlüsselungsoptionen Amazon Simple Storage Service (Amazon S3) oder AWS Key Management Service (AWS KMS) zur Sicherung von Sitzungsdaten verwenden. Führen Sie in diesen Fällen einen der folgenden Schritte aus, um Session Manager-Aktionen auf Ihren Instances auszuführen:
+ **Einbetten von Berechtigungen für Session Manager-Aktionen in einer benutzerdefinierten IAM-Rolle**
Um einer vorhandenen IAM-Rolle, die nicht auf der AWS bereitgestellten Standardrichtlinie basiert, Berechtigungen für Session Manager Aktionen hinzuzufügen`AmazonSSMManagedInstanceCore`, folgen Sie den Schritten unter. [Session Manager-Berechtigungen für eine vorhandene IAM-Rolle hinzufügen](getting-started-add-permissions-to-existing-profile.md)
+ **Erstellen einer benutzerdefinierten IAM-Rolle, die ausschließlich Session Manager-Berechtigungen besitzt**
Um eine IAM-Rolle zu erstellen, die ausschließlich Berechtigungen für Session Manager-Aktionen enthält, befolgen Sie die Schritte in [Erstellen einer benutzerdefinierten IAM-Rolle für Session Manager](getting-started-create-iam-instance-profile.md).
+ **Erstellen und Verwenden einer neuen IAM-Rolle mit Berechtigungen für alle Systems-Manager-Aktionen**
Um eine IAM-Rolle für von Systems Manager verwaltete Instanzen zu erstellen, die eine Standardrichtlinie verwendet, die bereitgestellt wird, AWS um allen Systems Manager-Berechtigungen zu gewähren, folgen Sie den Schritten [unter Konfigurieren der für Systems Manager erforderlichen Instanzberechtigungen](setup-instance-permissions.md).
**Topics**
+ [Session Manager-Berechtigungen für eine vorhandene IAM-Rolle hinzufügen](getting-started-add-permissions-to-existing-profile.md)
+ [Erstellen einer benutzerdefinierten IAM-Rolle für Session Manager](getting-started-create-iam-instance-profile.md)
# Session Manager-Berechtigungen für eine vorhandene IAM-Rolle hinzufügen
Gehen Sie wie folgt vor, um einer vorhandenen AWS Identity and Access Management (IAM)-Rolle Session Manager-Berechtigungen hinzuzufügen. Durch das Hinzufügen von Berechtigungen zu einer vorhandenen Rolle können Sie die Sicherheit Ihrer Computerumgebung verbessern, ohne die AWS `AmazonSSMManagedInstanceCore` Richtlinie für Instanzberechtigungen verwenden zu müssen.
**Anmerkung**
Notieren Sie die folgenden Informationen:
Dieses Verfahren setzt voraus, dass Ihre vorhandene Rolle bereits andere Systems-Manager-`ssm`-Berechtigungen für Aktionen enthält, für die Sie den Zugriff erlauben möchten. Diese Richtlinie reicht allein nicht aus, um Session Manager verwenden zu können.
Das folgende Richtlinienbeispiel beinhaltet eine `s3:GetEncryptionConfiguration`-Aktion. Diese Aktion ist erforderlich, wenn Sie in den Session Manager-Protokollierungseinstellungen die Option **S3-Protokollverschlüsselung erzwingen** gewählt haben.
Wenn die `ssmmessages:OpenControlChannel` Berechtigung aus den Richtlinien entfernt wird, die mit Ihrem IAM-Instanzprofil oder Ihrer IAM-Dienstrolle verknüpft sind, SSM Agent verliert der verwaltete Knoten die Konnektivität zum Systems Manager Manager-Dienst in der Cloud. Es kann jedoch bis zu 1 Stunde dauern, bis eine Verbindung beendet wird, nachdem die Berechtigung entfernt wurde. Dies ist dasselbe Verhalten wie beim Löschen der IAM-Instanzrolle oder der IAM-Servicerolle.
**So fügen Sie Session Manager-Berechtigungen einer vorhandenen Rolle hinzu (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im Navigationsbereich **Rollen**.
1. Wählen Sie den Namen der Rolle aus, zu der Sie die Berechtigungen hinzufügen möchten.
1. Wählen Sie die Registerkarte **Berechtigungen**.
1. Wählen Sie **Berechtigungen hinzufügen** und dann **Eingebundene Richtlinie hinzufügen** aus.
1. Wählen Sie den Tab **JSON**.
1. Ersetzen Sie den Inhalt der Standardrichtlinie durch den folgenden Inhalt. *key-name*Ersetzen Sie es durch den Amazon-Ressourcennamen (ARN) des AWS Key Management Service Schlüssels (AWS KMS key), den Sie verwenden möchten.
------
#### [ 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"
}
]
}
```
------
Weitere Informationen über die Verwendung eines KMS-Schlüssels zum Verschlüsseln von Sitzungsdaten finden Sie unter [So aktivieren Sie die KMS-Schlüsselverschlüsselung von Sitzungsdaten (Konsole)](session-preferences-enable-encryption.md).
Wenn Sie keine AWS KMS Verschlüsselung für Ihre Sitzungsdaten verwenden, können Sie den folgenden Inhalt aus der Richtlinie entfernen.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. Wählen Sie **Weiter: Tags** aus.
1. (Optional) Fügen Sie Tags hinzu, indem Sie **Tag hinzufügen** auswählen und die bevorzugten Tags für die Richtlinie eingeben.
1. Wählen Sie **Weiter: Prüfen** aus.
1. Geben Sie auf der Seite **Richtlinie prüfen** im Feld **Name** einen Namen für die Inline-Richtlinie ein, z. B. **SessionManagerPermissions**.
1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für die Richtlinie ein.
Wählen Sie **Richtlinie erstellen** aus.
Weitere Informationen über die `ssmmessages`-Aktionen finden Sie unter [Referenz: ec2messages, ssmmessages und andere API-Operationen](systems-manager-setting-up-messageAPIs.md).
# Erstellen einer benutzerdefinierten IAM-Rolle für Session Manager
Sie können eine AWS Identity and Access Management (IAM-) Rolle erstellen, die Ihnen Session Manager die Berechtigung erteilt, Aktionen auf Ihren von Amazon EC2 verwalteten Instances durchzuführen. Sie können auch eine Richtlinie hinzufügen, um die Berechtigungen zu gewähren, die für das Senden von Sitzungsprotokollen an Amazon Simple Storage Service (Amazon S3) und Amazon CloudWatch Logs erforderlich sind.
Nachdem Sie die IAM-Rolle erstellt haben, finden Sie Informationen dazu, wie Sie die Rolle an eine Instance [anhängen oder ersetzen können, auf der AWS re:Post Website unter Ein Instance-Profil](https://aws.amazon.com/premiumsupport/knowledge-center/attach-replace-ec2-instance-profile/) anhängen oder ersetzen. Weitere Informationen über IAM-Instance-Profile und -Rollen finden Sie unter [Verwendung von Instance-Profilen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) im *IAM-Benutzerhandbuch* und [IAM-Rollen für Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) im *Amazon Elastic Compute Cloud-Benutzerhandbuch für Linux-Instances*. Weitere Informationen zum Erstellen einer IAM-Servicerolle für On-Premises-Maschinen finden Sie unter [Erstellen der für Systems Manager erforderlichen IAM-Servicerolle in Hybrid- und Multi-Cloud-Umgebungen.](https://docs.aws.amazon.com/systems-manager/latest/userguide/hybrid-multicloud-service-role.html)
**Topics**
+ [Erstellen einer IAM-Rolle mit geringstmöglichen Session Manager-Berechtigungen (Konsole)](#create-iam-instance-profile-ssn-only)
+ [Erstellen einer IAM-Rolle mit Berechtigungen für Amazon S3 Session Manager und CloudWatch Logs (Konsole)](#create-iam-instance-profile-ssn-logging)
## Erstellen einer IAM-Rolle mit geringstmöglichen Session Manager-Berechtigungen (Konsole)
Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte IAM-Rolle mit einer Richtlinie zu erstellen, die ausschließlich Berechtigungen für Session Manager-Aktionen auf Ihren Instances bereitstellt.
**So erstellen Sie ein Instance-Profil mit den geringstmöglichen Session Manager-Berechtigungen (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im Navigationsbereich **Richtlinien** und dann **Richtlinie erstellen**. (Wenn die Schaltfläche **Get Started (Erste Schritte)** angezeigt wird, klicken Sie darauf und wählen Sie anschließend **Create Policy (Richtlinie erstellen)** aus.)
1. Wählen Sie den Tab **JSON**.
1. Ersetzen Sie den Standardinhalt durch folgende Richtlinie. Um Sitzungsdaten mit AWS Key Management Service (AWS KMS) zu verschlüsseln, ersetzen Sie *key-name* sie durch den Amazon-Ressourcennamen (ARN) der AWS KMS key , die Sie verwenden möchten.
**Anmerkung**
Wenn die `ssmmessages:OpenControlChannel` Berechtigung aus den Richtlinien entfernt wird, die mit Ihrem IAM-Instanzprofil oder Ihrer IAM-Dienstrolle verknüpft sind, SSM Agent verliert der verwaltete Knoten die Konnektivität zum Systems Manager Manager-Dienst in der Cloud. Es kann jedoch bis zu 1 Stunde dauern, bis eine Verbindung beendet wird, nachdem die Berechtigung entfernt wurde. Dies ist dasselbe Verhalten wie beim Löschen der IAM-Instanzrolle oder der IAM-Servicerolle.
------
#### [ 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"
}
]
}
```
------
Weitere Informationen über die Verwendung eines KMS-Schlüssels zum Verschlüsseln von Sitzungsdaten finden Sie unter [So aktivieren Sie die KMS-Schlüsselverschlüsselung von Sitzungsdaten (Konsole)](session-preferences-enable-encryption.md).
Wenn Sie keine AWS KMS Verschlüsselung für Ihre Sitzungsdaten verwenden, können Sie den folgenden Inhalt aus der Richtlinie entfernen.
```
,
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": "key-name"
}
```
1. Wählen Sie **Weiter: Tags** aus.
1. (Optional) Fügen Sie Tags hinzu, indem Sie **Tag hinzufügen** auswählen und die bevorzugten Tags für die Richtlinie eingeben.
1. Wählen Sie **Weiter: Prüfen** aus.
1. Geben Sie auf der Seite **Richtlinie prüfen** im Feld **Name** einen Namen für die Inline-Richtlinie ein, z. B. **SessionManagerPermissions**.
1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für die Richtlinie ein.
1. Wählen Sie **Richtlinie erstellen** aus.
1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen**.
1. Auf der Seite **Create Role** (Rolle erstellen) wählen Sie **AWS service** (-Service), und für**Use case** (Anwendungsfall), wählen Sie **EC2** aus.
1. Wählen Sie **Weiter** aus.
1. Aktivieren Sie auf der Seite **Attached permissions policy** (Richtlinie für angefügte Berechtigungen) das Kontrollkästchen links neben dem Namen der Richtlinie, die Sie gerade erstellt haben, z. B. **SessionManagerPermissions**.
1. Wählen Sie **Weiter** aus.
1. Geben Sie auf der Seite **Name, review, and create** (Benennen, überprüfen und erstellen) für **Role name** (Rollenname) einen Namen für die IAM-Rolle ein, z. B. **MySessionManagerRole**.
1. (Optional) Geben Sie in **Role description (Beschreibung der Rolle)** eine Beschreibung für das Instance-Profil ein.
1. (Optional) Fügen Sie Tags hinzu, indem Sie**Add tag** (Tag hinzufügen) auswählen und die bevorzugten Tags für die Richtlinie eingeben.
Wählen Sie **Rolle erstellen** aus.
Weitere Informationen zu `ssmmessages`-Aktionen finden Sie unter [Referenz: ec2messages, ssmmessages und andere API-Operationen](systems-manager-setting-up-messageAPIs.md).
## Erstellen einer IAM-Rolle mit Berechtigungen für Amazon S3 Session Manager und CloudWatch Logs (Konsole)
Verwenden Sie das folgende Verfahren, um eine benutzerdefinierte IAM-Rolle mit einer Richtlinie zu erstellen, die Berechtigungen für Session Manager-Aktionen auf Ihren Instances bereitstellt. Die Richtlinie bietet auch die erforderlichen Berechtigungen für die Speicherung von Sitzungsprotokollen in Amazon Simple Storage Service (Amazon S3) -Buckets und Amazon CloudWatch Logs-Protokollgruppen.
**Wichtig**
Um Sitzungsprotokolle an einen Amazon S3-Bucket auszugeben, der zu einem anderen AWS-Konto gehört, müssen Sie die `s3:PutObjectAcl`-Berechtigung dieser IAM-Rollen-Richtlinie hinzufügen. Außerdem müssen Sie sicherstellen, dass die Bucket-Richtlinie kontenübergreifenden Zugriff auf die IAM-Rolle gewährt, die vom besitzenden Konto verwendet wird, um dem Systems Manager Berechtigungen für verwaltete Instances zu gewähren. Wenn der Bucket die Verschlüsselung des Key Management Service (KMS) verwendet, muss die KMS-Richtlinie des Buckets diesen kontoübergreifenden Zugriff ebenfalls gewähren. Weitere Informationen zur Konfiguration von kontoübergreifenden Bucket-Berechtigungen in Amazon S3 finden Sie unter [Gewährung von kontoübergreifenden Bucket-Berechtigungen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*. Wenn die kontoübergreifenden Berechtigungen nicht hinzugefügt werden, kann das Konto, das Eigentümer des Amazon-S3-Buckets ist, nicht auf die Sitzungsausgabeprotokolle zugreifen.
Informationen zum Angeben von Präferenzen für das Speichern von Sitzungsprotokollen finden Sie unter [Protokollierung von Sitzungen aktivieren und deaktivieren](session-manager-logging.md).
**So erstellen Sie eine IAM-Rolle mit Berechtigungen für Session Manager Amazon S3 und CloudWatch Logs (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im Navigationsbereich **Richtlinien** und dann **Richtlinie erstellen**. (Wenn die Schaltfläche **Get Started (Erste Schritte)** angezeigt wird, klicken Sie darauf und wählen Sie anschließend **Create Policy (Richtlinie erstellen)** aus.)
1. Wählen Sie den Tab **JSON**.
1. Ersetzen Sie den Standardinhalt durch folgende Richtlinie. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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. Wählen Sie **Weiter: Tags** aus.
1. (Optional) Fügen Sie Tags hinzu, indem Sie **Tag hinzufügen** auswählen und die bevorzugten Tags für die Richtlinie eingeben.
1. Wählen Sie **Weiter: Prüfen** aus.
1. Geben Sie auf der Seite **Richtlinie prüfen** im Feld **Name** einen Namen für die Inline-Richtlinie ein, z. B. **SessionManagerPermissions**.
1. (Optional) Geben Sie im Feld **Beschreibung** eine Beschreibung für die Richtlinie ein.
1. Wählen Sie **Richtlinie erstellen** aus.
1. Wählen Sie im Navigationsbereich **Rollen** und dann **Rolle erstellen**.
1. Auf der Seite **Create Role** (Rolle erstellen) wählen Sie **AWS service** (-Service), und für**Use case** (Anwendungsfall), wählen Sie **EC2** aus.
1. Wählen Sie **Weiter** aus.
1. Aktivieren Sie auf der Seite **Attached permissions policy** (Richtlinie für angefügte Berechtigungen) das Kontrollkästchen links neben dem Namen der Richtlinie, die Sie gerade erstellt haben, z. B. **SessionManagerPermissions**.
1. Wählen Sie **Weiter** aus.
1. Geben Sie auf der Seite **Name, review, and create** (Benennen, überprüfen und erstellen) für **Role name** (Rollenname) einen Namen für die IAM-Rolle ein, z. B. **MySessionManagerRole**.
1. (Optional) Geben Sie im Feld **Role description** (Rollenbeschreibung) eine Beschreibung für die Rolle ein.
1. (Optional) Fügen Sie Tags hinzu, indem Sie**Add tag** (Tag hinzufügen) auswählen und die bevorzugten Tags für die Richtlinie eingeben.
1. Wählen Sie **Rolle erstellen** aus.
# Schritt 3: Steuern des Sitzungs-Zugriffs auf verwaltete Knoten
Sie gewähren oder entziehen Session Manager den Zugriff auf verwaltete Knoten mithilfe von AWS Identity and Access Management (IAM-) Richtlinien. Sie können eine Richtlinie erstellen und sie einem IAM-Benutzer oder einer IAM-Gruppe zuordnen, die festlegt, mit welchen verwalteten Knoten sich der Benutzer oder die Gruppe verbinden kann. Sie können auch die Session Manager-API-Operationen festlegen, die der Benutzer oder die Gruppe auf diesen verwalteten Knoten durchführen kann.
Um Ihnen den Einstieg in die IAM-Berechtigungsrichtlinien für Session Manager zu erleichtern, haben wir Beispielrichtlinien für einen Endbenutzer und einen Administrator erstellt. Sie können diese Richtlinien mit nur geringfügigen Änderungen verwenden. Oder verwenden Sie sie als Leitfaden für die Erstellung benutzerdefinierter IAM-Richtlinien. Weitere Informationen finden Sie unter [Muster-IAM-Richtlinien für Session Manager](getting-started-restrict-access-quickstart.md). Informationen dazu, wie Sie IAM-Richtlinien erstellen und diese Benutzern oder Gruppen anfügen, finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) und [Hinzufügen und Entfernen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.
**Über Sitzungs-ID-ARN-Formate**
Beim Erstellen einer IAM-Richtlinie für den Session Manager-Zugriff geben Sie eine Sitzungs-ID als Teil des Amazon-Ressourcennamens (ARN) an. Die Sitzungs-ID enthält den Benutzernamen als Variable. Um dies zu veranschaulichen, finden Sie hier das Format eines Session Manager-ARN und ein Beispiel:
```
arn:aws:ssm:region-id:account-id:session/session-id
```
Beispiel:
```
arn:aws:ssm:us-east-2:123456789012:session/JohnDoe-1a2b3c4d5eEXAMPLE
```
Weitere Informationen zur Verwendung von Variablen in IAM-Richtlinien finden Sie unter [IAM-Richtlinienelemente: Variablen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html).
**Topics**
+ [Starten Sie eine Standard-Shell-Sitzung, indem Sie das Standard-Sitzungsdokument in den IAM-Richtlinien angeben](getting-started-default-session-document.md)
+ [Starten Sie eine Sitzung mit einem Dokument, indem Sie die Sitzungsdokumente in IAM-Richtlinien angeben](getting-started-specify-session-document.md)
+ [Muster-IAM-Richtlinien für Session Manager](getting-started-restrict-access-quickstart.md)
+ [Zusätzliche IAM-Beispielrichtlinien für Session Manager](getting-started-restrict-access-examples.md)
# Starten Sie eine Standard-Shell-Sitzung, indem Sie das Standard-Sitzungsdokument in den IAM-Richtlinien angeben
Wenn Sie die Konfiguration Session Manager für Ihre Sitzung vornehmen AWS-Konto oder wenn Sie die Sitzungseinstellungen in der Systems Manager Manager-Konsole ändern, erstellt das System ein SSM-Sitzungsdokument mit dem Namen`SSM-SessionManagerRunShell`. Dies ist das Standard-Sitzungsdokument. Session Manager verwendet dieses Dokument, um Ihre Sitzungseinstellungen zu speichern, die Informationen wie die folgenden enthalten:
+ Ein Ort, an dem Sie Sitzungsdaten speichern möchten, z. B. ein Amazon Simple Storage Service (Amazon S3) -Bucket oder eine Amazon CloudWatch Logs-Protokollgruppe.
+ Eine AWS Key Management Service (AWS KMS) Schlüssel-ID zum Verschlüsseln von Sitzungsdaten.
+ Ob die Unterstützung von Run As für Ihre Sitzungen erlaubt ist.
Hier sehen Sie ein Beispiel für die Informationen, die im `SSM-SessionManagerRunShell`-Dokument Sitzungseinstellungen enthalten sind.
```
{
"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"
}
}
```
Standardmäßig verwendet Session Manager das Standard-Sitzungsdokument, wenn ein Benutzer eine Sitzung von AWS-Managementkonsole aus startet. Dies gilt entweder für Fleet Manager oder Session Manager in der Systems Manager Manager-Konsole oder für EC2 Connect in der Amazon EC2 EC2-Konsole. Session Managerverwendet auch das Standardsitzungsdokument, wenn ein Benutzer eine Sitzung mit einem AWS CLI Befehl wie dem folgenden Beispiel startet:
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE
```
Um eine Standard-Shell-Sitzung zu starten, müssen Sie das Standard-Sitzungsdokument in der IAM-Richtlinie angeben, wie im folgenden Beispiel gezeigt.
------
#### [ 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": [
"*"
]
}
]
}
```
------
# Starten Sie eine Sitzung mit einem Dokument, indem Sie die Sitzungsdokumente in IAM-Richtlinien angeben
Wenn Sie den AWS CLI -Befehl [start-session](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html) mit dem Standard-Sitzungsdokument verwenden, können Sie den Dokumentnamen auslassen. Das System ruft automatisch das `SSM-SessionManagerRunShell`-Sitzungsdokument auf.
In allen anderen Fällen müssen Sie einen Wert für den `document-name`-Parameter angeben. Wenn ein Benutzer den Namen eines Sitzungsdokuments in einem Befehl angibt, überprüft das System seine IAM-Richtlinie, um sicherzustellen, dass er berechtigt ist, auf das Dokument zuzugreifen. Wenn sie nicht berechtigt sind, schlägt die Verbindungsanforderung fehl. In den folgenden Beispielen ist der `document-name`-Parameter im `AWS-StartPortForwardingSession`-Sitzungsdokument enthalten.
```
aws ssm start-session \
--target i-02573cafcfEXAMPLE \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"], "localPortNumber":["56789"]}'
```
Ein Beispiel für die Angabe eines Session Manager-Sitzungsdokuments in einer IAM-Richtlinie finden Sie unter [Kurzeinführung in Endbenutzerrichtlinien für Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
**Anmerkung**
Um eine Sitzung mit SSH zu starten, müssen Sie die Konfigurationsschritte auf dem verwalteten Zielknoten *and* der lokalen Maschine des Benutzers ausführen. Informationen finden Sie unter [(Optional) Berechtigungen für SSH-Verbindungen über Session Manager zulasen und steuern](session-manager-getting-started-enable-ssh-connections.md).
# Muster-IAM-Richtlinien für Session Manager
Verwenden Sie die Beispiele in diesem Abschnitt, um Ihnen bei der Erstellung von AWS Identity and Access Management (IAM-) Richtlinien zu helfen, die die am häufigsten benötigten Zugriffsberechtigungen Session Manager bereitstellen.
**Anmerkung**
Sie können auch eine AWS KMS key Richtlinie verwenden, um zu kontrollieren, welche IAM-Entitäten (Benutzer oder Rollen) Zugriff auf Ihren KMS-Schlüssel erhalten. AWS-Konten Weitere Informationen finden Sie [im *AWS Key Management Service Entwicklerhandbuch* unter Überblick über die Verwaltung des Zugriffs auf Ihre AWS KMS Ressourcen](https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html) und die [Verwendung wichtiger Richtlinien](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html). AWS KMS
**Topics**
+ [Kurzeinführung in Endbenutzerrichtlinien für Session Manager](#restrict-access-quickstart-end-user)
+ [Kurzeinführung in Administratorrichtlinien für Session Manager](#restrict-access-quickstart-admin)
## Kurzeinführung in Endbenutzerrichtlinien für Session Manager
Verwenden Sie die folgenden Beispiele, um IAM-Endbenutzerrichtlinien für Session Manager zu erstellen.
Sie können eine Richtlinie erstellen, die es Benutzern ermöglicht, Sitzungen nur von der Session Manager Konsole und AWS Command Line Interface (AWS CLI), nur von der Amazon Elastic Compute Cloud (Amazon EC2) -Konsole oder von allen drei aus zu starten.
Diese Richtlinien bieten Endbenutzern die Möglichkeit, eine Sitzung zu einem bestimmten verwalteten Knoten zu starten und nur ihre eigenen Sitzungen zu beenden. Beispiele für Anpassungen, die Sie möglicherweise für die Richtlinie ausführen sollten, finden Sie unter [Zusätzliche IAM-Beispielrichtlinien für Session Manager](getting-started-restrict-access-examples.md).
Ersetzen Sie in den folgenden Beispielrichtlinien jede *example resource placeholder* durch Ihre eigenen Informationen.
Wählen Sie die folgenden Registerkarten, um die Beispielrichtlinie für den Bereich des Sitzungszugriffs anzuzeigen, den Sie bereitstellen möchten.
------
#### [ Session Manager and Fleet Manager ]
Verwenden Sie diese Beispielrichtlinie für Provider-Benutzer, die Sitzungen nur über die Session Manager- und die Fleet Manager-Konsolen starten und wiederaufnehmen können.
------
#### [ 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 ]
Verwenden Sie diese Beispielrichtlinie für Provider-Benutzer, die Sitzungen nur über die Amazon EC2-Konsole starten und wiederaufnehmen können. Diese Richtlinie bietet nicht alle Berechtigungen, die zum Starten von Sitzungen über die Session ManagerKonsole und die AWS CLI Konsole erforderlich sind.
------
#### [ 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 ]
Verwenden Sie diese Beispielrichtlinie für Provider-Benutzer, die Sitzungen nur über die AWS CLI starten und wiederaufnehmen können.
------
#### [ 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"
}
]
}
```
------
------
**Anmerkung**
`SSM-SessionManagerRunShell` ist der Standardname des SSM-Dokuments, das Session Manager zum Speichern Ihrer Sitzungskonfiguration erstellt. Sie können stattdessen ein benutzerdefiniertes Sitzungsdokument erstellen und es in dieser Richtlinie angeben. Sie können auch das von AWS bereitgestellte Dokument `AWS-StartSSHSession` für Benutzer verwenden, die Sitzungen mit SSH starten. Weitere Informationen über die für die Unterstützung von Sitzungen mit SSH erforderlichen Konfigurationsschritte finden Sie unter [(Optional) Zulassen und Steuern von Berechtigungen für SSH-Verbindungen über Session Manager](session-manager-getting-started-enable-ssh-connections.md).
Die `kms:GenerateDataKey`-Berechtigung ermöglicht die Erstellung eines Datenverschlüsselungsschlüssels, der zur Verschlüsselung von Sitzungsdaten verwendet wird. Wenn Sie die Verschlüsselung AWS Key Management Service (AWS KMS) für Ihre Sitzungsdaten verwenden, *key-name* ersetzen Sie sie durch den Amazon-Ressourcennamen (ARN) des KMS-Schlüssels, den Sie verwenden möchten, im Format`arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE`. Wenn Sie keine KMS-Schlüsselverschlüsselung für Ihre Sitzungsdaten verwenden möchten, entfernen Sie den folgenden Inhalt aus der Richtlinie.
```
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey"
],
"Resource": "key-name"
}
```
Informationen zur Verwendung AWS KMS zur Verschlüsselung von Sitzungsdaten finden Sie unter[So aktivieren Sie die KMS-Schlüsselverschlüsselung von Sitzungsdaten (Konsole)](session-preferences-enable-encryption.md).
Die Genehmigung für [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html) ist erforderlich, wenn ein Benutzer versucht, eine Sitzung über die Amazon-EC2-Konsole zu starten, aber SSM Agent zunächst auf die erforderliche Mindestversion für Session Manager aktualisiert werden muss. Run Command wird verwendet, um einen Befehl an die Instance zu senden und den Agenten zu aktualisieren.
## Kurzeinführung in Administratorrichtlinien für Session Manager
Verwenden Sie die folgenden Beispiele, um IAM-Administratorrichtlinien für Session Manager zu erstellen.
Diese Richtlinien bieten Administratoren die Möglichkeit, eine Sitzung für verwaltete Knoten zu starten, die mit `Key=Finance,Value=WebServers` markiert sind, sowie die Berechtigung zum Erstellen, Aktualisieren und Löschen von Einstellungen und die Berechtigung, nur ihre eigenen Sitzungen zu beenden. Beispiele für Anpassungen, die Sie möglicherweise für die Richtlinie ausführen sollten, finden Sie unter [Zusätzliche IAM-Beispielrichtlinien für Session Manager](getting-started-restrict-access-examples.md).
Sie können eine Richtlinie erstellen, die es Administratoren ermöglicht, diese Aufgaben nur von der Session Manager Konsole und AWS CLI nur von der Amazon EC2 EC2-Konsole aus oder von allen drei aus auszuführen.
Ersetzen Sie in den folgenden Beispielrichtlinien jede *example resource placeholder* durch Ihre eigenen Informationen.
Wählen Sie die folgenden Registerkarten aus, um die Beispielrichtlinie für das zu unterstützende Zugriffsszenario anzuzeigen.
------
#### [ Session Manager and CLI ]
Verwenden Sie diese Beispielrichtlinie für Provider-Administratoren, die sitzungsbezogene Aufgaben nur über die Session Manager-Konsole und die AWS CLI ausführen können. Diese Richtlinie bietet nicht alle Berechtigungen, die für die Ausführung von sitzungsbezogenen Aufgaben über die Amazon EC2-Konsole erforderlich sind.
------
#### [ 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 ]
Verwenden Sie diese Beispielrichtlinie für Provider-Administratoren, die sitzungsbezogene Aufgaben nur über die Amazon EC2-Konsole ausführen können. Diese Richtlinie bietet nicht alle Berechtigungen, die zum Ausführen von sitzungsbezogenen Aufgaben über die Session Manager-Konsole und die AWS CLI-Konsole erforderlich sind.
------
#### [ 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}-*"
]
}
]
}
```
------
------
#### [ Session Manager, CLI, and Amazon EC2 ]
Verwenden Sie diese Beispielrichtlinie für Provider-Administratoren, die sitzungsbezogene Aufgaben über die Session Manager-Konsole, die AWS CLI und die Amazon EC2-Konsole ausführen können.
------
#### [ 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}-*"
]
}
]
}
```
------
------
**Anmerkung**
Die Berechtigung für [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html) ist erforderlich, wenn ein Benutzer versucht, eine Sitzung über die Amazon-EC2-Konsole zu starten, aber zuerst ein Befehl zur Aktualisierung von SSM Agent gesendet werden muss.
# Zusätzliche IAM-Beispielrichtlinien für Session Manager
Die folgenden Beispielrichtlinien helfen Ihnen beim Erstellen einer benutzerdefinierten AWS Identity and Access Management (IAM)-Richtlinien für alle Session Manager-Benutzerzugriffsszenarien, die Sie unterstützen müssen.
**Topics**
+ [Beispiel 1: Zugriff auf Dokumente in der Konsole gewähren](#grant-access-documents-console-example)
+ [Beispiel 2: Beschränken des Zugriffs auf bestimmte verwaltete Knoten](#restrict-access-example-instances)
+ [Beispiel 3: Beschränken des Zugriffs anhand von Tags](#restrict-access-example-instance-tags)
+ [Beispiel 4: Benutzern erlauben, ausschließlich von ihnen gestartete Sitzungen zu beenden](#restrict-access-example-user-sessions)
+ [Beispiel 5: Benutzer erhalten vollständigen (administrativen) Zugriff auf alle Sitzungen](#restrict-access-example-full-access)
## Beispiel 1: Zugriff auf Dokumente in der Konsole gewähren
Sie können Benutzern erlauben, ein benutzerdefiniertes Dokument anzugeben, wenn sie eine Sitzung über die Session-Manager-Konsole starten. Das folgende Beispiel für eine IAM-Richtlinie gewährt die Erlaubnis, auf Dokumente zuzugreifen, deren Namen mit **SessionDocument-** den angegebenen AWS-Region und AWS-Konto beginnen.
Um diese Richtlinie zu verwenden, ersetzen Sie jede *example resource placeholder* durch Ihre eigenen Informationen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:GetDocument",
"ssm:ListDocuments"
],
"Resource": [
"arn:aws:ssm:us-east-1:111122223333:document/SessionDocument-*"
]
}
]
}
```
------
**Anmerkung**
Die Session-Manager-Konsole unterstützt nur Sitzungsdokumente mit einem `sessionType` von `Standard_Stream`, die zur Definition von Sitzungseinstellungen verwendet werden. Weitere Informationen finden Sie unter [Schema des Sitzungsdokuments](session-manager-schema.md).
## Beispiel 2: Beschränken des Zugriffs auf bestimmte verwaltete Knoten
Sie können eine IAM-Richtlinie erstellen, die definiert, mit welchen verwalteten Knoten ein Benutzer mithilfe von Session Manager eine Verbindung herstellen darf. Die folgende Richtlinie gewährt einem Benutzer beispielsweise die Berechtigung, seine Sitzungen auf drei bestimmten Knoten zu starten, zu beenden und fortzusetzen. Die Richtlinie schränkt den Benutzer ein, eine Verbindung zu anderen als den angegebenen Knoten herzustellen.
**Anmerkung**
Informationen zu verbundenen Benutzern finden Sie unter [Beispiel 4: Benutzern erlauben, ausschließlich von ihnen gestartete Sitzungen zu beenden](#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}-*"]
}
]
}
```
------
## Beispiel 3: Beschränken des Zugriffs anhand von Tags
Sie können den Zugriff auf verwaltete Knoten anhand bestimmter Tags einschränken. Im folgenden Beispiel darf der Benutzer Sitzungen (`Effect: Allow, Action: ssm:StartSession, ssm:ResumeSession`) auf jedem verwalteten Knoten (`Resource: arn:aws:ec2:region:987654321098:instance/*`) starten und fortsetzen, vorausgesetzt, dass es sich bei dem Knoten um einen Finanzknoten WebServer (`ssm:resourceTag/Finance: WebServer`) handelt. Wenn der Benutzer einen Befehl an einen verwalteten Knoten sendet, der nicht markiert ist oder einen anderen Tag als `Finance: WebServer` hat, enthält das Befehlsergebnis `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"
]
}
]
}
```
------
Sie können IAM-Richtlinien erstellen, mit denen ein Benutzer Sitzungen mit verwalteten Knoten starten kann, die mit mehreren Tags markiert sind. Die folgende Richtlinie ermöglicht dem Benutzer das Starten von Sitzungen mit verwalteten Knoten, auf denen beide angegebenen Tags angewendet wurden. Wenn ein Benutzer einen Befehl an einen verwalteten Knoten sendet, der nicht mit beiden Tags markiert ist, enthält das Befehlsergebnis `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"
]
}
]
}
```
------
Weitere Informationen zum Erstellen von IAM-Richtlinien finden Sie unter [Verwaltete Richtlinien und eingebundene Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html) im *IAM-Benutzerhandbuch*. Weitere Informationen über das Markieren von verwalteten Knoten finden Sie unter [Markieren Ihrer Amazon-EC2-Ressourcen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) im *Benutzerhandbuch zu Amazon EC2* (Inhalt gilt für Windows- und Linux-verwaltete Knoten). Weitere Informationen zur Steigerung des Sicherheitsstatus in Bezug auf nicht autorisierte Befehle auf Root-Ebene auf Ihren verwalteten Knoten finden Sie unter [Einschränken des Zugriffs auf Befehle auf Stammebene durch SSM Agent](ssm-agent-restrict-root-level-commands.md)
## Beispiel 4: Benutzern erlauben, ausschließlich von ihnen gestartete Sitzungen zu beenden
Session Managerbietet zwei Methoden, um zu steuern, welche Sitzungen ein Verbundbenutzer in Ihrem AWS-Konto Netzwerk beenden darf.
+ Verwenden Sie die Variable `{aws:userid}` in einer AWS Identity and Access Management (IAM-) Berechtigungsrichtlinie. Verbundbenutzer können nur von ihnen gestartete Sitzungen beenden. Verwenden Sie für Benutzer ohne Verbundzugriff Methode 1. Verwenden Sie für Verbundbenutzer Methode 2.
+ Verwenden Sie Tags, die von AWS Tags in einer IAM-Berechtigungsrichtlinie bereitgestellt werden. Sie nehmen eine Bedingung in die Richtlinie auf, die es Benutzern erlaubt, nur Sitzungen zu beenden, die mit bestimmten Tags versehen sind, die von AWS bereitgestellt wurden. Diese Methode funktioniert für alle Konten, auch für Konten, die Verbundkonten verwenden, um Zugriff IDs zu gewähren. AWS
### Methode 1: Gewähren Sie TerminateSession Berechtigungen mithilfe der Variablen `{aws:username}`
Die folgende IAM-Richtlinie ermöglicht es einem Benutzer, alle Sitzungen in Ihrem Konto einzusehen. IDs Benutzer können jedoch nur über von ihnen gestartete Sitzungen mit verwalteten Knoten interagieren. Ein Benutzer, dem die folgende Richtlinie zugewiesen wurde, kann keine Verbindungen mit Sitzungen anderer Benutzer herstellen oder diese beenden. Die Richtlinie verwendet die Variable `{aws:username}`, um dies zu erreichen.
**Anmerkung**
Diese Methode funktioniert nicht für Konten, die Zugriff auf die AWS Nutzung von Federated IDs gewähren.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ssm:DescribeSessions"
],
"Effect": "Allow",
"Resource": [
"*"
]
},
{
"Action": [
"ssm:TerminateSession"
],
"Effect": "Allow",
"Resource": [
"arn:aws:ssm:*:*:session/${aws:username}-*"
]
}
]
}
```
------
### Methode 2: Gewähren Sie TerminateSession Berechtigungen mithilfe von Tags, die bereitgestellt werden von AWS
Sie können steuern, welche Sitzungen ein Benutzer beenden kann, indem Sie eine Bedingung mit bestimmten Tag-Schlüsselvariablen in einer IAM-Richtlinie verwenden. Die Bedingung gibt an, dass der Benutzer nur Sitzungen beenden kann, die mit einer oder beiden dieser spezifischen Tag-Schlüsselvariablen und einem angegebenen Wert gekennzeichnet sind.
Wenn ein Benutzer in Ihrem Umfeld eine Sitzung AWS-Konto startet, Session Manager wendet er der Sitzung zwei Ressourcen-Tags an. Das erste Ressourcen-Tag ist `aws:ssmmessages:target-id`, mit dem Sie die ID des Ziels angeben, das der Benutzer beenden darf. Das andere Ressourcen-Tag ist `aws:ssmmessages:session-id`, mit einem Wert im Format `role-id:caller-specified-role-name`.
**Anmerkung**
Session Manager unterstützt keine benutzerdefinierten Tags für diese IAM-Zugriffssteuerungsrichtlinie. Sie müssen die unten beschriebenen Resource-Tags verwenden AWS, die von bereitgestellt werden.
** `aws:ssmmessages:target-id` **
Mit diesem Tag-Schlüssel schließen Sie die ID des verwalteten Knotens als Wert in die Richtlinie ein. Im folgenden Richtlinienblock lässt die Bedingungsanweisung einen Benutzer nur den Knoten i-02573cafcfEXAMPLE beenden.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:target-id": [
"i-02573cafcfEXAMPLE"
]
}
}
}
]
}
```
Wenn der Benutzer versucht, eine Sitzung zu beenden, für die ihm diese `TerminateSession`-Berechtigung nicht erteilt wurde, wird eine `AccessDeniedException`-Fehlermeldung angezeigt.
** `aws:ssmmessages:session-id` **
Dieser Tag-Schlüssel enthält als Wert in der Anforderung zum Starten einer Sitzung eine Variable für die Sitzungs-ID.
Das folgende Beispiel zeigt eine Richtlinie für Fälle, in denen der Aufrufertyp `User` ist. Der Wert, für den Sie für `aws:ssmmessages:session-id` angeben, ist die ID des Benutzers. In diesem Beispiel stellt `AIDIODR4TAW7CSEXAMPLE` die ID eines Benutzers in Ihrem AWS-Konto dar. Um die ID für einen Benutzer in Ihrem abzurufen AWS-Konto, verwenden Sie den IAM-Befehl,`get-user`. Weitere Informationen finden Sie unter [get-user](https://docs.aws.amazon.com/IAM/latest/UserGuide/get-user.html) im AWS Identity and Access Management Abschnitt des *IAM-Benutzerhandbuchs*.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"AIDIODR4TAW7CSEXAMPLE"
]
}
}
}
]
}
```
Das folgende Beispiel zeigt eine Richtlinie für Fälle, in denen der Aufrufertyp `AssumedRole` ist. Sie können die Variable `{aws:userid}` für den Wert verwenden, den Sie für `aws:ssmmessages:session-id` angeben. Alternativ können Sie eine Rollen-ID für den Wert, den Sie für `aws:ssmmessages:session-id` angeben, fest codieren. Wenn Sie eine Rollen-ID fest codieren, müssen Sie den Wert im Format `role-id:caller-specified-role-name` angeben. Beispiel, `AIDIODR4TAW7CSEXAMPLE:MyRole`.
Damit System-Tags angewendet werden können, darf die von Ihnen bereitzustellende Rollen-ID nur folgende Zeichen enthalten: Unicode-Buchstaben, 0-9, Leerzeichen, `_`, `.`, `:`, `/`, `=`, `+`, `-`, `@` und `\`.
Verwenden Sie den Befehl, um die Rollen-ID für eine Rolle in Ihrem AWS-Konto abzurufen. `get-caller-identity` Weitere Informationen finden Sie [get-caller-identity](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html)in der AWS CLI Befehlsreferenz.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:TerminateSession"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:resourceTag/aws:ssmmessages:session-id": [
"${aws:userid}*"
]
}
}
}
]
}
```
Wenn ein Benutzer versucht, eine Sitzung zu beenden, für die ihm diese `TerminateSession`-Berechtigung nicht erteilt wurde, wird eine `AccessDeniedException`-Fehlermeldung angezeigt.
**`aws:ssmmessages:target-id`** und **`aws:ssmmessages:session-id`**
Sie können auch IAM-Richtlinien erstellen, die es einem Benutzer ermöglichen, Sitzungen zu beenden, die mit beiden System-Tags gekennzeichnet sind, wie in diesem Beispiel dargestellt.
****
```
{
"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}*"
]
}
}
}
]
}
```
## Beispiel 5: Benutzer erhalten vollständigen (administrativen) Zugriff auf alle Sitzungen
Die folgende IAM-Richtlinie ermöglicht Benutzern die vollständige Interaktion mit allen verwalteten Knoten und allen Sitzungen, die von allen Benutzern für alle Knoten erstellt wurden. Diese Berechtigung sollte nur einem Administrator gewährt werden, der vollständige Kontrolle über die Session Manager-Aktivitäten Ihrer Organisation benötigt.
------
#### [ 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}-*"]
}
]
}
```
------
# Schritt 4: Konfigurieren von Sitzungspräferenzen
Benutzer, denen in ihrer AWS Identity and Access Management (IAM-) Richtlinie Administratorberechtigungen gewährt wurden, können Sitzungseinstellungen konfigurieren, darunter die folgenden:
+ Aktivieren Sie den Run-As-Support für Linux-verwaltete Knoten. Dadurch ist es möglich, Sitzungen mit den Anmeldeinformationen eines bestimmten Betriebssystembenutzers zu starten, anstatt mit den Anmeldeinformationen eines vom System generierten `ssm-user` Kontos, das auf einem verwalteten AWS Systems Manager Session Manager Knoten erstellt werden kann.
+ Konfigurieren Sie Session Manager die Konfiguration so, dass AWS KMS key Verschlüsselung verwendet wird, um die zwischen Client-Computern und verwalteten Knoten übertragenen Daten zusätzlich zu schützen.
+ Konfigurieren Sie Session Manager die Konfiguration, um Sitzungsverlaufsprotokolle zu erstellen und an einen Amazon Simple Storage Service (Amazon S3) -Bucket oder eine Amazon CloudWatch Logs-Protokollgruppe zu senden. Die gespeicherten Protokolldaten können anschließend verwendet werden, um die Sitzungsverbindungen mit Ihren verwalteten Knoten und die auf diesen während der Sitzungen ausgeführten Befehle zu melden.
+ Konfigurieren Sie Sitzungs-Timeouts. Mit dieser Einstellung können Sie festlegen, wann eine Sitzung nach einem Zeitraum der Inaktivität beendet werden soll.
+ Konfigurieren Sie Session Manager so, dass es konfigurierbare Shell-Profile verwendet. Mit diesen anpassbaren Profilen können Sie Einstellungen in Sitzungen wie Shell-Einstellungen, Umgebungsvariablen, Arbeitsverzeichnissen und das Ausführen mehrerer Befehle definieren, wenn eine Sitzung gestartet wird.
Weitere Informationen zu den Berechtigungen, die zum Konfigurieren von Session Manager-Einstellungen erforderlich sind, finden Sie unter [Gewähren oder Verweigern von Benutzerberechtigungen zum Aktualisieren von Session Manager-Einstellungen](preference-setting-permissions.md).
**Topics**
+ [Gewähren oder Verweigern von Benutzerberechtigungen zum Aktualisieren von Session Manager-Einstellungen](preference-setting-permissions.md)
+ [Angeben eines Zeitüberschreitungswerts für Leerlaufsitzungen](session-preferences-timeout.md)
+ [Angeben der maximalen Sitzungsdauer](session-preferences-max-timeout.md)
+ [Konfigurierbare Shell-Profile zulassen](session-preferences-shell-config.md)
+ [Run-As-Support für Linux- und macOS-verwaltete Knoten einschalten](session-preferences-run-as.md)
+ [So aktivieren Sie die KMS-Schlüsselverschlüsselung von Sitzungsdaten (Konsole)](session-preferences-enable-encryption.md)
+ [Erstellen eines Dokuments mit Session Manager-Einstellungen (Befehlszeile)](getting-started-create-preferences-cli.md)
+ [Aktualisieren von Session Manager-Einstellungen (Befehlszeile)](getting-started-configure-preferences-cli.md)
Weitere Informationen zur Verwendung der Systems Manager-Konsole zum Konfigurieren von Optionen für die Protokollierung von Sitzungsdaten finden Sie in den folgenden Themen:
+ [Protokollieren von Sitzungsdaten mithilfe von Amazon S3 (Konsole)](session-manager-logging-s3.md)
+ [Streaming-Sitzungsdaten mit Amazon CloudWatch Logs (Konsole)](session-manager-logging-cwl-streaming.md)
+ [Protokollierung von Sitzungsdaten mit Amazon CloudWatch Logs (Konsole)](session-manager-logging-cloudwatch-logs.md)
# Gewähren oder Verweigern von Benutzerberechtigungen zum Aktualisieren von Session Manager-Einstellungen
Kontoeinstellungen werden jeweils AWS-Region als AWS Systems Manager (SSM-) Dokumente gespeichert. Bevor Benutzer die Kontoeinstellungen für Sitzungen in Ihrem Konto aktualisieren können, müssen ihnen die notwendigen Berechtigungen für den Zugriff auf die Art des SSM-Dokuments gewährt werden, in denen diese Einstellungen gespeichert werden. Diese Berechtigungen werden durch eine AWS Identity and Access Management (IAM-) Richtlinie gewährt.
**Administratorrichtlinie, die das Erstellen und Aktualisieren von Richtlinien zulässt**
Ein Administrator kann die folgende Richtlinie zum jederzeitigen Erstellen und Aktualisieren von Einstellungen besitzen. Die folgende Richtlinie gewährt die Berechtigung für Zugriff und Aktualisierung des Dokuments `SSM-SessionManagerRunShell` im Konto 123456789012 in der Region us-east-2.
------
#### [ 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"
]
}
]
}
```
------
**Benutzerrichtlinie, die das Aktualisieren von Einstellungen verhindert**
Mittels der folgenden Richtlinie verhindern Sie das Aktualisieren oder Überschreiben von Session Manager-Einstellungen durch Endbenutzer in Ihrem Konto.
------
#### [ 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"
]
}
]
}
```
------
# Angeben eines Zeitüberschreitungswerts für Leerlaufsitzungen
Session Manager, ein Tool in AWS Systems Manager, ermöglicht es Ihnen, den Zeitraum festzulegen, für den ein Benutzer inaktiv sein darf, bevor das System eine Sitzung beendet. Standardmäßig wird eine Sitzung nach 20 Minuten Inaktivität beendet. Sie können diese Einstellung ändern und eine Zeitüberschreitung zwischen 1 und 60 Minuten Inaktivität festlegen. Einige professionelle Agenturen für Computersicherheit empfehlen, Timeouts für inaktive Sitzungen auf maximal 15 Minuten festzulegen.
Der Timeout-Timer für inaktive Sitzungen wird zurückgesetzt, wenn clientseitige Eingaben Session Manager empfangen werden. Zu diesen Eingaben gehören, sind aber nicht beschränkt auf:
+ Tastatureingabe im Terminal
+ Ereignisse zur Größenänderung von Terminal- oder Browserfenstern
+ Wiederverbindung der Sitzung (ResumeSession), die aufgrund von Netzwerkunterbrechungen, der Verwaltung von Browser-Tabs oder Verbindungsabbrüchen auftreten kann WebSocket
Da bei diesen Ereignissen der Leerlauftimer zurückgesetzt wird, kann eine Sitzung auch ohne direkte Terminalbefehle länger als das konfigurierte Timeout aktiv bleiben.
Wenn Ihre Sicherheitsanforderungen unabhängig von der Aktivität strenge Beschränkungen für die Sitzungsdauer vorschreiben, verwenden Sie zusätzlich zum Timeout im Leerlauf die Einstellung *Maximale Sitzungsdauer*. Weitere Informationen finden Sie unter [Angeben der maximalen Sitzungsdauer](session-preferences-max-timeout.md).
**So lassen Sie Zeitüberschreitungen für Leerlaufsitzungen zu (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Präferenzen** und anschließend **Bearbeiten** aus.
1. Geben Sie im Feld **minutes** unter **Zeitüberschreitung bei Leerlaufsitzung** an, wie lange ein Benutzer inaktiv sein kann, bevor eine Sitzung beendet wird.
1. Wählen Sie **Speichern**.
# Angeben der maximalen Sitzungsdauer
Session Manager, ein Tool in AWS Systems Manager, ermöglicht es Ihnen, die maximale Dauer einer Sitzung festzulegen, bevor sie endet. Standardmäßig haben Sitzungen keine maximale Dauer. Der Wert, den Sie für die maximale Sitzungsdauer angeben, muss zwischen 1 und 1 440 Minuten liegen.
**So geben Sie die maximale Sitzungsdauer an (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Präferenzen** und anschließend **Bearbeiten** aus.
1. Aktivieren Sie das Kontrollkästchen neben **Enable maximum session duration** (Aktivieren der maximalen Sitzungsdauer).
1. Geben Sie die maximale Sitzungsdauer in dem Feld **minutes** (Minuten) unter **Maximum session duration** (Maximale Sitzungsdauer) an.
1. Wählen Sie **Speichern**.
# Konfigurierbare Shell-Profile zulassen
Standardmäßig starten Sitzungen auf EC2-Instances für Linux, die Bourne-Shell (sh) zu verwenden. Sie könnten jedoch eine andere Shell wie bash vorziehen. Indem Sie konfigurierbare Shell-Profile zulassen, können Sie Einstellungen in Sitzungen wie Shell-Einstellungen, Umgebungsvariablen, Arbeitsverzeichnissen und das Ausführen mehrerer Befehle anpassen, wenn eine Sitzung gestartet wird.
**Wichtig**
Systems Manager überprüft die Befehle oder Skripts in Ihrem Shell-Profil nicht, bevor sie ausgeführt werden, um zu sehen, welche Änderungen sie an einer Instance vornehmen würden. Um die Fähigkeit eines Benutzers, Befehle oder Skripte zu ändern, die in seinem Shell-Profil eingegeben wurden, einzuschränken, wird Folgendes empfohlen:
Erstellen Sie ein angepasstes Sitzungsdokument für Ihre AWS Identity and Access Management (IAM)-Benutzer und -Rollen. Ändern Sie dann die IAM-Richtlinie für diese Benutzer und Rollen so, dass die `StartSession` API-Operation nur das Sitzungstyp-Dokument verwenden kann, das Sie für sie erstellt haben. Weitere Informationen finden Sie unter [Erstellen eines Dokuments mit Session Manager-Einstellungen (Befehlszeile)](getting-started-create-preferences-cli.md) und [Kurzeinführung in Endbenutzerrichtlinien für Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user).
Ändern Sie die IAM-Richtlinie für Ihre IAM-Benutzer und -Rollen, um den Zugriff auf die `UpdateDocument` API-Operation für die von Ihnen erstellte Sitzungstyp-Dokumentressource zu verweigern. Auf diese Weise können Benutzer und Rollen das von Ihnen erstellte Dokument für ihre Sitzungseinstellungen verwenden, ohne dass sie die Einstellungen ändern können.
**So aktivieren Sie konfigurierbare Shell-Profile**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Präferenzen** und anschließend **Bearbeiten** aus.
1. Geben Sie die Umgebungsvariablen, Shell-Einstellungen oder Befehle, die beim Start der Sitzung ausgeführt werden sollen, in den Feldern der entsprechenden Betriebssysteme an.
1. Wählen Sie **Speichern**.
Im Folgenden sehen Sie einige Beispielbefehle, die Ihrem Shell-Profil hinzugefügt werden können.
Wechseln Sie zur bash-Shell und wechseln Sie in das Verzeichnis /usr auf Linux-Instances.
```
exec /bin/bash
cd /usr
```
Geben Sie einen Zeitstempel und eine Begrüßungsnachricht zu Beginn einer Sitzung aus.
------
#### [ 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."
```
------
Zeigen Sie die dynamische Systemaktivität zu Beginn einer Sitzung an.
------
#### [ 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 "------- ------ ----- ----- ----- ------ -- -----------"}
```
------
# Run-As-Support für Linux- und macOS-verwaltete Knoten einschalten
Standardmäßig authentifiziert Session Manager Verbindungen mit den Anmeldeinformationen des vom System generierten `ssm-user`-Kontos, das auf einem verwalteten Knoten erstellt wird. (Auf Linux- und macOS-Maschinen wird das Konto zu `/etc/sudoers/` hinzugefügt.) Wenn Sie möchten, können Sie Sitzungen stattdessen mit den Anmeldeinformationen eines Betriebssystem-Benutzerkontos (OS) oder eines Domainbenutzers für Instances authentifizieren, die einem Active Directory beigetreten sind. In diesem Fall überprüft Session Manager vor dem Starten der Sitzung, ob das von Ihnen angegebene Betriebssystemkonto auf dem Knoten oder in der Domain vorhanden ist. Wenn Sie versuchen, eine Sitzung mit einem Betriebssystemkonto zu starten, das auf dem Knoten oder in der Domain nicht vorhanden ist, schlägt die Verbindung fehl.
**Anmerkung**
Session Manager unterstützt nicht die Verwendung des `root`-Benutzerkontos eines Betriebssystems zur Authentifizierung von Verbindungen. Für Sitzungen, die mit einem Betriebssystem-Benutzerkonto authentifiziert werden, gelten die Betriebssystem- und Verzeichnisrichtlinien des Knotens, wie Anmeldeeinschränkungen oder Nutzungseinschränkungen für Systemressourcen, möglicherweise nicht.
**Funktionsweise**
Wenn Sie die Run As-Unterstützung für Sitzungen aktivieren, überprüft das System für Zugriffsberechtigungen wie folgt:
1. Wurde die IAM-Entität (Benutzer oder Rolle) des Benutzers, der die Sitzung startet, mit `SSMSessionRunAs = os user account name` gekennzeichnet?
Falls ja, ist der Betriebssystem-Benutzername auf dem verwalteten Knoten vorhanden? Wenn dies der Fall ist, wird die Sitzung gestartet. Wenn dies nicht der Fall ist, wird das Starten der Sitzung verboten.
Wenn die IAM-Entität *nicht* mit `SSMSessionRunAs = os user account name` gekennzeichnet wurde, fahren Sie mit Schritt 2 fort.
1. Wenn die IAM-Entität nicht markiert wurde`SSMSessionRunAs = os user account name`, wurde in den Session Manager Einstellungen von ein Betriebssystem-Benutzername angegeben? AWS-Konto
Falls ja, ist der Betriebssystem-Benutzername auf dem verwalteten Knoten vorhanden? Wenn dies der Fall ist, wird die Sitzung gestartet. Wenn dies nicht der Fall ist, wird das Starten der Sitzung verboten.
**Anmerkung**
Wenn Sie die Unterstützung „Ausführen als“ aktivieren, wird Session Manager daran gehindert, Sitzungen mit dem `ssm-user`-Konto auf einem verwalteten Knoten zu starten. Dies bedeutet, dass, wenn Session Manager die Verbindung nicht mithilfe des angegebenen Betriebssystem-Benutzerkontos herstellen kann, es nicht auf die Standardmethode zurückgreift.
Wenn Sie „Ausführen als“ aktivieren, ohne ein Betriebssystemkonto anzugeben oder eine IAM-Entität zu markieren, und Sie in den Session Manager-Einstellungen kein Betriebssystemkonto angegeben haben, schlagen Sitzungsverbindungsversuche fehl.
**So aktivieren Sie den Run-As-Support für Linux- und macOS-verwaltete Knoten**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Präferenzen** und anschließend **Bearbeiten** aus.
1. Aktivieren Sie das Kontrollkästchen neben **Run As-Unterstützung für Linux-Instances aktivieren**.
1. Führen Sie eine der folgenden Aktionen aus:
+ **Option 1**: Geben Sie im Feld **Benutzername des Betriebssystems** den Namen des Benutzerkontos des Betriebssystems auf dem verwalteten Zielknoten ein, den Sie zum Starten von Sitzungen verwenden möchten. Wenn Sie diese Option verwenden, werden alle Sitzungen von demselben Betriebssystembenutzer für alle Benutzer in Ihrem System ausgeführt AWS-Konto , die eine Verbindung herstellenSession Manager.
+ **Option 2** (Empfohlen): Wählen Sie den Link **IAM-Konsole öffnen** aus. Wählen Sie im Navigationsbereich eine der Optionen **Users (Benutzer)** oder **Roles (Rollen)**. Wählen Sie die Entität (Benutzer oder Rolle) aus, der Sie Tags hinzufügen möchten, und wählen Sie dann die Registerkarte **Tags**. Geben Sie `SSMSessionRunAs` als Schlüsselname ein. Geben Sie den Namen eines Betriebssystem-Benutzerkontos als den Schlüsselwert ein. Wählen Sie **Änderungen speichern ** aus.
Mit dieser Option können Sie bei Bedarf eindeutige Betriebssystembenutzer für verschiedene IAM-Entitäten angeben. Weitere Informationen zum Markieren von IAM-Ressourcen (Benutzer oder Rollen) finden Sie unter [Markieren von IAM-Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) im *IAM-Benutzerhandbuch*.
Im Folgenden wird ein -Beispiel gezeigt.
![\[Screenshot der Angabe von Tags für Session Manager Berechtigung „Run As“.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/ssn-run-as-tags.png)
1. Wählen Sie **Speichern**.
# So aktivieren Sie die KMS-Schlüsselverschlüsselung von Sitzungsdaten (Konsole)
Verwenden Sie AWS Key Management Service (AWS KMS), um Verschlüsselungsschlüssel zu erstellen und zu verwalten. Mit AWS KMS können Sie die Verwendung von Verschlüsselung in einer Vielzahl von AWS-Services und in Ihren Anwendungen steuern. Sie können angeben, dass Sitzungsdaten, die zwischen Ihren verwalteten Knoten und den lokalen Computern der Benutzer in Ihren AWS-Konto Knoten übertragen werden, mithilfe der KMS-Schlüsselverschlüsselung verschlüsselt werden. (Dies ist eine Ergänzung zur TLS 1.2/1.3-Verschlüsselung, die AWS bereits standardmäßig zur Verfügung steht.) Um Session Manager Sitzungsdaten zu verschlüsseln, erstellen Sie einen *symmetrischen* KMS-Schlüssel mit. AWS KMS
AWS KMS Verschlüsselung ist für die `Standard_Stream` `NonInteractiveCommands` Sitzungstypen`InteractiveCommands`, und verfügbar. Um die Option zum Verschlüsseln von Sitzungsdaten mit einem Schlüssel verwenden zu können AWS KMS, der in Version 2.3.539.0 oder höher von erstellt wurde, AWS Systems Manager SSM Agent muss auf dem verwalteten Knoten installiert sein.
**Anmerkung**
Sie müssen die AWS KMS Verschlüsselung zulassen, um Kennwörter auf Ihren verwalteten Knoten von der Konsole aus zurückzusetzen. AWS Systems Manager Weitere Informationen finden Sie unter [Zurücksetzen eines Passworts auf einem verwalteten Knoten](fleet-manager-reset-password.md#managed-instance-reset-a-password).
Sie können einen Schlüssel verwenden, den Sie in Ihrem erstellt haben AWS-Konto. Sie können jedoch auch einen Schlüssel verwenden, der in einem anderen AWS-Konto erstellt wurde. Der Ersteller des Schlüssels in einer anderen Datei AWS-Konto muss Ihnen die für die Verwendung des Schlüssels erforderlichen Berechtigungen zur Verfügung stellen.
Nachdem Sie die KMS-Schlüsselverschlüsselung für Ihre Sitzungsdaten aktiviert haben, müssen sowohl die Benutzer, die Sitzungen starten, als auch die verwalteten Knoten, mit denen sie verbunden sind, über die Berechtigung zur Verwendung des Schlüssels verfügen. Sie erteilen die Erlaubnis zur Verwendung des KMS-Schlüssels Session Manager mithilfe von AWS Identity and Access Management (IAM-) Richtlinien. Weitere Informationen finden Sie unter den folgenden Themen:
+ Fügen Sie AWS KMS Berechtigungen für Benutzer in Ihrem Konto hinzu:[Muster-IAM-Richtlinien für Session Manager](getting-started-restrict-access-quickstart.md).
+ Fügen Sie AWS KMS Berechtigungen für verwaltete Knoten in Ihrem Konto hinzu:[Schritt 2: Überprüfen oder Hinzufügen von Instance-Berechtigungen für Session Manager](session-manager-getting-started-instance-profile.md).
Weitere Informationen zum Erstellen und Verwalten von KMS-Schlüsseln finden Sie im [https://docs.aws.amazon.com/kms/latest/developerguide/](https://docs.aws.amazon.com/kms/latest/developerguide/).
Informationen zur Verwendung von AWS CLI , um die KMS-Schlüsselverschlüsselung von Sitzungsdaten in Ihrem Konto zu aktivieren, finden Sie unter [Erstellen eines Dokuments mit Session Manager-Einstellungen (Befehlszeile)](getting-started-create-preferences-cli.md) oder[Aktualisieren von Session Manager-Einstellungen (Befehlszeile)](getting-started-configure-preferences-cli.md).
**Anmerkung**
Es entstehen Kosten für die Verwendung von KMS-Schlüsseln. Weitere Informationen finden Sie unter [AWS Key Management Service -Preise](https://aws.amazon.com/kms/pricing/).
**So aktivieren Sie die KMS-Schlüsselverschlüsselung von Sitzungsdaten (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Präferenzen** und anschließend **Bearbeiten** aus.
1. Aktivieren Sie das Kontrollkästchen neben **Enable KMS encryption** (Aktivieren der KMS-Verschlüsselung).
1. Führen Sie eine der folgenden Aktionen aus:
+ Klicken Sie auf die Schaltfläche neben **Select a KMS key in my current account (Einen KMS-Schlüssel in meinem aktuellen Konto auswählen)** und wählen Sie anschließend einen Schlüssel aus der Liste aus.
–oder–
Wählen Sie die Schaltfläche neben **Enter a KMS key alias or KMS key ARN (Einen KMS-Schlüssel-Alias oder KMS-Schlüssel-ARN eingeben)** aus. Geben Sie manuell einen KMS-Schlüssel-Alias für einen Schlüssel ein, der in Ihrem aktuellen Konto erstellt wurde. Für einen Schlüssel in einem anderen Konto geben Sie den Amazon-Ressourcennamen (ARN) des Schlüssels ein. Im Folgenden sind einige Beispiele aufgeführt:
+ Schlüssel-Alias: `alias/my-kms-key-alias`
+ Schüssel-ARN: `arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-12345EXAMPLE`
–oder–
Wählen Sie **Create new key (Neuen Schlüssel erstellen)**, um einen neuen KMS-Schlüssel in Ihrem Konto zu erstellen. Nachdem Sie den neuen Schlüssel erstellt haben, kehren Sie zur Registerkarte **Preferences (Einstellungen)** zurück und wählen Sie den Schlüssel zum Verschlüsseln der Sitzungsdaten in Ihrem Konto aus.
Weitere Informationen zur gemeinsamen Nutzung von Schlüsseln finden Sie im *AWS Key Management Service Entwicklerhandbuch unter [AWS-Konten Erlauben des Zugriffs auf Schlüssel durch externe](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html#key-policy-modifying-external-accounts) Benutzer*.
1. Wählen Sie **Speichern**.
# Erstellen eines Dokuments mit Session Manager-Einstellungen (Befehlszeile)
Gehen Sie wie folgt vor, um SSM-Dokumente zu erstellen, die Ihre Einstellungen für AWS Systems Manager Session Manager Sitzungen definieren. Sie können das Dokument verwenden, um Sitzungsoptionen wie Datenverschlüsselung, Sitzungsdauer und Protokollierung zu konfigurieren. Sie können beispielsweise angeben, ob Sitzungsprotokolldaten in einem Amazon Simple Storage Service (Amazon S3) -Bucket oder einer Amazon CloudWatch Logs-Protokollgruppe gespeichert werden sollen. Sie können Dokumente erstellen, die allgemeine Einstellungen für alle Sitzungen für ein AWS-Konto und AWS-Region oder Einstellungen für einzelne Sitzungen definieren.
**Anmerkung**
Sie können die allgemeinen Sitzungseinstellungen auch über die Session-Manager-Konsole konfigurieren.
Dokumente, die zum Einstellen von Session-Manager-Einstellungen verwendet werden, müssen einen `sessionType` von `Standard_Stream` haben. Weitere Informationen zu Sitzungs-Dokumenten finden Sie unter [Schema des Sitzungsdokuments](session-manager-schema.md).
Weitere Informationen zur Verwendung der Befehlszeile zum Aktualisieren vorhandener Session Manager-Einstellungen finden Sie unter [Aktualisieren von Session Manager-Einstellungen (Befehlszeile)](getting-started-configure-preferences-cli.md).
Ein Beispiel für die Erstellung von Sitzungseinstellungen mit CloudFormation finden Sie unter [Erstellen eines Systems Manager Manager-Dokuments für Session Manager Einstellungen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-document.html#aws-resource-ssm-document--examples) im *AWS CloudFormation Benutzerhandbuch*.
**Anmerkung**
In diesem Verfahren wird beschrieben, wie Dokumente für die Festlegung von Session Manager Einstellungen auf der AWS-Konto Ebene erstellt werden. Um Dokumente zu erstellen, die für die Festlegung von Einstellungen auf Sitzungsebene verwendet werden, geben Sie einen anderen Wert als `SSM-SessionManagerRunShell` für die dateibezogenen Befehlseingaben an.
Wenn Sie Ihr Dokument verwenden möchten, um Einstellungen für Sitzungen festzulegen, die mit der AWS Command Line Interface (AWS CLI) gestartet wurden, geben Sie den Dokumentnamen als `--document-name`-Parameterwert an. Um Einstellungen für Sitzungen vorzunehmen, die von der Session-Manager-Konsole aus gestartet werden, können Sie den Namen Ihres Dokuments eingeben oder aus einer Liste auswählen.
**So erstellen Sie Session Manager-Einstellungen (Befehlszeile)**
1. Erstellen Sie eine JSON-Datei auf Ihrem lokalen Computer und geben Sie Ihr beispielsweise einen Namen wie `SessionManagerRunShell.json`. Fügen Sie der Datei anschließend den folgenden Inhalt ein.
```
{
"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"
}
}
}
```
Sie können Werte auch mithilfe von Parametern an Ihre Sitzungseinstellungen übergeben, anstatt die Werte fest zu kodieren, wie im folgenden Beispiel gezeigt.
```
{
"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. Legen Sie fest, wohin Sie die Sitzungsdaten senden möchten. Sie können einen S3-Bucket-Namen (mit optionalem Präfix) oder einen CloudWatch Logs-Log-Gruppennamen angeben. Wenn Sie die Daten zwischen dem lokalen Client und den verwalteten Knoten weiter verschlüsseln möchten, geben Sie den KMS-Schlüssel ein, der für die Verschlüsselung verwendet werden soll. Im Folgenden wird ein -Beispiel gezeigt.
```
{
"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"
}
}
}
```
**Anmerkung**
Wenn Sie die Protokolldaten der Sitzung nicht verschlüsseln möchten, ändern Sie für `s3EncryptionEnabled` `true` in `false`.
Wenn Sie keine Protokolle an einen Amazon S3 S3-Bucket oder eine CloudWatch Logs-Protokollgruppe senden, aktive Sitzungsdaten nicht verschlüsseln oder die Unterstützung „Als ausführen“ für die Sitzungen in Ihrem Konto nicht aktivieren möchten, können Sie die Zeilen für diese Optionen löschen. Überprüfen Sie, dass die letzte Zeile im Abschnitt `inputs` nicht mit einem Komma endet.
Wenn Sie eine KMS-Schlüssel-ID zum Verschlüsseln Ihrer Sitzungsdaten hinzufügen, müssen sowohl die Benutzer, die die Sitzungen starten, als auch die verwalteten Knoten, mit denen sie sich verbinden, über die Berechtigung zur Verwendung des Schlüssels verfügen. Sie erteilen die Berechtigung zur Verwendung des KMS-Schlüssels mit Session Manager anhand von IAM-Richtlinien. Weitere Informationen finden Sie unter den folgenden Themen:
Fügen Sie AWS KMS Berechtigungen für Benutzer in Ihrem Konto hinzu: [Muster-IAM-Richtlinien für Session Manager](getting-started-restrict-access-quickstart.md)
Fügen Sie AWS KMS Berechtigungen für verwaltete Knoten in Ihrem Konto hinzu: [Schritt 2: Überprüfen oder Hinzufügen von Instance-Berechtigungen für Session Manager](session-manager-getting-started-instance-profile.md)
1. Speichern Sie die Datei.
1. Führen Sie in dem Verzeichnis, in dem Sie die JSON-Datei erstellt haben, den folgenden Befehl aus.
------
#### [ 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
```
------
Bei erfolgreicher Ausführung gibt der Befehl eine Ausgabe zurück, die in etwa wie folgt aussieht:
```
{
"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"
}
}
```
# Aktualisieren von Session Manager-Einstellungen (Befehlszeile)
Das folgende Verfahren beschreibt, wie Sie Ihr bevorzugtes Befehlszeilentool verwenden, um Änderungen an den AWS Systems Manager Session Manager Einstellungen für Ihr AWS-Konto ausgewähltes Konto vorzunehmen AWS-Region. Verwenden Sie Session Manager Einstellungen, um Optionen für die Protokollierung von Sitzungsdaten in einem Amazon Simple Storage Service (Amazon S3) -Bucket oder einer Amazon CloudWatch Logs-Protokollgruppe festzulegen. Mithilfe der Session Manager-Einstellungen können Sie zudem Ihre Sitzungsdaten verschlüsseln.
**So aktualisieren Sie Session Manager-Einstellungen (Befehlszeile)**
1. Erstellen Sie eine JSON-Datei auf Ihrem lokalen Computer und geben Sie Ihr beispielsweise einen Namen wie `SessionManagerRunShell.json`. Fügen Sie der Datei anschließend den folgenden Inhalt ein.
```
{
"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. Legen Sie fest, wohin Sie die Sitzungsdaten senden möchten. Sie können einen S3-Bucket-Namen (mit einem optionalen Präfix) oder einen CloudWatch Logs-Protokollgruppennamen angeben. Wenn Sie Daten zwischen dem lokalen Client und den verwalteten Knoten weiter verschlüsseln möchten, geben Sie den für die Verschlüsselung AWS KMS key zu verwendenden Knoten an. Im Folgenden wird ein -Beispiel gezeigt.
```
{
"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"
}
}
}
```
**Anmerkung**
Wenn Sie die Protokolldaten der Sitzung nicht verschlüsseln möchten, ändern Sie für `s3EncryptionEnabled` `true` in `false`.
Wenn Sie keine Protokolle an einen Amazon S3 S3-Bucket oder eine CloudWatch Logs-Protokollgruppe senden, aktive Sitzungsdaten nicht verschlüsseln oder die Unterstützung „Als ausführen“ für die Sitzungen in Ihrem Konto nicht aktivieren möchten, können Sie die Zeilen für diese Optionen löschen. Überprüfen Sie, dass die letzte Zeile im Abschnitt `inputs` nicht mit einem Komma endet.
Wenn Sie eine KMS-Schlüssel-ID zum Verschlüsseln Ihrer Sitzungsdaten hinzufügen, müssen sowohl die Benutzer, die die Sitzungen starten, als auch die verwalteten Knoten, mit denen sie sich verbinden, über die Berechtigung zur Verwendung des Schlüssels verfügen. Sie erteilen die Erlaubnis, den KMS-Schlüssel Session Manager mithilfe von AWS Identity and Access Management (IAM) -Richtlinien zu verwenden. Weitere Informationen finden Sie unter den folgenden Themen:
Fügen Sie AWS KMS Berechtigungen für Benutzer in Ihrem Konto hinzu:[Muster-IAM-Richtlinien für Session Manager](getting-started-restrict-access-quickstart.md).
Fügen Sie AWS KMS Berechtigungen für verwaltete Knoten in Ihrem Konto hinzu:[Schritt 2: Überprüfen oder Hinzufügen von Instance-Berechtigungen für Session Manager](session-manager-getting-started-instance-profile.md).
1. Speichern Sie die Datei.
1. Führen Sie in dem Verzeichnis, in dem Sie die JSON-Datei erstellt haben, den folgenden Befehl aus.
------
#### [ 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'
```
------
Bei erfolgreicher Ausführung gibt der Befehl eine Ausgabe zurück, die in etwa wie folgt aussieht:
```
{
"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"
}
}
```
# Schritt 5: (Optional) Beschränken des Zugriffs auf Befehle in einer Sitzung
Sie können die Befehle einschränken, die ein Benutzer in einer AWS Systems Manager Session Manager Sitzung ausführen kann, indem Sie ein Dokument mit benutzerdefiniertem `Session` Typ AWS Systems Manager (SSM) verwenden. In dem Dokument definieren Sie den Befehl, der ausgeführt wird, wenn der Benutzer eine Sitzung startet, und die Parameter, die der Benutzer dem Befehl übergeben kann. Die `Session` des `schemaVersion`-Dokuments muss 1.0 und der `sessionType` des Dokuments muss `InteractiveCommands` lauten. Anschließend können Sie AWS Identity and Access Management (IAM)-Richtlinien erstellen, die es den Benutzern ermöglichen, nur auf die von Ihnen definierten `Session`-Dokumente zuzugreifen. Weitere Informationen zur Verwendung von IAM-Richtlinien zum Beschränken des Zugriffs auf Befehle in einer Sitzung finden Sie unter [IAM-Richtlinienbeispiele für interaktive Befehle](#interactive-command-policy-examples).
Dokumente mit dem Zeichen `sessionType` von `InteractiveCommands` werden nur für Sitzungen unterstützt, die mit AWS Command Line Interface (AWS CLI) gestartet wurden. Der Benutzer gibt den Namen des benutzerdefinierten Dokuments als `--document-name`-Parameterwert an und gibt alle Befehlsparameterwerte über die Option `--parameters` an. Weitere Informationen zur Ausführung interaktiver Befehle finden Sie unter [Starten einer Sitzung (interaktive und nicht interaktive Befehle)](session-manager-working-with-sessions-start.md#sessions-start-interactive-commands).
Gehen Sie wie folgt vor, um ein SSM-Dokument vom benutzerdefinierten Typ `Session` zu erstellen, das den Befehl definiert, den ein Benutzer ausführen darf.
## Beschränken des Zugriffs auf Befehle in einer Sitzung (Konsole)
**So beschränken Sie die Befehle, die ein Benutzer in einer Session Manager-Sitzung ausführen kann (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich die Option **Dokumente** aus.
1. Wählen Sie **Create command or session (Befehl oder Sitzung erstellen)** aus.
1. Geben Sie unter **Name** einen aussagekräftigen Namen für das Dokument ein.
1. Wählen Sie für **Document type (Dokumenttyp)** die Option **Session document (Sitzungsdokument)** aus.
1. Geben Sie mithilfe von JSON oder YAML Ihren Dokumentinhalt ein, der den Befehl definiert, den ein Benutzer in einer Session Manager-Sitzung ausführen kann, wie im folgenden Beispiel gezeigt.
------
#### [ 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. Wählen Sie **Create document** (Dokument erstellen) aus.
## Beschränken des Zugriffs auf Befehle in einer Sitzung (Befehlszeile)
**Bevor Sie beginnen**
Falls Sie es noch nicht getan haben, installieren und konfigurieren Sie die AWS Command Line Interface (AWS CLI) oder die AWS -Tools für PowerShell. Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) und [Installieren des AWS -Tools für PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
**So beschränken Sie die Befehle, die ein Benutzer in einer Session Manager-Sitzung ausführen kann (Befehlszeile)**
1. Erstellen Sie eine JSON- oder YAML-Datei für Ihren Dokumentinhalt, der den Befehl definiert, den ein Benutzer in einer Session Manager-Sitzung ausführen kann, wie im folgenden Beispiel gezeigt.
------
#### [ 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. Führen Sie die folgenden Befehle aus, um ein SSM-Dokument unter Verwendung Ihres Inhalts zu erstellen, der den Befehl definiert, den ein Benutzer in einer Session Manager-Sitzung ausführen kann.
------
#### [ 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"
```
------
## Interaktive Befehlsparameter und AWS CLI
Sie können interaktive Befehlsparameter bereitstellen, wenn Sie die AWS CLI verwenden. Je nach Betriebssystem (OS) Ihres Client-Computers, mit dem Sie eine Verbindung zu verwalteten Knoten herstellen, kann die Syntax AWS CLI, die Sie für Befehle angeben, die Sonder- oder Escape-Zeichen enthalten, unterschiedlich sein. Die folgenden Beispiele zeigen einige der verschiedenen Möglichkeiten, wie Sie Befehlsparameter angeben können, wenn Sie die verwenden AWS CLI, und wie mit Sonder- oder Escape-Zeichen umgegangen wird.
Auf Parameter, die in gespeichert sind, Parameter Store kann in den AWS CLI Befehlsparametern verwiesen werden, wie im folgenden Beispiel gezeigt.
------
#### [ 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}}"]}'
```
------
Das folgende Beispiel zeigt, wie Sie mit der AWS CLI eine Kurzschriftsyntax verwenden, um Parameter zu übergeben.
------
#### [ 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"
```
------
Sie können auch optionale Parameter in JSON angeben, wie im folgenden Beispiel dargestellt.
------
#### [ 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"]}'
```
------
Parameter können auch in einer JSON-Datei gespeichert und für die bereitgestellt werden, AWS CLI wie im folgenden Beispiel gezeigt. Weitere Informationen zur Verwendung von AWS CLI -Parametern aus einer Datei finden Sie unter [Laden von AWS CLI -Parametern aus einer Datei](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-file.html) im *AWS Command Line Interface -Benutzerhandbuch*.
```
{
"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
```
------
Sie können auch ein AWS CLI Skelett aus einer JSON-Eingabedatei generieren, wie im folgenden Beispiel gezeigt. *Weitere Informationen zum Generieren von AWS CLI Skeletten aus JSON-Eingabedateien finden Sie im Benutzerhandbuch unter [Generieren von AWS CLI Skeletten und Eingabeparametern aus einer JSON- oder YAML-Eingabedatei](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-skeleton.html).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
```
------
Um Zeichen in Anführungszeichen zu maskieren, müssen Sie den Escapezeichen zusätzliche umgekehrte Schrägstriche hinzufügen, wie im folgenden Beispiel gezeigt.
------
#### [ 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\""]}'
```
------
Informationen zum Verwenden von Anführungszeichen bei Befehlsparametern in AWS CLI finden Sie unter [Verwenden von Anführungszeichen mit Zeichenfolgen in der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/;cli-usage-parameters-quoting-strings.html) im *AWS Command Line Interface -Benutzerhandbuch*.
## IAM-Richtlinienbeispiele für interaktive Befehle
Sie können IAM-Richtlinien erstellen, mit denen Benutzer nur auf die von Ihnen definierten `Session`-Dokumente zugreifen können. Dadurch werden die Befehle, die ein Benutzer in einer Session Manager-Sitzung ausführen kann, nur auf die Befehle beschränkt, die in Ihren benutzerdefinierten SSM-Dokumenten vom Typ `Session` definiert sind.
**Einem Benutzer erlauben, einen interaktiven Befehl auf einem einzelnen verwalteten Knoten auszuführen**
****
```
{
"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}-*"]
}
]
}
```
**Einem Benutzer erlauben, einen interaktiven Befehl auf allen verwalteten Knoten auszuführen**
****
```
{
"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}-*"]
}
]
}
```
**Einem Benutzer erlauben, mehrere interaktive Befehle auf allen verwalteten Knoten auszuführen**
****
```
{
"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}-*"]
}
]
}
```
# Schritt 6: (Optional) Verwenden Sie diese Option AWS PrivateLink , um einen VPC-Endpunkt einzurichten für Session Manager
Sie können den Sicherheitsstatus Ihrer verwalteten Knoten weiter verbessern, indem Sie AWS Systems Manager zum Verwenden eines Virtual Private Cloud (VPC)-Schnittstellenendpunkts konfigurieren. Schnittstellenendpunkte werden von einer Technologie unterstützt AWS PrivateLink, mit der Sie über private IP-Adressen privat auf Amazon Elastic Compute Cloud (Amazon EC2) und Systems Manager APIs zugreifen können.
AWS PrivateLink schränkt den gesamten Netzwerkverkehr zwischen Ihren verwalteten Knoten, Systems Manager und Amazon EC2 auf das Amazon-Netzwerk ein. (Verwaltete Knoten haben keinen Zugriff auf das Internet.) Zudem benötigen Sie kein Internet-Gateway, kein NAT-Gerät und kein Virtual Private Gateway.
Informationen zum Erstellen eines VPC-Endpunkts finden Sie unter [Die Sicherheit von EC2-Instances mithilfe von VPC-Endpunkten verbessern](setup-create-vpc.md) für Systems Manager.
Die Alternative zur Verwendung eines VPC-Endpunkts ist das Erlauben von ausgehendem Internetzugriff auf Ihre verwalteten Knoten. In diesem Fall müssen die verwalteten Knoten auch ausgehenden HTTPS-Datenverkehr (Port 443) zu den folgenden Endpunkten erlauben:
+ `ec2messages.region.amazonaws.com`
+ `ssm.region.amazonaws.com`
+ `ssmmessages.region.amazonaws.com`
Systems Manager verwendet `ssmmessages.region.amazonaws.com`, den letzten dieser Endpunkte, über den Sie Anrufe von SSM Agent auf den Session Manager-Service in der Cloud tätigen können.
Um optionale Funktionen wie AWS Key Management Service (AWS KMS) -Verschlüsselung, das Streamen von Protokollen an Amazon CloudWatch Logs (CloudWatch Logs) und das Senden von Protokollen an Amazon Simple Storage Service (Amazon S3) zu nutzen, müssen Sie ausgehenden HTTPS-Verkehr (Port 443) zu den folgenden Endpunkten zulassen:
+ `kms.region.amazonaws.com`
+ `logs.region.amazonaws.com`
+ `s3.region.amazonaws.com`
Weitere Informationen zu erforderlichen Endpunkten für Systems Manager finden Sie unter [Referenz: ec2messages, ssmmessages und andere API-Operationen](systems-manager-setting-up-messageAPIs.md).
# Schritt 7: (Optional) Deaktivieren oder Aktivieren der Administratorberechtigungen für das SSM-Benutzerkonto
Ab Version 2.3.50.0 von AWS Systems Manager SSM Agent erstellt der Agent ein lokales Benutzerkonto mit dem Namen `ssm-user` und fügt es der Administratorgruppe `/etc/sudoers` (LinuxundmacOS) oder der Administratorgruppe (Windows) hinzu. Auf Agenten-Versionen vor 2.3.612.0 wird das Konto beim ersten Start bzw. Neustart des SSM Agent nach der Installation erstellt. Auf Version 2.3.612.0 und höher wird das `ssm-user`-Konto beim ersten Start einer Sitzung auf einem Knoten erstellt. Dies `ssm-user` ist der Standardbenutzer des Betriebssystems (OS), wenn eine AWS Systems Manager Session Manager Sitzung gestartet wird. SSM AgentVersion 2.3.612.0 wurde am 8. Mai 2019 veröffentlicht.
Wenn Sie verhindern möchten, dass Session Manager-Benutzer administrative Befehle auf einem Knoten ausführen, können Sie ihre `ssm-user`-Kontoberechtigungen aktualisieren. Sie können diese Berechtigungen wiederherstellen, nachdem sie entfernt wurden.
**Topics**
+ [Verwalten von sudo-Berechtigungen für ssm-user-Konten in Linux und macOS](#ssm-user-permissions-linux)
+ [Verwalten von Administratorberechtigungen für das Konto ssm-user in Windows Server](#ssm-user-permissions-windows)
## Verwalten von sudo-Berechtigungen für ssm-user-Konten in Linux und macOS
Mit den folgenden Verfahren können Sie die sudo-Berechtigungen von ssm-Benutzerkonten auf Linux- und macOS-verwalteten Knoten aktivieren oder deaktivieren.
**Verwenden von Run Command zum Ändern von sudo-Berechtigungen für ssm-user (Konsole)**
+ Verwenden Sie die Prozedur in [Ausführen von Befehlen über die Konsole](running-commands-console.md) mit den folgenden Werten:
+ Wählen Sie unter **Command document (Befehlsdokument)** die Option `AWS-RunShellScript` aus.
+ Um den sudo-Zugriff zu entfernen, fügen Sie im Bereich **Command parameters (Befehlsparameter)** Folgendes in das Feld **Commands (Befehle)** ein.
```
cd /etc/sudoers.d
echo "#User rules for ssm-user" > ssm-agent-users
```
–oder–
Um den sudo-Zugriff wiederherzustellen, fügen Sie im Bereich **Command parameters (Befehlsparameter)** Folgendes in das Feld **Commands (Befehle)** ein.
```
cd /etc/sudoers.d
echo "ssm-user ALL=(ALL) NOPASSWD:ALL" > ssm-agent-users
```
**Verwenden der Befehlszeile zum Ändern von sudo-Berechtigungen für ssm-user (AWS CLI)**
1. Stellen Sie eine Verbindung zum verwalteten Knoten her und führen Sie den folgenden Befehl aus.
```
sudo -s
```
1. Ändern Sie den Arbeitsordner mit dem folgenden Befehl.
```
cd /etc/sudoers.d
```
1. Öffnen Sie die Datei mit dem Namen `ssm-agent-users`, um sie zu bearbeiten.
1. Um den sudo-Zugriff zu entfernen, löschen Sie die folgende Zeile.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
–oder–
Um den sudo-Zugriff wiederherzustellen, fügen Sie die folgende Zeile hinzu.
```
ssm-user ALL=(ALL) NOPASSWD:ALL
```
1. Speichern Sie die Datei.
## Verwalten von Administratorberechtigungen für das Konto ssm-user in Windows Server
Mit den folgenden Verfahren können Sie die Administratorberechtigungen von ssm-user-Konten auf von Windows Server verwalteten Knoten aktivieren oder deaktivieren.
**Verwenden von Run Command zum Ändern von Administratorberechtigungen (Konsole)**
+ Verwenden Sie die Prozedur in [Ausführen von Befehlen über die Konsole](running-commands-console.md) mit den folgenden Werten:
Wählen Sie unter **Command document (Befehlsdokument)** die Option `AWS-RunPowerShellScript` aus.
Um den administrativen Zugriff zu entfernen, fügen Sie im Bereich **Command parameters (Befehlsparameter)** Folgendes in das Feld **Commands (Befehle)** ein.
```
net localgroup "Administrators" "ssm-user" /delete
```
–oder–
Um den administrativen Zugriff wiederherzustellen, fügen Sie im Bereich **Command parameters (Befehlsparameter)** Folgendes in das Feld **Commands (Befehle)** ein.
```
net localgroup "Administrators" "ssm-user" /add
```
**Verwenden des PowerShell- oder Eingabeaufforderungs-Fensters zum Ändern von Administratorberechtigungen**
1. Stellen Sie eine Verbindung mit dem verwalteten Knoten her und öffnen Sie das PowerShell- oder Eingabeaufforderungsfenster.
1. Um den administrativen Zugriff zu entfernen, führen Sie den folgenden Befehl aus.
```
net localgroup "Administrators" "ssm-user" /delete
```
–oder–
Um den administrativen Zugriff wiederherzustellen, führen Sie den folgenden Befehl aus.
```
net localgroup "Administrators" "ssm-user" /add
```
**Verwenden Sie die Windows-Konsole, um die Berechtigungen für Administratoren zu ändern**
1. Stellen Sie eine Verbindung mit dem verwalteten Knoten her und öffnen Sie das PowerShell- oder Eingabeaufforderungsfenster.
1. Führen Sie in der Befehlszeile `lusrmgr.msc` aus, um die Konsole **Local Users and Groups (Lokale Benutzer und Gruppen)** zu öffnen.
1. Öffnen Sie das Verzeichnis **Benutzer** und dann **ssm-user**.
1. Führen Sie auf der Registerkarte **Member Of (Mitglied von)** einen der folgenden Schritte aus:
+ Um den administrativen Zugriff zu entfernen, wählen Sie **Administrators (Administratoren)** und dann **Remove (Entfernen)** aus.
–oder–
Um den administrativen Zugriff wiederherzustellen, geben Sie **Administrators** in das Textfeld ein und klicken dann auf **Add (Hinzufügen)**.
1. Wählen Sie **OK** aus.
# Schritt 8: (Optional) Berechtigungen für SSH-Verbindungen über Session Manager zulassen und steuern
Sie können Benutzern in Ihrem Konto erlauben AWS-Konto , mithilfe von AWS Command Line Interface (AWS CLI) Secure Shell (SSH) -Verbindungen zu verwalteten Knoten herzustellen. AWS Systems Manager Session Manager Benutzer, die eine Verbindung über SSH herstellen, können auch mit dem Secure Copy Protocol (SCP) Dateien zwischen ihren lokalen Maschinen und verwalteten Knoten kopieren. Sie können diese Funktionalität verwenden, um eine Verbindung zu verwalteten Knoten herzustellen, ohne eingehende Ports öffnen oder Bastion-Hosts pflegen zu müssen.
Wenn Sie SSH-Verbindungen überSession Manager, AWS CLI und SSM Agent stellen Sie sichere WebSocket Verbindungen über TLS zu Session Manager Endpunkten her. Die SSH-Sitzung läuft innerhalb dieses verschlüsselten Tunnels und bietet so eine zusätzliche Sicherheitsebene, ohne dass eingehende Ports auf Ihren verwalteten Knoten geöffnet werden müssen.
Nachdem Sie SSH-Verbindungen zugelassen haben, können Sie AWS Identity and Access Management (IAM-) Richtlinien verwenden, um Benutzern, Gruppen oder Rollen das Herstellen von SSH-Verbindungen explizit zu gestatten oder zu verweigern. Session Manager
**Anmerkung**
Protokollieren ist für Session Manager-Sitzungen, die eine Verbindung über Port-Weiterleitung oder SSH herstellen, nicht verfügbar. Das liegt daran, dass SSH alle Sitzungsdaten innerhalb der sicheren TLS-Verbindung zwischen den Endpunkten AWS CLI und Session Manager Endpunkten verschlüsselt und Session Manager nur als Tunnel für SSH-Verbindungen dient.
**Topics**
+ [Zulassen von SSH-Verbindungen für Session Manager](#ssh-connections-enable)
+ [Steuern von Benutzerberechtigungen für SSH-Verbindungen über Session Manager](#ssh-connections-permissions)
## Zulassen von SSH-Verbindungen für Session Manager
Gehen Sie wie folgt vor, um über Session Manager SSH-Verbindungen für einen verwalteten Knoten zuzulassen.
**Um SSH-Verbindungen für Session Manager zuzulassen**
1. Gehen Sie auf dem verwalteten Knoten, zu dem Sie SSH-Verbindungen erlauben möchten, wie folgt vor:
+ Stellen Sie sicher, dass SSH auf dem verwalteten Knoten ausgeführt wird. (Sie können eingehende Ports für den Knoten schließen.)
+ Stellen Sie sicher, dass SSM Agent Version 2.3.672.0 oder höher auf dem verwalteten Knoten installiert ist.
Weitere Informationen zum Installieren oder Aktualisieren von SSM Agent auf einem verwalteten Knoten finden Sie in den folgenden Themen:
+ [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für Windows Server](manually-install-ssm-agent-windows.md).
+ [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für Linux](manually-install-ssm-agent-linux.md)
+ [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für macOS](manually-install-ssm-agent-macos.md)
+ [So installieren Sie den SSM Agent in Hybrid-Windows-Knoten](hybrid-multicloud-ssm-agent-install-windows.md)
+ [So installieren Sie den SSM Agent in Hybrid-Linux-Knoten](hybrid-multicloud-ssm-agent-install-linux.md)
**Anmerkung**
Für die Verwendung Session Manager mit lokalen Servern, Edge-Geräten und virtuellen Maschinen (VMs), die Sie als verwaltete Knoten aktiviert haben, müssen Sie die Stufe „Advanced-Instances“ verwenden. Weitere Informationen über erweiterte Instances finden Sie unter [Konfigurieren von Instance-Kontingenten](fleet-manager-configure-instance-tiers.md).
1. Gehen Sie auf der lokalen Maschine, mit der Sie mit SSH eine Verbindung zu einem verwalteten Knoten herstellen möchten, wie folgt vor:
+ Stellen Sie sicher, dass Version 1.1.23.0 oder höher des Session Manager-Plugin installiert ist.
Weitere Informationen zur Installation des Session Manager-Plugins finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md).
+ Aktualisieren Sie die SSH-Konfigurationsdatei so, dass ein Proxy-Befehl ausgeführt wird, der eine Session Manager-Sitzung startet und alle Daten über die Verbindung überträgt.
**Linux und macOS**
**Tipp**
Die SSH-Konfigurationsdatei befindet sich in der Regel unter `~/.ssh/config`.
Fügen Sie der Konfigurationsdatei auf dem lokalen Computer den folgenden Code hinzu.
```
# 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 **
**Tipp**
Die SSH-Konfigurationsdatei befindet sich in der Regel unter `C:\Users\\.ssh\config`.
Fügen Sie der Konfigurationsdatei auf dem lokalen Computer den folgenden Code hinzu.
```
# 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"
```
+ Erstellen ein Privacy-Enhanced-Mail-Zertifikat (eine PEM-Datei) oder mindestens einen öffentlichen Schlüssel, bzw. überprüfen Sie, ob sie darüber verfügen, die beim Herstellen von Verbindungen zu verwalteten Knoten verwendet werden sollen. Dies muss ein Schlüssel sein, der dem verwalteten Knoten bereits zugeordnet ist. Die Berechtigungen für Ihre private Schlüsseldatei müssen so festgelegt sein, dass nur Sie diese lesen können. Mit dem folgenden Befehl können Sie die Berechtigungen für Ihre private Schlüsseldatei so festlegen, dass nur Sie diese lesen können.
```
chmod 400 .pem
```
Für eine Amazon Elastic Compute Cloud (Amazon EC2)-Instance kann dies beispielsweise die Schlüsselpaardatei sein, die Sie beim Erstellen der Instance erstellt oder ausgewählt haben. (Sie geben den Pfad zum Zertifikat oder Schlüssel als Teil des Befehls zum Starten einer Sitzung an. Informationen zum Starten einer Sitzung mithilfe von SSH finden Sie unter [Starten einer Sitzung (SSH)](session-manager-working-with-sessions-start.md#sessions-start-ssh).)
## Steuern von Benutzerberechtigungen für SSH-Verbindungen über Session Manager
Nachdem Sie SSH-Verbindungen über Session Manager auf einem verwalteten Knoten aktiviert haben, können Sie IAM-Richtlinien verwenden, um Benutzern, Gruppen oder Rollen zu erlauben oder zu verweigern, SSH-Verbindungen über Session Manager herzustellen.
**So verwenden Sie eine IAM-Richtlinie, um SSH-Verbindungen über Session Manager zu erlauben**
+ Wählen Sie eine der folgenden Optionen aus:
+ **Option 1**: Öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
Wählen Sie im Navigationsbereich **Policies (Richtlinien)** aus und aktualisieren Sie dann die Berechtigungsrichtlinie für den Benutzer oder die Rolle, dem/der Sie die Berechtigung erteilen möchten, SSH-Verbindungen über Session Manager zu starten.
Fügen Sie beispielsweise das folgende Element der Schnellstart-Richtlinie hinzu, die Sie in [Kurzeinführung in Endbenutzerrichtlinien für Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user) erstellt haben. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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}-*"
}
]
}
```
------
+ **Option 2**: Hängen Sie mithilfe der, der oder der AWS-Managementkonsole AWS API eine Inline-Richtlinie an AWS CLI eine Benutzerrichtlinie an.
Verwenden Sie die Methode Ihrer Wahl und fügen Sie die Richtlinienerklärung in **Option 1** der Richtlinie für einen AWS Benutzer, eine Gruppe oder eine Rolle bei.
Informationen finden Sie im Abschnitt [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.
**So verwenden Sie eine IAM-Richtlinie, um SSH-Verbindungen über Session Manager zu verweigern**
+ Wählen Sie eine der folgenden Optionen aus:
+ **Option 1**: Öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). Wählen Sie im Navigationsbereich **Policies (Richtlinien)** aus und aktualisieren Sie dann die Berechtigungsrichtlinie für den Benutzer oder die Rolle, die am Starten von Session Manager-Sitzungen gehindert werden soll.
Fügen Sie beispielsweise das folgende Element der Schnellstart-Richtlinie hinzu, die Sie in [Kurzeinführung in Endbenutzerrichtlinien für Session Manager](getting-started-restrict-access-quickstart.md#restrict-access-quickstart-end-user) erstellt haben.
------
#### [ 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}-*"
}
]
}
```
------
+ **Option 2**: Hängen Sie mithilfe der, der oder der AWS-Managementkonsole AWS API eine Inline-Richtlinie an AWS CLI eine Benutzerrichtlinie an.
Verwenden Sie die Methode Ihrer Wahl und fügen Sie die Richtlinienerklärung in **Option 1** der Richtlinie für einen AWS Benutzer, eine Gruppe oder eine Rolle bei.
Informationen finden Sie im Abschnitt [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.
# Arbeiten mit Session Manager
Sie können die AWS Systems Manager-Konsole, die Amazon Elastic Compute Cloud (Amazon EC2)-Konsole oder die AWS Command Line Interface (AWS CLI) verwenden, um Sitzungen zu starten, die eine Verbindung zu den verwalteten Knoten herstellen, auf die Ihr Systemadministrator Ihnen mit AWS Identity and Access Management (IAM)-Richtlinien Zugriff gewährt hat. Abhängig von Ihren Berechtigungen können Sie auch Informationen zu Sitzungen anzeigen, noch nicht abgelaufene inaktive Sitzungen fortsetzen und Sitzungen beenden. Nachdem eine Sitzung eingerichtet wurde, ist sie nicht von der Dauer der IAM-Rollensitzung betroffen. Informationen zur Begrenzung der Sitzungsdauer mit Session Manager, finden Sie unter [Angeben eines Zeitüberschreitungswerts für Leerlaufsitzungen](session-preferences-timeout.md) und [Angeben der maximalen Sitzungsdauer](session-preferences-max-timeout.md).
Weitere Informationen zu Sitzungen finden Sie unter [Was ist eine Sitzung?](session-manager.md#what-is-a-session).
**Topics**
+ [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md)
+ [Starten einer Sitzung](session-manager-working-with-sessions-start.md)
+ [Eine Sitzung beenden](session-manager-working-with-sessions-end.md)
+ [Anzeigen des Sitzungsverlaufs](session-manager-working-with-view-history.md)
# Installiere das Session Manager Plugin für AWS CLI
Um Session Manager-Sitzungen mit Ihren verwalteten Knoten mithilfe von AWS Command Line Interface (AWS CLI) zu initiieren, müssen Sie das *Session Manager-Plugin* auf Ihrer lokalen Maschine installieren. Sie können das Plugin in unterstützten Versionen von Microsoft Windows Server, macOS, Linux und Ubuntu Server installieren.
**Anmerkung**
Um das Session Manager Plugin verwenden zu können, muss AWS CLI Version 1.16.12 oder höher auf Ihrem lokalen Computer installiert sein. Weitere Informationen finden Sie unter [Installieren oder Aktualisierung auf die neueste Version von AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
**Topics**
+ [Aktuelle Version und Versionsverlauf des Session Manager-Plugins](plugin-version-history.md)
+ [Installieren Sie das Session Manager-Plugin in Windows](install-plugin-windows.md)
+ [Installieren Sie das Session Manager-Plugin in macOS](install-plugin-macos-overview.md)
+ [Installieren des Session Manager-Plugins unter Linux](install-plugin-linux-overview.md)
+ [Verifizieren der Session Manager-Plugin-Installation](install-plugin-verify.md)
+ [Session Manager-Plugin in GitHub](plugin-github.md)
+ [(Optional) Aktivieren Sie die Session Manager-Plug-In-Protokollierung](install-plugin-configure-logs.md)
# Aktuelle Version und Versionsverlauf des Session Manager-Plugins
Auf Ihrem lokalen Computer muss eine unterstützte Version des Session Manager-Plugins ausgeführt werden. Die aktuelle unterstützte Mindestversion ist 1.1.17.0. Wenn Sie eine ältere Version ausführen, werden Ihre Session Manager-Operationen möglicherweise nicht erfolgreich abgeschlossen.
Um zu prüfen, ob Sie die neueste Version ausführen, führen Sie den folgenden Befehl in der AWS CLI aus.
**Anmerkung**
Der Befehl gibt nur dann Ergebnisse zurück, wenn sich das Plugin im Standardinstallationsverzeichnis für Ihren Betriebssystemtypen befindet. Sie können die Version auch in der Datei `VERSION` überprüfen. Diese Datei befindet sich in dem Verzeichnis, in dem Sie das Plugin installiert haben.
```
session-manager-plugin --version
```
In der folgenden Tabelle finden Sie alle Versionen des Session Manager-Plugins sowie die in den einzelnen Versionen enthaltenen Features und Erweiterungen.
**Wichtig**
Wir empfehlen Ihnen, immer die neueste Version zu verwenden. Die neueste Version enthält Verbesserungen, die die Benutzererfahrung mit dem Plugin verbessern.
| Version | Datum der Veröffentlichung | Details |
| --- | --- | --- |
| 1,2,792,0 | 17. März 2026 | **Bugfix**: Internationale Tastaturunterstützung für Windows hinzugefügt. |
| 1.2.779.0 | 12. Februar 2026 | **Verbesserung**: Aktualisieren Sie die Go-Version in Dockerfile auf 1.25. **Bugfix**: Shebang-Zeilen zu Debian-Paketskripten hinzugefügt. |
| 1.2.764.0 | 19. November 2025 | **Verbesserung**: Unterstützung für OpenDataChannel Signaturanfragen hinzugefügt. **Bugfix**: Checkstyle-Probleme behoben, um die neuere Go-Version zu unterstützen. |
| 1.2.707.0 | 6. Februar 2025 | **Verbesserung**: Die Go-Version wurde im Dockerfile auf 1.23 aktualisiert. Der Schritt zur Versionskonfiguration in der README-Datei wurde aktualisiert. |
| 1,2,694,0 | 20. November 2024 | **Fehlerbehebung**: Die Änderung, durch die Anmeldeinformationen zu Anfragen hinzugefügt wurden, wurde rückgängig gemacht. OpenDataChannel |
| 1.2.688.0 | 6. November 2024 | **Diese Version ist am 20.11.2024 veraltet.** **Verbesserungen**:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/plugin-version-history.html) |
| 1.2.677.0 | 10. Oktober 2024 | **Verbesserung**: Unterstützung für die Weitergabe der Plugin-Version mit Anfragen hinzugefügt. OpenDataChannel |
| 1.2.650.0 | 02. Juli 2024 | **Verbesserung: Auf** 1.54.10 aktualisiert aws-sdk-go.**Bugfix**: Kommentare für Gofmt Check wurden neu formatiert. |
| 1.2.633.0 | 30. Mai 2024 | Verbesserung: Das Dockerfile wurde aktualisiert, sodass es ein Amazon Elastic Container Registry (Amazon ECR)-Image verwendet. |
| 1,2,553,0 | 10. Januar 2024 | Verbesserung: Aktualisierte aws-sdk-go und abhängige Golang-Pakete. |
| 1.2.536.0 | 4. Dezember 2023 | Verbesserung: Unterstützung für die Übergabe einer [StartSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartSession.html)API-Antwort als Umgebungsvariable an hinzugefügt. session-manager-plugin |
| 1.2.497.0 | 1. August 2023 | Verbesserung: Go SDK wurde auf v1.44.302 aktualisiert. |
| 1,2,463,0 | 15. März 2023 | Verbesserung: Mac with Apple silicon-Unterstützung für Apple Mac (M1) im macOS-Bundle-Installer und im signierten Installer hinzugefügt. |
| 1,2,398,0 | 14. Oktober 2022 | Verbesserung: Unterstützung für Golang-Version 1.17. Aktualisieren Sie den session-manager-plugin Standard-Runner für macOS, um Python3 zu verwenden. Aktualisieren Sie den Importpfad von SSMCLI auf. session-manager-plugin |
| 1.2.339.0 | 16. Juni 2022 | Fehlerbehebung: Behebt die Zeitbeschränkung der Leerlaufsitzung für Portsitzungen. |
| 1.2.331,0 | 27. Mai 2022 | Fehlerbehebung: Behebt Portsitzungen, die vorzeitig geschlossen werden, wenn der lokale Server vor der Zeitbeschränkung keine Verbindung herstellt. |
| 1.2.323,0 | 19. Mai 2022 | Fehlerbehebung: Deaktivieren Sie Smux Keep Alive, um das Timeout-Feature im Leerlauf zu verwenden. |
| 1.2.312,0 | 31. März 2022 | Verbesserung: Unterstützt mehr Payload-Typen für Ausgabenachrichten. |
| 1.2.295,0 | 12. Januar 2022 | Fehlerbehebung: Aufgehängte Sitzungen durch das erneute Senden von Stream-Daten des Clients, wenn der Agent inaktiv wird, und falsche Protokolle für die Nachrichten start\$1publication und pause\$1publication. |
| 1.2.279,0 | 27. Oktober 2021 | Verbesserung: ZIP-Paketierung für Windows-Plattform. |
| 1.2.245,0 | 19. August 2021 | Verbesserung: Aktualisieren von aws-sdk-go auf die neueste Version (v1.40.17), um AWS IAM Identity Center zu unterstützen. |
| 1,2,234,0 | 26. Juli 2021 | Fehlerbehebung: Abrupt abgebrochenes Szenario im interaktiven Sitzungstyp behandeln. |
| 1.2.205,0 | 10. Juni 2021 | Verbesserung: Unterstützung für signiertes macOS-Installationsprogramm. |
| 1,2,54,0 | 29. Januar 2021 | Verbesserung: Unterstützung für das Ausführen von Sitzungen im NonInteractiveCommands Ausführungsmodus hinzugefügt. |
| 1.2.30.0 | 24. November 2020 | **Verbesserung**: (Nur Port-Weiterleitungssitzungen) Verbesserte Gesamtleistung. |
| 1.2.7.0 | 15. Oktober 2020 | **Verbesserung**: (Nur Port-Weiterleitungssitzungen) Verringerte Latenz und verbesserte Gesamtleistung. |
| 1.1.61.0 | 17. April 2020 | **Erweiterung**: ARM-Unterstützung für Linux und Ubuntu Server hinzugefügt. |
| 1.1.54.0 | 6. Januar 2020 | **Fehlerbehebung**: Verarbeitung des Race-Bedingungsszenarios von Paketen, die gelöscht werden, wenn das Session Manager-Plugin nicht bereit ist. |
| 1.1.50.0 | 19. November 2019 | **Erweiterung**: Unterstützung für die Weiterleitung eines Ports an einen lokalen Unix-Socket hinzugefügt. |
| 1.1.35.0 | 7. November 2019 | **Verbesserung**: (Nur Portweiterleitungssitzungen) Sendet einen TerminateSession Befehl an, SSM Agent wenn der lokale Benutzer drückt. `Ctrl+C` |
| 1.1.33.0 | 26. September 2019 | Erweiterung: (Nur Port-Weiterleitungssitzungen) Senden Sie ein Trennsignal an den Server, wenn der Client die TCP-Verbindung trennt. |
| 1.1.31.0 | 6. September 2019 | Erweiterung: Aktualisieren Sie, um die Port-Weiterleitungssitzung offen zu halten, bis der Remote-Server die Verbindung schließt. |
| 1.1.26.0 | 30. Juli 2019 | **Erweiterung**: Begrenzung der Datenübertragungsrate während einer Sitzung aktualisiert. |
| 1.1.23.0 | 9. Juli 2019 | **Verbesserung**: Unterstützung für die Ausführung von SSH-Sitzungen mit Session Manager hinzugefügt. |
| 1.1.17.0 | 4. April 2019 | **Erweiterung**: Unterstützung für die zusätzliche Verschlüsselung von Sitzungsdaten mit AWS Key Management Service (AWS KMS) hinzugefügt. |
| 1.0.37.0 | 20. September 2018 | **Verbesserung**: Fehlerbehebung für Windows-Version. |
| 1.0.0.0 | 11. September 2018 | Erstveröffentlichung des Session Manager-Plugins. |
# Installieren Sie das Session Manager-Plugin in Windows
Sie können das Session Manager-Plug-In auf Windows Vista oder höher mit dem eigenständigen Installationsprogramm installieren.
Wenn Aktualisierungen veröffentlicht werden, müssen Sie die Installation wiederholen, um die aktuelle Version des Session Manager-Plugins zu erhalten.
**Anmerkung**
Notieren Sie die folgenden Informationen:
Das Session Manager-Plugin-Installationsprogramm benötigt Administratorrechte, um das Plugin zu installieren.
Um optimale Ergebnisse zu erzielen, sollten Sie Sitzungen auf Windows-Clients mittels Windows PowerShell-Version 5 oder höher starten. Alternativ hierzu können Sie auch die Befehls-Shell in Windows 10 verwenden. Das Session Manager-Plug-In unterstützt nur PowerShell und die Befehls-Shell. Die Befehlszeilentools von Drittanbietern sind möglicherweise nicht mit dem Plug-In kompatibel.
**So installieren Sie das Session Manager-Plug-In mithilfe des EXE-Installationsprogramms**
1. Laden Sie das Installationsprogramm über die folgende URL herunter.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPluginSetup.exe
```
Alternativ können Sie eine gezippte Version des Installationsprogramms mit der folgenden URL herunterladen.
```
https://s3.amazonaws.com/session-manager-downloads/plugin/latest/windows/SessionManagerPlugin.zip
```
1. Führen Sie das heruntergeladene Installationsprogramm aus und folgen Sie den Anweisungen auf dem Bildschirm. Wenn Sie die gezippte Version des Installationsprogramms heruntergeladen haben, müssen Sie zuerst das Installationsprogramm entpacken.
Lassen Sie das Feld „Installationsspeicherort“ leer, um das Plug-In im Standardverzeichnis zu installieren.
+ `%PROGRAMFILES%\Amazon\SessionManagerPlugin\bin\`
1. Überprüfen Sie, ob die Installation erfolgreich war. Weitere Informationen finden Sie unter [Verifizieren der Session Manager-Plugin-Installation](install-plugin-verify.md).
**Anmerkung**
Wenn Windows die ausführbare Datei nicht finden kann, müssen Sie die Eingabeaufforderung möglicherweise erneut öffnen oder das Installationsverzeichnis der Umgebungsvariablen `PATH` manuell hinzufügen. Informationen finden Sie im Fehlerbehebungsthema [Session Manager-Plugin wurde nicht automatisch zumBefehlszeilenpfad hinzugefügt (Windows)](session-manager-troubleshooting.md#windows-plugin-env-var-not-set).
# Installieren Sie das Session Manager-Plugin in macOS
Wählen Sie eines der folgenden Themen aus, unter dem das Session Manager-Plugin auf macOS installiert werden soll.
**Anmerkung**
Das signierte Installationsprogramm ist eine signierte `.pkg`-Datei. Das mitgelieferte Installationsprogramm verwendet eine `.zip`-Datei. Wenn Sie die Datei entpackt haben, können Sie das Plugin mithilfe der Binärdatei installieren.
## Installieren des Session Manager-Plugins in macOS mittels des signierten Installationsprogramms
In diesem Abschnitt wird beschrieben, wie Sie das Session Manager-Plugin mithilfe des signierten Installers auf macOS installieren.
**So installieren Sie das Session Manager-Plugin mittels des signierten Installationsprogramms (macOS)**
1. Laden Sie das signierte Installationsprogramm herunter.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
#### [ Mac mit Apple-Halbleiter ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
```
------
1. Führen Sie die Installationsbefehle aus. Wenn der Befehl fehlschlägt, überprüfen Sie, ob der Ordner `/usr/local/bin` vorhanden ist. Ist dies nicht der Fall, erstellen Sie ihn und führen Sie den Befehl erneut aus.
```
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. Überprüfen Sie, ob die Installation erfolgreich war. Weitere Informationen finden Sie unter [Verifizieren der Session Manager-Plugin-Installation](install-plugin-verify.md).
## Installieren Sie das Session Manager-Plugin in macOS
In diesem Abschnitt wird beschrieben, wie Sie das Session Manager-Plugin mithilfe des mitgelieferten Installers auf macOS installieren.
**Wichtig**
Notieren Sie die folgenden wichtigen Informationen.
Standardmäßig benötigt das Installationsprogramm Sudo-Zugriff, um ausgeführt zu werden, da das Skript das Plugin im `/usr/local/sessionmanagerplugin`-Systemverzeichnis installiert. Wenn Sie das Plugin nicht mit Sudo installieren möchten, aktualisieren Sie das Installationsskript manuell, um das Plugin in einem Verzeichnis zu installieren, für das kein Sudo-Zugriff erforderlich ist.
Das gebündelte Installationsprogramm unterstützt keine Installation in Pfaden, die Leerzeichen enthalten.
**Sie installieren Sie das Session Manager-Plugin mittels des Paketinstallationsprogramms (macOS)**
1. Laden Sie das Paketinstallationsprogramm herunter.
------
#### [ x86\$164 ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
#### [ Mac mit Apple-Halbleiter ]
```
curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
```
------
1. Entpacken Sie das Paket.
```
unzip sessionmanager-bundle.zip
```
1. Führen Sie den Installationsbefehl aus.
```
sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
**Anmerkung**
Das Plugin benötigt Python 3.10 oder höher. Standardmäßig wird das Installationsskript unter der Standard-Systemversion von Python ausgeführt. Wenn Sie eine alternative Version von Python installiert haben und diese zum Installieren des Session Manager-Plugins verwenden möchten, führen Sie das Installationsskript mit dieser Version aus, indem Sie den absoluten Pfad der ausführbaren Python-Datei verwenden. Im Folgenden wird ein -Beispiel gezeigt.
```
sudo /usr/local/bin/python3.11 sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```
Das Installationsprogramm installiert das Session Manager-Plugin in `/usr/local/sessionmanagerplugin` und erstellt den Symlink `session-manager-plugin` im Verzeichnis `/usr/local/bin`. Dies beseitigt die Notwendigkeit, das Installationsverzeichnis in der `$PATH`-Variablen des Benutzers anzugeben.
Eine Erklärung der Optionen `-i` und `-b` sehen Sie, indem Sie die Option `-h` verwenden.
```
./sessionmanager-bundle/install -h
```
1. Überprüfen Sie, ob die Installation erfolgreich war. Weitere Informationen finden Sie unter [Verifizieren der Session Manager-Plugin-Installation](install-plugin-verify.md).
**Anmerkung**
Um das Plugin zu deinstallieren, führen Sie die folgenden beiden Befehle in der angegebenen Reihenfolge aus.
```
sudo rm -rf /usr/local/sessionmanagerplugin
```
```
sudo rm /usr/local/bin/session-manager-plugin
```
# Installieren des Session Manager-Plugins unter Linux
Dieser Abschnitt enthält Informationen zur Überprüfung der Signatur des Session Manager-Plugin-Installationspakets und zur Installation des Plugins in den folgenden Linux-Distributionen:
+ Amazon Linux 2
+ AL2023
+ RHEL
+ Debian Server
+ Ubuntu Server
**Topics**
+ [Verifizieren der Signatur des Session Manager-Plugins](install-plugin-linux-verify-signature.md)
+ [Installieren Sie das Session Manager-Plugin auf Amazon Linux 2, Amazon Linux 2023 und Red Hat Enterprise Linux-Distributionen](install-plugin-linux.md)
+ [Das Session Manager-Plugin in Debian Server und Ubuntu Server installieren](install-plugin-debian-and-ubuntu.md)
# Verifizieren der Signatur des Session Manager-Plugins
Die RPM- und Debian-Installationspakete des Session Manager-Plugins für Linux-Instances sind kryptografisch signiert. Sie können einen öffentlichen Schlüssel verwenden, um zu verifizieren, dass die Binärdatei und das Paket des Plugins original und unverändert sind. Wenn die Dateien beschädigt sind oder verändert wurden, schlägt die Überprüfung fehl. Sie können die Signatur des Installationspakets mithilfe des GNU Privacy Guard (GPG)-Tools überprüfen. Die folgenden Informationen sind für Session Manager-Plugin-Versionen 1.2.707.0 oder höher.
Führen Sie die folgenden Schritte aus, um die Signatur des Session Manager-Plugin-Installationspakets zu überprüfen.
**Topics**
+ [Schritt 1: Session Manager-Plugin-Installationspaket herunterladen](#install-plugin-linux-verify-signature-installer-packages)
+ [Schritt 2: Zugehörige Signaturdatei herunterladen](#install-plugin-linux-verify-signature-packages)
+ [Schritt 3: GPG-Tool installieren](#install-plugin-linux-verify-signature-packages-gpg)
+ [Schritt 4: Session Manager-Plugin-Installationspaket auf einem Linux-Server überprüfen](#install-plugin-linux-verify-signature-packages)
## Schritt 1: Session Manager-Plugin-Installationspaket herunterladen
Laden Sie das zu prüfende Session Manager-Plugin-Installationspaket herunter.
**Amazon Linux 2- AL2023 und RHEL RPM-Pakete**
------
#### [ 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"
```
------
**Debian Server- und Ubuntu Server-Deb-Pakete**
------
#### [ 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"
```
------
## Schritt 2: Zugehörige Signaturdatei herunterladen
Nachdem Sie das Installationspaket heruntergeladen haben, laden Sie die zugehörige Signaturdatei für die Paketüberprüfung herunter. Um einen zusätzlichen Schutz vor unbefugtem Kopieren oder Verwenden der session-manager-plugin Binärdatei im Paket zu bieten, bieten wir auch Binärsignaturen an, mit denen Sie einzelne Binärdateien validieren können. Sie können diese binären Signaturen je nach Ihren Sicherheitsanforderungen verwenden.
**Amazon Linux 2 AL2023 und RHEL Signaturpakete**
------
#### [ x86\$164 ]
Paket:
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm.sig"
```
Binärdatei:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
Paket:
```
curl -o "session-manager-plugin.rpm.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm.sig"
```
Binärdatei:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.sig"
```
------
**Deb-Signaturpakete für Debian Server und Ubuntu Server**
------
#### [ x86\$164 ]
Paket:
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb.sig"
```
Binärdatei:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.sig"
```
------
#### [ ARM64 ]
Paket:
```
curl -o "session-manager-plugin.deb.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.deb.sig"
```
Binärdatei:
```
curl -o "session-manager-plugin.sig" "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_arm64/session-manager-plugin.sig"
```
------
## Schritt 3: GPG-Tool installieren
Um die Signatur des Session Manager-Plugins zu überprüfen, muss das GNU Privacy Guard (GPG)-Tool auf Ihrem System installiert sein. Der Überprüfungsprozess erfordert GPG-Version 2.1 oder höher. Sie können Ihre GPG-Version mit dem folgenden Befehl ermitteln:
```
gpg --version
```
Wenn Ihre Version älter als 2.1 ist, müssen Sie sie aktualisieren, bevor Sie fortfahren können. Bei den meisten Systemen können Sie das GPG-Tool über Ihren Paketmanager aktualisieren. In unterstützten Amazon-Linux- und RHEL-Versionen können Sie zum Beispiel die folgenden Befehle verwenden:
```
sudo yum update
sudo yum install gnupg2
```
Auf unterstützten Ubuntu Server- und Debian Server-Systemen können Sie die folgenden Befehle verwenden:
```
sudo apt-get update
sudo apt-get install gnupg2
```
Sie müssen die erforderliche GPG-Version haben, bevor Sie mit dem Überprüfungsprozess fortfahren.
## Schritt 4: Session Manager-Plugin-Installationspaket auf einem Linux-Server überprüfen
Gehen Sie wie folgt vor, um das Session Manager-Plugin-Installationspaket auf einem Linux-Server zu überprüfen.
**Anmerkung**
Amazon Linux 2 unterstützt die GPG-Version 2.1 oder höher nicht. Wenn das folgende Verfahren auf Ihren Amazon-Linux-2-Instances nicht funktioniert, überprüfen Sie die Signatur auf einer anderen Plattform, bevor Sie sie auf Ihren Amazon-Linux-2-Instances installieren.
1. Kopieren Sie den folgenden öffentlichen Schlüssel und speichern Sie ihn in einer Datei namens 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. Importieren Sie den öffentlichen Schlüssel in Ihren Schlüsselbund. Der zurückgegebene Schlüsselwert sollte `2C4D4AFF6F6757EE` lauten.
```
$ 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. Führen Sie den folgenden Befehl aus, um den Fingerabdruck zu verifizieren.
```
gpg --fingerprint 2C4D4AFF6F6757EE
```
Der Fingerabdruck für die Befehlsausgabe sollte wie folgt aussehen.
```
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)
```
Wenn keine Übereinstimmung vorliegt, installieren Sie das Plugin nicht. Kontakt. AWS Support
1. Überprüfen Sie die Installer-Paketsignatur. Ersetzen Sie das *signature-filename* und *downloaded-plugin-filename* durch die Werte, die Sie beim Herunterladen der Signaturdatei angegeben haben session-manager-plugin, und, wie in der Tabelle weiter oben in diesem Thema aufgeführt.
```
gpg --verify signature-filename downloaded-plugin-filename
```
Für die x86\$164-Architektur unter Amazon Linux 2 lautet der Befehl wie folgt:
```
gpg --verify session-manager-plugin.rpm.sig session-manager-plugin.rpm
```
Dieser Befehl gibt etwa die folgende Ausgabe zurück.
```
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
```
Wenn die Ausgabe die Bezeichnung `BAD signature`enthält, überprüfen Sie, ob Sie das Verfahren korrekt durchgeführt haben. Wenn Sie weiterhin diese Antwort erhalten, wenden Sie sich an das Paket AWS Support und installieren Sie es nicht. Die Vertrauens-Warnmeldung bedeutet nicht, dass die Signatur ungültig ist, sondern nur, dass Sie den öffentlichen Schlüssel nicht überprüft haben. Beachten Sie die Warnung zu vertrauenswürdigen Inhalten. Wenn die Ausgabe die Phrase `Can't check signature: No public key` enthält, überprüfen Sie, ob Sie Session Manager-Plugin-Version 1.2.707.0 oder höher heruntergeladen haben.
# Installieren Sie das Session Manager-Plugin auf Amazon Linux 2, Amazon Linux 2023 und Red Hat Enterprise Linux-Distributionen
Gehen Sie wie folgt vor, um das Session Manager Plugin auf Amazon Linux 2, Amazon Linux 2023 (AL2023) und RHEL Distributionen zu installieren.
1. Laden Sie das Session Manager-Plugin-RPM-Paket herunter und installieren Sie es.
------
#### [ x86\$164 ]
Führen Sie unter Amazon Linux 2 und RHEL 7 den folgenden Befehl aus:
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
Führen Sie auf den Geräten RHEL 8 AL2023 und 9 den folgenden Befehl aus:
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm
```
------
#### [ ARM64 ]
Führen Sie unter Amazon Linux 2 und RHEL 7 den folgenden Befehl aus:
```
sudo yum install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
Führen Sie an den Stellen RHEL 8 AL2023 und 9 den folgenden Befehl aus:
```
sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_arm64/session-manager-plugin.rpm
```
------
1. Überprüfen Sie, ob die Installation erfolgreich war. Weitere Informationen finden Sie unter [Verifizieren der Session Manager-Plugin-Installation](install-plugin-verify.md).
**Anmerkung**
Wenn Sie das Plugin deinstallieren möchten, führen Sie `sudo yum erase session-manager-plugin -y` aus.
# Das Session Manager-Plugin in Debian Server und Ubuntu Server installieren
1. Laden Sie das Session Manager-Plug-In-deb-Paket herunter.
------
#### [ 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. Führen Sie den Installationsbefehl aus.
```
sudo dpkg -i session-manager-plugin.deb
```
1. Überprüfen Sie, ob die Installation erfolgreich war. Weitere Informationen finden Sie unter [Verifizieren der Session Manager-Plugin-Installation](install-plugin-verify.md).
**Anmerkung**
Wenn Sie das Plugin jemals deinstallieren möchten, führen Sie `sudo dpkg -r session-manager-plugin` aus.
# Verifizieren der Session Manager-Plugin-Installation
Führen Sie die folgenden Befehle aus, um zu überprüfen, ob das Session Manager-Plugin erfolgreich installiert wurde.
```
session-manager-plugin
```
Wenn die Installation erfolgreich war, wird die folgende Meldung zurückgegeben.
```
The Session Manager plugin is installed successfully. Use the AWS CLI to start a session.
```
Sie können die Installation auch testen, indem Sie den [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)-Befehl in der [AWS Command Line Interface](https://aws.amazon.com/cli/) (AWS CLI) ausführen. Ersetzen Sie im folgenden Befehl *instance-id* durch Ihre eigenen Informationen.
```
aws ssm start-session --target instance-id
```
Dieser Befehl funktioniert nur AWS CLI, wenn Sie den installiert und konfiguriert haben und Ihr Session Manager Administrator Ihnen die erforderlichen IAM-Berechtigungen für den Zugriff auf den verwalteten Zielknoten erteilt hat. Session Manager
# Session Manager-Plugin in GitHub
Der Quellcode für das Session Manager-Plugin ist auf [https://github.com/aws/session-manager-plugin](https://github.com/aws/session-manager-plugin) verfügbar, damit Sie das Plugin entsprechend Ihren Anforderungen anpassen können. Wir möchten Sie bitten, uns eventuelle [Änderungswünsche](https://github.com/aws/session-manager-plugin/blob/mainline/CONTRIBUTING.md) mitzuteilen. Amazon Web Services bietet jedoch keine Unterstützung für die Ausführung modifizierter Kopien dieser Software.
# (Optional) Aktivieren Sie die Session Manager-Plug-In-Protokollierung
Das Session Manager-Plug-In enthält eine Option zum Aktivieren der Protokollierung für von Ihnen ausgeführte Sitzungen. Standardmäßig ist die Protokollierung deaktiviert.
Wenn Sie die Protokollierung aktivieren, erstellt das Session Manager-Plug-In Protokolldateien sowohl für Anwendungsaktivitäten (`session-manager-plugin.log`) als auch für Fehler (`errors.log`) auf Ihrem lokalen Computer.
**Topics**
+ [Aktivieren der Protokollierung für das Session Manager-Plug-In (Windows)](#configure-logs-windows)
+ [Aktivieren der Protokollierung für das Session Manager-Plug-In (Linux und macOS)](#configure-logs-linux)
## Aktivieren der Protokollierung für das Session Manager-Plug-In (Windows)
1. Suchen Sie die Datei `seelog.xml.template` für das Plug-In.
Der Standardspeicherort ist `C:\Program Files\Amazon\SessionManagerPlugin\seelog.xml.template`.
1. Ändern Sie den Namen der Datei in `seelog.xml`.
1. Öffnen Sie die Datei und ändern Sie `minlevel="off"` in `minlevel="info"` oder `minlevel="debug"`.
**Anmerkung**
Standardmäßig werden Protokolleinträge zum Öffnen eines Datenkanals und Neuverbinden von Sitzungen auf **INFO**-Ebene aufgezeichnet. Datenflusseinträge (Pakete und Bestätigung) werden auf **DEBUG**-Ebene aufgezeichnet.
1. Ändern Sie andere Konfigurationsoptionen, die Sie ändern möchten. Optionen, die Sie ändern können, sind:
+ **Debug-Ebene**: Sie können die Debug-Ebene von `formatid="fmtinfo"` in `formatid="fmtdebug"` ändern.
+ Die**Protokolldateioptionen**: Sie können die Protokolldateioptionen einschließlich des Speicherorts der Protokolle ändern, jedoch nicht die Namen von Protokolldateien.
**Wichtig**
Sie dürfen die Dateinamen nicht ändern. Wenn Sie dies tun, funktioniert die Protokollierung nicht korrekt.
```
```
1. Speichern Sie die Datei.
## Aktivieren der Protokollierung für das Session Manager-Plug-In (Linux und macOS)
1. Suchen Sie die Datei `seelog.xml.template` für das Plug-In.
Der Standardspeicherort ist `/usr/local/sessionmanagerplugin/seelog.xml.template`.
1. Ändern Sie den Namen der Datei in `seelog.xml`.
1. Öffnen Sie die Datei und ändern Sie `minlevel="off"` in `minlevel="info"` oder `minlevel="debug"`.
**Anmerkung**
Standardmäßig werden Protokolleinträge zum Öffnen von Datenkanälen und Neuverbinden von Sitzungen auf **INFO**-Ebene aufgezeichnet. Datenflusseinträge (Pakete und Bestätigung) werden auf **DEBUG**-Ebene aufgezeichnet.
1. Ändern Sie andere Konfigurationsoptionen, die Sie ändern möchten. Optionen, die Sie ändern können, sind:
+ **Debug-Ebene**: Sie können die Debug-Ebene von `formatid="fmtinfo"` in `outputs formatid="fmtdebug"` ändern.
+ Die**Protokolldateioptionen**: Sie können die Protokolldateioptionen einschließlich des Speicherorts der Protokolle ändern, jedoch nicht die Namen von Protokolldateien.
**Wichtig**
Sie dürfen die Dateinamen nicht ändern. Wenn Sie dies tun, funktioniert die Protokollierung nicht korrekt.
```
```
**Wichtig**
Wenn Sie das angegebene Standardverzeichnis für das Speichern von Protokollen verwenden, müssen Sie Sitzungsbefehle entweder über **sudo** ausführen oder dem Verzeichnis, in dem das Plug-In installiert ist, vollständige Lese- und Schreibberechtigungen erteilen. Um diese Einschränkungen zu umgehen, ändern Sie den Speicherort, an dem die Protokolle gespeichert werden.
1. Speichern Sie die Datei.
# Starten einer Sitzung
Sie können die AWS Systems Manager Konsole, die Amazon Elastic Compute Cloud (Amazon EC2) -Konsole, die AWS Command Line Interface (AWS CLI) oder SSH verwenden, um eine Sitzung zu starten.
**Topics**
+ [Starten einer Sitzung (Systems Manager-Konsole)](#start-sys-console)
+ [Starten einer Sitzung (Amazon EC2-Konsole)](#start-ec2-console)
+ [Starten einer Sitzung (AWS CLI)](#sessions-start-cli)
+ [Starten einer Sitzung (SSH)](#sessions-start-ssh)
+ [Starten einer Sitzung (Port-Weiterleitung)](#sessions-start-port-forwarding)
+ [Starten einer Sitzung (Port-Weiterleitung an entfernten Host)](#sessions-remote-port-forwarding)
+ [Starten einer Sitzung (interaktive und nicht interaktive Befehle)](#sessions-start-interactive-commands)
## Starten einer Sitzung (Systems Manager-Konsole)
Sie können die AWS Systems Manager Konsole verwenden, um eine Sitzung mit einem verwalteten Knoten in Ihrem Konto zu starten.
**Anmerkung**
Bevor Sie eine Sitzung beginnen, stellen Sie sicher, dass Sie die Einrichtungsschritte für Session Manager ausgeführt haben. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
**Starten einer Sitzung (Systems-Manager-Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie **Sitzung starten** aus.
1. (Optional) Geben Sie eine Beschreibung für die Sitzung im Feld **Grund für die Sitzung** ein.
1. Aktivieren Sie unter **Ziel-Instances** das Optionsfeld links neben dem verwalteten Knoten aus, mit dem Sie eine Verbindung herstellen möchten.
Wenn der gewünschte Knoten nicht in der Liste enthalten ist oder wenn Sie einen Knoten auswählen und einen Konfigurationsfehler erhalten, lesen Sie die Schritte zur Fehlerbehebung unter [Verwalteter Knoten ist nicht verfügbar oder nicht für Session Manager konfiguriert](session-manager-troubleshooting.md#session-manager-troubleshooting-instances).
1. Wählen Sie **Sitzung starten**, um die Sitzung sofort zu starten.
–oder–
Wählen Sie **Weiter** für die Sitzungsoptionen.
1. (Optional) Wählen Sie unter **Sitzungsdokument** das Dokument aus, das Sie zu Beginn der Sitzung ausführen möchten. Wenn Ihr Dokument Laufzeitparameter unterstützt, können Sie in jedes Parameterfeld einen oder mehrere durch Komma getrennte Werte eingeben.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie **Sitzung starten** aus.
Nach der Herstellung der Verbindung können Sie Bash-Befehle (Linux und macOS) oder PowerShell-Befehle (Windows) wie für jeden anderen Verbindungstyp ausführen.
**Wichtig**
Wenn Sie Benutzern die Möglichkeit geben möchten, beim Starten von Sitzungen in der Session-Manager-Konsole ein Dokument anzugeben, beachten Sie Folgendes:
Sie müssen Benutzern die in ihrer IAM-Richtlinie festgelegten Berechtigungen `ssm:GetDocument` und `ssm:ListDocuments` gewähren. Weitere Informationen finden Sie unter [Zugriff auf benutzerdefinierte Sitzungsdokumente in der Konsole gewähren](getting-started-restrict-access-examples.md#grant-access-documents-console-example).
Die Konsole unterstützt nur Sitzungsdokumente, für die der `sessionType` als `Standard_Stream` definiert ist. Weitere Informationen finden Sie unter [Schema des Sitzungsdokuments](session-manager-schema.md).
## Starten einer Sitzung (Amazon EC2-Konsole)
Sie können die Amazon Elastic Compute Cloud (Amazon EC2)-Konsole verwenden, um eine Sitzung mit einer Instance in Ihrem Konto zu starten.
**Anmerkung**
Wenn Sie den Fehler erhalten, dass Sie nicht berechtigt sind, eine oder mehrere Systems Manager (`ssm:command-name`)-Aktionen auszuführen, müssen Sie sich an Ihren Administrator wenden. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt. Bitten Sie diese Person, Ihre Richtlinien zu aktualisieren, damit Sie Sitzungen von der Amazon EC2-Konsole aus starten können. Wenn Sie ein Administrator sind, finden Sie weitere Informationen unter [Muster-IAM-Richtlinien für Session Manager](getting-started-restrict-access-quickstart.md).
**Starten einer Sitzung (Amazon EC2-Konsole)**
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Navigationsbereich **Instances** aus.
1. Wählen Sie die Instance und **Connect (Verbinden)** aus.
1. Für **Connection method (Verbindungsmethode)** wählen Sie **Session Manager**.
1. Wählen Sie **Connect** aus.
Nach der Herstellung der Verbindung können Sie Bash-Befehle (Linux und macOS) oder PowerShell-Befehle (Windows) wie für jeden anderen Verbindungstyp ausführen.
## Starten einer Sitzung (AWS CLI)
Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
Bevor Sie eine Sitzung beginnen, stellen Sie sicher, dass Sie die Einrichtungsschritte für Session Manager ausgeführt haben. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
Um die Befehle AWS CLI to run session verwenden zu können, muss das Session Manager Plugin auch auf Ihrem lokalen Computer installiert sein. Weitere Informationen finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md).
Um eine Sitzung mit dem zu starten AWS CLI, führen Sie den folgenden Befehl aus und *instance-id* ersetzen Sie ihn durch Ihre eigenen Informationen.
```
aws ssm start-session \
--target instance-id
```
Informationen zu anderen Optionen, die Sie mit dem **start-session** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)im AWS Systems Manager Abschnitt der AWS CLI Befehlsreferenz.
## Starten einer Sitzung (SSH)
Um eine Session Manager-SSH-Sitzung zu starten, muss Version 2.3.672.0 oder höher von SSM Agent auf dem verwalteten Knoten installiert sein.
**Anforderungen für SSH-Verbindungen**
Beachten Sie die folgenden Anforderungen und Einschränkungen für Sitzungsverbindungen über Session Manager SSH:
+ Ihr anvisierter verwalteter Knoten muss so konfiguriert sein, dass er SSH-Verbindungen unterstützt. Weitere Informationen finden Sie unter [(Optional) Berechtigungen für SSH-Verbindungen über Session Manager aktivieren und steuern](session-manager-getting-started-enable-ssh-connections.md).
+ Sie müssen mithilfe des Kontos des verwalteten Knotens verbinden, der dem Privacy Enhanced Mail (PEM)-Zertifikat zugeordnet ist, und nicht dem `ssm-user`-Konto, das für andere Arten von Sitzungsverbindungen verwendet wird. Auf EC2-Instances für Linux und macOS, ist beispielsweise der Standardbenutzer `ec2-user`. Weitere Hinweise zur Identifizierung des Standardbenutzers für die einzelnen Instance-Typen finden Sie unter [Informationen zu Ihrer Instance anfordern](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connection-prereqs.html#connection-prereqs-get-info-about-instance) im *Amazon-EC2-Benutzerhandbuch*.
+ Protokollieren ist für Session Manager-Sitzungen, die eine Verbindung über Port-Weiterleitung oder SSH herstellen, nicht verfügbar. Dies liegt daran, dass SSH alle Sitzungsdaten innerhalb der sicheren TLS-Verbindung zwischen den Endpunkten AWS CLI und den Session Manager Endpunkten verschlüsselt und Session Manager nur als Tunnel für SSH-Verbindungen dient.
**Anmerkung**
Bevor Sie eine Sitzung beginnen, stellen Sie sicher, dass Sie die Einrichtungsschritte für Session Manager ausgeführt haben. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
Um eine Sitzung über SSH zu starten, führen Sie folgenden Befehl aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
```
ssh -i /path/my-key-pair.pem username@instance-id
```
**Tipp**
Wenn Sie eine Sitzung mit SSH starten, können Sie mit dem folgenden Befehl lokale Dateien auf den anvisierten verwalteten Knoten kopieren.
```
scp -i /path/my-key-pair.pem /path/ExampleFile.txt username@instance-id:~
```
Informationen zu anderen Optionen, die Sie mit dem **start-session** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)im AWS Systems Manager Abschnitt der Befehlsreferenz. AWS CLI
## Starten einer Sitzung (Port-Weiterleitung)
Um eine Session Manager-Port-Weiterleitungs-Sitzung zu starten, muss Version 2.3.672.0 oder höher des SSM Agent auf dem verwalteten Knoten installiert sein.
**Anmerkung**
Bevor Sie eine Sitzung beginnen, stellen Sie sicher, dass Sie die Einrichtungsschritte für Session Manager ausgeführt haben. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
Um die Befehle AWS CLI to run session verwenden zu können, müssen Sie das Session Manager Plug-in auf Ihrem lokalen Computer installieren. Weitere Informationen finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md).
Je nach Betriebssystem und Befehlszeilentool kann die Platzierung von Anführungszeichen unterschiedlich sein, und möglicherweise sind Escapezeichen erforderlich.
Um eine Port-Weiterleitungssitzung zu starten, führen Sie den folgenden Befehl in der CLI aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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"
```
------
`portNumber` ist der Remote-Port auf dem verwalteten Knoten, an den der Sitzungsverkehr umgeleitet werden soll. Sie können beispielsweise Port `3389` für die Verbindung zu einem Windows-Knoten mithilfe des Remote Desktop Protocol (RDP) angeben. Wenn Sie den `portNumber`-Parameter nicht angeben, verwendet Session Manager die `80`-Standardschulungsparameter.
`localPortNumber` ist der Port auf Ihrem lokalen Computer, an dem der Verkehr beginnt, z. B. `56789` Dieser Wert ist, was Sie eingeben, wenn Sie eine Verbindung mit einem verwalteten Knoten über einen Client herstellen. Beispiel, **localhost:56789**.
Informationen zu anderen Optionen, die Sie mit dem **start-session** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)im AWS Systems Manager Abschnitt der AWS CLI Befehlsreferenz.
Weitere Informationen zu Port-Weiterleitungssitzungen finden Sie unter [Port-Weiterleitung unter Verwendung von AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/) im *AWS News Blog*.
## Starten einer Sitzung (Port-Weiterleitung an entfernten Host)
Um eine Session Manager-Port-Weiterleitungs-Sitzung zu einem entfernten Host zu starten, muss Version 3.1.1374.0 oder höher des SSM Agent auf dem verwalteten Knoten installiert sein. Der Remote-Host muss nicht von Systems Manager verwaltet werden.
**Anmerkung**
Bevor Sie eine Sitzung beginnen, stellen Sie sicher, dass Sie die Einrichtungsschritte für Session Manager ausgeführt haben. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
Um die Befehle AWS CLI to run session verwenden zu können, müssen Sie das Session Manager Plug-in auf Ihrem lokalen Computer installieren. Weitere Informationen finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md).
Je nach Betriebssystem und Befehlszeilentool kann die Platzierung von Anführungszeichen unterschiedlich sein, und möglicherweise sind Escapezeichen erforderlich.
Um eine Port-Weiterleitungssitzung zu starten, führen Sie den folgenden Befehl in der AWS CLI aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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"
```
------
Der `host`-Wert stellt den Hostnamen oder die IP-Adresse des Remote-Hosts dar, zu dem Sie eine Verbindung herstellen möchten. Es gelten weiterhin allgemeine Anforderungen an Konnektivität und Namensauflösung zwischen dem verwalteten Knoten und dem Remote-Host.
`portNumber` ist der Remote-Port auf dem verwalteten Knoten, an den der Sitzungsverkehr umgeleitet werden soll. Sie können beispielsweise Port `3389` für die Verbindung zu einem Windows-Knoten mithilfe des Remote Desktop Protocol (RDP) angeben. Wenn Sie den `portNumber`-Parameter nicht angeben, verwendet Session Manager die `80`-Standardschulungsparameter.
`localPortNumber` ist der Port auf Ihrem lokalen Computer, an dem der Verkehr beginnt, z. B. `56789` Dieser Wert ist, was Sie eingeben, wenn Sie eine Verbindung mit einem verwalteten Knoten über einen Client herstellen. Beispiel, **localhost:56789**.
Informationen zu anderen Optionen, die Sie mit dem **start-session** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)im AWS Systems Manager Abschnitt der AWS CLI Befehlsreferenz.
### Starten einer Sitzung mit einer Amazon-ECS-Aufgabe
Session Manager unterstützt das Starten einer Portweiterleitungssitzung mit einer Aufgabe in einem Amazon Elastic Container Service (Amazon ECS)-Cluster. Aktivieren Sie dazu ECS Exec. Weitere Informationen finden Sie unter [Überwachen von Amazon-ECS-Containern mit ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) im *Entwicklerhandbuch zum Amazon Elastic Container Service*.
Sie müssen ebenso die Aufgabenrolle in IAM aktualisieren, sodass sie die folgenden Berechtigungen enthält:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}
]
}
```
------
Um eine Port-Weiterleitungssitzung mit einer Amazon-ECS-Aufgabe zu starten, führen Sie den folgenden Befehl in der AWS CLI aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
**Anmerkung**
Entfernen Sie die <- und >-Symbole aus dem `target`-Parameter. Diese Symbole dienen nur zur Verdeutlichung des Lesers.
------
#### [ 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"
```
------
## Starten einer Sitzung (interaktive und nicht interaktive Befehle)
Bevor Sie eine Sitzung beginnen, stellen Sie sicher, dass Sie die Einrichtungsschritte für Session Manager ausgeführt haben. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
Um die Befehle AWS CLI to run session verwenden zu können, muss das Session Manager Plugin auch auf Ihrem lokalen Computer installiert sein. Weitere Informationen finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md).
Um eine Interactive Befehls-Sitzung zu starten, führen Sie den folgenden Befehl aus. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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"
```
------
Informationen zu anderen Optionen, die Sie mit dem **start-session** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/start-session.html)im AWS Systems Manager Abschnitt der AWS CLI Befehlsreferenz.
**Weitere Informationen**
+ [Verwenden Sie Port-Forwarding in AWS Systems ManagerSession Manager, um eine Verbindung zu Remote-Hosts herzustellen](https://aws.amazon.com/blogs/mt/use-port-forwarding-in-aws-systems-manager-session-manager-to-connect-to-remote-hosts/)
+ [Amazon EC2 EC2-Instance-Portweiterleitung mit AWS Systems Manager](https://aws.amazon.com/blogs/mt/amazon-ec2-instance-port-forwarding-with-aws-systems-manager/)
+ [AWS Verwaltete Microsoft AD-Ressourcen mit Session Manager Portweiterleitung verwalten](https://aws.amazon.com/blogs/mt/manage-aws-managed-microsoft-ad-resources-with-session-manager-port-forwarding/)
+ [Port-Weiterleitung mit AWS Systems ManagerSession Manager](https://aws.amazon.com/blogs/aws/new-port-forwarding-using-aws-system-manager-sessions-manager/) im *AWS News Blog*.
# Eine Sitzung beenden
Sie können mithilfe der AWS Systems Manager-Konsole oder der AWS Command Line Interface (AWS CLI) eine Sitzung beenden, die Sie in Ihrem Konto gestartet haben. Wenn Sie in der Konsole auf die Schaltfläche **Beenden** für eine Sitzung klicken oder die API-Aktion [TerminateSession](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TerminateSession.html) mithilfe von AWS CLI aufrufen, wird Session Manager die Sitzung dauerhaft beenden und die Datenverbindung zwischen dem Session Manager-Client und SSM Agent auf dem verwalteten Knoten wird geschlossen. Sie können eine beendete Sitzung nicht fortsetzen.
Wenn in einer geöffneten Sitzung 20 Minuten lang keine Benutzeraktivität stattfindet, löst der Ruhezustand ein Timeout aus. Session Manager ruft `TerminateSession` nicht auf, schließt aber den zugrunde liegenden Kanal. Sie können eine Sitzung, die aufgrund eines Timeouts im Leerlauf geschlossen wurde, nicht fortsetzen.
Wir empfehlen, eine Sitzung immer explizit zu beenden, indem Sie den `terminate-session`-Befehl verwenden, wenn Sie die AWS CLI verwenden, oder die Schaltfläche **Beenden**, wenn Sie die Konsole verwenden. (Die Schaltflächen zum **Beenden** befinden sich sowohl im Sitzungsfenster als auch auf der Hauptseite der Session Manager-Konsole.) Wenn Sie nur ein Browser- oder Befehlsfenster schließen, wird die Sitzung in der Konsole 30 Tage lang als **Aktiv** aufgeführt. Wenn Sie eine Sitzung nicht explizit beenden oder wenn das Zeitlimit für eine Sitzung überschritten wird, werden alle Prozesse, die zu diesem Zeitpunkt auf dem verwalteten Knoten ausgeführt wurden, weiterhin ausgeführt.
**Topics**
+ [So beenden Sie eine Sitzung (Konsole)](#stop-sys-console)
+ [Beenden einer Sitzung (AWS CLI)](#stop-cli)
## So beenden Sie eine Sitzung (Konsole)
Sie können mithilfe der AWS Systems Manager-Konsole eine Sitzung in Ihrem Konto beenden.
**So beenden Sie eine Sitzung (Konsole)**
1. Öffnen Sie die AWS Systems Manager-Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie unter **Sessions (Sitzungen)** die Optionsschaltfläche links neben der Sitzung aus, die Sie beenden möchten.
1. Wähen Sie **Beenden**.
## Beenden einer Sitzung (AWS CLI)
Um eine Sitzung über die AWS CLI zu beenden, führen Sie folgenden Befehl aus. Ersetzen Sie *session-id* mit Ihren eigenen Informationen.
```
aws ssm terminate-session \
--session-id session-id
```
Weitere Informationen zum Befehl **terminate-session** finden Sie unter [https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/terminate-session.html) im Abschnitt AWS Systems Manager der Befehlsreferenz AWS CLI.
# Anzeigen des Sitzungsverlaufs
Sie können die AWS Systems Manager Konsole oder die AWS Command Line Interface (AWS CLI) verwenden, um Informationen zu Sitzungen in Ihrem Konto einzusehen. In der Konsole können Sie Sitzungsdetails wie die folgenden anzeigen:
+ Die ID der Sitzung
+ Welche Benutzer über eine Sitzung eine Verbindung mit einem verwalteten Knoten hergestellt haben
+ Die ID des verwalteten Knotens
+ Wann die Sitzung gestartet und beendet wurde
+ Den Status der Sitzung
+ Den für das Speichern von Sitzungsprotokollen angegebenen Speicherort (wenn aktiviert)
Mithilfe der AWS CLI können Sie eine Liste der Sitzungen in Ihrem Konto einsehen, nicht jedoch die zusätzlichen Details, die in der Konsole verfügbar sind.
Informationen zur Protokollierung des Sitzungsverlaufs finden Sie unter [Protokollierung von Sitzungen aktivieren und deaktivieren](session-manager-logging.md).
**Topics**
+ [Anzeigen des Sitzungsverlaufs (Konsole)](#view-console)
+ [Anzeigen des Sitzungsverlaufs (AWS CLI)](#view-history-cli)
## Anzeigen des Sitzungsverlaufs (Konsole)
Sie können die AWS Systems Manager Konsole verwenden, um Details zu den Sitzungen in Ihrem Konto einzusehen.
**So zeigen Sie den Sitzungsverlauf an (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Session history (Sitzungsverlauf)** aus.
–oder–
Wenn die Session Manager-Startseite zum ersten Mal geöffnet wird, wählen Sie **Einstellungen konfigurieren** und dann die Registerkarte **Sitzungsverlauf** aus.
## Anzeigen des Sitzungsverlaufs (AWS CLI)
Führen Sie den folgenden Befehl aus AWS CLI, um eine Liste der Sitzungen in Ihrem Konto mit dem anzuzeigen.
```
aws ssm describe-sessions \
--state History
```
**Anmerkung**
Dieser Befehl gibt nur Ergebnisse für Verbindungen zu Zielen zurück, die mit Session Manager initiiert wurden. Es werden keine Verbindungen aufgeführt, die auf andere Weise hergestellt wurden, z. B. Remote Desktop Protocol (RDP) oder Secure Shell Protocol (SSH).
Informationen zu anderen Optionen, die Sie mit dem **describe-sessions** Befehl verwenden können, finden Sie [https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-sessions.html)im AWS Systems Manager Abschnitt der AWS CLI Befehlsreferenz.
# Protokollieren von Sitzungsaktivitäten
Zusätzlich zur Bereitstellung von Informationen zu den aktuellen und abgeschlossenen Sitzungen in der Systems-Manager-Konsole stellt Session Manager Ihnen Optionen für das Protokoll von Sitzungsaktivitäten in Ihrem AWS-Konto mit AWS CloudTrail bereit.
CloudTrail erfasst Session-API-Aufrufe über die Systems Manager-Konsole, das AWS Command Line Interface (AWS CLI) und das Systems Manager SDK. Sie können die Informationen auf der CloudTrail Konsole anzeigen oder sie in einem bestimmten Amazon Simple Storage Service (Amazon S3) -Bucket speichern. Ein Amazon S3 S3-Bucket wird für alle CloudTrail Protokolle Ihres Kontos verwendet. Weitere Informationen finden Sie unter [AWS Systems Manager API-Aufrufe protokollieren mit AWS CloudTrail](monitoring-cloudtrail-logs.md).
**Anmerkung**
Für wiederkehrende, historische, analytische Analysen Ihrer Protokolldateien sollten Sie erwägen, CloudTrail Protokolle mithilfe von [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) oder einer von Ihnen verwalteten Tabelle abzufragen. Weitere Informationen finden Sie unter [AWS CloudTrail Logs abfragen](https://docs.aws.amazon.com/athena/latest/ug/cloudtrail-logs.html) im *AWS CloudTrail Benutzerhandbuch*.
## Überwachung der Sitzungsaktivität mit Amazon EventBridge (Konsole)
Mit können Sie Regeln einrichten EventBridge, um zu erkennen, wann Änderungen an AWS Ressourcen vorgenommen werden. Sie können eine Regel erstellen, um zu erkennen, wenn ein Benutzer in Ihrer Organisation eine Sitzung startet oder beendet, und dann z. B. über Amazon SNS eine Benachrichtigung bezüglich des Ereignisses erhalten.
EventBridge Die Unterstützung für Session Manager stützt sich auf Aufzeichnungen von API-Vorgängen, die von aufgezeichnet wurden CloudTrail. (Sie können die CloudTrail Integration mit verwenden EventBridge , um auf die meisten AWS Systems Manager Ereignisse zu reagieren.) Aktionen, die innerhalb einer Sitzung stattfinden, z. B. ein `exit` Befehl, der keinen API-Aufruf durchführt, werden von nicht erkannt EventBridge.
Die folgenden Schritte zeigen, wie Sie Benachrichtigungen über Amazon Simple Notification Service (Amazon SNS) initiieren, wenn ein Session ManagerAPI-Ereignis eintritt, z. B. **StartSession**.
**Um die Sitzungsaktivität mit Amazon EventBridge (Konsole) zu überwachen**
1. Erstellen Sie ein Amazon SNS-Thema zum Senden von Benachrichtigungen, wenn das Session Manager-Ereignis eintritt, die Sie überwachen möchten.
Weitere Informationen finden Sie unter [Erstellen eines Themas](https://docs.aws.amazon.com/sns/latest/dg/CreateTopic.html) im *Amazon Simple Notification Service-Entwicklerhandbuch*.
1. Erstellen Sie eine EventBridge Regel, um das Amazon SNS SNS-Ziel für den Session Manager Ereignistyp aufzurufen, den Sie verfolgen möchten.
Informationen zur Erstellung der Regel finden Sie im [* EventBridge Amazon-Benutzerhandbuch* unter Erstellen von EventBridge Amazon-Regeln, die auf Ereignisse reagieren](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html).
Wählen Sie während der Erstellung der Regel die folgenden Optionen aus:
+ Wählen Sie für **AWS service** (-Service), die Option **Systems Manager** aus.
+ Wählen Sie als **Ereignistyp** die Option **AWS API Call through** aus CloudTrail.
+ Wählen Sie **Specific operation (s) (Spezifische Operation(en))** aus und geben Sie dann nacheinander die Session Manager-Befehle ein, für die Sie Benachrichtigungen erhalten möchten. Sie können **StartSession****ResumeSession**, und wählen**TerminateSession**. (unterstützt die `Describe*` Befehle `Get*`` List*`, und EventBridge nicht.)
+ Für **Select a target** (Wählen Sie ein Ziel aus), wählen Sie **SNS-Thema** aus. Wählen Sie unter **Topic (Thema)** den Namen des von Ihnen in Schritt 1 erstellten Amazon SNS-Themas aus.
Weitere Informationen finden Sie im *[ EventBridge Amazon-Benutzerhandbuch](https://docs.aws.amazon.com/eventbridge/latest/userguide/)* und im *[Amazon Simple Notification Service Getting Started Guide](https://docs.aws.amazon.com/sns/latest/gsg/)*.
# Protokollierung von Sitzungen aktivieren und deaktivieren
Die Sitzungsprotokollierung zeichnet Informationen über aktuelle und abgeschlossene Sitzungen in der Systems-Manager-Konsole auf. Sie können auch Details zu Befehlen protokollieren, die während Sitzungen in Ihrem AWS-Konto ausgeführt werden. Mithilfe der Sitzungsprotokollierung können Sie Folgendes tun:
+ Erstellen und Speichern von Sitzungsprotokollen zu Archivierungszwecken.
+ Generieren eines Berichts mit Details zu jeder Verbindung, die mit Ihren verwalteten Knoten über Session Manager in den letzten 30 Tagen hergestellt wurde.
+ Generieren Sie Benachrichtigungen für die Sitzungsprotokollierung in Ihren Benachrichtigungen AWS-Konto, z. B. Amazon Simple Notification Service (Amazon SNS).
+ Initiieren Sie automatisch eine weitere Aktion für eine AWS Ressource als Ergebnis von Aktionen, die während einer Sitzung ausgeführt wurden, z. B. das Ausführen einer AWS Lambda Funktion, das Starten einer AWS CodePipeline Pipeline oder das Ausführen eines AWS Systems Manager Run Command Dokuments.
**Wichtig**
Beachten Sie die folgenden Anforderungen und Einschränkungen für Session Manager:
Session Manager protokolliert die von Ihnen eingegebenen Befehle und deren Ausgabe während einer Sitzung abhängig von Ihren Sitzungseinstellungen. Um zu verhindern, dass vertrauliche Daten wie Passwörter in Ihren Sitzungsprotokollen angezeigt werden, empfehlen wir die folgenden Befehle, wenn Sie während einer Sitzung vertrauliche Daten eingeben.
```
stty -echo; read passwd; stty echo;
```
```
$Passwd = Read-Host -AsSecureString
```
Wenn Sie Windows Server 2012 oder früher verwenden, werden die Daten in Ihren Protokollen möglicherweise nicht optimal formatiert. Wir empfehlen die Verwendung von Windows Server 2012 R2 und höher, um optimal formatierte Protokolle zu erhalten.
Wenn Sie Linux- oder macOS-verwaltete Knoten verwenden, muss das Screen-Serviceprogramm installiert sein. Wenn dies nicht der Fall ist, werden die Protokolldaten möglicherweise abgeschnitten. Unter Amazon Linux AL2 2.023 und ist Ubuntu Server das Screen Utility standardmäßig installiert. Um Screen manuell zu installieren, müssen Sie abhängig von Ihrer Linux-Version entweder `sudo yum install screen` oder `sudo apt-get install screen` ausführen.
Protokollieren ist für Session Manager-Sitzungen, die eine Verbindung über Port-Weiterleitung oder SSH herstellen, nicht verfügbar. Das liegt daran, dass SSH alle Sitzungsdaten innerhalb der sicheren TLS-Verbindung zwischen den Session Manager Endpunkten verschlüsselt AWS CLI und Session Manager nur als Tunnel für SSH-Verbindungen dient.
Weitere Informationen zu den Berechtigungen, die für die Verwendung von Amazon S3 oder Amazon CloudWatch Logs für die Protokollierung von Sitzungsdaten erforderlich sind, finden Sie unter[Erstellen einer IAM-Rolle mit Berechtigungen für Amazon S3 Session Manager und CloudWatch Logs (Konsole)](getting-started-create-iam-instance-profile.md#create-iam-instance-profile-ssn-logging).
Weitere Informationen zu Protokollierungsoptionen für Session Manager finden Sie in den folgenden Themen.
**Topics**
+ [Streaming-Sitzungsdaten mit Amazon CloudWatch Logs (Konsole)](session-manager-logging-cwl-streaming.md)
+ [Protokollieren von Sitzungsdaten mithilfe von Amazon S3 (Konsole)](session-manager-logging-s3.md)
+ [Protokollierung von Sitzungsdaten mit Amazon CloudWatch Logs (Konsole)](session-manager-logging-cloudwatch-logs.md)
+ [Konfigurieren der Sitzungsprotokollierung auf Festplatte](session-manager-logging-disk.md)
+ [Anpassen, wie lange die Session Manager temporäre Protokolldatei auf der Festplatte gespeichert wird](session-manager-logging-disk-retention.md)
+ [Deaktivierung der Session Manager Protokollierung in CloudWatch Logs und Amazon S3](session-manager-enable-and-disable-logging.md)
# Streaming-Sitzungsdaten mit Amazon CloudWatch Logs (Konsole)
Sie können einen kontinuierlichen Stream von Sitzungsdatenprotokollen an Amazon CloudWatch Logs senden. Wichtige Details, wie die Befehle, die ein Benutzer in einer Sitzung ausgeführt hat, die ID des Benutzers, der die Befehle ausgeführt hat, und Zeitstempel für den Zeitpunkt, zu dem die Sitzungsdaten in CloudWatch Logs gestreamt werden, sind beim Streaming von Sitzungsdaten enthalten. Beim Streamen von Sitzungsdaten werden die Protokolle JSON-formatiert, um Ihnen bei der Integration in Ihre vorhandenen Protokollierungslösungen zu helfen. Streaming-Sitzungsdaten werden für interaktive Befehle nicht unterstützt.
**Anmerkung**
Um Sitzungsdaten von Windows Server-verwalteten Knoten zu streamen, müssen Sie PowerShell 5.1 oder höher installiert haben. Standardmäßig ist bei Windows Server 2016 und höher die erforderliche PowerShell-Version installiert. Bei Windows Server 2012 und 2012 R2 ist die erforderliche PowerShell-Version jedoch nicht standardmäßig installiert. Wenn Sie PowerShell noch nicht auf Ihren von Windows Server 2012 oder 2012 R2 verwalteten Knoten aktualisiert haben, können Sie dies mit Run Command tun. Informationen zur Aktualisierung von PowerShell mithilfe von Run Command finden Sie unter [Aktualisierung PowerShell mit Run Command](run-command-tutorial-update-software.md#rc-console-pwshexample).
**Wichtig**
Wenn Sie die Einstellung der **PowerShell Transkriptionsrichtlinie** auf Ihren Windows Server verwalteten Knoten konfiguriert haben, können Sie keine Sitzungsdaten streamen.
**Um Sitzungsdaten mit Amazon CloudWatch Logs zu streamen (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Präferenzen** und anschließend **Bearbeiten** aus.
1. Aktivieren Sie unter **CloudWatch Protokollierung** das Kontrollkästchen neben **Aktivieren**.
1. Wählen Sie die Option **Sitzungsungsprotokolle streamen** aus.
1. (Empfohlen) Aktivieren Sie das Kontrollkästchen neben **Nur verschlüsselte CloudWatch Protokollgruppen zulassen**. Wenn diese Funktion aktiviert ist, werden die Protokolldaten mithilfe des serverseitigen Verschlüsselungsschlüssels, der für die Protokollgruppe angegeben wurde, verschlüsselt. Wenn Sie die Protokolldaten, die an CloudWatch Logs gesendet werden, nicht verschlüsseln möchten, deaktivieren Sie das Kontrollkästchen. Außerdem müssen Sie das Kontrollkästchen deaktivieren, wenn die Verschlüsselung für die Protokollgruppe nicht aktiviert ist.
1. Wählen Sie für **CloudWatch Protokolle** eine der folgenden Optionen aus, AWS-Konto um die bestehende CloudWatch Protokollgruppe Logs in die Sie die Sitzungsprotokolle hochladen möchten, anzugeben:
+ Geben Sie den Namen einer bereits in Ihrem Konto erstellten Protokollgruppe in das Textfeld ein, um die Sitzungsprotokolldaten zu speichern.
+ **Protokollgruppen durchsuchen**: Wählen Sie eine bereits in Ihrem Konto erstellte Protokollgruppe aus, um die Sitzungsprotokolldaten zu speichern.
1. Wählen Sie **Speichern**.
# Protokollieren von Sitzungsdaten mithilfe von Amazon S3 (Konsole)
Sie können Sitzungsprotokolldaten zu Debugging- und Fehlerbehebungszwecken in einem angegebenen Amazon Simple Storage Service (Amazon S3)-Bucket speichern. Standardmäßig werden Protokolle an einen verschlüsselten Amazon S3-Bucket gesendet. Die Verschlüsselung erfolgt mit dem für den Bucket angegebenen Schlüssel, entweder einem AWS KMS key oder einem Amazon S3 S3-Schlüssel für serverseitige Verschlüsselung (SSE) (AES-256).
**Wichtig**
Bei Verwendung von Buckets im Stil eines virtuellen Hostings mit SSL (Secure Sockets Layer) stimmt das SSL-Wildcard-Zertifikat nur mit Buckets überein, die keine Punkte enthalten. Um dies zu umgehen, verwenden Sie HTTP oder schreiben Sie Ihre eigene Logik zur Verifizierung von Zertifikaten. Wir empfehlen, bei der Verwendung von Buckets im Stil des virtuellen Hostings keine Punkte („.“) in Bucket-Namen zu verwenden.
**Verschlüsselung von Amazon S3-Bucket**
Um Protokolle mit Verschlüsselung an Ihren Amazon S3-Bucket senden zu können, muss die Verschlüsselungsfunktion für den Bucket aktiviert sein. Weitere Informationen zur Amazon S3 Bucket-Verschlüsselung finden Sie unter [Amazon S3-Standardverschlüsselung für S3-Buckets](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html).
**Kundenseitig verwalteter Schlüssel**
Wenn Sie zum Verschlüsseln Ihres Buckets einen KMS-Schlüssel verwenden, den Sie selbst verwalten, muss das Ihren Instances angefügte IAM-Instance-Profil explizite Berechtigungen zum Lesen des Schlüssels besitzen. Wenn Sie einen verwenden Von AWS verwalteter Schlüssel, benötigt die Instance diese ausdrückliche Genehmigung nicht. Weitere Informationen zum Bereitstellen des Instance-Profils mit Zugriff auf die Verwendung des Schlüssels finden Sie unter [Gestattet Schlüsselbenutzern die Verwendung des Schlüssels](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default-allow-users) im *AWS Key Management Service -Entwicklerhandbuch*.
Gehen Sie wie folgt vor, um Session Manager zum Speichern von Sitzungsprotokollen im Amazon S3-Bucket zu konfigurieren.
**Anmerkung**
Sie können den auch verwenden AWS CLI , um den Amazon S3 S3-Bucket anzugeben oder zu ändern, an den Sitzungsdaten gesendet werden. Weitere Informationen finden Sie unter [Aktualisieren von Session Manager-Einstellungen (Befehlszeile)](getting-started-configure-preferences-cli.md).
**Protokollieren von Sitzungsdaten mithilfe von Amazon S3 (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Präferenzen** und anschließend **Bearbeiten** aus.
1. Wählen Sie bei **S3-Protokollierung** neben **Aktivieren** das Kontrollkästchen aus.
1. (Empfohlen) Aktivieren Sie das Kontrollkästchen neben **Nur verschlüsselte S3-Buckets zulassen**. Wenn diese Funktion aktiviert ist, werden die Protokolldaten mithilfe des serverseitigen Verschlüsselungsschlüssels, der für den Bucket angegeben wurde, verschlüsselt. Wenn Sie die an Amazon S3 gesendeten Protokolldaten nicht verschlüsseln möchten, aktivieren Sie das Kontrollkästchen. Außerdem müssen Sie das Kontrollkästchen deaktivieren, wenn die Verschlüsselung für den S3-Bucket nicht aktiviert ist.
1. Wählen Sie in **S3 bucket name (Name des S3-Buckets)** eine der folgenden Optionen aus:
**Anmerkung**
Wir empfehlen, bei der Verwendung von Buckets im Stil des virtuellen Hostings keine Punkte („.“) in Bucket-Namen zu verwenden. Weitere Informationen zu Namenskonventionen für Amazon-S3-Buckets finden Sie unter [Bucket-Einschränkungen und -Limits](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
+ **Choose a bucket name from the list (Bucket-Namen aus der Liste auswählen)**: Wählen Sie einen bereits in Ihrem Konto erstellten Amazon S3-Bucket aus, um Sitzungsprotokolldaten zu speichern.
+ **Enter a bucket name in the text box (Geben Sie einen Namen für den Bucket in das Textfeld ein)**: Geben Sie den Namen eines bereits in Ihrem Konto erstellten Amazon S3-Buckets ein, um Sitzungsprotokolldaten zu speichern.
1. (Optional) Geben Sie in **S3 key prefix (S3-Schlüsselpräfix)** den Namen eines vorhandenen oder neuen Ordners ein, in dem die Protokolle im ausgewählten Bucket gespeichert werden sollen.
1. Wählen Sie **Speichern**.
Weitere Informationen zum Arbeiten mit Amazon S3 und Amazon-S3-Buckets finden Sie im *[Benutzerhandbuch zu Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)* und im *[Benutzerhandbuch zu Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/)*.
# Protokollierung von Sitzungsdaten mit Amazon CloudWatch Logs (Konsole)
Mit Amazon CloudWatch Logs können Sie Protokolldateien aus verschiedenen Quellen überwachen, speichern und darauf zugreifen AWS-Services. Sie können Sitzungsprotokolldaten zu Debugging- und Fehlerbehebungszwecken an eine CloudWatch Logs-Protokollgruppe senden. Standardmäßig werden Protokolldaten nach Verschlüsselung mit Ihrem KMS-Schlüssel gesendet. Sie können die Daten jedoch mit oder ohne Verschlüsselung an ihre Protokollgruppe senden.
Gehen Sie wie folgt vor, um AWS Systems Manager Session Manager zu konfigurieren, dass Sitzungsprotokolldaten am Ende Ihrer Sitzungen an eine CloudWatch Logs-Protokollgruppe gesendet werden.
**Anmerkung**
Sie können den auch verwenden AWS CLI , um die CloudWatch Logs-Protokollgruppe anzugeben oder zu ändern, an die Sitzungsdaten gesendet werden. Weitere Informationen finden Sie unter [Aktualisieren von Session Manager-Einstellungen (Befehlszeile)](getting-started-configure-preferences-cli.md).
**So protokollieren Sie Sitzungsdaten mit Amazon CloudWatch Logs (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Präferenzen** und anschließend **Bearbeiten** aus.
1. Aktivieren Sie unter **CloudWatch Protokollierung** das Kontrollkästchen neben **Aktivieren**.
1. Wählen Sie die Option **Sitzungsungsprotokolle hochladen** aus.
1. (Empfohlen) Aktivieren Sie das Kontrollkästchen neben **Nur verschlüsselte CloudWatch Protokollgruppen zulassen**. Wenn diese Funktion aktiviert ist, werden die Protokolldaten mithilfe des serverseitigen Verschlüsselungsschlüssels, der für die Protokollgruppe angegeben wurde, verschlüsselt. Wenn Sie die Protokolldaten, die an CloudWatch Logs gesendet werden, nicht verschlüsseln möchten, deaktivieren Sie das Kontrollkästchen. Außerdem müssen Sie das Kontrollkästchen deaktivieren, wenn die Verschlüsselung für die Protokollgruppe nicht aktiviert ist.
1. Wählen Sie für **CloudWatch Protokolle** eine der folgenden Optionen aus, AWS-Konto um die bestehende CloudWatch Protokollgruppe Logs in die Sie die Sitzungsprotokolle hochladen möchten, anzugeben:
+ **Choose a log group from the list (Eine Protokollgruppe aus der Liste auswählen)**: Wählen Sie eine bereits in Ihrem Konto erstellte Protokollgruppe aus, in die die Sitzungsprotokolldaten gespeichert werden sollen.
+ **Enter a log group name in the text box (Geben Sie den Namen einer Protokollgruppe in das Textfeld ein)**: Geben Sie den Namen einer bereits in Ihrem Konto erstellten Protokollgruppe ein, in die die Sitzungsprotokolldaten gespeichert werden sollen.
1. Wählen Sie **Speichern**.
Weitere Informationen zur Arbeit mit CloudWatch Logs finden Sie im *[Amazon CloudWatch Logs-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/)*.
# Konfigurieren der Sitzungsprotokollierung auf Festplatte
Nachdem Sie die Session Manager Protokollierung bei Amazon S3 CloudWatch oder Amazon S3 aktiviert haben, werden alle während einer Sitzung ausgeführten Befehle (und die daraus resultierenden Ausgaben) in einer temporären Datei auf der Festplatte der Ziel-Instance protokolliert. Die temporäre Datei hat den Namen `ipcTempFile.log`.
`ipcTempFile.log` wird durch den `SessionLogsDestination`-Parameter in der SSM Agent-Konfigurationsdatei gesteuert. Dieser Parameter akzeptiert die folgenden Werte:
+ **Festplatte**: Wenn Sie diesen Parameter angeben und die Sitzungsprotokollierung auf CloudWatch oder Amazon S3 *aktiviert ist*, SSM Agent erstellt die `ipcTempFile.log` temporäre Protokolldatei und protokolliert Sitzungsbefehle sowie die Ausgabe auf der Festplatte. Session Managerlädt dieses Protokoll je nach Protokollierungskonfiguration während oder nach der Sitzung entweder CloudWatch auf S3 hoch. Das Protokoll wird dann entsprechend der für den SSM Agent `SessionLogsRetentionDurationHours` Konfigurationsparameter angegebenen Dauer gelöscht.
Wenn Sie diesen Parameter angeben und die Sitzungsprotokollierung bei Amazon S3 *deaktiviert* ist, werden SSM Agent trotzdem der Befehlsverlauf und die Ausgabe in der `ipcTempFile.log` Datei protokolliert. CloudWatch Die Datei wird entsprechend der für den SSM Agent `SessionLogsRetentionDurationHours` Konfigurationsparameter angegebenen Dauer gelöscht.
+ **none**: Wenn Sie diesen Parameter angeben und die Sitzungsprotokollierung bei CloudWatch oder Amazon S3 *aktiviert ist*, funktioniert die Protokollierung auf der Festplatte genauso, als ob Sie den `disk` Parameter angegeben hätten. SSM Agentbenötigt die temporäre Datei, wenn die Sitzungsprotokollierung bei CloudWatch oder Amazon S3 aktiviert ist.
Wenn Sie diesen Parameter angeben und die Sitzungsprotokollierung bei CloudWatch oder Amazon S3 *deaktiviert* SSM Agent ist, wird die `ipcTempFile.log` Datei nicht erstellt.
Gehen Sie wie folgt vor, um die Erstellung der `ipcTempFile.log`-temporären Protokolldatei auf der Festplatte zu aktivieren oder zu deaktivieren, wenn eine Sitzung gestartet wird.
**Um die Erstellung der Session Manager-temporären Protokolldatei auf der Festplatte zu aktivieren oder zu deaktivieren**
1. Installieren Sie SSM Agent entweder auf Ihrer Instance oder führen Sie ein Upgrade auf Version 3.2.2086 oder höher durch. Weitere Informationen zum Überprüfen der Agent-Versionsnummer finden Sie unter [Überprüfen der SSM Agent-Versionsnummer](ssm-agent-get-version.md). Informationen zur manuellen Installation des Agenten finden Sie in den folgenden Abschnitten nach dem Verfahren für Ihr Betriebssystem:
+ [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für Linux](manually-install-ssm-agent-linux.md)
+ [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für macOS](manually-install-ssm-agent-macos.md)
+ [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für Windows Server](manually-install-ssm-agent-windows.md)
1. Erstellen Sie eine Verbindung zu Ihrer Instance und suchen Sie die `amazon-ssm-agent.json`-Datei am folgenden Speicherort.
+ **Linux**:/etc/amazon/ssm/
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
Wenn die Datei `amazon-ssm-agent.json` nicht existiert, kopieren Sie den Inhalt von `amazon-ssm-agent.json.template` in eine neue Datei im selben Verzeichnis. Benennen Sie die Datei `amazon-ssm-agent.json`.
1. Geben Sie entweder `none` oder `disk` für den `SessionLogsDestination`-Parameter an. Speichern Sie Ihre Änderungen.
1. [Starten Sie SSM Agent neu](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
Wenn Sie `disk` für den `SessionLogsDestination`-Parameter angegeben haben, können Sie überprüfen, ob die temporäre Protokolldatei SSM Agent erstellt wird, indem Sie eine neue Sitzung starten und die `ipcTempFile.log`-Datei dann am folgenden Speicherort suchen:
+ **Linux**://var/lib/amazon/ssm*target ID*/Sitzung/Orchestration/ *session ID* /Standard\$1Stream/ .log ipcTempFile
+ **macOS**: opt/aws/ssm/data*target ID*/*session ID*/sitzung/orchestration/ ipcTempFile /Standard\$1Stream/ .log
+ **Windows Server**: C:\$1\$1 AmazonProgramData\$1 SSM\$1\$1 SitzungInstanceData\$1 *target ID* Orchestrierung\$1\$1 Standard\$1Stream*session ID*\$1 .log ipcTempFile
**Anmerkung**
Standardmäßig wird die temporäre Protokolldatei 14 Tage lang auf der Instance gespeichert.
Wenn Sie den `SessionLogsDestination`-Parameter für mehrere Instances aktualisieren möchten, empfehlen wir Ihnen, ein SSM-Dokument zu erstellen, das die neue Konfiguration spezifiziert. Anschließend können Sie Systems Manager Run Command verwenden, um die Änderung auf Ihren Instances zu implementieren. Weitere Informationen finden Sie unter [Eigene AWS Systems Manager Dokumente schreiben (Blog](https://aws.amazon.com/blogs/mt/writing-your-own-aws-systems-manager-documents/)) und. [Ausführen von Befehlen auf verwalteten Knoten](running-commands.md)
# Anpassen, wie lange die Session Manager temporäre Protokolldatei auf der Festplatte gespeichert wird
Nachdem Sie die Session Manager Protokollierung bei Amazon S3 CloudWatch oder Amazon S3 aktiviert haben, werden alle während einer Sitzung ausgeführten Befehle (und die daraus resultierenden Ausgaben) in einer temporären Datei auf der Festplatte der Ziel-Instance protokolliert. Die temporäre Datei hat den Namen `ipcTempFile.log`. Session ManagerLädt dieses temporäre Protokoll während einer Sitzung oder nach deren Abschluss entweder CloudWatch auf S3 hoch. Das temporäre Protokoll wird dann entsprechend der für den SSM Agent `SessionLogsRetentionDurationHours` Konfigurationsparameter angegebenen Dauer gelöscht. Standardmäßig wird die temporäre Protokolldatei 14 Tage lang am folgenden Speicherort auf der Instance gespeichert:
+ **Linux**:/var/lib/amazon/ssm*target ID*/session/orchestration/ *session ID* /Standard\$1Stream/ .log ipcTempFile
+ **macOS**: opt/aws/ssm/data*target ID*/*session ID*/sitzung/orchestration/ ipcTempFile /Standard\$1Stream/ .log
+ **Windows Server**: C:\$1\$1 AmazonProgramData\$1 SSM\$1\$1 SitzungInstanceData\$1 *target ID* Orchestrierung\$1\$1 Standard\$1Stream*session ID*\$1 .log ipcTempFile
Gehen Sie wie folgt vor, um einzustellen, wie lange die Session Manager temporäre Protokolldatei auf der Festplatte gespeichert wird.
**Um einzustellen, wie lange die `ipcTempFile.log`-Datei auf der Festplatte gespeichert wird**
1. Erstellen Sie eine Verbindung zu Ihrer Instance und suchen Sie die `amazon-ssm-agent.json`-Datei am folgenden Speicherort.
+ etc/amazon/ssmLinux**:**//
+ **macOS**: /opt/aws/ssm/
+ **Windows Server**: C:\$1Program Files\$1Amazon\$1SSM
Wenn die Datei `amazon-ssm-agent.json` nicht existiert, kopieren Sie den Inhalt von `amazon-ssm-agent.json.template` in eine neue Datei im selben Verzeichnis. Benennen Sie die Datei `amazon-ssm-agent.json`.
1. Ändern Sie den Wert von `SessionLogsRetentionDurationHours` auf die gewünschte Anzahl von Stunden. Wenn `SessionLogsRetentionDurationHours` auf 0 gesetzt ist, wird die temporäre Protokolldatei während der Sitzung erstellt und nach Abschluss der Sitzung gelöscht. Diese Einstellung sollte sicherstellen, dass die Protokolldatei nach dem Ende der Sitzung nicht erhalten bleibt.
1. Speichern Sie Ihre Änderungen.
1. [Starten Sie SSM Agent neu](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-status-and-restart.html).
# Deaktivierung der Session Manager Protokollierung in CloudWatch Logs und Amazon S3
Sie können die Systems Manager Manager-Konsole verwenden oder AWS CLI die Sitzungsprotokollierung in Ihrem Konto deaktivieren.
**So deaktivieren Sie die Sitzungsprotokollierung (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Session Manager** aus.
1. Wählen Sie die Registerkarte **Präferenzen** und anschließend **Bearbeiten** aus.
1. Um die CloudWatch Protokollierung zu deaktivieren, deaktivieren **CloudWatch Sie im Bereich Protokollierung** das Kontrollkästchen **Aktivieren**.
1. Um die S3-Protokollierung zu deaktivieren, deaktivieren Sie im Abschnitt **S3-Protokollierung** das Kontrollkästchen **Aktivieren**.
1. Wählen Sie **Speichern**.
**So können Sie Sitzungsprotokollierung deaktivieren (AWS CLI)**
Um die Sitzungsprotokollierung mit dem zu deaktivieren AWS CLI, folgen Sie den Anweisungen unter[Aktualisieren von Session Manager-Einstellungen (Befehlszeile)](getting-started-configure-preferences-cli.md).
Stellen Sie in Ihrer JSON-Datei sicher, dass die Eingaben `s3BucketName` und `cloudWatchLogGroupName` keine Werte enthalten. Beispiel:
```
"inputs": {
"s3BucketName": "",
...
"cloudWatchLogGroupName": "",
...
}
```
Alternativ können Sie, um die Protokollierung zu deaktivieren, alle `S3*` und `cloudWatch*` Eingaben aus Ihrer JSON-Datei entfernen, um die Protokollierung zu deaktivieren.
**Anmerkung**
Abhängig von Ihrer Konfiguration kann es sein, dass nach der Deaktivierung CloudWatch von S3 immer noch eine temporäre Protokolldatei auf der Festplatte von generiert wirdSSM Agent. Weitere Informationen, wie Sie die Protokollierung auf der Festplatte deaktivieren können, finden Sie unter [Konfigurieren der Sitzungsprotokollierung auf Festplatte](session-manager-logging-disk.md).
# Schema des Sitzungsdokuments
In den folgenden Informationen werden die Schemaelemente eines Sitzungsdokuments beschrieben. AWS Systems Manager Session Manager verwendet Sitzungsdokumente, um zu bestimmen, welche Art von Sitzung gestartet werden soll, z. B. eine Standardsitzung, eine Port-Weiterleitungssitzung oder eine Sitzung zum Ausführen eines interaktiven Befehls.
[schemaVersion](#version)
Die Schemaversion des Sitzungsdokuments. Sitzungsdokumente unterstützen nur die Version 1.0.
**Typ:** Zeichenfolge
Erforderlich: Ja
[description](#descript)
Eine Beschreibung, die Sie für das Sitzungsdokument angeben. Beispiel: „Dokument zum Starten der Port-Weiterleitungssitzung mit Session Manager“.
**Typ:** Zeichenfolge
Erforderlich: Nein
[sessionType](#type)
Der Sitzungstyp, mit dem das Sitzungsdokument erstellt wird.
**Typ:** Zeichenfolge
Erforderlich: Ja
Zulässige Werte: `InteractiveCommands` \$1 `NonInteractiveCommands` \$1 `Port` \$1 `Standard_Stream`
[inputs](#in)
Die Sitzungseinstellungen, die für Sitzungen verwendet werden, die mit diesem Sitzungsdokument erstellt wurden. Dieses Element ist für Sitzungsdokumente erforderlich, die zum Erstellen von `Standard_Stream`-Sitzungen verwendet werden.
Typ: StringMap
Erforderlich: Nein
[s3BucketName](#bucket)
Der Amazon Simple Storage Service (Amazon S3)-Bucket, an den Sie am Ende Ihrer Sitzungen Sitzungsprotokolle senden möchten.
**Typ:** Zeichenfolge
Erforderlich: Nein
[s3KeyPrefix](#prefix)
Das Präfix, das beim Senden von Protokollen an den Amazon S3-Bucket verwendet werden soll, den Sie in der `s3BucketName`-Eingabe angegeben haben. Weitere Hinweise zur Verwendung eines freigegebenen Präfixes für in Amazon S3 gespeicherte Objekte finden Sie unter [Wie kann ich Ordner in einem S3-Bucket verwenden?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/using-folders.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
**Typ:** Zeichenfolge
Erforderlich: Nein
[s3EncryptionEnabled](#s3Encrypt)
Wenn auf `true` eingestellt ist, muss der Amazon S3-Bucket, den Sie in der `s3BucketName`-Eingabe angegeben haben, verschlüsselt werden.
Typ: Boolesch
Erforderlich: Ja
[cloudWatchLogGroupName](#logGroup)
Der Name der Amazon CloudWatch Logs (CloudWatch Logs)-Gruppe, an die Sie am Ende Ihrer Sitzungen Sitzungsprotokolle senden möchten.
**Typ:** Zeichenfolge
Erforderlich: Nein
[cloudWatchEncryptionEnabled](#cwEncrypt)
Wenn auf `true` eingestellt ist, muss die Protokollgruppe, die Sie in der `cloudWatchLogGroupName`-Eingabe angegeben haben, verschlüsselt werden.
Typ: Boolesch
Erforderlich: Ja
[cloudWatchStreamingEnabled](#cwStream)
Wenn auf `true` eingestellt ist, wird ein kontinuierlicher Stream von Sitzungsdaten an die Protokollgruppe gesendet, die Sie in der `cloudWatchLogGroupName`-Eingabe angegeben haben. Wenn auf `false` eingestellt ist, werden Sitzungsprotokolle am Ende Ihrer Sitzungen an die Protokollgruppe gesendet, die Sie in der `cloudWatchLogGroupName`-Eingabe angegeben haben.
Typ: Boolesch
Erforderlich: Ja
[kmsKeyId](#kms)
Die ID des AWS KMS key, den Sie verwenden möchten, um Daten zwischen dem lokalen Client-Maschinen und den von Amazon Elastic Compute Cloud (Amazon EC2) verwalteten Knoten, zu denen Sie eine Verbindung herstellen, weiter zu verschlüsseln.
**Typ:** Zeichenfolge
Erforderlich: Nein
[runAsEnabled](#run)
Wenn auf `true` eingestellt ist, müssen Sie in der `runAsDefaultUser`-Eingabe ein Benutzerkonto angeben, das auf den verwalteten Knoten vorhanden ist, mit denen Sie eine Verbindung herstellen möchten. Andernfalls können Sitzungen nicht gestartet werden. Standardmäßig werden Sitzungen mit dem von AWS Systems Manager SSM Agent erstellten `ssm-user`-Konto gestartet. Das Run-As-Feature wird nur für die Verbindung mit Linux und macOS-verwalteten Knoten unterstützt.
Typ: Boolesch
Erforderlich: Ja
[runAsDefaultUser](#runUser)
Der Name des Benutzerkontos, mit dem Sitzungen auf Linux- und macOS-verwalteten Knoten gestartet werden sollen, wenn die `runAsEnabled`-Eingabe auf `true` eingestellt ist. Das Benutzerkonto, das Sie für diese Eingabe angeben, muss auf den verwalteten Knoten vorhanden sein, mit denen Sie eine Verbindung herstellen möchten. Andernfalls können Sitzungen nicht gestartet werden.
**Typ:** Zeichenfolge
Erforderlich: Nein
[idleSessionTimeout](#timeout)
Die Zeit der Inaktivität, die Sie zulassen möchten, bevor eine Sitzung beendet wird. Diese Eingabe wird in Minuten gemessen.
**Typ:** Zeichenfolge
Zulässige Werte: 1 bis 60
Erforderlich: Nein
[maxSessionDuration](#maxDuration)
Die maximale Zeit, die Sie erlauben möchten, bevor eine Sitzung beendet wird. Diese Eingabe wird in Minuten gemessen.
**Typ:** Zeichenfolge
Zulässige Werte: 1–1 440
Erforderlich: Nein
[shellProfile](#shell)
Die Einstellungen, die Sie pro Betriebssystem angeben und die in Sitzungen angewendet werden, wie Shell-Einstellungen, Umgebungsvariablen, Arbeitsverzeichnissen und das Ausführen mehrerer Befehle.
Typ: StringMap
Erforderlich: Nein
[windows](#win)
Die Shell-Einstellungen, Umgebungsvariablen, Arbeitsverzeichnisse und Befehle, die Sie für Sitzungen auf Windows Server-verwalteten Knoten angeben.
**Typ:** Zeichenfolge
Erforderlich: Nein
[linux](#lin)
Die Shell-Einstellungen, Umgebungsvariablen, Arbeitsverzeichnisse und Befehle, die Sie für Sitzungen auf Linux- und macOS-verwalteten Knoten angeben.
**Typ:** Zeichenfolge
Erforderlich: Nein
[parameters](#param)
Ein Objekt, das die Parameter definiert, die das Dokument akzeptiert. Weitere Informationen zum Definieren von Dokumentparametern finden Sie unter **Parameter** im [Top-Level-Datenelemente](documents-syntax-data-elements-parameters.md#top-level). Wir empfehlen, Parameter, auf die Sie häufig verweisen, im Systems Manager Parameter Store abzuspeichern und dann auf sie zu verweisen. In diesem Abschnitt des Dokuments können Sie die Parameter Store-Parameter `String` und `StringList` referenzieren. In diesem Abschnitt des Dokuments können Sie die Parameter Store-Parameter `SecureString` nicht referenzieren. Sie können über das folgende Format einen Parameter Store-Parameter referenzieren.
```
{{ssm:parameter-name}}
```
Mehr über Parameter Store erfahren Sie unter [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md).
Typ: StringMap
Erforderlich: Nein
[properties](#props)
Ein Objekt, dessen Werte Sie angeben, die in der `StartSession` API-Operation verwendet werden.
Für Sitzungsdokumente, die für `InteractiveCommands`-Sitzungen verwendet werden,enthält das Eigenschaftenobjekt die Befehle, die auf den von Ihnen angegebenen Betriebssystemen ausgeführt werden sollen. Mit der `runAsElevated` booleschen Eigenschaft können Sie auch festlegen, ob Befehle als `root` ausgeführt werden. Weitere Informationen finden Sie unter [Zugriff auf Befehle in einer Sitzung beschränken](session-manager-restrict-command-access.md).
Für Sitzungsdokumente, die für `Port`-Sitzungen verwendet werden, enthält das Eigenschaftenobjekt die Portnummer, an die der Datenverkehr umgeleitet werden soll. Ein Beispiel ist das Beispiel zum Sitzungsdokument des Typs `Port` an späterer Stelle in diesem Thema.
Typ: StringMap
Erforderlich: Nein
Beispiel für Sitzungsdokument vom Typ `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"
}
}
}
```
------
Beispiel für Sitzungsdokument vom Typ `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
}
}
}
```
------
Beispiel für Sitzungsdokument vom Typ `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"
}
}
```
------
Beispiel für Sitzungsdokument mit Sonderzeichen
------
#### [ 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
}
}
}
```
------
# Fehlerbehebung für Session Manager
Im Folgenden finden Sie Informationen zur Behandlung von Problemen mit AWS Systems Manager Session Manager.
**Topics**
+ [AccessDeniedException beim Aufrufen der TerminateSession Operation](#session-manager-troubleshooting-access-denied-exception)
+ [Der Dokumentvorgang ist unerwartet fehlgeschlagen: Zeitlimit für den Dokumentenarbeiter überschritten](#session-manager-troubleshooting-document-worker-timed-out)
+ [Session Manager kann von der Amazon-EC2-Konsole aus keine Verbindung herstellen](#session-manager-troubleshooting-EC2-console)
+ [Keine Berechtigung zum Starten einer Sitzung](#session-manager-troubleshooting-start-permissions)
+ [SSM Agent nicht online](#session-manager-troubleshooting-agent-not-online)
+ [Keine Berechtigung zum Ändern von Sitzungspräferenzen](#session-manager-troubleshooting-preferences-permissions)
+ [Verwalteter Knoten ist nicht verfügbar oder nicht für Session Manager konfiguriert](#session-manager-troubleshooting-instances)
+ [Session Manager-Plugin nicht gefunden](#plugin-not-found)
+ [Session Manager-Plugin wurde nicht automatisch zumBefehlszeilenpfad hinzugefügt (Windows)](#windows-plugin-env-var-not-set)
+ [Session Manager-Plugin reagiert nicht mehr](#plugin-unresponsive)
+ [TargetNotConnected](#ssh-target-not-connected)
+ [Nach dem Starten einer Sitzung wird ein leerer Bildschirm angezeigt](#session-manager-troubleshooting-start-blank-screen)
+ [Verwalteter Knoten reagiert während langer Sitzungen nicht mehr](#session-manager-troubleshooting-log-retention)
+ [Beim Aufrufen des Vorgangs ist ein Fehler aufgetreten (InvalidDocument) StartSession](#session-manager-troubleshooting-invalid-document)
## AccessDeniedException beim Aufrufen der TerminateSession Operation
**Problem**: Beim versuchten Beenden einer Sitzung gibt Systems Manager den folgenden Fehler zurück:
```
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.
```
**Lösung A: Stellen Sie sicher, dass die [neueste Version des Session Manager-Plug-ins](https://docs.aws.amazon.com/systems-manager/latest/userguide/plugin-version-history.html) auf dem Knoten installiert ist**
Geben Sie im Terminal den folgenden Befehl ein und drücken Sie anschließend die Eingabetaste.
```
session-manager-plugin --version
```
**Lösung B: Installieren oder reinstallieren Sie die neueste Version des Plugins**
Weitere Informationen finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md).
**Lösung C: Versuchen Sie, eine Verbindung zum Knoten wiederherzustellen**
Stellen Sie sicher, dass der Knoten auf Anfragen reagiert. Versuchen Sie, die Sitzung wiederherzustellen. Oder öffnen Sie bei Bedarf die Amazon-EC2-Konsole und überprüfen Sie, dass die Instance ausgeführt wird.
## Der Dokumentvorgang ist unerwartet fehlgeschlagen: Zeitlimit für den Dokumentenarbeiter überschritten
**Problem**: Beim Starten einer Sitzung auf einem Linux-Host gibt Systems Manager den folgenden Fehler zurück:
```
document process failed unexpectedly: document worker timed out,
check [ssm-document-worker]/[ssm-session-worker] log for crash reason
```
Wenn Sie die SSM Agent-Protokollierung wie unter [Anzeigen von SSM Agent-Protokollen](ssm-agent-logs.md) beschrieben konfiguriert haben, können Sie weitere Details im Debugging-Protokoll einsehen. Für dieses Problem zeigt Session Manager den folgende Protokolleintrag an:
```
failed to create channel: too many open files
```
Dieser Fehler weist in der Regel darauf hin, dass zu viele Session Manager-Arbeitsprozesse ausgeführt werden und das zugrunde liegende Betriebssystem ein Limit erreicht hat. Sie haben zwei Möglichkeiten, dieses Problem zu lösen.
**Lösung A: Das Limit für Dateibenachrichtigungen im Betriebssystem erhöhen**
Sie können das Limit erhöhen, indem Sie den folgenden Befehl von einem separaten Linux-Host aus ausführen. Dieser Befehl verwendet Systems Manager Run Command. Der angegebene Wert erhöht sich `max_user_instances` auf 8 192. Dieser Wert ist erheblich höher als der Standardwert 128, belastet aber die Hostressourcen nicht:
```
aws ssm send-command --document-name AWS-RunShellScript \
--instance-id i-02573cafcfEXAMPLE --parameters \
"commands=sudo sysctl fs.inotify.max_user_instances=8192"
```
**Lösung B: Die von Session Manager im Zielhost verwendeten Dateibenachrichtigungen reduzieren**
Führen Sie den folgenden Befehl von einem separaten Linux-Host aus, um die auf dem Zielhost laufenden Sitzungen aufzulisten:
```
aws ssm describe-sessions --state Active --filters key=Target,value=i-02573cafcfEXAMPLE
```
Überprüfen Sie die Befehlsausgabe, um nicht mehr benötigte Sitzungen zu identifizieren. Sie können diese Sitzung beenden, indem Sie den folgenden Befehl von einem separaten Linux-Host ausführen:
```
aws ssm terminate-session —session-id session ID
```
Wenn auf dem Remoteserver keine weiteren Sitzungen mehr laufen, können Sie optional zusätzliche Ressourcen freigeben, indem Sie den folgenden Befehl von einem separaten Linux-Host aus ausführen. Dieser Befehl beendet alle Session Manager-Prozesse, die auf dem Remote-Host ausgeführt werden, und folglich alle Sitzungen auf dem Remote-Host. Bevor Sie diesen Befehl ausführen, stellen Sie sicher, dass keine laufenden Sitzungen vorhanden sind, die Sie behalten möchten:
```
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 kann von der Amazon-EC2-Konsole aus keine Verbindung herstellen
**Problem**: Nach der Erstellung einer neuen Instance bietet Ihnen die **Connect**-Schaltfläche > **Session Manager**-Registerkarte in der Konsole von Amazon Elastic Compute Cloud (Amazon EC2) nicht die Möglichkeit, sich zu verbinden.
**Lösung A: Erstellen Sie ein Instanzprofil**: Falls Sie dies noch nicht getan haben (wie in den Informationen auf der Registerkarte „**Session Manager**“ in der EC2-Konsole beschrieben), erstellen Sie ein AWS Identity and Access Management (IAM-) Instanzprofil mithilfe von. Quick Setup Quick Setupist ein Tool in. AWS Systems Manager
Session Manager erfordert ein IAM-Instance-Profil, um eine Verbindung zu Ihrer Instance herzustellen. Sie können ein Instance-Profil erstellen und es Ihrer Instance zuweisen, indem Sie eine [Host-Verwaltungs-Konfiguration](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-host-management.html) mit Quick Setup erstellen. Eine *Host-Verwaltungs-Konfiguration* erstellt ein Instance-Profil mit den erforderlichen Berechtigungen und weist es Ihrer Instance zu. Eine Host-Verwaltungs-Konfiguration ermöglicht auch andere Systems-Manager-Tools und erstellt IAM-Rollen für die Ausführung dieser Tools. Die Nutzung von Quick Setup oder der Tools, die durch die Host-Verwaltungs-Konfiguration aktiviert werden, ist kostenlos. [Öffnen Sie Quick Setup und erstellen Sie eine Host-Verwaltungs-Konfiguration](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt).
**Wichtig**
Nachdem Sie die Host-Verwaltungs-Konfiguration erstellt haben, kann es einige Minuten dauern, bis Amazon EC2 die Änderung registriert und die Registerkarte **Session Manager** aktualisiert hat. Wenn auf der Registerkarte nach zwei Minuten keine Schaltfläche **Verbinden** angezeigt wird, starten Sie Ihre Instance neu. Wenn nach dem Neustart immer noch keine Verbindungsoption angezeigt wird, öffnen Sie [Quick Setup](https://console.aws.amazon.com/systems-manager/quick-setup/create-configuration&configurationType=SSMHostMgmt) und überprüfen Sie, dass Sie nur eine Hostverwaltungskonfiguration haben. Wenn es zwei gibt, löschen Sie die ältere Konfiguration und warten Sie einige Minuten.
Wenn Sie nach dem Erstellen einer Host-Verwaltungs-Konfiguration immer noch keine Verbindung herstellen können oder wenn Sie eine Fehlermeldung erhalten, einschließlich einer Fehlermeldung zu SSM Agent, nutzen Sie eine der folgenden Lösungen:
+ [Lösung B: Kein Fehler, aber es kann immer noch keine Verbindung hergestellt werden](#session-manager-troubleshooting-EC2-console-no-error)
+ [Lösung C: Fehler wegen fehlendem SSM Agent](#session-manager-troubleshooting-EC2-console-no-agent)
### Lösung B: Kein Fehler, aber es kann immer noch keine Verbindung hergestellt werden
Wenn Sie die Host-Verwaltungs-Konfiguration erstellt haben, mehrere Minuten gewartet haben, bevor Sie versucht haben, eine Verbindung herzustellen, und immer noch keine Verbindung herstellen können, müssen Sie die Host-Management-Konfiguratio möglicherweise manuell auf Ihre Instance anwenden. Gehen Sie wie folgt vor, um eine Quick Setup Host-Verwaltungs-Konfiguration zu aktualisieren und Änderungen auf eine Instance anzuwenden.
**So aktualisieren Sie eine Host-Verwaltungs-Konfiguration mit Quick Setup**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **Quick Setup** aus.
1. Wählen Sie in der **Konfigurationsliste** die **Host-Verwaltungs-Konfiguration** aus, die Sie erstellt haben.
1. Wählen Sie **Aktionen** und wählen Sie dann **Konfiguration bearbeiten**.
1. Wählen Sie unten im Bereich **Ziele** unter **Wählen Sie aus, wie Sie auf Instances abzielen möchten** die Option **Manuell** aus.
1. Wählen Sie im Abschnitt **Instances** die Instance aus, die Sie erstellt haben.
1. Wählen Sie **Aktualisieren** aus.
Warten Sie einige Minuten, bis EC2 die Registerkarte **Session Manager** aktualisiert hat. Wenn Sie immer noch keine Verbindung herstellen können oder eine Fehlermeldung angezeigt wird, überprüfen Sie die verbleibenden Lösungen für dieses Problem.
### Lösung C: Fehler wegen fehlendem SSM Agent
Wenn Sie mithilfe von keine Host-Management-Konfiguration erstellen konnten oder wenn Sie eine Fehlermeldung erhalten habenQuick Setup, dass Sie SSM Agent nicht installiert wurden, müssen Sie die Installation möglicherweise manuell SSM Agent auf Ihrer Instance durchführen. SSM Agentist eine Amazon-Software, mit der Systems Manager mithilfe von eine Verbindung zu Ihrer Instance herstellen kannSession Manager. SSM Agentist standardmäßig auf den meisten Amazon Machine Images (AMIs) installiert. Wenn Ihre Instance aus einem nicht standardmäßigen AMI oder einem älteren AMI erstellt wurde, müssen Sie den Agenten möglicherweise manuell installieren. Informationen zum Installationsverfahren von SSM Agent finden Sie im folgenden Thema, das Ihrem Instance-Betriebssystem entspricht.
+ [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 und 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)
Bei Problemen mit SSM Agent siehe [Fehlerbehebung für SSM Agent](troubleshooting-ssm-agent.md).
## Keine Berechtigung zum Starten einer Sitzung
**Problem**: Sie versuchen, eine Sitzung zu starten. Das System teilt Ihnen jedoch mit, dass Sie nicht über die erforderlichen Berechtigungen verfügen.
+ **Lösung**: Ein Systemadministrator hat Ihnen keine AWS Identity and Access Management (IAM-) Richtlinienberechtigungen zum Starten von Session Manager Sitzungen erteilt. Weitere Informationen finden Sie unter [Kontrollieren des Sitzungszugriffs von Benutzern auf Instances](session-manager-getting-started-restrict-access.md).
## SSM Agent nicht online
**Problem**: Auf der Registerkarte Amazon-EC2-Instance **Session Manager** wird eine Meldung angezeigt, die besagt: „SSM Agent ist nicht online. SSM Agent konnte keine Verbindung zu einem Systems-Manager-Endpunkt herstellen, um sich beim Service zu registrieren.“
**Lösung**: SSM Agent ist Amazon-Software, die auf Amazon-EC2-Instances ausgeführt wird, sodass sie zu Session Manager eine Verbindung aufbauen kann. Wenn Sie diesen Fehler sehen, kann SSM Agent keine Verbindung mit dem Systems-Manager-Endpunkt herstellen. Die Ursache des Problems könnten Firewall-Einschränkungen, Routing-Probleme oder mangelnde Internetverbindung sein. Sie lösen dieses Problem, indem Sie die Probleme mit der Netzwerkverbindung untersuchen. Weitere Informationen erhalten Sie unter [Fehlerbehebung für SSM Agent](troubleshooting-ssm-agent.md) und [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md). Informationen zu Endpunkten von Systems Manager finden Sie unter [AWS Systems Manager -Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/ssm.html) in der Allgemeinen AWS -Referenz.
## Keine Berechtigung zum Ändern von Sitzungspräferenzen
**Problem**: Sie versuchen, globale Sitzungspräferenzen für Ihre Organisation zu aktualisieren. Das System teilt Ihnen jedoch mit, dass Sie nicht über die erforderlichen Berechtigungen verfügen.
+ **Lösung**: Ihnen wurden vom Systemadministrator keine IAM-Richtlinienberechtigungen zum Festlegen von Session Manager-Präferenzen erteilt. Weitere Informationen finden Sie unter [Gewähren oder Verweigern von Benutzerberechtigungen zum Aktualisieren von Session Manager-Einstellungen](preference-setting-permissions.md).
## Verwalteter Knoten ist nicht verfügbar oder nicht für Session Manager konfiguriert
**Problem 1**: Sie möchten auf der Seite **Start a session** (Sitzung starten) der Konsole eine Sitzung starten. Es befindet sich jedoch kein verwalteter Knoten in der Liste.
+ **Lösung A**: Der verwaltete Knoten, zu dem Sie eine Verbindung herstellen möchten, wurde möglicherweise nicht konfiguriert. AWS Systems Manager Weitere Informationen finden Sie unter [Einrichten der einheitlichen Systems-Manager-Konsole für eine Organisation](systems-manager-setting-up-organizations.md).
**Anmerkung**
Wenn er bereits auf einem verwalteten Knoten ausgeführt AWS Systems Manager SSM Agent wird, wenn Sie das IAM-Instanzprofil anhängen, müssen Sie den Agenten möglicherweise neu starten, bevor die Instanz auf der Seite **Sitzungskonsole starten** aufgeführt wird.
+ **Lösung B**: Die Proxy-Konfiguration, die Sie auf den SSM Agent auf Ihrem verwalteten Knoten angewendet haben, ist möglicherweise falsch. Wenn die Proxy-Konfiguration falsch ist, kann der verwaltete Knoten die erforderlichen Service-Endpunkte nicht erreichen, oder der Knoten meldet sich möglicherweise als anderes Betriebssystem beim Systems Manager. Weitere Informationen erhalten Sie unter [Konfigurieren Sie SSM Agent, um einen Proxy in Linux-Knoten zu verwenden](configure-proxy-ssm-agent.md) und [Konfigurieren des SSM Agent zur Nutzung eines Proxys für Windows Server-Instances](configure-proxy-ssm-agent-windows.md).
**Problem 2**: Ein verwalteter Knoten, mit dem Sie eine Verbindung herstellen möchten, befindet sich in der Liste auf der Seite **Start a session** (Sitzung starten) der Konsole. Die Seite meldet jedoch, dass „die von Ihnen ausgewählte Instance nicht für die Verwendung mit Session Manager konfiguriert wurde.“
+ **Lösung A**: Der verwaltete Knoten wurde für die Verwendung mit dem Systems-Manager-Service konfiguriert. Das dem Knoten angefügte IAM-Instance-Profil enthält jedoch möglicherweise keine Berechtigungen für das Session Manager-Tool. Informationen hierzu finden Sie unter [Überprüfen oder Erstellen eines IAM-Instance-Profils mit Session Manager-Berechtigungen](session-manager-getting-started-instance-profile.md).
+ **Lösung B**: Der verwaltete Knoten wird nicht auf einer Version von SSM Agent ausgeführt, die den Session Manager unterstützt. Aktualisieren Sie SSM Agent auf dem Knoten auf die Version 2.3.68.0 oder höher.
Sie können SSM Agent manuell auf einem verwalteten Knoten aktualisieren, indem Sie die in [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für Windows Server](manually-install-ssm-agent-windows.md), [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für Linux](manually-install-ssm-agent-linux.md) oder [Manuelle Installation und Deinstallation des SSM Agent auf EC2-Instances für macOS](manually-install-ssm-agent-macos.md) beschriebenen Schritte ausführen, abhängig vom Betriebssystem.
Alternativ können Sie das Run Command-Dokument `AWS-UpdateSSMAgent` verwenden, um die Agent-Version auf einem oder mehreren verwalteten Knoten gleichzeitig zu aktualisieren. Weitere Informationen finden Sie unter [Aktualisierung von SSM Agent mithilfe von Run Command](run-command-tutorial-update-software.md#rc-console-agentexample).
**Tipp**
Damit Ihr Agent stets auf dem aktuellen Stand ist, sollten Sie die Aktualisierung des SSM Agent auf die jeweils aktuelle Version anhand eines automatisierten Zeitplans ausführen, den Sie mittels einer der beiden folgenden Methoden definieren:
Führen Sie `AWS-UpdateSSMAgent` als Teil einer State Manager-Zuordnung aus. Weitere Informationen finden Sie unter [Exemplarische Vorgehensweise: Automatisches Update SSM Agent mit dem AWS CLI](state-manager-update-ssm-agent-cli.md).
Führen Sie `AWS-UpdateSSMAgent` als Teil eines Wartungsfensters aus. Weitere Informationen zum Arbeiten mit Wartungsfenstern finden Sie unter [Wartungsfenster mit der Konsole erstellen und verwalten](sysman-maintenance-working.md) und [Tutorial: Erstellen und konfigurieren Sie ein Wartungsfenster mit dem AWS CLI](maintenance-windows-cli-tutorials-create.md).
+ **Lösung C**: Der verwaltete Knoten kann die erforderlichen Service-Endpunkte nicht erreichen. Sie können die Sicherheitslage Ihrer verwalteten Knoten verbessern, indem Sie Schnittstellenendpunkte verwenden, die mit Strom versorgt werden, AWS PrivateLink um eine Verbindung zu Systems Manager Manager-Endpunkten herzustellen. Die Alternative zur Verwendung von Schnittstellenendpunkten ist das Erlauben von ausgehendem Internetzugriff auf Ihre verwalteten Knoten. Weitere Informationen finden Sie unter [Verwenden PrivateLink zum Einrichten eines VPC-Endpunkts für Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-privatelink.html).
+ **Lösung D**: Der verwaltete Knoten verfügt über begrenzte verfügbare CPU- oder Speicherressourcen. Auch wenn Ihr verwalteter Knoten ansonsten funktionsfähig ist, können Sie keine Sitzung einrichten, wenn der Knoten nicht über genügend verfügbare Ressourcen verfügt. Weitere Informationen finden Sie unter [Problembehandlung bei unerreichbaren Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-console.html).
## Session Manager-Plugin nicht gefunden
Um die Befehle AWS CLI to run session verwenden zu können, muss das Session Manager Plugin auch auf Ihrem lokalen Computer installiert sein. Weitere Informationen finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md).
## Session Manager-Plugin wurde nicht automatisch zumBefehlszeilenpfad hinzugefügt (Windows)
Wenn Sie das Session Manager-Plugin auf Windows installieren, sollte die ausführbare Datei `session-manager-plugin` der Umgebungsvariablen `PATH` Ihres Betriebssystems automatisch hinzugefügt werden. Wenn die Prüfung auf korrekte Installation des Session Manager-Plugins (`aws ssm start-session --target instance-id`) ergibt, dass der Befehl fehlgeschlagen ist, müssen Sie das Plugin möglicherweise mittels des folgenden Verfahrens manuell einrichten.
**So ändern Sie die Variable PATH (Windows)**
1. Betätigen Sie die Windows-Taste und geben Sie **environment variables** ein.
1. Wählen Sie **Edit environment variables for your account (Umgebungsvariablen für Ihr Konto bearbeiten)**.
1. Wählen Sie **PATH** und anschließend **Edit**.
1. Fügen Sie dem Feld **Variable value (Variablenwert)** Pfade hinzu, die durch Semikolons getrennt sind, wie in diesem Beispiel dargestellt: *`C:\existing\path`*;*`C:\new\path`*
*`C:\existing\path`* stellt den Wert dar, der sich bereits im Feld befindet. *`C:\new\path`* stellt den Pfad dar, den Sie hinzufügen möchten, wie im folgenden Beispielen dargestellt.
+ **64-Bit-Computer**: `C:\Program Files\Amazon\SessionManagerPlugin\bin\`
1. Klicken Sie zweimal auf **OK**, um die neuen Einstellungen anzuwenden.
1. Schließen Sie alle etwa ausgeführten Eingabeaufforderungen und öffnen Sie erneut.
## Session Manager-Plugin reagiert nicht mehr
Während einer Port-Weiterleitungssitzung kann der Datenverkehr nicht mehr weitergeleitet werden, wenn auf Ihrem lokalen Computer Antivirus-Software installiert ist. In einigen Fällen stört Antivirus-Software das Session Manager-Plugin, was zu Prozess-Deadlocks führt. Um dieses Problem zu beheben, erlauben Sie das Session Manager-Plugin in der Antivirus-Software oder schließen Sie es aus. Weitere Informationen zum Standardinstallationspfad für das Session Manager-Plugin finden Sie unter [Installiere das Session Manager Plugin für AWS CLI](session-manager-working-with-install-plugin.md).
## TargetNotConnected
**Problem**: Sie versuchen, eine Sitzung zu starten, aber das System gibt die Fehlermeldung „Beim Aufrufen der StartSession Operation ist ein Fehler aufgetreten (TargetNotConnected): *InstanceID* ist nicht verbunden“ zurück.
+ **Lösung A**: Dieser Fehler wird zurückgegeben, wenn der angegebene verwaltete Knoten für die Sitzung nicht vollständig für die Verwendung mit dem Session Manager konfiguriert wurde. Weitere Informationen finden Sie unter [Einrichten von Session Manager](session-manager-getting-started.md).
+ **Lösung B**: Dieser Fehler wird auch zurückgegeben, wenn Sie versuchen, eine Sitzung auf einem verwalteten Knoten zu starten, der sich in einem anderen AWS-Konto oder befindet AWS-Region.
## Nach dem Starten einer Sitzung wird ein leerer Bildschirm angezeigt
**Problem**: Sie starten eine Sitzung und Session Manager zeigt einen leeren Bildschirm an.
+ **Lösung A**: Dieses Problem kann auftreten, wenn das Root-Volume des verwalteten Knotens voll ist. Aufgrund von mangelndem Speicherplatz funktioniert SSM Agent auf dem Knoten nicht mehr. Um dieses Problem zu lösen, verwenden Sie Amazon, CloudWatch um Metriken und Protokolle von den Betriebssystemen zu sammeln. Weitere Informationen finden Sie unter [Erfassung von Metriken, Protokollen und Traces mit dem CloudWatch Agenten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) im * CloudWatch Amazon-Benutzerhandbuch*.
+ **Lösung B**: Möglicherweise wird ein leerer Bildschirm angezeigt, wenn Sie über einen Link auf die Konsole zugegriffen haben, der ein nicht übereinstimmendes Endpunkt- und Regionspaar enthält. Beispielsweise ist in der folgenden Konsolen-URL `us-west-2` der angegebene Endpunkt, aber `us-west-1` die angegebene AWS-Region.
```
https://us-west-2.console.aws.amazon.com/systems-manager/session-manager/sessions?region=us-west-1
```
+ **Lösung C**: Der verwaltete Knoten stellt über VPC-Endpunkte eine Verbindung zu Systems Manager her, und Ihre Session Manager Einstellungen schreiben die Sitzungsausgabe in einen Amazon S3 S3-Bucket oder eine Amazon CloudWatch Logs-Protokollgruppe, aber ein `s3` Gateway-Endpunkt oder `logs` Schnittstellenendpunkt ist in der VPC nicht vorhanden. Ein `s3`-Endpunkt im Format **`com.amazonaws.region.s3`** ist erforderlich, wenn Ihre verwalteten Knoten eine Verbindung zu Systems Manager mithilfe von VPC-Endpunkten herstellen und Ihre Session Manager-Einstellungen die Sitzungsausgabe in einen Amazon-S3-Bucket schreiben. Alternativ **`com.amazonaws.region.logs`**ist ein `logs` Endpunkt in diesem Format erforderlich, wenn Ihre verwalteten Knoten über VPC-Endpunkte eine Verbindung zu Systems Manager herstellen und Ihre Session Manager Einstellungen die Sitzungsausgabe in eine CloudWatch Logs-Protokollgruppe schreiben. Weitere Informationen finden Sie unter [Erstellen von VPC-Endpunkten für Systems Manager](setup-create-vpc.md#create-vpc-endpoints).
+ **Lösung D**: Die Protokollgruppe oder der Amazon S3-Bucket, die/den Sie in Ihren Sitzungseinstellungen angegeben haben, wurde gelöscht. Aktualisieren Sie Ihre Sitzungseinstellungen mit einer gültigen Protokollgruppe oder einem gültigen S3-Bucket, um dieses Problem zu beheben.
+ **Lösung E**: Die Protokollgruppe oder der Amazon S3-Bucket, die/den Sie in Ihren Sitzungseinstellungen angegeben haben, ist nicht verschlüsselt, aber Sie haben die `cloudWatchEncryptionEnabled`- oder `s3EncryptionEnabled`-Eingabe auf `true` eingestellt. Um dieses Problem zu beheben, aktualisieren Sie Ihre Sitzungseinstellungen mit einer Protokollgruppe oder einem Amazon S3-Bucket, die/der verschlüsselt ist, oder stellen Sie die `cloudWatchEncryptionEnabled`- oder `s3EncryptionEnabled`-Eingabe auf `false` ein. Dieses Szenario gilt nur für Kunden, die Sitzungseinstellungen mithilfe von Befehlszeilentools erstellen.
## Verwalteter Knoten reagiert während langer Sitzungen nicht mehr
**Problem**: Ihr verwalteter Knoten reagiert nicht oder stürzt während einer langen Sitzung ab.
**Lösung**: Verringern Sie die SSM Agent-Protokollaufbewahrungsdauer für Session Manager.
**So verringern Sie die SSM Agent-Protokollaufbewahrungsdauer für Sitzungen**
1. Suchen Sie `amazon-ssm-agent.json.template` im `/etc/amazon/ssm/`-Verzeichnis für Linux oder `C:\Program Files\Amazon\SSM` für Windows.
1. Kopieren Sie den Inhalt von `amazon-ssm-agent.json.template` in eine neue Datei im selben Verzeichnis namens `amazon-ssm-agent.json`.
1. Verringern Sie den Standardwert des `SessionLogsRetentionDurationHours`-Werts in der `SSM`-Eigenschaft und speichern Sie die Datei.
1. Starten Sie die SSM Agent neu.
## Beim Aufrufen des Vorgangs ist ein Fehler aufgetreten (InvalidDocument) StartSession
**Problem**: Sie erhalten den folgenden Fehler, wenn Sie eine Sitzung mit dem AWS CLI starten.
```
An error occurred (InvalidDocument) when calling the StartSession operation: Document type: 'Command' is not supported. Only type: 'Session' is supported for Session Manager.
```
**Lösung**: Das SSM-Dokument, das Sie für den `--document-name`-Parameter angegeben haben, ist kein *Sitzungsdokument*. Gehen Sie wie folgt vor, um eine Liste von Sitzungsdokumenten in der AWS-Managementkonsole anzuzeigen.
**So rufen Sie eine Liste von Sitzungsdokumenten auf**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich die Option **Dokumente** aus.
1. Wählen Sie in der Liste **Kategorien** die Option **Sitzungsdokumente** aus.
# AWS Systems Manager State Manager
State Manager, ein Tool in AWS Systems Manager, ist ein sicherer und skalierbarer Konfigurationsmanagement-Service, der den Prozess automatisiert, Ihre verwalteten Knoten und andere AWS Ressourcen in einem von Ihnen definierten Zustand zu halten. Um mit State Manager zu beginnen, öffnen Sie die [Systems-Manager-Konsole](https://console.aws.amazon.com//systems-manager/state-manager). Wählen Sie im Navigationsbereich **State Manager** aus.
**Anmerkung**
State Manager und Maintenance Windows können ähnliche Arten von Updates für Ihre verwalteten Knoten ausführen. Welche Option Sie wählen, hängt davon ab, ob Sie die System-Compliance automatisieren oder zeitkritische Aufgaben mit hoher Priorität während der von Ihnen angegebenen Zeiträume ausführen müssen.
Weitere Informationen finden Sie unter [Auswahl zwischen State Manager und Maintenance Windows](state-manager-vs-maintenance-windows.md).
## Welche Vorteile bietet State Manager meiner Organisation?
Durch die Verwendung vorkonfigurierter Systems-Manager-Dokumente (SSM-Dokumente), bietet State Manager die folgenden Vorteile für die Verwaltung Ihrer Knoten:
+ Bootstrap von Knoten mit bestimmter Software beim Startup.
+ Herunterladen und Aktualisieren von Agenten nach einem definierten Zeitplan, einschließlich des SSM Agent.
+ Konfigurieren von Netzwerkeinstellungen.
+ Verbinden Sie Knoten mit einer Microsoft-Active-Directory-Domain.
+ Ausführen von Skripts auf Linux-, macOS- und Windows Server-verwalteten Knoten während des gesamten Lebenszyklus.
Um Konfigurationsabweichungen zwischen anderen AWS Ressourcen zu verwalten, können Sie Automation, ein Tool in Systems Manager, verwenden, mit State Manager dem Sie die folgenden Arten von Aufgaben ausführen können:
+ Fügen Sie eine Systems Manager Rolle an Amazon Elastic Compute Cloud (Amazon EC2)-Instances an, um sie auf *verwaltete Knoten* zu ändern.
+ Erzwingen Sie die gewünschten Eingangs- und Ausgangsregeln für eine Sicherheitsgruppe.
+ Erstellen oder löschen Sie Amazon DynamoDB-Backups.
+ Erstellen oder löschen Sie Amazon Elastic Block Store (Amazon EBS)-Snapshots.
+ Deaktivieren Sie Lese- und Schreibberechtigungen für Amazon Simple Storage Service (Amazon S3)-Buckets.
+ Starten, Stoppen oder starten Sie verwaltete Knoten und Amazon Relational Database Service (Amazon RDS)-Instances neu.
+ Anwenden von Patches auf Linux, macOS und Windows AMIs.
Weitere Informationen zur Verwendung von State Manager mit Automation-Runbooks finden Sie unter [Planen von Automatisierungen mit State Manager-Zuordnungen](scheduling-automations-state-manager-associations.md).
## An wen richtet sich State Manager?
State Managerist für jeden AWS Kunden geeignet, der die Verwaltung und Steuerung seiner AWS Ressourcen verbessern und Konfigurationsabweichungen reduzieren möchte.
## Über welche Features verfügt State Manager?
Nachstehend sind einige der wichtigsten Features von State Manager aufgelistet:
+
**State Manager-Zuordnungen**
Eine State Manager *Zuordnung* ist eine Konfiguration, die Sie Ihren AWS Ressourcen zuweisen. Die Konfiguration definiert den Status, den Sie auf Ihren Ressourcen beibehalten möchten. Beispiel: Eine Zuordnung kann angeben, dass auf einem verwalteten Knoten Antiviren-Software installiert sein und ausgeführt werden muss oder dass bestimmte Ports geschlossen sein müssen.
Eine Assoziation gibt einen Zeitplan an, wann die Konfiguration und die Ziele für die Assoziation angewendet werden sollen. Beispielsweise könnte eine Zuordnung für Antivirensoftware einmal täglich auf allen verwalteten Knoten in einem AWS-Konto ausgeführt werden. Wenn die Software nicht auf einem Knoten installiert ist, könnte die Assoziation State Manager anweisen, sie zu installieren. Wenn die Software installiert ist, aber der Service nicht ausgeführt wird, könnte die Assoziation State Manager anweisen, den Service zu starten.
+
**Flexible Planungs-Optionen**
State Manager bietet die folgenden Optionen zum Planen, wenn eine Assoziation ausgeführt wird:
+ **Sofortige oder verzögerte Verarbeitung**
Wenn Sie eine Assoziation erstellen, führt das System diese standardmäßig sofort auf den angegebenen Ressourcen aus. Nach der ersten Ausführung wird die Assoziation gemäß dem von Ihnen festgelegten Zeitplan in Intervallen ausgeführt.
Sie können State Manager anweisen, eine Assoziation nicht sofort auszuführen, indem Sie die **Apply association only at next specified Cron-interval** (Übernehmen der Assoziation erst für das nächste angegebene Cron-Intervall)-Option in der Konsole oder im`ApplyOnlyAtCronInterval`-Parameter von der Befehlszeile aus verwenden.
+ **Cron- und Rate-Ausdrücke**
Wenn Sie eine Zuordnung erstellen, geben Sie den Zeitpunkt an, zu dem State Manager die Konfiguration anwendet. State Manager unterstützt Standardausdrücke für Cron- und Rate-Ausdrücke für die Planung, wenn eine Zuordnung ausgeführt wird. State Manager unterstützt auch Cron-Ausdrücke, die einen Wochentag und das Zahlenzeichen (\$1) enthalten, um den *x*-ten Tag eines Monats festzulegen, um eine Zuordnung auszuführen, und das (L)-Zeichen, um den letzten *X* Tag des Monats anzugeben.
**Anmerkung**
State Manager unterstützt derzeit nicht die Angabe von Monaten in Cron-Ausdrücken für Zuordnungen.
Um weiter zu steuern, wann eine Assoziation ausgeführt wird, z. B. wenn Sie zwei Tage nach dem Patch-Dienstag eine Assoziation ausführen möchten, können Sie einen Offset angeben. Ein *Offset* definiert, wie viele Tage nach dem geplanten Tag gewartet werden müssen, um eine Assoziation auszuführen.
Weitere Informationen zum Erstellen von Cron- und Rate-Ausdrücken finden Sie unter [Referenz: Cron- und Rate-Ausdrücke für System Manager](reference-cron-and-rate-expressions.md).
+
**Mehrere Targeting-Optionen**
Eine Assoziation gibt auch die Ziele für die Assoziation an. State Managerunterstützt die gezielte Ausrichtung von AWS Ressourcen mithilfe von Tags AWS -Ressourcengruppen IDs, einzelnen Knoten oder allen verwalteten Knoten im aktuellen AWS-Region und AWS-Konto.
+
**Amazon-S3-Support**
Speichern Sie die Befehlsausgabe von Zuordnungsausführungen in einem Amazon-S3-Bucket Ihrer Wahl. Weitere Informationen finden Sie unter [Arbeiten mit Zuordnungen in Systems Manager](state-manager-associations.md).
+
**EventBridge Unterstützung**
Dieses Systems Manager Manager-Tool wird in EventBridge Amazon-Regeln sowohl als *Ereignistyp* als auch als *Zieltyp* unterstützt. Weitere Informationen finden Sie unter [Überwachung von Systems Manager Manager-Ereignissen mit Amazon EventBridge](monitoring-eventbridge-events.md) und [Referenz: EventBridge Amazon-Ereignistypen und -muster für Systems Manager](reference-eventbridge-events.md).
## Entstehen Kosten für die Verwendung von State Manager?
State Manager ist ohne Aufpreis erhältlich.
**Topics**
+ [Welche Vorteile bietet State Manager meiner Organisation?](#state-manager-benefits)
+ [An wen richtet sich State Manager?](#state-manager-who)
+ [Über welche Features verfügt State Manager?](#state-manager-features)
+ [Entstehen Kosten für die Verwendung von State Manager?](#state-manager-cost)
+ [Grundlegendes zur Funktionsweise von State Manager](state-manager-about.md)
+ [Arbeiten mit Zuordnungen in Systems Manager](state-manager-associations.md)
+ [Erstellen von Zuordnungen, die MOF-Dateien ausführen](systems-manager-state-manager-using-mof-file.md)
+ [Erstellen von Zuordnungen, die Ansible-Playbooks ausführen](systems-manager-state-manager-ansible.md)
+ [Erstellen von Zuordnungen, die Chef-Rezepte ausführen](systems-manager-state-manager-chef.md)
+ [Exemplarische Vorgehensweise: Automatisches Update SSM Agent mit dem AWS CLI](state-manager-update-ssm-agent-cli.md)
+ [Anleitung: Automatische Aktualisierung von PV-Treibern auf EC2-Instances für Windows Server](state-manager-update-pv-drivers.md)
**Weitere Informationen**
+ [Bekämpfung von Konfigurationsabweichungen mithilfe von Amazon EC2 Systems Manager und Windows DSC PowerShell ](https://aws.amazon.com/blogs/mt/combating-configuration-drift-using-amazon-ec2-systems-manager-and-windows-powershell-dsc/)
+ [Konfigurieren von Amazon EC2-Instances in einer Auto Scaling-Gruppe mit State Manager](https://aws.amazon.com/blogs/mt/configure-amazon-ec2-instances-in-an-auto-scaling-group-using-state-manager/)
# Grundlegendes zur Funktionsweise von State Manager
State Manager, ein Tool in AWS Systems Manager, ist ein sicherer und skalierbarer Service, der den Prozess automatisiert, bei dem verwaltete Knoten in einer [Hybrid- und Multi-Cloud-Infrastruktur](operating-systems-and-machine-types.md#supported-machine-types) in einem von Ihnen definierten Zustand belassen werden.
So funktioniert State Manager:
**1. Ermitteln Sie den Status, den Sie auf Ihre AWS Ressourcen anwenden möchten.**
Möchten Sie sicherstellen, dass Ihr verwaltete Knoten mit spezifischen Anwendungen, wie z. B. Antiviren- oder Malware-Anwendungen, konfiguriert ist? Möchten Sie die den Prozess zur Aktualisierung des SSM Agent oder andere AWS -Pakete wie z. B. `AWSPVDriver` automatisieren? Müssen Sie sicherstellen, dass bestimmte Ports geöffnet oder geschlossen sind? Legen Sie zunächst den Bundesstaat festState Manager, den Sie auf Ihre AWS Ressourcen anwenden möchten. Der Status, den Sie anwenden möchten, legt fest, welches SSM-Dokument Sie verwenden können, um eine State Manager-Zuordnung zu erstellen.
Eine State Manager *Zuordnung* ist eine Konfiguration, die Sie Ihren AWS Ressourcen zuweisen. Die Konfiguration definiert den Status, den Sie auf Ihren Ressourcen beibehalten möchten. Beispiel: Eine Zuordnung kann angeben, dass auf einem verwalteten Knoten Antiviren-Software installiert sein und ausgeführt werden muss oder dass bestimmte Ports geschlossen sein müssen.
Eine Assoziation gibt einen Zeitplan an, wann die Konfiguration und die Ziele für die Assoziation angewendet werden sollen. Beispielsweise könnte eine Zuordnung für Antivirensoftware einmal täglich auf allen verwalteten Knoten in einem AWS-Konto ausgeführt werden. Wenn die Software nicht auf einem Knoten installiert ist, könnte die Assoziation State Manager anweisen, sie zu installieren. Wenn die Software installiert ist, aber der Service nicht ausgeführt wird, könnte die Assoziation State Manager anweisen, den Service zu starten.
**2. Stellen Sie fest, ob ein vorkonfiguriertes SSM-Dokument Ihnen helfen kann, den gewünschten Status für Ihre AWS Ressourcen zu erreichen.**
Systems Manager umfasst Dutzende von vorkonfigurierten SSM-Dokumenten, die Sie verwenden können, um eine Zuordnung zu erstellen. Vorkonfigurierte Dokumente sind bereit, allgemeine Aufgaben wie das Installieren von Anwendungen, das Konfigurieren von Amazon, das Ausführen von AWS Systems Manager Automatisierungen CloudWatch, das Ausführen von Shell-Skripts PowerShell und das Verbinden verwalteter Knoten mit einer Verzeichnisdienstdomäne für Active Directory auszuführen.
Sie können alle SSM-Dokumente in der [Systems Manager-Konsole](https://console.aws.amazon.com/systems-manager/documents) anzeigen. Wählen Sie den Namen eines Dokuments an, um mehr darüber zu erfahren. Nachfolgend finden Sie zwei Beispiele: [https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description](https://console.aws.amazon.com/systems-manager/documents/AWS-ConfigureAWSPackage/description) und [https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description](https://console.aws.amazon.com/systems-manager/documents/AWS-InstallApplication/description).
**3. Erstellen einer Assoziation.**
Sie können eine Zuordnung mithilfe der Systems Manager Manager-Konsole, der AWS Command Line Interface (AWS CLI), AWS Tools for Windows PowerShell (Tools für Windows PowerShell) oder der Systems Manager Manager-API erstellen. Beim Erstellen einer Assoziation geben Sie die folgenden Informationen an:
+ Ein Name für die Assoziation.
+ Die Parameter für das SSM-Dokument (z. B. den Pfad zu der zu installierenden Anwendung oder zu dem Skript, das auf den Knoten ausgeführt werden soll).
+ Ziele für die Zuordnung. Sie können verwaltete Knoten als Ziel angeben, indem Sie Tags angeben IDs, einen einzelnen Knoten oder eine Gruppe in auswählen AWS -Ressourcengruppen. Sie können auch *alle* verwalteten Knoten im aktuellen AWS-Region und als Ziel festlegen AWS-Konto. Wenn Ihre Ziele mehr als 1 000 Knoten umfassen, verwendet das System einen stündlichen Drosselungsmechanismus. Das bedeutet, dass Sie möglicherweise Ungenauigkeiten bei der Anzahl Ihrer Statusaggregationen feststellen, da der Aggregationsprozess stündlich und nur dann ausgeführt wird, wenn sich der Ausführungsstatus für einen Knoten ändert.
+ Eine Rolle, die vom Verband verwendet wird, um in Ihrem Namen Maßnahmen zu ergreifen. State Manager übernimmt diese Rolle und den für die Übertragung von Konfigurationen an Knoten erforderlichen APIs Aufruf. Informationen zum Einrichten der benutzerdefinierten Rolle finden Sie unter. [Rollen einrichten für `AssociationDispatchAssumeRole`](#setup-assume-role) Wenn keine Rolle angegeben wird, wird die [serviceverknüpfte Rolle für Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/using-service-linked-roles.html) verwendet.
**Anmerkung**
Es wird empfohlen, eine benutzerdefinierte IAM-Rolle zu definieren, damit Sie die volle Kontrolle über die Berechtigungen haben, über die State Manager verfügt, wenn Sie in Ihrem Namen Maßnahmen ergreifen.
Die Unterstützung von dienstbezogenen Rollen in State Manager wird schrittweise eingestellt. Verbände, die auf eine dienstbezogene Rolle angewiesen sind, müssen möglicherweise in future aktualisiert werden, damit sie weiterhin ordnungsgemäß funktionieren.
Informationen zur Verwaltung der Verwendung von benutzerdefinierten Rollen finden Sie unter. [Verwaltung der Nutzung von AssociationDispatchAssumeRole mit `ssm:AssociationDispatchAssumeRole`](#context-key-assume-role)
+ Einen Zeitplan für die Häufigkeit der Statusanwendung. Sie können einen Cron- oder Rate-Ausdruck festlegen. Weitere Informationen zum Erstellen von Zeitplänen mit cron- und Rate-Ausdrücken für Zuordnungen finden Sie unter [Cron- und Rate-Ausdrücke für Zuordnungen](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association).
**Anmerkung**
State Manager unterstützt derzeit nicht die Angabe von Monaten in Cron-Ausdrücken für Assoziationen.
Wenn Sie den Befehl ausführen, um die Assoziation zu erstellen, bindet Systems Manager die von Ihnen angegebenen Informationen (Zeitplan, Ziele, SSM-Dokument und Parameter) an die anvisierten Ressourcen. Der Status der Zuordnung wird zunächst als „Pending (ausstehend)“ angezeigt, während das System versucht, alle Ziele zu erreichen und *sofort* den in der Zuordnung angegebenen Status anzuwenden.
Wenn Sie eine neue Zuordnung erstellen, die ausgeführt werden soll, solange eine frühere Zuordnung noch ausgeführt wird, führt dies zu einer Unterbrechung der früheren Zuordnung und die neue Zuordnung wird ausgeführt.
Systems Manager meldet den Status der Anforderung zum Erstellen von Assoziationen auf den Ressourcen. Sie können Statusdetails in der Konsole oder (für verwaltete Knoten) mithilfe der [DescribeInstanceAssociationsStatus](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstanceAssociationsStatus.html)API-Operation anzeigen. Wenn Sie die Ausgabe des Befehls beim Erstellen einer Zuordnung in Amazon Simple Storage Service (Amazon S3) auswählen, können Sie die Ausgabe auch im angegebenen Amazon S3-Bucket anzeigen.
Weitere Informationen finden Sie unter [Arbeiten mit Zuordnungen in Systems Manager](state-manager-associations.md).
API-Vorgänge, die während der Ausführung einer Zuordnung durch das SSM-Dokument initiiert werden, werden in AWS CloudTrail nicht protokolliert.
**4. Überwachen und aktualisieren Sie.**
Nach dem Erstellen der Zuordnung wendet State Manager den Status entsprechend des in der Zuordnung definierten Zeitplans erneut an. Sie können den Status Ihrer Zuordnungen auf der [State Manager-Seite](https://console.aws.amazon.com/systems-manager/state-manager) in der Konsole oder mit dem direkten Aufruf der Zuordnungs-ID anzeigen, die von Systems Manager beim Erstellen der Zuordnung generiert wurde. Weitere Informationen finden Sie unter [Anzeigen von Zuordnungsverläufen](state-manager-associations-history.md). Sie können Ihre Zuordnungsdokumente aktualisieren und Sie bei Bedarf erneut anwenden. Sie können auch mehrere Versionen einer Zuordnung erstellen. Weitere Informationen finden Sie unter [Bearbeiten und Erstellen einer neuen Version einer Zuordnung](state-manager-associations-edit.md).
## Verstehen, wann Zuordnungen auf Ressourcen angewendet werden
Wenn Sie eine Zuordnung erstellen, geben Sie ein SSM-Dokument an, das die Konfiguration, eine Liste der Zielressourcen und einen Zeitplan für die Anwendung der Konfiguration definiert. Standardmäßig führt State Manager die Zuordnung aus, wenn Sie sie erstellen und dann nach Ihrem Zeitplan. State Manager versucht auch, die Zuordnung in den folgenden Situationen auszuführen:
+ **Zuordnung bearbeiten** – State Manager führt die Zuordnung aus, nachdem ein Benutzer seine Änderungen bearbeitet und in einem der folgenden Zuordnungsfelder gespeichert hat: `DOCUMENT_VERSION`, `PARAMETERS`, `SCHEDULE_EXPRESSION`, `OUTPUT_S3_LOCATION`.
+ **Dokumentbearbeitung** – State Manager führt die Zuordnung aus, nachdem ein Benutzer Änderungen am SSM-Dokument, das den Konfigurationsstatus der Zuordnung definiert, bearbeitet und gespeichert hat. Insbesondere wird die Zuordnung nach den folgenden Änderungen am Dokument ausgeführt:
+ Ein Benutzer gibt eine neue `$DEFAULT`-Dokumentversion an, und die Zuordnung wurde mit der `$DEFAULT`-Version erstellt.
+ Ein Benutzer aktualisiert ein Dokument und die Zuordnung wurde mit der `$LATEST`-Version erstellt.
+ Ein Benutzer löscht das Dokument, das beim Erstellen der Zuordnung angegeben wurde.
+ **Manueller Start** – State Manager führt die Zuordnung aus, wenn sie vom Benutzer entweder über die Systems-Manager-Konsole oder programmgesteuert initiiert wird.
+ **Zieländerungen** – State Manager führt die Zuordnung aus, nachdem eine der folgenden Aktivitäten auf einem Zielknoten auftritt:
+ Ein verwalteter Knoten wird zum ersten Mal online geschaltet.
+ Ein verwalteter Knoten geht online, nachdem ein geplanter Zuordnungslauf verpasst wurde.
+ Ein verwalteter Knoten wird online gestellt, nachdem er länger als 30 Tage angehalten war.
**Anmerkung**
State Manager überwacht keine Dokumente oder Pakete, die in Zuordnungen in AWS-Konten verwendet werden. Wenn Sie ein Dokument oder Paket in einem Konto aktualisieren, führt die Aktualisierung nicht dazu, dass die Zuordnung im zweiten Konto ausgeführt wird. Sie müssen die Zuordnung im zweiten Konto manuell ausführen.
**Verhindern, dass Zuordnungen ausgeführt werden, wenn sich ein Ziel ändert**
In einigen Fällen möchten Sie möglicherweise nicht, dass eine Zuordnung ausgeführt wird, wenn sich ein Ziel, das aus verwalteten Knoten besteht, ändert, sondern nur gemäß dem angegebenen Zeitplan.
**Anmerkung**
Das Ausführen eines Automatisierungs-Runbooks ist mit Kosten verbunden. Wenn eine Zuordnung mit einem Automation-Runbook auf alle Instances in Ihrem Konto abzielt und Sie regelmäßig eine große Anzahl von Instances starten, wird das Runbook beim Start auf jeder der Instances ausgeführt. Dies kann zu erhöhten Automatisierungskosten führen.
Um zu verhindern, dass eine Zuordnung ausgeführt wird, wenn sich die Ziele für diese Zuordnung ändern, aktivieren Sie das **Kontrollkästchen „Zuordnung nur im nächsten angegebenen Cron-Intervall anwenden“**. Dieses Kontrollkästchen befindet sich im Bereich **Zeitplan angeben** auf den Seiten **Zuordnung erstellen** und **Zuordnung bearbeiten**.
Diese Option gilt für Zuordnungen, die entweder ein Automatisierungs-Runbook oder ein SSM-Dokument enthalten.
## Informationen zu Zielupdates mit Automation-Runbooks
Damit Verknüpfungen, die mit Automation-Runbooks erstellt wurden, angewendet werden können, wenn neue Zielknoten erkannt werden, müssen die folgenden Bedingungen erfüllt sein:
+ Die Zuordnung muss durch eine [Quick Setup](systems-manager-quick-setup.md)-Konfiguration erstellt worden sein. Quick Setup ist ein Tool in AWS Systems Manager. Verknüpfungen, die von anderen Prozessen erstellt werden derzeit nicht unterstützt.
+ Das Automation-Runbook muss explizit auf den Ressourcentyp `AWS::EC2::Instance` oder `AWS::SSM::ManagedInstance` abzielen.
+ Die Zuordnung muss sowohl Parameter als auch Ziele angeben.
In der Konsole werden die Felder **Parameter** und **Ziele** angezeigt, wenn Sie eine Ausführung mit Ratensteuerung wählen.
![\[Parameter- und Zieloptionen werden in der Konsole für die Ausführung von Ratensteuerungen angezeigt\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/sm_Rate_control_execution_options.png)
Wenn Sie die API-Aktionen [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) oder [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_UpdateAssociation.html) verwenden, können Sie diese Werte mithilfe der Eingaben `AutomationTargetParameterName` und `Targets` angeben. In jeder dieser API-Aktionen können Sie auch verhindern, dass die Zuordnung bei jeder Änderung eines Ziels ausgeführt wird, indem Sie den `ApplyOnlyAtCronInterval`-Parameter auf `true` setzen.
Informationen zur Verwendung der Konsole zur Steuerung der Ausführung von Zuordnungen, einschließlich Informationen zur Vermeidung unerwartet hoher Kosten für Automatisierungsausführungen, finden Sie unter [Verstehen, wann Zuordnungen auf Ressourcen angewendet werden](#state-manager-about-scheduling).
## Rollen einrichten für `AssociationDispatchAssumeRole`
Beim Einrichten des benutzerdefinierten Dispatches sollten Rollen übernommen werden, von denen State Manager annimmt, dass sie Aktionen in Ihrem Namen ausführen. Die Rollen sollten vertrauenswürdig sein `ssm.amazonaws.com` und über die erforderlichen Anrufberechtigungen verfügen `ssm:SendCommand` oder auf Anwendungsfällen der Assoziation `ssm:StartAutomationExecution` basieren.
Beispiel für eine Vertrauensrichtlinie:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Verwaltung der Nutzung von AssociationDispatchAssumeRole mit `ssm:AssociationDispatchAssumeRole`
Um die Verwendung von benutzerdefiniertem Versand zu verwalten, übernehmen Sie Rollen, die State Manager für die Ausführung von Aktionen in Ihrem Namen übernimmt. Verwenden Sie dazu den `ssm:AssociationDispatchAssumeRole` Bedingungsschlüssel. Diese Bedingung steuert, ob Verknüpfungen erstellt oder aktualisiert werden können, ohne dass eine benutzerdefinierte Dispatse-Rolle angegeben wird.
In der folgenden Beispielrichtlinie gewährt die `"Allow"` Anweisung APIs nur dann Berechtigungen zum Erstellen und Aktualisieren von Verknüpfungen, wenn der `AssociationDispatchAssumeRole` Parameter angegeben ist. Ohne diesen Parameter in API-Anfragen gewährt die Richtlinie keine Berechtigung zum Erstellen oder Aktualisieren von Verknüpfungen:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:CreateAssociation",
"ssm:UpdateAssociation",
"ssm:CreateAssociationBatch"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ssm:AssociationDispatchAssumeRole": "*"
}
}
}
]
}
```
# Arbeiten mit Zuordnungen in Systems Manager
In diesem Abschnitt wird beschrieben, wie Sie State Manager-Assoziation mit der AWS Systems Manager-Konsole, der AWS Command Line Interface (AWS CLI) und AWS -Tools für PowerShell erstellen und verwalten.
**Topics**
+ [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md)
+ [Erstellen von Zuordnungen](state-manager-associations-creating.md)
+ [Bearbeiten und Erstellen einer neuen Version einer Zuordnung](state-manager-associations-edit.md)
+ [Löschen von Zuordnungen](systems-manager-state-manager-delete-association.md)
+ [Ausführen von Auto-Scaling-Gruppen mit Zuordnungen](systems-manager-state-manager-asg.md)
+ [Anzeigen von Zuordnungsverläufen](state-manager-associations-history.md)
+ [Arbeiten mit Zuordnungen mithilfe von IAM](systems-manager-state-manager-iam.md)
# Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen
In diesem Thema werden Features von State Manager beschrieben, mit denen Sie eine Zuordnung für Dutzende oder Hunderte von Knoten bereitstellen und gleichzeitig steuern können, wie viele Knoten die Zuordnung zum geplanten Zeitpunkt ausführen. State Manager ist ein Tool von AWS Systems Manager.
## Nutzung von Zielen
Wenn Sie eine State Manager-Assoziation erstellen, wählen Sie im Abschnitt **Targets** (Ziele) der Systems Manager-Konsole, welche Knoten mit der Assoziation konfiguriert werden sollen, wie hier gezeigt.
![\[Verschiedene Optionen für das Auswählen von Knoten als Ziel bei der Erstellung einer State Manager-Assoziation\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/state-manager-targets.png)
Wenn Sie mithilfe eines Befehlszeilen-Tools wie AWS Command Line Interface (AWS CLI) eine Zuordnung erstellen, geben Sie den Parameter `targets` an. Durch die Ausrichtung auf Knoten können Sie Dutzende, Hunderte oder Tausende von Knoten mit einer Zuordnung konfigurieren, ohne einzelne Knoten angeben oder auswählen zu müssen IDs.
Jeder verwaltete Knoten kann von maximal 20 Zuordnungen betroffen sein.
State Manager enthält die folgenden Zieloptionen bei der Erstellung einer Zuordnung.
**Tags angeben**
Verwenden Sie diese Option, um einen Tag-Schlüssel und (optional) einen Tag-Wert anzugeben, die Ihren Knoten zugewiesen sind. Wenn Sie die Anforderung ausführen, versucht das System, die Assoziation auf allen Knoten zu erstellen, die dem angegebenen Tag-Schlüssel und -Wert entsprechen. Wenn Sie mehrere Tag-Werte angegeben haben, zielt die Assoziation auf jeden Knoten mit mindestens einem dieser Tag-Werte ab. Wenn das System die Zuordnung erstmals erstellt, führt es die Zuordnung aus. Nach dieser erstmaligen Ausführung führt das System die Zuordnung dem angegebenen Zeitplan entsprechend aus.
Wenn Sie neue Knoten erstellen und diesen Konten den angegebenen Tag-Schlüssel und -Wert zuweisen, wendet das System die Assoziation automatisch an und führt sie sofort und anschließend dem angegebenen Zeitplan entsprechend aus. Dies gilt, wenn die Zuordnung ein Befehls- oder Richtliniendokument verwendet und nicht angewendet wird, wenn die Zuordnung ein Automation-Runbook verwendet. Wenn Sie die angegebenen Tags aus einem Knoten löschen, führt das System die Assoziation für diese Knoten nicht mehr aus.
**Anmerkung**
Wenn Sie Automation-Runbooks mit verwenden State Manager und die Tagging-Beschränkung Sie daran hindert, ein bestimmtes Ziel zu erreichen, sollten Sie die Verwendung von Automations-Runbooks mit Amazon in Betracht ziehen. EventBridge Weitere Informationen finden Sie unter [Führen Sie Automatisierungen auf EventBridge der Grundlage von Ereignissen aus](running-automations-event-bridge.md). Weitere Informationen zur Verwendung von State Manager mithilfe von Runbooks finden Sie unter [Planen von Automatisierungen mit State Manager-Zuordnungen](scheduling-automations-state-manager-associations.md).
Als bewährte Methode empfehlen wir die Verwendung von Tags, wenn Sie Zuordnungen erstellen, die ein Befehls- oder Richtlinien-Dokument verwenden. Wir empfehlen auch die Verwendung von Tags, wenn Sie Zuordnungen zu Auto-Scaling-Gruppen erstellen. Weitere Informationen finden Sie unter [Ausführen von Auto-Scaling-Gruppen mit Zuordnungen](systems-manager-state-manager-asg.md).
**Anmerkung**
Notieren Sie die folgenden Informationen:
Wenn Sie eine Assoziation in der erstellen AWS-Managementkonsole , die mithilfe von Tags auf Knoten abzielt, können Sie nur einen Tag-Schlüssel für eine Automations-Assoziation und fünf Tag-Schlüssel für eine Befehlszuordnung angeben. *Alle* in der Zuordnung angegebenen Tag-Schlüssel müssen dem Knoten aktuell zugewiesen sein. Sind sie das nicht, kann State Manager den Knoten nicht für eine Zuordnung anvisieren.
Wenn Sie die Konsole verwenden *und* Ihre Knoten gezielt ansprechen möchten, indem Sie mehr als einen Tag-Schlüssel für eine Automatisierungs-Zuordnung und fünf Tag-Tasten für eine Befehlszuweisung verwenden, weisen Sie die Tag-Schlüssel einer AWS -Ressourcengruppen Gruppe zu und fügen Sie der Gruppe die Knoten hinzu. Sie können dann die Option **Ressourcengruppe** in der **Zielliste** auswählen, wenn Sie die State Manager-Zuordnung erstellen.
Sie können mit der AWS CLI maximal fünf Tag-Schlüssel angeben. Wenn Sie den verwenden AWS CLI, müssen *alle* im `create-association` Befehl angegebenen Tag-Tasten dem Knoten aktuell zugewiesen sein. Sind sie das nicht, kann State Manager den Knoten nicht für eine Zuordnung anvisieren.
**Manuelles Auswählen von Knoten**
Verwenden Sie diese Option, um die Knoten, auf denen Sie die Assoziation erstellen möchten, manuell auszuwählen. Im Bereich **Instanzen** werden alle von Systems Manager verwalteten Knoten im aktuellen AWS-Konto und angezeigt AWS-Region. Sie können beliebig viele Knoten manuell auswählen. Wenn das System die Zuordnung erstmals erstellt, führt es die Zuordnung aus. Nach dieser erstmaligen Ausführung führt das System die Zuordnung dem angegebenen Zeitplan entsprechend aus.
**Anmerkung**
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
**Eine Ressourcengruppe auswählen**
Verwenden Sie diese Option, um eine Zuordnung für alle Knoten zu erstellen, die von einer AWS -Ressourcengruppen tag- oder AWS CloudFormation stapelbasierten Abfrage zurückgegeben wurden.
Unten folgen Details zum Auswählen von Ressourcengruppen als Ziel für eine Zuordnung.
+ Wenn Sie einer Gruppe neue Knoten hinzufügen, ordnet das System die Knoten automatisch der Assoziation zu, die die Ressourcengruppe zum Ziel hat. Wenn das System die Änderung erkennt, wendet es die Assoziation auf die Knoten an. Nach dieser erstmaligen Ausführung führt das System die Zuordnung dem angegebenen Zeitplan entsprechend aus.
+ Wenn Sie eine Zuordnung erstellen, die auf eine Ressourcengruppe abzielt, und der `AWS::SSM::ManagedInstance` Ressourcentyp für diese Gruppe angegeben wurde, wird die Zuordnung standardmäßig sowohl auf Amazon Elastic Compute Cloud (Amazon EC2) -Instances als auch auf EC2 Nicht-Knoten in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) ausgeführt.
Umgekehrt gilt dies auch. Wenn Sie eine Zuordnung erstellen, die auf eine Ressourcengruppe abzielt, und der `AWS::EC2::Instance` Ressourcentyp für diese Gruppe angegeben wurde, wird die Zuordnung standardmäßig sowohl auf EC2 Nicht-Knoten in einer [Hybrid- und Multi-Cloud-Umgebung](operating-systems-and-machine-types.md#supported-machine-types) als auch auf (Amazon- EC2) Instances ausgeführt.
+ Wenn Sie eine Zuordnung erstellen, die auf eine Ressourcengruppe abzielt, dürfen der Ressourcengruppe nicht mehr als fünf Tag-Schlüssel zugewiesen oder mehr als fünf Werte für einen Tag-Schlüssel angegeben werden. Wenn eine dieser Bedingungen auf die Tags und Schlüssel zutrifft, die Ihrer Ressourcengruppe zugewiesen sind, kann die Zuordnung nicht ausgeführt werden und gibt einen `InvalidTarget`-Fehler zurück.
+ Wenn Sie mithilfe von Tags eine Zuordnung erstellen, die auf eine Ressourcengruppe abzielt, können Sie für den Tagwert nicht die Option **(leerer Wert)** wählen.
+ Wenn Sie eine Ressourcengruppe löschen, führen alle Instances in dieser Gruppe die Zuordnung nicht mehr aus. Es ist ratsam, Zuordnungen zu löschen, die die Gruppe zum Ziel haben.
+ Sie können für eine Zuordnung maximal eine einzelne Ressourcengruppe als Ziel auswählen. Mehrere oder verschachtelte Gruppen werden nicht unterstützt.
+ Nachdem Sie eine Zuordnung erstellt haben, aktualisiert State Manager die Zuordnung in regelmäßigen Abständen mit Informationen zu Ressourcen in der Ressourcengruppe. Wenn Sie einer Ressourcengruppe neue Ressourcen hinzufügen, hängt es von verschiedenen Faktoren ab, wann das System die Zuordnung auf die neuen Ressourcen anwendet. Sie können den Status der Zuordnung auf der Seite State Manager der Systems Manager-Konsole bestimmen.
**Warnung**
Ein AWS Identity and Access Management (IAM-) Benutzer, eine Gruppe oder eine Rolle mit der Berechtigung, eine Zuordnung zu erstellen, die auf eine Ressourcengruppe von EC2 Amazon-Instances abzielt, hat automatisch die Kontrolle über alle Instances in der Gruppe auf Stammebene. Sie sollten nur vertrauenswürdigen Administratoren die Berechtigung erteilen, Zuordnungen zu erstellen.
Weitere Informationen zu Resource Groups finden Sie unter [Was ist AWS -Ressourcengruppen?](https://docs.aws.amazon.com/ARG/latest/userguide/) im *AWS -Ressourcengruppen -Benutzerhandbuch*.
**Wählen Sie alle Knoten**
Verwenden Sie diese Option, um alle Knoten im aktuellen und als Ziel festzulegen. AWS-Konto AWS-Region Wenn Sie die Anforderung ausführen, sucht das System nach der Zuordnung und versucht, sie auf allen Knoten im aktuellen AWS-Konto und AWS-Region zu erstellen. Wenn das System die Zuordnung erstmals erstellt, führt es die Zuordnung aus. Nach dieser erstmaligen Ausführung führt das System die Zuordnung dem angegebenen Zeitplan entsprechend aus. Wenn Sie neue Instances erstellen, wendet das System die Assoziation automatisch an und führt sie sofort und anschließend dem angegebenen Zeitplan entsprechend aus.
## Verwenden von Ratensteuerungen
Sie können die Ausführung einer Assoziation für Ihre Knoten steuern, indem Sie einen Gleichzeitigkeitswert und einen Fehlerschwellenwert angeben. Der Gleichzeitigkeitswert gibt an, wie viele Knoten die Assoziation gleichzeitig ausführen können. Der Fehlerschwellenwert gibt an, wie viele Assoziationsausführungen fehlschlagen dürfen, bevor Systems Manager einen Befehl an alle mit dieser Assoziation konfigurierten Knoten sendet, um die Ausführung der Assoziation zu beenden. Der Befehl verhindert, dass die Zuordnung vor der nächsten geplanten Zuordnung ausgeführt wird. Die Gleichzeitigkeits- und die Fehlergrenzwertfeature werden gemeinsam als *Ratensteuerungen* bezeichnet.
![\[Verschiedene Optionen für Ratensteuerungen bei der Erstellung einer State Manager-Assoziation\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/state-manager-rate-controls.png)
**Nebenläufigkeit**
Durch Angabe eines Gleichzeitigkeitswerts können die Auswirkungen der Ausführung auf Ihre Knoten begrenzt werden, indem Sie angeben, dass jeweils nur eine bestimmte Anzahl von Knoten eine Assoziation gleichzeitig verarbeiten kann. Sie können entweder eine absolute Anzahl an verwalteten Knoten, z. B. 20, oder einen Prozentsatz des Ziel-Knotensatzes, beispielsweise 10 %, angeben.
Bitte beachten Sie die folgenden Einschränkungen und Begrenzungen für die Gleichzeitigkeitsfunktion bei State Manager:
+ Wenn Sie eine Assoziation erstellen, indem Sie Ziele angeben, aber keinen Gleichzeitigkeitswert festlegen, dann gibt State Manager automatisch eine maximale Gleichzeitigkeit von 50 Knoten vor.
+ Wenn eine Assoziation ausgeführt wird, die die Gleichzeitigkeitsfunktion verwendet, und ein neuer Knoten online geht, der den Zielkriterien entspricht, führen diese neuen Knoten die Assoziation aus, wenn damit der Gleichzeitigkeitswert nicht überschritten wird. Wenn der Gleichzeitigkeitswert überschritten wird, wird der Knoten für das aktuelle Assoziationsausführungsintervall ignoriert. Die Knoten werden dann zum nächsten geplanten Intervall bei normaler Beachtung der Gleichzeitigkeitsbeschränkung ausgeführt.
+ Wenn Sie eine Assoziation aktualisieren, die die Gleichzeitigkeitsfunktion verwendet, und diese Assoziation wird gerade auf einer oder mehreren Knoten ausgeführt, dann erhalten diese Knoten die Erlaubnis, die Ausführung der Assoziation abzuschließen. Zuordnungen, deren Ausführung noch nicht begonnen hat, werden nicht mehr ausgeführt. Nachdem die Ausführung laufender Assoziationen abgeschlossen wurde, führen alle Ziel-Knoten die Assoziation sofort erneut aus, da sie aktualisiert wurde. Auch bei dieser erneuten Ausführung gilt der festgelegte Gleichzeitigkeitswert.
**Fehlerschwellenwerte**
Ein Fehlergrenzwert gibt an, wie viele Assoziationsausführungen auftreten dürfen, bevor Systems Manager einen Befehl zu jedem mit dieser Assoziation konfigurierten Knoten sendet. Der Befehl verhindert, dass die Zuordnung vor der nächsten geplanten Zuordnung ausgeführt wird. Sie können entweder eine absolute Anzahl an Fehlern, z. B. 10, oder einen Prozentsatz des festgelegten Ziels, beispielsweise 10 % festlegen.
Wenn Sie z. B. die absolute Zahl von drei Fehlern angeben, sendet State Manager einen Befehl zum Anhalten, wenn der vierte Fehler zurückgegeben wird. Wenn Sie 0 angeben, sendet State Manager den Befehl zum Anhalten, wenn der erste Fehler gemeldet wird.
Wenn Sie einen Fehlerschwellenwert von 10 % für 50 Zuordnungen angeben, sendet State Manager den Befehl zum Anhalten, wenn der sechste Fehler zurückgegeben wird. Zuordnungen, die bereits ausgeführt werden, wenn ein Fehlerschwellenwert erreicht wird, werden noch abgeschlossen, es besteht jedoch die Möglichkeit, dass einige dieser Zuordnungen fehlschlagen. Um sicherzustellen, dass nicht mehr Fehler als im Fehlerschwellenwert angegeben auftreten, setzen Sie den Wert für die **Concurrency (Gleichzeitigkeit)** auf 1, sodass die Zuordnungen jeweils einzeln ausgeführt werden.
Es gelten die folgenden Einschränkungen und Begrenzungen für Fehlerschwellenwert in State Manager:
+ Fehlerschwellenwerte werden für das aktuelle Intervall übernommen.
+ Informationen zu den einzelnen Fehlern werden mit detaillierten Informationen zu den Arbeitsschritten im Zuordnungsverlauf aufgezeichnet.
+ Wenn Sie eine Zuordnung unter Verwendung von Zielen erstellen, aber keinen Fehlerschwellenwert angeben, dann gibt State Manager automatisch einen Schwellenwert von 100 % Fehlern vor.
# Erstellen von Zuordnungen
State Manager, ein Tool in AWS Systems Manager, hilft Ihnen dabei, Ihre AWS Ressourcen in einem von Ihnen definierten Zustand zu halten und Konfigurationsabweichungen zu reduzieren. Um dies zu tun, verwendet State Manager Assoziationen. Eine *Assoziation* ist eine Konfiguration, die Sie Ihren AWS -Ressourcen zuweisen. Die Konfiguration definiert den Status, den Sie auf Ihren Ressourcen beibehalten möchten. Beispiel: Eine Zuordnung kann angeben, dass auf einem verwalteten Knoten Antiviren-Software installiert sein und ausgeführt werden muss oder dass bestimmte Ports geschlossen sein müssen.
Eine Assoziation gibt einen Zeitplan an, wann die Konfiguration und die Ziele für die Assoziation angewendet werden sollen. Beispielsweise könnte eine Zuordnung für Antivirensoftware einmal täglich auf allen verwalteten Knoten in einem AWS-Konto ausgeführt werden. Wenn die Software nicht auf einem Knoten installiert ist, könnte die Assoziation State Manager anweisen, sie zu installieren. Wenn die Software installiert ist, aber der Service nicht ausgeführt wird, könnte die Assoziation State Manager anweisen, den Service zu starten.
**Warnung**
Wenn Sie eine Zuordnung erstellen, können Sie eine AWS Ressourcengruppe verwalteter Knoten als Ziel für die Zuordnung auswählen. Wenn ein AWS Identity and Access Management (IAM-) Benutzer, eine Gruppe oder eine Rolle berechtigt ist, eine Zuordnung zu erstellen, die auf eine Ressourcengruppe verwalteter Knoten abzielt, hat dieser Benutzer, diese Gruppe oder Rolle automatisch die Kontrolle über alle Knoten in der Gruppe auf Stammebene. Sie sollten nur vertrauenswürdigen Administratoren die Berechtigung erteilen, Assoziationen zu erstellen.
**Zuordnungsziele und Ratensteuerungen**
Eine Zuordnung gibt an, welche verwalteten Knoten oder Ziele die Zuordnung erhalten sollen. State Manager enthält mehrere Funktionen, mit denen Sie Ihre verwalteten Knoten gezielt ausrichten und steuern können, wie die Zuordnung für diese Ziele bereitgestellt wird. Weitere Informationen zu Zielen und Ratensteuerungen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
**Markierungs-Zuordnungen**
Sie können einer Assoziation bei der Erstellung Tags zuweisen, indem Sie ein Befehlszeilentool wie oder verwenden. AWS CLI AWS -Tools für PowerShell Das Hinzufügen von Tags zu einer Zuordnung über die Systems-Manager-Konsole wird nicht unterstützt.
**Ausgeführte Zuordnungen**
Standardmäßig wird von State Manager eine Zuordnung sofort nach deren Erstellung und dann gemäß dem von Ihnen definierten Zeitplan ausgeführt.
Das System führt auch Zuordnungen nach den folgenden Regeln aus:
+ State Manager versucht, die Assoziation während eines Intervalls auf allen angegebenen oder als Ziel ausgewählten Knoten auszuführen.
+ Wenn eine Assoziation in einem Intervall nicht ausgeführt wird (weil beispielsweise die Anzahl der Knoten, die die Zuordnung gleichzeitig ausführen können, durch einen Gleichzeitigkeitswert begrenzt wird), versucht State Manager, die Assoziation im nächsten Intervall auszuführen.
+ State Manager führt die Zuordnung nach Änderungen an der Konfiguration, den Zielknoten, Dokumenten oder Parametern der Zuordnung aus. Weitere Informationen finden Sie unter [Verstehen, wann Zuordnungen auf Ressourcen angewendet werden](state-manager-about.md#state-manager-about-scheduling).
+ State Manager zeichnet einen Verlauf für alle übersprungenen Datensätze an. Sie können den Verlauf auf der Registerkarte **Execution History (Ausführungsverlauf)** anzeigen.
## Planen von Zuordnungen
Sie können Zuordnungen so planen, dass sie in einfachen Intervallen ausgeführt werden, z. B. *alle 10 Stunden*, oder Sie können erweiterte Zeitpläne erstellen, indem Sie benutzerdefinierte Cron- und Rate-Ausdrücke verwenden. Sie können auch verhindern, dass Zuordnungen ausgeführt werden, wenn Sie diese zum ersten Mal erstellen.
**Verwenden von Cron- und Rate-Ausdrücken zur Planung von Ausführungen von Zuordnungen**
Zusätzlich zu den standardmäßigen Cron- und Rate-Ausdrücken werden von State Manager auch Cron-Ausdrücke unterstützt, die einen Wochentag und das Nummernzeichen (\$1) enthalten, um den *x*-ten Tag eines Monats für die Ausführung einer Assoziation zu bestimmen. Hier ist ein Beispiel, das am dritten Dienstag jeden Monats um 23:30 Uhr UTC einen Cron-Zeitplan ausführt:
`cron(30 23 ? * TUE#3 *)`
Hier ist ein Beispiel, das am zweiten Donnerstag jeden Monats um Mitternacht UTC läuft:
`cron(0 0 ? * THU#2 *)`
State Manager unterstützt auch das (L)-Zeichen, um den letzten *X* Tag des Monats anzugeben. Hier ist ein Beispiel, das am letzten Dienstag jeden Monats um Mitternacht UTC einen Cron-Zeitplan ausführt:
`cron(0 0 ? * 3L *)`
Um weiter zu steuern, wann eine Assoziation ausgeführt wird, z. B. wenn Sie zwei Tage nach dem Patch-Dienstag eine Assoziation ausführen möchten, können Sie einen Offset angeben. Ein *Offset* definiert, wie viele Tage nach dem geplanten Tag gewartet werden müssen, um eine Assoziation auszuführen. Wenn Sie beispielsweise einen Cron-Zeitplan mit `cron(0 0 ? * THU#2 *)` angegeben haben, können Sie die Nummer 3 im Feld **Planversatz** angeben, um die Assoziation jeden Sonntag nach dem zweiten Donnerstag im Monat auszuführen.
**Anmerkung**
Um Offsets zu verwenden, müssen Sie entweder **Zuordnung nur beim nächsten angegebenen Cron-Intervall in der Konsole anwenden** auswählen oder den `ApplyOnlyAtCronInterval`-Parameter über die Befehlszeile angeben. Wenn eine dieser Optionen aktiviert ist, führt State Manager die Zuordnung nicht sofort nach dem Erstellen aus.
Weitere Informationen zu cron- und Rate-Ausdrücken finden Sie unter [Referenz: Cron- und Rate-Ausdrücke für System Manager](reference-cron-and-rate-expressions.md).
## Erstellen einer Zuordnung (Konsole)
Im folgenden Verfahren wird beschrieben, wie mithilfe der Systems Manager-Konsole eine State Manager-Zuordnung erstellt wird.
**Anmerkung**
Notieren Sie die folgenden Informationen:
Dieses Verfahren beschreibt, wie eine Zuordnung erstellt wird, die entweder ein `Command`- oder ein `Policy`-Dokument zum Ansprechen verwalteter Knoten verwendet. Weitere Informationen zum Erstellen einer Assoziation, die ein Automation-Runbook verwendet, um Knoten oder andere Arten von AWS -Ressourcen anzuvisieren, finden Sie unter [Planen von Automatisierungen mit State Manager-Zuordnungen](scheduling-automations-state-manager-associations.md).
Sie können bei der Erstellung einer Zuordnung mit der AWS-Managementkonsole maximal fünf Tag-Schlüssel angeben. *Alle* für die Zuordnung angegebenen Tag-Schlüssel müssen dem Knoten aktuell zugewiesen sein. Sind sie das nicht, kann State Manager den Knoten nicht für die Zuordnung anvisieren.
**So erstellen Sie eine State Manager-Zuordnung**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **State Manager** aus.
1. Wählen Sie **Create association (Zuordnung erstellen)** aus.
1. Geben Sie im Feld **Name** einen Namen an.
1. Wählen Sie in der Liste **Document (Dokument)** die Option neben dem Namen des Dokuments aus. Beachten Sie den Dokumenttyp. Dieses Verfahren gilt für `Command`- und `Policy`-Dokumente. Weitere Informationen zum Erstellen einer Zuordnung, die ein Automation-Runbook verwendet, finden Sie unter [Planen von Automatisierungen mit State Manager-Zuordnungen](scheduling-automations-state-manager-associations.md).
**Wichtig**
State Manager unterstützt nicht das Ausführen von Zuordnungen, die eine neue Version eines Dokuments verwenden, wenn dieses Dokument von einem anderen Konto freigegeben wird. State Manager führt immer die `default`-Version eines Dokuments aus, wenn es von einem anderen Konto freigegeben wird, obwohl die Systems-Manager-Konsole anzeigt, dass eine neue Version verarbeitet wurde. Wenn Sie eine Zuordnung mit einer neuen Version eines Dokuments ausführen möchten, das von einem anderen Konto freigegeben wurde, müssen Sie die Dokumentversion auf `default` einstellen.
1. Geben Sie für **Parameters (Parameter)** die erforderlichen Eingabeparameter an.
1. (Optional) Wählen Sie für **Association Dispatch Assume Role** eine Rolle aus der Dropdownliste aus. State Manager wird mit dieser Rolle in Ihrem Namen Maßnahmen ergreifen. Informationen zum Einrichten der benutzerdefinierten Rolle finden Sie unter [Rollen einrichten für `AssociationDispatchAssumeRole`](state-manager-about.md#setup-assume-role)
**Anmerkung**
Es wird empfohlen, eine benutzerdefinierte IAM-Rolle zu definieren, damit Sie die volle Kontrolle über die Berechtigungen haben, über die State Manager verfügt, wenn Sie in Ihrem Namen Maßnahmen ergreifen.
Die Unterstützung von dienstbezogenen Rollen in State Manager wird schrittweise eingestellt. Verbände, die auf eine dienstbezogene Rolle angewiesen sind, müssen möglicherweise in future aktualisiert werden, damit sie weiterhin ordnungsgemäß funktionieren.
Informationen zur Verwaltung der Verwendung von benutzerdefinierten Rollen finden Sie unter. [Verwaltung der Nutzung von AssociationDispatchAssumeRole mit `ssm:AssociationDispatchAssumeRole`](state-manager-about.md#context-key-assume-role)
1. (Optional) Wählen Sie einen CloudWatch Alarm aus, der bei Ihrem Verband zur Überwachung eingereicht werden soll.
**Anmerkung**
Bitte beachten Sie die folgenden Informationen über diesen Schritt.
Die Liste der Alarme zeigt maximal 100 Alarme. Wenn Sie Ihren Alarm nicht in der Liste sehen, verwenden Sie den, AWS Command Line Interface um die Zuordnung zu erstellen. Weitere Informationen finden Sie unter [Erstellen einer Zuordnung (Befehlszeile)](#create-state-manager-association-commandline).
Um Ihrem Befehl einen CloudWatch Alarm anzuhängen, muss der IAM-Principal, der die Zuordnung erstellt, über die entsprechende Berechtigung für die `iam:createServiceLinkedRole` Aktion verfügen. Weitere Informationen zu CloudWatch Alarmen finden Sie unter [ CloudWatch Amazon-Alarme verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Ausstehende Befehlsaufrufe oder Automatisierungen werden nicht ausgeführt, wenn Ihr Alarm aktiviert wird.
1. Wählen Sie für **Ziele** eine Option aus. Weitere Informationen zur Verwendung von Zielen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
**Anmerkung**
Damit Verknüpfungen, die mit Automations-Runbooks erstellt wurden, angewendet werden können, wenn neue Zielknoten erkannt werden, müssen bestimmte Bedingungen erfüllt sein. Weitere Informationen finden Sie unter [Informationen zu Zielupdates mit Automation-Runbooks](state-manager-about.md#runbook-target-updates).
1. Wählen Sie im Abschnitt **Zeitplan angeben** entweder **Nach Zeitplan** oder **Kein Zeitplan** aus. Wenn Sie **On schedule (Auf Zeitplan)** auswählen, verwenden Sie die verfügbaren Schaltflächen zum Erstellen eines cron- oder rate-Zeitplans für die Zuordnung.
Wenn Sie nicht möchten, dass eine Zuordnung unmittelbar nach der Erstellung ausgeführt wird, wählen Sie **Apply association only at the next specified Cron interval (Zuordnung erst beim nächsten angegebenen Cron-Intervall anwenden)**.
1. (Optional) Im **Schedule offset** (Planversatz), geben Sie eine Zahl zwischen 1 und 6 an.
1. Im Abschnitt **Advanced options (Erweiterte Optionen)** wählen Sie mit **Compliance severity (Compliance-Schweregrad)** einen Schweregrad für die Zuordnung und mit **Change Calendars (Änderungskalender)** einen Änderungskalender für die Zuordnung aus.
In den Compliance-Berichten finden Sie Informationen dazu, ob die Zuordnung konform ist, zusammen mit dem Schweregrad, den Sie hier angeben. Weitere Informationen finden Sie unter [Informationen zu State Manager-Zuordnungs-Compliance](compliance-about.md#compliance-about-association).
Der Änderungskalender bestimmt, wann die Zuordnung ausgeführt wird. Wenn der Kalender geschlossen ist, wird die Zuordnung nicht angewendet. Wenn der Kalender geöffnet ist, wird die Zuordnung entsprechend ausgeführt. Weitere Informationen finden Sie unter [AWS Systems Manager Change Calendar](systems-manager-change-calendar.md).
1. Wählen Sie im Abschnitt **Rate control** (Ratensteuerung) Optionen für die Ausführung der Assoziation auf mehreren Knoten aus. Weitere Informationen zu Ratensteuerungen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
Wählen Sie im Abschnitt **Gleichzeitigkeit** eine Option aus:
+ Wählen Sie **Ziele** aus, um eine absolute Anzahl von Zielen einzugeben, die die Zuordnung gleichzeitig ausführen können.
+ Wählen Sie **Prozentsatz** aus, um einen Prozentsatz der Ziele anzugeben, die die Zuordnung gleichzeitig ausführen können.
Wählen Sie im Abschnitt **Fehlerschwellenwert** eine Option aus:
+ Wählen Sie **Fehler** aus und geben Sie die absolute Anzahl erlaubter Fehler an, bis State Manager die Ausführung von Zuordnungen für weitere Ziele beendet.
+ Wählen Sie **Prozentsatz** aus und geben Sie den Prozentsatz erlaubter Fehler an, bis State Manager die Ausführung von Zuordnungen für weitere Ziele beendet.
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben der Ausgabe in S3 aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind die Berechtigungen des dem verwalteten Knoten zugewiesenen Instance-Profils und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
Im Folgenden finden Sie die minimalen Berechtigungen, die erforderlich sind, um Amazon S3-Ausgabe für eine Zuordnung zu aktivieren. Sie können den Zugriff weiter einschränken, indem Sie IAM-Richtlinien an Benutzer oder Rollen innerhalb eines Kontos anfügen. Ein Amazon EC2-Instance-Profil sollte mindestens eine IAM-Rolle mit der von `AmazonSSMManagedInstanceCore` verwalteten Richtlinie und der folgenden Inline-Richtlinie haben.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
]
}
```
------
Für minimale Berechtigungen muss der Amazon S3-Bucket, in den Sie exportieren, über die von der Amazon S3-Konsole definierten Standardeinstellungen verfügen. Weitere Informationen zum Erstellen eines Amazon S3-Buckets finden Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) im *Amazon S3-Benutzerhandbuch*.
**Anmerkung**
API-Vorgänge, die während der Ausführung einer Zuordnung durch das SSM-Dokument initiiert werden, werden in AWS CloudTrail nicht protokolliert.
1. Wählen Sie **Zuordnung erstellen**.
**Anmerkung**
Wenn Sie die von Ihnen erstellte Zuordnung löschen, wird die Zuordnung nicht mehr auf Zielen dieser Zuordnung ausgeführt.
## Erstellen einer Zuordnung (Befehlszeile)
Das folgende Verfahren beschreibt, wie Sie die AWS CLI (unter Linux oderWindows Server) oder Tools für verwenden PowerShell , um eine State Manager Zuordnung zu erstellen. Dieser Abschnitt enthält einige Beispiele, die zeigen, wie Ziele und Ratensteuerungen verwendet werden. Mit Zielen und Ratensteuerungen können Sie Dutzenden oder Hunderten von Knoten eine Assoziation zuweisen, während Sie die Ausführung dieser Assoziationen steuern. Weitere Informationen zu Zielen und Ratensteuerungen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
**Wichtig**
Dieses Verfahren beschreibt, wie eine Zuordnung erstellt wird, die entweder ein `Command`- oder ein `Policy`-Dokument zum Ansprechen verwalteter Knoten verwendet. Informationen zum Erstellen einer Assoziation, die mithilfe eines Automatisierungs-Runbooks auf Knoten oder andere AWS Ressourcentypen abzielt, finden Sie unter[Planen von Automatisierungen mit State Manager-Zuordnungen](scheduling-automations-state-manager-associations.md).
**Bevor Sie beginnen**
Der Parameter `targets` ist ein Array von Suchkriterien, die Knoten mit einer Kombination aus `Key` und `Value`, die Sie angeben, als Ziel auswählen. Wenn Sie planen, mithilfe des Parameters `targets` eine Assoziation für Dutzende oder Hunderte von Knoten zu erstellen, überprüfen Sie die folgenden Optionen für die Zielauswahl, bevor Sie mit dem Verfahren beginnen.
Spezifische Knoten ansprechen, indem Sie Folgendes angeben IDs
```
--targets Key=InstanceIds,Values=instance-id-1,instance-id-2,instance-id-3
```
```
--targets Key=InstanceIds,Values=i-02573cafcfEXAMPLE,i-0471e04240EXAMPLE,i-07782c72faEXAMPLE
```
Instances mithilfe von -Tags als Ziel auswählen
```
--targets Key=tag:tag-key,Values=tag-value-1,tag-value-2,tag-value-3
```
```
--targets Key=tag:Environment,Values=Development,Test,Pre-production
```
Zielknoten mithilfe von AWS -Ressourcengruppen
```
--targets Key=resource-groups:Name,Values=resource-group-name
```
```
--targets Key=resource-groups:Name,Values=WindowsInstancesGroup
```
Zielt auf alle Instanzen in der aktuellen Version ab AWS-Konto und AWS-Region
```
--targets Key=InstanceIds,Values=*
```
**Anmerkung**
Notieren Sie die folgenden Informationen:
State Manager unterstützt nicht das Ausführen von Zuordnungen, die eine neue Version eines Dokuments verwenden, wenn dieses Dokument von einem anderen Konto freigegeben wird. State Manager führt immer die `default`-Version eines Dokuments aus, wenn es von einem anderen Konto freigegeben wird, obwohl die Systems-Manager-Konsole anzeigt, dass eine neue Version verarbeitet wurde. Wenn Sie eine Zuordnung mit einer neuen Version eines Dokuments ausführen möchten, das von einem anderen Konto freigegeben wurde, müssen Sie die Dokumentversion auf `default` einstellen.
State Managerunterstützt keine`IncludeChildOrganizationUnits`,`ExcludeAccounts`,`TargetsMaxErrors`, `TargetsMaxConcurrency``Targets`, `TargetLocationAlarmConfiguration` Parameter für [TargetLocation](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_TargetLocation.html).
Sie können mit der AWS CLI maximal fünf Tag-Schlüssel angeben. Wenn Sie den verwenden AWS CLI, müssen *alle* im `create-association` Befehl angegebenen Tag-Schlüssel dem Knoten aktuell zugewiesen sein. Sind sie das nicht, kann State Manager den Knoten nicht für eine Zuordnung anvisieren.
Beim Erstellen der Zuordnung geben Sie die auch den Zeitplan für die Ausführung an. Geben Sie den Zeitplan mit einem cron- oder Rate-Ausdruck an. Weitere Informationen zu cron- und Rate-Ausdrücken finden Sie unter [Cron- und Rate-Ausdrücke für Zuordnungen](reference-cron-and-rate-expressions.md#reference-cron-and-rate-expressions-association).
Damit Verknüpfungen, die mit Automations-Runbooks erstellt wurden, angewendet werden können, wenn neue Zielknoten erkannt werden, müssen bestimmte Bedingungen erfüllt sein. Weitere Informationen finden Sie unter [Informationen zu Zielupdates mit Automation-Runbooks](state-manager-about.md#runbook-target-updates).
**So erstellen Sie eine Zuordnung**
1. Installieren und konfigurieren Sie den AWS CLI oder den AWS -Tools für PowerShell, falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) und [Installieren des AWS -Tools für PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Verwenden Sie das folgende Format, um einen Befehl zu erstellen, der eine State Manager-Zuordnung erstellt. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
------
#### [ 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"
```
------
In dem folgenden Beispiel wird eine Assoziaition für Knoten erstellt, die mit `"Environment,Linux"` getaggt sind. Die Assoziation verwendet das Dokument `AWS-UpdateSSMAgent`, um den SSM Agent auf den Ziel-Knoten jeden Sonntagmorgen um 2:00 Uhr UTC zu aktualisieren. Diese Assoziation wird jeweils auf maximal 10 Knoten gleichzeitig ausgeführt. Die Ausführung dieser Assoziation wird außerdem für ein bestimmtes Ausführungsintervall auf weiteren Knoten gestoppt, wenn die Fehlerzählung 5 überschreitet. Der Zuordnung wird für Compliance-Berichte der Schweregrad Mittel zugewiesen.
------
#### [ 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
```
------
Das folgende Beispiel zielt auf den Knoten ab, IDs indem ein Platzhalterwert (\$1) angegeben wird. Dadurch kann Systems Manager eine Zuordnung auf *allen* Knoten im aktuellen AWS-Konto und erstellen AWS-Region. Diese Assoziation wird jeweils auf maximal 10 Knoten gleichzeitig ausgeführt. Die Ausführung dieser Assoziation wird außerdem für ein bestimmtes Ausführungsintervall auf weiteren Knoten gestoppt, wenn die Fehlerzählung 5 überschreitet. Der Zuordnung wird für Compliance-Berichte der Schweregrad Mittel zugewiesen. Diese Assoziation verwendet einen Zeitplan-Offset, was bedeutet, dass sie zwei Tage nach dem angegebenen Cron-Zeitplan ausgeführt wird. Sie enthält auch den `ApplyOnlyAtCronInterval`-Parameter, der erforderlich ist, um den Zeitplan-Offset zu verwenden, und was bedeutet, dass die Assoziation nicht sofort nach ihrer Erstellung ausgeführt wird.
------
#### [ 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
```
------
Im folgenden Beispiel wird eine Assoziation für Knoten in Ressourcengruppen erstellt. Die Gruppe trägt den Namen „HR-Department“. Die Assoziation verwendet das Dokument `AWS-UpdateSSMAgent`, um den SSM Agent auf den Ziel-Knoten jeden Sonntagmorgen um 2:00 Uhr UTC zu aktualisieren. Diese Assoziation wird jeweils auf maximal 10 Knoten gleichzeitig ausgeführt. Die Ausführung dieser Assoziation wird außerdem für ein bestimmtes Ausführungsintervall auf weiteren Knoten gestoppt, wenn die Fehlerzählung 5 überschreitet. Der Zuordnung wird für Compliance-Berichte der Schweregrad Mittel zugewiesen. Diese Assoziation wird entsprechend dem angegebenen Cron-Zeitplan ausgeführt. Sie wird nicht unmittelbar nach dem Erstellen der Zuordnung ausgeführt.
------
#### [ 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
```
------
Im folgenden Beispiel wird eine Zuordnung erstellt, die auf Knoten ausgeführt wird, die mit einer bestimmten Knoten-ID gekennzeichnet sind. Die Assoziation verwendet das SSM Agent-Dokument zur Aktualisierung von SSM Agent für die Zielknoten, wenn der Änderungskalender geöffnet ist. Die Zuordnung überprüft den Kalenderstatus, wenn er ausgeführt wird. Wenn der Kalender beim Start geschlossen ist und die Zuordnung nur einmal ausgeführt wird, wird diese nicht erneut ausgeführt, da das Ausführungsfenster der Zuordnung abgelaufen ist. Wenn der Kalender geöffnet ist, wird die Zuordnung entsprechend ausgeführt.
**Anmerkung**
Wenn Sie neue Knoten zu den Tags oder Ressourcengruppen hinzufügen, auf die eine Assoziation wirkt, wenn der Änderungskalender geschlossen ist, wird die Assoziation auf diese Knoten angewendet, sobald der Änderungskalender geöffnet wird.
------
#### [ 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)"
```
------
Im folgenden Beispiel wird eine Zuordnung erstellt, die auf Knoten ausgeführt wird, die mit einer bestimmten Knoten-ID gekennzeichnet sind. Die ZuoAssoziation verwendet das Dokument SSM Agent, um jeden Sonntag um 2:00 Uhr SSM Agent auf den Zielknoten zu aktualisieren. Diese Assoziation wird nur zum angegebenen Cron-Zeitplan ausgeführt, wenn der Änderungskalender geöffnet ist. Wenn die Zuordnung erstellt wird, überprüft sie den Kalenderstatus. Wenn der Kalender geschlossen ist, wird die Zuordnung nicht angewendet. Wenn das Intervall zum Anwenden der Zuordnung am Sonntag um 2:00 Uhr beginnt, prüft die Zuordnung, ob der Kalender geöffnet ist. Wenn der Kalender geöffnet ist, wird die Zuordnung entsprechend ausgeführt.
**Anmerkung**
Wenn Sie neue Knoten zu den Tags oder Ressourcengruppen hinzufügen, auf die eine Assoziation wirkt, wenn der Änderungskalender geschlossen ist, wird die Assoziation auf diese Knoten angewendet, sobald der Änderungskalender geöffnet wird.
------
#### [ 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 *)"
```
------
**Anmerkung**
Wenn Sie die von Ihnen erstellte Zuordnung löschen, wird die Zuordnung nicht mehr auf Zielen dieser Zuordnung ausgeführt. Wenn Sie den Parameter `apply-only-at-cron-interval` angegeben haben, können Sie diese Option auch zurücksetzen. Geben Sie dazu den Parameter `no-apply-only-at-cron-interval` an, wenn Sie die Zuordnung über die Befehlszeile aktualisieren. Dieser Parameter erzwingt die sofortige Ausführung der Zuordnung nach dem Aktualisieren der Zuordnung und gemäß dem angegebenen Intervall.
# Bearbeiten und Erstellen einer neuen Version einer Zuordnung
Sie können eine State Manager-Zuordnung bearbeiten, um den Namen, den Zeitplan, den Schweregrad, Ziele, oder andere Werte zu ändern. Bei Zuordnungen, die auf Dokumenten vom Typ „SSM-Befehl“ basieren, können Sie die Ausgabe des Befehls auch in einen Amazon Simple Storage Service (Amazon S3)-Bucket schreiben. Nachdem Sie eine Zuordnung bearbeitet haben, erstellt State Manager eine neue Version. Sie können unterschiedliche Versionen, wie in den folgenden Schritten beschrieben, nach der Bearbeitung anzeigen.
**Anmerkung**
Damit Verknüpfungen, die mit Automations-Runbooks erstellt wurden, angewendet werden können, wenn neue Zielknoten erkannt werden, müssen bestimmte Bedingungen erfüllt sein. Weitere Informationen finden Sie unter [Informationen zu Zielupdates mit Automation-Runbooks](state-manager-about.md#runbook-target-updates).
Die folgenden Verfahren beschreiben, wie Sie mithilfe der Systems Manager Manager-Konsole () und AWS Command Line Interface AWS -Tools für PowerShell (Tools für AWS CLI PowerShell) eine neue Version einer Zuordnung bearbeiten und erstellen.
**Wichtig**
State Manager unterstützt nicht das Ausführen von Zuordnungen, die eine neue Version eines Dokuments verwenden, wenn dieses Dokument von einem anderen Konto freigegeben wird. State Manager läuft immer die `default`-Version eines Dokuments, wenn es von einem anderen Konto freigegeben wird, obwohl die Systems-Manager-Konsole anzeigt, dass eine neue Version verarbeitet wurde. Wenn Sie eine Zuordnung mit einer neuen Version eines Dokuments ausführen möchten, das von einem anderen Konto freigegeben wurde, müssen Sie die Dokumentversion auf `default` einstellen.
## Bearbeiten einer Zuordnung (Konsole)
Im folgenden Verfahren wird beschrieben, wie Sie mithilfe der Systems Manager-Konsole eine neue Version einer Zuordnung bearbeiten und erstellen.
**Anmerkung**
Für Zuordnungen, die SSM-Befehlsdokumente und keine Automation-Runbooks verwenden, erfordert dieses Verfahren, dass Sie Schreibzugriff auf einen vorhandenen Amazon-S3-Bucket haben. Wenn Sie Amazon S3 bisher nicht verwendet haben, bedenken Sie, dass Gebühren für die Nutzung von Amazon S3 anfallen. Weitere Informationen zum Erstellen eines Buckets finden Sie unter [Erstellen eines Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html).
**So bearbeiten Sie eine State Manager-Zuordnung**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **State Manager** aus.
1. Wählen Sie eine vorhandene Zuordnung und dann **Bearbeiten** aus.
1. Konfigurieren Sie die Zuordnung so erneut, dass sie Ihre aktuellen Anforderungen erfüllt.
Informationen zu den Zuordnungsoptionen mit `Command`- und `Policy`-Dokumenten finden Sie unter [Erstellen von Zuordnungen](state-manager-associations-creating.md). Informationen zu Zuordnungsoptionen mit Automation-Runbooks finden Sie unter [Planen von Automatisierungen mit State Manager-Zuordnungen](scheduling-automations-state-manager-associations.md).
1. Wählen Sie **Save Changes**.
1. (Optional) Um Zuordnungsinformationen anzuzeigen, wählen Sie auf der Seite **Zuordnungen** den Namen der von Ihnen bearbeiteten Zuordnung und dann die Registerkarte **Versionen** aus. Das System listet alle Version der Zuordnung auf, die Sie erstellt und bearbeitet haben.
1. (Optional) Gehen Sie wie folgt vor, um die Ausgabe für Verknüpfungen anzuzeigen, die auf `Command`-SSM-Dokumenten basieren:
1. Öffnen Sie die Amazon S3 S3-Konsole unter [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. Wählen Sie den Namen des Amazon S3-Buckets, den Sie zum Speichern von Befehlsausgaben angegeben haben, und wählen Sie dann den Ordner, dessen Name der ID dem Knoten entspricht, der die Assoziation ausgeführt hat. (Wenn Sie festgelegt haben, Ausgaben in einem Ordner im Bucket zu speichern, öffnen Sie diesen zuerst.)
1. Zeigen Sie die `stdout`-Datei in einer tieferen Ebenen im Ordner `awsrunPowerShell` an.
1. Wählen Sie **Open** oder **Download**, um den Hostnamen anzuzeigen.
## Bearbeiten einer Zuordnung (Befehlszeile)
Das folgende Verfahren beschreibt, wie Sie die AWS CLI (unter Linux oderWindows Server) verwenden oder AWS -Tools für PowerShell eine neue Version einer Assoziation bearbeiten und erstellen.
**So bearbeiten Sie eine State Manager-Zuordnung**
1. Installieren und konfigurieren Sie die AWS CLI oder die AWS -Tools für PowerShell, falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) und [Installieren des AWS -Tools für PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Verwenden Sie das folgende Format, um einen Befehl zum Bearbeiten und Erstellen einer neuen Version einer vorhandenen State Manager-Zuordnung zu erstellen. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen.
**Wichtig**
Wenn Sie `[https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/desupdatecribe-association.html)` aufrufen, löscht das System alle optionalen Parameter aus der Anforderung und überschreibt die Zuordnung mit Nullwerten für diese Parameter. Dies ist beabsichtigt. Sie müssen alle optionalen Parameter im Aufruf angeben, auch wenn Sie die Parameter nicht ändern. Dies umfasst den `--name`-Parameter. Bevor Sie diese Aktion aufrufen, empfehlen wir, dass Sie den `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-association.html)`-API-Vorgang aufrufen und sich alle optionalen Parameter notieren, die für Ihren `update-association`-Aufruf erforderlich sind.
------
#### [ 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
```
------
Im folgenden Beispiel wird eine vorhandene Zuordnung aktualisiert, um den Namen in `TestHostnameAssociation2` zu ändern. Die neue Zuordnungsversion wird stündlich ausgeführt und schreibt die Ausgabe der Befehle in den angegebenen Amazon S3-Bucket.
------
#### [ 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 * * ? *)"
```
------
Im folgenden Beispiel wird eine vorhandene Zuordnung aktualisiert, um den Namen in `CalendarAssociation` zu ändern. Die neue Zuordnung wird ausgeführt, wenn der Kalender geöffnet ist, und schreibt die Befehlsausgabe in den angegebenen Amazon S3-Bucket.
------
#### [ 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"
```
------
Im folgenden Beispiel wird eine vorhandene Zuordnung aktualisiert, um den Namen in `MultiCalendarAssociation` zu ändern. Die neue Zuordnung wird ausgeführt, wenn die Kalender geöffnet sind, und schreibt die Befehlsausgabe in den angegebenen Amazon S3-Bucket.
------
#### [ 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. Um die neue Version der Zuordnung anzuzeigen, führen Sie den folgenden Befehl aus.
------
#### [ 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 *
```
------
Das System gibt unter anderem folgende Informationen zurück
------
#### [ 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}
```
------
# Löschen von Zuordnungen
Gehen Sie wie folgt vor, um eine Zuordnung mithilfe der AWS Systems Manager -Konsole zu löschen.
**Löschen einer Zuordnung**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **State Manager** aus.
1. Wählen Sie eine Zuordnung aus und wählen Sie **Löschen** aus.
Sie können mehrere Verknüpfungen in einem einzigen Vorgang löschen, indem Sie eine Automatisierung von der AWS Systems Manager Konsole aus ausführen. Wenn Sie mehrere Verknüpfungen zum Löschen auswählen, startet State Manager die Startseite des Automatisierungs-Runbooks mit der Zuordnung, die als Eingabeparameterwerte IDs eingegeben wurde.
**So können mehrere Verknüpfungen in einem einzigen Vorgang löschen**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **State Manager** aus.
1. Wählen Sie jede Zuordnung aus, die Sie löschen möchten, und wählen Sie dann **Löschen**.
1. (Optional) Wählen Sie im Bereich **Zusätzliche Eingabeparameter** den Amazon-Ressourcennamen (ARN) für die *angenommene Rolle aus*, die die Automatisierung während der Ausführung verwenden soll. Um eine neue Rolle zu erstellen, wählen Sie **Erstellen**.
1. Wählen Sie **Absenden** aus.
# Ausführen von Auto-Scaling-Gruppen mit Zuordnungen
Die bewährte Methode beim Verwenden von Zuordnungen zum Ausführen von Auto-Scaling-Gruppen besteht darin, Tag-Ziele zu verwenden. Wenn Sie Tags nicht verwenden, könnten Sie das Zuordnungslimit erreichen.
Wenn alle Knoten mit demselben Schlüssel und demselben Wert versehen sind, benötigen Sie nur eine Assoziation, um Ihre Auto-Scaling-Gruppe auszuführen. Im folgenden Verfahren wird beschrieben, wie Sie so eine Zuordnung erstellen.
**Erstellen einer Zuordnung, auf der Auto-Scaling-Gruppen ausgeführt wird**
1. Stellen Sie sicher, dass alle Knoten in der Auto-Scaling-Gruppe mit demselben Schlüssel und demselben Wert versehen sind. Weitere Informationen zum Markieren von Knoten finden Sie unter [Markieren von Auto-Scaling-Gruppen und Knoten](https://docs.aws.amazon.com//autoscaling/ec2/userguide/autoscaling-tagging.html) im *AWS Auto Scaling -Benutzerhandbuch*.
1. Erstellen Sie eine Zurodnung unter Verwendung des Verfahrens in [Arbeiten mit Zuordnungen in Systems Manager](state-manager-associations.md).
Wenn Sie in der Konsole arbeiten, wählen Sie **Specify instance tags (Instance-Tags angeben)** im Feld **Targets (Ziele)**. Geben Sie für **Instance-Tags** den **Tag**-Schlüssel und -Welt für Ihre Auto-Scaling-Gruppe ein.
Wenn Sie AWS Command Line Interface (AWS CLI) verwenden, geben Sie an, `--targets Key=tag:tag-key,Values=tag-value` wo der Schlüssel und der Wert mit dem übereinstimmen, womit Sie Ihre Knoten markiert haben.
# Anzeigen von Zuordnungsverläufen
Mithilfe der [DescribeAssociationExecutions](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutions.html)API-Operation können Sie alle Ausführungen für eine bestimmte Zuordnungs-ID anzeigen. Verwenden Sie diesen Vorgang, um Status, detaillierten Status, Ergebnisse, Uhrzeit der letzten Ausführung und weitere Informationen zu einer State Manager-Zuordnung einzusehen. State Manager ist ein Tool in AWS Systems Manager. Diese API-Operation enthält auch Filter, mit denen Sie entsprechend den von Ihnen festgelegten Kriterien nach Zuordnungen suchen können. Sie können beispielsweise genaue Angaben zu Datum und Uhrzeit machen und mithilfe eines GREATER\$1THAN-Filters Ausführungen anzeigen, die nach dem angegebenen Datum und der angegebenen Uhrzeit verarbeitet wurden.
Wenn beispielsweise die Ausführung einer Zuordnung fehlgeschlagen ist, können Sie mithilfe des [DescribeAssociationExecutionTargets](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeAssociationExecutionTargets.html)API-Vorgangs einen Drilldown zu den Details einer bestimmten Ausführung durchführen. Dieser Vorgang zeigt Ihnen die Ressourcen, z. B. den Knoten IDs, auf dem die Zuordnung ausgeführt wurde, und die verschiedenen Zuordnungsstatus. Anschließend können Sie sehen, bei welchen Ressourcen oder Knoten eine Assoziation nicht ausgeführt werden konnte. Anhand der Ressourcen-ID können Sie dann die Details der Befehlsausführung anzeigen, um zu bestimmen, welcher Schritt in einem Befehl fehlgeschlagen ist.
Die Beispiele in diesem Abschnitt enthalten auch Informationen darüber, wie Sie mithilfe des [StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html)API-Vorgangs eine Assoziation einmal bei der Erstellung ausführen können. Sie können mithilfe dieser API-Operation fehlgeschlagenen Zuordnungsausführungen nachgehen. Wenn Sie sehen, dass eine Zuordnung fehlgeschlagen ist, können Sie eine Änderung an der Ressource vornehmen und dann die Zuordnung sofort ausführen, um zu sehen, ob die Änderung an der Ressource nun eine erfolgreiche Ausführung der Zuordnung zulässt.
**Anmerkung**
API-Vorgänge, die während der Ausführung einer Zuordnung durch das SSM-Dokument initiiert werden, werden in AWS CloudTrail nicht protokolliert.
## Anzeigen von Zuordnungsverläufen (Konsole)
Mit dem folgenden Verfahren können Sie den Ausführungsverlauf für eine bestimmte Zuordnungs-ID und anschließend Ausführungsdetails für eine oder mehrere Ressourcen anzeigen.
**So zeigen Sie den Ausführungsverlauf für eine bestimmte Zuordnungs-ID an**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie **State Manager**.
1. Wählen Sie im Feld **Association id (Zuordnungs-ID)** eine Zuordnung aus, deren Verlauf Sie anzeigen möchten.
1. Klicken Sie auf die Schaltfläche **View details (Details ansehen)**.
1. Wählen Sie die Registerkarte **Execution history (Ausführungsverlauf)**.
1. Wählen Sie eine Zuordnung aus, für die Sie Ausführungsdetails auf Ressourcenebene anzeigen möchten. Wählen Sie z. B. eine Zuordnung mit dem Status **Failed (Fehlgeschlagen)** aus. Anschließend können Sie die Ausführungsdetails für die Koten anzeigen, bei denen das Ausführen der Assoziation fehlgeschlagen ist.
Verwenden Sie die Suchfeldfilter zur Suche nach der Ausführung, für die Sie Details anzeigen möchten.
![\[Filtern Sie die Liste der State Manager-Zuordnungsausführungen.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/sysman-state-executions-filter.png)
1. Wählen eine Ausführungs-ID aus. Die Seite **Association execution targets (Zuordnungsausführungsziele)** wird geöffnet. Diese Seite zeigt alle Ressourcen an, die die Zuordnung ausgeführt haben.
1. Wählen Sie eine Ressourcen-ID aus, um spezifische Informationen zu dieser Ressource anzuzeigen.
Verwenden Sie die Suchfeldfilter zur Suche nach der Ressource, für die Sie Details anzeigen möchten.
![\[Filtern Sie die Liste der State Manager-Zuordnungsausführungsziele.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/sysman-state-executions-targets-filter.png)
1. Wenn Sie eine Zuordnung untersuchen, die nicht ausgeführt werden konnte, können Sie mit der Schaltfläche **Apply association now (Zuordnung nun anwenden)** eine Zuordnung nur einmal zum Zeitpunkt der Erstellung ausführen. Nachdem Sie Änderungen an der Ressource vorgenommen haben, bei der die Zuordnung nicht ausgeführt werden konnte, wählen Sie den Link **Association ID (Zuordnungs-ID)** im Navigations-Breadcrumb aus.
1. Klicken Sie auf die Schaltfläche **Apply association now (Zuordnung nun anwenden)**. Wenn die Ausführung abgeschlossen ist, überprüfen Sie, ob die Zuordnungsausführung erfolgreich war.
## Anzeigen von Zuordnungsverläufen (Befehlszeile)
Das folgende Verfahren beschreibt, wie Sie AWS Command Line Interface (AWS CLI) (unter Linux oderWindows Server) verwenden oder AWS -Tools für PowerShell den Ausführungsverlauf für eine bestimmte Zuordnungs-ID anzeigen. Im Anschluss an dieses Verfahren wird beschrieben, wie Sie Ausführungsdetails für eine oder mehrere Ressourcen anzeigen.
**So zeigen Sie den Ausführungsverlauf für eine bestimmte Zuordnungs-ID an**
1. Installieren und konfigurieren Sie das AWS CLI oder das AWS -Tools für PowerShell, falls Sie das noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) und [Installieren des AWS -Tools für PowerShell](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html).
1. Führen Sie den folgenden Befehl aus, um eine Liste von Ausführungen für eine bestimmte Zuordnungs-ID anzuzeigen.
------
#### [ Linux & macOS ]
```
aws ssm describe-association-executions \
--association-id ID \
--filters Key=CreatedTime,Value="2018-04-10T19:15:38.372Z",Type=GREATER_THAN
```
**Anmerkung**
Dieser Befehl wendet einen Filter an, um die Ergebnisse auf solche Ausführungen einzuschränken, die nach einem bestimmten Datum und einer bestimmten Uhrzeit aufgetreten sind. Wenn Sie alle Ausführungen für eine bestimmte Zuordnungs-ID anzeigen möchten, entfernen Sie den Parameter `--filters` und den Wert ` 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
```
**Anmerkung**
Dieser Befehl wendet einen Filter an, um die Ergebnisse auf solche Ausführungen einzuschränken, die nach einem bestimmten Datum und einer bestimmten Uhrzeit aufgetreten sind. Wenn Sie alle Ausführungen für eine bestimmte Zuordnungs-ID anzeigen möchten, entfernen Sie den Parameter `--filters` und den Wert ` 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"}
```
**Anmerkung**
Dieser Befehl wendet einen Filter an, um die Ergebnisse auf solche Ausführungen einzuschränken, die nach einem bestimmten Datum und einer bestimmten Uhrzeit aufgetreten sind. Wenn Sie alle Ausführungen für eine bestimmte Zuordnungs-ID anzeigen möchten, entfernen Sie den Parameter `-Filter` und den Wert ` @{"Key"="CreatedTime";"Value"="2019-06-01T19:15:38.372Z";"Type"="GREATER_THAN"}`.
------
Das System gibt unter anderem folgende Informationen zurück
------
#### [ 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
```
------
Sie können die Ergebnisse einschränken, indem Sie einen oder mehrere Filter verwenden. Das folgende Beispiel gibt alle Zuordnungen zurück, die vor einem bestimmten Datum und einer bestimmten Uhrzeit ausgeführt wurden.
------
#### [ 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"}
```
------
Das folgende Beispiel gibt alle Zuordnungen zurück, die nach einem bestimmten Datum und einer bestimmten Uhrzeit *erfolgreich* ausgeführt wurden.
------
#### [ 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. Führen Sie den folgenden Befehl aus, um alle Ziele anzuzeigen, an denen die betreffende Ausführung ausgeführt wurde.
------
#### [ 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
```
------
Sie können die Ergebnisse einschränken, indem Sie einen oder mehrere Filter verwenden. Das folgende Beispiel gibt Informationen über alle Ziele zurück, an denen die betreffende Zuordnung nicht ausgeführt werden konnte.
------
#### [ 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"
}
```
------
Das folgende Beispiel gibt Informationen über einen bestimmten verwalteten Knoten zurück, bei dem eine Assoziation nicht ausgeführt werden konnte.
------
#### [ 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. Wenn Sie eine Verknüpfung untersuchen, die nicht ausgeführt werden konnte, können Sie den [StartAssociationsOnce](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_StartAssociationsOnce.html)API-Vorgang verwenden, um eine Verknüpfung sofort und nur einmal auszuführen. Nachdem Sie Änderungen an der Ressource vornehmen, bei der die Zuordnung nicht ausgeführt werden konnte, führen Sie den folgenden Befehl aus, um die Zuordnung sofort und nur einmal auszuführen.
------
#### [ Linux & macOS ]
```
aws ssm start-associations-once \
--association-id ID
```
------
#### [ Windows ]
```
aws ssm start-associations-once ^
--association-id ID
```
------
#### [ PowerShell ]
```
Start-SSMAssociationsOnce `
-AssociationId ID
```
------
# Arbeiten mit Zuordnungen mithilfe von IAM
State Manager, ein Tool in AWS Systems Manager, verwendet [Ziele](systems-manager-state-manager-targets-and-rate-controls.md#systems-manager-state-manager-targets-and-rate-controls-about-targets), um auszuwählen, mit welchen Instances Sie Ihre Verknüpfungen konfigurieren. Ursprünglich wurden Zuordnungen erstellt, indem ein Dokumentname (`Name`) und Instance-ID (`InstanceId`) angegeben wurden. Dadurch wurde eine Zuordnung zwischen einem Dokument und einer Instance oder einem verwalteten Knoten erstellt. Zuordnungen wurden durch diese Parameter identifiziert. Diese Parameter sind jetzt veraltet, werden aber weiterhin unterstützt. Die Ressourcen `instance` und `managed-instance` wurden als Ressourcen zu Aktionen mit `Name` und `InstanceId` hinzugefügt.
AWS Identity and Access Management Das Verhalten bei der Durchsetzung von Richtlinien (IAM) hängt vom angegebenen Ressourcentyp ab. Ressourcen für State Manager-Vorgänge werden nur basierend auf der übergebenen Anforderung erzwungen. State Manager führt keine tiefe Prüfung auf die Eigenschaften von Ressourcen in Ihrem Konto durch. Eine Anforderung wird nur anhand von Richtlinienressourcen validiert, wenn der Anforderungsparameter die angegebenen Richtlinienressourcen enthält. Wenn Sie beispielsweise eine Instance im Ressourcenblock angeben, wird die Richtlinie erzwungen, wenn die Anforderung den `InstanceId`-Parameter verwendet. Der `Targets`-Parameter für jede Ressource im Konto wird nicht für diese `InstanceId` überprüft.
Im Folgenden sind einige Fälle mit verwirrendem Verhalten dargestellt:
+ [DescribeAssociation[DeleteAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DeleteAssociation.html)](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_DescribeActivations.html), und [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html)verwenden Sie`instance`,, und `document` Ressourcen`managed-instance`, um die veraltete Art des Verweises auf Assoziationen anzugeben. Dies beinhaltet alle Zuordnungen, die mit dem veralteten `InstanceId`-Parameter erstellt wurden.
+ [CreateAssociation[CreateAssociationBatch](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociationBatch.html)](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_CreateAssociation.html), und [UpdateAssociation](https://docs.aws.amazon.com//systems-manager/latest/APIReference/API_UpdateAssociation.html)verwenden Sie `instance` und `managed-instance` Ressourcen, um die veraltete Art der Bezugnahme auf Assoziationen zu spezifizieren. Dies beinhaltet alle Zuordnungen, die mit dem veralteten `InstanceId`-Parameter erstellt wurden. Der `document`-Ressourcentyp ist Teil der veralteten Methode, auf Zuordnungen zu verweisen und ist eine tatsächliche Eigenschaft einer Zuordnung. Das bedeutet, dass Sie IAM-Richtlinien mit den Berechtigungen `Allow` oder `Deny` für `Create`- und `Update`-Aktionen auf der Grundlage des Dokumentennamens erstellen können.
Weitere Informationen zur Verwendung von IAM-Richtlinien mit Systems Manager finden Sie unter [Identity and Access Management für AWS Systems Manager](security-iam.md) oder [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Systems Manager](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanager.html) in der *Service Authorization-Referenz*.
# Erstellen von Zuordnungen, die MOF-Dateien ausführen
Sie können MOF-Dateien (Managed Object Format) ausführen, um mithilfe eines Tools in State Manager AWS Systems Manager, mithilfe des `AWS-ApplyDSCMofs` SSM-Dokuments einen Zielstatus auf Windows Server verwalteten Knoten zu erzwingen. Das `AWS-ApplyDSCMofs`-Dokument weist zwei Ausführungsmodi auf. Mit dem ersten Modus können Sie die Assoziation so konfigurieren, dass sie die verwalteten Knoten scannt und meldet, wenn sie den in den MOF-Dateien definierten gewünschten Status aufweisen. Im zweiten Modus können Sie die MOF-Dateien ausführen und die Konfiguration Ihrer Knoten basierend auf den Ressourcen und ihren in den MOF-Dateien definierten Werten ändern. Mit dem `AWS-ApplyDSCMofs`-Dokument können Sie MOF-Konfigurationsdateien von Amazon Simple Storage Service (Amazon S3), einem lokal freigegebenen Verzeichnis, oder einer sicheren Website mit einer HTTPS-Domain herunterladen und ausführen.
State Manager protokolliert und meldet den Status der einzelnen MOF-Dateiausführungen bereits während die Zuordnungen ausgeführt werden. Darüber hinaus meldet State Manager die Ausgabe der MOF-Dateiausführungen als Compliance-Ereignis, das Sie auf der [AWS Systems Manager Compliance](https://console.aws.amazon.com/systems-manager/compliance)-Seite anzeigen können.
Die Ausführung von MOF-Dateien basiert auf der Windows PowerShell Desired State Configuration (PowerShell DSC). PowerShell DSC ist eine deklarative Plattform, die für die Konfiguration, Bereitstellung und Verwaltung von Windows-Systemen verwendet wird. PowerShell DSC ermöglicht es Administratoren, in einfachen Textdokumenten, den sogenannten DSC-Konfigurationen, zu beschreiben, wie ein Server konfiguriert werden soll. Eine PowerShell DSC-Konfiguration ist ein spezielles PowerShell Skript, das angibt, was zu tun ist, aber nicht, wie es zu tun ist. Bei der Ausführung der Konfiguration wird eine MOF-Datei erzeugt. Die MOF-Datei kann auf einen oder mehrere Server angewendet werden, um die gewünschte Konfiguration für diese Server zu erreichen. PowerShell DSC-Ressourcen übernehmen die eigentliche Aufgabe, die Konfiguration durchzusetzen. Weitere Informationen finden Sie unter Übersicht über die [Konfiguration des PowerShell gewünschten Windows-Zustands](https://download.microsoft.com/download/4/3/1/43113F44-548B-4DEA-B471-0C2C8578FBF8/Quick_Reference_DSC_WS12R2.pdf).
**Topics**
+ [Verwenden von Amazon S3 zum Speichern von Artefakten](#systems-manager-state-manager-using-mof-file-S3-storage)
+ [Auflösen von Anmeldeinformationen in MOF-Dateien](#systems-manager-state-manager-using-mof-file-credentials)
+ [Verwenden von Token in MOF-Dateien](#systems-manager-state-manager-using-mof-file-tokens)
+ [Voraussetzungen zum Erstellen von Zuordnungen, die MOF-Dateien ausführen](#systems-manager-state-manager-using-mof-file-prereqs)
+ [Erstellen einer Zuordnung, die MOF-Dateien ausführt](#systems-manager-state-manager-using-mof-file-creating)
+ [Problembehandlung bei der Erstellung von Zuordnungen, die MOF-Dateien ausführen](#systems-manager-state-manager-using-mof-file-troubleshooting)
+ [Anzeigen von Details zur DSC-Ressourcen-Compliance](#systems-manager-state-manager-viewing-mof-file-compliance)
## Verwenden von Amazon S3 zum Speichern von Artefakten
Wenn Sie Amazon S3 zum Speichern von PowerShell Modulen, MOF-Dateien, Compliance-Berichten oder Statusberichten verwenden, AWS Systems Manager SSM Agent müssen die von verwendete AWS Identity and Access Management (IAM) -Rolle `GetObject` und die `ListBucket` Berechtigungen für den Bucket vorhanden sein. Ohne diese Berechtigungen gibt das System einen *Zugriff verweigert* Fehler zurück. Unten finden Sie wichtige Informationen zum Speichern von Artefakten in Amazon S3.
+ Wenn sich der Bucket in einem anderen befindet AWS-Konto, erstellen Sie eine Bucket-Ressourcenrichtlinie, die dem Konto (oder der IAM-Rolle) `GetObject` und Berechtigungen gewährt. `ListBucket`
+ Wenn Sie benutzerdefinierte DSC-Ressourcen verwenden möchten, können Sie diese Ressourcen aus einem Amazon S3-Bucket herunterladen. Sie können sie auch automatisch aus der PowerShell Galerie installieren.
+ Wenn Sie Amazon S3 als Modulquelle verwenden, laden Sie das Modul als Zip-Datei im folgenden Format mit Groß- und Kleinschreibung hoch: *ModuleName* \$1 *ModuleVersion* .zip. Zum Beispiel: \$11.0.0.zip MyModule.
+ Alle Dateien müssen im sich im Stammverzeichnis des Buckets befinden. Ordnerstrukturen werden nicht unterstützt.
## Auflösen von Anmeldeinformationen in MOF-Dateien
Anmeldeinformationen werden mithilfe von [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/) oder [AWS Systems Manager Parameter Store](systems-manager-parameter-store.md) aufgelöst. Auf diese Weise können Sie eine automatische Rotation der Anmeldeinformationen einrichten. Auf diese Weise kann DSC auch Anmeldeinformationen automatisch an Ihre Server weitergeben, ohne sie erneut bereitstellen zu müssen. MOFs
Um ein AWS Secrets Manager Geheimnis in einer Konfiguration zu verwenden, erstellen Sie ein PSCredential Objekt, bei dem der Benutzername der SecretId oder SecretARN des Geheimnisses ist, das die Anmeldeinformationen enthält. Sie können für das Passwort einen beliebigen Wert angeben. Der Wert wird ignoriert. Im Folgenden sehen Sie ein Beispiel.
```
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
}
}
}
```
Kompilieren Sie Ihr MOF mithilfe der PsAllowPlaintextPassword Einstellung in den Konfigurationsdaten. Dies ist kein besonderes Risiko, weil die Anmeldeinformationen nur einen Bezeichner enthalten.
Stellen Sie in Secrets Manager sicher, dass der Knoten in einer von IAM verwalteten Richtlinie und optional in der Secret Resource Policy, falls vorhanden, GetSecretValue Zugriff hat. Für die Arbeit mit DSC muss das Geheimnis das folgende Format aufweisen.
```
{ 'Username': 'a_name', 'Password': 'a_password' }
```
Das Secret kann weitere Eigenschaften (z. B. Eigenschaften für die Rotation) haben, aber es muss mindestens den Benutzernamen und das Passwort enthalten.
Es wird empfohlen, eine Rotationsmethode für mehrere Benutzer zu verwenden, bei der Sie zwei verschiedene Benutzernamen und Kennwörter verwenden und die AWS Lambda Rotationsfunktion zwischen diesen wechselt. Diese Methode ermöglicht Ihnen, mehrere aktive Konten zu haben, ohne in Gefahr zu laufen, dass Benutzer bei einer Rotation ausgesperrt werden.
## Verwenden von Token in MOF-Dateien
Token bieten Ihnen die Möglichkeit, Eigenschaftswerte von Ressourcen zu ändern, *nachdem* die MOF-Datei kompiliert wurde. Auf diese Weise können Sie häufig verwendete MOF-Dateien auf mehreren Servern mit ähnlichen Konfigurationen wiederverwenden.
Die Ersetzung der Token funktioniert nur für Ressourceneigenschaften des Typs `String`. Wenn Ihre Ressource jedoch eine eingebettete CIM-Knoten-Eigenschaft hat, löst sie auch Token von `String`-Eigenschaften in diesem CIM-Knoten auf. Sie können die Token-Ersetzung nicht für Zahlen oder Arrays verwenden.
Stellen Sie sich beispielsweise ein Szenario vor, in dem Sie die xComputerManagement Ressource verwenden und den Computer mithilfe von DSC umbenennen möchten. Normalerweise benötigen Sie eine dedizierte MOF-Datei für diesen Computer. Mit der Token-Unterstützung können Sie eine MOF-Datei erstellen und diese auf alle Ihre Knoten anwenden. Sie können in der `ComputerName`-Eigenschaft in der MOF-Datei anstelle des festkodierten Computernamens ein Token vom Typ Instance-Tag verwenden. Der Wert wird während beim Parsing der MOF-Datei aufgelöst. Sehen Sie sich das folgende Beispiel an.
```
Configuration MyConfig
{
xComputer Computer
{
ComputerName = '{tag:ComputerName}'
}
}
```
Sie setzen dann ein Tag entweder für den verwalteten Knoten in der Systems Manager-Konsole oder ein Amazon Elastic Compute Cloud (Amazon EC2)-Tag in der Amazon EC2-Konsole. Wenn Sie das Dokument ausführen, ersetzt das Skript den Wert des Instanz-Tags durch das Token \$1tag:ComputerName\$1.
Sie können auch mehrere Tags in einer einzigen Eigenschaft kombinieren, wie im folgenden Beispiel gezeigt.
```
Configuration MyConfig
{
File MyFile
{
DestinationPath = '{env:TMP}\{tag:ComputerName}'
Type = 'Directory'
}
}
```
Es gibt fünf verschiedene Arten von Token, die Sie verwenden können:
+ **tag**: Amazon EC2-Tag oder Tag auf einem verwalteten Knoten.
+ **tagb64**: Dies ist das gleiche wie tag, aber das System verwendet base64, um den Wert zu dekodieren. Auf diese Weise können Sie in Tag-Werten Sonderzeichen verwenden.
+ **env**: Löst Umgebungsvariablen auf.
+ **ssm**: Parameter Store-Werte. Es werden nur die Typen String und Secure String unterstützt.
+ **tagssm**: Dies ist dasselbe wie Tag, aber wenn das Tag auf dem Knoten nicht festgelegt ist, versucht das System, den Wert aus einem Systems Manager-Parameter mit demselben Namen aufzulösen. Dies ist nützlich, wenn Sie einen „globalen Standardwert“ benötigen, den Sie auf einzelnen Knoten außer Kraft setzen möchten (z. B. bei One-Box-Bereitstellungen).
Es folgt ein Parameter Store-Beispiel, bei dem der Token-Typ `ssm` verwendet wird.
```
File MyFile
{
DestinationPath = "C:\ProgramData\ConnectionData.txt"
Content = "{ssm:%servicePath%/ConnectionData}"
}
```
Token spielen eine wichtige Rolle bei der Reduzierung von redundantem Code, weil MOF-Dateien generisch und wiederverwendbar werden. Wenn Sie serverspezifische MOF-Dateien vermeiden können, benötigen Sie auch keinen Service, um die MOF-Datei zu erstellen. Ein MOF-Building-Service erhöht die Kosten, verlangsamt die Bereitstellungszeit und erhöht das Risiko von Konfigurationsabweichungen zwischen gruppierten Knoten, da bei der Kompilierung unterschiedliche Modulversionen auf dem Build-Server installiert wurden. MOFs
## Voraussetzungen zum Erstellen von Zuordnungen, die MOF-Dateien ausführen
Bevor Sie eine Assoziation erstellen, die MOF-Dateien ausführt, überprüfen Sie, ob Ihre verwalteten Knoten die folgenden Voraussetzungen erfüllen:
+ Windows PowerShell Version 5.0 oder höher. Weitere Informationen finden Sie unter [ PowerShell Systemanforderungen für Windows](https://docs.microsoft.com/en-us/powershell/scripting/install/windows-powershell-system-requirements?view=powershell-6) auf Microsoft.com.
+ [AWS Tools for Windows PowerShell](https://aws.amazon.com/powershell/) Version 3.3.261.0 oder höher
+ SSM Agent, Version 2.2 oder höher.
## Erstellen einer Zuordnung, die MOF-Dateien ausführt
**So erstellen Sie eine Zuordnung, die MOF-Dateien ausführt**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **State Manager** aus.
1. Wählen Sie **State Manager** und dann **Zuordnung wählen** aus.
1. Geben Sie im Feld **Name** einen Namen an. Dies ist zwar optional, wird aber empfohlen. Ein Name kann Ihnen helfen, den Zweck der Zuordnung zu verstehen, nachdem Sie sie erstellt haben. Der Name darf keine Leerzeichen enthalten.
1. Wählen Sie in der Liste **Dokument** die Option **`AWS-ApplyDSCMofs`** aus.
1. Geben Sie im Abschnitt **Parameters (Parameter)** die benötigten Angaben für die erforderlichen und die optionalen Eingabeparameter ein.
1. **Mofs To Apply (Anzuwendende MOF-Dateien)**: Geben Sie eine oder mehrere MOF-Dateien an, die mit dieser Zuordnung ausgeführt werden sollen. Um eine Liste von MOF-Dateien anzugeben, trennen Sie die Dateinamen mit Kommas. Systems Manager durchläuft die Liste der MOF-Dateien und führt sie in der Reihenfolge aus, die in der kommagetrennten Liste angegeben ist.
+ Eine Amazon S3-Bucket-Bezeichnung. Bucketnamen müssen Kleinbuchstaben angegeben werden. Geben Sie diese Informationen in dem folgenden Format an.
```
s3:amzn-s3-demo-bucket:MOF_file_name.mof
```
Wenn Sie ein angeben möchten AWS-Region, verwenden Sie das folgende Format.
```
s3:bucket_Region:amzn-s3-demo-bucket:MOF_file_name.mof
```
+ Eine sichere Website. Geben Sie diese Informationen in dem folgenden Format an.
```
https://domain_name/MOF_file_name.mof
```
Ein Beispiel.
```
https://www.example.com/TestMOF.mof
```
+ Ein Dateisystem auf einer lokalen Freigabe. Geben Sie diese Informationen in dem folgenden Format an.
```
\server_name\shared_folder_name\MOF_file_name.mof
```
Ein Beispiel.
```
\StateManagerAssociationsBox\MOFs_folder\MyMof.mof
```
1. **Service Path (Service-Pfad)**: (Optional) Ein Service-Pfad ist entweder das Präfix eines Amazon S3-Buckets, in den Sie Berichte und Statusinformationen schreiben möchten, oder ein Service-Pfad ist ein Pfad für Parameter Store-Parameter-basierte Tags. Bei der Auflösung parameterbasierter Tags verwendet das System \$1ssm: %ServicePath%/*parameter\$1name*\$1, um den ServicePath-Wert in den Parameternamen einzufügen. Wenn Ihr WebServers/Production" then the systems resolves the parameter as: WebServers/Production *parameter\$1name* Dienstpfad beispielsweise "/ist. Dies ist nützlich, wenn Sie in einem Konto mehrere Umgebungen ausführen.
1. **Report Bucket Name (Bucket-Name für Berichte)**: (Optional) Geben Sie den Namen eines Amazon S3-Buckets ein, in den Sie Compliance-Daten schreiben möchten. Berichte werden in diesem Bucket im JSON-Format gespeichert.
**Anmerkung**
Sie können dem Bucketnamen ein Präfix voranstellen, um die Region anzugeben, in der sich der Bucket befindet. Hier ist ein Beispiel: US-West-2:MYMOFBucket. Wenn Sie einen Proxy für Amazon S3-Endpunkte in einer bestimmten Region verwenden, die us-east-1 nicht enthält, stellen Sie dem Bucket-Namen eine Region voran. Wenn dem Bucketname kein Präfix vorangestellt ist, wird die Bucketregion unter Verwendung des Endpunkts us-east-1 automatisch erkannt.
1. **Mof Operation Mode** (MOF-Betriebsmodus): Wählen Sie das State Manager-Verhalten beim Ausführen der Zuordnung **`AWS-ApplyDSCMofs`** aus:
+ **Apply** (Anwenden): Korrigiert Knoten-Konfigurationen, die nicht konform sind.
+ **ReportOnly**: Korrigieren Sie keine Knotenkonfigurationen, sondern protokollieren Sie stattdessen alle Compliance-Daten und melden Sie Knoten, die nicht konform sind.
1. **Status Bucket Name (Bucket-Name für Status)**: (Optional) Geben Sie den Namen eines Amazon S3-Buckets ein, in den Sie den MOF-Ausführungsstatus schreiben möchten. Diese Statusberichte sind Singleton-Zusammenfassungen des letzten Compliance-Laufs eines Knotens. Dies bedeutet, dass der Bericht überschrieben wird, wenn die Zuordnung das nächste Mal MOF-Dateien ausführt.
**Anmerkung**
Sie können dem Bucketnamen ein Präfix voranstellen, um die Region anzugeben, in der sich der Bucket befindet. Ein Beispiel: `us-west-2:amzn-s3-demo-bucket`. Wenn Sie einen Proxy für Amazon S3-Endpunkte in einer bestimmten Region verwenden, die us-east-1 nicht enthält, stellen Sie dem Bucket-Namen eine Region voran. Wenn dem Bucketname kein Präfix vorangestellt ist, wird die Bucketregion unter Verwendung des Endpunkts us-east-1 automatisch erkannt.
1. **Name des Quell-Buckets für das Modul**: (Optional) Geben Sie den Namen eines Amazon S3 S3-Buckets ein, der PowerShell Moduldateien enthält. Wenn Sie **None (Keine)** angeben, wählen Sie **True (Wahr)** für die nächste Option, **Allow PS Gallery Module Source**.
**Anmerkung**
Sie können dem Bucketnamen ein Präfix voranstellen, um die Region anzugeben, in der sich der Bucket befindet. Ein Beispiel: `us-west-2:amzn-s3-demo-bucket`. Wenn Sie einen Proxy für Amazon S3-Endpunkte in einer bestimmten Region verwenden, die us-east-1 nicht enthält, stellen Sie dem Bucket-Namen eine Region voran. Wenn dem Bucketname kein Präfix vorangestellt ist, wird die Bucketregion unter Verwendung des Endpunkts us-east-1 automatisch erkannt.
1. **Quelle des PS Gallery-Moduls zulassen**: (Optional) Wählen Sie **True**, um PowerShell Module von [https://www.powershellgallery.com/](https://www.powershellgallery.com/)herunterzuladen. Wenn Sie **Falsch** wählen, geben Sie eine Quelle für die vorherige Option an **ModuleSourceBucketName**.
1. **Proxy-URI**: (Optional) Verwenden Sie diese Option, um MOF-Dateien von einem Proxy-Server herunterzuladen.
1. **Reboot Behavior (Neustart-Verhalten)**: (Optional) Geben Sie eine der folgenden Neustart-Verhaltensweisen an, wenn die Ausführung Ihrer MOF-Datei einen Neustart erfordert:
+ **AfterMof**: Startet den Knoten neu, nachdem alle MOF-Ausführungen abgeschlossen sind. Selbst wenn mehrere MOF-Ausführungen einen Neustart anfordern, wartet das System mit dem Neustart, bis alle MOF-Ausführungen abgeschlossen sind.
+ **Immediately** (Sofort): Startet den Knoten neu, sobald eine MOF-Ausführung dies anfordert. Wenn mehrere MOF-Dateien ausgeführt werden, die einen Neustart anfordern, wird der Knoten mehrmals neu gestartet.
+ **Never** (Nie): Knoten werden selbst dann nicht neu gestartet, wenn die MOF-Ausführung explizit einen Neustart anfordert.
1. **Use Computer Name For Reporting (Computername für Berichte verwenden)**: (Optional) Aktivieren Sie diese Option, um in gemeldeten Compliance-Informationen den Namen des Computers aufzuführen. Der Standardwert ist **false** (falsch). Das bedeutet, dass das System bei der Meldung von Compliance-Informationen die Knoten-ID verwendet.
1. **Turn on Verbose Logging (Verbose-Protokollierung aktivieren)**: (Optional) Wir empfehlen, die Verbose-Protokollierung zu aktivieren, wenn Sie MOF-Dateien zum ersten Mal bereitstellen.
**Wichtig**
Wenn diese Option aktiviert ist, schreibt die ausführliche Protokollierung mehr Daten in Ihren Amazon S3-Bucket als die Standardprotokollierung für die Zuordnungsausführung. Dies kann dazu führen, dass die Leistung beeinträchtigt wird und etwas höhere Speichergebühren für Amazon S3 anfallen. Um diese Probleme beim Speichern großer Datenvolumen abzumildern, empfehlen wir, die Lebenszyklusrichtlinien für Ihren Amazon S3-Bucket zu aktivieren. Weitere Informationen finden Sie unter [Wie erstelle ich eine Lebenszyklus-Richtlinie für einen S3-Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
1. **Turn on Debug Logging (Debug-Protokollierung aktivieren)**: (Optional) Es wird empfohlen, die Debug-Protokollierung zu aktivieren, um MOF-Fehler zu beheben. Wir empfehlen außerdem, diese Option bei normaler Nutzung zu deaktivieren.
**Wichtig**
Wenn diese Option aktiviert ist, schreibt die Debug-Protokollierung mehr Daten in Ihren Amazon S3-Bucket als die Standardprotokollierung für die Zuordnungsausführung. Dies kann dazu führen, dass die Leistung beeinträchtigt wird und etwas höhere Speichergebühren für Amazon S3 anfallen. Um diese Probleme beim Speichern großer Datenvolumen abzumildern, empfehlen wir, die Lebenszyklusrichtlinien für Ihren Amazon S3-Bucket zu aktivieren. Weitere Informationen finden Sie unter [Wie erstelle ich eine Lebenszyklus-Richtlinie für einen S3-Bucket?](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-lifecycle.html) im *Benutzerhandbuch zu Amazon Simple Storage Service*.
1. **Compliance Type (Compliance-Typ)**: (Optional) Geben Sie den Compliance-Typ für die Meldung von Compliance-Informationen an. Der Standard-Compliance-Typ lautet **Custom:DSC**. Wenn Sie mehrere Zuordnungen erstellen, die MOF-Dateien ausführen, müssen Sie für jede Zuordnung einen anderen Compliance-Typ angeben. Wenn Sie dies nicht tun, überschreiben die zusätzlichen Zuordnungen mit **Custom:DSC** jeweils die bereits zusammengestellten Compliance-Daten.
1. **Pre Reboot Script (Skript vor dem Neustart)**: (Optional) Geben Sie ein Skript an, das ausgeführt werden soll, wenn die Konfiguration einen Neustart anfordert. Das Skript wird vor dem Neustart ausgeführt. Das Skript muss aus einer einzelnen Zeile bestehen. Trennen Sie zusätzliche Zeilen mithilfe von Semikolons.
1. Wählen Sie im Abschnitt **Targets (Ziele)** entweder **Specifying tags (Angaben von Tags)** oder **Manually Selecting Instance (Manuelles Auswählen einer Instance)** aus. Wenn Sie die Zielressourcen mithilfe von Tags ausgewählt haben, geben Sie einen Tag-Schlüssel und den Tag-Wert in die entsprechenden Felder ein. Weitere Informationen zur Verwendung von Zielen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
1. Wählen Sie im Abschnitt **Zeitplan angeben** entweder **Nach Zeitplan** oder **Kein Zeitplan** aus. Wenn Sie **On Schedule (Nach Zeitplan)** auswählen, verwenden Sie die verfügbaren Schaltflächen zum Erstellen eines cron- oder rate-Zeitplans für die Zuordnung.
1. Führen Sie im Abschnitt **Advanced options (Erweiterte Optionen)** Folgendes durch:
+ Wählen Sie unter **Compliance severity (Compliance -Schweregrad)**, einen Schweregrad für die Zuordnung aus. In den Compliance-Berichten finden Sie Informationen dazu, ob die Zuordnung konform ist, zusammen mit dem Schweregrad, den Sie hier angeben. Weitere Informationen finden Sie unter [Informationen zu State Manager-Zuordnungs-Compliance](compliance-about.md#compliance-about-association).
1. Konfigurieren Sie im Abschnitt **Rate control** (Ratensteuerung) Optionen für die Ausführung von State Manager-Zuordnungen in der Flotte der verwalteten Knoten. Weitere Informationen zu diesen Optionen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
Wählen Sie im Abschnitt **Gleichzeitigkeit** eine Option aus:
+ Wählen Sie **Ziele** aus, um eine absolute Anzahl von Zielen einzugeben, die die Zuordnung gleichzeitig ausführen können.
+ Wählen Sie **Prozentsatz** aus, um einen Prozentsatz der Ziele anzugeben, die die Zuordnung gleichzeitig ausführen können.
Wählen Sie im Abschnitt **Fehlerschwellenwert** eine Option aus:
+ Wählen Sie **Errors (Fehler)** aus und geben Sie die absolute Anzahl erlaubter Fehler an, bis State Manager die Ausführung von Zuordnungen für weitere Ziele beendet.
+ Wählen Sie **Percentage (Prozentsatz)** aus und geben Sie den Prozentsatz erlaubter Fehler an, bis State Manager die Ausführung von Zuordnungen für weitere Ziele beendet.
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben der Ausgabe in S3 aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind die Berechtigungen des dem verwalteten Knoten zugewiesenen Instance-Profils und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
1. Wählen Sie **Zuordnung erstellen**.
State Manager erstellt die Assoziation und führt sie sofort auf den angegebenen Knoten aus. Nach der ersten Ausführung wird die Zuordnung gemäß dem festgelegten Zeitplan und entsprechend den folgenden Regeln in Intervallen ausgeführt:
+ State Manager führt Assoziationen für Knoten aus, die online sind, wenn das Intervall gestartet wird und überspringt Offline-Knoten.
+ State Manager versucht, die Assoziation während eines Intervalls auf allen konfigurierten Knoten auszuführen.
+ Wenn eine Assoziation in einem Intervall nicht ausgeführt wird (weil beispielsweise die Anzahl der Knoten, die die Assoziation gleichzeitig ausführen können, durch einen Gleichzeitigkeitswert begrenzt wird), versucht State Manager, die Assoziation im nächsten Intervall auszuführen.
+ State Manager zeichnet einen Verlauf für alle übersprungenen Datensätze an. Sie können den Verlauf auf der Registerkarte **Execution History (Ausführungsverlauf)** anzeigen.
**Anmerkung**
Das `AWS-ApplyDSCMofs` ist ein Systems Manager Befehlsdokument. Dies bedeutet, dass dieses Dokument auch mit Run Command ausgeführt werden kann, einem Tool von AWS Systems Manager. Weitere Informationen finden Sie unter [AWS Systems Manager Run Command](run-command.md).
## Problembehandlung bei der Erstellung von Zuordnungen, die MOF-Dateien ausführen
Dieser Abschnitt enthält Informationen zur Unterstützung bei der Behebung von Problemen, die möglicherweise beim Erstellen von Zuordnungen zur Ausführung von MOF-Dateien auftreten.
**Aktivieren der erweiterten Protokollierung**
Aktivieren Sie als ersten Schritt zur Fehlerbehebung die erweiterte Protokollierung. Führen Sie dazu die folgenden Schritte aus:
1. Stellen Sie sicher, dass die Zuordnung so konfiguriert ist, dass sie Befehlsausgaben entweder in Amazon S3 oder Amazon CloudWatch Logs (CloudWatch) schreibt.
1. Setzen Sie den Parameter **Enable Verbose Logging** auf „True“ fest.
1. Setzen Sie den Parameter **Enable Debug Logging** auf „True“ fest.
Wenn die Verbose- und die Debug-Protokollierung aktiviert ist, enthält die **Stdout**-Ausgabedatei Details über die Skriptausführung. Diese Ausgabedatei kann Sie bei der Suche, an welcher Stelle das Skript fehlgeschlagen ist, unterstützen. Die **Stderr**-Ausgabedatei enthält Fehler, die während der Skriptausführung aufgetreten sind.
**Häufige Probleme beim Erstellen von Zuordnungen, die MOF-Dateien ausführen**
Dieser Abschnitt enthält Informationen über häufige Probleme, die beim Erstellen von Zuordnungen für die Ausführung von MOF-Dateien auftreten können, sowie Schritte, um diese Probleme zu beheben.
**Meine MOF-Datei wurde nicht angewendet.**
Wenn State Manager die Assoziation nicht auf Ihre Knoten anwenden konnte, überprüfen Sie zunächst die **Stderr**-Ausgabedatei. Diese Datei kann Ihnen helfen, die Ursache des Problems zu verstehen. Überprüfen Sie auch Folgendes:
+ Der Knoten hat die erforderlichen Zugriffsberechtigungen für alle mit der MOF-Datei verbundenen Amazon S3-Buckets. Das heißt:
+ **s3: GetObject Berechtigungen**: Dies ist für MOF-Dateien in privaten Amazon S3 S3-Buckets und benutzerdefinierte Module in Amazon S3 S3-Buckets erforderlich.
+ **s3: PutObject Berechtigung**: Dies ist erforderlich, um Compliance-Berichte und den Compliance-Status in Amazon S3 S3-Buckets zu schreiben.
+ Wenn Sie Tags verwenden, stellen Sie sicher, dass der Knoten die erforderliche IAM-Richtlinie hat. Die Verwendung von Tags erfordert, dass die Instance-IAM-Rolle über eine Richtlinie verfügt, die die Aktionen `ec2:DescribeInstances` und `ssm:ListTagsForResource` ermöglicht.
+ Stellen Sie sicher, dass dem Knoten die erwarteten Tags oder SSM-Parameter zugewiesen wurden.
+ Stellen Sie sicher, dass alle Tags und SSM-Parameter richtig geschrieben sind.
+ Versuchen Sie, die MOF-Datei lokal auf dem Knoten auszuführen, um sicherzustellen, dass kein Problem bei der MOF-Datei selbst vorliegt.
**Meine MOF-Datei schien fehlzuschlagen, aber die Systems Manager-Ausführung war erfolgreich.**
Wenn das Dokument `AWS-ApplyDSCMofs` erfolgreich ausgeführt wurde, wird der Systems Manager-Ausführungsstatus als **Success (Erfolg)** angezeigt. Dieser Status sagt nichts über den Compliance-Status Ihres Knotens, gemessen an den Konfigurationsanforderungen in der MOF-Datei, aus. Um den Compliance-Status Ihrer Knoten anzuzeigen, zeigen Sie die Compliance-Berichte an. Sie können einen JSON-Bericht im Amazon S3-Bericht-Bucket anzeigen. Dies gilt nur für Run Command- und für State Manager-Ausführungen. Darüber hinaus können Sie Compliance-Details für State Manager auf der Systems Manager-Compliance-Seite anzeigen.
**In der Stderr-Ausgabedatei finden sich Hinweise, dass bei dem Versuch, den Service zu erreichen, ein Fehler bei der Namensauflösung aufgetreten ist.**
Dieser Fehler weist darauf hin, dass das Skript einen Remoteservice nicht erreichen kann. In den meisten Fällen dürfte das Skript Probleme haben, Amazon S3 zu erreichen. Dieses Problem tritt am häufigsten auf, wenn das Skript versucht, Compliance-Berichte oder den Compliance-Status in den Amazon S3-Bucket zu schreiben, der in den Dokumentparametern angegeben ist. In der Regel tritt dieser Fehler auf, wenn eine Datenverarbeitungsumgebung eine Firewall oder einen transparenten Proxy mit einer Zulassungsliste verwendet. So beheben Sie dieses Problem
+ Verwenden Sie die regionsspezifische Bucket-Syntax für alle Amazon S3-Bucket-Parameter. Beispiel: Die **Mofs to Apply**-Parameter sollten in dem folgenden Format angegeben werden:
s3:: *bucket-region**amzn-s3-demo-bucket*: *mof-file-name* .mof.
Ein Beispiel:` s3:us-west-2:amzn-s3-demo-bucket:my-mof.mof`
Die Bucketnamen für Berichte, Statusinformationen und Modulquellen sollten in dem folgenden Format angegeben werden.
*bucket-region*:. *amzn-s3-demo-bucket* Hier ist ein Beispiel: `us-west-1:amzn-s3-demo-bucket;`
+ Wenn sich das Problem nicht durch Verwendung einer regionsspezifischen Syntax beheben lässt, stellen Sie sicher, dass die Ziel-Knoten in der gewünschten Region auf Simple Storage Service (Amazon S3) zugreifen können. So können Sie dies überprüfen
1. Suchen Sie den Endpunktnamen für Amazon S3 in der entsprechenden Amazon S3-Region. Weitere Informationen finden Sie unter [Amazon-S3-Service-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_region) im *Allgemeine Amazon Web Services-Referenz*.
1. Melden Sie sich am Ziel-Knoten an und führen Sie den folgenden Ping-Befehl aus.
```
ping s3.s3-region.amazonaws.com
```
Wenn der Ping fehlschlägt, bedeutet dies, dass entweder Amazon S3 ausgefallen ist oder ein firewall/transparent Proxy den Zugriff auf die Amazon S3 S3-Region blockiert oder der Knoten nicht auf das Internet zugreifen kann.
## Anzeigen von Details zur DSC-Ressourcen-Compliance
Systems Manager erfasst Compliance-Informationen zu DSC-Ressourcenfehlern im Amazon S3 **Status-Bucket**, den Sie bei der Ausführung des `AWS-ApplyDSCMofs`-Dokuments angegeben haben. Die Suche nach Informationen zu DSC-Ressourcenfehlern in einem Amazon S3-Bucket kann zeitaufwendig sein. Stattdessen können Sie diese Informationen auf der Systems Manager-Seite **Compliance** anzeigen.
Der Bereich **Compliance-Ressourcen-Zusammenfassung** zeigt die Anzahl der Ressourcen an, die fehlgeschlagen sind. Im folgenden Beispiel **ComplianceType**ist das **custom:DSC** und eine Ressource ist nicht konform.
**Anmerkung**
custom:DSC ist der Standardwert im Dokument. **ComplianceType**`AWS-ApplyDSCMofs` Dieser Wert ist anpassbar.
![\[Anzeigen der Anzahl im Bereich Compliance-Ressourcen-Zusammenfassung der Seite Compliance.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-3.png)
Im Abschnitt „**Detailübersicht für Ressourcen**“ werden Informationen über die AWS Ressource mit der nicht konformen DSC-Ressource angezeigt. Dieser Bereich enthält auch den MOF-Namen, Skript-Ausführungsschritte und (falls zutreffend) den Link **View output (Ausgabe anzeigen)** zur Ansicht detaillierter Statusinformationen.
![\[Anzeigen von Compliance-Details für einen MOF-Ausführungs-Ressourcenfehler\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-1.png)
Der Link **View output** zeigt die letzten 4.000 Zeichen des detaillierten Status an. Systems Manager beginnt mit der Ausnahme als erstem Element und scannt dann durch die ausführlichen Nachrichten und stellt so viele wie möglich voran, bis das Kontingent von 4.000 Zeichen erreicht wird. Dieser Vorgang zeigt die Protokollmeldungen an, die vor dem Auslösen der Ausnahme ausgegeben wurden. Dabei handelt es sich um die relevantesten Nachrichten für die Fehlerbehebung.
![\[Anzeigen der ausführlichen Ausgabe bei Compliance-Problemen mit MOF-Ressourcen\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/state-manager-mof-detailed-status-2.png)
Weitere Informationen zum Anzeigen von Compliance-Informationen finden Sie unter [AWS Systems Manager-Compliance](systems-manager-compliance.md).
**Situationen, die die Compliance-Berichterstellung beeinflussen**
Wenn die State Manager-Zuordnung fehlschlägt, werden keine Compliance-Daten gemeldet. Genauer gesagt, meldet Systems Manager doesn’t keine Compliance-Elemente, wenn eine MOF-Datei nicht verarbeitet werden kann, da die Zuordnungen fehlschlagen. Beispiel: Wenn Systems Manager versucht, eine MOF-Datei von einem Amazon S3-Bucket herunterzuladen, und der Knoten keine Berechtigung zum Zugriff besitzt, schlägt die Zuordnung fehl und es werden keine Compliance-Daten gemeldet.
Wenn eine Ressource in einer zweiten MOF-Datei fehlschlägt, dann *meldet* Systems Manager Bericht-Compliance-Daten. Beispiel: Wenn ein MOF versucht, eine Datei auf einem nicht vorhandenen Laufwerk zu erstellen, dann meldet Systems Manager Compliance, da das `AWS-ApplyDSCMofs`-Dokument vollständig verarbeitet werden kann. Dies bedeutet, dass die Zuordnung erfolgreich ausgeführt wird.
# Erstellen von Zuordnungen, die Ansible-Playbooks ausführen
Sie können State Manager-Zuordnungen erstellen, die Ansible-Playbooks ausführen, indem Sie das `AWS-ApplyAnsiblePlaybooks`-SSM-Dokument verwenden. State Manager ist ein Tool von AWS Systems Manager. Dieses Dokument bietet die folgenden Vorteile für die Ausführung von Playbooks:
+ Unterstützung für die Ausführung komplexer Playbooks
+ Support für das Herunterladen von Playbooks von GitHub und Amazon Simple Storage Service (Amazon S3)
+ Unterstützung der komprimierten Playbook-Struktur
+ Erweiterte Protokollierung
+ Möglichkeit, anzugeben, welches Playbook ausgeführt werden soll, wenn Playbooks gebündelt werden
**Anmerkung**
Systems Manager enthält zwei SSM-Dokumente, mit denen Sie State Manager-Zuordnungen erstellen können, die Ansible-Playbooks ausführen: `AWS-RunAnsiblePlaybook` und `AWS-ApplyAnsiblePlaybooks`. Das `AWS-RunAnsiblePlaybook`-Dokument ist veraltet. Es bleibt für Legacy-Zwecke in Systems Manager verfügbar. Wir empfehlen, dass Sie das `AWS-ApplyAnsiblePlaybooks`-Dokument aufgrund der hier beschriebenen Verbesserungen verwenden.
Zuordnungen, die Ansible-Playbooks ausführen, werden in macOS nicht unterstützt.
**Unterstützung für die Ausführung komplexer Playbooks**
Das `AWS-ApplyAnsiblePlaybooks`-Dokument unterstützt gebündelte, komplexe Playbooks, da es die gesamte Dateistruktur vor der Ausführung des angegebenen Haupt-Playbooks in ein lokales Verzeichnis kopiert. Sie können Quell-Playbooks in Zip-Dateien oder in einer Verzeichnisstruktur bereitstellen. Die Zip-Datei oder das Verzeichnis kann in GitHub oder Amazon S3 gespeichert werden.
**Unterstützung für das Herunterladen von Playbooks von GitHub**
Das `AWS-ApplyAnsiblePlaybooks`-Dokument verwendet das `aws:downloadContent`-Plugin zum Herunterladen von Playbook-Dateien. Dateien können in GitHub in einer einzigen Datei oder als kombinierte Gruppe von Playbook-Dateien gespeichert werden. Geben Sie Informationen über Ihr GitHub-Repository im JSON-Format an, um Inhalte von GitHub herunterzuladen. Ein Beispiel.
```
{
"owner":"TestUser",
"repository":"GitHubTest",
"path":"scripts/python/test-script",
"getOptions":"branch:master",
"tokenInfo":"{{ssm-secure:secure-string-token}}"
}
```
**Unterstützung für das Herunterladen von Playbooks von Amazon S3**
Sie können Ansible-Playbooks auch in Amazon S3 als einzelne ZIP-Datei oder als Verzeichnisstruktur speichern und herunterladen. Geben Sie den Pfad zur Datei an, um Inhalte von Amazon S3 herunterzuladen. Nachfolgend finden Sie zwei Beispiele.
**Beispiel 1: Herunterladen einer bestimmten Playbook-Datei**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/playbook.yml"
}
```
**Beispiel 2: Herunterladen des Inhalts eines Verzeichnisses**
```
{
"path":"https://s3.amazonaws.com/amzn-s3-demo-bucket/ansible/webservers/"
}
```
**Wichtig**
Wenn Sie Amazon S3 angeben, muss das AWS Identity and Access Management (IAM) -Instance-Profil auf Ihren verwalteten Knoten Berechtigungen für den S3-Bucket enthalten. Weitere Informationen finden Sie unter [Erforderliche Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md).
**Unterstützung der komprimierten Playbook-Struktur**
Mit dem `AWS-ApplyAnsiblePlaybooks`-Dokument können Sie komprimierte ZIP-Dateien im heruntergeladenen Paket ausführen. Das Dokument prüft, ob die heruntergeladenen Dateien eine komprimierte Datei im ZIP-Format enthalten. Wenn eine ZIP-Datei gefunden wird, dekomprimiert das Dokument die Datei automatisch und führt dann die angegebene Ansible-Automatisierung aus.
**Erweiterte Protokollierung**
Das `AWS-ApplyAnsiblePlaybooks`-Dokument enthält einen optionalen Parameter für die Angabe verschiedener Protokollierungsebenen. Geben Sie -v für niedrige Ausführlichkeit, -vv oder -vvv für mittlere Ausführlichkeit und -vvvv für die Protokollierung auf Debug-Ebene an. Diese Optionen werden direkt den Ansible-Ausführlichkeitsoptionen zugeordnet.
**Möglichkeit, anzugeben, welches Playbook ausgeführt werden soll, wenn Playbooks gebündelt werden**
Das `AWS-ApplyAnsiblePlaybooks`-Dokument enthält einen erforderlichen Parameter, um anzugeben, welches Playbook ausgeführt werden soll, wenn mehrere Playbooks gebündelt werden. Diese Option bietet Flexibilität für die Ausführung von Playbooks, um verschiedene Anwendungsfälle zu unterstützen.
## Grundlegendes zu installierten Abhängigkeiten
Wenn Sie **True** für den **InstallDependencies**Parameter angeben, überprüft Systems Manager, ob auf Ihren Knoten die folgenden Abhängigkeiten installiert sind:
+ **Ubuntu Server/Debian Server**: Apt-get (Paketverwaltung), Python 3, Ansible, Unzip
+ Von **Amazon Linux** unterstützte Versionen: Ansible
+ **RHEL**: Python 3, Ansible, Entpacken
Wenn eine oder mehrere dieser Abhängigkeiten nicht gefunden werden, installiert Systems Manager sie automatisch.
## Erstellen einer Zuordnung zur Ausführung von Ansible-Playbooks (Konsole)
Im folgenden Verfahren wird beschrieben, wie Sie mit der Systems-Manager-Konsole eine State Manager-Zuordnung erstellen, die Ansible-Playbooks mithilfe des `AWS-ApplyAnsiblePlaybooks`-Dokuments ausführt.
**So erstellen Sie eine Zuordnung, die Ansible-Playbooks ausführt (Konsole)**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **State Manager** aus.
1. Wählen Sie **State Manager** und dann **Zuordnung wählen** aus.
1. Geben Sie unter **Name** einen Namen an, der Ihnen hilft, sich an den Zweck der Zuordnung zu erinnern.
1. Wählen Sie in der Liste **Dokument** die Option **`AWS-ApplyAnsiblePlaybooks`** aus.
1. Wählen Sie im Abschnitt **Parameter** für **Source Type** entweder **GitHub**oder **S3** aus.
**GitHub**
Wenn Sie **GitHub** auswählen, geben Sie Repository-Informationen im folgenden Format ein.
```
{
"owner":"user_name",
"repository":"name",
"path":"path_to_directory_or_playbook_to_download",
"getOptions":"branch:branch_name",
"tokenInfo":"{{(Optional)_token_information}}"
}
```
**S3**
Wenn Sie **S3** auswählen, geben Sie Pfadinformationen im folgenden Format ein.
```
{
"path":"https://s3.amazonaws.com/path_to_directory_or_playbook_to_download"
}
```
1. Wählen Sie unter **Install Dependencies (Abhängigkeiten installieren)** eine Option aus.
1. (Optional) Geben Sie unter **Playbook File (Playbook-Datei)** einen Dateinamen ein. Wenn eine Zip-Datei das Playbook enthält, geben Sie einen relativen Pfad zur Zip-Datei an.
1. (Optional) Geben Sie unter **Zusätzliche Variablen** Variablen ein, die State Manager zur Laufzeit an Ansible senden soll.
1. (Optional) Wählen Sie unter **Check (Prüfen)** eine Option aus.
1. (Optional) Wählen Sie für **Verbose** eine Option aus.
1. Wählen Sie für **Ziele** eine Option aus. Weitere Informationen zur Verwendung von Zielen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
1. Wählen Sie im Abschnitt **Specify schedule (Zeitplan angeben)** entweder **On schedule (Nach Zeitplan)** oder **No schedule (Kein Zeitplan)** aus. Wenn Sie **On schedule (Nach Zeitplan)** auswählen, verwenden Sie die verfügbaren Schaltflächen zum Erstellen eines cron- oder rate-Zeitplans für die Zuordnung.
1. Wählen Sie im Abschnitt **Advanced options (Erweiterte Optionen)** für **Compliance severity (Compliance-Schweregrad)** einen Schweregrad für die Zuordnung aus. In den Compliance-Berichten finden Sie Informationen dazu, ob die Zuordnung konform ist, zusammen mit dem Schweregrad, den Sie hier angeben. Weitere Informationen finden Sie unter [Informationen zu State Manager-Zuordnungs-Compliance](compliance-about.md#compliance-about-association).
1. Konfigurieren Sie im Abschnitt **Rate control** (Ratensteuerung) Optionen für die Ausführung von State Manager-Zuordnungen in der Flotte von verwalteten Knoten. Weitere Informationen über Ratensteuerungen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
Wählen Sie im Abschnitt **Gleichzeitigkeit** eine Option aus:
+ Wählen Sie **Ziele** aus, um eine absolute Anzahl von Zielen einzugeben, die die Zuordnung gleichzeitig ausführen können.
+ Wählen Sie **Prozentsatz** aus, um einen Prozentsatz der Ziele anzugeben, die die Zuordnung gleichzeitig ausführen können.
Wählen Sie im Abschnitt **Fehlerschwellenwert** eine Option aus:
+ Wählen Sie **Fehler** aus und geben Sie die absolute Anzahl erlaubter Fehler an, bis State Manager die Ausführung von Zuordnungen für weitere Ziele beendet.
+ Wählen Sie **Prozentsatz** aus und geben Sie den Prozentsatz erlaubter Fehler an, bis State Manager die Ausführung von Zuordnungen für weitere Ziele beendet.
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben der Ausgabe in S3 aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind die Berechtigungen des dem verwalteten Knoten zugewiesenen Instance-Profils und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
1. Wählen Sie **Zuordnung erstellen**.
**Anmerkung**
Wenn Sie auf einer oder mehreren Knoten eine Assoziation anhand von Tags erstellen und von einem dieser Knoten die Tags entfernen, wird die Assoziation auf diesem Knoten nicht mehr ausgeführt. Die Assoziazion zwischen dem Knoten und dem State Manager-Dokument ist aufgehoben.
## Erstellen einer Zuordnung zur Ausführung von Ansible-Playbooks (CLI)
Im folgenden Verfahren wird beschrieben, wie Sie mit AWS Command Line Interface (AWS CLI) eine State Manager Assoziation erstellen, die Ansible Playbooks mithilfe des `AWS-ApplyAnsiblePlaybooks` Dokuments ausführt.
**So erstellen Sie eine Zuordnung, die Ansible-Playbooks ausführt (CLI)**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie einen der folgenden Befehle aus, um eine Zuordnung zu erstellen, die Ansible-Playbooks ausführt, indem Knoten mithilfe von Tags angesprochen werden. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen. Befehl (A) gibt GitHub als Quelltyp an. Befehl (B) gibt Amazon S3 als Quelltyp an.
**(Eine) GitHub Quelle**
------
#### [ 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"
```
------
Ein Beispiel.
```
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) S3-Quelle**
------
#### [ 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"
```
------
Ein Beispiel.
```
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 *)"
```
**Anmerkung**
State Manager-Zuordnungen unterstützen nicht alle Cron- und Rate-Ausdrücke. Weitere Informationen zum Erstellen von Cron- und Rate-Ausdrücken für Zuordnungen finden Sie unter [Referenz: Cron- und Rate-Ausdrücke für System Manager](reference-cron-and-rate-expressions.md).
Das System versucht, die Assoziation auf den Knoten zu erstellen und den Status sofort anzuwenden.
1. Führen Sie den folgenden Befehl aus, um einen aktualisierten Status der soeben erstellten Zuordnung anzuzeigen.
```
aws ssm describe-association --association-id "ID"
```
# Erstellen von Zuordnungen, die Chef-Rezepte ausführen
Sie können State Manager-Zuordnungen erstellen, die Chef-Rezepte ausführen, indem Sie das `AWS-ApplyChefRecipes`-SSM-Dokument verwenden. State Manager ist ein Tool von AWS Systems Manager. Sie können mit dem `AWS-ApplyChefRecipes` SSM-Dokument eine Ausrichtung auf Linux-basierte verwaltete Systems Manager-Knoten verwenden. Dieses Dokument bietet die folgenden Vorteile für die Ausführung von Chef-Rezepten:
+ Unterstützt mehrere Versionen von Chef (Chef 11 bis Chef 18).
+ Installiert die Chef-Clientsoftware automatisch auf Ziel-Knoten.
+ Führt optional [Systems Manager-Compliance-Prüfungen](systems-manager-compliance.md) für Ziel-Knoten aus und speichert die Ergebnisse der Compliance-Prüfungen in einem Amazon Simple Storage Service (Amazon S3)-Bucket.
+ Führt mehrere Cookbooks und Rezepte in einem einzigen Durchlauf des Dokuments aus.
+ Führt optional Rezepte im `why-run`-Modus aus, um anzuzeigen, welche Rezepte sich auf Ziel-Knoten ändern, ohne Änderungen vorzunehmen.
+ Wendet optional benutzerdefinierte JSON-Attribute auf `chef-client`-Durchläufe an.
+ Wendet optional benutzerdefinierte JSON-Attribute aus einer Quelldatei an, die an einem von Ihnen angegebenen Ort gespeichert ist.
Sie können [Git](#state-manager-chef-git), [GitHub](#state-manager-chef-github), [HTTP](#state-manager-chef-http) oder [Amazon-S3-Buckets](#state-manager-chef-s3) als Download-Quellen für Chef Cookbooks und Rezepte verwenden, die Sie in einem `AWS-ApplyChefRecipes`-Dokument angeben.
**Anmerkung**
Zuordnungen, die Chef-Rezepte ausführen, werden in macOS nicht unterstützt.
## Erste Schritte
Bevor Sie ein `AWS-ApplyChefRecipes`-Dokument erstellen, bereiten Sie Ihre Chef-Cookbooks und das Cookbook-Repository vor. Wenn Sie noch kein Chef Kochbuch haben, das Sie verwenden möchten, können Sie zunächst ein `HelloWorld` Testkochbuch verwenden, das für Sie vorbereitet AWS wurde. Das `AWS-ApplyChefRecipes`-Dokument verweist bereits standardmäßig auf dieses Cookbook. Ihre Cookbooks sollten ähnlich wie die folgende Verzeichnisstruktur eingerichtet werden. Im folgenden Beispiel sind `jenkins` und `nginx` Beispiele für Chef-Cookbooks, die im [https://supermarket.chef.io/](https://supermarket.chef.io/) auf der Chef-Website verfügbar sind.
Kochbücher auf der [https://supermarket.chef.io/](https://supermarket.chef.io/)Website AWS können zwar nicht offiziell unterstützt werden, aber viele von ihnen funktionieren mit dem Dokument. `AWS-ApplyChefRecipes` Im Folgenden finden Sie Beispiele für Kriterien, die Sie bestimmen müssen, wenn Sie ein Community-Cookbook testen:
+ Das Cookbook sollte die Linux-basierten Betriebssysteme der Systems Manager-verwalteten Knoten unterstützen, auf die Sie zielen.
+ Das Cookbook sollte für die Chef-Client-Version (Chef 11 bis Chef 18) gültig sein, die Sie verwenden.
+ Das Cookbook ist kompatibel mit Chef Infra Client und erfordert keinen Chef-Server.
Stellen Sie sicher, dass Sie die `Chef.io`-Website erreichen können, damit alle Cookbooks, die Sie in der Ausführungsliste angeben, installiert werden können, wenn das Systems-Manager-Dokument (SSM-Dokument) ausgeführt wird. Die Verwendung eines eingebetteten `cookbooks`-Ordners wird zwar unterstützt, ist aber nicht erforderlich. Sie können Cookbooks direkt unter der Root-Ebene speichern.
```
└── cookbooks (optional level)
├── jenkins
│ ├── metadata.rb
│ └── recipes
└── nginx
├── metadata.rb
└── recipes
```
**Wichtig**
Bevor Sie eine State Manager-Zuordnung erstellen, in der Chef-Rezepte ausgeführt werden, beachten Sie, dass die Dokumentausführung die Chef-Clientsoftware auf den Systems-Manager-verwalteten Knoten installiert, es sei denn, Sie setzen den Wert der **Chef-Client-Version** auf `None`. Diese Operation verwendet ein Installationsskript von Chef, um Chef-Komponenten in Ihrem Namen zu installieren. Bevor Sie ein `AWS-ApplyChefRecipes`-Dokument ausführen, stellen Sie sicher, dass Ihr Unternehmen alle geltenden gesetzlichen Anforderungen einhalten kann, einschließlich der Lizenzbedingungen, die für die Verwendung von Chef-Software gelten. Weitere Informationen finden Sie auf der [Chef-Website](https://www.chef.io/).
Systems Manager kann Compliance-Berichte an einen S3-Bucket oder die Systems Manager-Konsole übermitteln oder Compliance-Ergebnisse als Antwort auf Systems Manager-API-Befehle zur Verfügung stellen. Zum Ausführen von Systems Manager-Compliance-Berichten muss das Instance-Profil, das an Systems Manager-verwaltete Knoten angefügt ist, über Berechtigungen zum Schreiben in den S3-Bucket verfügen. Das Instance-Profil muss über die Berechtigung zur Nutzung der Systems Manager `PutComplianceItem`-API verfügen. Weitere Informationen zur Systems Manager-Compliance finden Sie unter [AWS Systems Manager-Compliance](systems-manager-compliance.md).
### Protokollieren der Dokumentausführung
Wenn Sie ein Systems Manager Manager-Dokument (SSM-Dokument) mithilfe einer State Manager Zuordnung ausführen, können Sie die Zuordnung so konfigurieren, dass die Ausgabe des Dokumentenlaufs ausgewählt wird, und Sie können die Ausgabe an Amazon S3 oder Amazon CloudWatch Logs (CloudWatch Logs) senden. Um die Problembehebung zu vereinfachen, wenn die Ausführung einer Zuordnung abgeschlossen ist, stellen Sie sicher, dass die Zuordnung so konfiguriert ist, dass die Befehlsausgabe entweder in einen Amazon S3 S3-Bucket oder in CloudWatch Logs geschrieben wird. Weitere Informationen finden Sie unter [Arbeiten mit Zuordnungen in Systems Manager](state-manager-associations.md).
## Anwenden von JSON-Attributen auf Ziele bei der Ausführung eines Rezepts
Sie können JSON-Attribute angeben, die Ihr Chef-Client während einer Zuordnung auf die Zielknoten anwenden soll. Beim Einrichten der Zuordnung können Sie unformatiertes JSON oder den Pfad zu einer in Amazon S3 gespeicherten JSON-Datei angeben.
Verwenden Sie JSON-Attribute, wenn Sie beispielsweise die Art und Weise, wie das Rezept ausgeführt wird, anpassen möchten, ohne das Rezept selbst ändern zu müssen:
+ **Überschreiben einer kleinen Anzahl von Attributen**
Verwenden Sie benutzerdefiniertes JSON, um zu vermeiden, dass Sie mehrere Versionen eines Rezepts verwalten müssen, um kleine Unterschiede zu berücksichtigen.
+ **Bereitstellung variabler Werte**
Verwenden Sie benutzerdefiniertes JSON, um Werte anzugeben, die sich von ändern können run-to-run. Wenn Ihre Chef-Cookbooks beispielsweise eine Drittanbieter-Anwendung konfigurieren, die Zahlungen akzeptiert, können Sie möglicherweise benutzerdefiniertes JSON verwenden, um die URL des Zahlungsendpunkts anzugeben.
**Angeben von Attributen in unformatiertem JSON**
Im Folgenden finden Sie ein Beispiel für das Format, das Sie verwenden können, um benutzerdefinierte JSON-Attribute für Ihr Chef-Rezept anzugeben.
```
{"filepath":"/tmp/example.txt", "content":"Hello, World!"}
```
**Angabe eines Pfads zu einer JSON-Datei**
Im Folgenden finden Sie ein Beispiel für das Format, das Sie verwenden können, um den Pfad zu benutzerdefinierten JSON-Attributen für Ihr Chef-Rezept anzugeben.
```
{"sourceType":"s3", "sourceInfo":"someS3URL1"}, {"sourceType":"s3", "sourceInfo":"someS3URL2"}
```
## Git als Quelle für Cookbooks verwenden
Das `AWS-ApplyChefRecipes`-Dokument verwendet das [aws:downloadContent](documents-command-ssm-plugin-reference.md#aws-downloadContent)-Plugin, um Chef-Cookbooks herunterzuladen. Um Inhalte aus Git herunterzuladen, geben Sie Informationen über Ihr Git-Repository im JSON-Format an, wie im folgenden Beispiel. Ersetzen Sie jeden *example-resource-placeholder* durch Ihre Informationen.
```
{
"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}}"
}
```
## Verwenden von GitHub als Quelle für Cookbooks
Das `AWS-ApplyChefRecipes`-Dokument verwendet das [aws:downloadContent](documents-command-ssm-plugin-reference.md#aws-downloadContent)-Plugin, um Cookbooks herunterzuladen. Um Inhalte aus GitHub herunterzuladen, geben Sie Informationen über Ihr GitHub-Repository im JSON-Format an, wie im folgenden Beispiel. Ersetzen Sie jeden *example-resource-placeholder* durch Ihre Informationen.
```
{
"owner":"TestUser",
"repository":"GitHubCookbookRepository",
"path":"cookbooks/HelloWorld",
"getOptions":"branch:refs/head/main",
"tokenInfo":"{{ssm-secure:token-secure-string-parameter}}"
}
```
## HTTP als Quelle für Cookbooks verwenden
Sie können Chef Cookbooks an einem benutzerdefinierten HTTP-Speicherort entweder als einzelne `.zip` oder `tar.gz`-Datei oder als Verzeichnisstruktur speichern. Um Inhalte über HTTP herunterzuladen, geben Sie den Pfad zu der Datei oder dem Verzeichnis im JSON-Format wie im folgenden Beispiel an. Ersetzen Sie jeden *example-resource-placeholder* durch Ihre Informationen.
```
{
"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}}"
}
```
## Verwenden von Amazon S3 als Quelle für Cookbooks
Sie können Chef-Cookbooks auch in Amazon S3 als einzelne `.zip`- oder `tar.gz`-Datei oder als Verzeichnisstruktur speichern und herunterladen. Um Inhalte von Amazon S3 herunterzuladen, geben Sie den Pfad zu der Datei im JSON-Format wie in den folgenden Beispielen an. Ersetzen Sie jeden *example-resource-placeholder* durch Ihre Informationen.
**Beispiel 1: Herunterladen eines bestimmten Cookbooks**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks/HelloWorld.zip"
}
```
**Beispiel 2: Herunterladen des Inhalts eines Verzeichnisses**
```
{
"path":"https://s3.amazonaws.com/chef-cookbooks-test/HelloWorld"
}
```
**Wichtig**
Wenn Sie Amazon S3 angeben, muss das Instance-Profil AWS Identity and Access Management (IAM) auf Ihren verwalteten Knoten mit der `AmazonS3ReadOnlyAccess` Richtlinie konfiguriert werden. Weitere Informationen finden Sie unter [Erforderliche Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md).
## Erstellen einer Zuordnung, die Chef-Rezepte ausführt (Konsole)
Im folgenden Verfahren wird beschrieben, wie Sie mit der Systems-Manager-Konsole eine State Manager-Zuordnung erstellen, die Chef-Cookbooks mithilfe des `AWS-ApplyChefRecipes`-Dokuments ausführt.
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **State Manager** aus.
1. Wählen Sie **State Manager** und dann **Zuordnung wählen** aus.
1. Geben Sie unter **Name** einen Namen ein, der Ihnen hilft, sich an den Zweck der Zuordnung zu erinnern.
1. Wählen Sie in der Liste **Dokument** die Option **`AWS-ApplyChefRecipes`** aus.
1. Wählen Sie unter **Parameter** für **Quelltyp** entweder **Git**, **GitHub**, **HTTP**, oder **S3** aus.
1. Geben Sie unter **Quelleninfo** die Informationen zur Cookbook-Quelle in dem Format ein, das dem in Schritt 6 ausgewählten **Quellentyp** entspricht. Weitere Informationen finden Sie unter den folgenden Themen:
+ [Git als Quelle für Cookbooks verwenden](#state-manager-chef-git)
+ [Verwenden von GitHub als Quelle für Cookbooks](#state-manager-chef-github)
+ [HTTP als Quelle für Cookbooks verwenden](#state-manager-chef-http)
+ [Verwenden von Amazon S3 als Quelle für Cookbooks](#state-manager-chef-s3)
1. Listen Sie in der **Run list (Ausführungsliste)** die auszuführenden Rezepte im folgenden Format auf. Trennen Sie jedes Rezept durch ein Komma wie gezeigt. Geben Sie kein Leerzeichen nach dem Komma ein. Ersetzen Sie jeden *example-resource-placeholder* durch Ihre Informationen.
```
recipe[cookbook-name1::recipe-name],recipe[cookbook-name2::recipe-name]
```
1. (Optional) Geben Sie benutzerdefinierte JSON-Attribute an, die der Chef-Client an Ihre Zielknoten weitergeben soll.
1. Fügen Sie unter **Inhalt von JSON-Attributen** alle Attribute hinzu, die der Chef-Client an Ihre Zielknoten weitergeben soll.
1. Fügen Sie in **JSON-Attributquellen** die Pfade zu allen Attributen hinzu, die der Chef-Client an Ihre Zielknoten weitergeben soll.
Weitere Informationen finden Sie unter [Anwenden von JSON-Attributen auf Ziele bei der Ausführung eines Rezepts](#apply-custom-json-attributes).
1. Geben Sie für die **Chef-Client-Version** eine Chef-Version an. Gültige Werte sind `11` bis `18` oder `None`. Wenn Sie eine Zahl zwischen `11` und `18` (einschließlich) angeben, installiert Systems Manager die richtige Chef-Client-Version auf Ihren Zielknoten. Wenn Sie `None` angeben, installiert Systems Manager den Chef-Client nicht auf Ziel-Knoten, bevor Sie die Rezepte des Dokuments ausführen.
1. (Optional) Geben Sie für **Chef-Client-Argumente** zusätzliche Argumente an, die für die von Ihnen verwendete Version von Chef unterstützt werden. Um mehr über unterstützte Argumente zu erfahren, führen Sie `chef-client -h` auf einem Knoten aus, auf dem der Chef-Client ausgeführt wird.
1. (Optional) Aktivieren Sie **Why-run**, um Änderungen anzuzeigen, die bei der Ausführung der Rezepte an Ziel-Knoten vorgenommen wurden, ohne dass die Ziel-Knoten tatsächlich geändert werden.
1. Wählen Sie für **Compliance severity (Schweregrad der Compliance)** den Schweregrad der Systems Manager-Compliance-Ergebnisse aus, die gemeldet werden sollen. In den Compliance-Berichten finden Sie Informationen dazu, ob die Zuordnung konform ist, zusammen mit dem festgelegten Schweregrad. Compliance-Berichte werden in einem S3-Bucket gespeichert, den Sie als Wert des Parameters **Compliance report bucket (Compliance-Berichts-Bucket)** angeben (Schritt 14). Weitere Informationen zur Compliance finden Sie unter [Erfahren Sie mehr über Compliance](compliance-about.md) in dieser Anleitung.
Compliance-Scans messen die Abweichung zwischen der Konfiguration, die in Ihren Chef-Rezepten und Knoten-Ressourcen angegeben ist. Gültige Werte sind `Critical`, `High`, `Medium`, `Low`, `Informational`, `Unspecified` oder `None`. Um die Compliance-Berichterstattung zu überspringen, wählen Sie `None`.
1. Geben Sie unter **Compliance type (Compliance-Typ)** den Compliance-Typ an, für den die Ergebnisse gemeldet werden sollen. Gültige Werte sind `Association` für State Manager Assoziationen oder `Custom:`*custom-type*. Der Standardwert ist `Custom:Chef`.
1. Geben Sie unter **Compliance-Berichts-Bucket** den Namen eines S3-Buckets ein, in dem Informationen zu jeder Chef-Ausführung dieses Dokuments gespeichert werden sollen, einschließlich der Ressourcenkonfiguration und der Ergebnisse der Compliance.
1. Konfigurieren Sie in **Rate control** (Ratensteuerung) Optionen für die Ausführung von State Manager-Zuordnungen in der Flotte von verwalteten Knoten. Weitere Informationen über Ratensteuerungen finden Sie unter [Verstehen von Zielen und Ratensteuerungen in State Manager Zuordnungen](systems-manager-state-manager-targets-and-rate-controls.md).
Wählen Sie unter **Concurrency (Gleichzeitigkeit)** eine Option aus:
+ Wählen Sie **Ziele** aus, um eine absolute Anzahl von Zielen einzugeben, die die Zuordnung gleichzeitig ausführen können.
+ Wählen Sie **Prozentsatz** aus, um einen Prozentsatz der Ziele anzugeben, die die Zuordnung gleichzeitig ausführen können.
Wählen Sie unter **Error threshold (Fehlerschwelle)** eine Option aus:
+ Wählen Sie **Fehler** aus und geben Sie die absolute Anzahl erlaubter Fehler an, bis State Manager die Ausführung von Zuordnungen für weitere Ziele beendet.
+ Wählen Sie **Prozentsatz** aus und geben Sie den Prozentsatz erlaubter Fehler an, bis State Manager die Ausführung von Zuordnungen für weitere Ziele beendet.
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben der Ausgabe in S3 aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind die Berechtigungen des dem verwalteten Knoten zugewiesenen Instance-Profils und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
1. Wählen Sie **Zuordnung erstellen**.
## Erstellen einer Zuordnung, die Chef-Rezepte ausführt (CLI)
Das folgende Verfahren beschreibt, wie Sie mit AWS Command Line Interface (AWS CLI) eine State Manager Assoziation erstellen, die Chef-Kochbücher mithilfe des `AWS-ApplyChefRecipes` Dokuments ausführt.
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie einen der folgenden Befehle aus, um eine Zuordnung zu erstellen, die Chef Cookbooks auf Zielknoten ausführt, die die angegebenen Tags haben. Verwenden Sie den Befehl, der für Ihren Quellentyp des Cookbooks und Ihr Betriebssystem geeignet ist. Ersetzen Sie jeden *example-resource-placeholder* durch Ihre Informationen.
1. **Git-Quelle**
------
#### [ 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. **GitHub source**
------
#### [ 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"
```
------
Ein Beispiel.
------
#### [ 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. **HTTP-Quelle**
------
#### [ 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. **Amazon-S3-Quelle**
------
#### [ 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"
```
------
Ein Beispiel.
------
#### [ 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 *)"
```
------
Das System erstellt die Zuordnung und führt die Zuordnung auf den Zielknoten aus, es sei denn, Ihr angegebener cron- oder rate-Ausdruck verhindert dies.
**Anmerkung**
State Manager-Zuordnungen unterstützen nicht alle Cron- und Rate-Ausdrücke. Weitere Informationen zum Erstellen von Cron- und Rate-Ausdrücken für Zuordnungen finden Sie unter [Referenz: Cron- und Rate-Ausdrücke für System Manager](reference-cron-and-rate-expressions.md).
1. Führen Sie den folgenden Befehl aus, um den Status der Zuordnung, die Sie gerade erstellt haben, anzuzeigen.
```
aws ssm describe-association --association-id "ID"
```
## Anzeigen von Details zur Chef-Ressourcen-Compliance
Systems Manager erfasst Compliance-Informationen über von Chef verwaltete Ressourcen im **Compliance-Berichts-Bucket**-Wert von Amazon S3, den Sie bei der Ausführung des `AWS-ApplyChefRecipes`-Dokuments angegeben haben. Die Suche nach Informationen zu Chef-Ressourcenfehlern in einem S3-Bucket kann zeitaufwendig sein. Stattdessen können Sie diese Informationen auf der Systems Manager-Seite **Compliance** anzeigen.
Ein Systems-Manager-Compliance-Scan sammelt Informationen zu Ressourcen auf Ihren verwalteten Knoten, die in der letzten Chef-Ausführung erstellt oder überprüft wurden. Die Ressourcen können unter anderem Dateien, Verzeichnisse, `systemd`-Services, `yum`-Pakete, Vorlagendateien, `gem`-Pakete und abhängige Cookbooks umfassen.
Der Bereich **Compliance-Ressourcen-Zusammenfassung** zeigt die Anzahl der Ressourcen an, die fehlgeschlagen sind. Im folgenden Beispiel **ComplianceType**lautet **Custom: Chef** und eine Ressource ist nicht konform.
**Anmerkung**
`Custom:Chef`ist der **ComplianceType**Standardwert im `AWS-ApplyChefRecipes` Dokument. Dieser Wert ist anpassbar.
![\[Anzeigen der Anzahl im Bereich Compliance-Ressourcen-Zusammenfassung der Seite Compliance.\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/state-manager-chef-compliance-summary.png)
Der Abschnitt „**Detailübersicht für Ressourcen**“ enthält Informationen über die AWS Ressource, die nicht richtlinientreu ist. Dieser Abschnitt enthält auch den Chef-Ressourcentyp, für den die Compliance ausgeführt wurde, den Schweregrad des Problems, den Compliance-Status und Links zu weiteren Informationen, falls vorhanden.
![\[Anzeigen von Compliance-Details für einen von Chef verwalteten Ressourcenfehler\]](http://docs.aws.amazon.com/de_de/systems-manager/latest/userguide/images/state-manager-chef-compliance-details.png)
**View output** zeigt die letzten 4.000 Zeichen des detaillierten Status an. Systems Manager beginnt mit der Ausnahme als erstem Element, sucht nach ausführlichen Meldungen und zeigt diese an, bis das Kontingent von 4.000 Zeichen erreicht ist. Dieser Vorgang zeigt die Protokollmeldungen an, die vor dem Auslösen der Ausnahme ausgegeben wurden. Dabei handelt es sich um die relevantesten Nachrichten für die Fehlerbehebung.
Weitere Informationen zum Anzeigen von Compliance-Informationen finden Sie unter [AWS Systems Manager-Compliance](systems-manager-compliance.md).
**Wichtig**
Wenn die State Manager-Zuordnung fehlschlägt, werden keine Compliance-Daten gemeldet. Beispiel: Wenn Systems Manager versucht, ein Chef-Cookbook aus einem S3-Bucket herunterzuladen, und der Knoten keine Berechtigung zum Zugriff besitzt, schlägt die Zuordnung fehl und Systems Manager meldet keine Compliance-Daten.
# Exemplarische Vorgehensweise: Automatisches Update SSM Agent mit dem AWS CLI
Mit den folgenden Schritten können Sie eine State Manager-Zuordnung mithilfe der AWS Command Line Interface erstellen. Durch die Zuordnung wird der SSM Agent automatisch entsprechend einem von Ihnen angegebenen Zeitplan aktualisiert. Mehr über SSM Agent erfahren Sie unter [Arbeiten mit SSM Agent](ssm-agent.md). Informationen zum Anpassen des Aktualisierungszeitplans für SSM Agent mithilfe der Konsole finden Sie unter [Automatische Aktualisierung von SSM Agent](ssm-agent-automatic-updates.md#ssm-agent-automatic-updates-console).
Wenn Sie über SSM Agent-Aktualisierungen benachrichtigt werden möchten, abonnieren Sie die Seite [SSM Agent-Versionshinweise](https://github.com/aws/amazon-ssm-agent/blob/master/RELEASENOTES.md) auf GitHub.
**Bevor Sie beginnen**
Bevor Sie die folgenden Schritte ausführen, stellen Sie sicher, dass Sie mindestens eine Amazon Elastic Compute Cloud (Amazon EC2)-Instance für Linux, macOS oder Windows Server ausführen, die für Systems Manager konfiguriert ist. Weitere Informationen finden Sie unter [Einrichtung verwalteter Knoten für AWS Systems Manager](systems-manager-setting-up-nodes.md).
Wenn Sie eine Zuordnung entweder mithilfe von AWS CLI oder erstellen AWS Tools for Windows PowerShell, verwenden Sie den `--Targets` Parameter, um Instances als Ziel zu verwenden, wie im folgenden Beispiel gezeigt. Verwenden Sie nicht den Parameter `--InstanceID`. Der Parameter `--InstanceID` ist veraltet.
**So erstellen Sie eine Zuordnung für die automatische Aktualisierung von SSM Agent**
1. Installieren und konfigurieren Sie AWS Command Line Interface (AWS CLI), falls Sie dies noch nicht getan haben.
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren der neuesten Version von AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Führen Sie den folgenden Befehl aus, um eine Zuordnung zu erstellen, indem Sie Instances mithilfe von Amazon Elastic Compute Cloud (Amazon EC2)-Tags anvisieren. Ersetzen Sie jeden *example resource placeholder* durch Ihre Informationen. Der `Schedule`-Parameter legt einen Zeitplan für die Ausführung der Zuordnung an jedem Sonntagmorgen um 2:00 Uhr (UTC) fest.
State Manager-Zuordnungen unterstützen nicht alle Cron- und Rate-Ausdrücke. Weitere Informationen zum Erstellen von Cron- und Rate-Ausdrücken für Zuordnungen finden Sie unter [Referenz: Cron- und Rate-Ausdrücke für System 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 *)"
```
------
Sie können mehrere Instanzen als Ziel angeben, indem Sie die Instanzen IDs in einer durch Kommas getrennten Liste angeben.
------
#### [ 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 *)"
```
------
Sie können die Version des SSM Agent angeben, den Sie aktualisieren möchten.
------
#### [ 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
```
------
Das System gibt unter anderem folgende Informationen zurück
```
{
"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"
}
]
}
}
```
Das System versucht, die Zuordnung für die Instances zu erstellen und wendet den Status nach der Erstellung an. Der Zuordnungsstatus lautet `Pending` (Schwebend).
1. Führen Sie den folgenden Befehl aus, um einen aktualisierten Status der erstellten Zuordnung anzuzeigen.
```
aws ssm list-associations
```
Wenn auf Ihren Instances *nicht* die neueste Version von SSM Agent ausgeführt wird, wird der Status `Failed` angezeigt. Bei Veröffentlichung einer neuen SSM Agent-Version wird der neue Agent automatisch von der Zuordnung installiert und der Status zeigt `Success` an.
# Anleitung: Automatische Aktualisierung von PV-Treibern auf EC2-Instances für Windows Server
Amazon Windows Server Amazon Machine Images (AMIs) enthalten eine Reihe von Treibern, die den Zugriff auf virtualisierte Hardware ermöglichen. Diese Treiber werden von Amazon Elastic Compute Cloud (Amazon EC2) verwendet, um Instance-Speicher und Amazon Elastic Block Store (Amazon EBS)-Volumes ihren Geräten zuzuordnen. Wir empfehlen, die aktuellen Treiber zu installieren, um die Stabilität und Leistung Ihrer EC2-Instances für Windows Server zu verbessern. Weitere Informationen zu PV-Treibern finden Sie unter [AWS PV-Treiber](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/xen-drivers-overview.html#xen-driver-awspv).
Die folgende exemplarische Vorgehensweise zeigt Ihnen, wie Sie eine State Manager Zuordnung so konfigurieren, dass neue AWS PV-Treiber automatisch heruntergeladen und installiert werden, sobald die Treiber verfügbar sind. State Managerist ein Tool in AWS Systems Manager.
**Bevor Sie beginnen**
Bevor Sie die folgenden Schritte ausführen, stellen Sie sicher, dass Sie mindestens eine Amazon-EC2-Instance für Windows Server ausführen, die für Systems Manager verwaltet konfiguriert ist. Weitere Informationen finden Sie unter [Einrichtung verwalteter Knoten für AWS Systems Manager](systems-manager-setting-up-nodes.md).
**So erstellen Sie eine State Manager-Zuordnung, die automatisch PV-Treiber aktualisiert**
1. Öffnen Sie die AWS Systems Manager Konsole unter [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Wählen Sie im Navigationsbereich **State Manager** aus.
1. Wählen Sie **Create association (Zuordnung erstellen)** aus.
1. Geben Sie im Feld **Name** einen beschreibenden Namen für die Zuordnung ein.
1. Wählen Sie in der Liste **Dokument** die Option `AWS-ConfigureAWSPackage` aus.
1. Gehen Sie im Abschnitt **Parameter** wie folgt vor:
+ Wählen Sie für **Action (Aktion)** die Option **Install (Installieren)**.
+ Wählen Sie für **Installation type (Art der Installation)** **Uninstall and reinstall (Deinstallieren und neu installieren)**.
**Anmerkung**
Direkte Upgrades werden für dieses Paket nicht unterstützt. Es muss deinstalliert und neu installiert werden.
+ Geben Sie unter **Name** **AWSPVDriver** ein.
Sie müssen nichts für **Version** und **Zusätzliche Argumente** eingeben.
1. Identifizieren Sie für den Abschnitt **Ziele** die verwalteten Knoten, auf denen Sie diese Operation ausführen möchten, indem Sie Tags angeben, Instances oder Edge-Geräte manuell auswählen oder eine Ressourcengruppe angeben.
**Tipp**
Wenn ein verwalteter Knoten, den Sie erwarten, nicht aufgeführt ist, finden Sie weitere Informationen unter [Problembehandlung bei der Verfügbarkeit verwalteter Knoten](fleet-manager-troubleshooting-managed-nodes.md) Tipps zur Fehlerbehebung.
**Anmerkung**
Wenn Sie Ziel-Instances mittels Tags auswählen und Tags angeben, die Linux-Instances zugeordnet sind, ist die Zuordnung zwar auf der Windows Server-Instance erfolgreich, schlägt jedoch auf den Linux-Instances fehl. Der Gesamtstatus der Zuordnung zeigt **Failed** (Fehler) an.
1. Wählen Sie im Bereich **Zeitplan angeben** aus, ob die Zuordnung nach einem von Ihnen konfigurierten Zeitplan oder nur einmal ausgeführt werden soll. Aktualisierte PV-Treiber werden mehrere Male pro Jahr veröffentlicht. Wenn Sie möchten, können Sie die Zuordnung einmal pro Monat ausführen lassen.
1. Wählen Sie unter **Erweiterte Optionen** für **Compliance-Schweregrad** einen Schweregrad für die Zuordnung aus. In den Compliance-Berichten finden Sie Informationen dazu, ob die Zuordnung konform ist, zusammen mit dem Schweregrad, den Sie hier angeben. Weitere Informationen finden Sie unter [Informationen zu State Manager-Zuordnungs-Compliance](compliance-about.md#compliance-about-association).
1. Für **Ratenregelung**:
+ Geben Sie unter **Nebenläufigkeit** entweder eine Zahl oder einen Prozentsatz der verwalteten Knoten an, auf denen der Befehl gleichzeitig ausgeführt werden soll.
**Anmerkung**
Wenn Sie Ziele ausgewählt haben, indem Sie Tags für verwaltete Knoten oder AWS Ressourcengruppen angegeben haben und Sie sich nicht sicher sind, wie viele verwaltete Knoten das Ziel sind, schränken Sie die Anzahl der Ziele ein, die das Dokument gleichzeitig ausführen können, indem Sie einen Prozentsatz angeben.
+ Geben Sie unter **Fehlerschwellenwert** an, wann die Ausführung des Befehls auf anderen verwalteten Knoten beendet werden soll, nachdem dafür entweder auf einer bestimmten Anzahl oder einem Prozentsatz von Knoten ein Fehler aufgetreten ist. Falls Sie beispielsweise drei Fehler angeben, sendet Systems Manager keinen Befehl mehr, wenn der vierte Fehler empfangen wird. Von verwalteten Knoten, auf denen der Befehl noch verarbeitet wird, werden unter Umständen ebenfalls Fehler gesendet.
1. (Optional) Wenn Sie im Abschnitt **Ausgabeoptionen** die Befehlsausgabe in einer Datei speichern möchten, aktivieren Sie das Kontrollkästchen **Schreiben der Ausgabe in S3 aktivieren**. Geben Sie die Namen für den Bucket und das Präfix (Ordner) in die Textfelder ein.
**Anmerkung**
Die S3-Berechtigungen zum Schreiben von Daten in einen S3-Bucket sind die Berechtigungen des dem verwalteten Knoten zugewiesenen Instance-Profils und nicht diejenigen des IAM-Benutzers, der diese Aufgabe ausführt. Weitere Informationen finden Sie unter [Instance-Berechtigungen für Systems Manager konfigurieren](setup-instance-permissions.md) oder [Eine IAM-Servicerolle für eine Hybrid-Umgebung erstellen](hybrid-multicloud-service-role.md). Wenn sich der angegebene S3-Bucket in einem anderen AWS-Konto befindet, stellen Sie außerdem sicher, dass das Instance-Profil oder die IAM-Servicerolle, die dem verwalteten Knoten zugeordnet ist, über die erforderlichen Berechtigungen zum Schreiben in diesen Bucket verfügt.
1. (Optional) Wählen Sie im Bereich **CloudWatch Alarm** unter **Alarmname** einen CloudWatch Alarm aus, der auf Ihre Assoziation zur Überwachung angewendet werden soll.
**Anmerkung**
Bitte beachten Sie die folgenden Informationen über diesen Schritt.
Die Liste der Alarme zeigt maximal 100 Alarme. Wenn Sie Ihren Alarm nicht in der Liste sehen, verwenden Sie den, AWS Command Line Interface um die Zuordnung zu erstellen. Weitere Informationen finden Sie unter [Erstellen einer Zuordnung (Befehlszeile)](state-manager-associations-creating.md#create-state-manager-association-commandline).
Um Ihrem Befehl einen CloudWatch Alarm anzuhängen, muss der IAM-Principal, der die Zuordnung erstellt, über die entsprechende Berechtigung für die `iam:createServiceLinkedRole` Aktion verfügen. Weitere Informationen zu CloudWatch Alarmen finden Sie unter [ CloudWatch Amazon-Alarme verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
Ausstehende Befehlsaufrufe oder Automatisierungen werden nicht ausgeführt, wenn Ihr Alarm aktiviert wird.
1. Wählen Sie **Create association** (Zuordnung erstellen) und dann **Close** (Schließen) aus. Das System versucht, die Zuordnung auf den Instances zu erstellen und den Status sofort anzuwenden.
Wenn Sie die Zuordnung auf einer oder mehreren Amazon-EC2-Instances für Windows Server erstellt haben, ändert sich der Status zu **Success (Erfolg)**. Wenn Ihre Instances nicht ordnungsgemäß für Systems Manager konfiguriert sind, oder wenn Sie versehentlich Linux-Instances ausgewählt haben, wird der Status **Failed** (Fehler) angezeigt.
Wenn der Status **Failed (Fehlgeschlagen)** lautet, wählen Sie die Zuordnungs-ID aus, wählen Sie die Registerkarte **Resource (Ressourcen)** und überprüfen Sie dann, ob die Zuordnung auf Ihren EC2-Instances für Windows Server erfolgreich erstellt wurde. Wenn EC2-Instances für den Status **Fehlgeschlagen Windows Server** anzeigen, stellen Sie sicher, dass die auf der Instance ausgeführt SSM Agent wird, und stellen Sie sicher, dass die Instance mit einer AWS Identity and Access Management (IAM) -Rolle für Systems Manager konfiguriert ist. Weitere Informationen finden Sie unter [Einrichten der einheitlichen Systems-Manager-Konsole für eine Organisation](systems-manager-setting-up-organizations.md).