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:

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.

Wenn Sie AWS Control Tower verwenden, können Sie die Steuerungen und Landing Zones als Grundlage für Ihren Integritätsschutz für Berechtigungen und Ihre Multi-Konten-Umgebung nutzen. Die Landing Zones bieten eine vorkonfigurierte, sichere Basisumgebung mit getrennten Konten für verschiedene Workloads und Anwendungen. Der Integritätsschutz setzt verbindliche Kontrollen in Bezug auf Sicherheit, Betrieb und Compliance durch eine Kombination aus Service-Kontrollrichtlinien (SCPs), AWS Config-Regeln und anderen Konfigurationen durch. Bei der Verwendung von Integritätsschutz und Landing Zones im Control Tower zusammen mit SCPs, die für die Kundenorganisation spezifisch sind, ist es jedoch kritisch, die in der AWS-Dokumentation beschriebenen Best Practices zu befolgen, um Konflikte zu vermeiden und eine angemessene Steuerung sicherzustellen. Detaillierte Empfehlungen zur Verwaltung von SCPs, Konten und Organisationseinheiten (OUs) in einer Control-Tower-Umgebung finden Sie in der AWS Control Tower-Anleitung für AWS Organizations.

Wenn Sie sich an diese Empfehlungen halten, können Sie den Integritätsschutz, die Landing Zones und die benutzerdefinierten SCPs von Control Tower effektiv nutzen. Gleichzeitig vermeiden Sie potenzielle Konflikte und stellen eine angemessene Verwaltung und Kontrolle Ihrer AWS-Umgebung mit mehreren Konten sicher.

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 dem Team die nötige Flexibilität bieten, die Aufgaben zu erledigen, und gleichzeitig die Risiken reduzieren, die durch einen IAM-Verwaltungszugriff entstehen.

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

Ressourcen

Zugehörige Dokumente:

Zugehörige Beispiele:

Zugehörige Tools: