Der Wert der AWS SRA - AWSPrä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.

Der Wert der AWS SRA

AWS hat eine große (und wachsende)Reihe von sicherheitsbezogenen Diensten. Die Kunden haben ihre Wertschätzung für die detaillierten Informationen in unseren Servicedokumentationen, Blogbeiträgen, Tutorials, Gipfeltreffen und Konferenzen zum Ausdruck gebracht. Sie teilten uns auch mit, dass sie das Gesamtbild besser verstehen und einen strategischen Überblick über die AWS-Sicherheitsservices erhalten möchten. Als wir mit Kunden zusammenarbeiteten, um ein tieferes Verständnis für ihre Bedürfnisse zu erlangen, ergaben sich drei Prioritäten:

  1. Kunden wünschen sich mehr Informationen und empfohlene Muster, wie sie die AWS-Sicherheitsdienste ganzheitlich bereitstellen, konfigurieren und betreiben können. In welchen Konten und für welche Sicherheitsziele sollten die Dienste bereitgestellt und verwaltet werden?  Gibt es ein Sicherheitskonto, in dem alle oder die meisten Dienste funktionieren sollten?  Wie beeinflusst die Wahl des Standorts (Organisationseinheit oder AWS-Konto) die Sicherheitsziele? Welche Kompromisse (Designüberlegungen) sollten Kunden beachten?

  2. Kunden sind an unterschiedlichen Perspektiven für die logische Organisation der vielen AWS-Sicherheitsservices interessiert. Über die Hauptfunktion der einzelnen Dienste (z. B. Identitätsdienste oder Protokollierungsdienste) hinaus helfen diese alternativen Gesichtspunkte Kunden bei der Planung, Gestaltung und Implementierung ihrer Sicherheitsarchitektur. Ein Beispiel, das später in diesem Handbuch vorgestellt wird, fasst die Services auf der Grundlage der Schutzebenen zusammen, die an der empfohlenen Struktur Ihrer AWS-Umgebung ausgerichtet sind.

  3. Kunden suchen nach Anleitungen und Beispielen, um Sicherheitsdienste am effektivsten zu integrieren. Wie sollten sie beispielsweise AWS Config am besten mit anderen Services abstimmen und mit ihnen verbinden, um die schwere Arbeit in automatisierten Prüf- und Überwachungspipelines zu erledigen?  Kunden bitten um Rat, wie sich jeder AWS-Sicherheitsservice auf andere Sicherheitsdienste stützt oder diese unterstützt.

Wir behandeln jedes dieser Punkte in der AWS SRA. Die erste Priorität in der Liste (wohin die Dinge gehen) ist der Schwerpunkt des Hauptarchitekturdiagramms und der begleitenden Diskussionen in diesem Dokument. Wir bieten eine empfohlene Architektur für AWS Organizations und eine account-by-account Beschreibung, welche Dienste wohin gehen.  Um mit der zweiten Priorität in der Liste zu beginnen (wie man über den gesamten Satz von Sicherheitsdiensten nachdenkt), lesen Sie den AbschnittWenden Sie Sicherheitsservices in Ihrer gesamten AWS-Organisation an. In diesem Abschnitt wird beschrieben, wie Sie Sicherheitsdienste gemäß der Struktur der Elemente in Ihrer AWS-Organisation gruppieren können. Dieselben Ideen spiegeln sich auch in der Diskussion desAnwendungskonto, in dem hervorgehoben wird, wie Sicherheitsdienste betrieben werden können, um sich auf bestimmte Ebenen des Kontos zu konzentrieren: Amazon EC2-Instances (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC) -Netzwerke und das breitere Konto verwenden. Schließlich spiegelt sich die dritte Priorität (Serviceintegration) in der gesamten Anleitung wider — insbesondere in der Diskussion einzelner Services in den Abschnitten dieser Dokumentation und im Code im AWS SRA-Code-Repository.

In diesem Abschnitt wird AWS „verwenden

Es gibt verschiedene Möglichkeiten, die AWS SRA zu verwenden, je nachdem, wo Sie sich auf Ihrem Weg zur Einführung der Cloud befinden. Im Folgenden finden Sie eine Liste von Möglichkeiten, um den größtmöglichen Einblick in die AWS SRA-Assets zu gewinnen (Architekturdiagramm, schriftliche Anleitungen und Codebeispiele).

  • Definedder Zielstatus für Ihre eigene Sicherheitsarchitektur.

Ganz gleich, ob Sie gerade Ihre AWS-Cloud-Reise beginnen — mit der Einrichtung Ihrer ersten Gruppe von Konten — oder planen, eine etablierte AWS-Umgebung zu verbessern, die AWS SRA ist der richtige Ort, um mit dem Aufbau Ihrer Sicherheitsarchitektur zu beginnen. Beginnen Sie mit einer umfassenden Grundlage für die Kontostruktur und Sicherheitsdienste, und passen Sie sie dann an Ihren speziellen Technologie-Stack, Ihre Fähigkeiten, Sicherheitsziele und Compliance-Anforderungen an. Wenn Sie wissen, dass Sie mehr Workloads erstellen und starten werden, können Sie Ihre angepasste Version der AWS SRA als Grundlage für die Sicherheitsreferenzarchitektur Ihres Unternehmens verwenden.

  • Prüfen(und überarbeiten) Sie die Designs und Funktionen, die Sie bereits implementiert haben.

Wenn Sie bereits über ein Sicherheitsdesign und eine Implementierung verfügen, lohnt es sich, sich etwas Zeit zu nehmen, um Ihre Daten mit der AWS SRA zu vergleichen. Die AWS SRA ist umfassend konzipiert und bietet eine diagnostische Grundlage für die Überprüfung Ihrer eigenen Sicherheit. Wenn Ihre Sicherheitsdesigns mit der AWS SRA übereinstimmen, können Sie sich sicherer fühlen, dass Sie bei der Verwendung von AWS-Services Best Practices befolgen. Wenn Ihre Sicherheitsdesigns abweichen oder sogar nicht mit den Richtlinien in der AWS SRA übereinstimmen, ist dies nicht unbedingt ein Zeichen dafür, dass Sie etwas falsch machen. Stattdessen bietet Ihnen diese Beobachtung die Möglichkeit, Ihren Entscheidungsprozess zu überprüfen. Es gibt legitime geschäftliche und technologische Gründe, warum Sie von den Best Practices der AWS SRA abweichen könnten. Möglicherweise erfordern Ihre speziellen Compliance-, regulatorischen oder organisatorischen Sicherheitsanforderungen spezifische Servicekonfigurationen. Anstatt AWS-Services zu verwenden, haben Sie möglicherweise eine bevorzugte Funktion für ein Produkt aus dem AWS-Partnernetzwerk oder eine benutzerdefinierte Anwendung, die Sie erstellt und verwaltet haben. Manchmal stellen Sie bei dieser Überprüfung fest, dass Ihre früheren Entscheidungen auf der Grundlage älterer Technologien, AWS-Funktionen oder geschäftlicher Einschränkungen getroffen wurden, die nicht mehr gelten. Dies ist eine gute Gelegenheit, Updates zu überprüfen, zu priorisieren und sie an der entsprechenden Stelle Ihres technischen Backlogs hinzuzufügen. Was auch immer Sie bei der Bewertung Ihrer Sicherheitsarchitektur im Lichte der AWS SRA entdecken, es wird für Sie wertvoll sein, diese Analyse zu dokumentieren. Diese historische Aufzeichnung von Entscheidungen und deren Rechtfertigungen kann dazu beitragen, future Entscheidungen zu informieren und zu priorisieren.

  • Bootstrapdie Implementierung Ihrer eigenen Sicherheitsarchitektur.

Die AWS SRA-Infrastructure as Code (IaC) -Module bieten eine schnelle und zuverlässige Möglichkeit, mit dem Aufbau und der Implementierung Ihrer Sicherheitsarchitektur zu beginnen. Diese Module werden in derCode-Repositoryund in der Berechtigung „verwendenÖffentlichkeit GitHub Endlager. Sie ermöglichen es Ingenieuren nicht nur, auf qualitativ hochwertigen Beispielen der Muster in den AWS SRA-Leitfäden aufzubauen, sondern sie enthalten auch empfohlene Sicherheitskontrollen wie Kennwortrichtlinien für AWS Identity and Access Management (IAM), Amazon Simple Storage Service (Amazon S3), Sperrkonto, öffentlicher Zugriff, Amazon EC2 standardmäßige Amazon Elastic Block Store (Amazon EBS) -Verschlüsselung und Integration mit dem AWS Control Tower, sodass die Kontrollen angewendet oder entfernt werden, wenn neue AWS-Konten aufgenommen oder außer Betrieb genommen werden.

  • Lernenmehr über AWS-Sicherheitsservices und -Funktionen.

Die Anleitungen und Diskussionen in der AWS SRA beinhalten wichtige Funktionen sowie Überlegungen zur Bereitstellung und Verwaltung einzelner AWS-Sicherheits- und sicherheitsbezogener Services. Ein Merkmal der AWS SRA ist, dass sie eine allgemeine Einführung in die Breite der AWS-Sicherheitsdienste und deren Zusammenarbeit in einer Umgebung mit mehreren Konten bietet. Dies ergänzt den tiefen Einblick in die Funktionen und Konfigurationen für jeden Dienst, der in anderen Quellen zu finden ist. Ein Beispiel dafür ist derDiskussionwie AWS Security Hub Sicherheitsergebnisse aus einer Vielzahl von AWS-Services, AWS-Partnerprodukten und sogar Ihren eigenen Anwendungen aufnimmt.

  • Driveeine Diskussion der organisatorischen Governance und Verantwortlichkeiten für die Sicherheit.

Ein wichtiges Element beim Entwerfen und Implementieren einer Sicherheitsarchitektur oder -strategie ist es, zu verstehen, wer in Ihrem Unternehmen welche sicherheitsbezogenen Verantwortlichkeiten hat. Beispielsweise hängt die Frage, wo Sicherheitsergebnisse aggregiert und überwacht werden können, mit der Frage zusammen, welches Team für diese Aktivität verantwortlich sein wird. Werden alle Ergebnisse im gesamten Unternehmen von einem zentralen Team überwacht, das Zugriff auf ein dediziertes Security Tooling-Konto benötigt? Oder sind einzelne Anwendungsteams (oder Geschäftsbereiche) für bestimmte Überwachungsaktivitäten verantwortlich und benötigen daher Zugriff auf bestimmte Warn- und Überwachungstools? Ein weiteres Beispiel: Wenn Ihre Organisation über eine Gruppe verfügt, die alle Verschlüsselungsschlüssel zentral verwaltet, hat dies Einfluss darauf, wer berechtigt ist, Schlüssel des AWS Key Management Service (AWS KMS) zu erstellen, und in welchen Konten diese Schlüssel verwaltet werden. Das Verständnis der Merkmale Ihres Unternehmens — der verschiedenen Teams und Verantwortlichkeiten — hilft Ihnen dabei, die AWS SRA optimal auf Ihre Bedürfnisse zuzuschneiden. Umgekehrt wird manchmal die Diskussion über die Sicherheitsarchitektur zum Anstoß, um die bestehenden organisatorischen Verantwortlichkeiten zu diskutieren und mögliche Änderungen zu berücksichtigen. AWS empfiehlt einen dezentralen Entscheidungsprozess, bei dem Workload-Teams für die Definition der Sicherheitskontrollen auf der Grundlage ihrer Workload-Funktionen und -Anforderungen verantwortlich sind. Das Ziel eines zentralisierten Sicherheits- und Governance-Teams ist es, ein System aufzubauen, das es den Workload-Eigentümern ermöglicht, fundierte Entscheidungen zu treffen und allen Beteiligten Einblick in Konfiguration, Ergebnisse und Ereignisse zu verschaffen. Die AWS SRA kann ein Mittel sein, um diese Diskussionen zu identifizieren und zu informieren.

Wichtige Implementierungsrichtlinien der AWS SRA

Im Folgenden finden Sie acht wichtige Erkenntnisse aus der AWS SRA, die Sie beim Entwerfen und Implementieren Ihrer Sicherheit berücksichtigen sollten.   

  • AWS Organizations und eine geeignete Strategie für mehrere Konten sind notwendige Elemente Ihrer Sicherheitsarchitektur. Die richtige Trennung von Workloads, Teams und Funktionen bildet die Grundlage für die Trennung von Aufgaben und defense-in-depth strategien „verwenden. Der Leitfaden behandelt dies weiter in einemspäterer Abschnitt.

  • Defense-in-depth ist ein wichtiger Entwurfserwägung bei der Auswahl von Sicherheitskontrollen für Ihr Unternehmen. Es hilft Ihnen, die entsprechenden Sicherheitskontrollen auf verschiedenen Ebenen der AWS-Organisationsstruktur einzuführen, wodurch die Auswirkungen eines Problems minimiert werden: Wenn es ein Problem mit einer Ebene gibt, gibt es Kontrollen, die andere wertvolle IT-Ressourcen isolieren. Die AWS SRA zeigt, wie verschiedene AWS-Services auf verschiedenen Ebenen des AWS-Technologie-Stacks funktionieren und wie die kombinierte Verwendung dieser Services Ihnen dabei hilft, defense-in-depth. Dieser defense-in-depth Das Konzept auf AWS wird in einemspäterer Abschnittmit Konstruktionsbeispielen unterAnwendungskonto.

  • Nutzen Sie die Vielzahl von Sicherheitsbausteinen für mehrere AWS-Services und -Funktionen, um eine robuste und belastbare Cloud-Infrastruktur aufzubauen. Wenn Sie die AWS SRA an Ihre speziellen Bedürfnisse anpassen, sollten Sie nicht nur die Hauptfunktion der AWS-Services und -Funktionen (z. B. Authentifizierung, Verschlüsselung, Überwachung, Berechtigungsrichtlinie) berücksichtigen, sondern auch, wie sie sich in die Struktur Ihrer Architektur einfügen. EINspäterer Abschnittin der Anleitung wird beschrieben, wie einige Services in Ihrer gesamten AWS-Organisation funktionieren. Andere Dienste funktionieren am besten innerhalb eines einzigen Kontos, und einige dienen dazu, einzelnen Auftraggebern Berechtigungen zu erteilen oder zu verweigern. Die Berücksichtigung dieser beiden Perspektiven hilft Ihnen dabei, einen flexibleren, mehrschichtigen Sicherheitsansatz zu entwickeln.

  • Nutzen Sie nach Möglichkeit (wie in späteren Abschnitten ausführlich beschrieben) AWS-Services, die in jedem Konto bereitgestellt werden können (verteilt statt zentralisiert), und erstellen Sie konsistente gemeinsame Leitplanken, die dazu beitragen können, Ihre Workloads vor Missbrauch zu schützen und die Auswirkungen von Sicherheitsereignissen zu verringern. Die AWS SRA verwendet den AWS Security Hub (zentrale Fundüberwachung und Konformitätsprüfungen), Amazon GuardDuty (Bedrohungserkennung und Erkennung von Anomalien), AWS Config (Ressourcenüberwachung und Änderungserkennung), IAM Access Analyzer (Überwachung des Ressourcenzugriffs, AWS CloudTrail (Protokollierung der Service-API-Aktivitäten in Ihrer gesamten Umgebung) und Amazon Macie (Datenklassifizierung) als Basissatz von AWS-Services, die für jedes AWS-Konto bereitgestellt werden können.

  • Nutzen Sie die delegierte Verwaltungsfunktion von AWS Organizations, wo sie unterstützt wird, wie weiter unten imDelegated AdministrationAbschnitt des Leitfadens. Auf diese Weise können Sie ein AWS-Mitgliedskonto als Administrator für unterstützte Dienste registrieren. Die delegierte Administration bietet verschiedenen Teams innerhalb Ihres Unternehmens die Flexibilität, je nach ihren Verantwortlichkeiten separate Konten zu verwenden, um AWS-Services in der gesamten Umgebung zu verwalten. Darüber hinaus hilft Ihnen die Verwendung eines delegierten Administrators dabei, den Zugriff auf das Verwaltungskonto von AWS Organizations einzuschränken und den Aufwand für Berechtigungen zu verwalten.

  • Implementieren Sie eine zentrale Überwachung, Verwaltung und Governance in Ihren AWS-Organisationen. Durch die Verwendung von AWS-Services, die die Aggregation mehrerer Konten (und manchmal auch mehrere Regionen) unterstützen, zusammen mit delegierten Verwaltungsfunktionen ermöglichen Sie Ihren zentralen Sicherheits-, Netzwerk- und Cloud-Engineering-Teams einen umfassenden Überblick und Kontrolle über die entsprechende Sicherheitskonfiguration und Datenerfassung. Darüber hinaus können die Daten Workload-Teams zur Verfügung gestellt werden, damit sie zu einem früheren Zeitpunkt im Softwareentwicklungslebenszyklus (SDLC) effektive Sicherheitsentscheidungen treffen können.

  • Verwenden Sie AWS Control Tower zum Einrichten und Verwalten Ihrer AWS-Umgebung für mehrere Konten mit der Implementierung vorgefertigter Sicherheitskontrollen zum Bootstrap Ihrer AWS-Berechtigung „verwenden. Der AWS Control Tower bietet eine Blaupause für Identitätsmanagement, Verbundzugriff auf Konten, zentralisierte Protokollierung und definierte Workflows für die Bereitstellung zusätzlicher Konten. Sie können dasAnpassungen für Control Tower (CfCT)Lösung, um die vom AWS Control Tower verwalteten Konten mit zusätzlichen Sicherheitskontrollen, Servicekonfigurationen und Governance zu versehen, wie das AWS SRA-Code-Repository demonstriert. Die Account Factory-Funktion stellt neuen Konten automatisch konfigurierbare Vorlagen zur Verfügung, die auf der genehmigten Kontokonfiguration basieren, um Konten innerhalb Ihrer AWS Organizations zu standardisieren. Sie können die Governance auch auf ein einzelnes bestehendes AWS-Konto ausdehnen, indem Sie es in einer Organisationseinheit (OU) registrieren, die bereits vom AWS Control Tower verwaltet wird.

  • Die AWS SRA-Codebeispiele zeigen, wie Sie die Implementierung von Mustern im AWS SRA-Leitfaden automatisieren können, indem Sie Infrastructure as Code (IaC) verwenden. Die Kodifizierung der Muster bietet die Möglichkeit, IaC ähnlich wie andere Anwendungen in Ihrem Unternehmen zu behandeln, bei denen Tests automatisiert werden können, bevor Bereitstellungen durchgeführt werden. IaC trägt auch dazu bei, Konsistenz und Wiederholbarkeit durch die Bereitstellung von Leitplanken in mehreren (z. B. SDLC- oder regionsspezifischen) Umgebungen sicherzustellen. Die SRA-Codebeispiele verwenden den AWS Control Tower with Customizations for AWS Control Tower (CfCT), um die Integration von IaC in eine AWS-Umgebung zu beschleunigen.