Der Wert der AWS SRA

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 Dokument vorgestellt wird, gruppiert die Dienste anhand 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 am besten auf andere Dienste abstimmen und sich AWS Config mit ihnen 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.

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, 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 diese dann auf der Grundlage Ihres speziellen Technologie-Stacks, Ihrer 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 der AWS SRA als Grundlage für die Sicherheitsreferenzarchitektur Ihres Unternehmens verwenden. Informationen dazu, wie Sie den in der AWS SRA beschriebenen Zielzustand 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 dem AWS SRA übereinstimmen, können Sie sich darauf verlassen, dass Sie bei der Verwendung bewährte Verfahren befolgen. AWS-Services 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 von den Best Practices der AWS SRA abweichen könnten. Möglicherweise erfordern Ihre speziellen Compliance-, behördlichen oder organisatorischen Sicherheitsanforderungen spezifische Servicekonfigurationen. Oder Sie haben möglicherweise eine bevorzugte Funktion für ein Produkt aus der AWS Partner Network oder eine benutzerdefinierte Anwendung, die Sie erstellt und verwaltet haben, anstatt sie zu verwenden AWS-Services. 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 Ihres technischen Backlogs 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-Module (Infrastructure as Code, 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 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 enthalten auch empfohlene Sicherheitskontrollen wie IAM-Passwortrichtlinien, den öffentlichen Zugriff von Amazon Simple Storage Service (Amazon S3) für Sperrkonten, die EC2 standardmäßige Amazon Elastic Block Store (Amazon EBS) -Verschlüsselung und die Integration mit, AWS Control Tower sodass die Kontrollen angewendet oder entfernt werden, wenn neue Geräte integriert oder außer Betrieb genommen AWS-Konten werden.

Erfahren Sie mehr über Sicherheitsdienste und Funktionen. AWS

Die Anleitungen und Diskussionen in der AWS SRA beinhalten wichtige Funktionen sowie Überlegungen zur Bereitstellung und Verwaltung einzelner sicherheits- und AWS sicherheitsrelevanter Dienste. Ein Merkmal des AWS SRA besteht darin, 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 eingehende Untersuchung der Funktionen und der Konfiguration der einzelnen Dienste, die in anderen Quellen zu finden sind. Ein Beispiel hierfür ist die Diskussion darüber, wie AWS Security Hub Cloud Security Posture Management (AWS Security Hub CSPM) Sicherheitsergebnisse aus einer Vielzahl von AWS-Services AWS Partner Produkten und sogar aus Ihren eigenen Anwendungen aufnimmt.

Fördern Sie eine 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 AWS Key Management Service (AWS KMS) 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 die SRA besser an Ihre Bedürfnisse anpassen. AWS 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 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, Einblick in die Konfiguration, Ergebnisse und Ereignisse zu erhalten. Die AWS SRA kann als Instrument zur Identifizierung und Information dieser Diskussionen dienen.

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.

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 Organizations Struktur zu implementieren, wodurch die Auswirkungen eines Problems minimiert werden: Wenn es ein Problem mit einer Ebene gibt, sind Kontrollen vorhanden, die andere wertvolle IT-Ressourcen isolieren. Die AWS SRA zeigt, wie unterschiedliche AWS-Services Funktionen auf den 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 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, die sich über mehrere AWS-Services Funktionen erstrecken, 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 AWS-Services und die Hauptmerkmale (z. B. Authentifizierung, Verschlüsselung, Überwachung, Berechtigungsrichtlinien) berücksichtigen, sondern auch, wie diese 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.

Wenn möglich (wie in späteren Abschnitten beschrieben), sollten Sie diese Möglichkeit nutzen, AWS-Services die für jedes Konto bereitgestellt werden kann (verteilt statt zentralisiert), und ein einheitliches Set von gemeinsamen Sicherheitsvorkehrungen einrichten, 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 CSPM (zentrale Ü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, der AWS-Services in allen eingesetzt werden kann. AWS-Konto

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 Verwaltung bietet den verschiedenen Teams in Ihrem Unternehmen die Flexibilität, je nach ihren Zuständigkeiten separate Konten für die Verwaltung der AWS-Services gesamten Umgebung zu verwenden. Darüber hinaus hilft Ihnen die Verwendung eines delegierten Administrators dabei, den Zugriff auf das AWS Organizations Verwaltungskonto einzuschränken und den damit verbundenen Berechtigungsaufwand zu verwalten.

Implementieren Sie zentralisierte Überwachung, Verwaltung und Steuerung in Ihren AWS Organisationen. Durch AWS-Services die Verwendung dieser Unterstützung für die Aggregation mehrerer Konten (und manchmal mehrerer Regionen) zusammen mit Funktionen für die delegierte Verwaltung ermöglichen Sie Ihren zentralen Sicherheits-, Netzwerk- und Cloud-Engineering-Teams eine umfassende Transparenz 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 Software Development Lifecycle (SDLC) effektive Sicherheitsentscheidungen treffen können.

Verwenden Sie AWS Control Tower es, um Ihre AWS Umgebung mit mehreren Konten einzurichten und zu verwalten, indem Sie vorgefertigte Sicherheitskontrollen implementieren, um Ihre Sicherheitsreferenzarchitektur zu starten. AWS Control Tower bietet einen Plan 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 verwalteten Konten AWS Control Tower mit zusätzlichen Sicherheitskontrollen, Servicekonfigurationen und Governance zu versehen, wie das SRA-Code-Repository zeigt. AWS Die Account-Factory-Funktion stellt neuen Konten automatisch konfigurierbare Vorlagen zur Verfügung, die auf der genehmigten Kontokonfiguration basieren, um die Konten innerhalb Ihrer Organisation zu standardisieren. AWS Sie können die Verwaltung auch auf eine bestehende Person ausdehnen, AWS-Konto indem Sie sie in eine Organisationseinheit (OU) eintragen, die bereits verwaltet wird. AWS Control Tower

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 Ihrem Unternehmen 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 mit oder ohne bereitgestellt werden. AWS Organizations AWS Control Tower Die erforderlichen Lösungen in diesem Repository AWS Control Tower wurden in einer AWS Control Tower Umgebung bereitgestellt und getestet, in der CfCT AWS Control Tower (Customizations for) verwendet AWS CloudFormation wurde. Lösungen, die dies nicht erfordern AWS Control Tower , wurden in einer AWS Organizations Umgebung getestet, indem AWS CloudFormation Wenn Sie dies nicht tun AWS Control Tower, können Sie die AWS Organizations basierte Bereitstellungslösung verwenden.