AWS-Kochbuch

Kapitel 1. Sicherheit

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

1.0 Einleitung

Die durchschnittlichen Kosten einer Datenschutzverletzung erreichten im Jahr 2021 einen neuen Höchststand von 4,24 Millionen USD, wie der IBM/Ponemon Institute Report berichtet. Wenn du dich dafür entscheidest, deine Anwendungen in der Cloud zu betreiben, vertraust du darauf, dass AWS eine sichere Infrastruktur für Cloud-Dienste bereitstellt, damit du dich auf deine eigenen Innovationen und wertschöpfenden Aktivitäten konzentrieren kannst.

Aber für die Sicherheit in der Cloud sind du und AWS gemeinsam verantwortlich. Du bist für die Konfiguration von Dingen wie AWS Identity and Access Management (IAM)-Richtlinien, Amazon EC2-Sicherheitsgruppen und hostbasierte Firewalls verantwortlich. Mit anderen Worten: Die Sicherheit der Hardware- und Software-Plattform, aus der die AWS-Cloud besteht, liegt in der Verantwortung von AWS. Für die Sicherheit der Software und der Konfigurationen, die du in deinem AWS-Konto bzw. deinen AWS-Konten implementierst, bist du selbst verantwortlich.

Wenn du Cloud-Ressourcen in AWS bereitstellst und konfigurierst, ist es wichtig, die Sicherheitseinstellungen zu kennen, die für die Aufrechterhaltung einer sicheren Umgebung erforderlich sind. Die Rezepte in diesem Kapitel enthalten bewährte Methoden und Anwendungsfälle, die sich auf die Sicherheit konzentrieren. Da Sicherheit ein Teil von allem ist, wirst du diese Rezepte in Verbindung mit anderen Rezepten und Kapiteln in diesem Buch verwenden. Du wirst zum Beispiel sehen, wie der AWS Systems Manager Session Manager in diesem Buch verwendet wird, wenn du dich mit deinen EC2-Instanzen verbindest. Diese grundlegenden Sicherheitsrezepte geben dir die Werkzeuge an die Hand, die du brauchst, um sichere Lösungen auf AWS zu entwickeln.

Zusätzlich zu den Inhalten in diesem Kapitel gibt es viele großartige Ressourcen, mit denen du tiefer in Sicherheitsthemen bei AWS eintauchen kannst. Der Vortrag"The Fundamentals of AWS Cloud Security", der auf der AWS-Sicherheitskonferenz re:Inforce 2019 gehalten wurde, gibt einen guten Überblick. Ein weiterführender Vortrag, "Encryption: It Was the Best of Controls, It Was the Worst of Controls", von der AWS re:Invent, befasst sich mit Verschlüsselungsszenarien, die im Detail erklärt werden.

Tipp

AWS veröffentlicht einen Leitfaden mit bewährten Methoden zur Sicherung deines Kontos, und alle Inhaber eines AWS-Kontos sollten mit den bewährten Methoden vertraut sein, da diese ständig weiterentwickelt werden.

Warnung

In diesem Kapitel behandeln wir wichtige Sicherheitsthemen. Es ist nicht möglich, alle Themen zu behandeln, da die Liste der Services und Konfigurationen (in Bezug auf die Sicherheit bei AWS) ständig wächst und sich weiterentwickelt. AWS hält seine Webseite mit den bewährten Methoden für Sicherheit, Identität und Compliance auf dem neuesten Stand.

Konfiguration der Arbeitsstation

Du brauchst ein paar Dinge, um für die Rezepte in diesem Kapitel gerüstet zu sein.

Allgemeines Setup

Folge den "Allgemeinen Schritten zur Einrichtung der Workstation für CLI-Rezepte", um deine Konfiguration zu überprüfen und die erforderlichen Umgebungsvariablen einzurichten. Anschließend klonst du das Code-Repository des Kapitels:

git clone https://github.com/AWSCookbook/Security

1.1 Erstellen und Annehmen einer IAM-Rolle für den Entwicklerzugang

Problem

Um sicherzustellen, dass du nicht immer administrative Berechtigungen verwendest, musst du eine IAM-Rolle für die Entwicklung in deinem AWS-Konto erstellen.

Lösung

Erstelle eine Rolle mit einer IAM-Richtlinie, die es ermöglicht, die Rolle später zu übernehmen. Füge der Rolle die von AWS verwaltete PowerUserAccess IAM-Richtlinie hinzu (siehe Abbildung 1-1).

Abbildung 1-1. Rolle erstellen, Richtlinie anhängen und Rolle übernehmen

Steps

1. Erstelle eine Datei namens assume-role-policy-template.json mit folgendem Inhalt. Damit kann ein IAM-Principal die Rolle übernehmen, die du als Nächstes erstellen wirst (die Datei wird im Repository bereitgestellt):

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "PRINCIPAL_ARN"
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }

   Tipp

   Wenn du einen IAM-Benutzer verwendest und diesen löschst und neu anlegst, funktioniert diese Richtlinie nicht mehr, da der IAM-Dienst das Risiko einer Privilegienerweiterung eindämmt. Weitere Informationen dazu findest du im Hinweis in der IAM-Dokumentation.

2. Rufe den ARN für ab, deinen Benutzer und setze ihn als Variable:

   PRINCIPAL_ARN=$(aws sts get-caller-identity --query Arn --output text)

3. Verwenden Sie den Befehl sed, um die PRINCIPAL_ARN in der Datei assume-role-policy-template.json und generiere die Datei assume-role-policy.json:

   sed -e "s|PRINCIPAL_ARN|${PRINCIPAL_ARN}|g" \
        assume-role-policy-template.json > assume-role-policy.json

4. Erstelle eine Rolle und gib die Datei mit den Rollenrichtlinien an:

   ROLE_ARN=$(aws iam create-role --role-name AWSCookbook101Role \
        --assume-role-policy-document file://assume-role-policy.json \
        --output text --query Role.Arn)

5. Verbinde die AWS verwaltete PowerUserAccess Richtlinie mit der Rolle:

   aws iam attach-role-policy --role-name AWSCookbook101Role \
        --policy-arn arn:aws:iam::aws:policy/PowerUserAccess

   Hinweis

   AWS stellt Zugriffsrichtlinien für gängige Auftragsfunktionen zur Verfügung, um dir den Zugang zu erleichtern. Diese Richtlinien können ein guter Ausgangspunkt sein, um den Benutzerzugriff auf dein Konto für bestimmte Arbeitsfunktionen zu delegieren; es ist jedoch am besten, für jeden Zugriffsbedarf eine Richtlinie mit den geringsten Rechten für deine eigenen spezifischen Anforderungen zu definieren.

Validierungsprüfungen

Nimm die Rolle an:

aws sts assume-role --role-arn $ROLE_ARN \
     --role-session-name AWSCookbook101

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

{
  "Credentials": {
    "AccessKeyId": "<snip>",
    "SecretAccessKey": "<snip>",
    "SessionToken": "<snip>",
    "Expiration": "2021-09-12T23:34:56+00:00"
  },
  "AssumedRoleUser": {
    "AssumedRoleId": "EXAMPLE:AWSCookbook101",
    "Arn": "arn:aws:sts::11111111111:assumed-role/AWSCookbook101Role/AWSCookbook101"
  }
}

Tipp

Die AssumeRole API gibt einen Satz temporärer Anmeldeinformationen für eine Rollensitzung vom AWS Security Token Service (STS) an den Aufrufer zurück, sofern die Berechtigungen in der AssumeRole Richtlinie für die Rolle dies zulassen. Alle IAM-Rollen haben eine AssumeRole Richtlinie, die mit ihnen verknüpft ist. Du kannst die Ausgabe dieser Richtlinie verwenden, um die Anmeldeinformationen für die AWS CLI zu konfigurieren, AccessKey, SecretAccessKey und SessionToken als Umgebungsvariablen festzulegen und die Rolle in der AWS-Konsole mit der Funktion Switch Role zu übernehmen. Wenn deine Anwendungen AWS-API-Aufrufe tätigen müssen, übernimmt das AWS SDK für die Programmiersprache deiner Wahl diese Aufgabe für sie.

Aufräumen

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Diskussion

Die Verwendung von Administratorrechten für routinemäßige Entwicklungsaufgaben ist keine bewährte Methode für die Sicherheit. Die Vergabe nicht benötigter Berechtigungen kann dazu führen, dass nicht autorisierte Aktionen durchgeführt werden. Die Verwendung der PowerUserAccess AWS verwalteten Richtlinie für Entwicklungszwecke ist zu Beginn eine bessere Alternative als die Verwendung von AdministratorAccess. Später solltest du eine eigene , vom Kunden verwaltete Richtlinie definieren, die nur die spezifischen Aktionen für deinen Bedarf zulässt. Wenn du dich zum Beispiel häufig anmelden musst, um den Status deiner EC2-Instances zu überprüfen, kannst du eine schreibgeschützte Richtlinie für diesen Zweck erstellen und sie an eine Rolle anhängen. Genauso kannst du eine Rolle für den Zugriff auf die Rechnungsstellung erstellen und sie nur für den Zugriff auf die AWS Billing-Konsole verwenden. Je mehr du das Prinzip der geringsten Privilegien anwendest, desto mehr wird die Sicherheit zu einem natürlichen Bestandteil deiner Arbeit.

Du hast in diesem Rezept einen IAM-Benutzer verwendet, um die Schritte auszuführen. Wenn du ein AWS-Konto verwendest, das den Verbund für den Zugriff nutzt (z. B. ein Sandbox- oder Entwicklungs-AWS-Konto bei deinem Arbeitgeber), solltest du statt eines IAM-Benutzers temporäre Anmeldeinformationen aus dem AWS STS verwenden. Bei dieser Art des Zugriffs werden zeitbasierte Token verwendet, die nach einer gewissen Zeit ablaufen, und keine "langlebigen" Anmeldeinformationen wie Zugangsschlüssel oder Passwörter. Als du die AssumeRole in den Validierungsschritten durchgeführt hast, hast du den STS-Dienst für temporäre Anmeldeinformationen aufgerufen. Um dir bei häufigen AssumeRole Operationen zu helfen, unterstützt die AWS CLI benannte Profile, die automatisch deine temporären Zugangsdaten für deine Rolle annehmen und aktualisieren können, wenn du den Parameter role_arn im benannten Profil angibst.

Tipp

Du kannst die Multi-Faktor-Authentifizierung (MFA) als Bedingung in den von dir erstellten AssumeRole Richtlinien verlangen. Dadurch kann die Rolle nur von einer Identität übernommen werden, die mit MFA authentifiziert wurde. Weitere Informationen darüber, wie du MFA für AssumeRole verlangst, findest du im Support-Dokument.

Siehe Rezept 9.4, um einen Alarm zu erstellen, wenn ein Root-Login auftritt.

Tipp

Du kannst kontoübergreifenden Zugriff auf deine AWS-Ressourcen gewähren. Die Ressource, die du in der Richtlinie in diesem Rezept definierst, verweist auf das AWS-Konto und den Prinzipal innerhalb dieses Kontos, dem du den Zugriff gewähren möchtest. Du solltest immer eine ExternalID verwenden, wenn du den kontoübergreifenden Zugriff aktivierst. Weitere Informationen findest du in der offiziellen Anleitung für den kontoübergreifenden Zugriff.

Herausforderung

Erstelle zusätzliche IAM-Rollen für jede der AWS verwalteten Richtlinien für Auftragsfunktionen (z. B. Rechnungsstellung, Datenbankadministrator, Netzwerk usw.).

1.2 Erstellen einer Least Privilege IAM-Richtlinie auf der Grundlage von Zugriffsmustern

Problem

Du möchtest den Zugriff mit den geringsten Rechten für deinen Benutzer einrichten und die Berechtigungen so einschränken, dass du nur auf die Services, Ressourcen und Aktionen zugreifen kannst, die du in deinem AWS-Konto nutzen musst.

Lösung

Verwende den IAM Access Analyzer in der IAM-Konsole, um eine IAM-Richtlinie auf der Grundlage der CloudTrail-Aktivitäten in deinem AWS-Konto zu erstellen, wie in Abbildung 1-2 dargestellt.

Abbildung 1-2. IAM Access Analyzer Arbeitsablauf

Voraussetzung

• CloudTrail-Protokollierung aktiviert für dein Konto zu einem konfigurierten S3-Bucket (siehe Rezept 9.3)

Steps

1. Navigiere zur IAM-Konsole und wähle deine IAM-Rolle oder den IAM-Benutzer aus, für den du eine Richtlinie erstellen möchtest.

2. Scrolle auf der Registerkarte "Berechtigungen" (die standardmäßig aktive Registerkarte bei der Anzeige deines Schulleiters) nach unten, erweitere den Abschnitt "Richtlinie auf der Grundlage von CloudTrail-Ereignissen generieren" und klicke auf die Schaltfläche "Richtlinie generieren".

   Tipp

   Um einen schnellen Überblick über die AWS-Services zu erhalten, auf die dein Principal zugegriffen hat, klicke auf die Registerkarte Access Advisor und sieh dir die Service-Liste und die Zugriffszeit an. Der IAM Access Advisor ist zwar nicht so leistungsfähig wie der Access Analyzer, aber er kann bei der Überprüfung oder Fehlerbehebung von IAM-Principals in deinem AWS-Konto hilfreich sein.

3. Wähle den Zeitraum der CloudTrail-Ereignisse, die du auswerten möchtest, wähle deinen CloudTrail-Trail, wähle deine Region (oder wähle "Alle Regionen") und wähle "Eine neue Dienstrolle erstellen und verwenden". Der IAM Access Analyzer erstellt eine Rolle für den Dienst, die für den Lesezugriff auf den von dir ausgewählten Trail verwendet wird. Klicke abschließend auf "Richtlinie generieren". Siehe Abbildung 1-3 für ein Beispiel.

   

   Abbildung 1-3. Generierung einer Richtlinie in der IAM Access Analyzer Konfiguration

   Hinweis

   Die Erstellung der Rolle kann bis zu 30 Sekunden dauern. Sobald die Rolle erstellt ist, dauert die Erstellung der Richtlinie eine gewisse Zeit, die davon abhängt, wie viele Aktivitäten in deinem CloudTrail-Trail vorhanden sind.

4. Sobald die Analyse abgeschlossen ist, scrolle zum Ende der Registerkarte "Berechtigungen" und klicke auf "Generierte Richtlinie anzeigen" (siehe Abbildung 1-4).

   

   Abbildung 1-4. Ansicht der erstellten Richtlinie

5. Klicke auf Weiter und du siehst eine generierte Richtlinie im JSON-Format, die auf der Aktivität deines IAM-Principals basiert. Du kannst diese Richtlinie in der Benutzeroberfläche bearbeiten, wenn du zusätzliche Berechtigungen hinzufügen möchtest. Klicke erneut auf Weiter, wähle einen Namen und du kannst die erstellte Richtlinie als IAM-Richtlinie einsetzen.

   Du solltest eine generierte IAM-Richtlinie in der IAM-Konsole sehen, die dieser ähnelt:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "access-analyzer:ListPolicyGenerations",
           "cloudtrail:DescribeTrails",
           "cloudtrail:LookupEvents",
           "iam:GetAccountPasswordPolicy",
           "iam:GetAccountSummary",
           "iam:GetServiceLastAccessedDetails",
           "iam:ListAccountAliases",
           "iam:ListGroups",
           "iam:ListMFADevices",
           "iam:ListUsers",
           "s3:ListAllMyBuckets",
           "sts:GetCallerIdentity"
         ],
         "Resource": "*"
       }, ...
   }

Validierungsprüfungen

Erstelle einen neuen IAM-Benutzer oder eine neue IAM-Rolle und verknüpfe die neu erstellte IAM-Richtlinie mit ihr. Führe eine von der Richtlinie gewährte Aktion durch, um zu überprüfen, ob die Richtlinie deinem IAM-Prinzipal erlaubt, die von dir benötigten Aktionen durchzuführen.

Diskussion

Du solltest immer versuchen, IAM-Richtlinien mit den geringsten Privilegien zu implementieren, wenn du sie für deine Nutzer und Anwendungen aufstellst. Oftmals weißt du zu Beginn nicht genau, welche Berechtigungen du benötigst. Mit dem IAM Access Analyzer kannst du damit beginnen, deinen Nutzern und Anwendungen in einer Entwicklungsumgebung einen größeren Geltungsbereich einzuräumen, die CloudTrail-Protokollierung zu aktivieren(Rezept 9.3) und dann den IAM Access Analyzer zu starten, nachdem du ein Zeitfenster hast, das die übliche Aktivität gut abbildet (wähle diesen Zeitraum in der Access Analyzer-Konfiguration wie in Schritt 3). Die erstellte Richtlinie enthält alle erforderlichen Berechtigungen, damit deine Anwendung oder deine Nutzer so arbeiten können, wie sie es in dem von dir analysierten Zeitraum getan haben. hilft dir dabei, das Prinzip der geringsten Rechte umzusetzen.

Hinweis

Du solltest dir auch die Liste der Dienste ansehen, die Access Analyzer unterstützt.

Herausforderung

Verwende den IAM-Richtlinien-Simulator (siehe Rezept 1.4) für die erstellte Richtlinie, um zu überprüfen, ob die Richtlinie den benötigten Zugriff enthält.

1.3 Durchsetzung von IAM-Benutzerpasswortrichtlinien in deinem AWS-Konto

Hinweis

Besonderen Dank an Gaurav Raje für seinen Beitrag zu diesem Rezept.

Problem

Deine Sicherheitsrichtlinie schreibt vor, dass du für alle Benutzer deines AWS-Kontos eine Passwortrichtlinie durchsetzen musst. Die Passwortrichtlinie legt eine 90-tägige Gültigkeitsdauer fest, und die Passwörter müssen aus mindestens 32 Zeichen bestehen, darunter Klein- und Großbuchstaben, Zahlen und Symbole.

Lösung

Lege eine Passwortrichtlinie für IAM-Benutzer in deinem AWS-Konto fest. Erstelle eine IAM-Gruppe und einen IAM-Benutzer und füge den Benutzer zu der Gruppe hinzu, um zu überprüfen, ob die Richtlinie durchgesetzt wird (siehe Abbildung 1-5).

Abbildung 1-5. Verwendung von Passwortrichtlinien mit IAM-Benutzern

Hinweis

Wenn deine Organisation über ein zentrales Benutzerverzeichnis verfügt, empfehlen wir dir, Identitätsföderation zu verwenden, um mit AWS Single Sign-On (SSO) auf deine AWS-Konten zuzugreifen, anstatt einzelne IAM-Benutzer und -Gruppen zu erstellen. Mit Federation kannst du einen Identitätsanbieter (IdP) nutzen, bei dem du bereits Benutzer und Gruppen verwaltest. AWS veröffentlicht einen Leitfaden, in dem die verfügbaren Konfigurationen für den föderierten Zugriff erläutert werden. Du kannst Rezept 9.6 befolgen, um AWS SSO für dein Konto zu aktivieren, auch wenn du keinen IdP zur Verfügung hast (AWS SSO bietet ein Verzeichnis, das du standardmäßig verwenden kannst).

Steps

1. Lege mit der AWS CLI eine IAM-Passwortrichtlinie fest, die Klein- und Großbuchstaben, Symbole und Zahlen erfordert. Die Richtlinie sollte eine Mindestlänge von 32 Zeichen, ein maximales Passwortalter von 90 Tagen und die Verhinderung der Wiederverwendung von Passwörtern vorsehen:

   aws iam update-account-password-policy \
        --minimum-password-length 32 \
        --require-symbols \
        --require-numbers \
        --require-uppercase-characters \
        --require-lowercase-characters \
        --allow-users-to-change-password \
        --max-password-age 90 \
        --password-reuse-prevention true

2. Erstelle eine IAM-Gruppe:

   aws iam create-group --group-name AWSCookbook103Group

   Du solltest eine ähnliche Ausgabe wie die folgende sehen:

   {
     "Group": {
       "Path": "/",
       "GroupName": "AWSCookbook103Group",
       "GroupId": "<snip>",
       "Arn": "arn:aws:iam::111111111111:group/AWSCookbook103Group",
       "CreateDate": "2021-11-06T19:26:01+00:00"
     }
   }

3. Hänge die Richtlinie ReadOnlyAccess an die Gruppe an:

   aws iam attach-group-policy --group-name AWSCookbook103Group \
        --policy-arn arn:aws:iam::aws:policy/AWSBillingReadOnlyAccess

   Tipp

   Es ist am besten, Richtlinien an Gruppen und nicht direkt an Benutzer zu knüpfen. Wenn die Zahl der Nutzer/innen wächst, ist es einfacher, IAM-Gruppen zu verwenden, um Berechtigungen zu delegieren und die Verwaltung zu erleichtern. Das hilft auch bei der Einhaltung von Standards wie CIS Level 1.

4. Erstelle einen IAM-Benutzer:

   aws iam create-user --user-name awscookbook103user

   Du solltest eine ähnliche Ausgabe wie die folgende sehen:

   {
     "User": {
       "Path": "/",
       "UserName": "awscookbook103user",
       "UserId": "<snip>",
       "Arn": "arn:aws:iam::111111111111:user/awscookbook103user",
       "CreateDate": "2021-11-06T21:01:47+00:00"
     }
   }

5. Verwende den Secrets Manager, um ein Passwort zu generieren, das mit deiner Passwortrichtlinie übereinstimmt:

   RANDOM_STRING=$(aws secretsmanager get-random-password \
   --password-length 32 --require-each-included-type \
   --output text \
   --query RandomPassword)

6. Erstelle ein Login-Profil für , in dem du ein Passwort angibst:

   aws iam create-login-profile --user-name awscookbook103user \
        --password $RANDOM_STRING

   Du solltest eine ähnliche Ausgabe wie die folgende sehen:

   {
     "LoginProfile": {
       "UserName": "awscookbook103user",
       "CreateDate": "2021-11-06T21:11:43+00:00",
       "PasswordResetRequired": false
     }
   }

7. Füge den Benutzer zu der Gruppe hinzu, die du für den reinen Zugriff auf die Abrechnung erstellt hast:

   aws iam add-user-to-group --group-name AWSCookbook103Group \
        --user-name awscookbook103user

Validierungsprüfungen

Überprüfe, ob die von dir festgelegte Kennwortrichtlinie jetzt aktiv ist:

aws iam get-account-password-policy

Du solltest eine ähnliche Ausgabe sehen wie:

{
  "PasswordPolicy": {
    "MinimumPasswordLength": 32,
    "RequireSymbols": true,
    "RequireNumbers": true,
    "RequireUppercaseCharacters": true,
    "RequireLowercaseCharacters": true,
    "AllowUsersToChangePassword": true,
    "ExpirePasswords": true,
    "MaxPasswordAge": 90,
    "PasswordReusePrevention": 1
  }
}

Versuche, über die AWS CLI einen neuen Benutzer mit einem Passwort zu erstellen, das gegen die Passwortrichtlinie verstößt. AWS wird dir nicht erlauben, einen solchen Benutzer zu erstellen:

aws iam create-user --user-name awscookbook103user2

Verwende den Secrets Manager, um ein Passwort zu generieren, das nicht mit deiner Passwortrichtlinie übereinstimmt:

RANDOM_STRING2=$(aws secretsmanager get-random-password \
--password-length 16 --require-each-included-type \
--output text \
--query RandomPassword)

Erstelle ein Anmeldeprofil für den Benutzer, in dem das Passwort angegeben ist:

aws iam create-login-profile --user-name awscookbook103user2 \
--password $RANDOM_STRING2

Dieser Befehl sollte fehlschlagen und du solltest eine ähnliche Ausgabe wie diese sehen:

An error occurred (PasswordPolicyViolation) when calling the CreateLoginProfile
operation: Password should have a minimum length of 32

Aufräumen

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Diskussion

Für Benutzer, die sich mit Passwörtern anmelden, können Administratoren in AWS Passwortrichtlinien für ihre Konten durchsetzen, die den Sicherheitsanforderungen deiner Organisation entsprechen. Auf diese Weise können Administratoren sicherstellen, dass einzelne Nutzer/innen die Sicherheit der Organisation nicht gefährden, indem sie schwache Passwörter wählen oder ihre Passwörter nicht regelmäßig ändern.

Tipp

Die Multi-Faktor-Authentifizierung wird für IAM-Benutzer empfohlen. Du kannst ein softwarebasiertes virtuelles MFA-Gerät oder ein Hardware-Gerät für einen zweiten Faktor für IAM-Benutzer verwenden. AWS führt eine aktualisierte Liste der unterstützten Geräte.

Die Multi-Faktor-Authentifizierung ist eine großartige Möglichkeit, eine weitere Sicherheitsebene zu der bestehenden passwortbasierten Sicherheit hinzuzufügen. Sie kombiniert das, was du weißt, mit dem, was du hast. Wenn also dein Passwort einem böswilligen Dritten in die Hände fällt, braucht er den zusätzlichen Faktor, um sich zu authentifizieren.

Herausforderung

Lade den Berechtigungsbericht herunter, um die IAM-Benutzer und das Passwortalter in deinem Konto zu analysieren.

1.4 Testen von IAM-Richtlinien mit dem IAM-Richtlinien-Simulator

Problem

Du hast eine IAM-Richtlinie, die du gerne einsetzen würdest, aber du möchtest ihre Wirksamkeit zunächst testen.

Lösung

Verbinde eine IAM-Richtlinie mit einer IAM-Rolle und simuliere Aktionen mit dem IAM-Richtlinien-Simulator, wie in Abbildung 1-6 gezeigt.

Abbildung 1-6. Simulieren von IAM-Richtlinien, die einer IAM-Rolle zugeordnet sind

Steps

1. Erstelle eine Datei namens assume-role-policy.json mit folgendem Inhalt (die Datei wird im Repository bereitgestellt):

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Service": "ec2.amazonaws.com"
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }

2. Erstelle eine IAM-Rolle mithilfe der Datei assume-role-policy.json:

   aws iam create-role --assume-role-policy-document \
        file://assume-role-policy.json --role-name AWSCookbook104IamRole

   Du solltest eine ähnliche Ausgabe wie die folgende sehen:

   {
     "Role": {
     "Path": "/",
     "RoleName": "AWSCookbook104IamRole",
     "RoleId": "<<UniqueID>>",
     "Arn": "arn:aws:iam::111111111111:role/AWSCookbook104IamRole",
     "CreateDate": "2021-09-22T23:37:44+00:00",
     "AssumeRolePolicyDocument": {
       "Version": "2012-10-17",
       "Statement": [
       ...

3. Füge die von IAM verwaltete Richtlinie für AmazonEC2ReadOnlyAccess der IAM-Rolle hinzu:

   aws iam attach-role-policy --role-name AWSCookbook104IamRole \
        --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

Tipp

Eine Liste aller Aktionen, Ressourcen und Bedingungsschlüssel für EC2 findest du in diesem AWS-Artikel. Die globalen IAM-Bedingungskontextschlüssel sind auch bei der Erstellung von fein abgestuften Richtlinien nützlich.

Validierungsprüfungen

Simuliere die Auswirkungen der von dir verwendeten IAM-Richtlinie, indem du verschiedene Arten von Aktionen für den EC2-Dienst testest.

Teste die Aktion ec2:CreateInternetGateway:

aws iam simulate-principal-policy \
     --policy-source-arn arn:aws:iam::$AWS_ACCOUNT_ARN:role/AWSCookbook104IamRole \
     --action-names ec2:CreateInternetGateway

Du solltest eine ähnliche Ausgabe wie die folgende sehen (beachte die EvalDecision):

{
  "EvaluationResults": [
  {
    "EvalActionName": "ec2:CreateInternetGateway",
    "EvalResourceName": "*",
    "EvalDecision": "implicitDeny",
    "MatchedStatements": [],
    "MissingContextValues": []
  }
  ]
}

Hinweis

Da du der Rolle in diesem Rezept nur die von AWS verwaltete AmazonEC2ReadOnlyAccess IAM-Richtlinie zugewiesen hast, wird die Aktion CreateInternetGateway implizit abgelehnt. Das ist das erwartete Verhalten. AmazonEC2ReadOnlyAccess gewährt keine "create"-Fähigkeiten für den EC2-Service.

Teste die Aktion ec2:DescribeInstances:

aws iam simulate-principal-policy \
     --policy-source-arn arn:aws:iam::$AWS_ACCOUNT_ARN:role/AWSCookbook104IamRole \
     --action-names ec2:DescribeInstances

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

{
  "EvaluationResults": [
  {
    "EvalActionName": "ec2:DescribeInstances",
    "EvalResourceName": "*",
    "EvalDecision": "allowed",
    "MatchedStatements": [
      {
      "SourcePolicyId": "AmazonEC2ReadOnlyAccess",
      "SourcePolicyType": "IAM Policy",
      "StartPosition": {
        "Line": 3,
        "Column": 17
      },
      "EndPosition": {
        "Line": 8,
        "Column": 6
      }
      }
    ],
    "MissingContextValues": []
  }
  ]
}

Hinweis

Die Richtlinie AmazonEC2ReadOnlyAccess erlaubt Leseoperationen auf dem EC2-Dienst, sodass die Operation DescribeInstances erfolgreich ist, wenn du diese Aktion simulierst.

Aufräumen

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Diskussion

MitIAM-Richtlinien kannst du Berechtigungen für die Verwaltung des Zugriffs in AWS festlegen. Richtlinien können mit Principals verknüpft werden, mit denen du Ressourcen, Benutzern, Gruppen und Services Berechtigungen erteilen (oder verweigern) kannst. Als bewährte Methode zur Gewährleistung der Sicherheit ist es immer am besten, wenn du deine Richtlinien auf die minimal erforderlichen Berechtigungen beschränkst. Der IAM-Richtlinien-Simulator kann bei der Erstellung und Verwaltung deiner eigenen IAM-Richtlinien für den am wenigsten privilegierten Zugang sehr hilfreich sein.

Der IAM-Richtlinien-Simulator bietet auch eine Weboberfläche, mit der du IAM-Richtlinien testen und Fehler beheben kannst, um die Auswirkungen der von dir definierten Richtlinien zu verstehen. Du kannst alle Richtlinien oder eine Teilmenge der Richtlinien testen, die du mit Benutzern, Gruppen und Rollen verknüpft hast.

Tipp

Der IAM-Richtlinien-Simulator kann dir helfen, die Auswirkungen der folgenden Punkte zu simulieren:

• Identitätsbasierte Maßnahmen

• IAM-Berechtigungsgrenzen

• AWS Organizations Service Control Policies (SCPs)

• Ressourcenbasierte Politik

Nachdem du die Ergebnisse des Richtliniensimulators überprüft hast, kannst du zusätzliche Anweisungen zu deinen Richtlinien hinzufügen, die entweder dein Problem lösen (aus der Sicht der Fehlerbehebung) oder neu erstellte Richtlinien mit Benutzern, Gruppen und Rollen verknüpfen, mit der Gewissheit, dass der Nettoeffekt der Richtlinie das ist, was du beabsichtigt hast.

Hinweis

Damit du einfach IAM-Richtlinien von Grund auf neu erstellen kannst, bietet AWS den AWS Policy Generator.

Herausforderung

Simuliere die Auswirkung einer Erlaubnis grenze auf einen IAM-Prinzipal (siehe Rezept 1.5).

1.5 Delegieren von IAM-Verwaltungsfunktionen mithilfe von Berechtigungsgrenzen

Problem

Du musst den Teammitgliedern die Möglichkeit geben, Lambda-Funktionen einzusetzen und IAM-Rollen für sie zu erstellen. Du musst die effektiven Berechtigungen der erstellten IAM-Rollen so einschränken, dass sie nur die für die Funktion erforderlichen Aktionen zulassen.

Lösung

Erstelle eine Richtlinie für die Berechtigungsgrenze, erstelle eine IAM-Rolle für Lambda-Entwickler, erstelle eine IAM-Richtlinie, die die Richtlinie für die Berechtigungsgrenze festlegt, und füge die Richtlinie der von dir erstellten Rolle hinzu. Abbildung 1-7 veranschaulicht die effektiven Berechtigungen der identitätsbasierten Richtlinie mit der Berechtigungsgrenze.

Abbildung 1-7. Effektive Berechtigungen einer identitätsbasierten Richtlinie mit Berechtigungsgrenze

Voraussetzung

• Ein IAM-Benutzer oder eine föderierte Identität für dein AWS-Konto mit administrativen Rechten (folge dem AWS-Leitfaden zur Erstellung deines ersten IAM-Admin-Benutzers und deiner Benutzergruppe).

Steps

1. Erstelle eine Datei namens assume-role-policy-template.json mit folgendem Inhalt (die Datei wird im Repository bereitgestellt):

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "PRINCIPAL_ARN"
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }

2. Rufe den ARN für deinen Benutzer ab und setze ihn als Variable:

   PRINCIPAL_ARN=$(aws sts get-caller-identity --query Arn --output text)

3. Ersetze mit dem Befehl sed PRINCIPAL_ARN in der Datei assume-role-policy-template.json, die wir im Repository bereitgestellt haben, und generiere die Datei assume-role-policy.json:

   sed -e "s|PRINCIPAL_ARN|${PRINCIPAL_ARN}|g" \
   assume-role-policy-template.json > assume-role-policy.json

   Hinweis

   Für die Zwecke dieses Rezepts legst du den erlaubten IAM-Prinzipal auf deinen eigenen Benutzer (Benutzer 1) fest. Um den delegierten Zugriff zu testen, würdest du den IAM-Prinzipal auf einen anderen Wert setzen.

4. Erstelle eine Rolle und gib die Datei mit den Rollenrichtlinien an:

   ROLE_ARN=$(aws iam create-role --role-name AWSCookbook105Role \
        --assume-role-policy-document file://assume-role-policy.json \
        --output text --query Role.Arn)

5. Erstelle eine JSON-Datei mit dem Namen boundary-template.json mit folgendem Inhalt. Dies erlaubt bestimmte DynamoDB-, S3- und CloudWatch Logs-Aktionen (Datei wird im Repository bereitgestellt):

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "CreateLogGroup",
         "Effect": "Allow",
         "Action": "logs:CreateLogGroup",
         "Resource": "arn:aws:logs:*:AWS_ACCOUNT_ID:*"
       },
       {
         "Sid": "CreateLogStreamandEvents",
         "Effect": "Allow",
         "Action": [
           "logs:CreateLogStream",
           "logs:PutLogEvents"
         ],
         "Resource": "arn:aws:logs:*:AWS_ACCOUNT_ID:*"
       }, 
       {
         "Sid": "DynamoDBPermissions",
         "Effect": "Allow",
         "Action": [
           "dynamodb:PutItem",
           "dynamodb:UpdateItem",
           "dynamodb:DeleteItem"
         ],
         "Resource": "arn:aws:dynamodb:*:AWS_ACCOUNT_ID:table/AWSCookbook*"
       },
       {
         "Sid": "S3Permissions",
         "Effect": "Allow",
         "Action": [
           "s3:GetObject",
           "s3:PutObject"
         ],
         "Resource": "arn:aws:s3:::AWSCookbook*/*"
       }
     ]
   }

6. Verwenden Sie den Befehl sed, um die AWS_ACCOUNT_ID in der Datei boundary-policy-template.json und generiere die Datei boundary-policy.json:

   sed -e "s|AWS_ACCOUNT_ID|${AWS_ACCOUNT_ID}|g" \
        boundary-policy-template.json > boundary-policy.json

7. Erstelle die Richtlinie für die Berechtigungsgrenze mit der AWS CLI:

   aws iam create-policy --policy-name AWSCookbook105PB \
        --policy-document file://boundary-policy.json

   Du solltest eine ähnliche Ausgabe wie die folgende sehen:

   {
     "Policy": {
       "PolicyName": "AWSCookbook105PB",
       "PolicyId": "EXAMPLE",
       "Arn": "arn:aws:iam::111111111111:policy/AWSCookbook105PB",
       "Path": "/",
       "DefaultVersionId": "v1",
       "AttachmentCount": 0,
       "PermissionsBoundaryUsageCount": 0,
       "IsAttachable": true,
       "CreateDate": "2021-09-24T00:36:53+00:00",
       "UpdateDate": "2021-09-24T00:36:53+00:00"
     }
   }

8. Erstelle eine Richtliniendatei mit dem Namen policy-template.json für die Rolle (die Datei wird im Repository bereitgestellt):

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "DenyPBDelete", 
         "Effect": "Deny",
         "Action": "iam:DeleteRolePermissionsBoundary",
         "Resource": "*"
       },
       {
         "Sid": "IAMRead", 
         "Effect": "Allow",
         "Action": [
           "iam:Get*",
           "iam:List*"
         ],
         "Resource": "*"
       },
       {
          "Sid": "IAMPolicies", 
         "Effect": "Allow",
         "Action": [
           "iam:CreatePolicy",
           "iam:DeletePolicy",
           "iam:CreatePolicyVersion",
           "iam:DeletePolicyVersion",
           "iam:SetDefaultPolicyVersion"
         ],
         "Resource": "arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSCookbook*"
       },
       {
         "Sid": "IAMRolesWithBoundary", 
         "Effect": "Allow",
         "Action": [
           "iam:CreateRole",
           "iam:DeleteRole",
           "iam:PutRolePolicy",
           "iam:DeleteRolePolicy",
           "iam:AttachRolePolicy",
           "iam:DetachRolePolicy"
         ],
         "Resource": [
           "arn:aws:iam::AWS_ACCOUNT_ID:role/AWSCookbook*"
         ],
         "Condition": {
           "StringEquals": {
             "iam:PermissionsBoundary": "arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSCookbook105PB"
           }
         }
       },
       {
         "Sid": "ServerlessFullAccess", 
         "Effect": "Allow",
           "Action": [
           "lambda:*",
           "logs:*",
           "dynamodb:*",
           "s3:*"
         ],
         "Resource": "*"
       },
       {
         "Sid": "PassRole", 
         "Effect": "Allow",
         "Action": "iam:PassRole",
         "Resource": "arn:aws:iam::AWS_ACCOUNT_ID:role/AWSCookbook*",
         "Condition": {
           "StringLikeIfExists": {
             "iam:PassedToService": "lambda.amazonaws.com"
           }
         }
       },
       {
         "Sid": "ProtectPB", 
         "Effect": "Deny",
         "Action": [
           "iam:CreatePolicyVersion",
           "iam:DeletePolicy",
           "iam:DeletePolicyVersion",
           "iam:SetDefaultPolicyVersion"
         ],
         "Resource": [
           "arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSCookbook105PB",
           "arn:aws:iam::AWS_ACCOUNT_ID:policy/AWSCookbook105Policy"
         ]
       }
     ]
   }

   Diese benutzerdefinierte IAM-Richtlinie besteht aus mehreren zusammenwirkenden Anweisungen, die bestimmte Berechtigungen für die Lösung der Problemstellung festlegen:

   

   DenyPBDelete: Verweigere explizit die Möglichkeit, Berechtigungsgrenzen von Rollen zu löschen.

   

   IAMRead: Erlaube Entwicklern einen schreibgeschützten IAM-Zugang, um sicherzustellen, dass die IAM-Konsole funktioniert.

   

   IAMPolicies: Erlaube die Erstellung von IAM-Richtlinien, erzwinge aber ein Präfix für die Namenskonvention AWSCookbook*.

   

   IAMRolesWithBoundary: Erlaube die Erstellung und Löschung von IAM-Rollen nur, wenn sie die referenzierte Berechtigungsgrenze enthalten.

   

   ServerlessFullAccess: Ermögliche Entwicklern den vollen Zugriff auf die Dienste AWS Lambda, Amazon DynamoDB, Amazon CloudWatch Logs und Amazon S3.

   

   PassRole: Erlaube es Entwicklern, IAM-Rollen an Lambda-Funktionen zu übergeben.

   

   ProtectPB: Verweigere explizit die Möglichkeit, die Berechtigungsgrenzen zu ändern, die die von ihnen erstellten Rollen begrenzen.

9. Verwenden Sie den Befehl sed, um die AWS_ACCOUNT_ID in der Datei policy-template.json und generiere die Datei policy.json:

   sed -e "s|AWS_ACCOUNT_ID|${AWS_ACCOUNT_ID}|g" \
        policy-template.json > policy.json

10. Erstelle die Richtlinie für den Entwicklerzugang:

    aws iam create-policy --policy-name AWSCookbook105Policy \
         --policy-document file://policy.json

    Du solltest eine ähnliche Ausgabe wie die folgende sehen:

    {
      "Policy": {
        "PolicyName": "AWSCookbook105Policy",
        "PolicyId": "EXAMPLE",
        "Arn": "arn:aws:iam::11111111111:policy/AWSCookbook105Policy",
        "Path": "/",
        "DefaultVersionId": "v1",
        "AttachmentCount": 0,
        "PermissionsBoundaryUsageCount": 0,
        "IsAttachable": true,
        "CreateDate": "2021-09-24T00:37:13+00:00",
        "UpdateDate": "2021-09-24T00:37:13+00:00"
      }
    }

11. Verbinde die Richtlinie mit der Rolle, die du in Schritt 2 erstellt hast:

    aws iam attach-role-policy --policy-arn \
         arn:aws:iam::$AWS_ACCOUNT_ID:policy/AWSCookbook105Policy \
         --role-name AWSCookbook105Role

Validierungsprüfungen

Nimm die von dir erstellte Rolle an und setze die Ausgabe auf lokale Variablen für die AWS CLI:

creds=$(aws --output text sts assume-role --role-arn $ROLE_ARN \
     --role-session-name "AWSCookbook105" | \
     grep CREDENTIALS | cut -d " " -f2,4,5)
export AWS_ACCESS_KEY_ID=$(echo $creds | cut -d " " -f2)
export AWS_SECRET_ACCESS_KEY=$(echo $creds | cut -d " " -f4)
export AWS_SESSION_TOKEN=$(echo $creds | cut -d " " -f5)

Um eine IAM-Rolle für eine Lambda-Funktion zu erstellen, erstelle eine assume role policy für den Lambda-Dienst(lambda-assume-role-policy.json):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Erstelle die Rolle unter Angabe der Berechtigungsgrenze, die dem in der Richtlinie festgelegten Standard für die Rollenbenennung entspricht:

TEST_ROLE_1=$(aws iam create-role --role-name AWSCookbook105test1 \
     --assume-role-policy-document \
     file://lambda-assume-role-policy.json \
     --permissions-boundary \
     arn:aws:iam::$AWS_ACCOUNT_ID:policy/AWSCookbook105PB \
     --output text --query Role.Arn)

die verwaltete AmazonDynamoDBFullAccess Richtlinie an die Rolle anhängen:

aws iam attach-role-policy --role-name AWSCookbook105test1 \
--policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess

die verwaltete CloudWatchFullAccess Richtlinie an die Rolle anhängen:

aws iam attach-role-policy --role-name AWSCookbook105test1 \
--policy-arn arn:aws:iam::aws:policy/CloudWatchFullAccess

Hinweis

Obwohl du AmazonDynamoDBFullAccess und CloudWatchFullAccess mit der Rolle verknüpft hast, werden die effektiven Berechtigungen der Rolle durch die Anweisungen in der Berechtigungsgrenze, die du in Schritt 3 erstellt hast, eingeschränkt. Außerdem hast du zwar s3:GetObject und s3:PutObject in der Begrenzung definiert, aber nicht in der Rollenrichtlinie, so dass die Funktion diese Aufrufe nicht machen kann, bis du eine Richtlinie erstellst, die diese Aktionen erlaubt. Wenn du diese Rolle einer Lambda-Funktion zuordnest, kann die Lambda-Funktion nur die Aktionen ausführen, die in der Schnittmenge zwischen der Berechtigungsgrenze und der Rollenrichtlinie erlaubt sind (siehe Abbildung 1-7).

Du kannst nun eine Lambda-Funktion erstellen, die diese Rolle (AWSCookbook105test1) als Ausführungsrolle angibt, um die DynamoDB- und CloudWatch Logs-Berechtigungen für die Funktion zu überprüfen. Du kannst die Ergebnisse auch mit dem IAM Policy Simulator testen.

Du hast ein AssumeRole verwendet und Umgebungsvariablen gesetzt, um dein lokales AWS-Terminalprofil außer Kraft zu setzen und diese Validierungsprüfungen durchzuführen. Um sicherzustellen, dass du zu deiner ursprünglichen authentifizierten Sitzung in der Kommandozeile zurückkehrst, führe die Bereinigungsschritte aus, die oben in der README-Datei im Repository angegeben sind.

Aufräumen

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Hinweis

Achte darauf, dass du deine Umgebungsvariablen löschst, damit du die für zukünftige Rezepte benötigten Berechtigungen wiedererlangen kannst:

unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN

Diskussion

In deinem Bestreben, ein Least Privilege-Zugriffsmodell für Benutzer und Anwendungen in AWS zu implementieren, musst du es Entwicklern ermöglichen, IAM-Rollen zu erstellen, die ihre Anwendungen annehmen können, wenn sie mit anderen AWS-Diensten interagieren müssen. Eine AWS Lambda-Funktion, die auf eine Amazon DynamoDB-Tabelle zugreifen muss, benötigt zum Beispiel eine Rolle, um Operationen mit der Tabelle durchführen zu können. Wenn dein Team wächst, müssen deine Teammitglieder nicht jedes Mal zu dir kommen, wenn sie eine Rolle für einen bestimmten Zweck benötigen, sondern du kannst sie mit Berechtigungsgrenzen aktivieren (aber kontrollieren), ohne zu viel IAM-Zugriff aufzugeben. Die Bedingung iam:PermissionsBoundary in der Richtlinie, die die iam:CreateRole gewährt, stellt sicher, dass die erstellten Rollen immer die Berechtigungsgrenze enthalten müssen.

Berechtigungsgrenzen wirken wie eine Leitplanke und begrenzen die Ausweitung von Privilegien. Mit anderen Worten: Sie begrenzen die maximalen effektiven Berechtigungen eines IAM-Principals, der von einem delegierten Administrator erstellt wurde, indem sie festlegen, was die erstellten Rollen tun können. Wie in Abbildung 1-7 dargestellt, arbeiten sie mit der Berechtigungsrichtlinie (IAM-Richtlinie) zusammen, die mit einem IAM-Prinzipal (IAM-Benutzer oder -Rolle) verbunden ist. Dadurch wird verhindert, dass einer Administratorrolle ein breiter Zugriff gewährt werden muss, eine Eskalation der Privilegien verhindert und der Zugriff mit den geringsten Privilegien ermöglicht, indem deine Teammitglieder schnell ihre eigenen Rollen mit den geringsten Privilegien für ihre Anwendungen erstellen können.

In diesem Rezept hast du vielleicht bemerkt, dass wir für die Rollen und Richtlinien, auf die in der Berechtigungsrichtlinie verwiesen wird, die Namenskonvention AWSCookbook* verwendet haben, die sicherstellt, dass die delegierten Prinzipale Rollen und Richtlinien innerhalb dieser Konvention erstellen können. Das bedeutet, dass Entwickler Ressourcen erstellen und nur diese Rollen an Dienste weitergeben können und dabei eine einheitliche Namenskonvention einhalten. Dies ist eine ideale Vorgehensweise bei der Implementierung von Berechtigungsgrenzen. Du kannst eine Namenskonvention für verschiedene Teams, Anwendungen und Dienste entwickeln, so dass sie alle im selben Konto nebeneinander bestehen können, aber je nach ihren Anforderungen unterschiedliche Grenzen haben, falls nötig.

Zumindest musst du diese vier Dinge im Hinterkopf behalten, wenn du Rollen erstellst, die Berechtigungsleitplanken implementieren, um IAM-Berechtigungen an Nicht-Administratoren zu delegieren:

1. Erlaube die Erstellung von durch IAM-Kunden verwalteten Richtlinien: Deine Nutzer können jede beliebige Richtlinie erstellen; sie werden erst wirksam, wenn sie einem IAM-Prinzipal zugeordnet sind.

2. Erlaube die Erstellung von IAM-Rollen mit der Bedingung, dass eine Berechtigungsgrenze angehängt werden muss: Zwinge alle von deinen Teammitgliedern erstellten Rollen dazu, die Berechtigungsgrenze in die Rollenerstellung einzubeziehen.

3. Erlaube das Anhängen von Richtlinien, aber nur an Rollen, die eine Berechtigungsgrenze haben: Erlaube den Nutzern nicht, bestehende Rollen zu ändern, auf die sie möglicherweise Zugriff haben.

4. Erlaube iam:PassRole für AWS-Services, für die deine Benutzer Rollen erstellen: Deine Entwickler müssen vielleicht Rollen für Amazon EC2 und AWS Lambda erstellen, also gib ihnen die Möglichkeit, nur die von ihnen erstellten Rollen an diese von dir definierten Services weiterzugeben.

Tipp

Berechtigungsgrenzen sind ein mächtiges, fortschrittliches IAM-Konzept, das schwer zu verstehen sein kann. Wir empfehlen dir, den Vortrag von Brigid Johnson auf der AWS re:Inforce 2018 zu besuchen, um einige praktische Beispiele für IAM-Richtlinien, Rollen und Berechtigungsgrenzen zu sehen, die auf praktische Weise erklärt werden.

Herausforderung

Erweitern Sie die Berechtigungsgrenze, damit erstellte Rollen in einer SQS-Warteschlange und einem SNS-Thema veröffentlichen können, und passen Sie die Richtlinie für die Rolle ebenfalls an.

1.6 Mit dem AWS SSM Session Manager eine Verbindung zu EC2-Instanzen herstellen

Problem

Du hast eine EC2-Instanz in einem privaten Subnetz und musst dich mit der Instanz verbinden, ohne SSH über das Internet zu benutzen.

Lösung

Erstelle eine IAM-Rolle, füge die Richtlinie AmazonSSMManagedInstanceCore hinzu, erstelle ein EC2-Instanzprofil, füge die erstellte IAM-Rolle dem Instanzprofil hinzu, verbinde das EC2-Instanzprofil mit einer EC2-Instanz und führe schließlich den Befehl aws ssm start-session aus, um dich mit der Instanz zu verbinden. Ein logischer Ablauf dieser Schritte ist in Abbildung 1-8 dargestellt.

Abbildung 1-8. Mit dem Session Manager eine Verbindung zu einer EC2-Instanz herstellen

Voraussetzungen

• Amazon Virtual Private Cloud (VPC) mit isolierten oder privaten Subnetzen und zugehörigen Routentabellen

• Erforderliche VPC-Endpunkte für AWS Systems Manager

• AWS CLI v2 mit dem installierten Session Manager Plugin

Vorbereitung

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Steps

1. Erstelle eine Datei namens assume-role-policy.json mit folgendem Inhalt (die Datei wird im Repository bereitgestellt):

   {
     "Version": "2012-10-17",
     "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "Service": "ec2.amazonaws.com"
       },
       "Action": "sts:AssumeRole"
     }
     ]
   }

2. Erstelle mit diesem Befehl eine IAM-Rolle mit der Anweisung in der mitgelieferten Datei assume-role-policy.json:

   ROLE_ARN=$(aws iam create-role --role-name AWSCookbook106SSMRole \
        --assume-role-policy-document file://assume-role-policy.json \
        --output text --query Role.Arn)

3. Hänge die verwaltete Richtlinie AmazonSSMManagedInstanceCore an die Rolle an, damit die Rolle den Zugriff auf AWS Systems Manager erlaubt:

   aws iam attach-role-policy --role-name AWSCookbook106SSMRole \
        --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

4. Erstelle ein Instanzprofil:

   aws iam create-instance-profile \
        --instance-profile-name AWSCookbook106InstanceProfile

   Du solltest eine ähnliche Ausgabe wie die folgende sehen:

   {
     "InstanceProfile": {
       "Path": "/",
       "InstanceProfileName": "AWSCookbook106InstanceProfile",
       "InstanceProfileId": "(RandomString",
       "Arn": "arn:aws:iam::111111111111:instance-profile/AWSCookbook106InstanceProfile",
       "CreateDate": "2021-11-28T20:26:23+00:00",
       "Roles": []
     }
   }

5. Füge die Rolle, die du erstellt hast, zum Instanzprofil hinzu:

   aws iam add-role-to-instance-profile \
        --role-name AWSCookbook106SSMRole \
        --instance-profile-name AWSCookbook106InstanceProfile

   Hinweis

   Das Profil der EC2-Instanz enthält eine Rolle, die du erstellst. Durch die Zuordnung des Instanzprofils zu einer Instanz kann diese definieren, "wer ich bin", und die Rolle definiert, "was ich tun darf". Beides wird von IAM benötigt, damit eine EC2-Instanz mit anderen AWS-Diensten kommunizieren kann, die den IAM-Service nutzen. Du kannst eine Liste der Instanzprofile in deinem Konto erhalten, indem du den AWS CLI-Befehl aws iam list-instance-profiles ausführst.

6. Frag SSM nach der neuesten Amazon Linux 2 AMI ID, die in deiner Region verfügbar ist, und speichere sie als Umgebungsvariable:

   AMI_ID=$(aws ssm get-parameters --names \
        /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 \
        --query 'Parameters[0].[Value]' --output text)

7. Starte eine Instanz in einem deiner Subnetze, die auf das von dir erstellte Instanzprofil verweist und außerdem ein Name Tag verwendet, mit dem du die Instanz in der Konsole identifizieren kannst:

   INSTANCE_ID=$(aws ec2 run-instances --image-id $AMI_ID \
        --count 1 \
        --instance-type t3.nano \
        --iam-instance-profile Name=AWSCookbook106InstanceProfile \
        --subnet-id $SUBNET_1 \
        --security-group-ids $INSTANCE_SG \
        --metadata-options \
   HttpTokens=required,HttpPutResponseHopLimit=64,HttpEndpoint=enabled \
        --tag-specifications \
        'ResourceType=instance,Tags=[{Key=Name,Value=AWSCookbook106}]' \
        'ResourceType=volume,Tags=[{Key=Name,Value=AWSCookbook106}]' \
        --query Instances[0].InstanceId \
        --output text)

   Tipp

   EC2-Instance-Metadaten sind eine Funktion , mit der du in deiner EC2-Instanz über einen HTTP-Endpunkt von der Instanz selbst auf Informationen über deine EC2-Instanz zugreifen kannst. Dies ist hilfreich für die Skripterstellung und Automatisierung über Benutzerdaten. Du solltest immer die neueste Version der Instanz-Metadaten verwenden. In Schritt 7 hast du das getan, indem du das Flag --metadata-options angegeben und die Option HttpTokens=required angegeben hast, die IMDSv2 erzwingt.

Validierungsprüfungen

Stelle sicher, dass deine EC2-Instanz bei SSM registriert ist. Verwende den folgenden Befehl, um den Status zu überprüfen. Dieser Befehl sollte die Instanz-ID zurückgeben:

aws ssm describe-instance-information \
     --filters Key=ResourceType,Values=EC2Instance \
     --query "InstanceInformationList[].InstanceId" --output text

Verbinde dich mit der EC2-Instanz über den SSM Session Manager:

aws ssm start-session --target $INSTANCE_ID

Du solltest jetzt mit deiner Instanz verbunden sein und eine Eingabeaufforderung sehen. Führe in der Eingabeaufforderung einen Befehl aus, um zu überprüfen, ob du mit deiner EC2-Instanz verbunden bist, indem du den Metadatendienst nach einem IMDSv2-Token abfragst und das Token verwendest, um Metadaten für das mit der Instanz verbundene Profil abzufragen:

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/iam/info

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

{
  "Code" : "Success",
  "LastUpdated" : "2021-09-23T16:03:25Z",
  "InstanceProfileArn" : "arn:aws:iam::111111111111:instance-profile/AWSCookbook106InstanceProfile",
  "InstanceProfileId" : "AIPAZVTINAMEXAMPLE"
}

Beende die Session Manager-Sitzung:

exit

Aufräumen

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Diskussion

Wenn du den AWS SSM Session Manager verwendest, um dich mit EC2-Instanzen zu verbinden, bist du nicht mehr auf Secure Shell (SSH) über das Internet angewiesen, um über die Befehlszeile auf deine Instanzen zuzugreifen. Sobald du den Session Manager für deine Instanzen konfiguriert hast, kannst du dich sofort mit einer Bash-Shell-Sitzung unter Linux oder einer PowerShell-Sitzung für Windows-Systeme verbinden.

Warnung

SSM kann alle Befehle und ihre Ausgaben während einer Sitzung protokollieren. Mit diesem Befehl kannst du die Protokollierung von sensiblen Daten (z. B. Passwörtern) unterbinden, indem du eine Präferenz setzt:

stty -echo; read passwd; stty echo;

Weitere Informationen findest du in einem AWS-Artikel über die Protokollierung von Sitzungsaktivitäten.

Session Manager kommuniziert mit der AWS Systems Manager (SSM) API Endpunkten innerhalb der AWS Region, die du verwendest, über HTTPS (TCP Port 443). Der Agent auf deiner Instanz meldet sich beim Booten beim SSM-Service an. Für die Funktion des Session Managers sind keine Regeln für eingehende Sicherheitsgruppen erforderlich. Wir empfehlen, VPC-Endpunkte für Session Manager zu konfigurieren, um den Internetverkehr und die Kosten für NAT-Gateways(Network Address Translation) zu vermeiden.

Hier sind einige Beispiele für die erhöhte Sicherheit, die Session Manager bietet:

• In Sicherheitsgruppen, die mit Instanzen verbunden sind, müssen keine ins Internet gerichteten TCP-Ports zugelassen werden.

• Du kannst Instanzen in privaten (oder isolierten) Subnetzen betreiben, ohne sie direkt dem Internet auszusetzen, und trotzdem für Verwaltungsaufgaben auf sie zugreifen.

• Es ist nicht nötig, SSH-Schlüssel für Instanzen zu erstellen, zuzuordnen und zu verwalten.

• Es ist nicht nötig, Benutzerkonten und Passwörter auf den Instanzen zu verwalten.

• Du kannst den Zugriff auf die Verwaltung von EC2-Instanzen mithilfe von IAM-Rollen delegieren.

Hinweis

Ein Tool wie SSM, das so leistungsstarke Funktionen bietet, muss sorgfältig geprüft werden. AWS bietet Informationen zum Sperren von Berechtigungen für den SSM-Benutzer und weitere Informationen zum Überprüfen von Sitzungsaktivitäten.

Herausforderung

Sieh dir die Protokolle für eine Sitzung an und erstelle einen Alarm, wenn der Befehl rm ausgeführt wird.

1.7 EBS-Volumes mit KMS-Schlüsseln verschlüsseln

Problem

Du brauchst einen Verschlüsselungsschlüssel, um EBS-Volumes zu verschlüsseln, die an deine EC2-Instanzen in einer Region angeschlossen sind, und du musst den Schlüssel automatisch alle 365 Tage erneuern.

Lösung

Erstelle einen kundenverwalteten KMS-Schlüssel (CMK), aktiviere die jährliche Rotation des Schlüssels, aktiviere die EC2-Standardverschlüsselung für EBS-Volumes in einer Region und gib den von dir erstellten KMS-Schlüssel an (siehe Abbildung 1-9).

Abbildung 1-9. Erstellen eines vom Kunden verwalteten Schlüssels, Aktivieren der Rotation und Einstellen der Standardverschlüsselung für EC2 mit einem vom Kunden verwalteten Schlüssel

Steps

1. Erstelle einen kundenverwalteten KMS-Schlüssel und speichere den Schlüssel-ARN als lokale Variable:

   KMS_KEY_ID=$(aws kms create-key --description "AWSCookbook107Key" \
        --output text --query KeyMetadata.KeyId)

2. Erstelle einen Schlüsselalias, damit du in anderen Schritten auf den Schlüssel verweisen kannst:

   aws kms create-alias --alias-name alias/AWSCookbook107Key \
        --target-key-id $KMS_KEY_ID

3. Aktiviere die automatische Rotation des symmetrischen Schlüsselmaterials alle 365 Tage:

   aws kms enable-key-rotation --key-id $KMS_KEY_ID

4. Aktiviere die EBS-Verschlüsselung standardmäßig für den EC2-Dienst in deiner aktuellen Region:

   aws ec2 enable-ebs-encryption-by-default

   Du solltest eine ähnliche Ausgabe wie die folgende sehen:

   {
        "EbsEncryptionByDefault": true
   }

5. Aktualisiere den Standard-KMS-Schlüssel, der für die standardmäßige EBS-Verschlüsselung verwendet wird, auf deinen vom Kunden verwalteten Schlüssel, den du in Schritt 1 erstellt hast:

   aws ec2 modify-ebs-default-kms-key-id \
        --kms-key-id alias/AWSCookbook107Key

   Du solltest eine ähnliche Ausgabe wie die folgende sehen:

   {
     "KmsKeyId": "arn:aws:kms:us-east-1:111111111111:key/1111111-aaaa-bbbb-222222222"
   }

Validierungsprüfungen

Verwende die AWS CLI, um den Standard-EBS-Verschlüsselungsstatus für den EC2-Service abzurufen:

aws ec2 get-ebs-encryption-by-default

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

{
  "EbsEncryptionByDefault": true
}

Ruft die KMS-Schlüssel-ID ab, die für die Standardverschlüsselung verwendet wird:

aws ec2 get-ebs-default-kms-key-id

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

{
  "KmsKeyId": "arn:aws:kms:us-east-1:1111111111:key/1111111-aaaa-3333-222222222c64b"
}

Überprüfe den Status der automatischen Rotation des Schlüssels, den du erstellt hast:

aws kms get-key-rotation-status --key-id $KMS_KEY_ID

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

{
  "KeyRotationEnabled": true
}

Aufräumen

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Diskussion

Wenn du sicherstellen musst, dass alle deine neu erstellten EBS-Volumes verschlüsselt sind, hilft dir die Option ebs-encryption-by-default weiter. Wenn diese Einstellung aktiviert ist, werden die EBS-Volumes jeder EC2-Instanz, die du startest, standardmäßig mit dem angegebenen KMS-Schlüssel verschlüsselt. Wenn du keinen KMS-Schlüssel angibst, wird ein standardmäßig von AWS verwalteter aws/ebs KMS-Schlüssel erstellt und verwendet. Wenn du den Lebenszyklus des Schlüssels verwalten musst oder es eine Anforderung gibt, die besagt, dass du oder dein Unternehmen den Schlüssel verwalten muss, sollten vom Kunden verwaltete Schlüssel verwendet werden.

Die automatische Schlüsselrotation im KMS-Dienst vereinfacht deinen Ansatz für die Schlüsselrotation und die Verwaltung des Lebenszyklus von Schlüsseln.

KMS ist ein flexibler Dienst, mit dem du eine Vielzahl von Datenverschlüsselungsstrategien umsetzen kannst. Er unterstützt Schlüsselrichtlinien, mit denen du kontrollieren kannst, wer Zugriff auf den Schlüssel hat. Diese Schlüsselrichtlinien können zusätzlich zu deiner bestehenden IAM-Richtlinienstrategie eingesetzt werden, um die Sicherheit zu erhöhen. Mit KMS-Schlüsseln kannst du z. B. viele verschiedene Arten von Daten im Ruhezustand innerhalb deines AWS-Kontos verschlüsseln:

• Amazon S3

• Amazon EC2 EBS-Volumen

• Amazon RDS-Datenbanken und -Cluster

• Amazon DynamoDB-Tabellen

• Amazon EFS-Volumes

• Amazon FSx Dateifreigaben

• Und viele mehr

Herausforderung 1

Ändere die Schlüsselrichtlinie für den KMS-Schlüssel so, dass nur dein IAM-Prinzipal und der EC2-Dienst Zugriff darauf haben.

Herausforderung 2

Erstelle ein EBS-Volume und überprüfe, dass es verschlüsselt ist, indem du den Befehl aws ec2 describe-volumes verwendest.

1.8 Speichern, Verschlüsseln und Zugreifen auf Passwörter mit dem Secrets Manager

Problem

Du musst deiner EC2-Instanz die Möglichkeit geben, ein Datenbankpasswort für deine Anwendung sicher zu speichern und abzurufen.

Lösung

Erstelle ein Passwort, speichere das Passwort im Secrets Manager, erstelle eine IAM-Richtlinie mit Zugriff auf das Geheimnis und gewähre ein EC2-Instanzprofil Zugriff auf das Geheimnis, wie in Abbildung 1-10 gezeigt.

Abbildung 1-10. Ein Geheimnis erstellen und es über die EC2-Instanz abrufen

Voraussetzungen

• VPC mit isolierten Subnetzen und zugehörigen Routentabellen.

• EC2-Instanz eingerichtet. Du brauchst die Möglichkeit, dich mit dieser Instanz zu verbinden, um zu testen.

Vorbereitung

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Steps

1. Erstelle eine geheime mit der AWS CLI:

   RANDOM_STRING=$(aws secretsmanager get-random-password \
        --password-length 32 --require-each-included-type \
        --output text \
        --query RandomPassword)

2. Speichere es als neues Geheimnis im Secrets Manager:

   SECRET_ARN=$(aws secretsmanager \
        create-secret --name AWSCookbook108/Secret1 \
        --description "AWSCookbook108 Secret 1" \
        --secret-string $RANDOM_STRING \
        --output text \
        --query ARN)

3. Erstelle eine Datei mit dem Namen secret-access-policy-template.json, die auf das von dir erstellte Geheimnis verweist. (die Datei ist im Repository enthalten):

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "secretsmanager:GetResourcePolicy",
           "secretsmanager:GetSecretValue",
           "secretsmanager:DescribeSecret",
           "secretsmanager:ListSecretVersionIds"
         ],
         "Resource": [
           "SECRET_ARN"
         ]
       },
       {
         "Effect": "Allow",
         "Action": "secretsmanager:ListSecrets",
         "Resource": "*"
       }
     ]
   }

4. Benutze den Befehl sed, um zu ersetzen SECRET_ARN in der Datei secret-access-policy-template.json und generiere die Datei secret-access-policy.json:

   sed -e "s|SECRET_ARN|$SECRET_ARN|g" \
        secret-access-policy-template.json > secret-access-policy.json

5. Erstelle die IAM-Richtlinie für den geheimen Zugriff:

   aws iam create-policy --policy-name AWSCookbook108SecretAccess \
        --policy-document file://secret-access-policy.json

   Du solltest eine ähnliche Ausgabe wie die folgende sehen:

   {
     "Policy": {
       "PolicyName": "AWSCookbook108SecretAccess",
       "PolicyId": "(Random String)",
       "Arn": "arn:aws:iam::1111111111:policy/AWSCookbook108SecretAccess",
       "Path": "/",
       "DefaultVersionId": "v1",
       "AttachmentCount": 0,
       "PermissionsBoundaryUsageCount": 0,
       "IsAttachable": true,
       "CreateDate": "2021-11-28T21:25:23+00:00",
       "UpdateDate": "2021-11-28T21:25:23+00:00"
     }
   }

6. Gewähre einer EC2-Instanz die Fähigkeit, auf das Geheimnis zuzugreifen, indem du die IAM-Richtlinie, die du erstellt hast, zur aktuell zugewiesenen IAM-Rolle des EC2-Instanzprofils hinzufügst:

   aws iam attach-role-policy --policy-arn \
        arn:aws:iam::$AWS_ACCOUNT_ID:policy/AWSCookbook108SecretAccess \
        --role-name $ROLE_NAME

Validierungsprüfungen

Verbinde dich mit der EC2-Instanz:

aws ssm start-session --target $INSTANCE_ID

Lege deine Standardregion fest und exportiere sie:

export AWS_DEFAULT_REGION=us-east-1

Rufe das Geheimnis aus dem Secrets Manager von der EC2 ab:

aws secretsmanager get-secret-value --secret-id AWSCookbook108/Secret1

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

{
  "Name": "AWSCookbook108/Secret1",
  "VersionId": "<string>",
  "SecretString": "<secret value>",
  "VersionStages": [
    "AWSCURRENT"
  ],
  "CreatedDate": 1638221015.646,
  "ARN": "arn:aws:secretsmanager:us-east-1:111111111111:secret:AWSCookbook108/Secret1-<suffix>"
}</suffix>

Beende die Session Manager-Sitzung:

exit

Aufräumen

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Diskussion

Die sichere Erstellung, Speicherung und Verwaltung des Lebenszyklus von Geheimnissen wie API-Schlüsseln und Datenbankpasswörtern ist eine grundlegende Komponente für eine starke Sicherheitslage in der Cloud. Mit dem Secrets Manager kannst du eine Strategie zur Verwaltung von Geheimnissen umsetzen, die deine Sicherheitsstrategie unterstützt. Mithilfe von IAM-Richtlinien kannst du kontrollieren, wer auf welche Geheimnisse zugreifen darf, um sicherzustellen, dass die von dir verwalteten Geheimnisse nur für die erforderlichen Sicherheitsprinzipale zugänglich sind.

Da deine EC2-Instanz ein Instanzprofil verwendet, musst du keine fest codierten Anmeldedaten auf der Instanz speichern, damit sie auf das Geheimnis zugreifen kann. Der Zugriff wird über die IAM-Richtlinie gewährt, die mit dem Instanzprofil verknüpft ist. Jedes Mal, wenn du (oder deine Anwendung) von der EC2-Instanz auf das Geheimnis zugreifst, werden temporäre Sitzungsdaten vom STS Service abgerufen, damit der get-secret-value API-Aufruf das Geheimnis abrufen kann. Die AWS CLI automatisiert diesen Prozess des Token-Abrufs, wenn ein EC2-Instanzprofil an deine Instanz angehängt wird. Du kannst auch das AWS SDK in deinen Anwendungen verwenden, um diese Funktion zu nutzen.

Die Verwendung von Secrets Manager hat noch weitere Vorteile, z. B:

• Verschlüsseln von Geheimnissen mit KMS-Schlüsseln, die du erstellst und verwaltest

• Überprüfung des Zugriffs auf Geheimnisse durch CloudTrail

• Automatisieren der Geheimnisrotation mit Lambda

• Gewährung von Zugriff auf andere Nutzer, Rollen und Dienste wie EC2 und Lambda

• Replizieren von Geheimnissen in eine andere Region für hohe Verfügbarkeit und Disaster Recovery-Zwecke

Herausforderung

Konfiguriere eine Lambda-Funktion, um mit einer IAM-Rolle sicher auf das Geheimnis zuzugreifen.

1.9 Sperren des öffentlichen Zugriffs für ein S3 Bucket

Problem

Du wurdest vom Sicherheitsteam deines Unternehmens darauf aufmerksam gemacht, dass ein S3-Bucket falsch konfiguriert wurde und du den öffentlichen Zugriff darauf sperren musst.

Lösung

Wende die Funktion Amazon S3 Block Public Access auf deinen Bucket an und überprüfe dann den Status mit dem Access Analyzer (siehe Abbildung 1-11).

Tipp

AWS gibt in einem Artikel über die S3 Speicherung Auskunft darüber, was als "öffentlich" gilt.

Abbildung 1-11. Blockieren des öffentlichen Zugriffs auf einen S3-Bucket

Voraussetzung

• S3 Bucket mit öffentlich verfügbaren Objekten

Vorbereitung

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Steps

1. Erstelle einen Access Analyzer, der für die Validierung des Zugangs verwendet wird:

   ANALYZER_ARN=$(aws accessanalyzer create-analyzer \
        --analyzer-name awscookbook109\
        --type ACCOUNT \
        --output text --query arn)

2. Führe einen Scan deines S3-Buckets mit dem Access Analyzer durch:

   aws accessanalyzer start-resource-scan \
        --analyzer-arn $ANALYZER_ARN \
        --resource-arn arn:aws:s3:::awscookbook109-$RANDOM_STRING

3. Rufe die Ergebnisse des Access Analyzer-Scans ab (es kann etwa 30 Sekunden dauern, bis die Scanergebnisse verfügbar sind):

   aws accessanalyzer get-analyzed-resource \
        --analyzer-arn $ANALYZER_ARN \
        --resource-arn arn:aws:s3:::awscookbook109-$RANDOM_STRING

   Du solltest eine ähnliche Ausgabe wie die folgende sehen (beachte den Wert isPublic ):

   {
     "resource": {
     "actions": [
       "s3:GetObject",
       "s3:GetObjectVersion"
     ],
     "analyzedAt": "2021-06-26T17:42:00.861000+00:00",
     "createdAt": "2021-06-26T17:42:00.861000+00:00",
     "isPublic": true,
     "resourceArn": "arn:aws:s3:::awscookbook109-<<string>>",
     "resourceOwnerAccount": "111111111111",
     "resourceType": "AWS::S3::Bucket",
     "sharedVia": [
       "POLICY"
     ],
     "status": "ACTIVE",
     "updatedAt": "2021-06-26T17:42:00.861000+00:00"
     }
   }

4. Lege die öffentliche Zugangssperre für deinen Bucket fest:

   aws s3api put-public-access-block \
        --bucket awscookbook109-$RANDOM_STRING \
        --public-access-block-configuration \
   "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

   Hinweis

   Siehe den AWS-Artikel über die verfügbaren PublicAccessBlock Konfigurationseigenschaften.

Validierungsprüfungen

Führe einen Scan deines S3-Buckets durch:

aws accessanalyzer start-resource-scan \
     --analyzer-arn $ANALYZER_ARN \
     --resource-arn arn:aws:s3:::awscookbook109-$RANDOM_STRING

Erhalte die Ergebnisse des Access Analyzer Scans:

aws accessanalyzer get-analyzed-resource \
     --analyzer-arn $ANALYZER_ARN \
     --resource-arn arn:aws:s3:::awscookbook109-$RANDOM_STRING

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

{
  "resource": {
  "analyzedAt": "2021-06-26T17:46:24.906000+00:00",
  "isPublic": false,
  "resourceArn": "arn:aws:s3:::awscookbook109-<<string>>",
  "resourceOwnerAccount": "111111111111",
  "resourceType": "AWS::S3::Bucket"
  }
}

Aufräumen

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Diskussion

Eines der besten Dinge, die du tun kannst, um die Datensicherheit in deinem AWS-Konto zu gewährleisten, ist, immer darauf zu achten, dass du die richtigen Sicherheitskontrollen für deine Daten anwendest. Wenn du ein Objekt in deinem S3-Bucket als öffentlich markierst, ist es für jeden im Internet zugänglich, da S3 Objekte über HTTP bereitstellt. Eine der häufigsten Sicherheitsfehlkonfigurationen, die Nutzer/innen in der Cloud vornehmen, ist die Kennzeichnung von Objekten als öffentlich, obwohl dies nicht beabsichtigt oder erforderlich ist. Um sich vor Fehlkonfigurationen von S3-Objekten zu schützen, ist die Aktivierung von BlockPublicAccess für deine Buckets aus Sicherheitsgründen eine gute Sache.

Tipp

Du kannst die Einstellungen für öffentliche Blöcke auch auf der Ebene deines Kontos festlegen, was alle S3-Buckets in deinem Konto einschließen würde:

aws s3control put-public-access-block \
    --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true \
    --account-id $AWS_ACCOUNT_ID

Du kannst S3-Inhalte für Internetnutzer über HTTP und HTTPS bereitstellen und dabei deinen Bucket privat halten. Content Delivery Networking (CDN), wie Amazon CloudFront, bietet sicherere, effizientere und kostengünstigere Möglichkeiten für das globale Hosting statischer Websites und die Nutzung von S3 als Objektquelle. Ein Beispiel für eine CloudFront-Konfiguration, die statische Inhalte aus einem S3-Bucket bereitstellt, findest du in Rezept 1.10.

Herausforderung

Setze einen VPC-Endpunkt für S3 in deiner VPC ein und erstelle eine Bucket-Richtlinie, um den Zugriff auf deinen S3-Bucket nur über diesen Endpunkt zu beschränken.

1.10 Sichere Bereitstellung von Webinhalten aus S3 mit CloudFront

Problem

Du hast nicht-öffentliche Webinhalte in S3 und möchtest CloudFront so konfigurieren, dass die Inhalte bereitgestellt werden.

Lösung

Erstelle eine CloudFront-Verteilung und setze den Ursprung auf deinen S3-Bucket. Konfiguriere dann eine Ursprungszugriffsidentität (OAI), um zu verlangen, dass der Bucket nur von CloudFront aus zugänglich ist (siehe Abbildung 1-12).

Abbildung 1-12. CloudFront und S3

Voraussetzung

• S3 Bucket mit statischen Webinhalten

Vorbereitung

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Steps

1. Erstelle einen Verweis von CloudFront OAI auf in einer S3-Bucket-Richtlinie:

   OAI=$(aws cloudfront create-cloud-front-origin-access-identity \
        --cloud-front-origin-access-identity-config \
        CallerReference="awscookbook",Comment="AWSCookbook OAI" \
        --query CloudFrontOriginAccessIdentity.Id --output text)

2. Ersetze mit dem Befehl sed die Werte in der Datei distribution-config-template.json durch deinen CloudFront OAI- und S3-Bucket-Namen:

   sed -e "s/CLOUDFRONT_OAI/${OAI}/g" \
        -e "s|S3_BUCKET_NAME|awscookbook110-$RANDOM_STRING|g" \
        distribution-template.json > distribution.json

3. Erstelle eine CloudFront-Verteilung, die die gerade erstellte JSON-Datei für die Verteilungskonfiguration verwendet:

   DISTRIBUTION_ID=$(aws cloudfront create-distribution \
        --distribution-config file://distribution.json \
        --query Distribution.Id --output text)

4. Es dauert ein paar Minuten, bis die Verteilung erstellt ist; mit diesem Befehl kannst du den Status überprüfen. Warte, bis der Status "Bereitgestellt" lautet:

   aws cloudfront get-distribution --id $DISTRIBUTION_ID \
       --output text --query Distribution.Status

5. Konfiguriere die S3-Bucket-Richtlinie so, dass sie nur Anfragen von CloudFront zulässt, indem du eine Bucket-Richtlinie wie diese verwendest (wir haben bucket-policy-template.json im Repository bereitgestellt):

   {
     "Version": "2012-10-17",
     "Id": "PolicyForCloudFrontPrivateContent",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity CLOUDFRONT_OAI"
         },
         "Action": "s3:GetObject",
         "Resource": "arn:aws:s3:::S3_BUCKET_NAME/*"
       }
     ]
   }

6. Verwende den Befehl sed, um die Werte in der Datei bucket-policy-template.json durch den CloudFront OAI- und S3-Bucket-Namen zu ersetzen:

   sed -e "s/CLOUDFRONT_OAI/${OAI}/g" \
        -e "s|S3_BUCKET_NAME|awscookbook110-$RANDOM_STRING|g" \
        bucket-policy-template.json > bucket-policy.json

7. Wende die Bucket-Richtlinie auf den S3-Bucket mit deinen statischen Webinhalten an:

   aws s3api put-bucket-policy --bucket awscookbook110-$RANDOM_STRING \
        --policy file://bucket-policy.json

8. Hol dir die DOMAIN_NAME der von dir erstellten Verteilung:

   DOMAIN_NAME=$(aws cloudfront get-distribution --id $DISTRIBUTION_ID \
        --query Distribution.DomainName --output text)

Validierungsprüfungen

Versuche, über HTTPS direkt auf den S3-Bucket zuzugreifen, um zu überprüfen, ob der Bucket nicht direkt Inhalte bereitstellt:

curl https://awscookbook110-$RANDOM_STRING.s3.$AWS_REGION.amazonaws.com/index.html

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

$ curl https://awscookbook110-$RANDOM_STRING.s3.$AWS_REGION.amazonaws.com/index.html
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AccessDenied</Code><Message>Access
Denied</Message><RequestId>0AKQD0EFJC9ZHPCC</RequestId><HostId>gfld4qKp9A93G8ee7VPBFrXBZV1HE3jiOb3bNB54fP
EPTihit/OyFh7hF2Nu4+Muv6JEc0ebLL4=</HostId></Error>
110-Optimizing-S3-with-CloudFront:$

Verwende curl, um zu sehen, dass deine index.html-Datei vom privaten S3-Bucket über CloudFront bereitgestellt wird:

curl $DOMAIN_NAME

Du solltest eine ähnliche Ausgabe wie die folgende sehen:

$ curl $DOMAIN_NAME
AWSCookbook
$

Aufräumen

Folge den Schritten im Ordner dieses Rezepts im Kapitel Code Repository.

Diskussion

Diese Konfiguration ermöglicht es dir, den S3-Bucket privat zu halten und nur der CloudFront-Distribution den Zugriff auf Objekte im Bucket zu ermöglichen. Du hast eine Ursprungs-Zugangsidentität erstellt und eine Bucket-Richtlinie definiert, die nur CloudFront den Zugriff auf deine S3-Inhalte erlaubt. Damit hast du eine solide Grundlage für die Sicherheit deiner S3-Buckets mit dem zusätzlichen Schutz des globalen CDN von CloudFront geschaffen.

Der Schutz, den ein CDN vor einem DDoS-Angriff (Distributed-Denial-of-Service) bietet, ist erwähnenswert, da die Endnutzeranfragen an deine Inhalte zu einem Präsenzpunkt im CloudFront-Netzwerk mit der geringsten Latenz geleitet werden. Dies schützt dich auch vor den Kosten eines DDoS-Angriffs auf statische Inhalte, die in einem S3-Bucket gehostet werden, da es in der Regel kostengünstiger ist, Anfragen über CloudFront statt direkt über S3 zu stellen.

Standardmäßig wird CloudFront mit einem HTTPS-Zertifikat auf dem Standard-Hostnamen für deine Distribution geliefert, das du zur Sicherung des Datenverkehrs verwendest. Mit CloudFront kannst du deinen eigenen benutzerdefinierten Domainnamen zuordnen, ein benutzerdefiniertes Zertifikat von Amazon Certificate Manager (ACM) anhängen, von HTTP auf HTTPS umleiten, HTTPS erzwingen, das Cache-Verhalten anpassen, Lambda-Funktionen (Lambda @Edge) aufrufen und vieles mehr.

Herausforderung

Füge eine geografische Einschränkung zu deiner CloudFront Verteilung hinzu.