SEC03-BP05 Definieren eines Integritätsschutzes für Berechtigungen in Ihrer Organisation - AWS Well-Architected Framework

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 Genehmigungsrichtlinien umfasst Ihren Integritätsschutz, um bei Autorisierungsentscheidungen die effektiven Berechtigungen eines Prinzipals 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: Die Umgebungen sind durch die Verwendung separater AWS-Konten klar voneinander abgegrenzt.  Service-Kontrollrichtlinien (SCP) 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:

  • AWS-Konten für Mitglieder werden innerhalb einer AWS-Organisation erstellt, ohne dass SCPs verwendet werden, um die Nutzung und die für ihre Root-Anmeldeinformationen verfügbaren Rechte 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

  • Sie verlassen sich bei der Einschränkung von Berechtigungen auf die implizite Ablehnungsgrundlage von AWS IAM und vertrauen darauf, dass Richtlinien keine unerwünschte ausdrückliche Genehmigungsberechtigung gewähren.

  • 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 Nutzung dieser bewährten Methode: Durch den Integritätsschutz für Berechtigungen kann das Vertrauen gestärkt werden, dass keine unerwünschten Berechtigungen erteilt 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 Genehmigung nicht auf Ressourcen in einem anderen Konto zugreifen, selbst wenn sich beide Konten in derselben AWS-Organisation oder 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 (SCP) verwenden, die Sie entweder auf eine Organisationseinheit oder ein Konto anwenden können.  SCPs können allgemeine Zugriffskontrollen durchsetzen, etwa 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 besteht darin, mithilfe von IAM-Ressourcenrichtlinien die verfügbaren Aktionen festzulegen, die Sie für die zugehörigen Ressourcen ausführen können – zusammen mit allen Bedingungen, die der aktuelle Prinzipal erfüllen muss.  Dies kann so breit gefasst sein, dass alle Aktionen zugelassen werden, solange der Prinzipal Teil Ihrer Organisation ist (unter Verwendung des Bedingungsschlüssels PrincipalOrgID), oder so detailliert sein, dass nur bestimmte Aktionen einer bestimmten IAM-Rolle zugelassen werden.  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 seine Workload erforderlichen Berechtigungen verwalten.  Dazu muss es möglicherweise neue IAM-Rollen und Berechtigungsrichtlinien erstellen.  Sie können den maximalen Umfang der Berechtigungen erfassen, die das Team innerhalb einer IAM-Berechtigungsgrenze gewähren darf, und dieses Dokument einer IAM-Rolle zuordnen, mit der das Team dann seine IAM-Rollen und -Berechtigungen verwalten kann.  Dieser Ansatz kann ihm die Möglichkeit bieten, ihre Arbeit zu erledigen und gleichzeitig die Risiken eines administrativen IAM-Zugriffs verringern.

Ein detaillierterer Schritt ist die Implementierung von Techniken zur Verwaltung des privilegierten Zugriffs (PAM) und zur Verwaltung des vorübergehend erhöhten Zugriffs (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 Konfigurieren eines MFA-geschützten API-Zugriffs. 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 einem Prinzipal durch eine IAM-Rolle gewährten Berechtigungen mithilfe einer Sitzungsrichtlinie einzuschränken und diese Einschränkung dann während des genehmigten Zeitfensters vorübergehend aufzuheben. Weitere Informationen zu Lösungen, die AWS und ausgewählte Partner validiert haben, finden Sie unter Temporärer 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. Weitere Informationen finden Sie unter Beispiele für Service-Kontrollrichtlinie.

  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 Workload-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: