AWS - Grundinformationen

Reading time: 21 minutes

Organisationshierarchie

Konten

In AWS gibt es ein Root-Konto, das der Elterncontainer für alle Konten Ihrer Organisation ist. Sie müssen jedoch dieses Konto nicht verwenden, um Ressourcen bereitzustellen; Sie können andere Konten erstellen, um verschiedene AWS-Infrastrukturen voneinander zu trennen.

Dies ist aus Sicherheitssicht sehr interessant, da ein Konto nicht auf Ressourcen eines anderen Kontos zugreifen kann (es sei denn, es werden speziell Brücken erstellt), sodass Sie auf diese Weise Grenzen zwischen Bereitstellungen schaffen können.

Daher gibt es zwei Arten von Konten in einer Organisation (wir sprechen von AWS-Konten und nicht von Benutzerkonten): ein einzelnes Konto, das als Verwaltungskonto bezeichnet wird, und ein oder mehrere Mitgliedskonten.

• Das Verwaltungskonto (das Root-Konto) ist das Konto, das Sie verwenden, um die Organisation zu erstellen. Vom Verwaltungskonto der Organisation aus können Sie Folgendes tun:

• Konten in der Organisation erstellen

• Andere bestehende Konten zur Organisation einladen

• Konten aus der Organisation entfernen

• Einladungen verwalten

• Richtlinien auf Entitäten (Wurzeln, OUs oder Konten) innerhalb der Organisation anwenden

• Die Integration mit unterstützten AWS-Diensten aktivieren, um die Dienstfunktionalität über alle Konten in der Organisation bereitzustellen.

• Es ist möglich, sich als Root-Benutzer mit der E-Mail-Adresse und dem Passwort anzumelden, die zur Erstellung dieses Root-Kontos/Organisation verwendet wurden.

Das Verwaltungskonto hat die Verantwortlichkeiten eines Zahlungskontos und ist verantwortlich für die Bezahlung aller Gebühren, die von den Mitgliedskonten angefallen sind. Sie können das Verwaltungskonto einer Organisation nicht ändern.

• Mitgliedskonten bilden alle anderen Konten in einer Organisation. Ein Konto kann nur Mitglied einer Organisation zur gleichen Zeit sein. Sie können eine Richtlinie an ein Konto anhängen, um Kontrollen nur auf dieses eine Konto anzuwenden.
• Mitgliedskonten müssen eine gültige E-Mail-Adresse verwenden und können einen Namen haben; im Allgemeinen werden sie nicht in der Lage sein, die Abrechnung zu verwalten (aber sie könnten Zugang dazu erhalten).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Organisationseinheiten

Konten können in Organisationseinheiten (OU) gruppiert werden. Auf diese Weise können Sie Richtlinien für die Organisationseinheit erstellen, die auf alle untergeordneten Konten angewendet werden. Beachten Sie, dass eine OU andere OUs als Kinder haben kann.

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

Service Control Policy (SCP)

Eine Service Control Policy (SCP) ist eine Richtlinie, die die Dienste und Aktionen spezifiziert, die Benutzer und Rollen in den Konten, auf die die SCP Einfluss hat, verwenden können. SCPs sind ähnlich wie IAM Berechtigungsrichtlinien, mit dem Unterschied, dass sie keine Berechtigungen gewähren. Stattdessen spezifizieren SCPs die maximalen Berechtigungen für eine Organisation, eine organisatorische Einheit (OU) oder ein Konto. Wenn Sie eine SCP an die Root-Organisation oder eine OU anhängen, beschränkt die SCP die Berechtigungen für Entitäten in Mitgliedskonten.

Dies ist der EINZIGE Weg, wie sogar der Root-Benutzer daran gehindert werden kann, etwas zu tun. Zum Beispiel könnte es verwendet werden, um Benutzer daran zu hindern, CloudTrail zu deaktivieren oder Backups zu löschen.
Der einzige Weg, dies zu umgehen, besteht darin, auch das Master-Konto zu kompromittieren, das die SCPs konfiguriert (das Master-Konto kann nicht blockiert werden).

SCP-Beispiele:

• Den Root-Account vollständig verweigern

• Nur bestimmte Regionen zulassen

• Nur genehmigte Dienste zulassen

• Verweigern, dass GuardDuty, CloudTrail und S3 Public Block Access deaktiviert werden

• Verweigern, dass Sicherheits-/Vorfallreaktionsrollen gelöscht oder

modifiziert werden.

• Verweigern, dass Backups gelöscht werden.
• Verweigern, dass IAM-Benutzer und Zugriffsschlüssel erstellt werden

Finden Sie JSON-Beispiele in https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html

Resource Control Policy (RCP)

Eine Resource Control Policy (RCP) ist eine Richtlinie, die die maximalen Berechtigungen für Ressourcen innerhalb Ihrer AWS-Organisation definiert. RCPs sind in der Syntax ähnlich wie IAM-Richtlinien, gewähren jedoch keine Berechtigungen—sie begrenzen nur die Berechtigungen, die von anderen Richtlinien auf Ressourcen angewendet werden können. Wenn Sie eine RCP an die Root-Organisation, eine organisatorische Einheit (OU) oder ein Konto anhängen, beschränkt die RCP die Ressourcenberechtigungen für alle Ressourcen im betroffenen Bereich.

Dies ist der EINZIGE Weg, um sicherzustellen, dass Ressourcen die vordefinierten Zugriffslevel nicht überschreiten—selbst wenn eine identitätsbasierte oder ressourcenbasierte Richtlinie zu großzügig ist. Der einzige Weg, diese Grenzen zu umgehen, besteht darin, auch die RCP zu ändern, die von dem Verwaltungskonto Ihrer Organisation konfiguriert wurde.

RCP-Beispiele:

• S3-Buckets so einschränken, dass sie nur von Prinzipalen innerhalb Ihrer Organisation zugegriffen werden können
• KMS-Schlüsselverwendung auf nur vertrauenswürdige organisatorische Konten beschränken
• Berechtigungen für SQS-Warteschlangen begrenzen, um unbefugte Änderungen zu verhindern
• Zugriffsgrenzen für Secrets Manager-Geheimnisse durchsetzen, um sensible Daten zu schützen

Finden Sie Beispiele in AWS Organizations Resource Control Policies documentation

ARN

Amazon Resource Name ist der einzigartige Name, den jede Ressource innerhalb von AWS hat, er setzt sich wie folgt zusammen:

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Beachten Sie, dass es 4 Partitionen in AWS gibt, aber nur 3 Möglichkeiten, sie zu benennen:

• AWS Standard: aws
• AWS China: aws-cn
• AWS US public Internet (GovCloud): aws-us-gov
• AWS Secret (US Classified): aws

IAM - Identity and Access Management

IAM ist der Dienst, der es Ihnen ermöglicht, Authentifizierung, Autorisierung und Zugriffskontrolle innerhalb Ihres AWS-Kontos zu verwalten.

• Authentifizierung - Prozess der Definition einer Identität und der Überprüfung dieser Identität. Dieser Prozess kann unterteilt werden in: Identifikation und Verifizierung.
• Autorisierung - Bestimmt, auf was eine Identität innerhalb eines Systems zugreifen kann, nachdem sie authentifiziert wurde.
• Zugriffskontrolle - Die Methode und der Prozess, wie der Zugriff auf eine sichere Ressource gewährt wird.

IAM kann durch seine Fähigkeit definiert werden, Authentifizierungs-, Autorisierungs- und Zugriffskontrollmechanismen von Identitäten zu Ihren Ressourcen innerhalb Ihres AWS-Kontos zu verwalten, zu steuern und zu regeln.

AWS account root user

Wenn Sie zum ersten Mal ein Amazon Web Services (AWS) Konto erstellen, beginnen Sie mit einer einzigen Anmeldedaten, die vollständigen Zugriff auf alle AWS-Dienste und Ressourcen im Konto hat. Dies ist der Root-Benutzer des AWS-Kontos und wird durch die Anmeldung mit der E-Mail-Adresse und dem Passwort, die Sie zur Erstellung des Kontos verwendet haben, aufgerufen.

Beachten Sie, dass ein neuer Admin-Benutzer weniger Berechtigungen als der Root-Benutzer hat.

Aus sicherheitstechnischer Sicht wird empfohlen, andere Benutzer zu erstellen und diesen zu vermeiden.

IAM users

Ein IAM Benutzer ist eine Entität, die Sie in AWS erstellen, um die Person oder Anwendung zu repräsentieren, die damit interagiert. Ein Benutzer in AWS besteht aus einem Namen und Anmeldeinformationen (Passwort und bis zu zwei Zugriffsschlüssel).

Wenn Sie einen IAM-Benutzer erstellen, gewähren Sie ihm Berechtigungen, indem Sie ihn zu einer Gruppe von Benutzern machen, die über geeignete Berechtigungspolicen verfügt (empfohlen), oder indem Sie Richtlinien direkt an den Benutzer anhängen.

Benutzer können MFA aktivieren, um sich über die Konsole anzumelden. API-Token von MFA-aktivierten Benutzern sind nicht durch MFA geschützt. Wenn Sie den Zugriff auf die API-Schlüssel eines Benutzers mithilfe von MFA einschränken möchten, müssen Sie in der Richtlinie angeben, dass MFA erforderlich ist, um bestimmte Aktionen auszuführen (Beispiel hier).

CLI

• Access Key ID: 20 zufällige Großbuchstaben-Zahlenkombinationen wie AKHDNAPO86BSHKDIRYT
• Secret access key ID: 40 zufällige Groß- und Kleinbuchstaben: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Es ist nicht möglich, verlorene Secret Access Key IDs wiederherzustellen).

Wann immer Sie den Access Key ändern müssen, sollten Sie diesen Prozess befolgen:
Einen neuen Zugriffsschlüssel erstellen -> Den neuen Schlüssel auf das System/die Anwendung anwenden -> Den ursprünglichen als inaktiv markieren -> Testen und überprüfen, ob der neue Zugriffsschlüssel funktioniert -> Alten Zugriffsschlüssel löschen

MFA - Multi Factor Authentication

Es wird verwendet, um einen zusätzlichen Faktor für die Authentifizierung zusätzlich zu Ihren bestehenden Methoden, wie Passwort, zu erstellen und somit ein mehrstufiges Authentifizierungsniveau zu schaffen.
Sie können eine kostenlose virtuelle Anwendung oder ein physisches Gerät verwenden. Sie können Apps wie Google Authenticator kostenlos verwenden, um MFA in AWS zu aktivieren.

Richtlinien mit MFA-Bedingungen können an Folgendes angehängt werden:

• Ein IAM-Benutzer oder eine Gruppe
• Eine Ressource wie einen Amazon S3-Bucket, eine Amazon SQS-Warteschlange oder ein Amazon SNS-Thema
• Die Vertrauensrichtlinie einer IAM-Rolle, die von einem Benutzer übernommen werden kann

Wenn Sie über die CLI auf eine Ressource zugreifen möchten, die MFA überprüft, müssen Sie GetSessionToken aufrufen. Das gibt Ihnen ein Token mit Informationen über MFA.
Beachten Sie, dass AssumeRole-Anmeldeinformationen diese Informationen nicht enthalten.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Wie hier angegeben, gibt es viele verschiedene Fälle, in denen MFA nicht verwendet werden kann.

IAM-Benutzergruppen

Eine IAM Benutzergruppe ist eine Möglichkeit, Richtlinien gleichzeitig mehreren Benutzern zuzuordnen, was die Verwaltung der Berechtigungen für diese Benutzer erleichtern kann. Rollen und Gruppen können kein Teil einer Gruppe sein.

Sie können eine identitätsbasierte Richtlinie an eine Benutzergruppe anhängen, sodass alle Benutzer in der Benutzergruppe die Berechtigungen der Richtlinie erhalten. Sie können eine Benutzergruppe nicht als Principal in einer Richtlinie (wie einer ressourcenbasierten Richtlinie) identifizieren, da Gruppen sich auf Berechtigungen beziehen, nicht auf Authentifizierung, und Principals authentifizierte IAM-Entitäten sind.

Hier sind einige wichtige Merkmale von Benutzergruppen:

• Eine Benutzer gruppe kann viele Benutzer enthalten, und ein Benutzer kann zu mehreren Gruppen gehören.
• Benutzergruppen können nicht geschachtelt werden; sie können nur Benutzer enthalten, keine anderen Benutzergruppen.
• Es gibt keine Standardbenutzergruppe, die automatisch alle Benutzer im AWS-Konto einschließt. Wenn Sie eine solche Benutzergruppe haben möchten, müssen Sie sie erstellen und jeden neuen Benutzer zuweisen.
• Die Anzahl und Größe der IAM-Ressourcen in einem AWS-Konto, wie die Anzahl der Gruppen und die Anzahl der Gruppen, denen ein Benutzer angehören kann, sind begrenzt. Weitere Informationen finden Sie in den IAM- und AWS STS-Quoten.

IAM-Rollen

Eine IAM Rolle ist sehr ähnlich zu einem Benutzer, da sie eine Identität mit Berechtigungspolitiken ist, die bestimmen, was sie in AWS tun kann und was nicht. Eine Rolle hat jedoch keine Anmeldeinformationen (Passwort oder Zugriffsschlüssel), die mit ihr verbunden sind. Anstatt eindeutig mit einer Person verbunden zu sein, ist eine Rolle dazu gedacht, von jedem übernommen zu werden, der sie benötigt (und genügend Berechtigungen hat). Ein IAM-Benutzer kann eine Rolle übernehmen, um vorübergehend andere Berechtigungen für eine bestimmte Aufgabe zu übernehmen. Eine Rolle kann einem federierten Benutzer zugewiesen werden, der sich über einen externen Identitätsanbieter anstelle von IAM anmeldet.

Eine IAM-Rolle besteht aus zwei Arten von Richtlinien: einer Vertrauensrichtlinie, die nicht leer sein kann und definiert, wer die Rolle übernehmen kann, und einer Berechtigungsrichtlinie, die nicht leer sein kann und definiert, auf was sie zugreifen kann.

AWS Security Token Service (STS)

AWS Security Token Service (STS) ist ein Webdienst, der die Ausstellung von temporären, eingeschränkten Anmeldeinformationen erleichtert. Er ist speziell auf folgende Aspekte zugeschnitten:

Temporäre Anmeldeinformationen in IAM

Temporäre Anmeldeinformationen werden hauptsächlich mit IAM-Rollen verwendet, es gibt jedoch auch andere Verwendungen. Sie können temporäre Anmeldeinformationen anfordern, die einen eingeschränkteren Satz von Berechtigungen haben als Ihr standardmäßiger IAM-Benutzer. Dies verhindert, dass Sie versehentlich Aufgaben ausführen, die nicht erlaubt sind durch die eingeschränkten Anmeldeinformationen. Ein Vorteil von temporären Anmeldeinformationen ist, dass sie automatisch nach einer festgelegten Zeitspanne ablaufen. Sie haben die Kontrolle über die Dauer, für die die Anmeldeinformationen gültig sind.

Richtlinien

Richtlinienberechtigungen

Werden verwendet, um Berechtigungen zuzuweisen. Es gibt 2 Arten:

• AWS verwaltete Richtlinien (vorkonfiguriert von AWS)
• Kundenverwaltete Richtlinien: Von Ihnen konfiguriert. Sie können Richtlinien basierend auf AWS verwalteten Richtlinien erstellen (eine davon ändern und Ihre eigene erstellen), den Richtlinien-Generator verwenden (eine GUI-Ansicht, die Ihnen hilft, Berechtigungen zu gewähren und zu verweigern) oder Ihre eigenen schreiben.

Standardmäßig ist der Zugriff verweigert, der Zugriff wird gewährt, wenn eine explizite Rolle angegeben wurde.
Wenn einzelne "Deny" existiert, wird es das "Allow" überschreiben, mit Ausnahme von Anfragen, die die Root-Sicherheitsanmeldeinformationen des AWS-Kontos verwenden (die standardmäßig erlaubt sind).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Die globalen Felder, die für Bedingungen in jedem Dienst verwendet werden können, sind hier dokumentiert.
Die spezifischen Felder, die für Bedingungen pro Dienst verwendet werden können, sind hier dokumentiert.

Inline-Richtlinien

Diese Art von Richtlinien wird direkt einem Benutzer, einer Gruppe oder einer Rolle zugewiesen. Daher erscheinen sie nicht in der Richtlinienliste, da sie von niemand anderem verwendet werden können.
Inline-Richtlinien sind nützlich, wenn Sie eine strikte Eins-zu-eins-Beziehung zwischen einer Richtlinie und der Identität aufrechterhalten möchten, auf die sie angewendet wird. Zum Beispiel möchten Sie sicherstellen, dass die Berechtigungen in einer Richtlinie nicht versehentlich einer anderen Identität zugewiesen werden, als der, für die sie bestimmt sind. Wenn Sie eine Inline-Richtlinie verwenden, können die Berechtigungen in der Richtlinie nicht versehentlich der falschen Identität zugeordnet werden. Darüber hinaus werden die in der Identität eingebetteten Richtlinien ebenfalls gelöscht, wenn Sie die AWS Management Console verwenden, um diese Identität zu löschen. Das liegt daran, dass sie Teil der Hauptentität sind.

Ressourcen-Bucket-Richtlinien

Dies sind Richtlinien, die in Ressourcen definiert werden können. Nicht alle Ressourcen von AWS unterstützen sie.

Wenn eine Hauptentität keinen ausdrücklichen Verweigerung auf ihnen hat und eine Ressourcenrichtlinie ihnen Zugriff gewährt, dann sind sie erlaubt.

IAM-Grenzen

IAM-Grenzen können verwendet werden, um die Berechtigungen, auf die ein Benutzer oder eine Rolle Zugriff haben sollte, zu beschränken. Auf diese Weise wird die Operation fehlschlagen, selbst wenn ein anderes Set von Berechtigungen dem Benutzer durch eine andere Richtlinie gewährt wird, wenn er versucht, sie zu verwenden.

Eine Grenze ist einfach eine Richtlinie, die einem Benutzer angehängt ist und das maximale Niveau der Berechtigungen angibt, die der Benutzer oder die Rolle haben kann. Selbst wenn der Benutzer Administratorzugriff hat, wenn die Grenze angibt, dass er nur S· Buckets lesen kann, ist das das Maximum, was er tun kann.

Dies, SCPs und die Einhaltung des Prinzips der minimalen Berechtigung sind die Möglichkeiten, um zu kontrollieren, dass Benutzer nicht mehr Berechtigungen haben, als sie benötigen.

Sitzungsrichtlinien

Eine Sitzungsrichtlinie ist eine Richtlinie, die festgelegt wird, wenn eine Rolle angenommen wird. Dies wird wie eine IAM-Grenze für diese Sitzung sein: Das bedeutet, dass die Sitzungsrichtlinie keine Berechtigungen gewährt, sondern sie auf die in der Richtlinie angegebenen beschränkt (wobei die maximalen Berechtigungen die sind, die die Rolle hat).

Dies ist nützlich für Sicherheitsmaßnahmen: Wenn ein Administrator eine sehr privilegierte Rolle annehmen möchte, könnte er die Berechtigungen auf nur die in der Sitzungsrichtlinie angegebenen beschränken, falls die Sitzung kompromittiert wird.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

Hinweis: Standardmäßig kann AWS Sitzungspolicies zu Sitzungen hinzufügen, die aus anderen Gründen generiert werden. Zum Beispiel in unauthentifizierten Cognito-angenommenen Rollen wird AWS standardmäßig (unter Verwendung verbesserter Authentifizierung) Sitzungsanmeldeinformationen mit einer Sitzungspolicy generieren, die die Dienste einschränkt, auf die die Sitzung zugreifen kann auf die folgende Liste.

Daher, wenn Sie irgendwann den Fehler "... weil keine Sitzungspolicy das ... erlaubt", und die Rolle Zugriff hat, um die Aktion auszuführen, liegt es daran, dass eine Sitzungspolicy dies verhindert.

Identitätsföderation

Die Identitätsföderation ermöglicht Benutzern von Identitätsanbietern, die extern zu AWS sind, den sicheren Zugriff auf AWS-Ressourcen, ohne AWS-Benutzerdaten von einem gültigen IAM-Benutzerkonto angeben zu müssen.
Ein Beispiel für einen Identitätsanbieter kann Ihr eigenes Unternehmens-Microsoft Active Directory (über SAML) oder OpenID-Dienste (wie Google) sein. Der föderierte Zugriff ermöglicht es dann den Benutzern innerhalb davon, auf AWS zuzugreifen.

Um dieses Vertrauen zu konfigurieren, wird ein IAM-Identitätsanbieter (SAML oder OAuth) generiert, der die andere Plattform vertraut. Dann wird mindestens eine IAM-Rolle (vertrauend) dem Identitätsanbieter zugewiesen. Wenn ein Benutzer von der vertrauenswürdigen Plattform auf AWS zugreift, greift er als die genannte Rolle zu.

Allerdings möchten Sie normalerweise eine andere Rolle je nach Gruppe des Benutzers auf der Drittanbieterplattform vergeben. Dann können mehrere IAM-Rollen dem Drittanbieter-Identitätsanbieter vertrauen, und die Drittanbieterplattform wird diejenige sein, die es Benutzern ermöglicht, eine Rolle oder die andere zu übernehmen.

IAM Identity Center

AWS IAM Identity Center (Nachfolger von AWS Single Sign-On) erweitert die Möglichkeiten von AWS Identity and Access Management (IAM), um einen zentralen Ort bereitzustellen, der die Verwaltung von Benutzern und deren Zugriff auf AWS-Konten und Cloud-Anwendungen zusammenführt.

Die Anmeldedomäne wird etwas sein wie <user_input>.awsapps.com.

Um Benutzer anzumelden, können 3 Identitätsquellen verwendet werden:

• Identity Center Directory: Reguläre AWS-Benutzer
• Active Directory: Unterstützt verschiedene Connectoren
• Externer Identitätsanbieter: Alle Benutzer und Gruppen stammen von einem externen Identitätsanbieter (IdP)

Im einfachsten Fall des Identity Center-Verzeichnisses wird das Identity Center eine Liste von Benutzern & Gruppen haben und in der Lage sein, Richtlinien für sie zu irgendeinem der Konten der Organisation zuzuweisen.

Um einem Benutzer/einer Gruppe im Identity Center Zugriff auf ein Konto zu gewähren, wird ein SAML-Identitätsanbieter, der dem Identity Center vertraut, erstellt, und eine Rolle, die dem Identitätsanbieter mit den angegebenen Richtlinien vertraut, wird im Zielkonto erstellt.

AwsSSOInlinePolicy

Es ist möglich, Berechtigungen über Inline-Richtlinien für Rollen zu vergeben, die über IAM Identity Center erstellt wurden. Die in den Konten erstellten Rollen, die Inline-Richtlinien im AWS Identity Center erhalten, haben diese Berechtigungen in einer Inline-Richtlinie namens AwsSSOInlinePolicy.

Daher bedeutet es nicht, dass, selbst wenn Sie 2 Rollen mit einer Inline-Richtlinie namens AwsSSOInlinePolicy sehen, dass sie die gleichen Berechtigungen haben.

Cross Account Trusts und Rollen

Ein Benutzer (vertrauend) kann eine Cross-Account-Rolle mit einigen Richtlinien erstellen und dann einem anderen Benutzer (vertrauenswürdig) den Zugriff auf sein Konto erlauben, jedoch nur mit dem Zugriff, der in den neuen Rollrichtlinien angegeben ist. Um dies zu erstellen, erstellen Sie einfach eine neue Rolle und wählen Sie Cross-Account-Rolle aus. Rollen für den Cross-Account-Zugriff bieten zwei Optionen. Bereitstellung des Zugriffs zwischen AWS-Konten, die Sie besitzen, und Bereitstellung des Zugriffs zwischen einem Konto, das Sie besitzen, und einem Drittanbieter-AWS-Konto.
Es wird empfohlen, den Benutzer, der vertraut ist, anzugeben und nichts Allgemeines zu verwenden, da sonst andere authentifizierte Benutzer wie föderierte Benutzer dieses Vertrauen ebenfalls missbrauchen können.

AWS Simple AD

Nicht unterstützt:

• Vertrauensverhältnisse
• AD-Admin-Center
• Vollständige PS-API-Unterstützung
• AD-Warenkorb
• Gruppenverwaltete Dienstkonten
• Schemaerweiterungen
• Kein direkter Zugriff auf OS oder Instanzen

Web-Föderation oder OpenID-Authentifizierung

Die App verwendet AssumeRoleWithWebIdentity, um temporäre Anmeldeinformationen zu erstellen. Dies gewährt jedoch keinen Zugriff auf die AWS-Konsole, sondern nur auf Ressourcen innerhalb von AWS.

Weitere IAM-Optionen

• Sie können eine Passwortrichtlinieneinstellung wie Mindestlänge und Passwortanforderungen festlegen.
• Sie können einen "Credential Report" herunterladen, der Informationen über aktuelle Anmeldeinformationen (wie Erstellungszeit des Benutzers, ob das Passwort aktiviert ist...) enthält. Sie können einen Credential Report so oft wie einmal alle vier Stunden generieren.

AWS Identity and Access Management (IAM) bietet feingranulare Zugriffskontrolle über alle AWS-Dienste. Mit IAM können Sie festlegen, wer auf welche Dienste und Ressourcen zugreifen kann und unter welchen Bedingungen. Mit IAM-Richtlinien verwalten Sie Berechtigungen für Ihre Mitarbeiter und Systeme, um die minimalen Berechtigungen sicherzustellen.

IAM-ID-Präfixe

Auf dieser Seite finden Sie die IAM-ID-Präfixe von Schlüsseln, abhängig von ihrer Natur:

| ACCA | Kontextabhängige Anmeldeinformationen | | AGPA | Benutzergruppe | | AIDA | IAM-Benutzer | | AIPA | Amazon EC2-Instanzprofil | | AKIA | Zugriffsschlüssel | | ANPA | Verwaltete Richtlinie | | ANVA | Version in einer verwalteten Richtlinie | | APKA | Öffentliches Schlüssel | | AROA | Rolle | | ASCA | Zertifikat | | ASIA | Temporäre (AWS STS) Zugriffsschlüssel-IDs verwenden dieses Präfix, sind jedoch nur in Kombination mit dem geheimen Zugriffsschlüssel und dem Sitzungstoken eindeutig. |

Empfohlene Berechtigungen zur Überprüfung von Konten

Die folgenden Berechtigungen gewähren verschiedenen Lesezugriff auf Metadaten:

• arn:aws:iam::aws:policy/SecurityAudit
• arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
• codebuild:ListProjects
• config:Describe*
• cloudformation:ListStacks
• logs:DescribeMetricFilters
• directconnect:DescribeConnections
• dynamodb:ListTables

Sonstiges

CLI-Authentifizierung

Damit ein regulärer Benutzer sich über die CLI bei AWS authentifizieren kann, müssen lokale Anmeldeinformationen vorhanden sein. Standardmäßig können Sie diese manuell in ~/.aws/credentials konfigurieren oder ausführen aws configure.
In dieser Datei können Sie mehr als ein Profil haben. Wenn kein Profil angegeben ist, wird das in dieser Datei als [default] bezeichnete verwendet.
Beispiel einer Anmeldeinformationsdatei mit mehr als 1 Profil:

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Wenn Sie auf verschiedene AWS-Konten zugreifen müssen und Ihr Profil Zugriff auf eine Rolle innerhalb dieser Konten erhalten hat, müssen Sie nicht jedes Mal manuell STS aufrufen (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) und die Anmeldeinformationen konfigurieren.

Sie können die Datei ~/.aws/config verwenden, um anzugeben, welche Rollen übernommen werden sollen, und dann den Parameter --profile wie gewohnt verwenden (die assume-role wird für den Benutzer transparent durchgeführt).
Ein Beispiel für eine Konfigurationsdatei:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Mit dieser Konfigurationsdatei können Sie dann aws cli verwenden wie:

aws --profile acc2 ...

Wenn Sie nach etwas ähnlichem suchen, aber für den Browser, können Sie die Erweiterung AWS Extend Switch Roles überprüfen.

Automatisierung temporärer Anmeldeinformationen

Wenn Sie eine Anwendung ausnutzen, die temporäre Anmeldeinformationen generiert, kann es mühsam sein, diese alle paar Minuten in Ihrem Terminal zu aktualisieren, wenn sie ablaufen. Dies kann behoben werden, indem eine credential_process-Direktive in der Konfigurationsdatei verwendet wird. Zum Beispiel, wenn Sie eine anfällige Webanwendung haben, könnten Sie Folgendes tun:

[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com

Beachten Sie, dass Anmeldeinformationen in jedem Fall im folgenden Format an STDOUT zurückgegeben werden müssen:

{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}

Referenzen

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html
• https://aws.amazon.com/iam/
• https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
• https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/