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.
Wenden Sie Sicherheitsservices in Ihrer gesamten AWS-Organisation an
| Beeinflussen Sie die future der AWS Security Reference Architecture (AWSSRA), indem Sie an einer kurzen Umfrage teilnehmen |
Wie in einem vorherigen Abschnitt beschrieben, suchen Kunden nach einer zusätzlichen Möglichkeit, über die gesamte Palette der AWS-Sicherheitsservices nachzudenken und diese strategisch zu organisieren. Der gängigste organisatorische Ansatz besteht heute darin, Sicherheitsservices nach Hauptfunktionen zu gruppieren — je nachdem, was jeder Service tut. Die Sicherheitsperspektive von AWS CAF listet neun funktionale Funktionen auf, darunter Identitäts- und Zugriffsmanagement, Infrastrukturschutz, Datenschutz und Bedrohungserkennung. Die Abstimmung der AWS-Services mit diesen funktionalen Funktionen ist eine praktische Methode, um Implementierungsentscheidungen in den einzelnen Bereichen zu treffen. Wenn es beispielsweise um Identitäts- und Zugriffsmanagement geht, sind IAM und IAM Identity Center Services, die in Betracht gezogen werden sollten. Bei der Gestaltung Ihres Ansatzes zur Bedrohungserkennung GuardDuty könnte Amazon Ihre erste Überlegung sein.
Als Ergänzung zu dieser funktionalen Sichtweise können Sie Ihre Sicherheit auch aus einer übergreifenden, strukturellen Sicht betrachten. Das heißt, zusätzlich zu der Frage: „Welche AWS-Services sollte ich verwenden, um meine Identitäten, meinen logischen Zugriff oder meine Mechanismen zur Bedrohungserkennung zu kontrollieren und zu schützen?“ , können Sie auch fragen: „Welche AWS-Services sollte ich in meiner gesamten AWS-Organisation anwenden? Welche Verteidigungsebenen sollte ich einrichten, um die Amazon EC2 EC2-Instances im Kern meiner Anwendung zu schützen?“ In dieser Ansicht ordnen Sie AWS-Services und -Funktionen Ebenen in Ihrer AWS-Umgebung zu. Einige Services und Funktionen eignen sich hervorragend für die Implementierung von Kontrollen in Ihrer gesamten AWS-Organisation. Das Blockieren des öffentlichen Zugriffs auf Amazon S3 S3-Buckets ist beispielsweise eine spezifische Kontrolle auf dieser Ebene. Dies sollte vorzugsweise in der Stammorganisation erfolgen, anstatt Teil der individuellen Kontoeinrichtung zu sein. Andere Services und Funktionen eignen sich am besten zum Schutz einzelner Ressourcen innerhalb eines AWS-Kontos. Ein Beispiel für diese Kategorie ist die Implementierung einer untergeordneten Zertifizierungsstelle (CA) innerhalb eines Kontos, für das private TLS-Zertifikate erforderlich sind. Eine weitere ebenso wichtige Gruppierung besteht aus Services, die sich auf die virtuelle Netzwerkschicht Ihrer AWS-Infrastruktur auswirken. Das folgende Diagramm zeigt sechs Ebenen in einer typischen AWS-Umgebung: AWS-Organisation, Organisationseinheit (OU), Konto, Netzwerkinfrastruktur, Prinzipale und Ressourcen.
Das Verständnis der Services in diesem strukturellen Kontext, einschließlich der Kontrollen und Schutzmaßnahmen auf jeder Ebene, hilft Ihnen bei der Planung und Implementierung einer defense-in-depth Strategie in Ihrer AWS-Umgebung. Mit dieser Perspektive können Sie Fragen sowohl von oben nach unten beantworten (z. B. „Welche Services verwende ich, um Sicherheitskontrollen in meiner gesamten AWS-Organisation zu implementieren?“) und von unten nach oben (z. B. „Welche Services verwalten die Kontrollen auf dieser EC2-Instance?“). In diesem Abschnitt gehen wir die Elemente einer AWS-Umgebung durch und identifizieren die zugehörigen Sicherheitsservices und -funktionen. Natürlich verfügen einige AWS-Services über umfangreiche Funktionen und unterstützen mehrere Sicherheitsziele. Diese Services unterstützen möglicherweise mehrere Elemente Ihrer AWS-Umgebung.
Aus Gründen der Übersichtlichkeit beschreiben wir kurz, wie einige der Services den angegebenen Zielen entsprechen. Im nächsten Abschnitt werden die einzelnen Services innerhalb jedes AWS-Kontos näher erläutert.
Unternehmensweit oder mehrere Konten
Auf der obersten Ebene gibt es AWS-Services und -Funktionen, die darauf ausgelegt sind, Governance- und Kontrollfunktionen oder Guardrails auf mehrere Konten in einer AWS-Organisation (einschließlich der gesamten Organisation oder bestimmter Organisationseinheiten) anzuwenden. Service Control Policies (SCPs) sind ein gutes Beispiel für eine IAM-Funktion, die einen präventiven unternehmensweiten AWS-Schutzmechanismus bietet. Ein anderes Beispiel ist AWS CloudTrail, das die Überwachung über einen Organisationspfad ermöglicht, der alle Ereignisse für alle AWS-Konten in dieser AWS-Organisation protokolliert. Dieser umfassende Trail unterscheidet sich von einzelnen Trails, die möglicherweise in jedem Konto erstellt werden. Ein drittes Beispiel ist AWS Firewall Manager, mit dem Sie mehrere Ressourcen für alle Konten in Ihrer AWS-Organisation konfigurieren, anwenden und verwalten können: AWS WAF-Regeln, AWS WAF Classic-Regeln, AWS Shield Advanced-Schutzmaßnahmen, Amazon Virtual Private Cloud (Amazon VPC) -Sicherheitsgruppen, AWS-Netzwerk-Firewall-Richtlinien und Amazon Route 53 Resolver DNS-Firewall-Richtlinien.
Die in der folgenden Abbildung mit einem Sternchen (*) markierten Dienste haben einen doppelten Anwendungsbereich: unternehmensweit und kundenorientiert. Diese Dienste überwachen oder kontrollieren grundsätzlich die Sicherheit innerhalb eines einzelnen Kontos. Sie unterstützen jedoch auch die Möglichkeit, die Ergebnisse mehrerer Konten in einem unternehmensweiten Konto zusammenzufassen, um so eine zentrale Transparenz und Verwaltung zu gewährleisten. Der Klarheit halber sollten Sie SCPs in Betracht ziehen, die für eine gesamte OU, ein AWS-Konto oder eine AWS-Organisation gelten. Im Gegensatz dazu können Sie Amazon GuardDuty sowohl auf Kontoebene (wo individuelle Ergebnisse generiert werden) als auch auf AWS-Organisationsebene (mithilfe der Funktion für delegierte Administratoren) konfigurieren und verwalten, wo die Ergebnisse zusammengefasst angezeigt und verwaltet werden können.
AWS-Konten
Innerhalb von Organisationseinheiten gibt es Services, die dabei helfen, mehrere Arten von Elementen innerhalb eines AWS-Kontos zu schützen. Beispielsweise wird AWS Secrets Manager häufig von einem bestimmten Konto aus verwaltet und schützt Ressourcen (wie Datenbankanmeldedaten oder Authentifizierungsinformationen), Anwendungen und AWS-Services in diesem Konto. AWS IAM Access Analyzer kann so konfiguriert werden, dass Ergebnisse generiert werden, wenn Principals außerhalb des AWS-Kontos auf bestimmte Ressourcen zugreifen können. Wie im vorherigen Abschnitt erwähnt, können viele dieser Services auch innerhalb von AWS Organizations konfiguriert und verwaltet werden, sodass sie über mehrere Konten hinweg verwaltet werden können. Diese Dienste sind im Diagramm mit einem Sternchen (*) gekennzeichnet. Sie machen es auch einfacher, Ergebnisse aus mehreren Konten zu aggregieren und sie an ein einziges Konto zu übertragen. Dies gibt den einzelnen Anwendungsteams die Flexibilität und Transparenz, um Sicherheitsanforderungen zu verwalten, die für ihre Arbeitslast spezifisch sind, und ermöglicht gleichzeitig zentralen Sicherheitsteams Steuerung und Transparenz. Amazon GuardDuty ist ein Beispiel für einen solchen Service. GuardDutyüberwacht Ressourcen und Aktivitäten, die mit einem einzelnen Konto verknüpft sind, und GuardDuty Ergebnisse aus mehreren Mitgliedskonten (z. B. allen Konten in einer AWS-Organisation) können von einem delegierten Administratorkonto aus gesammelt, angezeigt und verwaltet werden.
Virtuelles Netzwerk, Datenverarbeitung und Bereitstellung von Inhalten
Da der Netzwerkzugriff für die Sicherheit so wichtig ist und die Recheninfrastruktur eine grundlegende Komponente vieler AWS-Workloads ist, gibt es viele AWS-Sicherheitsservices und -funktionen, die diesen Ressourcen gewidmet sind. Amazon Inspector ist beispielsweise ein Schwachstellen-Management-Service, der Ihre AWS-Workloads kontinuierlich auf Sicherheitslücken scannt. Diese Scans beinhalten Prüfungen der Netzwerkerreichbarkeit, die darauf hinweisen, dass es in Ihrer Umgebung zulässige Netzwerkpfade zu Amazon EC2 EC2-Instances gibt. Mit Amazon Virtual Private Cloud
Prinzipien und Ressourcen
AWS-Prinzipale und AWS-Ressourcen (zusammen mit IAM-Richtlinien) sind die grundlegenden Elemente des Identitäts- und Zugriffsmanagements auf AWS. Ein authentifizierter Principal in AWS kann Aktionen ausführen und auf AWS-Ressourcen zugreifen. Ein Principal kann als Root-Benutzer oder IAM-Benutzer eines AWS-Kontos oder durch Übernahme einer Rolle authentifiziert werden.
Anmerkung
Erstellen Sie keine persistenten API-Schlüssel, die dem AWS-Root-Benutzer zugeordnet sind. Der Zugriff auf den Root-Benutzer sollte nur auf die Aufgaben beschränkt werden, für die ein Root-Benutzer erforderlich ist, und dann nur über ein strenges Ausnahme- und Genehmigungsverfahren. Bewährte Methoden zum Schutz des Root-Benutzers Ihres Kontos finden Sie in der AWS-Dokumentation.
Eine AWS-Ressource ist ein Objekt, das in einem AWS-Service vorhanden ist und mit dem Sie arbeiten können. Beispiele hierfür sind eine EC2-Instance, ein CloudFormation AWS-Stack, ein Amazon Simple Notification Service (Amazon SNS) -Thema und ein S3-Bucket. IAM-Richtlinien sind Objekte, die Berechtigungen definieren, wenn sie einer IAM-Identität (Benutzer, Gruppe oder Rolle) oder AWS-Ressource zugeordnet sind. Identitätsbasierte Richtlinien sind Richtliniendokumente, die Sie einem Principal (Rollen, Benutzer und Benutzergruppen) zuordnen, um zu steuern, welche Aktionen ein Principal auf welchen Ressourcen und unter welchen Bedingungen ausführen kann. Ressourcenbasierte Richtlinien sind Richtliniendokumente, die Sie an eine Ressource wie einen S3-Bucket anhängen. Diese Richtlinien gewähren dem angegebenen Hauptbenutzer die Berechtigung, bestimmte Aktionen an dieser Ressource auszuführen, und definieren die Bedingungen für diese Berechtigung. Bei ressourcenbasierten Richtlinien handelt es sich um Inline-Richtlinien. Der Abschnitt mit den IAM-Ressourcen befasst sich eingehender mit den Arten von IAM-Richtlinien und ihrer Verwendung.
Um die Dinge in dieser Diskussion einfach zu halten, listen wir AWS-Sicherheitsservices und -funktionen für IAM-Entitäten auf, deren Hauptzweck darin besteht, auf Kontoprinzipalen zu arbeiten oder für diese zu gelten. Wir behalten diese Einfachheit bei und erkennen gleichzeitig die Flexibilität und den Umfang der Auswirkungen der IAM-Genehmigungsrichtlinien an. Eine einzelne Aussage in einer Richtlinie kann Auswirkungen auf mehrere Arten von AWS-Entitäten haben. Eine identitätsbasierte IAM-Richtlinie ist zwar einer IAM-Entität zugeordnet und definiert Berechtigungen (zulassen, verweigern) für diese Entität, aber die Richtlinie definiert auch implizit Berechtigungen für die angegebenen Aktionen, Ressourcen und Bedingungen. Auf diese Weise kann eine identitätsbasierte Richtlinie ein entscheidendes Element bei der Definition von Berechtigungen für eine Ressource sein.
Das folgende Diagramm veranschaulicht die AWS-Sicherheitsservices und -funktionen für AWS-Prinzipale. Identitätsbasierte Richtlinien werden an IAM-Ressourcenobjekte angehängt, die zur Identifizierung und Gruppierung verwendet werden, wie z. B. Benutzer, Gruppen und Rollen. Mit diesen Richtlinien können Sie festlegen, welche Aktionen diese Identität durchführen darf (ihre Berechtigungen). Eine IAM-Sitzungsrichtlinie ist eine Inline-Berechtigungsrichtlinie, die Benutzer in der Sitzung weitergeben, wenn sie die Rolle übernehmen. Sie können die Richtlinie selbst verabschieden oder Ihren Identity Broker so konfigurieren, dass er die Richtlinie einfügt, wenn Ihre Identitäten mit AWS verbunden werden. Auf diese Weise können Ihre Administratoren die Anzahl der Rollen reduzieren, die sie erstellen müssen, da mehrere Benutzer dieselbe Rolle übernehmen können, aber über eindeutige Sitzungsberechtigungen verfügen. Der IAM Identity Center-Service ist in AWS Organizations und AWS-API-Operationen integriert und unterstützt Sie bei der Verwaltung des SSO-Zugriffs und der Benutzerberechtigungen für Ihre AWS-Konten in AWS Organizations.
Das folgende Diagramm zeigt Dienste und Funktionen für Kontoressourcen. Ressourcenbasierten Richtlinien sind an eine Ressource angefügt. Sie können beispielsweise ressourcenbasierte Richtlinien an S3-Buckets, Amazon Simple Queue Service (Amazon SQS) -Warteschlangen, VPC-Endpunkte und AWS KMS KMS-Verschlüsselungsschlüssel anhängen. Sie können ressourcenbasierte Richtlinien verwenden, um festzulegen, wer Zugriff auf die Ressource hat und welche Aktionen sie mit ihr ausführen können. S3-Bucket-Richtlinien, AWS KMS KMS-Schlüsselrichtlinien und VPC-Endpunktrichtlinien sind Arten von ressourcenbasierten Richtlinien. AWS IAM Access Analyzer hilft Ihnen dabei, die Ressourcen in Ihrer Organisation und Konten, wie S3-Buckets oder IAM-Rollen, zu identifizieren, die mit einer externen Entität gemeinsam genutzt werden. Dies hilft Ihnen, unbeabsichtigten Zugriff auf Ihre Ressourcen und Daten zu identifizieren, was ein Sicherheitsrisiko darstellt. Mit AWS Config können Sie die Konfigurationen der unterstützten AWS-Ressourcen in Ihren AWS-Konten bewerten, prüfen und auswerten. AWS Config überwacht und zeichnet die AWS-Ressourcenkonfigurationen kontinuierlich auf und vergleicht die aufgezeichneten Konfigurationen automatisch mit den gewünschten Konfigurationen.
