Workloads OU — Anwendungskonto

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

Das folgende Diagramm zeigt die AWS-Sicherheitsservices, die im Anwendungskonto konfiguriert sind (zusammen mit der Anwendung selbst).

Das Anwendungskonto hostet die primäre Infrastruktur und die Dienste für die Ausführung und Wartung einer Unternehmensanwendung. Das Anwendungskonto und die Organisationseinheit Workloads dienen einigen primären Sicherheitszielen. Zunächst erstellen Sie für jede Anwendung ein separates Konto, um Grenzen und Kontrollen zwischen Workloads bereitzustellen und so Probleme mit der Vermischung von Rollen, Berechtigungen, Daten und Verschlüsselungsschlüsseln zu vermeiden. Sie möchten einen separaten Kontencontainer bereitstellen, in dem dem Anwendungsteam umfassende Rechte zur Verwaltung seiner eigenen Infrastruktur eingeräumt werden können, ohne andere zu beeinträchtigen. Als Nächstes fügen Sie eine Schutzebene hinzu, indem Sie dem Sicherheitsteam einen Mechanismus zur Überwachung und Erfassung von Sicherheitsdaten bereitstellen. Nutzen Sie einen Organisationsplan und lokale Bereitstellungen von Kontosicherheitsdiensten (Amazon GuardDuty, AWS Config, AWS Security Hub, Amazon EventBridge, AWS IAM Access Analyzer), die vom Sicherheitsteam konfiguriert und überwacht werden. Schließlich ermöglichen Sie es Ihrem Unternehmen, Kontrollen zentral festzulegen. Sie passen das Anwendungskonto an die umfassendere Sicherheitsstruktur an, indem Sie es zu einem Mitglied der Workloads-Organisationseinheit machen, über die es die entsprechenden Serviceberechtigungen, Einschränkungen und Schutzmaßnahmen erbt.

Überlegungen zum Design

• In Ihrer Organisation verfügen Sie wahrscheinlich über mehr als eine Geschäftsanwendung. Die Workloads OU ist für die Unterbringung der meisten Ihrer geschäftsspezifischen Workloads vorgesehen, einschließlich Produktions- und Nichtproduktionsumgebungen. Bei diesen Workloads kann es sich um eine Mischung aus kommerziellen off-the-shelf (COTS) Anwendungen und Ihren eigenen, intern entwickelten kundenspezifischen Anwendungen und Datendiensten handeln. Es gibt nur wenige Muster für die Organisation verschiedener Geschäftsanwendungen zusammen mit ihren Entwicklungsumgebungen. Ein Muster besteht darin, mehrere untergeordnete Organisationseinheiten auf der Grundlage Ihrer Entwicklungsumgebung zu haben, z. B. Produktion, Staging, Test und Entwicklung, und separate untergeordnete AWS-Konten unter diesen OUs zu verwenden, die sich auf verschiedene Anwendungen beziehen. Ein weiteres gängiges Muster besteht darin, separate untergeordnete Organisationseinheiten pro Anwendung zu haben und dann separate untergeordnete AWS-Konten für einzelne Entwicklungsumgebungen zu verwenden. Die genaue OU- und Kontostruktur hängt von Ihrem Anwendungsdesign und den Teams ab, die diese Anwendungen verwalten. Berücksichtigen Sie die Sicherheitskontrollen, die Sie durchsetzen möchten, unabhängig davon, ob sie umgebungs- oder anwendungsspezifisch sind, da es einfacher ist, diese Kontrollen als SCPs in Organisationseinheiten zu implementieren. Weitere Überlegungen zur Organisation von Workload-orientierten Organisationseinheiten finden Sie im Abschnitt Organisieren von Workload-orientierten Organisationseinheiten des AWS-Whitepapers Organizing Your AWS-Umgebung mithilfe mehrerer Konten.

Anwendung VPC

Die Virtual Private Cloud (VPC) im Anwendungskonto benötigt sowohl eingehenden Zugriff (für die einfachen Webservices, die Sie modellieren) als auch ausgehenden Zugriff (für Anwendungsanforderungen oder AWS-Serviceanforderungen). Standardmäßig sind Ressourcen innerhalb einer VPC untereinander routbar. Es gibt zwei private Subnetze: eines zum Hosten der EC2-Instances (Anwendungsschicht) und das andere für Amazon Aurora (Datenbankschicht). Die Netzwerksegmentierung zwischen verschiedenen Ebenen, z. B. der Anwendungs- und Datenbankebene, erfolgt über VPC-Sicherheitsgruppen, die den Datenverkehr auf Instanzebene einschränken. Aus Gründen der Ausfallsicherheit erstreckt sich der Workload über zwei oder mehr Availability Zones und verwendet zwei Subnetze pro Zone.

Überlegungen zum Design

• Sie können Traffic Mirroring verwenden, um Netzwerkdatenverkehr von einer elastic network interface von EC2-Instances zu kopieren. Anschließend können Sie den Datenverkehr zur Inhaltsinspektion, Bedrohungsüberwachung oder Fehlerbehebung an out-of-band Sicherheits- und Überwachungs-Appliances weiterleiten. Möglicherweise möchten Sie beispielsweise den Traffic überwachen, der Ihre VPC verlässt, oder den Traffic, dessen Quelle sich außerhalb Ihrer VPC befindet. In diesem Fall spiegeln Sie den gesamten Datenverkehr mit Ausnahme des Datenverkehrs, der innerhalb Ihrer VPC fließt, und senden ihn an eine einzige Monitoring-Appliance. Amazon VPC-Flow-Logs erfassen keinen gespiegelten Datenverkehr; sie erfassen im Allgemeinen nur Informationen aus Paket-Headern. Traffic Mirroring bietet tiefere Einblicke in den Netzwerkverkehr, indem es Ihnen ermöglicht, den tatsächlichen Datenverkehrsinhalt, einschließlich der Nutzlast, zu analysieren. Aktivieren Sie Traffic Mirroring nur für die elastic network interface von EC2-Instances, die möglicherweise als Teil sensibler Workloads betrieben werden oder für die Sie im Falle eines Problems voraussichtlich detaillierte Diagnosen benötigen.

VPC endpoints (VPC-Endpunkte)

VPC-Endpunkte bieten eine weitere Ebene der Sicherheitskontrolle sowie Skalierbarkeit und Zuverlässigkeit. Verwenden Sie diese, um Ihre Anwendungs-VPC mit anderen AWS-Services zu verbinden. (Im Anwendungskonto verwendet die AWS SRA VPC-Endpunkte für AWS KMS, AWS Systems Manager und Amazon S3.) Endpunkte sind virtuelle Geräte. Es handelt sich bei ihnen um horizontal skalierte, redundante und hochverfügbare VPC-Komponenten. Sie ermöglichen die Kommunikation zwischen Instances in Ihrer VPC und Services ohne Verfügbarkeitsrisiken oder Bandbreitenbeschränkungen für den Netzwerkverkehr. Sie können einen VPC-Endpunkt verwenden, um Ihre VPC privat mit unterstützten AWS-Services und VPC-Endpunktservices zu verbinden, die von AWS bereitgestellt werden, PrivateLink ohne dass ein Internet-Gateway, ein NAT-Gerät, eine VPN-Verbindung oder eine AWS Direct Connect-Verbindung erforderlich ist. Instances in Ihrer VPC benötigen keine öffentlichen IP-Adressen, um mit anderen AWS-Services zu kommunizieren. Der Datenverkehr zwischen Ihrer VPC und dem anderen AWS-Service verlässt das Amazon-Netzwerk nicht. 

Ein weiterer Vorteil der Verwendung von VPC-Endpunkten besteht darin, die Konfiguration von Endpunktrichtlinien zu ermöglichen. Eine VPC-Endpunktrichtlinie ist eine IAM-Ressourcenrichtlinie, die Sie einem Endpunkt beim Erstellen oder Ändern des Endpunkts zuordnen. Wenn Sie bei der Erstellung eines Endpoints keine IAM-Richtlinie anhängen, fügt AWS eine Standard-IAM-Richtlinie für Sie hinzu, die vollen Zugriff auf den Service ermöglicht. Eine Endpunktrichtlinie überschreibt oder ersetzt weder IAM-Richtlinien noch dienstspezifische Richtlinien (wie S3-Bucket-Richtlinien). Es handelt sich um eine separate IAM-Richtlinie zur Steuerung des Zugriffs vom Endpunkt auf den angegebenen Dienst. Auf diese Weise wird eine weitere Kontrollebene hinzugefügt, über die AWS-Prinzipale mit Ressourcen oder Services kommunizieren können.

Amazon EC2

Die Amazon EC2 EC2-Instances, aus denen unsere Anwendung besteht, verwenden Version 2 des Instance Metadata Service (IMDSv2). IMDSv2 bietet Schutz für vier Arten von Sicherheitslücken, die für den Zugriff auf das IMDS genutzt werden könnten: Firewalls von Website-Anwendungen, offene Reverse-Proxys, SSRF-Schwachstellen (Server-Side Request Forgery), offene Layer-3-Firewalls und NATs. Weitere Informationen finden Sie im Blogbeitrag Erweiterter Schutz vor offenen Firewalls, Reverse-Proxys und SSRF-Sicherheitslücken mit Verbesserungen am EC2 Instance Metadata Service.

Verwenden Sie separate VPCs (als Teilmenge der Kontogrenzen), um die Infrastruktur nach Workload-Segmenten zu isolieren. Verwenden Sie Subnetze, um Ihre Anwendungsschichten (z. B. Web, Anwendung und Datenbank) innerhalb einer einzelnen VPC zu isolieren. Verwenden Sie für Ihre Instances private Subnetze, wenn Sie nicht direkt aus dem Internet erreichbar sein sollen. Verwenden Sie AWS, um die Amazon EC2 EC2-API von Ihrem privaten Subnetz aus aufzurufen, ohne ein Internet-Gateway zu verwenden. PrivateLink Beschränken Sie den Zugriff auf Ihre Instances mithilfe von Sicherheitsgruppen. Verwenden Sie VPC Flow-Protokolle, um den Datenverkehr zu überwachen, der Ihre Instances erreicht. Verwenden Sie Session Manager, eine Funktion von AWS Systems Manager, um remote auf Ihre Instances zuzugreifen, anstatt eingehende SSH-Ports zu öffnen und SSH-Schlüssel zu verwalten. Verwenden Sie separate Amazon Elastic Block Store (Amazon EBS) -Volumes für das Betriebssystem und Ihre Daten. Sie können Ihr AWS-Konto so konfigurieren, dass die Verschlüsselung der neuen EBS-Volumes und Snapshot-Kopien, die Sie erstellen, erzwungen wird. 

Beispiel für eine Implementierung

Die AWS-SRA-Codebibliothek bietet eine Beispielimplementierung der standardmäßigen Amazon EBS-Verschlüsselung in Amazon EC2. Es zeigt, wie Sie die standardmäßige Amazon EBS-Verschlüsselung auf Kontoebene für jedes AWS-Konto und jede AWS-Region in der AWS-Organisation aktivieren können.

Application Load Balancer

Application Load Balancer verteilen den eingehenden Anwendungsdatenverkehr auf mehrere Ziele, z. B. EC2-Instances, in mehreren Availability Zones. In der AWS-SRA sind die EC2-Instances der Anwendung die Zielgruppe für den Load Balancer. Die AWS SRA verwendet HTTPS-Listener, um sicherzustellen, dass der Kommunikationskanal verschlüsselt ist. Der Application Load Balancer verwendet ein Serverzertifikat, um die Front-End-Verbindung zu beenden und anschließend Anfragen von Clients zu entschlüsseln, bevor sie an die Ziele gesendet werden.

AWS Certificate Manager (ACM) lässt sich nativ in Application Load Balancers integrieren, und der AWS SRA verwendet ACM, um die erforderlichen öffentlichen X.509-Zertifikate (TLS-Server) zu generieren und zu verwalten. Sie können TLS 1.2 und starke Verschlüsselungen für Front-End-Verbindungen mithilfe der Application Load Balancer Balancer-Sicherheitsrichtlinie erzwingen. Weitere Informationen finden Sie im Elastic Load Balancing-Benutzerhandbuch. 

Überlegungen zum Design

• Für allgemeine Szenarien, wie z. B. rein interne Anwendungen, die ein privates TLS-Zertifikat auf dem Application Load Balancer benötigen, können Sie ACM innerhalb dieses Kontos verwenden, um daraus ein privates Zertifikat zu generieren. AWS Private CA In der AWS-SRA wird die private ACM-Root-CA im Security Tooling-Konto gehostet und kann mit der gesamten AWS-Organisation oder mit bestimmten AWS-Konten gemeinsam genutzt werden, um Endeinheitenzertifikate auszustellen, wie zuvor im Abschnitt Security Tooling-Konto beschrieben. 

• Bei öffentlichen Zertifikaten können Sie ACM verwenden, um diese Zertifikate zu generieren und zu verwalten, einschließlich automatisierter Rotation. Alternativ können Sie Ihre eigenen Zertifikate mithilfe von SSL/TLS-Tools generieren, um eine Certificate Signing Request (CSR) zu erstellen, die CSR von einer Zertifizierungsstelle (CA) signieren zu lassen, um ein Zertifikat zu erstellen, und dann das Zertifikat in ACM importieren oder das Zertifikat zur Verwendung mit dem Application Load Balancer in IAM hochladen. Wenn Sie ein Zertifikat in ACM importieren, müssen Sie das Ablaufdatum des Zertifikats überwachen und es verlängern, bevor es abläuft. 

• Für zusätzliche Verteidigungsebenen können Sie AWS WAF WAF-Richtlinien zum Schutz des Application Load Balancer einsetzen. Edge-Richtlinien, Anwendungsrichtlinien und sogar private oder interne Ebenen zur Durchsetzung von Richtlinien erhöhen die Sichtbarkeit von Kommunikationsanfragen und sorgen für eine einheitliche Durchsetzung von Richtlinien. Weitere Informationen finden Sie im Blogbeitrag Deploying Defense in depth using AWS Managed Rules for AWS WAF.

AWS Private CA

AWS Private Certificate Authority(AWS Private CA) wird im Anwendungskonto verwendet, um private Zertifikate für die Verwendung mit einem Application Load Balancer zu generieren. Es ist ein übliches Szenario, dass Application Load Balancers sichere Inhalte über TLS bereitstellen. Dazu müssen TLS-Zertifikate auf dem Application Load Balancer installiert sein. Für rein interne Anwendungen können private TLS-Zertifikate den sicheren Kanal bereitstellen.

In der AWS-SRA AWS Private CA wird es im Security Tooling-Konto gehostet und mithilfe von AWS-RAM an das Anwendungskonto weitergegeben. Auf diese Weise können Entwickler in einem Anwendungskonto ein Zertifikat von einer gemeinsam genutzten privaten Zertifizierungsstelle anfordern. Die gemeinsame Nutzung von Zertifizierungsstellen innerhalb Ihrer Organisation oder zwischen AWS-Konten trägt dazu bei, die Kosten und die Komplexität der Erstellung und Verwaltung doppelter Zertifizierungsstellen in all Ihren AWS-Konten zu reduzieren. Wenn Sie ACM verwenden, um private Zertifikate von einer gemeinsamen Zertifizierungsstelle auszustellen, wird das Zertifikat lokal im anfragenden Konto generiert, und ACM bietet die vollständige Lebenszyklusverwaltung und Verlängerung.

Amazon Inspector

Die AWS SRA verwendet Amazon Inspector, um EC2-Instances und Container-Images, die sich in der Amazon Elastic Container Registry (Amazon ECR) befinden, automatisch zu erkennen und auf Softwareschwachstellen und unbeabsichtigte Netzwerkbedrohungen hin zu scannen.

Amazon Inspector wird dem Anwendungskonto zugeordnet, da es Schwachstellen-Management-Services für EC2-Instances in diesem Konto bereitstellt. Darüber hinaus meldet Amazon Inspector unerwünschte Netzwerkpfade zu und von EC2-Instances.

Amazon Inspector in Mitgliedskonten wird zentral vom delegierten Administratorkonto verwaltet. In der AWS-SRA ist das Security Tooling-Konto das delegierte Administratorkonto. Das delegierte Administratorkonto kann Ergebnisse, Daten und bestimmte Einstellungen für Mitglieder der Organisation verwalten. Dazu gehören die Anzeige aggregierter Ergebnisdetails für alle Mitgliedskonten, die Aktivierung oder Deaktivierung von Scans für Mitgliedskonten und die Überprüfung gescannter Ressourcen innerhalb der AWS-Organisation. 

Überlegungen zum Design

• Sie können Patch Manager, eine Funktion von AWS Systems Manager, verwenden, um On-Demand-Patches auszulösen, um Zero-Day-Schwachstellen oder andere kritische Sicherheitslücken in Amazon Inspector zu beheben. Patch Manager hilft Ihnen dabei, diese Sicherheitslücken zu patchen, ohne auf Ihren normalen Patching-Zeitplan warten zu müssen. Die Behebung erfolgt mithilfe des Systems Manager Automation-Runbooks. Weitere Informationen finden Sie in der zweiteiligen Blogserie Automatisieren Sie das Schwachstellenmanagement und die Behebung von Sicherheitslücken in AWS mithilfe von Amazon Inspector und AWS Systems Manager.

Amazon-Systemmanager

AWS Systems Manager ist ein AWS-Service, mit dem Sie Betriebsdaten aus mehreren AWS-Services anzeigen und betriebliche Aufgaben in Ihren AWS-Ressourcen automatisieren können. Mit automatisierten Genehmigungsworkflows und Runbooks können Sie menschliche Fehler reduzieren und Wartungs- und Bereitstellungsaufgaben für AWS-Ressourcen vereinfachen.

Zusätzlich zu diesen allgemeinen Automatisierungsfunktionen unterstützt Systems Manager eine Reihe von präventiven, detektiven und reaktionsschnellen Sicherheitsfunktionen. AWS Systems Manager Agent (SSM Agent) ist Amazon-Software, die auf einer EC2-Instance, einem lokalen Server oder einer virtuellen Maschine (VM) installiert und konfiguriert werden kann. SSM Agent ermöglicht es Systems Manager, diese Ressourcen zu aktualisieren, zu verwalten und zu konfigurieren. Systems Manager unterstützt Sie bei der Aufrechterhaltung von Sicherheit und Compliance, indem es diese verwalteten Instanzen scannt und alle Verstöße, die er in Ihren Patch-, Konfiguration- und benutzerdefinierten Richtlinien entdeckt, meldet (oder Korrekturmaßnahmen ergreift). 

Die AWS SRA verwendet Session Manager, eine Funktion von Systems Manager, um ein interaktives, browserbasiertes Shell- und CLI-Erlebnis bereitzustellen. Dies ermöglicht eine sichere und überprüfbare Instanzverwaltung, ohne dass eingehende Ports geöffnet, Bastion-Hosts verwaltet oder SSH-Schlüssel verwaltet werden müssen. Die AWS SRA verwendet Patch Manager, eine Funktion von Systems Manager, um Patches auf EC2-Instances sowohl für Betriebssysteme als auch für Anwendungen anzuwenden. 

Die AWS SRA nutzt auch Automation, eine Funktion von Systems Manager, um allgemeine Wartungs- und Bereitstellungsaufgaben von Amazon EC2 EC2-Instances und anderen AWS-Ressourcen zu vereinfachen. Automatisierung kann übliche IT-Aufgaben vereinfachen, wie z. B. das Ändern des Zustands einer oder mehrerer Knoten (mithilfe einer Genehmigungs-Automatisierung) oder die Verwaltung von Knoten-Status gemäß einem Zeitplan. Systems Manager umfasst Funktionen, mit deren Hilfe Sie große Gruppen von Instances mithilfe von Tags und Geschwindigkeitskontrollen anvisieren können, um Änderungen entsprechend den von Ihnen festgelegten Grenzwerten durchzuführen. Automation bietet Automatisierungen mit einem Klick zur Vereinfachung komplexer Aufgaben wie der Erstellung goldener Amazon Machine Images (AMIs) und der Wiederherstellung nicht erreichbarer EC2-Instances. Darüber hinaus können Sie die Betriebssicherheit erhöhen, indem Sie IAM-Rollen Zugriff auf bestimmte Runbooks gewähren, um bestimmte Funktionen auszuführen, ohne diesen Rollen direkt Berechtigungen zu erteilen. Wenn Sie beispielsweise möchten, dass eine IAM-Rolle berechtigt ist, bestimmte EC2-Instances nach Patch-Updates neu zu starten, Sie die Berechtigung aber nicht direkt an diese Rolle vergeben möchten, können Sie stattdessen ein Automatisierungs-Runbook erstellen und der Rolle die Berechtigungen erteilen, nur das Runbook auszuführen.

Überlegungen zum Design

• Systems Manager benötigt EC2-Instance-Metadaten, um korrekt zu funktionieren. Systems Manager kann mithilfe von Version 1 oder Version 2 des Instanz-Metadatendienstes (IMDSv1 und IMDSv2) auf Instanzmetadaten zugreifen. 

• SSM Agent muss mit verschiedenen AWS-Services und -Ressourcen wie Amazon EC2 EC2-Nachrichten, Systems Manager und Amazon S3 kommunizieren. Damit diese Kommunikation stattfinden kann, benötigt das Subnetz entweder eine ausgehende Internetverbindung oder die Bereitstellung geeigneter VPC-Endpunkte. Die AWS-SRA verwendet VPC-Endpunkte für den SSM-Agenten, um private Netzwerkpfade zu verschiedenen AWS-Services einzurichten. 

• Automation lässt Sie bewährte Methoden mit Ihrer restlichen Organisation teilen. Sie können bewährte Methoden für das Ressourcenmanagement in Runbooks erstellen und die Runbooks in AWS-Regionen und -Gruppen gemeinsam nutzen. Sie können auch die zulässigen Werte für Runbook-Parameter einschränken. Für diese Anwendungsfälle müssen Sie möglicherweise Automation-Runbooks in einem zentralen Konto wie Security Tooling oder Shared Services erstellen und sie mit dem Rest der AWS-Organisation teilen. Zu den häufigsten Anwendungsfällen gehören die Möglichkeit, Patches und Sicherheitsupdates zentral zu implementieren, Abweichungen bei VPC-Konfigurationen oder S3-Bucket-Richtlinien zu beheben und EC2-Instances skalierbar zu verwalten. Einzelheiten zur Implementierung finden Sie in der Systems Manager Manager-Dokumentation.

Amazon Aurora

In der AWS SRA bilden Amazon Aurora und Amazon S3 die logische Datenschicht. Aurora ist eine vollständig verwaltete, mit MySQL und PostgreSQL kompatible relationale Datenbank-Engine. Eine Anwendung, die auf den EC2-Instances ausgeführt wird, kommuniziert bei Bedarf mit Aurora und Amazon S3. Aurora ist mit einem Datenbank-Cluster innerhalb einer DB-Subnetzgruppe konfiguriert. 

Überlegungen zum Design

• Wie bei vielen Datenbankdiensten wird die Sicherheit für Aurora auf drei Ebenen verwaltet. Um zu kontrollieren, wer Amazon Relational Database Service (Amazon RDS) -Managementaktionen auf Aurora-DB-Clustern und DB-Instances ausführen kann, verwenden Sie IAM. Um zu steuern, welche Geräte und EC2-Instances Verbindungen zum Cluster-Endpunkt und Port der DB-Instance für Aurora-DB-Cluster in einer VPC öffnen können, verwenden Sie eine VPC-Sicherheitsgruppe. Um Anmeldungen und Berechtigungen für einen Aurora-DB-Cluster zu authentifizieren, können Sie den gleichen Ansatz wie bei einer eigenständigen DB-Instance von MySQL oder PostgreSQL verwenden, oder Sie können die IAM-Datenbankauthentifizierung für Aurora MySQL-Compatible Edition verwenden. Bei letzterem Ansatz authentifizieren Sie sich bei Ihrem Aurora MySQL-kompatiblen DB-Cluster mithilfe einer IAM-Rolle und eines Authentifizierungstoken.

Amazon S3

Amazon S3 ist ein Objektspeicherservice, der branchenführende Skalierbarkeit, Datenverfügbarkeit, Sicherheit und Leistung bietet. Es ist das Datenrückgrat vieler auf AWS basierender Anwendungen, und angemessene Berechtigungen und Sicherheitskontrollen sind für den Schutz sensibler Daten von entscheidender Bedeutung. Empfohlene bewährte Sicherheitsmethoden für Amazon S3 finden Sie in der Dokumentation, in Online-Technikgesprächen und in ausführlicheren Informationen in Blogbeiträgen. Die wichtigste bewährte Methode besteht darin, übermäßig freizügigen Zugriff (insbesondere öffentlichen Zugriff) auf S3-Buckets zu blockieren.

AWS KMS

Die AWS-SRA veranschaulicht das empfohlene Verteilungsmodell für die Schlüsselverwaltung, bei dem sich der KMS-Schlüssel innerhalb desselben AWS-Kontos wie die zu verschlüsselnde Ressource befindet. Aus diesem Grund wird AWS KMS nicht nur im Security Tooling-Konto, sondern auch im Anwendungskonto verwendet. Im Anwendungskonto wird AWS KMS verwendet, um Schlüssel zu verwalten, die für die Anwendungsressourcen spezifisch sind. Sie können eine Aufgabentrennung implementieren, indem Sie Schlüsselrichtlinien verwenden, um lokalen Anwendungsrollen Schlüsselnutzungsberechtigungen zu erteilen und die Verwaltungs- und Überwachungsberechtigungen auf Ihre wichtigsten Verwalter zu beschränken. 

Überlegungen zum Design

• In einem verteilten Modell liegt die Verantwortung für die Schlüsselverwaltung von AWS KMS beim Anwendungsteam. Ihr zentrales Sicherheitsteam kann jedoch für die Steuerung und Überwachung wichtiger kryptografischer Ereignisse wie der folgenden verantwortlich sein:

  • Das importierte Schlüsselmaterial in einem KMS-Schlüssel befindet kurz vor dem Ablaufdatum.

  • Das Schlüsselmaterial in einem KMS-Schlüssel wurde automatisch rotiert.

  • Ein KMS-Schlüssel wurde gelöscht.

  • Bei der Entschlüsselung kommt es häufig zu Fehlschlägen.

AWS CloudHSM

AWS CloudHSM bietet verwaltete Hardware-Sicherheitsmodule (HSMs) in der AWS-Cloud. Es ermöglicht Ihnen, Ihre eigenen Verschlüsselungsschlüssel auf AWS zu generieren und zu verwenden, indem Sie FIPS 140-2 Level 3-validierte HSMs verwenden, auf die Sie den Zugriff kontrollieren. Sie können CloudHSM verwenden, um die SSL/TLS-Verarbeitung für Ihre Webserver auszulagern. Dies reduziert die Belastung des Webservers und bietet zusätzliche Sicherheit, indem der private Schlüssel des Webservers in CloudHSM gespeichert wird. Auf ähnliche Weise könnten Sie ein HSM von CloudHSM in der eingehenden VPC im Netzwerkkonto bereitstellen, um Ihre privaten Schlüssel zu speichern und Zertifikatsanfragen zu signieren, falls Sie als ausstellende Zertifizierungsstelle agieren müssen. 

Überlegungen zum Design

• Wenn Sie eine strenge Anforderung für FIPS 140-2 Level 3 haben, können Sie AWS KMS auch so konfigurieren, dass der CloudHSM-Cluster als benutzerdefinierten Schlüsselspeicher verwendet wird, anstatt den nativen KMS-Schlüsselspeicher zu verwenden. Auf diese Weise profitieren Sie von der Integration zwischen AWS KMS und AWS-Services, die Ihre Daten verschlüsseln, und sind gleichzeitig für die HSMs verantwortlich, die Ihre KMS-Schlüssel schützen. Dies kombiniert Single-Tenant-HSMs unter Ihrer Kontrolle mit der Benutzerfreundlichkeit und Integration von AWS KMS. Um Ihre CloudHSM-Infrastruktur zu verwalten, müssen Sie eine Public-Key-Infrastruktur (PKI) einsetzen und über ein Team verfügen, das Erfahrung mit der Verwaltung von HSMs hat.

AWS Secrets Manager

AWS Secrets Manager hilft Ihnen dabei, die Anmeldeinformationen (Secrets) zu schützen, die Sie für den Zugriff auf Ihre Anwendungen, Services und IT-Ressourcen benötigen. Der Service ermöglicht es Ihnen, Datenbankanmeldedaten, API-Schlüssel und andere Geheimnisse während ihres gesamten Lebenszyklus effizient zu rotieren, zu verwalten und abzurufen. Sie können hartcodierte Anmeldeinformationen in Ihrem Code durch einen API-Aufruf an Secrets Manager ersetzen, um das Geheimnis programmgesteuert abzurufen. Dadurch wird sichergestellt, dass das Geheimnis nicht von jemandem, der Ihren Code untersucht, kompromittiert werden kann, da das Geheimnis nicht mehr im Code enthalten ist. Darüber hinaus hilft Ihnen Secrets Manager dabei, Ihre Anwendungen zwischen Umgebungen (Entwicklung, Vorproduktion, Produktion) zu verschieben. Anstatt den Code zu ändern, können Sie sicherstellen, dass ein entsprechend benannter und referenzierter Secret in der Umgebung verfügbar ist. Dies fördert die Konsistenz und Wiederverwendbarkeit des Anwendungscodes in verschiedenen Umgebungen und erfordert gleichzeitig weniger Änderungen und menschliche Interaktionen, nachdem der Code getestet wurde. 

Mit Secrets Manager können Sie den Zugriff auf geheime Daten mithilfe detaillierter IAM-Richtlinien und ressourcenbasierter Richtlinien verwalten. Sie können zur Sicherung von Geheimnissen beitragen, indem Sie sie mit Verschlüsselungsschlüsseln verschlüsseln, die Sie mithilfe von AWS KMS verwalten. Secrets Manager lässt sich auch in die Protokollierungs- und Überwachungsdienste von AWS integrieren, um eine zentrale Prüfung zu ermöglichen. 

Secrets Manager verwendet Umschlagverschlüsselung mit AWS-KMS-Schlüsseln und Datenschlüsseln, um jeden geheimen Wert zu schützen. Wenn Sie einen geheimen Schlüssel erstellen, können Sie einen beliebigen symmetrischen, vom Kunden verwalteten Schlüssel im AWS-Konto und in der AWS-Region auswählen, oder Sie können den von AWS verwalteten Schlüssel für Secrets Manager verwenden. 

Es hat sich bewährt, dass Sie Ihre Secrets überwachen können, um alle Änderungen daran zu protokollieren. Auf diese Weise können Sie sicherstellen, dass jede unerwartete Verwendung oder Änderung untersucht werden kann. Unerwünschte Änderungen können rückgängig gemacht werden. Secrets Manager unterstützt derzeit zwei AWS-Services, mit denen Sie Ihre Organisation und Aktivitäten überwachen können: AWS CloudTrail und AWS Config. CloudTrail erfasst alle API-Aufrufe für Secrets Manager als Ereignisse, einschließlich Aufrufe von der Secrets Manager Manager-Konsole und von Codeaufrufen an die Secrets Manager Manager-APIs. CloudTrail Erfasst darüber hinaus andere verwandte (nicht API-bezogene) Ereignisse, die sich auf die Sicherheit oder die Einhaltung von Vorschriften auf Ihr AWS-Konto auswirken oder Ihnen bei der Behebung von Betriebsproblemen helfen könnten. Dazu gehören bestimmte Rotationsereignisse von Geheimnissen und das Löschen geheimer Versionen. AWS Config kann detektivische Kontrollen bereitstellen, indem Änderungen an Geheimnissen in Secrets Manager verfolgt und überwacht werden. Zu diesen Änderungen gehören die Beschreibung, die Rotationskonfiguration, die Tags und die Beziehung zu anderen AWS-Quellen wie dem KMS-Verschlüsselungsschlüssel oder den AWS-Lambda-Funktionen, die für die geheime Rotation verwendet werden. Sie können Amazon EventBridge, das Benachrichtigungen über Konfigurations- und Compliance-Änderungen von AWS Config erhält, auch so konfigurieren, dass bestimmte geheime Ereignisse für Benachrichtigungen oder Abhilfemaßnahmen weitergeleitet werden. 

In der AWS-SRA befindet sich Secrets Manager im Anwendungskonto, um lokale Anwendungsfälle zu unterstützen und Geheimnisse zu verwalten, die ihrer Verwendung nahe kommen. Hier wird den EC2-Instances im Anwendungskonto ein Instance-Profil angehängt. Separate Secrets können dann in Secrets Manager konfiguriert werden, sodass das Instance-Profil geheime Daten abrufen kann, z. B. um der entsprechenden Active Directory- oder LDAP-Domäne beizutreten und auf die Aurora-Datenbank zuzugreifen. Secrets Manager ist in Amazon RDS integriert, um Benutzeranmeldeinformationen zu verwalten, wenn Sie eine Amazon RDS-DB-Instance oder einen Multi-AZ-DB-Cluster erstellen, ändern oder wiederherstellen. Dies hilft Ihnen bei der Verwaltung der Erstellung und Rotation von Schlüsseln und ersetzt die hartcodierten Anmeldeinformationen in Ihrem Code durch programmatische API-Aufrufe an Secrets Manager.

Überlegungen zum Design

• Im Allgemeinen sollten Sie Secrets Manager in dem Konto konfigurieren und verwalten, das dem Ort, an dem die Secrets verwendet werden, am nächsten ist. Dieser Ansatz nutzt die lokalen Kenntnisse des Anwendungsfalls und bietet Anwendungsentwicklungsteams Geschwindigkeit und Flexibilität. Für streng kontrollierte Informationen, bei denen eine zusätzliche Kontrollebene angebracht sein könnte, können Geheimnisse zentral vom Secrets Manager im Security Tooling-Konto verwaltet werden.

Amazon Cognito

Mit Amazon Cognito können Sie Ihren Web- und mobilen Apps schnell und effizient Benutzerregistrierung, Anmeldung und Zugriffskontrolle hinzufügen. Amazon Cognito ist auf Millionen von Benutzern skalierbar und unterstützt die Anmeldung bei Anbietern sozialer Identitäten wie Apple, Facebook, Google und Amazon sowie bei Anbietern von Unternehmensidentitäten über SAML 2.0 und OpenID Connect. Die beiden Hauptkomponenten von Amazon Cognito sind Benutzerpools und Identitätspools. Benutzerpools sind Benutzerverzeichnisse, die Anmelde- und Anmeldeoptionen für Ihre Anwendungsbenutzer bieten. Identitäten-Pools ermöglichen Ihnen, Ihren Benutzern Zugriff auf andere AWS-Services zu gewähren. Sie können Identitäten-Pools und Benutzerpools getrennt oder zusammen verwenden. Allgemeine Nutzungsszenarien finden Sie in der Amazon Cognito Cognito-Dokumentation.

Amazon Cognito bietet eine integrierte und anpassbare Benutzeroberfläche für die Benutzerregistrierung und -anmeldung. Sie können Android, iOS und JavaScript SDKs für Amazon Cognito verwenden, um Benutzerregistrierungs- und Anmeldeseiten zu Ihren Apps hinzuzufügen. Amazon Cognito Sync ist ein AWS-Service und eine Client-Bibliothek, die die geräteübergreifende Synchronisierung anwendungsbezogener Benutzerdaten ermöglicht.  

Amazon Cognito unterstützt die Multi-Faktor-Authentifizierung und Verschlüsselung von Daten im Ruhezustand und Daten während der Übertragung. Amazon Cognito Cognito-Benutzerpools bieten erweiterte Sicherheitsfunktionen, um den Zugriff auf Konten in Ihrer Anwendung zu schützen. Diese erweiterten Sicherheitsfunktionen bieten eine risikobasierte adaptive Authentifizierung und Schutz vor der Verwendung kompromittierter Anmeldeinformationen.  

Überlegungen zum Design

• Sie können eine AWS-Lambda-Funktion erstellen und diese Funktion dann bei Benutzerpool-Vorgängen wie Benutzerregistrierung, Bestätigung und Anmeldung (Authentifizierung) mit einem AWS Lambda Lambda-Trigger auslösen. Sie können Authentifizierungsaufforderungen hinzufügen, Benutzer migrieren und Verifizierungsnachrichten anpassen. Informationen zu allgemeinen Vorgängen und Benutzerabläufen finden Sie in der Amazon Cognito Cognito-Dokumentation. Amazon Cognito ruft Lambda-Funktionen synchron auf. 

• Sie können Amazon Cognito Cognito-Benutzerpools verwenden, um kleine, mandantenfähige Anwendungen zu sichern. Ein häufiger Anwendungsfall für Multi-Tenant-Designs ist die Ausführung von Workloads, um das Testen mehrerer Versionen einer Anwendung zu unterstützen. Ein Design mit mehreren Mandanten ist auch nützlich, um eine einzelne Anwendung mit unterschiedlichen Datensätzen zu testen, was die volle Nutzung Ihrer Clusterressourcen ermöglicht. Stellen Sie jedoch sicher, dass die Anzahl der Mandanten und das erwartete Volumen mit den entsprechenden Amazon Cognito-Servicekontingenten übereinstimmen. Diese Kontingente werden für alle Mandanten in Ihrer Anwendung freigegeben.

Amazon Verified Permissions

Amazon Verified Permissions ist ein skalierbares Berechtigungsmanagement und ein detaillierter Autorisierungsservice für die von Ihnen erstellten Anwendungen. Entwickler und Administratoren können Cedar verwenden, eine speziell entwickelte und sicherheitsorientierte Open-Source-Richtliniensprache mit Rollen und Attributen, um detailliertere, kontextsensitive und richtlinienbasierte Zugriffskontrollen zu definieren. Entwickler können sicherere Anwendungen schneller erstellen, indem sie die Autorisierung externalisieren und die Richtlinienverwaltung und -verwaltung zentralisieren. Verified Permissions umfasst Schemadefinitionen, die Grammatik von Richtlinienerklärungen und automatische Argumentation, die sich auf Millionen von Berechtigungen erstrecken, sodass Sie die Prinzipien der Standardverweigerung und der geringsten Zugriffsrechte durchsetzen können. Der Service umfasst auch einen Evaluierungssimulator, mit dem Sie Ihre Autorisierungsentscheidungen und Autorenrichtlinien testen können. Diese Funktionen erleichtern die Implementierung eines detaillierten, detaillierten Autorisierungsmodells zur Unterstützung Ihrer Zero-Trust-Ziele. Verified Permissions zentralisiert Berechtigungen in einem Richtlinienspeicher und hilft Entwicklern, diese Berechtigungen zu verwenden, um Benutzeraktionen in ihren Anwendungen zu autorisieren.

Sie können Ihre Anwendung über die API mit dem Dienst verbinden, um Benutzerzugriffsanfragen zu autorisieren. Für jede Autorisierungsanfrage ruft der Service die relevanten Richtlinien ab und bewertet diese Richtlinien, um anhand von Kontexteingaben wie Benutzern, Rollen, Gruppenmitgliedschaft und Attributen festzustellen, ob ein Benutzer eine Aktion an einer Ressource ausführen darf. Sie können Verified Permissions konfigurieren und verbinden, um Ihre Richtlinienverwaltungs- und Autorisierungsprotokolle an AWS zu senden CloudTrail. Wenn Sie Amazon Cognito als Identitätsspeicher verwenden, können Sie Verified Permissions integrieren und die ID- und Zugriffstoken verwenden, die Amazon Cognito bei den Autorisierungsentscheidungen in Ihren Anwendungen zurückgibt. Sie stellen Amazon Cognito Cognito-Token für Verified Permissions bereit. Verified Permissions verwendet die Attribute, die die Token enthalten, um den Principal darzustellen und die Rechte des Prinzipals zu identifizieren. Weitere Informationen zu dieser Integration finden Sie im AWS-Blogbeitrag Vereinfachung der feinkörnigen Autorisierung mit Amazon Verified Permissions und Amazon Cognito.

Verified Permissions hilft Ihnen bei der Definition der richtlinienbasierten Zugriffskontrolle (PBAC). PBAC ist ein Zugriffskontrollmodell, das mithilfe von Berechtigungen, die als Richtlinien ausgedrückt werden, bestimmt, wer auf welche Ressourcen in einer Anwendung zugreifen kann. PBAC vereint die rollenbasierte Zugriffskontrolle (RBAC) und die attributebasierte Zugriffskontrolle (ABAC), was zu einem leistungsfähigeren und flexibleren Zugriffskontrollmodell führt. Weitere Informationen über PBAC und darüber, wie Sie mithilfe von Verified Permissions ein Autorisierungsmodell entwerfen können, finden Sie im AWS-Blogbeitrag Policy-based access control in application development with Amazon Verified Permissions.

In der AWS-SRA befindet sich Verified Permissions im Anwendungskonto, um die Berechtigungsverwaltung für Anwendungen durch die Integration mit Amazon Cognito zu unterstützen.

Mehrschichtiger Schutz

Das Anwendungskonto bietet die Möglichkeit, die mehrschichtigen Verteidigungsprinzipien zu veranschaulichen, die AWS ermöglicht. Betrachten Sie die Sicherheit der EC2-Instances, die den Kern einer einfachen Beispielanwendung bilden, die in der AWS-SRA dargestellt wird, und Sie können sehen, wie AWS-Services in einer mehrschichtigen Verteidigung zusammenarbeiten. Dieser Ansatz entspricht der strukturellen Sicht der AWS-Sicherheitsservices, wie im Abschnitt Anwenden von Sicherheitsservices in Ihrer gesamten AWS-Organisation weiter oben in diesem Handbuch beschrieben.

• Die innerste Schicht sind die EC2-Instances. Wie bereits erwähnt, enthalten EC2-Instances standardmäßig oder als Optionen viele native Sicherheitsfunktionen. Beispiele hierfür sind IMDSv2, das Nitro-System und die Amazon EBS-Speicherverschlüsselung.

• Die zweite Schutzschicht konzentriert sich auf das Betriebssystem und die Software, die auf den EC2-Instances ausgeführt werden. Mit Services wie Amazon Inspector und AWS Systems Manager können Sie diese Konfigurationen überwachen, Berichte erstellen und Korrekturmaßnahmen ergreifen. Inspector überwacht Ihre Software auf Sicherheitslücken, und Systems Manager unterstützt Sie bei der Aufrechterhaltung von Sicherheit und Compliance, indem verwaltete Instanzen auf ihren Patch - und Konfigurationsstatus überprüft und anschließend alle von Ihnen angegebenen Korrekturmaßnahmen gemeldet und entsprechende Korrekturmaßnahmen ergriffen werden.

• Die Instances und die auf diesen Instances ausgeführte Software gehören zu Ihrer AWS-Netzwerkinfrastruktur. Die AWS-SRA nutzt nicht nur die Sicherheitsfunktionen von Amazon VPC, sondern nutzt auch VPC-Endpunkte, um private Konnektivität zwischen der VPC und den unterstützten AWS-Services bereitzustellen und um einen Mechanismus zur Platzierung von Zugriffsrichtlinien an der Netzwerkgrenze bereitzustellen.

• Die Aktivität und Konfiguration der EC2-Instances, der Software, des Netzwerks und der IAM-Rollen und -Ressourcen werden von kundenorientierten AWS-Services wie AWS Security Hub, Amazon, AWS, AWS Config GuardDuty CloudTrail, AWS IAM Access Analyzer und Amazon Macie weiter überwacht.

• Über das Anwendungskonto hinaus hilft Ihnen AWS RAM schließlich dabei, zu kontrollieren, welche Ressourcen mit anderen Konten gemeinsam genutzt werden, und IAM-Servicesteuerungsrichtlinien helfen Ihnen dabei, konsistente Berechtigungen in der gesamten AWS-Organisation durchzusetzen.