Der Wert des AWS SRA

Beeinflussen Sie die future der AWS Security Reference Architecture (AWSSRA), indem Sie an einer kurzen Umfrage teilnehmen.

AWS verfügt über ein umfangreiches (und wachsendes) Angebot an Sicherheits- und sicherheitsbezogenen Services. Kunden haben ihre Wertschätzung für die detaillierten Informationen zum Ausdruck gebracht, die in unseren Servicedokumentationen, Blogbeiträgen, Tutorials, Gipfeltreffen und Konferenzen verfügbar sind. Sie sagen uns auch, dass sie das Gesamtbild besser verstehen und sich einen strategischen Überblick über die AWS-Sicherheitsservices verschaffen möchten. Wenn wir mit Kunden zusammenarbeiten, um ein tieferes Verständnis für ihre Bedürfnisse zu erlangen, ergeben sich drei Prioritäten:

• Kunden wünschen sich mehr Informationen und empfohlene Muster, wie sie die AWS-Sicherheitsservices ganzheitlich bereitstellen, konfigurieren und betreiben können. In welchen 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 AWS-Sicherheitsservices aus unterschiedlichen Perspektiven logisch zu organisieren. Neben der Hauptfunktion der einzelnen Services (z. B. Identitätsdienste oder Logging-Services) helfen diese alternativen Sichtweisen den Kunden bei der Planung, Gestaltung und Implementierung ihrer Sicherheitsarchitektur. Ein Beispiel, das später in diesem Handbuch vorgestellt wird, gruppiert die Services auf der Grundlage der 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 Services 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-Sicherheitsservices auf andere Sicherheitsservices stützen oder diese unterstützen.

Wir behandeln jedes dieser Probleme in der AWS-SRA. Die erste Priorität in der Liste (wo die Dinge hingehören) ist der Schwerpunkt des Hauptarchitekturdiagramms und der dazugehörigen Diskussionen in diesem Dokument. Wir bieten eine empfohlene Architektur von AWS Organizations und eine account-by-account Beschreibung, welche Services wo eingesetzt werden.  Lesen Sie den Abschnitt Anwenden von Sicherheitsservices in Ihrer gesamten AWS-Organisation, um mit der zweiten Priorität in der Liste zu beginnen (wie Sie sich alle Sicherheitsservices vorstellen können). In diesem Abschnitt wird beschrieben, wie Sie Sicherheitsservices 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 Kontoebenen konzentrieren: Amazon Elastic Compute Cloud (Amazon EC2) -Instances, Amazon Virtual Private Cloud (Amazon VPC) -Netzwerke und das breitere Konto. Schließlich spiegelt sich die dritte Priorität (Serviceintegration) in der gesamten Anleitung wider — insbesondere in der Erläuterung der einzelnen Services in den ausführlichen Abschnitten dieser Dokumentation und im Code im AWS-SRA-Code-Repository.

So verwenden Sie die AWS SRA

Je nachdem, wo Sie sich auf Ihrem Weg zur Cloud-Einführung befinden, gibt es unterschiedliche Möglichkeiten, die AWS SRA zu nutzen. Im Folgenden finden Sie eine Liste von Möglichkeiten, wie Sie die besten Einblicke in die AWS SRA-Assets gewinnen 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 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 Kontostruktur und Sicherheitsservices und passen Sie sie dann auf der Grundlage Ihres speziellen Technologie-Stacks, Ihrer Fähigkeiten, Sicherheitsziele und Compliance-Anforderungen an. Wenn Sie wissen, dass Sie weitere Workloads erstellen und starten werden, können Sie Ihre benutzerdefinierte Version von AWS SRA als Grundlage für die Sicherheitsreferenzarchitektur Ihres Unternehmens verwenden. Informationen dazu, wie Sie den von der AWS SRA beschriebenen Zielstatus erreichen können, 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 umfassend konzipiert und bietet eine diagnostische Grundlage für die Überprüfung Ihrer eigenen Sicherheit. Wenn Ihre Sicherheitsentwürfe mit der AWS-SRA übereinstimmen, können Sie sich darauf verlassen, dass Sie bei der Nutzung von AWS-Services Best Practices befolgen. Wenn Ihre Sicherheitsentwürfe von den Richtlinien der AWS-SRA abweichen oder sogar nicht mit ihnen ü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 möglicherweise von den Best Practices für AWS SRA abweichen. Möglicherweise erfordern Ihre speziellen Compliance-, behördlichen oder organisatorischen Sicherheitsanforderungen spezifische Servicekonfigurationen. Anstatt AWS-Services zu nutzen, 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, alle Aktualisierungen zu überprüfen, zu priorisieren und sie an der entsprechenden Stelle in Ihrem technischen Backlog hinzuzufügen. Was auch immer Sie bei der Bewertung Ihrer Sicherheitsarchitektur im Lichte der AWS SRA entdecken, 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 (IaC) -Module 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 ausführlicher beschrieben. Sie ermöglichen es den Technikern nicht nur, auf qualitativ hochwertigen Beispielen für die Muster in den AWS SRA-Leitlinien aufzubauen, sondern sie beinhalten auch empfohlene Sicherheitskontrollen wie AWS Identity and Access Management (IAM) -Passwortrichtlinien, Amazon Simple Storage Service (Amazon S3) für den öffentlichen Zugriff auf Sperrkonten, Amazon EC2 EC2-Standardverschlüsselung mit Amazon Elastic Block Store (Amazon EBS) und Integration mit AWS Control Tower, sodass die Kontrollen angewendet oder entfernt werden, wenn neue AWS-Konten hinzugefügt oder außer Betrieb genommen werden.

• Erfahren Sie mehr ü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 besteht darin, dass sie eine allgemeine Einführung in die Breite der AWS-Sicherheitsdienste und deren Zusammenspiel in einer Umgebung mit mehreren Konten bietet. Dies ergänzt die eingehende Untersuchung der Funktionen und der Konfiguration der einzelnen Services, 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-Services, AWS-Partnerprodukten und sogar Ihren eigenen Anwendungen aufnimmt.

• Fördern Sie eine Diskussion über die Unternehmensführung und die Verantwortlichkeiten im Bereich Sicherheit.

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, AWS Key Management Service (AWS KMS) -Schlüssel zu erstellen, und in welchen Konten diese Schlüssel verwaltet werden. Wenn Sie die Merkmale Ihres Unternehmens — die verschiedenen Teams und Verantwortlichkeiten — kennen, können Sie die AWS SRA optimal an Ihre Bedürfnisse anpassen. Umgekehrt wird manchmal die Diskussion über die Sicherheitsarchitektur zum Anstoß, um die bestehenden organisatorischen Verantwortlichkeiten zu erörtern und mögliche Änderungen in Betracht zu ziehen. AWS empfiehlt einen dezentralen Entscheidungsprozess, bei dem Workload-Teams dafür verantwortlich sind, die Sicherheitskontrollen auf der Grundlage ihrer Workload-Funktionen und -Anforderungen zu definieren. Das Ziel eines zentralen 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, Einblick in die Konfiguration, Ergebnisse und Ereignisse zu erhalten. Die AWS SRA kann als Mittel zur Identifizierung und Information dieser Diskussionen dienen.

Wichtige Implementierungsrichtlinien der AWS SRA

Hier sind acht wichtige Erkenntnisse aus der AWS SRA, die Sie bei der Entwicklung und Implementierung Ihrer Sicherheit berücksichtigen sollten.   

• AWS Organizations 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.

• D efense-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-Organisationsstruktur 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. Die AWS-SRA zeigt, wie verschiedene AWS-Services auf verschiedenen Ebenen des AWS-Technologie-Stacks funktionieren und wie die Kombination dieser Services Ihnen dabei hilft, dies zu erreichen defense-in-depth. Dieses defense-in-depth Konzept auf AWS wird in einem späteren Abschnitt mit Designbeispielen unter Anwendungskonto näher erläutert.

• Verwenden Sie die Vielzahl von Sicherheitsbausteinen für mehrere AWS-Services und -Funktionen, um eine robuste und belastbare Cloud-Infrastruktur aufzubauen. Wenn Sie den 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, Genehmigungsrichtlinien) berücksichtigen, sondern auch, wie sie in die Struktur Ihrer Architektur passen. In einem späteren Abschnitt des Handbuchs wird beschrieben, wie einige Services in Ihrer gesamten AWS-Organisation 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-Services, 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. Die 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 der Service-API-Aktivitäten in Ihrer Umgebung) und Amazon Macie (Datenklassifizierung) als Basissatz von AWS-Services, die für jedes AWS-Konto bereitgestellt werden.

• 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 Services registrieren. Die delegierte Verwaltung bietet den verschiedenen Teams in Ihrem Unternehmen die Flexibilität, je nach ihren Aufgaben 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 damit verbundenen Berechtigungsaufwand zu verwalten.

• Implementieren Sie zentralisierte Überwachung, Verwaltung und Steuerung in Ihren AWS-Organisationen. Durch die Verwendung von AWS-Services, 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 (SDLC) effektive Sicherheitsentscheidungen treffen können.

• 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. AWS Control Tower bietet einen Blueprint 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 Governance 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 von Mustern innerhalb des AWS SRA-Leitfadens mithilfe von Infrastructure as Code (IaC) automatisieren können. Durch die Kodifizierung der Muster können Sie IaC wie andere Anwendungen in Ihrer Organisation behandeln und Tests automatisieren, bevor Sie Code bereitstellen. IaC trägt auch dazu bei, Konsistenz und Wiederholbarkeit sicherzustellen, indem Guardrails in mehreren (z. B. SDLC- oder regionsspezifischen) Umgebungen bereitgestellt werden. Die SRA-Codebeispiele können in einer Umgebung mit mehreren Konten von AWS Organizations mit oder ohne AWS Control Tower bereitgestellt werden. Die Lösungen in diesem Repository, die AWS Control Tower erfordern, wurden in einer AWS Control Tower-Umgebung mithilfe von AWS CloudFormation und Customizations for AWS Control Tower (cFCT) bereitgestellt und getestet. Lösungen, für die AWS Control Tower nicht erforderlich ist, wurden in einer Umgebung von AWS Organizations mithilfe von AWS getestet CloudFormation. Wenn Sie AWS Control Tower nicht verwenden, können Sie die auf AWS Organizations basierende Bereitstellungslösung verwenden.