Sicherheit auf mehreren Ebenen für webverwaltete Apps

von Guy Morton übersetzt durch Desiree Brunner

Sicherheit auf allen Ebenen anzuwenden ist ein Entwurfsprinzip der „Sicherheits” Säule des AWS Well-Architected Frameworks. Es fordert Sie auf sowohl, Sicherheit am Edge-Netzwerk, in der virtuellen privaten Cloud (VPC), auf dem Load Balancer, der Compute-Instanz (oder dem Service), dem Betriebssystem, der Anwendung und dem Code anzuwenden.

Viele gängige Webanwendungen sind mit einer einzigen Sicherheitsebene konzipiert: der Login-Seite. Hinter dieser Login-Seite befindet sich eine eingebaute Administrations-Oberfläche, die direkt dem Internet ausgesetzt ist. Admin-Schnittstellen für diese Apps haben in der Regel einfache Anmeldemechanismen und unterstützen oft keine Mehrfaktor-Authentifizierung (MFA), was sie zu einem attraktiven Ziel für Bedrohungsakteure machen kann.

Die integrierte Admin-Oberfläche kann auch dann problematisch sein, wenn Sie über mehrere Server horizontal skalieren möchten. Die Admin-Oberfläche ist auf jedem Server verfügbar, auf dem die App läuft, was eine große Angriffsfläche schafft. Da die Admin-Oberfläche die Software auf dem eigenen Server aktualisiert, müssen Sie Updates über eine Flotte von Instanzen hinweg synchronisieren.

Mehrstufige Sicherheit bedeutet, Isolationsgrenzen um die Teile Ihrer Architektur herum zu identifizieren (oder zu erstellen) und zu minimieren was erlaubt ist, um eine Grenze zu überschreiten. Mit jeder weiteren hinzugefügten Ebene haben Sie die Möglichkeit, zusätzliche Kontrollen auf jeder Ebene einzuführen und so weitere Grenzen zu schaffen, an denen Sicherheitskontrollen durchgesetzt werden können.

Das in diesem Beitrag beschriebene Anwendungsszenario ermöglicht es Ihnen viele zusätzliche Sicherheitsebenen einzufügen.

Beispiel für mehrstufige Sicherheit

Dieser Beitrag zeigt, wie Sie das Beispielprojekt „Ausführen von webadministrierten Apps auf AWS” nutzen können, um diese Herausforderungen anzugehen. Dieses Projekt implementiert eine horizontal skalierbare Architektur mit mehrstufiger Sicherheit. Das Projekt baut und konfiguriert viele verschiedene AWS-Services, die jeweils zur Sicherheit der verschiedenen Ebenen beitragen sollen.

Durch die Ausführung dieser Lösung können Sie eine segmentierte Architektur erstellen, die die beiden Funktionen dieser Apps in eine unprivilegierte öffentliche Ansicht und eine Administrator-Ansicht trennt. Dieses Design beschränkt den Zugriff auf die Administrator-Funktionen der Webanwendung und erstellt gleichzeitig eine Flotte unprivilegierter Instanzen zur skalierten Bereitstellung der App.

Abbildung 1 fasst zusammen, wie die verschiedenen Services in dieser Lösung zur Sicherheit auf folgenden Ebenen beitragen:

1. Am Netzwerkrand
2. Innerhalb der VPC
3. Auf dem Load Balancer
4. Auf den Compute-Instanzen
5. Innerhalb des Betriebssystems

Abbildung 1: Logisches Ablaufdiagramm zur Anwendung von Sicherheit auf mehreren Ebenen

Tiefgründige Betrachtung einer mehrschichtigen Architektur

Das folgende Diagramm zeigt die Lösungsarchitektur, die von „Ausführen von webadministrierten Apps auf AWS“ eingesetzt wird. Die Abbildung zeigt, wie die in dieser Lösung eingesetzten Services in verschiedenen AWS-Regionen bereitgestellt werden und wie Anfragen vom Anwendungsbenutzer durch die verschiedenen Serviceschichten fließen.

Abbildung 2: Mehrstufige Architektur

Dieser Beitrag wird sich näher mit jeder Ebene der Architektur befassen und zeigen, wie Sicherheit in jeder Ebene hinzugefügt wird. Bevor wir aber über die Technologie sprechen, sollten wir uns ansehen, wie Infrastruktur von Menschen aufgebaut und verwaltet wird.

Perimeter 0 – Sicherheit auf der Personenebene

Die Sicherheit beginnt bei den Personen in Ihrem Team und den operativen Praktiken Ihrer Organisation. Wie Ihre „Personenebene“ die Infrastruktur aufbaut und verwaltet, trägt erheblich zu Ihrem Sicherheitsstatus bei.

Ein Gestaltungsprinzip des Security-Pfeilers des Well-Architected Frameworks ist die Automatisierung von Sicherheits-Best-Practices. Dies hilft auf zweierlei Weise: Es reduziert den erforderlichen Aufwand für Personen im Laufe der Zeit und verhindert, dass sich Ressourcen in einem inkonsistenten oder falsch konfigurierten Zustand befinden. Wenn Menschen manuelle Prozesse zur Erledigung von Aufgaben verwenden, sind Fehler und übersehene Schritte häufig.

Der einfachste Weg, die Sicherheit zu automatisieren und den menschlichen Aufwand zu reduzieren, ist die Nutzung der von AWS verwalteten Services wie Amazon Relational Database Service (Amazon RDS). Bei Amazon RDS ist AWS für die Patches des Betriebssystems und der Datenbanksoftware verantwortlich und stellt Tools bereit, mit denen Sie Ihre Daten einfach sichern und wiederherstellen können.

Sie können wichtige Sicherheitsfunktionen automatisieren und integrieren, indem Sie verwaltete AWS-Sicherheitsservices wie Amazon GuardDuty, AWS Config, Amazon Inspector und AWS Security Hub nutzen. Diese Services bieten Netzwerküberwachung, Konfigurationsmanagement sowie die Erkennung von Softwareschwachstellen und unbeabsichtigter Netzwerkrisiken. Mit zunehmender Skalierung und Komplexität Ihrer Cloud-Umgebungen ist eine automatisierte Sicherheitsüberwachung unerlässlich.

Infrastructure as Code (IaC, zu Deutsch: Infrastruktur durch Code) ist eine bewährte Methode, der Sie folgen können, um die Erstellung von Infrastruktur zu automatisieren. Mit IaC definieren, konfigurieren und stellen Sie die von Ihnen genutzen AWS-Ressourcen bereit, und reduzieren somit die Wahrscheinlichkeit menschlicher Fehler beim Aufbau der AWS-Infrastruktur.

Die Einführung von IaC kann Ihren Sicherheitsstatus verbessern, da Sie die bei der Anwendungsentwicklung genutze Genauigkeit auf die Infrastrukturbereitstellung anwenden. Wenn Sie Ihre Infrastruktur-Definition in einem Source-Control-System (wie AWS CodeCommit) speichern, erstellen Sie ein prüfbares Artefakt. Mit der Versionskontrolle können Sie die Änderungen, die im Laufe der Zeit an der Architektur vorgenommen wurden, nachverfolgen.

Sie können automatisierte Tests zu Ihrem IaC-Projekt hinzufügen, um sicherzustellen, dass Ihre Infrastruktur den Sicherheitsrichtlinien Ihrer Organisation entspricht. Bei einer Notfallwiederherstellung im Falle eines Katastrophenereignisses, können Sie die vollständige Infrastruktur aus Ihrem IaC-Projekt erneut bereitstellen.

Eine weitere Disziplin auf der Personenebene ist die Anwendung des Prinzips der geringsten Rechte. AWS Identity and Access Management (IAM) ist ein flexibles und fein granulares Berechtigungssystem, mit dem Sie die kleinstmögliche Menge an Aktionen gewähren können, die Ihre Lösung benötigt. Sie können IAM zur Kontrolle des Zugriffs sowohl für Menschen als auch für Maschinen verwenden. In diesem Projekt verwenden wir es, um den Compute-Instanzen die am wenigsten benötigten Berechtigungen zu erteilen.

Sie können auch andere bewährte IAM-Methoden befolgen, wie z.B. die Verwendung temporärer Anmeldeinformationen anstelle langlebiger (wie Zugriffsschlüssel) und die regelmäßige Überprüfung und Entfernung nicht verwendeter Benutzer, Rollen, Berechtigungen, Richtlinien und Anmeldeinformationen.

Perimeter 1 – Netzwerkschutz

Das Internet ist öffentlich und daher nicht vertrauenswürdig, weshalb Sie proaktiv die Risiken durch Bedrohungsakteure und Netzwerkattacken angehen müssen.

Um das Risiko von Distributed-Denial-of-Service (DDoS)-Angriffen zu verringern, verwendet diese Lösung AWS Shield für einen verwalteten Schutz am Edge-Netzwerk. AWS Shield Standard ist automatisch für alle AWS-Kunden ohne zusätzliche Kosten aktiviert und soll Schutz vor gängigen DDoS-Angriffen auf Netzwerk- und Transportebene bieten. Für einen erhöhten Schutz vor Angriffen auf Ihre Anwendungen zu gewährleisten, können Sie AWS Shield Advanced abonnieren.

Amazon Route 53 löst die Hostnamen auf, die die Lösung verwendet, und ordnet die Hostnamen als Aliase einer Amazon CloudFront-Distribution zu. Route 53 ist ein hochverfügbarer und skalierbarer Domain Name System (DNS)-Web-Service, der Anfragen überprüft, um vor DNS-spezifischen Angriffsarten wie „DNS Amplification Attacks” (deutsch DNS-Verstärkungsangriffen) zu schützen.

Perimeter 2 – Verarbeitung von Anfragen

CloudFront arbeitet ebenfalls an dem AWS-Edge-Netzwerk und cached, transformiert und leitet eingehende Anfragen weiter an die relevanten Origin-Services über das globale AWS-Netzwerk mit niedriger Latenz. Das Risiko, dass DDoS-Versuche Ihre Anwendungsserver überlasten, wird zusätzlich durch das Caching von Web-Anfragen in CloudFront reduziert.

Die Lösung konfiguriert CloudFront so, dass in einer benutzerdefinierten Header ein gemeinsames Geheimnis zur Origin-Anfrage hinzugefügt wird. Eine CloudFront-Funktion kopiert die IP des Ursprungsbenutzers in eine andere benutzerdefinierte Header. Diese Header werden überprüft, wenn die Anfrage am Load Balancer ankommt.

AWS WAF, eine Web Application Firewall, blockiert bekannten schädlichen Traffic wie Cross-Site-Scripting (XSS) und SQL-Injection-Ereignisse, die hier in CloudFront eintreffen. Dieses Projekt verwendet AWS Managed Rules, aber Sie können auch eigene Regeln hinzufügen. Um den Frontend-Zugriff auf erlaubte IP-CIDR-Blöcke zu beschränken, konfiguriert dieses Projekt eine IP-Einschränkungsregel auf der Web Application Firewall.

Perimeter 3 – die VPC

Nachdem CloudFront und AWS WAF die Anfrage überprüft haben, leitet CloudFront sie an die Compute-Services innerhalb einer Amazon Virtual Private Cloud (Amazon VPC) weiter. VPCs sind logisch isolierte Netzwerke innerhalb Ihres AWS-Kontos, mit denen Sie den ein- und ausgehenden Netzwerkverkehr steuern können. Dieses Projekt konfiguriert ihre VPC so, dass es einen privaten IPv4-CIDR-Block verwendet, der nicht direkt von oder zum Internet geroutet werden kann, wodurch ein Netzwerkperimeter um Ihre Ressourcen bei AWS erzeugt wird.

Die Amazon Elastic Compute Cloud (Amazon EC2)-Instanzen werden in privaten Subnetzen innerhalb der VPCs gehostet, die keine eingehende Route aus dem Internet haben. Mit einem NAT-Gateway können Instanzen die erforderlichen ausgehenden Anfragen stellen. Dieses Design hostet die Datenbank-Instanzen in isolierten Subnetzen, die weder über einen ein- noch ausgehenden Internetzugriff verfügen. Amazon RDS ist ein verwalteter Service, so dass AWS das Patchen des Servers und der Datenbanksoftware verwaltet.

Auf AWS Secrets Manager greift die Lösung über einen VPC-Endpunkt zu. VPC-Endpunkte nutzen AWS PrivateLink, um Ihre VPC mit AWS-Services zu verbinden, als wären sie in Ihrer VPC. Auf diese Weise können Ressourcen in die VPC mit Secrets Manager kommunizieren, ohne das Internet zu durchqueren.

Das Projekt konfiguriert VPC Flow Logs als Teil der VPC-Einrichtung. VPC Flow Logs erfassen Informationen über den IP-Verkehr, der zu und von Netzwerkschnittstellen in Ihrem VPC geht. GuardDuty analysiert diese Protokolle und verwendet Bedrohungsinformationen, um unerwartete, potenziell unbefugte und böswillige Aktivitäten in Ihrer AWS-Umgebung zu identifizieren.

Auch wenn die Verwendung von VPCs und Subnetzen zur Segmentierung von Teilen Ihrer Anwendung eine gängige Strategie ist, gibt es noch andere Möglichkeiten, eine Partitionierung für Anwendungskomponenten zu erreichen:

• Sie können separate VPCs verwenden, um den Zugriff auf eine Datenbank einzuschränken, und VPC-Peering nutzen, um den Datenverkehr zwischen ihnen zu routen.
• Sie können eine Multi-Account-Strategie verwenden, sodass bei verschiedenen Konten unterschiedliche Sicherheits- und Compliance-Kontrollen angewendet werden, um starke logische Grenzen zwischen Teilen eines Systems zu schaffen. Sie können den Netzwerkverkehr mit Services wie AWS Transit Gateway zwischen Konten routen und mit AWS Network Firewall

Es gibt immer Kompromisse zwischen Komplexität, Benutzerfreundlichkeit und Sicherheit, so dass das richtige Maß an Isolation zwischen Komponenten von Ihren Anforderungen abhängt.

Perimeter 4 – Der Load Balancer

Nachdem die Anfrage an die VPC gesendet wurde, wird sie von einem Application Load Balancer (ALB) verarbeitet. Der ALB verteilt die Anfragen auf die zugrunde liegenden EC2-Instanzen. Der ALB verwendet TLS-Version 1.2, um eingehende Verbindungen mit einem AWS Certificate Manager (ACM)-Zertifikat zu verschlüsseln.

Der öffentliche Zugriff auf den Load Balancer ist nicht erlaubt. Eine auf den ALB angewandte Sicherheitsgruppe erlaubt nur eingehenden Datenverkehr über Port 443 aus dem CloudFront-IP-Bereich. Dies wird erreicht, indem die regionsspezifische AWS-verwaltete CloudFront-Präfix-Liste als Quelle in der Regel der Sicherheitsgruppe angegeben wird.

Der ALB verwendet Regeln, um zu entscheiden, ob die Anfrage an die Ziel-Instanzen weitergeleitet oder der Datenverkehr abgelehnt werden soll. Als zusätzliche Sicherheitsebene verwendet er die benutzerdefinierten Header, die die CloudFront-Verteilung hinzugefügt hat, um sicherzustellen, dass die Anfrage von CloudFront stammt. In einer anderen Regel verwendet der ALB die IP-Adresse des Ursprungsbenutzers, um zu entscheiden, welche Zielgruppe von Amazon EC2-Instanzen die Anfrage verarbeiten soll. Auf diese Weise können Sie Admin-Benutzer zu Instanzen leiten, die für Admin-Aufgaben konfiguriert sind.

Wenn eine Anfrage keiner gültigen Regel entspricht, sendet der ALB eine Antwort mit dem HTTP-Statuscode „404 Not Found” an den Benutzer zurück.

Perimeter 5 – Berechnen der Netzwerksicherheit von Instanzen

Eine Sicherheitsgruppe erstellt eine Isolationsgrenze um die EC2-Instanzen. Der einzige Datenverkehr, der die Instanz erreicht, ist der Datenverkehr, den die Regeln der Sicherheitsgruppe zulassen. In dieser Lösung darf nur der ALB eingehende Verbindungen zu den EC2-Instanzen herstellen.

Eine gängige Praxis ist es, dass Kunden auch Ports öffnen oder Bastion-Hosts einrichten und verwalten, um einen Remotezugriff auf ihre Compute-Instanzen zu ermöglichen. Das Risiko bei diesem Ansatz besteht darin, dass die Ports für das gesamte Internet geöffnet werden könnten und die Instanzen für Sicherheitslücken im Remoteprotokolls anfällig werden. Mit der zunehmenden Verbreitung von Homeoffice steigt das Risiko für die Erstellung dieser übermäßig permissiven eingehenden Regeln.

Mit AWS Systems Manager Session Manager können Sie den Bedarf an Bastion-Hosts oder offenen Ports beseitigen, indem Sie sichere temporäre Verbindungen zu Ihren EC2-Instanzen über den dort installierten SSM-Agent herstellen. Wie bei jeder Software, die Sie installieren, sollten Sie prüfen, ob der SSM-Agent Ihren Sicherheits- und Compliance-Anforderungen entspricht. Der Quellcode des SSM-Agents ist zur Überprüfung öffentlich zugänglich, siehe amazon-ssm-agent GitHub-Repository.

Die Compute-Ebene dieser Lösung besteht aus zwei separaten Amazon EC2 Auto Scaling Gruppen mit EC2-Instanzen. Eine Gruppe behandelt Anfragen von Administratoren, während die andere Anfragen von unpriviligierten Benutzern behandelt. Dies schafft eine weitere Isolationsgrenze, indem die Funktionen getrennt gehalten und gleichzeitig verhindert wird, dass ein Ausfall einer Komponente zum Ausfall des gesamten Systems führt. Jede Amazon EC2 Auto Scaling Gruppe erstreckt sich über mehrere Availability Zones (zu Deutsch: Verfügbarkeitszonen) und bietet so Resilienz bei einem Ausfall in einer Verfügbarkeitszone.

Durch die Verwendung von verwalteten Datenbankservices können Sie das Risiko verringern, dass Datenbankserverinstanzen nicht proaktiv mit Sicherheitsupdates gepatcht wurden. Verwaltete Infrastruktur hilft, das Risiko von Sicherheitsproblemen zu verringern, die darauf zurückzuführen sind, dass das zugrunde liegende Betriebssystem nicht zeitnah mit Sicherheitspatches versorgt wurde, sowie das Risiko von Ausfallzeiten durch Hardwarefehler.

Perimeter 6 – Berechnen des Betriebssystems von Instanzen

Wenn Instanzen zum ersten Mal gestartet werden, muss das Betriebssystem sicher sein, und die Instanzen müssen bei der Veröffentlichung neuer Sicherheits-Patches bei Bedarf aktualisiert werden. Wir empfehlen, unveränderbare Server zu erstellen und mit einem Tool wie EC2 Image Builder zu härten. Anstatt laufende Instanzen vor Ort zu patchen, ersetzen Sie sie, wenn ein aktualisiertes Amazon Machine Image (AMI) erstellt wird. Dieser Ansatz funktioniert in unserem Szenario-Beispiel, da der Anwendungscode (der sich im Laufe der Zeit ändert) auf Amazon Elastic File System (Amazon EFS) gespeichert ist. Wenn Sie also die Instanzen durch ein neues AMI ersetzen, können Sie Ihre aktuellen Anwendungsdaten ohne Zwischenschritt weiterverwenden.

Eine weitere Möglichkeit, mit der die Lösung die Sicherheit auf Ihren Instanzen auf Betriebssystemebene verbessert, ist die Verwendung von EC2-Instanzprofilen, damit sie IAM-Rollen annehmen können. IAM-Rollen gewähren Anwendungen, die auf EC2 laufen, temporäre Anmeldeinformationen anstatt hartcodierte Anmeldeinformationen, die auf der Instanz gespeichert sind. Der Zugriff auf andere AWS-Ressourcen erfolgt mit diesen temporären Anmeldeinformationen.

Die IAM-Rollen haben angehängte Richtlinien mit geringsten Rechten, die die Berechtigung zum Einbinden des EFS-Dateisystems und den Zugriff auf AWS Systems Manager erteilen. Wenn ein Datenbankgeheimnis in Secrets Manager vorhanden ist, erhält die IAM-Rolle die Berechtigung zum Zugriff darauf.

Perimeter 7 – Auf dem Dateisystem

Beide Auto-Scaling-Gruppen von EC2-Instanzen haben gemeinsamen Zugriff auf Amazon EFS, auf dem die von der Anwendung verwendeten Dateien bereitgestellt werden. Die IAM-Autorisierung wendet IAM-Dateisystemrichtlinien an, um den Zugriff der Instanz auf das Dateisystem zu steuern. Dadurch entsteht eine weitere Isolationsgrenze, die verhindert, dass die Nicht-Admin-Instanzen die Anwendungsdateien ändern.

Bei den Instanzen der Admin-Gruppe ist das Dateisystem im Lese-Schreib-Modus eingehängt. Dies ist erforderlich, damit die Anwendung sich selbst aktualisieren, Add-Ons installieren, Inhalte hochladen oder Konfigurationsänderungen vornehmen kann. Auf den nicht-privilegierten Instanzen ist das Dateisystem im Schreibgeschützten Modus eingehängt. Dies bedeutet, dass diese Instanzen keine Änderungen am Anwendungscode oder den Konfigurationsdateien vornehmen können.

Auf den nicht-privilegierten Instanzen ist das lokale Datei-Caching aktiviert. Dadurch werden Dateien vom EFS-Dateisystem auf dem lokalen Amazon Elastic Block Store (Amazon EBS)-Volume zwischengespeichert, um die Skalierbarkeit und Leistung zu verbessern.

Perimeter 8 – Webserver-Konfiguration

Diese Lösung verwendet unterschiedliche Webserver-Konfigurationen für die Instanzen in der jeweiliger Amazon EC2 Auto-Scaling-Gruppe. Dadurch wird eine weitere Isolationsgrenze auf Webserver-Ebene geschaffen.

Die Admin-Instanzen verwenden die Standardkonfiguration für die Anwendung, die Zugriff auf die Admin-Oberfläche erlaubt. Öffentlich zugängliche Nicht-Admin-Instanzen blockieren Admin-Routen wie wp-login.php und geben einen „403 Forbidden” HTTP-Fehler zurück. Dies schafft eine zusätzliche Schutzstufe für diese Routen.

Perimeter 9 – Datenbankensicherheit

Die Datenbankschicht befindet sich innerhalb von zwei weiteren Isolationsgrenzen. Die Lösung verwendet Amazon RDS, mit Datenbankinstanzen, die in isolierten Subnetzen bereitgestellt werden. Isolierte Subnetze haben keine eingehende oder ausgehende Internetverbindung und können nur über andere Netzwerkschnittstellen innerhalb der VPCs erreicht werden. Die RDS-Sicherheitsgruppe isoliert die Datenbankinstanzen weiter, indem sie nur eingehenden Verkehr von den EC2-Instanzen über den Datenbankserver-Port zulässt.

Durch die Verwendung der IAM-Authentifizierung für den Datenbankzugriff können Sie eine zusätzliche Sicherheitsebene hinzufügen, indem Sie die Nicht-Admin-Instanzen mit weniger privilegierten Datenbankbenutzeranmeldeinformationen konfigurieren.

Perimeter 10 – Sicherheit auf Anwendungscode-Ebene

Um Sicherheit auf Anwendungscode-Ebene anzuwenden, sollten Sie bewährte Methoden beim Installieren von verfügbaren Updates etablieren. Die meisten Anwendungen haben E-Mail-Listen, denen Sie folgen können, um benachrichtigt zu werden, wenn Updates verfügbar sind.

Sie sollten die Qualität einer Anwendung bewerten, bevor Sie sie einsetzen. Folgende Metriken sollten Sie berücksichtigen:

• Anzahl der Entwickler, die aktiv daran arbeiten
• Häufigkeit der Updates
• Wie schnell die Entwickler mit Patches reagieren, wenn Bugs gemeldet werden

Weitere Schritte, die Sie unternehmen können:

Nutzen Sie AWS Verified Access, um den Anwendungszugriff für menschliche Benutzer abzusichern. Mit Verified Access können Sie eine zusätzliche Benutzerauthentifizierungsstufe hinzufügen, um sicherzustellen, dass nur verifizierte Benutzer auf administrative Funktionen einer Anwendung zugreifen können.

Amazon GuardDuty ist ein Service zur Erkennung von Bedrohungen, der Ihre AWS-Konten und Workloads kontinuierlich auf schädliche Aktivitäten überwacht und detaillierte Sicherheitsergebnisse für Sichtbarkeit und Behebung liefert. Es kann die Kommunikation mit bekannten schädlichen Domänen und IP-Adressen erkennen und anomales Verhalten identifizieren. Der GuardDuty-Malware-Schutz hilft Ihnen Malware zu erkennen, indem die EBS-Volumes gescannt werden, die an Ihre EC2-Instanzen angehängt sind.

Amazon Inspector ist ein automatisierter Vulnerability-Management-Service, der automatisch die laufenden Amazon EC2-Instanzen erkennt und auf Softwareschwachstellen und unbeabsichtigte Netzwerkrisiken scannt. Um sicherzustellen, dass Ihre Web-Server-Instanzen aktualisiert werden, wenn Sicherheits-Patches verfügbar sind, verwenden Sie AWS Systems Manager Patch Manager.

Schlussfolgerung

In diesem Beitrag haben Sie gelernt, wie man eine Architektur auf AWS aufbaut, die mehrschichtige Sicherheit implementiert. Sie können verschiedene AWS-Services nutzen, um Ihrem Programm in verschiedenen Phasen des Anforderungslebenszyklus Schutz zu bieten.

Sie können mittels unseres Beispielprojektes mehr über die in diesem Blogartikel verwendeten Services lernen, indem Sie es in Ihrem eigenen Konto aufbauen. Es ist eine großartige Möglichkeit zu erkunden, wie die verschiedenen Services funktionieren und welche Funktionen verfügbar sind. Indem Sie verstehen, wie diese AWS-Services funktionieren, werden Sie bereit sein, sie zu verwenden, um Sicherheit auf mehreren Ebenen in Ihre eigenen Architekturen einzubauen.

Wenn Sie Feedback zu diesem Beitrag haben, hinterlassen Sie Kommentare im Kommentarbereich unten. Wenn Sie Fragen zu diesem Beitrag haben, wenden Sie sich an den AWS-Support.

Möchten Sie mehr Nachrichten zu AWS-Sicherheit erhalten? Folgen Sie uns auf X (vormals Twitter).

Guy Morton ist ein leitender Lösungsarchitekt bei AWS. Er bringt seine jahrzehntelange Erfahrung als Full-Stack-Entwickler, Architekt und Personalmanager ein, um Kunden dabei zu unterstützen, ihre Anwendungen sicher und skalierbar in der AWS-Cloud aufzubauen. Guy hat eine Leidenschaft für Automatisierung in all ihren Formen und ist außerdem ein gelegentlicher Songwriter und Musiker, der unter dem Pseudonym Whtsqr auftritt.