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.
# 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-based Instances kann das IMDS von Ihrem eigenen Netzwerk aus erreicht werden](instance-types.md#instance-hypervisor-type), wenn eine Netzwerk-Appliance in Ihrer VPC, z. B. ein virtueller Router, Pakete an die IMDS-Adresse weiterleitet und die [ source/destination Standardprüfung für die Instance ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html#EIP_Disable_SrcDestCheck) deaktiviert ist. Um zu verhindern, dass eine Quelle außerhalb Ihrer VPC IMDS erreicht, empfehlen wir, die Konfiguration der Netzwerk-Appliance so zu ändern, dass Pakete mit der Ziel-IPv4-Adresse von IMDS `169.254.169.254` und, sollten Sie den IPv6-Endpunkt aktiviert haben, die IPv6-Adresse von IMDS `[fd00:ec2::254]`, gelöscht werden.
## 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 *Verweigerungsregel*, um alle Instance-Metadatenanfragen (ob IMDSv1 oder IMDSv2) von jedem Prozess abzulehnen, der als dieser Benutzer ausgeführt wird.
```
$ 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 Standard-Installationsbenutzer-ID von`NT AUTHORITY\IUSR`) auf 169.254.169.254 zugreift. Es verwendet eine *Verweigerungsregel*, um alle Instance-Metadatenanfragen (ob IMDSv1 oder IMDSv2) von jedem Prozess abzulehnen, der als dieser Benutzer ausgeführt wird.
```
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.