SEC03-BP05 Definieren eines Integritätsschutzes für Berechtigungen in Ihrer Organisation - Säule „Sicherheit“

SEC03-BP05 Definieren eines Integritätsschutzes für Berechtigungen in Ihrer Organisation

Verwenden Sie Maßnahmen zum Integritätsschutz, um den Umfang der verfügbaren Berechtigungen, die Prinzipalen gewährt werden können, einzuschränken. Die Bewertungskette für Berechtigungsrichtlinien umfasst Ihren Integritätsschutz, um die effektiven Berechtigungen eines Prinzipals bei Autorisierungsentscheidungen zu bestimmen.  Sie können Maßnahmen zum Integritätsschutz mit einem ebenenbasierten Ansatz definieren. Wenden Sie einige Maßnahmen zum Integritätsschutz allgemein für Ihre gesamte Organisation an und andere granular auf Sitzungen mit temporärem Zugriff.

Gewünschtes Ergebnis: Sie haben eine klare Isolierung der Umgebungen durch separate AWS-Konten.  Service-Kontrollrichtlinien (SCPs) werden verwendet, um organisationsweite Maßnahmen zum Integritätsschutz zu definieren. Umfassender angelegte Maßnahmen zu Integritätsschutz werden auf den Hierarchieebenen festgelegt, die der Root Ihrer Organisation am nächsten sind, und strengerer Integritätsschutz wird näher an der Ebene der einzelnen Konten festgelegt.  Sofern unterstützt, definieren Ressourcenrichtlinien die Bedingungen, die ein Prinzipal erfüllen muss, um Zugriff auf eine Ressource zu erhalten. Die Ressourcenrichtlinien schränken auch den Umfang der erlaubten Aktionen ein, wo dies angebracht ist.  Berechtigungsgrenzen werden auf Prinzipale verteilt, die Workload-Berechtigungen verwalten und die Verwaltung von Berechtigungen an einzelne Workload-Besitzer delegieren.

Typische Anti-Muster:

  • Erstellen eines AWS-Konten als Mitglied innerhalb einer AWS-Organisation, aber keine Verwendung von SCPs, um die Verwendung und die verfügbaren Berechtigungen für ihre Anmeldeinformationen einzuschränken

  • Zuweisung von Berechtigungen auf der Grundlage der geringsten Berechtigung, aber kein Integritätsschutz für die maximale Anzahl von Berechtigungen, die gewährt werden können

  • Vertrauen auf die implizite Verweigerungsgrundlage von AWS IAM, um Berechtigungen einzuschränken, in der Annahme, dass die Richtlinien keine unerwünschte explizite Erlaubnis erteilen werden

  • mehrere Workload-Umgebungen im selben AWS-Konto ausführen und sich dann auf Mechanismen wie VPCs, Tags oder Ressourcenrichtlinien verlassen, um Berechtigungsgrenzen durchzusetzen

Vorteile der Einführung dieser bewährten Methode: Einrichtungen zum Integritätsschutz helfen dabei, Vertrauen zu schaffen, dass unerwünschte Berechtigungen nicht gewährt werden können, selbst wenn eine Berechtigungsrichtlinie dies versucht.  Dies kann die Definition und Verwaltung von Berechtigungen vereinfachen, da der maximale Umfang der zu berücksichtigenden Berechtigungen reduziert wird.

Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: mittel

Implementierungsleitfaden

Wir empfehlen Ihnen, einen ebenenbasierten Ansatz zu verwenden, um für Maßnahmen für den Integritätsschutz für Ihre Organisation zu definieren. Dieser Ansatz reduziert systematisch die maximale Anzahl der möglichen Berechtigungen, wenn weitere Ebenen hinzugefügt werden. So können Sie den Zugriff nach dem Prinzip der geringsten Berechtigung gewähren und das Risiko eines unbeabsichtigten Zugriffs aufgrund einer falschen Konfiguration der Richtlinie verringern.

Der erste Schritt zur Einrichtung zum Integritätsschutz ist die Isolierung Ihrer Workloads und Umgebungen in getrennten AWS-Konten.  Prinzipale eines Kontos können ohne ausdrückliche Erlaubnis nicht auf die Ressourcen eines anderen Kontos zugreifen, selbst wenn sich beide Konten in derselben AWS-Organisation oder unter derselben Organisationseinheit (OE) befinden.  Sie können OEs verwenden, um Konten zu gruppieren, die Sie als eine Einheit verwalten möchten.   

Der nächste Schritt besteht darin, die maximale Anzahl von Berechtigungen zu reduzieren, die Sie Prinzipalen innerhalb der Mitgliedskonten Ihrer Organisation erteilen können.  Zu diesem Zweck können Sie Service-Kontrollrichtlinien (SCPs) verwenden, die Sie entweder auf eine OE oder ein Konto anwenden können.  SCPs können allgemeine Zugriffskontrollen durchsetzen, wie z. B. die Beschränkung des Zugriffs auf bestimmte AWS-Regionen, die Verhinderung des Löschens von Ressourcen oder die Deaktivierung potenziell riskanter Serviceaktionen.   SCPs, die Sie auf das Root-Verzeichnis Ihrer Organisation anwenden, wirken sich nur auf die Mitgliedskonten aus, nicht auf das Verwaltungskonto.  SCPs regeln nur die Prinzipale innerhalb Ihrer Organisation. Ihre SCPs regeln keine Prinzipale außerhalb Ihrer Organisation, die auf Ihre Ressourcen zugreifen.

Ein weiterer Schritt ist die Verwendung von IAM-Ressourcenrichtlinien, um die verfügbaren Aktionen, die Sie für die von ihnen geregelten Ressourcen durchführen können, zusammen mit den Bedingungen, die der handelnde Prinzipal erfüllen muss, zu definieren.  Dies kann so weit gefasst sein, dass alle Aktionen erlaubt sind, solange das Prinzipal zu Ihrer Organisation gehört (unter Verwendung des Bedingungsschlüssels PrincipalOrgId), oder so granular, dass nur bestimmte Aktionen von einer bestimmten IAM-Rolle erlaubt sind.  Sie können einen ähnlichen Ansatz mit Bedingungen in IAM-Rollenvertrauensrichtlinien verfolgen.  Wenn eine Vertrauensrichtlinie für eine Ressource oder Rolle explizit einen Prinzipal im selben Konto wie die Rolle oder Ressource benennt, die sie regelt, benötigt dieser Prinzipal keine angehängte IAM-Richtlinie, die dieselben Berechtigungen gewährt.  Wenn der Prinzipal ein anderes Konto hat als die Ressource, dann benötigt der Prinzipal eine angehängte IAM-Richtlinie, die diese Berechtigungen gewährt.

Oft möchte ein Workload-Team die für seinen Workload erforderlichen Berechtigungen verwalten.  Dazu muss es möglicherweise neue IAM-Rollen und Berechtigungsrichtlinien erstellen.  Sie können den maximalen Umfang der Berechtigungen, die das Team gewähren darf, in einer IAM-Berechtigungsgrenze erfassen und dieses Dokument mit einer IAM-Rolle verknüpfen, die das Team dann zur Verwaltung seiner IAM-Rollen und Berechtigungen verwenden kann.  Dieser Ansatz kann ihm die Freiheit geben, ihre Arbeit zu erledigen und gleichzeitig die Risiken eines administrativen IAM-Zugriffs verringern.

Ein detaillierterer Schritt ist die Implementierung von Techniken zur Verwaltung von privilegiertem Zugriff (Privileged Access Management, PAM) und temporärer erweiterter Zugriffsverwaltung (Temporary Elevated Access Management, TEAM).  Ein Beispiel für PAM ist die Anforderung an Prinzipale, sich mehrfach zu authentifizieren, bevor sie privilegierte Aktionen durchführen.  Weitere Informationen finden Sie unter Configuring MFA-protected API access. TEAM benötigt eine Lösung, die die Genehmigung und den Zeitrahmen verwaltet, in dem ein Prinzipal erweiterten Zugriff haben darf.  Eine Möglichkeit besteht darin, den Prinzipal vorübergehend in die Vertrauensrichtlinie für eine IAM-Rolle aufzunehmen, die über einen erweiterten Zugriff verfügt.  Ein anderer Ansatz besteht darin, im Normalbetrieb die Berechtigungen, die einem Prinzipal von einer IAM-Rolle gewährt werden, mit einer Sitzungsrichtlinie einzuschränken und diese Einschränkung dann während des genehmigten Zeitfensters vorübergehend aufzuheben. Weitere Informationen über Lösungen, die AWS und ausgewählte Partner validiert haben, finden Sie unter Temporär erweiterter Zugriff.

Implementierungsschritte

  1. Isolieren Sie Ihre Workloads und Umgebungen in separaten AWS-Konten.

  2. Verwenden Sie SCPs, um die maximale Anzahl von Berechtigungen zu reduzieren, die Prinzipalen innerhalb der Mitgliedskonten Ihrer Organisation gewährt werden können.

    1. Wir empfehlen Ihnen, Ihre SCPs nach dem Prinzip der Erlaubnisliste zu schreiben, die alle Aktionen verweigert, außer denen, die Sie erlauben, und den Bedingungen, unter denen sie erlaubt sind. Beginnen Sie damit, die Ressourcen zu definieren, die Sie kontrollieren möchten, und setzen Sie den Effekt auf Verweigern. Verwenden Sie das NotAction-Element, um alle Aktionen zu verweigern, außer denen, die Sie angeben. Kombinieren Sie dies mit einer NotLike-Bedingung, um festzulegen, wann diese Aktionen erlaubt sind, falls zutreffend, wie z. B. StringNotLike und ArnNotLike.

    2. Siehe Service control policy examples.

  3. Verwenden Sie IAM-Ressourcenrichtlinien, um den Geltungsbereich einzugrenzen und Bedingungen für zulässige Aktionen auf Ressourcen festzulegen.  Verwenden Sie Bedingungen in IAM-Rollenvertrauensrichtlinien, um Einschränkungen für die Übernahme von Rollen zu erstellen.

  4. Weisen Sie IAM-Berechtigungsgrenzen zu IAM-Rollen zu, die Workload-Teams dann zur Verwaltung ihrer eigenen Workloads IAM-Rollen und -Berechtigungen verwenden können.

  5. Evaluieren Sie PAM- und TEAM-Lösungen auf der Grundlage Ihrer Bedürfnisse.

Ressourcen

Zugehörige Dokumente:

Zugehörige Beispiele:

Zugehörige Tools: