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 des AWS SRA
| Nehmen Sie an einer kurzen Umfrage teil |
AWSverfügt über ein umfangreiches (und wachsendes) Angebot an sicherheits- und sicherheitsbezogenen Diensten
-
Kunden wünschen sich mehr Informationen und empfohlene Muster, wie sie die AWS Sicherheitsdienste ganzheitlich bereitstellen, konfigurieren und betreiben können. Für welche Konten und im Hinblick auf welche Sicherheitsziele sollten die Services bereitgestellt und verwaltet werden? Gibt es ein Sicherheitskonto, für das alle oder die meisten Dienste ausgeführt werden sollen? Wie beeinflusst die Wahl des Standorts (Organisationseinheit oder AWS Konto) die Sicherheitsziele? Welche Kompromisse (Designüberlegungen) sollten sich Kunden bewusst sein?
-
Kunden sind daran interessiert, die vielen Sicherheitsdienste aus unterschiedlichen Perspektiven logisch zu organisieren. AWS Neben der Hauptfunktion der einzelnen Dienste (z. B. Identitätsdienste oder Protokollierungsdienste) helfen diese alternativen Sichtweisen den Kunden bei der Planung, Gestaltung und Implementierung ihrer Sicherheitsarchitektur. Ein Beispiel, das weiter unten in diesem Leitfaden vorgestellt wird, gruppiert die Dienste nach Schutzebenen, die auf die empfohlene Struktur Ihrer AWS Umgebung abgestimmt sind.
-
Kunden suchen nach Anleitungen und Beispielen, um Sicherheitsdienste so effektiv wie möglich zu integrieren. Wie sollten sie beispielsweise AWS Config am besten mit anderen Diensten abstimmen und verbinden, um die Schwerstarbeit bei automatisierten Audit- und Monitoring-Pipelines zu erledigen? Kunden fragen nach Informationen darüber, wie sich die einzelnen AWS Sicherheitsdienste auf andere Sicherheitsdienste verlassen oder diese unterstützen.
Wir gehen auf jedes dieser Probleme in der ein AWSSRA. Die erste Priorität in der Liste (wo die Dinge hingehören) ist der Schwerpunkt des Hauptarchitekturdiagramms und der begleitenden Diskussionen in diesem Dokument. Wir bieten eine empfohlene AWS Organisationsarchitektur und eine account-by-account Beschreibung, welche Dienste wo eingesetzt werden. Um mit der zweiten Priorität in der Liste zu beginnen (wie man sich die gesamte Palette von Sicherheitsdiensten vorstellen kann), lesen Sie den Abschnitt Sicherheitsdienste in Ihrer gesamten AWS Organisation anwenden. In diesem Abschnitt wird beschrieben, wie Sie Sicherheitsdienste entsprechend der Struktur der Elemente in Ihrer AWS Organisation gruppieren können. Darüber hinaus spiegeln sich dieselben Ideen in der Diskussion über das Anwendungskonto wider, in der hervorgehoben wird, wie Sicherheitsdienste so betrieben werden können, dass sie sich auf bestimmte Ebenen des Kontos konzentrieren: Amazon Elastic Compute Cloud (AmazonEC2) -Instances, Amazon Virtual Private Cloud (AmazonVPC) -Netzwerke und das breitere Konto. Schließlich spiegelt sich die dritte Priorität (Serviceintegration) in der gesamten Anleitung wider — insbesondere in der Erörterung der einzelnen Dienste in den ausführlichen Abschnitten dieser Dokumentation und des Codes im AWS SRA Code-Repository.
Wie benutzt man AWS SRA
AWSSRAJe nachdem, wo Sie sich auf Ihrem Weg zur Cloud-Einführung befinden, gibt es unterschiedliche Verwendungsmöglichkeiten. Im Folgenden finden Sie eine Liste von Möglichkeiten, wie Sie die AWS SRA Ressourcen optimal nutzen können (Architekturdiagramm, schriftliche Anleitungen und Codebeispiele).
-
Definieren Sie den Zielstatus für Ihre eigene Sicherheitsarchitektur.
Ganz gleich, ob Sie Ihre AWS Cloud-Reise gerade erst beginnen — Ihre ersten Konten einrichten — oder planen, eine bestehende AWS Umgebung zu verbessern, hier können Sie mit dem Aufbau Ihrer AWS SRA Sicherheitsarchitektur beginnen. Beginnen Sie mit einer umfassenden Grundlage aus Kontostruktur und Sicherheitsdiensten und passen Sie diese dann an Ihren speziellen Technologie-Stack, Ihre Fähigkeiten, Sicherheitsziele und Compliance-Anforderungen an. Wenn Sie wissen, dass Sie mehr Workloads erstellen und auf den Markt bringen werden, können Sie Ihre maßgeschneiderte Version von als Grundlage für die Sicherheitsreferenzarchitektur Ihres Unternehmens verwenden. AWS SRA Informationen dazu, wie Sie den in der beschriebenen Zielzustand erreichen können AWSSRA, finden Sie im Abschnitt Aufbau Ihrer Sicherheitsarchitektur — Ein schrittweiser Ansatz.
-
Überprü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 das, was Sie haben, mit dem AWS SRA zu vergleichen. Das AWS SRA ist so konzipiert, dass es umfassend ist und eine diagnostische Grundlage für die Überprüfung Ihrer eigenen Sicherheit bietet. Je nachdem, wo Ihre Sicherheitsentwürfe darauf abgestimmt sind AWSSRA, können Sie sich darauf verlassen, dass Sie bei der Nutzung von AWS Diensten bewährte Verfahren befolgen. Wenn Ihre Sicherheitsentwürfe von den Richtlinien in der abweichen oder sogar nicht mit ihnen übereinstimmen AWSSRA, 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 AWS SRA bewährten Methoden abweichen könnten. Möglicherweise erfordern Ihre speziellen Compliance-, behördlichen oder organisatorischen Sicherheitsanforderungen spezielle Servicekonfigurationen. Oder, anstatt AWS Dienste zu nutzen, bevorzugen Sie möglicherweise eine 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 möglicherweise 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, alle Aktualisierungen 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 vor dem Hintergrund dieser Faktoren entdecken AWSSRA, Sie werden es als wertvoll erachten, diese Analyse zu dokumentieren. Diese historischen Aufzeichnungen von Entscheidungen und ihren Begründungen können dazu beitragen, future Entscheidungen zu fundieren und zu priorisieren.
-
Starten Sie die Implementierung Ihrer eigenen Sicherheitsarchitektur.
Die AWS SRA Infrastructure-as-Code-Module (IaC) bieten eine schnelle und zuverlässige Möglichkeit, mit dem Aufbau und der Implementierung Ihrer Sicherheitsarchitektur zu beginnen. Diese Module werden im Abschnitt Code-Repository und im öffentlichen GitHub Repository
-
Erfahren Sie mehr über AWS Sicherheitsdienste und -funktionen.
Die Anleitungen und Diskussionen in der AWS SRA beinhalten wichtige Funktionen sowie Überlegungen zur Bereitstellung und Verwaltung einzelner sicherheitstechnischer und AWS sicherheitsrelevanter Services. Ein Merkmal von AWS SRA ist, dass es eine allgemeine Einführung in die Breite der AWS Sicherheitsdienste und deren Zusammenarbeit in einer Umgebung mit mehreren Konten bietet. Dies ergänzt die umfassenden Informationen zu den Funktionen und der Konfiguration der einzelnen Dienste, die in anderen Quellen zu finden sind. Ein Beispiel dafür ist die Diskussion darüber, wie AWS Security Hub Sicherheitsergebnisse aus einer Vielzahl von AWS Diensten, AWS Partnerprodukten und sogar Ihren eigenen Anwendungen aufnimmt.
-
Fördern Sie die Diskussion über Unternehmensführung und Sicherheitsverantwortung.
Ein wichtiges Element bei der Gestaltung und Implementierung einer Sicherheitsarchitektur oder -strategie ist es, zu verstehen, wer in Ihrem Unternehmen welche sicherheitsbezogenen Verantwortlichkeiten hat. Beispielsweise hängt die Frage, wo die Sicherheitsergebnisse zusammengefasst und überwacht werden sollen, mit der Frage zusammen, welches Team für diese Aktivität verantwortlich sein wird. Werden alle Ergebnisse unternehmensweit von einem zentralen Team überwacht, das Zugriff auf ein spezielles 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 Alarm- 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 für den AWS Schlüsselverwaltungsdienst (AWSKMS) zu erstellen, und in welchen Konten diese Schlüssel verwaltet werden. Wenn Sie die Merkmale Ihres Unternehmens — die verschiedenen Teams und Zuständigkeiten — kennen, können Sie sie besser an Ihre Bedürfnisse anpassen. AWS SRA Umgekehrt wird die Diskussion über die Sicherheitsarchitektur manchmal zum Anstoß, um die bestehenden organisatorischen Verantwortlichkeiten zu erörtern und mögliche Änderungen in Betracht zu ziehen. AWSempfiehlt einen dezentralen Entscheidungsprozess, bei dem die Workload-Teams dafür verantwortlich sind, die Sicherheitskontrollen auf der Grundlage ihrer Workload-Funktionen und -Anforderungen zu definieren. Das Ziel eines zentralisierten Sicherheits- und Governance-Teams besteht darin, ein System aufzubauen, das es den Workload-Verantwortlichen ermöglicht, fundierte Entscheidungen zu treffen, und das es allen Beteiligten ermöglicht, sich einen Überblick über Konfiguration, Ergebnisse und Ereignisse zu verschaffen. AWSSRASie können als Mittel dienen, um diese Diskussionen zu identifizieren und als Grundlage zu dienen.
Die wichtigsten Umsetzungsrichtlinien der AWS SRA
Hier sind acht wichtige Erkenntnisse aus dem AWSSRA, die Sie bei der Entwicklung und Implementierung Ihrer Sicherheit berücksichtigen sollten.
-
AWSOrganizations und eine angemessene 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. Der Leitfaden behandelt dies in einem späteren Abschnitt weiter.
-
Defense-in-depth ist ein wichtiger Entwurfsaspekt bei der Auswahl von Sicherheitskontrollen für Ihr Unternehmen. Es hilft Ihnen, die entsprechenden Sicherheitskontrollen auf verschiedenen Ebenen der AWS Unternehmensstruktur einzuführen, wodurch die Auswirkungen eines Problems minimiert werden können: Wenn es ein Problem mit einer Ebene gibt, gibt es Kontrollen, die andere wertvolle IT-Ressourcen isolieren. Dies AWS SRA zeigt, wie verschiedene AWS Dienste auf verschiedenen Ebenen des AWS Technologie-Stacks funktionieren und wie Sie durch die kombinierte Verwendung dieser Dienste Folgendes erreichen defense-in-depth können. Dieses defense-in-depth Konzept AWS wird in einem späteren Abschnitt anhand von Entwurfsbeispielen näher erläutert, die unter Anwendungskonto aufgeführt sind.
-
Verwenden Sie die Vielzahl von Sicherheitsbausteinen für mehrere AWS Dienste und Funktionen, um eine robuste und belastbare Cloud-Infrastruktur aufzubauen. Bei der Anpassung AWS SRA an Ihre speziellen Bedürfnisse sollten Sie nicht nur die Hauptfunktion der AWS Dienste und Funktionen (z. B. Authentifizierung, Verschlüsselung, Überwachung, Berechtigungsrichtlinien) berücksichtigen, sondern auch, wie sie in die Struktur Ihrer Architektur passen. In einem späteren Abschnitt des Handbuchs wird beschrieben, wie einige Dienste in Ihrem gesamten AWS Unternehmen funktionieren. Andere Dienste funktionieren am besten innerhalb eines einzigen Kontos, und einige sind so konzipiert, dass sie einzelnen Auftraggebern die Erlaubnis erteilen oder verweigern. Die Berücksichtigung dieser beiden Perspektiven hilft Ihnen dabei, einen flexibleren, mehrschichtigen Sicherheitsansatz zu entwickeln.
-
Verwenden Sie nach Möglichkeit (wie in späteren Abschnitten beschrieben) AWS Dienste, die in jedem Konto bereitgestellt werden können (verteilt statt zentralisiert), und erstellen Sie einheitliche gemeinsame Schutzmaßnahmen, die dazu beitragen können, Ihre Workloads vor Missbrauch zu schützen und die Auswirkungen von Sicherheitsereignissen zu reduzieren. The AWS SRA verwendet AWS Security Hub (zentrale Überwachung von Ergebnissen 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 von API Serviceaktivitäten in Ihrer gesamten Umgebung) und Amazon Macie (Datenklassifizierung) als AWS Basisdienste, die für jedes AWS Konto bereitgestellt werden können.
-
Nutzen Sie die Funktion zur delegierten Administration von AWS Organizations, wo sie unterstützt wird, wie später im Abschnitt zur delegierten Administration des Handbuchs erklärt wird. Auf diese Weise können Sie ein AWS Mitgliedskonto als Administrator für unterstützte Dienste registrieren. Die delegierte Administration bietet den verschiedenen Teams in Ihrem Unternehmen die Flexibilität, je nach ihren Zuständigkeiten separate Konten für die Verwaltung von AWS Diensten in der gesamten Umgebung zu verwenden. Darüber hinaus hilft Ihnen die Verwendung eines delegierten Administrators dabei, den Zugriff auf das Verwaltungskonto der AWS Organizations einzuschränken und den damit verbundenen Berechtigungsaufwand zu verwalten.
-
Implementieren Sie zentralisierte Überwachung, Verwaltung und Steuerung in Ihren AWS Organisationen. Durch die Verwendung von AWS Diensten, die die Aggregation mehrerer Konten (und manchmal mehrerer Regionen) unterstützen, sowie Funktionen zur delegierten Verwaltung 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 an Workload-Teams zurückgegeben werden, sodass diese zu einem früheren Zeitpunkt im Softwareentwicklungszyklus effektive Sicherheitsentscheidungen treffen können (). SDLC
-
Verwenden Sie AWS Control Tower, um Ihre AWS Umgebung mit mehreren Konten einzurichten und zu verwalten. Implementieren Sie dabei vorgefertigte Sicherheitskontrollen, um Ihre Sicherheitsreferenzarchitektur zu erstellen. AWSControl Tower bietet eine Blaupause für Identitätsmanagement, Verbundzugriff auf Konten, zentrale Protokollierung und definierte Workflows für die Bereitstellung zusätzlicher Konten. Anschließend können Sie die Customizations for AWS Control Tower (cFCT)
-Lösung verwenden, um die von AWS Control Tower verwalteten Konten mit zusätzlichen Sicherheitskontrollen, Servicekonfigurationen und Governance zu versehen, wie das AWS SRA Code-Repository zeigt. 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 Verwaltung auch auf ein einzelnes vorhandenes AWS Konto ausweiten, indem Sie es in einer Organisationseinheit (OU) registrieren, die bereits von AWS Control Tower verwaltet wird. -
Die AWS SRA Codebeispiele zeigen, wie Sie die Implementierung der im AWS SRA Leitfaden enthaltenen Muster mithilfe von Infrastructure as Code (IaC) automatisieren können. Durch die Kodifizierung der Muster können Sie IaC wie andere Anwendungen in Ihrem Unternehmen behandeln und Tests automatisieren, bevor Sie Code bereitstellen. IaC trägt auch dazu bei, Konsistenz und Wiederholbarkeit zu gewährleisten, indem Guardrails in mehreren (z. B. regionsspezifischen) Umgebungen eingesetzt werden. SDLC Die SRA Codebeispiele können in einer Unternehmensumgebung AWS Organizations mehreren Konten mit oder ohne AWS Control Tower bereitgestellt werden. Die Lösungen in diesem Repository, für die AWS Control Tower erforderlich sind, wurden in einer AWS Control Tower-Umgebung mithilfe von AWS CloudFormation and Customizations for AWS Control Tower (cFCT
) bereitgestellt und getestet. Lösungen, für die kein AWS Control Tower erforderlich ist, wurden in einer AWS Unternehmensumgebung unter Verwendung von getestet AWS CloudFormation. Wenn Sie AWS Control Tower nicht verwenden, können Sie die AWSorganisationsbasierte Bereitstellungslösung verwenden.
