Aufbau Ihrer Sicherheitsarchitektur — ein schrittweiser Ansatz - AWS Prä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.

Aufbau Ihrer Sicherheitsarchitektur — ein schrittweiser Ansatz

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

Die von der AWS SRA empfohlene Sicherheitsarchitektur für mehrere Konten ist eine Basisarchitektur, mit der Sie Sicherheit frühzeitig in Ihren Designprozess integrieren können. Die Reise jedes Unternehmens in die Cloud ist einzigartig. Um Ihre Cloud-Sicherheitsarchitektur erfolgreich weiterzuentwickeln, müssen Sie sich den gewünschten Zielstatus vorstellen, Ihre aktuelle Cloud-Bereitschaft verstehen und einen agilen Ansatz verfolgen, um etwaige Lücken zu schließen. Die AWS SRA bietet einen Referenzzielstatus für Ihre Sicherheitsarchitektur. Durch die schrittweise Transformation können Sie schnell einen Mehrwert nachweisen und gleichzeitig die Notwendigkeit minimieren, weitreichende Prognosen zu treffen.

Das AWS Cloud Adoption Framework (AWS CAF) empfiehlt vier iterative und inkrementelle Cloud-Transformationsphasen: Envision, Align, Launch und Scale. Wenn Sie in die Startphase eintreten und sich auf die Durchführung von Pilotinitiativen in der Produktion konzentrieren, sollten Sie sich auf den Aufbau einer starken Sicherheitsarchitektur als Grundlage für die Skalierungsphase konzentrieren, damit Sie über die technischen Fähigkeiten verfügen, Ihre geschäftskritischsten Workloads sicher zu migrieren und zu betreiben. Dieser schrittweise Ansatz eignet sich für Startups, kleine oder mittlere Unternehmen, die ihr Geschäft ausbauen möchten, oder für Unternehmen, die neue Geschäftsbereiche erwerben oder Fusionen und Übernahmen durchführen. Die AWS SRA hilft Ihnen dabei, diese grundlegende Sicherheitsarchitektur zu erreichen, sodass Sie Sicherheitskontrollen in Ihrem expandierenden Unternehmen in AWS Organizations einheitlich anwenden können. Die Basisarchitektur besteht aus mehreren AWS-Konten und -Services. Planung und Implementierung sollten ein mehrphasiger Prozess sein, sodass Sie sich über kleinere Meilensteine hinweg wiederholen können, um das größere Ziel, die Einrichtung Ihrer grundlegenden Sicherheitsarchitektur, zu erreichen. In diesem Abschnitt werden die typischen Phasen Ihrer Cloud-Reise anhand eines strukturierten Ansatzes beschrieben. Diese Phasen entsprechen den Prinzipien des Sicherheitsdesigns des AWS Well-Architected Framework.

Phase 1: Erstellen Sie Ihre Organisationseinheit und Ihre Kontostruktur

Voraussetzung für eine solide Sicherheitsbasis ist eine gut durchdachte AWS-Organisation und Kontostruktur. Wie bereits im Abschnitt SRA-Bausteine dieses Handbuchs erläutert, können Sie mit mehreren AWS-Konten verschiedene Geschäfts- und Sicherheitsfunktionen konstruktionsbedingt isolieren. Am Anfang mag das nach unnötiger Arbeit erscheinen, aber es ist eine Investition, die Ihnen hilft, schnell und sicher zu skalieren. In diesem Abschnitt wird auch erklärt, wie Sie mit AWS Organizations mehrere AWS-Konten verwalten können und wie Sie Funktionen für vertrauenswürdigen Zugriff und delegierte Administratoren verwenden können, um AWS-Services für diese verschiedenen Konten zentral zu verwalten.

Sie können AWS Control Tower wie weiter oben in diesem Handbuch beschrieben verwenden, um Ihre landing zone zu orchestrieren. Wenn Sie derzeit ein einzelnes AWS-Konto verwenden, finden Sie im Leitfaden Umstellung auf mehrere AWS-Konten Informationen, um so früh wie möglich zu mehreren Konten zu migrieren. Wenn Ihr Startup-Unternehmen derzeit beispielsweise Ideen und Prototypen für Ihr Produkt in einem einzigen AWS-Konto entwickelt, sollten Sie darüber nachdenken, eine Strategie für mehrere Konten zu verfolgen, bevor Sie Ihr Produkt auf den Markt bringen. Ebenso sollten kleine, mittlere und große Unternehmen mit der Entwicklung ihrer Strategie für mehrere Konten beginnen, sobald sie ihre ersten Produktionsworkloads planen. Beginnen Sie mit Ihren Foundation-Organisationseinheiten und AWS-Konten und fügen Sie dann Ihre Workload-bezogenen Organisationseinheiten und Konten hinzu.

Empfehlungen zur AWS-Konto- und Organisationsstruktur, die über das hinausgehen, was in der AWS-SRA vorgesehen ist, finden Sie im Blogbeitrag Strategie für mehrere Konten für kleine und mittlere Unternehmen. Denken Sie bei der Fertigstellung Ihrer Organisationseinheit und Ihrer Kontostruktur über die allgemeinen, unternehmensweiten Sicherheitskontrollen nach, die Sie mithilfe von Service Control Policies (SCPs) durchsetzen möchten.

Überlegungen zum Design
  • Replizieren Sie nicht die Berichtsstruktur Ihres Unternehmens, wenn Sie Ihre OU- und Kontostruktur entwerfen. Ihre Organisationseinheiten sollten auf Workload-Funktionen und gemeinsamen Sicherheitskontrollen basieren, die für die Workloads gelten. Versuchen Sie nicht, Ihre gesamte Kontostruktur von Anfang an zu entwerfen. Konzentrieren Sie sich auf die grundlegenden Organisationseinheiten und fügen Sie dann nach Bedarf Workload-Organisationseinheiten hinzu. Sie können Konten zwischen Organisationseinheiten verschieben, um in den frühen Phasen Ihres Entwurfs mit alternativen Ansätzen zu experimentieren. Dies kann jedoch zu einem gewissen Aufwand bei der Verwaltung logischer Berechtigungen führen, abhängig von den SCPs und den IAM-Bedingungen, die auf OU- und Kontopfaden basieren.

Beispiel für eine Implementierung

Die AWS-SRA-Codebibliothek bietet eine Beispielimplementierung von Account Alternate Contacts. Diese Lösung legt die alternativen Ansprechpartner für Abrechnung, Betrieb und Sicherheit für alle Konten innerhalb einer Organisation fest.

Phase 2: Implementieren Sie ein starkes Identitätsfundament

Sobald Sie mehrere AWS-Konten erstellt haben, sollten Sie Ihren Teams Zugriff auf die AWS-Ressourcen innerhalb dieser Konten gewähren. Es gibt zwei allgemeine Kategorien von Identitätsmanagement: Identitäts - und Zugriffsmanagement für Mitarbeiter und Kundenidentitäts- und Zugriffsmanagement (CIAM). Workforce IAM ist für Unternehmen gedacht, in denen sich Mitarbeiter und automatisierte Workloads bei AWS anmelden müssen, um ihre Arbeit zu erledigen. CIAM wird verwendet, wenn eine Organisation eine Möglichkeit zur Authentifizierung von Benutzern benötigt, um Zugriff auf die Anwendungen der Organisation zu gewähren. Sie benötigen zunächst eine IAM-Strategie für die Belegschaft, damit Ihre Teams Anwendungen erstellen und migrieren können. Sie sollten immer IAM-Rollen anstelle von IAM-Benutzern verwenden, um menschlichen oder maschinellen Benutzern Zugriff zu gewähren. Folgen Sie den AWS-SRA-Anweisungen zur Verwendung von AWS IAM Identity Center innerhalb der Org Management - und Shared Services-Konten, um den Single Sign-On-Zugriff (SSO) auf Ihre AWS-Konten zentral zu verwalten. Die Anleitung enthält auch Überlegungen zum Design für die Verwendung des IAM-Verbunds, wenn Sie IAM Identity Center nicht verwenden können.

Wenn Sie mit IAM-Rollen arbeiten, um Benutzern Zugriff auf AWS-Ressourcen zu gewähren, sollten Sie AWS IAM Access Analyzer und IAM Access Advisor verwenden, wie in den Abschnitten Security Tooling und Org Management dieses Handbuchs beschrieben. Diese Services helfen Ihnen dabei, die geringsten Rechte zu erreichen. Dabei handelt es sich um eine wichtige präventive Kontrolle, mit der Sie ein gutes Sicherheitsniveau aufbauen können.

Überlegungen zum Design
  • Um die geringsten Rechte zu erreichen, sollten Sie Prozesse entwerfen, die die Beziehungen zwischen Ihren Identitäten und den Berechtigungen, die sie für ein ordnungsgemäßes Funktionieren benötigen, regelmäßig überprüfen und verstehen. Wenn Sie lernen, sollten Sie diese Berechtigungen verfeinern und sie schrittweise auf die geringstmöglichen Berechtigungen reduzieren. Aus Gründen der Skalierbarkeit sollten Ihre zentralen Sicherheits- und Anwendungsteams dafür gemeinsam verantwortlich sein. Verwenden Sie Funktionen wie ressourcenbasierte Richtlinien, Berechtigungsgrenzen, attributbasierte Zugriffskontrollen und Sitzungsrichtlinien, um Anwendungsbesitzern dabei zu helfen, eine detaillierte Zugriffskontrolle zu definieren.

Beispiele für die Implementierung

Die AWS-SRA-Codebibliothek bietet zwei Beispielimplementierungen, die für diese Phase gelten:

  • Die IAM-Passwortrichtlinie legt die Kontopasswortrichtlinie für Benutzer so fest, dass sie den gängigen Compliance-Standards entspricht.

  • Access Analyzer konfiguriert einen Analyzer auf Organisationsebene innerhalb eines delegierten Administratorkontos und einen Analyzer auf Kontoebene in jedem Konto.

Phase 3: Aufrechterhaltung der Rückverfolgbarkeit

Wenn Ihre Benutzer Zugriff auf AWS haben und mit der Entwicklung beginnen, werden Sie wissen wollen, wer was, wann und von wo aus macht. Sie benötigen außerdem Einblick in potenzielle Sicherheitsfehlkonfigurationen, Bedrohungen oder unerwartetes Verhalten. Ein besseres Verständnis von Sicherheitsbedrohungen ermöglicht es Ihnen, die geeigneten Sicherheitskontrollen zu priorisieren. Um die AWS-Aktivitäten zu überwachen, folgen Sie den AWS SRA-Empfehlungen zur Einrichtung eines Organization Trails mithilfe von AWS CloudTrail und zur Zentralisierung Ihrer Protokolle im Log Archive-Konto. Verwenden Sie für die Überwachung von Sicherheitsereignissen AWS Security Hub GuardDuty, Amazon, AWS Config und AWS Security Lake, wie im Abschnitt Security Tooling-Konto beschrieben.

Überlegungen zum Design
  • Wenn Sie mit der Nutzung neuer AWS-Services beginnen, stellen Sie sicher, dass Sie servicespezifische Protokolle für den Service aktivieren und diese als Teil Ihres zentralen Protokoll-Repositorys speichern.

Beispiele für die Implementierung

Die AWS-SRA-Codebibliothek bietet die folgenden Beispielimplementierungen, die für diese Phase gelten:

  • Die Organisation CloudTrail erstellt einen Organisationspfad und legt Standardeinstellungen für die Konfiguration von Datenereignissen fest (z. B. in Amazon S3 und AWS Lambda), um die Duplizierung der von AWS Control CloudTrail Tower konfigurierten Daten zu reduzieren. Diese Lösung bietet Optionen für die Konfiguration von Verwaltungsereignissen.

  • Mit dem AWS Config Control Tower Management Account kann AWS Config im Verwaltungskonto die Einhaltung von Ressourcen überwachen.

  • Conformance Pack Organization Rules stellt ein Conformance Pack für die Konten und angegebenen Regionen innerhalb einer Organisation bereit.

  • AWS Config Aggregator stellt einen Aggregator bereit, indem die Verwaltung an ein anderes Mitgliedskonto als das Audit-Konto delegiert wird.

  • Security Hub Organization konfiguriert Security Hub innerhalb eines delegierten Administratorkontos für die Konten und verwalteten Regionen innerhalb der Organisation.

  • GuardDuty Die Organisation konfiguriert GuardDuty innerhalb eines delegierten Administratorkontos die Konten innerhalb einer Organisation.

Phase 4: Wenden Sie Sicherheit auf allen Ebenen an

Zu diesem Zeitpunkt sollten Sie über Folgendes verfügen:

  • Die entsprechenden Sicherheitskontrollen für Ihre AWS-Konten.

  • Eine klar definierte Konto- und Organisationsstruktur mit präventiven Kontrollen, die durch SCPs und IAM-Rollen und -Richtlinien mit den geringsten Rechten definiert werden.

  • Die Fähigkeit, AWS-Aktivitäten mithilfe von AWS zu protokollieren CloudTrail, Sicherheitsereignisse mithilfe von AWS Security Hub GuardDuty, Amazon und AWS Config zu erkennen und mithilfe von Amazon Security Lake erweiterte Analysen an einem speziell für die Sicherheit erstellten Data Lake durchzuführen.

Planen Sie in dieser Phase, Sicherheit auf anderen Ebenen Ihrer AWS-Organisation anzuwenden, wie im Abschnitt Anwenden von Sicherheitsservices in Ihrer gesamten AWS-Organisation beschrieben. Sie können Sicherheitskontrollen für Ihre Netzwerkebene einrichten, indem Sie Services wie AWS WAF, AWS Shield, AWS Firewall Manager, AWS Network Firewall, AWS Certificate Manager (ACM), Amazon CloudFront, Amazon Route 53 und Amazon VPC verwenden, wie im Abschnitt Netzwerkkonto beschrieben. Wenden Sie bei der Weiterentwicklung Ihres Technologie-Stacks Sicherheitskontrollen an, die für Ihren Workload oder Ihren Anwendungsstapel spezifisch sind. Verwenden Sie VPC-Endpunkte, Amazon Inspector, Amazon Systems Manager, AWS Secrets Manager und Amazon Cognito, wie im Abschnitt Anwendungskonto beschrieben.

Überlegungen zum Design
  • Berücksichtigen Sie bei der Gestaltung Ihrer Sicherheitskontrollen (Defense in Depth, DiD) Skalierungsfaktoren. Ihr zentrales Sicherheitsteam wird nicht über die Bandbreite oder das vollständige Verständnis dafür verfügen, wie sich jede Anwendung in Ihrer Umgebung verhält. Geben Sie Ihren Anwendungsteams die Möglichkeit, für die Identifizierung und Gestaltung der richtigen Sicherheitskontrollen für ihre Anwendungen verantwortlich und rechenschaftspflichtig zu sein. Das zentrale Sicherheitsteam sollte sich darauf konzentrieren, die richtigen Tools und Beratung bereitzustellen, um die Anwendungsteams zu unterstützen. Informationen zu den Skalierungsmechanismen, die AWS verwendet, um einen eher nach links gerichteten Sicherheitsansatz zu verfolgen, finden Sie im Blogbeitrag How AWS built the Security Guardians program, a mechanism to distribution ownership.

Beispiele für die Implementierung

Die AWS-SRA-Codebibliothek bietet die folgenden Beispielimplementierungen, die für diese Phase gelten:

  • EC2 Default EBS Encryption konfiguriert die standardmäßige Amazon Elastic Block Store (Amazon EBS) -Verschlüsselung in Amazon EC2 so, dass sie den standardmäßigen AWS-KMS-Schlüssel in den bereitgestellten AWS-Regionen verwendet.

  • S3 Block Account Public Access konfiguriert die Block Public Access (BPA) -Einstellungen auf Kontoebene in Amazon S3 für Konten innerhalb der Organisation.

  • Firewall Manager zeigt, wie eine Sicherheitsgruppenrichtlinie und AWS WAF WAF-Richtlinien für Konten innerhalb einer Organisation konfiguriert werden.

  • Inspector Organization konfiguriert Amazon Inspector innerhalb eines delegierten Administratorkontos für Konten und verwaltete Regionen innerhalb der Organisation.

Phase 5: Schützen Sie Daten bei der Übertragung und Speicherung

Ihre Geschäfts- und Kundendaten sind wertvolle Ressourcen, die Sie schützen müssen. AWS bietet verschiedene Sicherheitsservices und Funktionen zum Schutz von Daten während der Übertragung und Speicherung. Verwenden Sie AWS CloudFront mit AWS Certificate Manager, wie im Abschnitt Netzwerkkonto beschrieben, um Daten zu schützen, die während der Übertragung über das Internet gesammelt werden. Verwenden Sie für Daten, die innerhalb interner Netzwerke übertragen werden, einen Application Load Balancer mit AWS Private Certificate Authority, wie im Abschnitt Anwendungskonto erklärt. AWS KMS und AWS CloudHSM unterstützen Sie bei der Verwaltung kryptografischer Schlüssel, um Daten im Ruhezustand zu schützen.

Phase 6: Bereiten Sie sich auf Sicherheitsereignisse vor

Beim Betrieb Ihrer IT-Umgebung werden Sie auf Sicherheitsereignisse stoßen. Dabei handelt es sich um Veränderungen im täglichen Betrieb Ihrer IT-Umgebung, die auf einen möglichen Verstoß gegen Sicherheitsrichtlinien oder ein Versagen der Sicherheitskontrolle hinweisen. Eine ordnungsgemäße Rückverfolgbarkeit ist entscheidend, damit Sie so schnell wie möglich über ein Sicherheitsereignis informiert werden. Ebenso wichtig ist es, darauf vorbereitet zu sein, solche Sicherheitsereignisse zu analysieren und darauf zu reagieren, damit Sie geeignete Maßnahmen ergreifen können, bevor das Sicherheitsereignis eskaliert. Die Vorbereitung hilft Ihnen dabei, ein Sicherheitsereignis schnell zu beurteilen, um seine möglichen Auswirkungen zu verstehen.

Die AWS-SRA bietet Ihnen durch das Design des Security Tooling-Kontos und die Bereitstellung gemeinsamer Sicherheitsdienste für alle AWS-Konten die Möglichkeit, Sicherheitsereignisse in Ihrer gesamten AWS-Organisation zu erkennen. AWS Detective im Security Tooling-Konto hilft Ihnen dabei, ein Sicherheitsereignis zu analysieren und die Ursache zu identifizieren. Während einer Sicherheitsuntersuchung müssen Sie in der Lage sein, die relevanten Protokolle zu überprüfen, um den gesamten Umfang und den Zeitplan des Vorfalls aufzuzeichnen und zu verstehen. Protokolle sind auch für die Generierung von Warnmeldungen erforderlich, wenn bestimmte Aktionen von Interesse sind.

Die AWS SRA empfiehlt ein zentrales Log Archive-Konto für die unveränderliche Speicherung aller Sicherheits- und Betriebsprotokolle. Sie können Protokolle abfragen, indem Sie CloudWatch Logs Insights für Daten verwenden, die in CloudWatch Protokollgruppen gespeichert sind, und Amazon Athena und Amazon OpenSearch Service für Daten, die in Amazon S3 gespeichert sind. Verwenden Sie Amazon Security Lake, um Sicherheitsdaten aus der AWS-Umgebung, SaaS-Anbietern (Software as a Service), lokalen Anbietern und anderen Cloud-Anbietern automatisch zu zentralisieren. Richten Sie Abonnenten im Security Tooling-Konto oder einem anderen speziellen Konto ein, wie in der AWS SRA beschrieben, um diese Protokolle zur Untersuchung abzufragen.

Überlegungen zum Design
  • Sie sollten sich von Beginn Ihrer Cloud-Reise an darauf vorbereiten, Sicherheitsereignisse zu erkennen und darauf zu reagieren. Um begrenzte Ressourcen besser zu nutzen, weisen Sie Ihren AWS-Ressourcen Daten und Geschäftskritikalität zu, sodass Sie, wenn Sie ein Sicherheitsereignis erkennen, die Triage und Reaktion auf der Kritikalität der beteiligten Ressourcen priorisieren können.

  • Die Phasen für den Aufbau Ihrer Cloud-Sicherheitsarchitektur, wie in diesem Abschnitt beschrieben, sind sequentieller Natur. Sie müssen jedoch nicht auf den vollständigen Abschluss einer Phase warten, bevor Sie mit der nächsten Phase beginnen. Wir empfehlen Ihnen, einen iterativen Ansatz zu wählen, bei dem Sie beginnen, an mehreren Phasen parallel zu arbeiten und jede Phase weiterzuentwickeln, während Sie Ihre Cloud-Sicherheitslage weiterentwickeln. Während Sie die verschiedenen Phasen durchlaufen, wird sich Ihr Design weiterentwickeln. Erwägen Sie, die in der folgenden Abbildung vorgeschlagene Reihenfolge an Ihre speziellen Bedürfnisse anzupassen.

Sequentielle und iterative Phasen beim Aufbau einer Cloud-Sicherheitsarchitektur
Beispiel für eine Implementierung

Die AWS SRA-Codebibliothek bietet eine Beispielimplementierung von Detective Organization, die Detective automatisch aktiviert, indem die Verwaltung an ein Konto delegiert wird (z. B. Audit oder Security Tooling), und Detective für bestehende und future AWS Organizations Organizations-Konten konfiguriert wird.