IAM-Ressourcen - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

IAM-Ressourcen

Beeinflussen Sie die future der AWS Security Reference Architecture (AWSSRA), indem Sie an einer kurzen Umfrage teilnehmen.

AWS Identity and Access Management (IAM) ist zwar kein Service, der in einem herkömmlichen Architekturdiagramm enthalten ist, betrifft jedoch jeden Aspekt der AWS-Organisation, der AWS-Konten und der AWS-Services. Sie können keine AWS-Services bereitstellen, ohne zuerst IAM-Entitäten zu erstellen und Berechtigungen zu erteilen. Eine vollständige Erläuterung von IAM würde den Rahmen dieses Dokuments sprengen, aber dieser Abschnitt enthält wichtige Zusammenfassungen von Best-Practice-Empfehlungen und Hinweise auf zusätzliche Ressourcen.

 

Anwendungsfall oder Richtlinie

Effect (Effekt)

Verwaltet von

Zweck

Bezieht sich auf

Wirkt

Eingesetzt in

Service-Kontrollrichtlinien (SCPs)

Restrict

Zentrales Team, z. B. Plattform- oder Sicherheitsteam [1]

Leitplanken, Steuerung

Organisation, Organisationseinheit, Konto

Alle Principals in Organisation, OU und Konten

Konto für die Unternehmensverwaltung [2]

Grundlegende Richtlinien zur Kontoautomatisierung (die IAM-Rollen, die von der Plattform für den Betrieb eines Kontos verwendet werden)

Gewähren und einschränken

Zentrales Team, z. B. Plattform-, Sicherheits- oder IAM-Team [1]

Berechtigungen für (grundlegende) Automatisierungsrollen ohne Arbeitslast [3]

Einzelkonto [4]

Prinzipale, die bei der Automatisierung innerhalb eines Mitgliedskontos verwendet werden

Mitgliedskonten

Grundlegende Personalrichtlinien (die IAM-Rollen, die Benutzern Berechtigungen zur Ausführung ihrer Arbeit gewähren)

Gewähren und einschränken

Zentrales Team, z. B. Plattform-, Sicherheits- oder IAM-Team [1]

Berechtigungen für menschliche Rollen [5]

Einzelkonto [4]

Verbundprinzipale [5] und IAM-Benutzer [6]

Mitgliedskonten

Berechtigungsgrenzen (maximale Berechtigungen, die ein autorisierter Entwickler einem anderen Principal zuweisen kann)

Restrict

Zentrales Team, z. B. Plattform-, Sicherheits- oder IAM-Team [1]

Leitplanken für Anwendungsrollen (müssen angewendet werden)

Einzelkonto [4]

Einzelne Rollen für eine Anwendung oder einen Workload in diesem Konto [7]

Mitgliedskonten

Richtlinien für Maschinenrollen für Anwendungen (Rolle, die der von Entwicklern bereitgestellten Infrastruktur zugewiesen wird)

Gewähren und einschränken

An Entwickler delegiert [8]

Genehmigung für die Anwendung oder den Workload [9]

Einzelnes Konto

Ein Principal auf diesem Konto

Mitgliedskonten

Ressourcenrichtlinien

Gewähren und einschränken

An Entwickler delegiert [8,10]

Berechtigungen für Ressourcen

Ein einziges Konto

Ein Hauptbenutzer auf einem Konto [11]

Mitgliedskonten

  

Anmerkungen aus der Tabelle:

  1. Unternehmen verfügen über viele zentralisierte Teams (z. B. Teams für Cloud-Plattformen, Sicherheitsoperationen oder Identitäts- und Zugriffsmanagement), die die Zuständigkeiten dieser unabhängigen Kontrollen aufteilen und die Richtlinien gegenseitig überprüfen. Die Beispiele in der Tabelle sind Platzhalter. Sie müssen die wirksamste Aufgabentrennung für Ihr Unternehmen festlegen.

  2. Um SCPs verwenden zu können, müssen Sie alle Funktionen in AWS Organizations aktivieren.

  3. Allgemeine Basisrollen und -richtlinien sind im Allgemeinen erforderlich, um die Automatisierung zu ermöglichen, z. B. Berechtigungen für die Pipeline, Bereitstellungstools, Überwachungstools (z. B. AWS Lambda- und AWS Config-Regeln) und andere Berechtigungen. Diese Konfiguration wird normalerweise bereitgestellt, wenn das Konto bereitgestellt wird.

  4. Diese beziehen sich zwar auf eine Ressource (z. B. eine Rolle oder eine Richtlinie) in einem einzelnen Konto, können aber mithilfe von AWS repliziert oder für mehrere Konten bereitgestellt werden. CloudFormation StackSets

  5. Definieren Sie grundlegende menschliche Rollen und Richtlinien, die von einem zentralen Team auf alle Mitgliedskonten angewendet werden (häufig während der Kontobereitstellung). Beispiele hierfür sind die Entwickler im Plattformteam, das IAM-Team und die Sicherheitsprüfungsteams.

  6. Verwenden Sie nach Möglichkeit einen Identitätsverbund (anstelle von lokalen IAM-Benutzern).

  7. Berechtigungsgrenzen werden von delegierten Administratoren verwendet. Diese IAM-Richtlinie definiert die maximalen Berechtigungen und setzt andere Richtlinien außer Kraft (einschließlich “*:*” Richtlinien, die alle Aktionen für Ressourcen zulassen). Berechtigungsgrenzen sollten in den grundlegenden Personalrichtlinien als Voraussetzung für die Erstellung von Rollen (z. B. Rollen für die Workload-Leistung) und das Anhängen von Richtlinien vorgeschrieben sein. Zusätzliche Konfigurationen wie SCPs erzwingen die Festlegung der Rechtegrenzen.

  8. Dies setzt voraus, dass ausreichend Schutzmaßnahmen (z. B. SCPs und Rechtegrenzen) bereitgestellt wurden.

  9. Diese optionalen Richtlinien könnten während der Kontobereitstellung oder als Teil des Anwendungsentwicklungsprozesses bereitgestellt werden. Die Genehmigung zum Erstellen und Anhängen dieser Richtlinien unterliegt den eigenen Berechtigungen des Anwendungsentwicklers.

  10. Zusätzlich zu den lokalen Kontoberechtigungen verwaltet ein zentrales Team (z. B. das Cloud-Plattform-Team oder das Security Operations Team) häufig einige ressourcenbasierte Richtlinien, um einen kontenübergreifenden Zugriff für die Verwaltung der Konten zu ermöglichen (z. B. um Zugriff auf S3-Buckets für die Protokollierung zu gewähren).

  11. Eine ressourcenbasierte IAM-Richtlinie kann sich auf jeden Prinzipal in jedem Konto beziehen, um den Zugriff auf dessen Ressourcen zu gewähren oder zu verweigern. Sie kann sich sogar auf anonyme Principals beziehen, um den öffentlichen Zugriff zu ermöglichen.

 Um das Risiko eines böswilligen oder unbeabsichtigten Missbrauchs von Berechtigungen zu verringern, ist es von entscheidender Bedeutung, sicherzustellen, dass IAM-Identitäten nur über die Berechtigungen verfügen, die für eine genau abgegrenzte Reihe von Aufgaben erforderlich sind. Die Einrichtung und Beibehaltung eines Modells mit den geringsten Rechten erfordert einen durchdachten Plan zur kontinuierlichen Aktualisierung, Bewertung und Reduzierung übermäßiger Rechte. Hier sind einige zusätzliche Empfehlungen für diesen Plan:

  • Verwenden Sie das Governance-Modell Ihrer Organisation und die etablierte Risikobereitschaft, um spezifische Leitplanken und Genehmigungsgrenzen festzulegen.

  • Implementieren Sie Least-Privilegien in einem kontinuierlich iterativen Prozess. Dies ist keine einmalige Übung.

  • Verwenden Sie SCPs, um umsetzbare Risiken zu reduzieren. Dabei handelt es sich um breit angelegte Leitplanken und nicht um eng begrenzte Kontrollen.

  • Verwenden Sie Rechtegrenzen, um die IAM-Verwaltung sicherer zu delegieren.

    • Stellen Sie sicher, dass die delegierten Administratoren den von ihnen erstellten Rollen und Benutzern die entsprechende IAM-Grenzrichtlinie zuordnen.

  • Verwenden Sie als defense-in-depth Ansatz (in Verbindung mit identitätsbasierten Richtlinien) ressourcenbasierte IAM-Richtlinien, um einen umfassenden Zugriff auf Ressourcen zu verweigern.

  • Verwenden Sie IAM Access Advisor, AWS CloudTrail, AWS IAM Access Analyzer und zugehörige Tools, um regelmäßig die historische Nutzung und die erteilten Berechtigungen zu analysieren. Korrigieren Sie sofort offensichtliche Überberechtigungen.

  • Richten Sie allgemeine Aktionen gegebenenfalls auf bestimmte Ressourcen ein, anstatt ein Sternchen als Platzhalter für alle Ressourcen zu verwenden.

  • Implementieren Sie einen Mechanismus, um IAM-Richtlinienausnahmen auf der Grundlage von Anfragen schnell zu identifizieren, zu überprüfen und zu genehmigen.