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.
# Auf Instance-Metadaten für eine EC2-Instance zugreifen
Sie können auf EC2-Instance-Metadaten innerhalb der Instance selbst oder über die EC2-Konsole SDKs, API oder die zugreifen. AWS CLI Informationen zum Abrufen der aktuellen Instance-Metadateneinstellungen für eine Instance über die Konsole oder Befehlszeile finden Sie unter [Abfragen von Instance-Metadatenoptionen für vorhandene Instances](#query-IMDS-existing-instances).
Sie können Benutzerdaten für Instances mit einem EBS-Stamm-Volume ändern. Die Instances muss angehalten werden. Eine Anleitung für die Konsole finden Sie unter [Instance-Benutzerdaten aktualisieren](user-data.md#user-data-modify). Ein Linux-Beispiel, das die verwendet, finden Sie unter AWS CLI. [modify-instance-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html) Ein Windows-Beispiel, das die Tools für Windows verwendet PowerShell, finden Sie unter[Benutzerdaten und die Tools für Windows PowerShell](user-data.md#user-data-powershell).
**Anmerkung**
Beachten Sie, dass für HTTP-Anfragen für den Abruf von Instance-Metadaten und Benutzerdaten keine Gebühren berechnet werden.
## Überlegungen zum Instance-Zugriff auf Instance-Metadaten
Beachten Sie Folgendes, um Probleme mit Instanzmetadaten zu vermeiden.
**Fehler beim Starten der Instance aufgrund von IMDSv2 Erzwingungsmaßnahmen (`HttpTokensEnforced=enabled`)**
Bevor Sie die IMDSv2 Erzwingung aktivieren, müssen Sie die gesamte Software auf der Instance unterstützen IMDSv2. Danach können Sie die Standardeinstellung auf disable IMDSv1 (`httpTokens=required`) ändern und anschließend die Erzwingung aktivieren. Weitere Informationen finden Sie unter [Übergang zur Verwendung von Instance-Metadatenservice Version 2](instance-metadata-transition-to-version-2.md).
**Befehlsformat**
Das Befehlsformat ist unterschiedlich, je nachdem, ob Sie Instance Metadata Service Version 1 (IMDSv1) oder Instance Metadata Service Version 2 (IMDSv2) verwenden. Standardmäßig können Sie beide Instance-Metadaten-Services verwenden. Um die Verwendung von IMDSv2 zu erzwingen, lesen Sie [Instance-Metadaten-Services für den Zugriff auf Instance-Metadaten verwenden](configuring-instance-metadata-service.md).
**Falls IMDSv2 erforderlich, IMDSv1 funktioniert nicht**
Wenn Sie es verwenden IMDSv1 und keine Antwort erhalten, IMDSv2 ist dies wahrscheinlich erforderlich. Um zu überprüfen, ob dies erforderlich IMDSv2 ist, wählen Sie die Instanz aus, um ihre Details anzuzeigen. Der **IMDSv2**Wert gibt entweder **Erforderlich** (Sie müssen verwenden IMDSv2) oder **Optional** (Sie können entweder IMDSv2 oder verwendenIMDSv1) an.
**(IMDSv2) Wird verwendet/latest/api/token, um das Token abzurufen**
Das Ausgeben von `PUT`-Anfragen an einen beliebigen versionsspezifischen Pfad, beispielsweise `/2021-03-23/api/token`, führt dazu, dass der Metadatenservice „403-Verboten“-Fehler zurückgibt. Dieses Verhalten ist beabsichtigt.
**Metadaten-Version**
Um zu vermeiden, dass Sie Ihren Code jedes Mal aktualisieren müssen, wenn Amazon EC2 einen neuen Instance-Metadaten-Build veröffentlicht, empfehlen wir, `latest` im Pfad zu verwenden, nicht die Versionsnummer.
**IPv6 Unterstützung**
Um Instanz-Metadaten mithilfe einer IPv6 Adresse abzurufen, stellen Sie sicher, dass Sie die IPv6 Adresse des IMDS `[fd00:ec2::254]` anstelle der IPv4 Adresse `169.254.169.254` aktivieren und verwenden. Bei der Instance muss es sich um eine [Nitro-basierte Instance handeln](instance-types.md#instance-hypervisor-type), die in einem [Subnetz](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) gestartet wurde, das Folgendes unterstützt. IPv6
**(Windows) Erstellen Sie eine benutzerdefinierte Version AMIs mit Windows Sysprep**
Um sicherzustellen, dass IMDS funktioniert, wenn Sie eine Instance von einem benutzerdefinierten Windows-AMI starten, muss das AMI ein standardisiertes Image sein, welches mit Windows Sysprep erstellt wurde. Andernfalls funktioniert der IMDS nicht. Weitere Informationen finden Sie unter [Ein Amazon-EC2-AMI mit Windows Sysprep erstellen](ami-create-win-sysprep.md).
**Erwägen Sie in einer Container-Umgebung eine Neukonfiguration oder Erhöhung des Hop-Limits auf 2.**
Die AWS SDKs Verwendung IMDSv2 ruft standardmäßig auf. Wenn der IMDSv2 Anruf keine Antwort erhält, AWS SDKs wiederholen einige den Anruf und verwendenIMDSv1, falls er immer noch nicht erfolgreich ist. Dies kann zu einer Verzögerung führen, insbesondere in einer Container-Umgebung. *Wenn AWS SDKs das Hop-Limit in einer Container-Umgebung bei 1 liegt, erhält der Anruf bei Bedarf möglicherweise überhaupt keine Antwort, da das Aufrufen des Containers als zusätzlicher Netzwerk-Hop betrachtet wird.* IMDSv2
Um diese Probleme in einer Container-Umgebung zu vermeiden, sollten Sie die Konfiguration so ändern, dass Einstellungen (wie z. B. AWS-Region) direkt an den Container übergeben werden, oder erwägen Sie, das Hop-Limit auf 2 zu erhöhen. Weitere Informationen über die Auswirkung des Hop-Limits finden Sie unter [Erweitern Sie den EC2-Instance-Metadata-Service um Verbesserungen bei der Abwehr von offenen Firewalls, Reverse-Proxys und SSRF-Schwachstellen](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/). Weitere Informationen zum Ändern des Hop-Limits finden Sie unter [Ändern des PUT-Antwort-Hop-Limits](configuring-IMDS-existing-instances.md#modify-PUT-response-hop-limit).
**Begrenzen von Paketen pro Sekunde (PPS)**
Für Services, die [Link-Local](using-instance-addressing.md#link-local-addresses)-Adressen verwenden, gilt eine Obergrenze von 1 024 Paketen pro Sekunde (PPS). Dieses Limit umfasst die Summe von [Route-53-Resolver-DNS-Abfragen](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#vpc-dns-limits), Instance Metadata Service (IMDS)-Anfragen, [Amazon Time Service Network Time Protocol (NTP)](set-time.md)-Anfragen und [Windows-Licensing-Service-Anfragen (für Microsoft Windows-basierte Instances)](https://aws.amazon.com/windows/resources/licensing/).
**Zusätzliche Überlegungen zum Zugriff auf Benutzerdaten**
+ Benutzerdaten werden als Opaque-Daten behandelt: Was Sie eingeben, wird auch ausgegeben. Die Interpretation der Benutzerdaten und die Instance ist Aufgabe der Instance.
+ Benutzerdaten müssen mit Base64 codiert werden. Je nachdem, welches Tool oder SDK Sie verwenden, wird die Base64-Kodierung möglicherweise für Sie durchgeführt. Beispiel:
+ Die Amazon EC2-Konsole kann die base64-Codierung für Sie durchführen oder base64-codierte Eingaben entgegennehmen.
+ [AWS CLI Version 2 führt standardmäßig](https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-binaryparam) die Base64-Kodierung von Binärparametern für Sie durch. AWS CLI Version 1 führt die Base64-Kodierung des Parameters für Sie durch. `--user-data`
+ Die AWS SDK für Python (Boto3) führt die Base64-Kodierung des Parameters für Sie durch. `UserData`
+ Benutzerdaten sind auf 16 KB an Rohdaten, bevor diese base64-codiert werden, begrenzt. Die Länge einer Zeichenfolge *n* nach base64-Codierung ist ceil(*n*/3)\$14.
+ Benutzerdaten müssen base64-decodiert werden, wenn Sie sie abrufen. Wenn Sie die Daten über Instance-Metadaten oder die Konsole abrufen, werden sie automatisch für Sie dekodiert.
+ Wenn Sie eine Instance anhalten, ihre Benutzerdaten ändern und die Instance wieder starten, werden die aktualisierten Benutzerdaten nicht automatisch ausgeführt, wenn Sie die Instance starten. Bei Windows-Instances können Sie die Einstellungen so konfigurieren, dass aktualisierte Benutzerdatenskripte einmalig beim Starten der Instance oder bei jedem Neustart oder Start der Instance ausgeführt werden.
+ Benutzerdaten sind ein Instance-Attribut. Wenn Sie ein AMI auf der Grundlage einer Instance erstellen, sind die Instance-Benutzerdaten nicht im AMI enthalten.
## Auf Instance-Metadaten innerhalb einer EC2-Instance zugreifen
Da Ihre Instance-Metadaten von der ausgeführten Instance verfügbar sind, müssen Sie nicht die Amazon-EC2-Konsole oder die AWS CLI verwenden. Dies kann sehr hilfreich sein, wenn Sie ein Skript schreiben möchten, das in der Instance ausgeführt werden soll. So können Sie z. B. über die Instance-Metadaten auf die lokale IP-Adresse Ihrer Instance zugreifen, um die Verbindung zu einer externen Anwendung zu verwalten.
Alle folgenden Daten werden als Instance-Metadaten betrachtet, der Zugriff erfolgt jedoch auf unterschiedliche Weise. Wählen Sie die Registerkarte aus, die den Typ der Instance-Metadaten darstellt, auf die Sie zugreifen möchten, um weitere Informationen zu erhalten.
------
#### [ Metadata ]
Instance-Metadaten-Eigenschaften werden in Kategorien unterteilt. Eine Beschreibung der einzelnen Instance-Metadatenkategorien finden Sie unter [Instance-Metadatenkategorien](ec2-instance-metadata.md#instancedata-data-categories).
Um von einer laufenden Instanz aus auf die Eigenschaften der Instanz-Metadaten zuzugreifen, rufen Sie die Daten aus dem folgenden IPv4 oder ab. IPv6 URIs Die IP-Adressen sind Link-lokale Adressen und nur von der Instance aus gültig. Weitere Informationen finden Sie unter [Link-lokale Adressen](using-instance-addressing.md#link-local-addresses).
**IPv4**
```
http://169.254.169.254/latest/meta-data/
```
**IPv6**
```
http://[fd00:ec2::254]/latest/meta-data/
```
------
#### [ Dynamic data ]
Verwenden Sie eine der folgenden Methoden, um dynamische Daten aus einer laufenden Instanz abzurufenURIs.
**IPv4**
```
http://169.254.169.254/latest/dynamic/
```
**IPv6**
```
http://[fd00:ec2::254]/latest/dynamic/
```
**Beispiele: Zugriff mit cURL**
Die folgenden Beispiele verwenden `cURL`, um die High-Level-Instance-Identitätskategorien abzurufen.
*IMDSv2*
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/dynamic/instance-identity/
rsa2048
pkcs7
document
signature
dsa2048
```
*IMDSv1*
```
[ec2-user ~]$ curl http://169.254.169.254/latest/dynamic/instance-identity/
rsa2048
pkcs7
document
signature
dsa2048
```
**Beispiele: Zugriff mit PowerShell**
In den folgenden Beispielen werden PowerShell die Identitätskategorien für Instanzen auf hoher Ebene abgerufen.
*IMDSv2*
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/dynamic/instance-identity/
document
rsa2048
pkcs7
signature
```
*IMDSv1*
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/dynamic/instance-identity/
document
rsa2048
pkcs7
signature
```
Weitere Informationen zu dynamischen Daten und Beispiele dafür, wie sie abgerufen werden können, finden Sie unter [Instanzidentitätsdokumente für EC2 Amazon-Instances](instance-identity-documents.md).
------
#### [ User data ]
Verwenden Sie eine der folgenden Methoden, um Benutzerdaten aus einer Instanz abzurufen URIs. Um Benutzerdaten mithilfe der IPv6 Adresse abzurufen, müssen Sie sie aktivieren, und die Instance muss eine [Nitro-basierte Instance](instance-types.md#instance-hypervisor-type) in einem Subnetz sein, das dies unterstützt. IPv6
**IPv4**
```
http://169.254.169.254/latest/user-data
```
**IPv6**
```
http://[fd00:ec2::254]/latest/user-data
```
Eine Anfrage für Benutzerdaten geben die Daten unverändert zurück (Content-Type `application/octet-stream`). Wenn die Instance keine Benutzerdaten hat, gibt die Anfrage `404 - Not Found` zurück.
**Beispiele: Zugriff mit cURL zum Abrufen von kommagetrenntem Text**
Die folgenden Beispiele verwenden `cURL`, um Benutzerdaten abzurufen, die als kommagetrennter Text angegeben wurden.
*IMDSv2*
```
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```
*IMDSv1*
```
curl http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```
**Beispiele: Access with zum Abrufen von PowerShell kommagetrenntem Text**
In den folgenden Beispielen werden Benutzerdaten abgerufen PowerShell , die als kommagetrennter Text angegeben wurden.
*IMDSv2*
```
[string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```
*IMDSv1*
```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} `
-Method PUT -Uri http://169.254.169.254/latest/api/token} -Method GET -uri http://169.254.169.254/latest/user-data
1234,john,reboot,true | 4512,richard, | 173,,,
```
**Beispiele: Zugriff mit cURL zum Abrufen eines Skripts**
Die folgenden Beispiele verwenden `cURL`, um Benutzerdaten abzurufen, die als Skript angegeben wurden.
*IMDSv2*
```
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/user-data
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```
*IMDSv1*
```
curl http://169.254.169.254/latest/user-data
#!/bin/bash
yum update -y
service httpd start
chkconfig httpd on
```
**Beispiele: Access with, PowerShell um ein Skript abzurufen**
In den folgenden Beispielen PowerShell werden Benutzerdaten abgerufen, die als Skript angegeben wurden.
*IMDSv2*
```
[string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/user-data
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
true
```
*IMDSv1*
```
Invoke-RestMethod -uri http://169.254.169.254/latest/user-data
$file = $env:SystemRoot + "\Temp\" + (Get-Date).ToString("MM-dd-yy-hh-mm")
New-Item $file -ItemType file
true
```
------
## Abfragen von Instance-Metadatenoptionen für vorhandene Instances
Sie können die Instance-Metadatenoptionen für vorhandene Instances abfragen.
------
#### [ Console ]
**So fragen Sie die Instance-Metadatenoptionen für eine vorhandene Instance ab**
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 Ihre Instance aus und überprüfen Sie die folgenden Felder:
+ **IMDSv2**— Der Wert ist entweder **erforderlich** oder **optional**.
+ **Tags in Instance-Metadaten zulassen** – Der Wert ist entweder **Aktiviert** oder **Deaktiviert**.
1. Wenn Sie die Instance ausgewählt haben, wählen Sie **Aktionen**, **Instance-Einstellungen** und **Instance-Metadatenoptionen ändern**.
Im Dialogfeld wird angezeigt, ob der Instance-Metadatenservice für die ausgewählte Instance aktiviert oder deaktiviert ist.
------
#### [ AWS CLI ]
**So fragen Sie die Instance-Metadatenoptionen für eine vorhandene Instance ab**
Verwenden Sie den Befehl [describe-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instances.html).
```
aws ec2 describe-instances \
--instance-id i-1234567898abcdef0 \
--query 'Reservations[].Instances[].MetadataOptions'
```
------
#### [ PowerShell ]
**Um die Instanz-Metadatenoptionen für eine bestehende Instanz mithilfe der Tools für abzufragen PowerShell**
Verwenden Sie das cmdlet [Get-EC2Instance](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-EC2Instance.html).
```
(Get-EC2Instance `
-InstanceId i-1234567898abcdef0).Instances.MetadataOptions
```
------
## Antworten und Fehlermeldungen
Alle Instance-Metadaten werden als Text zurückgegeben (HTTP-Inhaltstyp `text/plain`).
Eine Anfrage für eine spezifische Metadatenressource gibt den entsprechenden Wert oder einen HTTP-Fehlercode `404 - Not Found` zurück, wenn die Ressource nicht verfügbar ist.
Eine Anfrage für eine allgemeine Metadatenressource (der URI endet auf „/”) gibt eine Liste der verfügbaren Ressourcen oder einen HTTP-Fehlercode `404 - Not Found` zurück, wenn keine entsprechenden Ressourcen vorhanden sind. Die Listenelemente stehen jeweils in einer eigenen Zeile, d. h. sie sind durch Zeilenvorschübe (ASCII 10) getrennt.
Wenn eine IMDSv1 Anfrage keine Antwort erhält, IMDSv2 ist dies wahrscheinlich erforderlich.
Bei Anfragen, die über gestellt wurden IMDSv2, können die folgenden HTTP-Fehlercodes zurückgegeben werden:
+ `400 - Missing or Invalid Parameters` – Die `PUT`-Anfrage ist nicht gültig.
+ `401 - Unauthorized` – Die `GET`-Anfrage verwendet ein ungültiges Token. Die empfohlene Aktion ist das Erzeugen eines neuen Token.
+ `403 - Forbidden` – Die Anfrage ist nicht zulässig oder der IMDS ist deaktiviert.
+ `404 - Not Found` – Die Ressource ist nicht verfügbar oder es gibt keine solche Ressource.
+ `503` – Die Anforderung konnte nicht abgeschlossen werden. Wiederholen Sie die Anforderung.
Wenn das IMDS einen Fehler zurückgibt, druckt **curl** die Fehlermeldung in der Ausgabe und gibt einen Erfolgsstatuscode zurück. Die Fehlermeldung wird in der `TOKEN`-Variablen gespeichert, was dazu führt, dass **curl**-Befehle, die das Token verwenden, fehlschlagen. Wenn Sie **curl** mit der **-f** Option aufrufen, wird im Falle eines HTTP-Serverfehlers ein Fehlerstatuscode zurückgegeben. Wenn Sie die Fehlerbehandlung aktivieren, kann die Shell den Fehler auffangen und das Skript beenden.
## Drosselung abfragen
Wir drosseln die Abfragen an den IMDS pro Instance und begrenzen die Anzahl gleichzeitiger Verbindungen von einer Instance zum IMDS.
Wenn Sie das IMDS zum Abrufen von AWS Sicherheitsanmeldedaten verwenden, vermeiden Sie es, bei jeder Transaktion oder gleichzeitig von einer großen Anzahl von Threads oder Prozessen aus nach Anmeldeinformationen zu fragen, da dies zu einer Drosselung führen kann. Wir empfehlen stattdessen, die Anmeldeinformationen im Cache zu speichern, bis sie sich ihrer Ablaufzeit nähern. Weitere Informationen über die IAM-Rolle und die der Rolle zugeordneten Sicherheitsanmeldeinformationen finden Sie unter [Abrufen von Sicherheitsanmeldeinformationen aus Instance-Metadaten](instance-metadata-security-credentials.md).
Wenn es beim Zugriff auf den IMDS zu einer Drosselung kommt, versuchen Sie Ihre Abfrage mit einer exponentiellen Backoff-Strategie erneut.
# Instance-Metadaten-Services für den Zugriff auf Instance-Metadaten verwenden
Sie können mit einer der folgenden Methoden auf Instance-Metadaten aus einer laufenden Instance zugreifen:
+ Instanz-Metadatendienst Version 2 (IMDSv2) — eine sitzungsorientierte Methode
Beispiele finden Sie unter [Beispiele für IMDSv2](#instance-metadata-retrieval-examples).
+ Instanz-Metadatendienst Version 1 (IMDSv1) — eine Methode request/response
Beispiele finden Sie unter [Beispiele für IMDSv1](#instance-metadata-retrieval-examples-imdsv1).
Standardmäßig können Sie entweder IMDSv1 oder oder IMDSv2 beide verwenden.
Sie können den Instanz-Metadatendienst (IMDS) auf jeder Instanz so konfigurieren, dass er nur IMDSv2 Aufrufe akzeptiert, was dazu führt, dass IMDSv1 Aufrufe fehlschlagen. Informationen darüber, wie Sie Ihre Instance für die Verwendung konfigurieren IMDSv2, finden Sie unter[Konfigurieren der Optionen des Instance-Metadaten-Services](configuring-instance-metadata-options.md).
Die `GET` Header `PUT` oder sind einzigartig für IMDSv2. Wenn diese Header in der Anfrage enthalten sind, dann ist die Anfrage für vorgesehen. IMDSv2 Wenn keine Header vorhanden sind, wird davon ausgegangen, dass die Anfrage dafür bestimmt ist. IMDSv1
Eine ausführliche Übersicht über finden [Sie unter IMDSv2 Erweiterter Schutz vor offenen Firewalls, Reverse-Proxys und SSRF-Sicherheitslücken mit Verbesserungen am EC2-Instanz-Metadatendienst](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/).
**Topics**
+ [
## Funktionsweise von Instance-Metadatenservice Version 2
](#instance-metadata-v2-how-it-works)
+ [
## Verwenden Sie ein unterstütztes AWS SDK
](#use-a-supported-sdk-version-for-imdsv2)
+ [
## Beispiele für IMDSv2
](#instance-metadata-retrieval-examples)
+ [
## Beispiele für IMDSv1
](#instance-metadata-retrieval-examples-imdsv1)
## Funktionsweise von Instance-Metadatenservice Version 2
IMDSv2 verwendet sitzungsorientierte Anfragen. Bei sitzungsorientierten Anforderungen erstellen Sie ein Sitzungs-Token, das die Sitzungsdauer definiert, die mindestens eine Sekunde und maximal sechs Stunden betragen kann. Während der angegebenen Dauer können Sie dasselbe Sitzungs-Token für nachfolgende Anfragen verwenden. Nach Ablauf der angegebenen Dauer müssen Sie ein neues Sitzungs-Token erstellen, das Sie für zukünftige Anfragen verwenden können.
**Anmerkung**
Die Beispiele in diesem Abschnitt verwenden die IPv4 Adresse des Instance Metadata Service (IMDS):. `169.254.169.254` Wenn Sie Instanz-Metadaten für EC2-Instances über die IPv6 Adresse abrufen, stellen Sie sicher, dass Sie stattdessen die IPv6 Adresse aktivieren und verwenden:. `[fd00:ec2::254]` Die IPv6 Adresse des IMDS ist mit Befehlen kompatibel. IMDSv2 Die IPv6 Adresse ist nur auf [Nitro-basierten Instances](instance-types.md#instance-hypervisor-type) in einem [Subnetz zugänglich, das von IPv6 -unterstützt wird](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html#subnet-ip-address-range) (Dual-Stack oder nur). IPv6
In den folgenden Beispielen wird ein Shell-Skript verwendet, IMDSv2 um die Metadatenelemente der Instanz auf oberster Ebene abzurufen. Jedes Beispiel:
+ Erstellt ein Sitzungs-Token mit einer Dauer von sechs Stunden (21 600 Sekunden) unter Verwendung der `PUT`-Anfrage.
+ Speichern den Sitzungs-Token-Header in einer Variablen namens `TOKEN` (Linux-Instances) oder `token` (Windows-Instances)
+ aFordert die Top-Level-Metadatenelemente über das Token an.
### Linux-Beispiel
Sie können zwei separate Befehle ausführen oder kombinieren.
**Separate Befehle**
Generieren Sie zuerst ein Token mit dem folgenden Befehl.
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`
```
Verwenden Sie dann das Token, um mit dem folgenden Befehl Metadatenelemente der obersten Ebene zu generieren.
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
```
**Kombinierte Befehle**
Sie können das Token speichern und die Befehle kombinieren. Das folgende Beispiel kombiniert die beiden obigen Befehle und speichert den Sitzungs-Token-Header in einer Variablen namens TOKEN.
**Anmerkung**
Wenn beim Erstellen des Tokens anstelle eines gültigen Tokens ein Fehler auftritt, wird in der Variablen eine Fehlermeldung gespeichert, und der Befehl funktioniert nicht.
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
```
Nachdem Sie ein Token erstellt haben, können Sie es bis zum Ablauf wiederverwenden. Im folgenden Beispielbefehl, der die ID des AMIs abruft, mit dem die Instance gestartet wurde, wird das im vorherigen Beispiel in `$TOKEN` gespeicherte Token wiederverwendet.
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/ami-id
```
### Windows-Beispiel
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/
```
Nachdem Sie ein Token erstellt haben, können Sie es bis zum Ablauf wiederverwenden. Im folgenden Beispielbefehl, der die ID des AMIs abruft, mit dem die Instance gestartet wurde, wird das im vorherigen Beispiel in `$token` gespeicherte Token wiederverwendet.
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} `
-Method GET -uri http://169.254.169.254/latest/meta-data/ami-id
```
Wenn Sie IMDSv2 Instanz-Metadaten anfordern, muss die Anfrage Folgendes enthalten:
1. Verwenden Sie eine `PUT`-Anfrage, um eine Sitzung mit dem Instance-Metadaten-Service zu starten. Die `PUT`-Anfrage gibt ein Token zurück, das in nachfolgenden `GET`-Anfragen an den Instance-Metadaten-Service enthalten sein muss. Das Token wird für den Zugriff auf Metadaten mit IMDSv2 benötigt.
1. Nehmen Sie das Token `GET` in alle Anfragen an den IMDS auf. Wenn die Token-Verwendung auf `required` festgelegt ist, erhalten Anfragen ohne gültiges Token oder mit abgelaufenem Token einen `401 - Unauthorized`-HTTP-Fehlercode.
+ Das Token ist ein Instance-bezogener Schlüssel. Das Token ist in anderen EC2-Instances nicht gültig und wird abgelehnt, wenn Sie versuchen, es außerhalb der Instance zu verwenden, in der es erzeugt wurde.
+ Die `PUT`-Anfrage muss einen Header enthalten, der die Time To Live (TTL) für das Token in Sekunden bis zu maximal sechs Stunden (21 600 Sekunden) angibt. Das Token stellt eine logische Sitzung dar. Die TTL gibt die Gültigkeitsdauer des Token und damit die Dauer der Sitzung an.
+ Nachdem ein Token abgelaufen ist, müssen Sie eine neue Sitzung mit einem anderen `PUT` erstellen, um auf die Instance-Metadaten zuzugreifen.
+ Sie können auswählen, ob Sie ein Token wiederverwenden oder bei jeder Anforderung einen neues Token erstellen möchten. Für eine kleine Anzahl von Anfragen kann es einfacher sein, bei jedem Zugriff auf den IMDS ein Token zu generieren und sofort zu verwenden. Aus Effizienzgründen können Sie jedoch eine längere Dauer für das Token festlegen und es wiederverwenden, anstatt jedes Mal eine `PUT`-Anfrage stellen zu müssen, wenn Sie Instance-Metadaten anfordern müssen. Es gibt keine praktische Beschränkung für die Anzahl gleichzeitiger Token, von denen jedes für eine eigene Sitzung steht. IMDSv2 ist jedoch immer noch durch normale IMDS-Verbindungs- und Drosselungsgrenzen eingeschränkt. Weitere Informationen finden Sie unter [Drosselung abfragen](instancedata-data-retrieval.md#instancedata-throttling).
In IMDSv2 Instance-Metadatenanfragen sind HTTP `GET`- und `HEAD`-Methoden zulässig. `PUT`-Anfragen werden abgelehnt, wenn sie einen X-Forwarded-For-Header enthalten.
Standardmäßig hat die Antwort auf `PUT`-Anfragen auf IP-Protokollebene ein Antworthop-Limit (Time To Live) von `1`. Wenn Sie ein größeres Hop-Limit benötigen, können Sie es mit dem Befehl anpassen. [modify-instance-metadata-options](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html) AWS CLI Beispielsweise benötigen Sie möglicherweise eine größeres Hop-Limit für die Abwärtskompatibilität mit Container-Services, die auf der Instance ausgeführt werden. Weitere Informationen finden Sie unter [Modifizieren von Instance-Metadatenoptionen für vorhandene Instances](configuring-IMDS-existing-instances.md).
## Verwenden Sie ein unterstütztes AWS SDK
Um IMDSv2 verwenden zu können, müssen Ihre EC2-Instances eine AWS SDK-Version verwenden, die die Verwendung von unterstützt. IMDSv2 Die neuesten Versionen aller unterstützen die AWS SDKs Verwendung von. IMDSv2
**Wichtig**
Wir empfehlen Ihnen, über die SDK-Versionen auf dem Laufenden zu bleiben, um über die neuesten Features, Sicherheitsupdates und zugrunde liegenden Abhängigkeiten informiert zu sein. Die fortgesetzte Verwendung einer nicht unterstützten SDK-Version wird nicht empfohlen und erfolgt nach Ihrem Ermessen. Weitere Informationen finden Sie in den [Wartungsrichtlinien für AWS SDKs und Tools](https://docs.aws.amazon.com/sdkref/latest/guide/maint-policy.html) im *AWS SDKs Referenzhandbuch für Tools*.
Im Folgenden sind die Mindestversionen aufgeführt, die die Verwendung von unterstützen IMDSv2:
+ [AWS CLI](https://github.com/aws/aws-cli) – 1.16.289
+ [AWS Tools for Windows PowerShell](https://github.com/aws/aws-tools-for-powershell) – 4.0.1.0
+ [AWS SDK für .NET](https://github.com/aws/aws-sdk-net) – 3.3.634.1
+ [AWS SDK für C\$1\$1](https://github.com/aws/aws-sdk-cpp) – 1.7.229
+ [AWS SDK für Go](https://github.com/aws/aws-sdk-go) – 1.25.38
+ [AWS SDK for Go v2](https://github.com/aws/aws-sdk-go-v2) — 0.19.0
+ [AWS SDK für Java](https://github.com/aws/aws-sdk-java) – 1.11.678
+ [AWS SDK for Java 2.x](https://github.com/aws/aws-sdk-java-v2) – 2.10.21
+ [AWS SDK für JavaScript in Node.js](https://github.com/aws/aws-sdk-js) — 2.722.0
+ [AWS SDK für Kotlin](https://github.com/awslabs/aws-sdk-kotlin) – 1,1.4
+ [AWS SDK für PHP](https://github.com/aws/aws-sdk-php) – 3.147.7
+ [AWS SDK für Python (Botocore)](https://github.com/boto/botocore) — 1.13.25
+ [AWS SDK für Python (Boto3)](https://github.com/boto/boto3) – 1.12.6
+ [AWS SDK für Ruby](https://github.com/aws/aws-sdk-ruby) – 3.79.0
## Beispiele für IMDSv2
Führen Sie die folgenden Beispiele auf Ihrer Amazon EC2 EC2-Instance aus, um die Instance-Metadaten für IMDSv2 abzurufen.
Auf Windows-Instanzen können Sie Windows verwenden PowerShell oder cURL oder wget installieren. Wenn Sie ein Drittanbieter-Tool in einer Windows-Instance installieren, sollten Sie die zugehörige Dokumentation unbedingt sorgfältig lesen; die Methode für die Aufrufe und die Ausgabe können von dieser Dokumentation abweichen.
**Topics**
+ [
### Abrufen der verfügbaren Versionen der Instance-Metadaten
](#instance-metadata-ex-1)
+ [
### Anfordern der Top-Level-Metadatenelemente
](#instance-metadata-ex-2)
+ [
### Die Werte für Metadatenelemente abrufen
](#instance-metadata-ex-2a)
+ [
### Abrufen der Liste der verfügbaren öffentlichen Schlüssel
](#instance-metadata-ex-3)
+ [
### Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
](#instance-metadata-ex-4)
+ [
### Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
](#instance-metadata-ex-5)
+ [
### Anfordern der Subnetz-ID für eine Instance
](#instance-metadata-ex-6)
+ [
### Abrufen von Instance-Tags für eine Instance
](#instance-metadata-ex-7)
### Abrufen der verfügbaren Versionen der Instance-Metadaten
In diesem Beispiel werden die verfügbaren Versionen der Instance-Metadaten abgerufen. Jede Version bezieht sich auf einen Instance-Metadaten-Build, wenn neue Instance-Metadatenkategorien veröffentlicht wurden. Die Build-Versionen der Instance-Metadaten korrelieren nicht mit den Amazon-EC2-API-Versionen. Es stehen frühere Versionen zur Verfügung, für den Fall dass Skripte angewendet werden, die auf den Strukturen und Daten dieser früheren Versionen aufbauen.
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
...
latest
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
...
latest
```
------
### Anfordern der Top-Level-Metadatenelemente
In diesem Beispiel werden die Metadaten-Elemente der obersten Ebene abgerufen. Weitere Informationen zu den einzelnen Punkten in der Antwort finden Sie unter [Instance-Metadatenkategorien](ec2-instance-metadata.md#instancedata-data-categories).
Beachten Sie, dass Tags nur dann in dieser Ausgabe enthalten sind, wenn Sie den Zugriff zugelassen haben. Weitere Informationen finden Sie unter [Zugriff auf Tags in Instance-Metadaten ermöglichen](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS).
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
iam/
instance-action
instance-id
instance-life-cycle
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```
------
### Die Werte für Metadatenelemente abrufen
Die folgenden Beispiele zeigen die Werte einiger der Top-Level-Metadatenelemente, die im vorherigen Beispiel abgerufen wurden. Diese Anfragen verwenden das gespeicherte Token, das mit dem Befehl im vorherigen Beispiel erstellt wurde. Das Token darf nicht abgelaufen sein.
------
#### [ cURL ]
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```
------
### Abrufen der Liste der verfügbaren öffentlichen Schlüssel
In diesem Beispiel wird die Liste der verfügbaren öffentlichen Schlüssel abgerufen.
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/
0=my-public-key
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/
0=my-public-key
```
------
### Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
In diesem Beispiel werden die Formate abgerufen, in denen der öffentliche Schlüssel 0 verfügbar ist.
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/0/
openssh-key
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
openssh-key
```
------
### Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
In diesem Beispiel wird der öffentliche Schlüssel 0 abgerufen (im Format für OpenSSH-Schlüssel).
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```
------
### Anfordern der Subnetz-ID für eine Instance
In diesem Beispiel wird eine Subnetz-ID für eine Instance vergeben.
------
#### [ cURL ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```
------
#### [ PowerShell ]
```
PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token
```
```
PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```
------
### Abrufen von Instance-Tags für eine Instance
Wenn der Zugriff auf Instance-Tags in den Instance-Metadaten aktiviert ist, können Sie die Tags für eine Instance aus den Instance-Metadaten abrufen. Weitere Informationen finden Sie unter [Abrufen von Tags aus Instance-Metadaten](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS).
## Beispiele für IMDSv1
Führen Sie die folgenden Beispiele auf Ihrer Amazon EC2 EC2-Instance aus, um die Instance-Metadaten für IMDSv1 abzurufen.
Auf Windows-Instanzen können Sie Windows verwenden PowerShell oder cURL oder wget installieren. Wenn Sie ein Drittanbieter-Tool in einer Windows-Instance installieren, sollten Sie die zugehörige Dokumentation unbedingt sorgfältig lesen; die Methode für die Aufrufe und die Ausgabe können von dieser Dokumentation abweichen.
**Topics**
+ [
### Abrufen der verfügbaren Versionen der Instance-Metadaten
](#instance-metadata-ex-1-imdsv1)
+ [
### Anfordern der Top-Level-Metadatenelemente
](#instance-metadata-ex-2-imdsv1)
+ [
### Die Werte für Metadatenelemente abrufen
](#instance-metadata-ex-2a-imdsv1)
+ [
### Abrufen der Liste der verfügbaren öffentlichen Schlüssel
](#instance-metadata-ex-3-imdsv1)
+ [
### Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
](#instance-metadata-ex-4-imdsv1)
+ [
### Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
](#instance-metadata-ex-5-imdsv1)
+ [
### Anfordern der Subnetz-ID für eine Instance
](#instance-metadata-ex-6-imdsv1)
+ [
### Abrufen von Instance-Tags für eine Instance
](#instance-metadata-ex-7-imdsv1)
### Abrufen der verfügbaren Versionen der Instance-Metadaten
In diesem Beispiel werden die verfügbaren Versionen der Instance-Metadaten abgerufen. Jede Version bezieht sich auf einen Instance-Metadaten-Build, wenn neue Instance-Metadatenkategorien veröffentlicht wurden. Die Build-Versionen der Instance-Metadaten korrelieren nicht mit den Amazon-EC2-API-Versionen. Es stehen frühere Versionen zur Verfügung, für den Fall dass Skripte angewendet werden, die auf den Strukturen und Daten dieser früheren Versionen aufbauen.
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
...
latest
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
...
latest
```
------
### Anfordern der Top-Level-Metadatenelemente
In diesem Beispiel werden die Metadaten-Elemente der obersten Ebene abgerufen. Weitere Informationen zu den einzelnen Punkten in der Antwort finden Sie unter [Instance-Metadatenkategorien](ec2-instance-metadata.md#instancedata-data-categories).
Beachten Sie, dass Tags nur dann in dieser Ausgabe enthalten sind, wenn Sie den Zugriff zugelassen haben. Weitere Informationen finden Sie unter [Zugriff auf Tags in Instance-Metadaten ermöglichen](work-with-tags-in-IMDS.md#allow-access-to-tags-in-IMDS).
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
iam/
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
hostname
iam/
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
tags/
```
------
### Die Werte für Metadatenelemente abrufen
Die folgenden Beispiele zeigen die Werte einiger der Top-Level-Metadatenelemente, die im vorherigen Beispiel abgerufen wurden.
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/ami-id
ami-0abcdef1234567890
```
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/reservation-id
r-0efghijk987654321
```
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/local-hostname
ip-10-251-50-12.ec2.internal
```
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-hostname
ec2-203-0-113-25.compute-1.amazonaws.com
```
------
### Abrufen der Liste der verfügbaren öffentlichen Schlüssel
In diesem Beispiel wird die Liste der verfügbaren öffentlichen Schlüssel abgerufen.
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/
0=my-public-key
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/ 0=my-public-key
```
------
### Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
In diesem Beispiel werden die Formate abgerufen, in denen der öffentliche Schlüssel 0 verfügbar ist.
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/
openssh-key
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
openssh-key
```
------
### Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
In diesem Beispiel wird der öffentliche Schlüssel 0 abgerufen (im Format für OpenSSH-Schlüssel).
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
```
------
### Anfordern der Subnetz-ID für eine Instance
In diesem Beispiel wird eine Subnetz-ID für eine Instance vergeben.
------
#### [ cURL ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```
------
#### [ PowerShell ]
```
PS C:\> Invoke-RestMethod -uri http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id
subnet-be9b61d7
```
------
### Abrufen von Instance-Tags für eine Instance
Wenn der Zugriff auf Instance-Tags in den Instance-Metadaten aktiviert ist, können Sie die Tags für eine Instance aus den Instance-Metadaten abrufen. Weitere Informationen finden Sie unter [Abrufen von Tags aus Instance-Metadaten](work-with-tags-in-IMDS.md#retrieve-tags-from-IMDS).
# Übergang zur Verwendung von Instance-Metadatenservice Version 2
Wenn Sie Ihre Instances so konfigurieren möchten, dass sie nur Aufrufe von Instance Metadata Service Version 2 (IMDSv2) akzeptieren, empfehlen wir Ihnen, die folgenden Tools und den folgenden Übergangspfad zu verwenden.
**Topics**
+ [
## Tools für den Übergang zu IMDSv2
](#tools-for-transitioning-to-imdsv2)
+ [
## Empfohlener Pfad zur Anforderung IMDSv2
](#recommended-path-for-requiring-imdsv2)
## Tools für den Übergang zu IMDSv2
Mit den folgenden Tools können Sie den Übergang Ihrer Software von zu identifizieren, zu überwachen und IMDSv1 zu IMDSv2 verwalten. Anweisungen zur Verwendung dieser Tools finden Sie unter[Empfohlener Pfad zur Anforderung IMDSv2](#recommended-path-for-requiring-imdsv2).
**AWS Software**
Die neuesten Versionen der AWS SDKs AWS CLI und unterstützen IMDSv2. Um IMDSv2 zu verwenden, aktualisieren Sie Ihre EC2-Instances, sodass sie die neuesten Versionen verwenden. Informationen zu den AWS SDK-Mindestversionen, die dies unterstützen IMDSv2, finden Sie unter. [Verwenden Sie ein unterstütztes AWS SDK](configuring-instance-metadata-service.md#use-a-supported-sdk-version-for-imdsv2)
Alle Amazon Linux 2- und Amazon Linux 2023-Softwarepakete IMDSv2 werden unterstützt. Amazon Linux 2023 ist IMDSv1 standardmäßig deaktiviert.
**IMDS-Paket-Analysator**
IMDS Packet Analyzer ist ein Open-Source-Tool, das IMDSv1 Aufrufe während der Startphase und der Laufzeitvorgänge Ihrer Instance identifiziert und protokolliert. Durch die Analyse dieser Protokolle können Sie genau identifizieren, welche Software Ihre Instances IMDSv1 aufruft, und bestimmen, welche Software aktualisiert werden muss, damit sie IMDSv2 nur auf Ihren Instances unterstützt wird. Sie können IMDS-Paket-Analysator von der Befehlszeile aus ausführen oder als Service installieren. Weitere Informationen finden Sie [AWS ImdsPacketAnalyzer](https://github.com/aws/aws-imds-packet-analyzer)unter *GitHub*.
**CloudWatch**
CloudWatch bietet die folgenden zwei Metriken für die Überwachung Ihrer Instances:
`MetadataNoToken`— IMDSv2 verwendet tokengestützte Sitzungen, tut dies aber IMDSv1 nicht. Die `MetadataNoToken` Metrik verfolgt die Anzahl der Aufrufe des Instance Metadata Service (IMDS), die verwendet werden. IMDSv1 Indem Sie diese Metrik bis zum Wert Null nachverfolgen, können Sie feststellen, ob und wann Ihre Software auf IMDSv2 aktualisiert wurde.
`MetadataNoTokenRejected`— Nach der Deaktivierung IMDSv1 können Sie anhand der `MetadataNoTokenRejected` Metrik verfolgen, wie oft ein IMDSv1 Anruf versucht und abgelehnt wurde. Indem Sie diese Metrik verfolgen, können Sie feststellen, ob Ihre Software aktualisiert werden muss, um sie verwenden IMDSv2 zu können.
Für jede EC2-Instance schließen sich diese Metriken gegenseitig aus. Wenn aktiviert IMDSv1 ist (`httpTokens = optional`), wird nur ausgegeben`MetadataNoToken`. Wenn deaktiviert IMDSv1 ist (`httpTokens = required`), wird nur ausgegeben`MetadataNoTokenRejected`. Wann Sie diese Metriken verwenden sollten, finden Sie unter[Empfohlener Pfad zur Anforderung IMDSv2](#recommended-path-for-requiring-imdsv2).
Weitere Informationen finden Sie unter [Instance-Metriken](viewing_metrics_with_cloudwatch.md#ec2-cloudwatch-metrics).
**Starten APIs**
**Neue Instances:** Verwenden Sie die [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)API, um neue Instances zu starten, für die die Verwendung von erforderlich ist IMDSv2. Weitere Informationen finden Sie unter [Konfigurieren von Instance-Metadatenoptionen für neue Instances](configuring-IMDS-new-instances.md).
**Bestehende Instanzen:** Verwenden Sie die [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API, um die Verwendung von IMDSv2 auf vorhandenen Instanzen vorzuschreiben. Weitere Informationen finden Sie unter [Modifizieren von Instance-Metadatenoptionen für vorhandene Instances](configuring-IMDS-existing-instances.md).
**Neue Instances, die von Auto Scaling Scaling-Gruppen gestartet wurden:** Um die Verwendung von IMDSv2 für alle neuen Instances zu verlangen, die von Auto Scaling Scaling-Gruppen gestartet werden, können Ihre Auto Scaling Scaling-Gruppen entweder eine Startvorlage oder eine Startkonfiguration verwenden. Wenn Sie [eine Startvorlage erstellen](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-launch-template.html) oder [eine Startkonfiguration erstellen](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/create-launch-configuration.html), müssen Sie die `MetadataOptions`-Parameter so konfigurieren, dass die Verwendung von IMDSv2 erforderlich ist. Die Auto-Scaling-Gruppe startet neue Instances mit der neuen Startvorlage oder Startkonfiguration, bestehende Instances sind davon jedoch nicht betroffen.
**Bestehende Instances in einer Auto Scaling Scaling-Gruppe:** Verwenden Sie die [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API, um die Verwendung von IMDSv2 auf vorhandenen Instances vorzuschreiben, oder beenden Sie die Instances, und die Auto Scaling Scaling-Gruppe startet neue Ersatz-Instances mit den Einstellungen der Instance-Metadaten-Optionen, die in der neuen Startvorlage oder Startkonfiguration definiert sind.
**AMIs**
AMIs konfiguriert mit dem `ImdsSupport` Parameter, der auf gesetzt ist, `v2.0` startet IMDSv2 standardmäßig Instances, die dies erfordern. Amazon Linux 2023 ist konfiguriert mit`ImdsSupport = v2.0`.
**Neu AMIs:** Verwenden Sie den CLI-Befehl [register-image](https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html), um den `ImdsSupport` Parameter auf zu setzen, `v2.0` wenn Sie ein neues AMI erstellen.
**Existierend AMIs:** Verwenden Sie den [modify-image-attribute](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-image-attribute.html)CLI-Befehl, um den `ImdsSupport` Parameter auf festzulegen, `v2.0` wenn Sie ein vorhandenes AMI ändern.
Weitere Informationen finden Sie unter [Konfigurieren des AMI](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-ami-configuration).
**Kontrollen auf Kontoebene**
Sie können Standardwerte für alle Instanz-Metadatenoptionen auf Kontoebene konfigurieren. Die Standardwerte werden automatisch angewendet, wenn Sie eine Instance starten. Weitere Informationen finden Sie unter[IMDSv2 Als Standard für das Konto festlegen](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults).
Sie können die Anforderung zur Nutzung auch IMDSv2 auf Kontoebene durchsetzen. Wenn die IMDSv2 Durchsetzung aktiviert ist:
+ **Neue Instanzen: Instances**, die so konfiguriert sind, dass sie mit IMDSv1 aktivierter Option gestartet werden, können nicht gestartet werden
+ **Bestehende Instances mit IMDSv1 deaktiviertem Status:** Versuche, sie IMDSv1 auf vorhandenen Instances zu aktivieren, werden verhindert.
+ **Bestehende Instanzen mit IMDSv1 aktivierter Option:** Bestehende Instanzen, die IMDSv1 bereits aktiviert sind, sind davon nicht betroffen.
Weitere Informationen finden Sie unter [IMDSv2 Auf Kontoebene durchsetzen](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level).
**IAM-Richtlinien und SCPs**
Sie können eine IAM-Richtlinie oder eine AWS Organizations Service Control Policy (SCP) verwenden, um Benutzer wie folgt zu kontrollieren:
+ Eine Instance kann nicht mithilfe der [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)API gestartet werden, es sei denn, die Instance ist für die Verwendung konfiguriert. IMDSv2
+ Eine bestehende Instanz kann nicht mithilfe der [ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)API geändert werden, um sie erneut zu aktivierenIMDSv1.
Die IAM-Richtlinie oder die SCP muss die folgenden IAM-Bedingungsschlüssel enthalten:
+ `ec2:MetadataHttpEndpoint`
+ `ec2:MetadataHttpPutResponseHopLimit`
+ `ec2:MetadataHttpTokens`
Wenn ein Parameter im API- oder CLI-Aufruf nicht mit dem Status übereinstimmt, der in der Richtlinie angegeben ist, die den Bedingungsschlüssel enthält, schlägt der API- oder CLI-Aufruf mit einer `UnauthorizedOperation` Antwort fehl.
Darüber hinaus können Sie eine zusätzliche Schutzebene auswählen, um die Änderung von IMDSv1 auf IMDSv2 zu erzwingen. Auf der Zugriffsverwaltungsebene für die APIs, die über EC2-Rollenanmeldedaten aufgerufen werden, können Sie einen Bedingungsschlüssel entweder in IAM-Richtlinien oder in AWS Organizations Dienststeuerungsrichtlinien () SCPs verwenden. Insbesondere wenn Sie den Bedingungsschlüssel `ec2:RoleDelivery` mit einem Wert von `2.0` in Ihren IAM-Richtlinien verwenden, erhalten API-Aufrufe, die mit den EC2-Rollenanmeldedaten von IMDSv1 abgerufen wurden, eine Antwort. `UnauthorizedOperation` Das Gleiche kann mit der von einer SCP erzwungenen Bedingung weiter gefasst werden. Dadurch wird sichergestellt, dass die über übermittelten Anmeldeinformationen IMDSv1 nicht tatsächlich zum Aufrufen verwendet werden können, APIs da bei API-Aufrufen, die nicht der angegebenen Bedingung entsprechen, eine `UnauthorizedOperation` Fehlermeldung ausgegeben wird.
Beispiele für IAM-Richtlinien finden Sie unter [Arbeiten mit Instance-Metadaten](ExamplePolicies_EC2.md#iam-example-instance-metadata). Weitere Informationen zu SCPs finden Sie im *AWS Organizations Benutzerhandbuch* unter [Richtlinien zur Servicesteuerung](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).
**Deklarative Richtlinien**
Verwenden Sie deklarative Richtlinien (eine Funktion von AWS Organizations), um die Standardeinstellungen für IMDS-Konten, einschließlich deren IMDSv2 Durchsetzung, in Ihrem gesamten Unternehmen zentral festzulegen. *Eine Beispielrichtlinie finden Sie auf der Registerkarte **Instanz-Metadaten** im Abschnitt [Unterstützte deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) im Benutzerhandbuch.AWS Organizations *
## Empfohlener Pfad zur Anforderung IMDSv2
**Topics**
+ [
### Schritt 1: Identifizieren Sie Instanzen mit IMDSv2 =optional und überprüfen Sie die Nutzung IMDSv1
](#path-step-1)
+ [
### Schritt 2: Aktualisieren Sie die Software auf IMDSv2
](#path-step-2)
+ [
### Schritt 3: Keine Instanzen erforderlich IMDSv2
](#path-step-3)
+ [
### Schritt 4: Stellen Sie IMDSv2 =required als Standard ein
](#path-step-4)
+ [
### Schritt 5: Erzwingen Sie, dass Instanzen Folgendes benötigen IMDSv2
](#path-step-5)
### Schritt 1: Identifizieren Sie Instanzen mit IMDSv2 =optional und überprüfen Sie die Nutzung IMDSv1
Um Ihren IMDSv2 Migrationsumfang einzuschätzen, identifizieren Sie Instanzen, die so konfiguriert sind, dass sie entweder IMDSv1 oder zulassen IMDSv2, und prüfen Sie IMDSv1 Aufrufe.
1. **Identifizieren Sie Instanzen, die so konfiguriert sind, dass sie entweder IMDSv1 oder IMDSv2:**
------
#### [ Amazon EC2 console ]
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. Um nur die Instanzen zu sehen, die so konfiguriert sind, dass sie IMDSv1 oder zulassen IMDSv2, fügen Sie den Filter **IMDSv2 = optional** hinzu.
1. Um zu sehen, ob dies **optional** oder für alle Instanzen **erforderlich IMDSv2 ** ist, öffnen Sie alternativ das **Einstellungsfenster** (Zahnradsymbol) **IMDSv2**, schalten Sie die Option ein und wählen Sie **Bestätigen**. Dadurch wird die **IMDSv2**Spalte zur **Instanzen-Tabelle** hinzugefügt.
------
#### [ AWS CLI ]
Verwenden Sie den Befehl [describe-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html) und filtern `metadata-options.http-tokens = optional` Sie wie folgt nach:
```
aws ec2 describe-instances --filters "Name=metadata-options.http-tokens,Values=optional" --query "Reservations[*].Instances[*].[InstanceId]" --output text
```
------
1. ** IMDSv1 Audit-Aufrufe für jede Instanz:**
Verwenden Sie die CloudWatch Metrik`MetadataNoToken`. Diese Metrik zeigt die Anzahl der IMDSv1 Aufrufe an das IMDS auf Ihren Instances. Weitere Informationen finden Sie unter [Instanz-Metriken](https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-metrics).
1. **Identifizieren Sie die Software auf Ihren Instances, die IMDSv1 Anrufe tätigt:**
Verwenden Sie den [Open-Source-IMDS Packet Analyzer](https://github.com/aws/aws-imds-packet-analyzer), um IMDSv1 Aufrufe während der Startphase und der Laufzeitvorgänge Ihrer Instance zu identifizieren und zu protokollieren. Verwenden Sie diese Informationen, um die Software zu identifizieren, die aktualisiert werden muss, damit Ihre Instances IMDSv2 nur einsatzbereit sind. Sie können IMDS-Paket-Analysator von der Befehlszeile aus ausführen oder als Service installieren.
### Schritt 2: Aktualisieren Sie die Software auf IMDSv2
Aktualisieren Sie alle SDKs, und Software CLIs, die Rollenanmeldedaten auf Ihren Instances verwendet, auf IMDSv2 -kompatible Versionen. Weitere Informationen zur Aktualisierung der CLI finden Sie unter [Installieren oder Aktualisieren auf die neueste Version der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) im *Benutzerhandbuch für AWS Command Line Interface *.
### Schritt 3: Keine Instanzen erforderlich IMDSv2
Nachdem Sie anhand der `MetadataNoToken` Metrik bestätigt haben, dass keine IMDSv1 Aufrufe mehr erforderlich sind, konfigurieren Sie Ihre vorhandenen Instances so, dass sie erforderlich sind IMDSv2. Konfigurieren Sie außerdem alle neuen Instanzen so, dass sie erforderlich sind IMDSv2. Mit anderen Worten, deaktivieren Sie es IMDSv1 auf allen vorhandenen und neuen Instanzen.
1. **Konfigurieren Sie bestehende Instanzen so, dass sie Folgendes erfordernIMDSv2:**
------
#### [ Amazon EC2 console ]
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 Ihre Instance aus.
1. Wählen Sie **Aktionen**, **Instance-Einstellungen** und **Instance-Metadata-Optionen ändern**.
1. Wählen Sie für **IMDSv2**die Option **Erforderlich** aus.
1. Wählen Sie **Speichern**.
------
#### [ AWS CLI ]
Verwenden Sie den [modify-instance-metadata-options](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-options.html)CLI-Befehl, um anzugeben, IMDSv2 dass nur verwendet werden soll.
------
**Anmerkung**
Sie können diese Einstellung bei laufenden Instances ändern. Die Änderung wird sofort wirksam, ohne dass ein Neustart der Instanz erforderlich ist.
Weitere Informationen finden Sie unter [Erfordern die Verwendung von IMDSv2](configuring-IMDS-existing-instances.md#modify-require-IMDSv2).
1. **Achten Sie nach der Deaktivierung IMDSv1 auf Probleme:**
1. Verfolgen Sie anhand der `MetadataNoTokenRejected` CloudWatch Metrik, wie oft ein IMDSv1 Anruf versucht und abgelehnt wurde.
1. Wenn die `MetadataNoTokenRejected` Metrik IMDSv1 Aufrufe einer Instanz aufzeichnet, bei der Softwareprobleme auftreten, bedeutet dies, dass die Software aktualisiert werden muss, damit sie verwendet IMDSv2 werden kann.
1. **Konfigurieren Sie neue Instanzen so, dass sie Folgendes erfordernIMDSv2:**
------
#### [ Amazon EC2 console ]
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Folgen Sie den Schritten, um [eine Instanz zu starten](ec2-launch-instance-wizard.md).
1. Erweitern Sie **Erweiterte Details** und wählen Sie als **Metadaten-Version** **nur V2 aus (Token erforderlich)**.
1. Überprüfen Sie im Bereich **Summary** (Übersicht) die Konfiguration Ihrer Instance und wählen Sie dann **Launch instance** (Instance starten) aus.
Weitere Informationen finden Sie unter [Konfigurieren der Instance beim Start](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-instance-settings).
------
#### [ AWS CLI ]
AWS CLI: Verwenden Sie den Befehl [run-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/run-instances.html) und geben Sie an, dass dies erforderlich IMDSv2 ist.
------
### Schritt 4: Stellen Sie IMDSv2 =required als Standard ein
Sie können IMDSv2 =required als Standardkonfiguration entweder auf Konto- oder Organisationsebene festlegen. Dadurch wird sichergestellt, dass alle neu gestarteten Instances automatisch so konfiguriert werden, dass sie Folgendes benötigen IMDSv2.
1. **Legen Sie den Standard auf Kontoebene fest:**
------
#### [ Amazon EC2 console ]
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 **Dashboard (Dashboard)**.
1. Wählen Sie auf der Karte **Kontoattribute** unter **Einstellungen** die Option **Datenschutz und Sicherheit** aus.
1. **Wählen Sie unter **IMDS-Standardeinstellungen** die Option Verwalten aus.**
1. **Wählen Sie für **Instance-Metadaten-Service** die Option Aktiviert aus.**
1. Wählen Sie für die **Metadatenversion** **nur V2 aus (Token erforderlich)**.
1. Wählen Sie **Aktualisieren** aus.
------
#### [ AWS CLI ]
Verwenden Sie den [modify-instance-metadata-defaults](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-instance-metadata-defaults.html)CLI-Befehl und geben Sie `--http-tokens required` und an`--http-put-response-hop-limit 2`.
------
Weitere Informationen finden Sie unter [IMDSv2 Als Standard für das Konto festlegen](configuring-IMDS-new-instances.md#set-imdsv2-account-defaults).
1. **Alternativ können Sie mithilfe einer deklarativen Richtlinie den Standard auf Organisationsebene festlegen:**
Verwenden Sie eine deklarative Richtlinie, um den Organisationsstandard für auf erforderlich festzulegen. IMDSv2 Eine Beispielrichtlinie finden Sie auf der Registerkarte **Instanz-Metadaten** im Abschnitt [Unterstützte deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) im *AWS Organizations Benutzerhandbuch*.
### Schritt 5: Erzwingen Sie, dass Instanzen Folgendes benötigen IMDSv2
Sobald Sie bestätigt haben, dass keine IMDSv1 Abhängigkeit von einer Ihrer Instances besteht, empfehlen wir Ihnen, dies für alle neuen Instances durchzusetzen IMDSv2 .
Verwenden Sie zur Durchsetzung eine der folgenden Optionen IMDSv2:
1. ** IMDSv2 Mit einer Kontoeigenschaft durchsetzen**
Sie können die Verwendung von für jedes Konto IMDSv2 auf Kontoebene erzwingen AWS-Region. Wenn diese Option erzwungen wird, können Instances nur gestartet werden, wenn sie so konfiguriert sind, dass sie dies erfordern IMDSv2. Diese Durchsetzung gilt unabhängig davon, wie die Instance oder das AMI konfiguriert ist. Weitere Informationen finden Sie unter [IMDSv2 Auf Kontoebene durchsetzen](configuring-IMDS-new-instances.md#enforce-imdsv2-at-the-account-level). Um diese Einstellung auf Organisationsebene anzuwenden, legen Sie eine deklarative Richtlinie fest. Eine Beispielrichtlinie finden Sie auf der Registerkarte **Instanz-Metadaten** im Abschnitt [Unterstützte deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html#declarative-policy-examples) im *AWS Organizations Benutzerhandbuch*.
Um zu verhindern, dass die Durchsetzung rückgängig gemacht wird, sollten Sie eine IAM-Richtlinie verwenden, um den Zugriff auf die API zu verhindern. [ModifyInstanceMetadataDefaults](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataDefaults.html) Weitere Informationen finden Sie unter [Verwenden einer IAM-Richtlinie](configuring-IMDS-new-instances.md#configure-IMDS-new-instances-iam-policy).
**Anmerkung**
Diese Einstellung ändert nicht die IMDS-Version vorhandener Instances, blockiert jedoch die Aktivierung vorhandener Instances, die derzeit IMDSv1 deaktiviert sind. IMDSv1
**Warnung**
Wenn die IMDSv2 Erzwingung aktiviert `httpTokens` ist und weder `required` in der Instance-Konfiguration beim Start noch in den Kontoeinstellungen oder in der AMI-Konfiguration auf festgelegt ist, schlägt der Instance-Start fehl. Informationen zur Problembehebung finden Sie unter [Das Starten einer IMDSv1 -fähigen Instance schlägt fehl](troubleshooting-launch.md#launching-an-imdsv1-enabled-instance-fails).
1. **Alternativ können Sie die IMDSv2 Erzwingung mithilfe der folgenden IAM- oder SCP-Bedingungsschlüssel erzwingen:**
+ `ec2:MetadataHttpTokens`
+ `ec2:MetadataHttpPutResponseHopLimit`
+ `ec2:MetadataHttpEndpoint`
Diese Bedingungsschlüssel steuern die Verwendung der [RunInstances[ModifyInstanceMetadataOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceMetadataOptions.html)](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html) APIs und der entsprechenden. CLIs Wenn eine Richtlinie erstellt wird und ein Parameter im API-Aufruf nicht mit dem in der Richtlinie über den Bedingungsschlüssel angegebenen Status übereinstimmt, schlägt der API- oder CLI-Aufruf mit einer `UnauthorizedOperation`-Antwort fehl.
Beispiele für IAM-Richtlinien finden Sie unter [Arbeiten mit Instance-Metadaten](ExamplePolicies_EC2.md#iam-example-instance-metadata).
# Zugriff auf den Instance-Metadaten-Service einschränken
Sie können die Verwendung lokaler Firewall-Regeln in Betracht ziehen, um den Zugriff auf den Instance Metadata Service (IMDS) für einige oder alle Prozesse zu deaktivieren.
Bei [Nitro-basierten Instances](instance-types.md#instance-hypervisor-type) kann das IMDS von Ihrem eigenen Netzwerk aus erreicht werden, wenn eine Netzwerk-Appliance innerhalb Ihrer VPC, beispielsweise ein virtueller Router, Pakete an die IMDS-Adresse weiterleitet und die Standard-[Quell-/Zielprüfung](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck) der Instance deaktiviert ist. Um zu verhindern, dass eine Quelle von außerhalb Ihrer VPC den IMDS erreicht, empfehlen wir Ihnen, die Konfiguration der Netzwerk-Appliance so zu ändern, dass Pakete mit der IPv4 Zieladresse des IMDS `169.254.169.254` und, falls Sie den IPv6 Endpunkt aktiviert haben, der IPv6 Adresse des IMDS verworfen werden. `[fd00:ec2::254]`
## IMDS-Zugriff für Linux-Instances einschränken
**Verwendung von iptables zur Einschränkung des Zugriffs**
Das folgende Beispiel verwendet Linux-iptables und sein `owner`-Modul, um zu verhindern, dass der Apache-Webserver (basierend auf seiner Standardinstallationsbenutzer-ID von `apache`) auf 169.254.169.254 zugreift. Es verwendet eine *Ablehnungsregel*, um alle Instanz-Metadatenanfragen (unabhängig davon, ob IMDSv1 oder IMDSv2) von Prozessen, die unter diesem Benutzer ausgeführt werden, abzulehnen.
```
$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner --uid-owner apache --jump REJECT
```
Oder Sie können erwägen, nur bestimmten Benutzern oder Gruppen Zugriff zu gewähren, indem Sie *Zulassungsregeln* verwenden. Zulassungsregeln können aus Sicherheitssicht einfacher zu verwalten sein, da Sie eine Entscheidung darüber treffen müssen, welche Software Zugriff auf Instance-Metadaten benötigt. Wenn Sie *Zulassungsregeln* verwenden, ist es weniger wahrscheinlich, dass Sie Software versehentlich den Zugriff auf den Metadaten-Service erlauben (auf den sie nicht zugreifen soll), wenn Sie später die Software oder Konfiguration auf einer Instance ändern. Sie können außerdem Gruppen mit Zulassungsregeln kombinieren, sodass Sie Benutzer zu einer zugelassenen Gruppe hinzufügen und aus dieser entfernen können, ohne die Firewall-Regel ändern zu müssen.
Das folgende Beispiel verhindert den Zugriff auf den IMDS durch alle Prozesse, mit Ausnahme von Prozessen, die im Benutzerkonto `trustworthy-user` ausgeführt werden.
```
$ sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner ! --uid-owner trustworthy-user --jump REJECT
```
**Anmerkung**
Um lokale Firewall-Regeln zu verwenden, müssen Sie die vorhergehenden Beispielbefehle an Ihre Bedürfnisse anpassen.
Standardmäßig sind iptables-Regeln nicht über Systemneustarts hinweg persistent. Sie können durch die Verwendung von Betriebssystemfeatures, die hier nicht beschrieben werden, persistent gestaltet werden.
Das iptables `owner`-Modul überprüft nur dann die Gruppenzugehörigkeit, wenn die Gruppe die Primärgruppe eines bestimmten lokalen Benutzers ist. Andere Gruppen werden nicht abgeglichen.
**Verwendung von PF oder IPFW zur Einschränkung des Zugriffs**
Wenn Sie FreeBSD oder OpenBSD verwenden, können Sie überlegen, PF oder IPFW zu verwenden. Die folgenden Beispiele beschränken den Zugriff auf den IMDS auf den Root-Benutzer.
**PF**
```
$ block out inet proto tcp from any to 169.254.169.254
```
```
$ pass out inet proto tcp from any to 169.254.169.254 user root
```
**IPFW**
```
$ allow tcp from any to 169.254.169.254 uid root
```
```
$ deny tcp from any to 169.254.169.254
```
**Anmerkung**
Die Reihenfolge der PF- und IPFW-Befehle ist von Bedeutung. PF verwendet standardmäßig die letzte übereinstimmende Regel und IPFW die erste übereinstimmende Regel.
## IMDS-Zugriff für Windows-Instances einschränken
**Verwenden der Windows-Firewall zur Zugriffsbeschränkung**
Im folgenden PowerShell Beispiel wird die integrierte Windows-Firewall verwendet, um zu verhindern, dass der Internet Information Server-Webserver (basierend auf seiner standardmäßigen Installationsbenutzer-ID von`NT AUTHORITY\IUSR`) auf 169.254.169.254 zugreift. Es verwendet eine *Ablehnungsregel*, um alle Instanz-Metadatenanforderungen (unabhängig davon, ob IMDSv1 oderIMDSv2) von Prozessen, die unter diesem Benutzer ausgeführt werden, abzulehnen.
```
PS C:\> $blockPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("NT AUTHORITY\IUSR")
PS C:\> $BlockPrincipalSID = $blockPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> $BlockPrincipalSDDL = "D:(A;;CC;;;$BlockPrincipalSID)"
PS C:\> New-NetFirewallRule -DisplayName "Block metadata service from IIS" -Action block -Direction out `
-Protocol TCP -RemoteAddress 169.254.169.254 -LocalUser $BlockPrincipalSDDL
```
Oder Sie können erwägen, nur bestimmten Benutzern oder Gruppen Zugriff zu gewähren, indem Sie *Zulassungsregeln* verwenden. Zulassungsregeln können aus Sicherheitssicht einfacher zu verwalten sein, da Sie eine Entscheidung darüber treffen müssen, welche Software Zugriff auf Instance-Metadaten benötigt. Wenn Sie *Zulassungsregeln* verwenden, ist es weniger wahrscheinlich, dass Sie Software versehentlich den Zugriff auf den Metadaten-Service erlauben (auf den sie nicht zugreifen soll), wenn Sie später die Software oder Konfiguration auf einer Instance ändern. Sie können außerdem Gruppen mit Zulassungsregeln kombinieren, sodass Sie Benutzer zu einer zugelassenen Gruppe hinzufügen und aus dieser entfernen können, ohne die Firewall-Regel ändern zu müssen.
Das folgende Beispiel verhindert den Zugriff auf Instance-Metadaten durch alle Prozesse, die als OS-Gruppe ausgeführt werden, die in der Variable `blockPrincipal` angegeben ist (in diesem Beispiel die Windows-Gruppe `Everyone`), mit Ausnahme der in `exceptionPrincipal` angegebenen Prozesse (in diesem Beispiel eine Gruppe namens `trustworthy-users`). Sie müssen für Prinzipale den Zugriff verweigern und ablehnen, da die Windows-Firewall im Gegensatz zur `! --uid-owner trustworthy-user`-Regel in Linux-iptables keinen Mechanismus zur Verfügung stellt, um nur einen bestimmten Prinzipal (Benutzer oder Gruppe) zuzulassen, indem alle anderen abgelehnt werden.
```
PS C:\> $blockPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("Everyone")
PS C:\> $BlockPrincipalSID = $blockPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> $exceptionPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("trustworthy-users")
PS C:\> $ExceptionPrincipalSID = $exceptionPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\> $PrincipalSDDL = "O:LSD:(D;;CC;;;$ExceptionPrincipalSID)(A;;CC;;;$BlockPrincipalSID)"
PS C:\> New-NetFirewallRule -DisplayName "Block metadata service for $($blockPrincipal.Value), exception: $($exceptionPrincipal.Value)" -Action block -Direction out `
-Protocol TCP -RemoteAddress 169.254.169.254 -LocalUser $PrincipalSDDL
```
**Anmerkung**
Um lokale Firewall-Regeln zu verwenden, müssen Sie die vorhergehenden Beispielbefehle an Ihre Bedürfnisse anpassen.
**Verwenden von netsh-Regeln zur Zugriffsbeschränkung**
Sie können erwägen, die gesamte Software mit `netsh`-Regeln zu blockieren. Diese sind jedoch viel weniger flexibel.
```
C:\> netsh advfirewall firewall add rule name="Block metadata service altogether" dir=out protocol=TCP remoteip=169.254.169.254 action=block
```
**Anmerkung**
Um lokale Firewall-Regeln zu verwenden, müssen Sie die vorhergehenden Beispielbefehle an Ihre Bedürfnisse anpassen.
`netsh`-Regeln müssen von einer Eingabeaufforderung mit erhöhten Rechten aus festgelegt werden und können nicht so konfiguriert werden, dass sie bestimmte Prinzipale verweigern oder zulassen.