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.
Vom Service verwalteter Standard: AWS Control Tower
Dieser Abschnitt enthält Informationen zum Service-Managed Standard: AWS Control Tower.
Was ist Service-Managed Standard:? AWS Control Tower
Dieser Standard richtet sich an Benutzer von AWS Security Hub und AWS Control Tower. Damit können Sie die proaktiven Kontrollen AWS Control Tower neben den detektiven Kontrollen von Security Hub im AWS Control Tower Service konfigurieren.
Proaktive Kontrollen tragen dazu bei, dass Sie die Vorschriften AWS-Konten einhalten, da sie Aktionen kennzeichnen, die zu Richtlinienverstößen oder Fehlkonfigurationen führen können. Detective Controls erkennt die Nichtkonformität von Ressourcen (z. B. Fehlkonfigurationen) in Ihrem. AWS-Konten Indem Sie proaktive und detektive Kontrollen für Ihre AWS Umgebung aktivieren, können Sie Ihre Sicherheitslage in verschiedenen Entwicklungsphasen verbessern.
Tipp
Von Services verwaltete Standards unterscheiden sich von den Standards, die AWS Security Hub verwaltet. Beispielsweise müssen Sie im Verwaltungsdienst einen vom Dienst verwalteten Standard erstellen und löschen. Weitere Informationen finden Sie unter Von Diensten verwaltete Standards in Security Hub.
In der Security Hub Hub-Konsole und API können Sie Service-Managed Standard: AWS Control Tower zusammen mit anderen Security Hub Hub-Standards anzeigen.
Den Standard erstellen
Dieser Standard ist nur verfügbar, wenn Sie den Standard in erstellen AWS Control Tower. AWS Control Tower erstellt den Standard, wenn Sie ein entsprechendes Steuerelement zum ersten Mal mithilfe einer der folgenden Methoden aktivieren:
-
AWS Control Tower Konsole
-
AWS Control Tower API(rufe die an
EnableControl
API) -
AWS CLI (führe den
enable-control
Befehl aus)
Security Hub-Steuerelemente werden in der AWS Control Tower Konsole als SH identifiziert.ControlID
(zum Beispiel SH. CodeBuild.1).
Wenn Sie den Standard erstellen und Security Hub noch nicht aktiviert haben, wird Security Hub AWS Control Tower auch für Sie aktiviert.
Wenn Sie ihn nicht eingerichtet haben AWS Control Tower, können Sie diesen Standard nicht in der Security Hub-Konsole, im Security Hub oder anzeigen oder darauf zugreifen AWS CLI. API Selbst wenn Sie ihn eingerichtet haben AWS Control Tower, können Sie diesen Standard in Security Hub nicht anzeigen oder darauf zugreifen, ohne den Standard zuerst AWS Control Tower mit einer der oben genannten Methoden zu erstellen.
Dieser Standard ist nur dort verfügbar, AWS-Regionen wo er verfügbar AWS Control Tower ist, einschließlich AWS GovCloud (US).
Steuerungen im Standard aktivieren und deaktivieren
Nachdem Sie den Standard in der AWS Control Tower Konsole erstellt haben, können Sie den Standard und die verfügbaren Steuerelemente in beiden Diensten anzeigen.
Nachdem Sie den Standard zum ersten Mal erstellt haben, enthält er keine Steuerelemente, die automatisch aktiviert werden. Wenn Security Hub neue Steuerelemente hinzufügt, werden diese außerdem nicht automatisch für Service-Managed Standard: AWS Control Tower aktiviert. Sie sollten die Kontrollen für den Standard AWS Control Tower mithilfe einer der folgenden Methoden aktivieren und deaktivieren:
-
AWS Control Tower Konsole
-
AWS Control Tower API(rufe das
EnableControl
und anDisableControl
APIs) -
AWS CLI (führe die
disable-control
Befehle enable-control
und aus)
Wenn Sie den Aktivierungsstatus eines Steuerelements in ändern AWS Control Tower, wird die Änderung auch in Security Hub widergespiegelt.
Die Deaktivierung eines Steuerelements in Security Hub, das aktiviert ist, AWS Control Tower führt jedoch zu Kontrollabweichungen. Der Kontrollstatus in AWS Control Tower wird als Drifted
angezeigt. Sie können diese Abweichung beheben, indem Sie in der AWS Control Tower Konsole die Option OU erneut registrieren auswählen oder die Steuerung AWS Control Tower mithilfe einer der oben genannten Methoden deaktivieren und erneut aktivieren.
Wenn Sie die Aktivierungs- und Deaktivierungsaktionen in abschließen, können Sie Kontrollabweichungen vermeiden. AWS Control Tower
Wenn Sie Kontrollen in aktivieren oder deaktivieren AWS Control Tower, gilt die Aktion für alle Konten und Regionen. Wenn Sie Steuerungen in Security Hub aktivieren und deaktivieren (für diesen Standard nicht empfohlen), gilt die Aktion nur für das aktuelle Konto und die Region.
Anmerkung
Die zentrale Konfiguration kann nicht zur Verwaltung von Service-Managed Standard: AWS Control Tower verwendet werden. Wenn Sie die zentrale Konfiguration verwenden, können Sie nur den AWS Control Tower Dienst verwenden, um die Steuerungen in diesem Standard für ein zentral verwaltetes Konto zu aktivieren und zu deaktivieren.
Aktivierungsstatus und Kontrollstatus anzeigen
Sie können den Aktivierungsstatus einer Kontrolle mit einer der folgenden Methoden anzeigen:
-
Security Hub-Konsole, Security Hub API oder AWS CLI
-
AWS Control Tower Konsole
-
AWS Control Tower APIum eine Liste der aktivierten Steuerelemente zu sehen (rufen Sie die auf
ListEnabledControls
API) -
AWS CLI um eine Liste der aktivierten Steuerelemente zu sehen (führen Sie den
list-enabled-controls
Befehl aus)
Ein Steuerelement, das Sie deaktivieren, AWS Control Tower hat den Aktivierungsstatus Disabled
in Security Hub, sofern Sie dieses Steuerelement nicht ausdrücklich in Security Hub aktivieren.
Security Hub berechnet den Kontrollstatus auf der Grundlage des Workflow-Status und des Compliance-Status der Kontrollergebnisse. Weitere Informationen zum Aktivierungsstatus und zum Kontrollstatus finden Sie unter. Details eines Steuerelements anzeigen
Auf der Grundlage des Kontrollstatus berechnet Security Hub eine Sicherheitsbewertung für Service-Managed Standard:. AWS Control Tower Diese Bewertung ist nur in Security Hub verfügbar. Darüber hinaus können Sie Kontrollergebnisse nur in Security Hub anzeigen. Die Standardsicherheitsbewertung und die Kontrollergebnisse sind in nicht verfügbar AWS Control Tower.
Anmerkung
Wenn Sie Kontrollen für Service-Managed Standard: aktivieren AWS Control Tower, kann es bis zu 18 Stunden dauern, bis Security Hub Ergebnisse für Kontrollen generiert, die eine bestehende AWS Config serviceverknüpfte Regel verwenden. Möglicherweise verfügen Sie bereits über serviceverknüpfte Regeln, wenn Sie andere Standards und Kontrollen in Security Hub aktiviert haben. Weitere Informationen finden Sie unter Zeitplan für die Ausführung von Sicherheitsprüfungen.
Den Standard löschen
Sie können diesen Standard löschen, AWS Control Tower indem Sie alle entsprechenden Steuerelemente mit einer der folgenden Methoden deaktivieren:
-
AWS Control Tower Konsole
-
AWS Control Tower API(rufe die an
DisableControl
API) -
AWS CLI (führe den
disable-control
Befehl aus)
Durch das Deaktivieren aller Steuerelemente wird der Standard in allen verwalteten Konten und verwalteten Regionen in gelöscht. AWS Control Tower Wenn Sie den Standard-in löschen, wird er von der Seite Standards der Security Hub-Konsole AWS Control Tower entfernt, und Sie können nicht mehr über den Security Hub API oder darauf zugreifen AWS CLI.
Anmerkung
Wenn Sie alle Steuerelemente aus dem Standard in Security Hub deaktivieren, wird der Standard nicht deaktiviert oder gelöscht.
Durch die Deaktivierung des Security Hub Hub-Dienstes werden Service-Managed Standard: AWS Control Tower und alle anderen Standards, die Sie aktiviert haben, entfernt.
Das Feldformat für Service-Managed Standard finden: AWS Control Tower
Wenn Sie Service-Managed Standard: erstellen AWS Control Tower und Kontrollen dafür aktivieren, erhalten Sie ab sofort Kontrollergebnisse in Security Hub. Security Hub meldet Kontrollergebnisse in derAWS Format für Sicherheitslücken (ASFF). Dies sind die ASFF Werte für den Amazon-Ressourcennamen (ARN) dieses Standards undGeneratorId
:
-
Standard ARN —
arn:aws:us-east-1
:securityhub:::standards/service-managed-aws-control-tower/v/1.0.0 -
GeneratorId –
service-managed-aws-control-tower/v/1.0.0/
CodeBuild.1
Ein Beispiel für einen Befund für Service-Managed Standard: finden Sie AWS Control Tower unterErgebnisse der Stichprobenkontrolle in Security Hub.
Kontrollen, die für Service-Managed Standard gelten: AWS Control Tower
Service-Managed Standard: AWS Control Tower unterstützt eine Teilmenge von Kontrollen, die Teil des AWS Foundational Security Best Practices () -Standards sind. FSBP Wählen Sie ein Steuerelement aus der folgenden Tabelle aus, um Informationen dazu anzuzeigen, einschließlich der Schritte zur Behebung fehlgeschlagener Ergebnisse.
Die folgende Liste zeigt die verfügbaren Steuerelemente für Service-Managed Standard:. AWS Control Tower Die regionalen Grenzwerte für Kontrollen entsprechen den regionalen Grenzwerten für die entsprechenden Kontrollen im Standard. FSBP Diese Liste zeigt standardunabhängige Sicherheitskontrollen. IDs In der AWS Control Tower Konsole IDs sind Steuerelemente als SH formatiert. ControlID
(zum Beispiel SH. CodeBuild.1). Wenn in Security Hub konsolidierte Kontrollergebnisse in Ihrem Konto deaktiviert sind, verwendet das ProductFields.ControlId
Feld die standardbasierte Kontroll-ID. Die standardbasierte Kontroll-ID ist als CT formatiert. ControlId
(zum Beispiel CT. CodeBuild.1).
-
[Konto.1] Sicherheitskontaktinformationen sollten bereitgestellt werden für AWS-Konto
-
[APIGateway.1] API Gateway REST und WebSocket API Ausführungsprotokollierung sollten aktiviert sein
-
[APIGateway.3] API REST API Gateway-Phasen sollten AWS X-Ray Ablaufverfolgung aktiviert
-
[APIGateway.4] API Das Gateway sollte mit einem WAF Web verknüpft sein ACL
-
[APIGateway.5] API REST API Gateway-Cache-Daten sollten im Ruhezustand verschlüsselt werden
-
[APIGateway.8] API Gateway-Routen sollten einen Autorisierungstyp angeben
-
[APIGateway.9] Die Zugriffsprotokollierung sollte für API Gateway V2-Stufen konfiguriert werden
-
[AppSync.5] AWS AppSync GraphQL APIs sollte nicht mit Schlüsseln authentifiziert werden API
-
[AutoScaling.9] Amazon EC2 Auto Scaling Scaling-Gruppen sollten EC2 Amazon-Startvorlagen verwenden
-
[CloudTrail.2] CloudTrail sollte die Verschlüsselung im Ruhezustand aktiviert haben
-
[CloudTrail.4] Die Überprüfung der CloudTrail Protokolldatei sollte aktiviert sein
-
[CloudTrail.5] CloudTrail Trails sollten in Amazon CloudWatch Logs integriert werden
-
[CodeBuild.3] CodeBuild S3-Protokolle sollten verschlüsselt sein
-
[DMS.1] Replikationsinstanzen des Database Migration Service sollten nicht öffentlich sein
-
[DocumentDB.1] Amazon DocumentDB-Cluster sollten im Ruhezustand verschlüsselt werden
-
[DocumentDB.3] Manuelle Cluster-Snapshots von Amazon DocumentDB sollten nicht öffentlich sein
-
[DynamoDB.1] DynamoDB-Tabellen sollten die Kapazität automatisch bei Bedarf skalieren
-
[DynamoDB.2] Bei DynamoDB-Tabellen sollte die Wiederherstellung aktiviert sein point-in-time
-
[DynamoDB.3] DynamoDB Accelerator (DAX) -Cluster sollten im Ruhezustand verschlüsselt werden
-
[EC2.1] EBS Amazon-Snapshots sollten nicht öffentlich wiederherstellbar sein
-
[EC2.3] Angehängte EBS Amazon-Volumes sollten im Ruhezustand verschlüsselt werden
-
[EC2.4] Gestoppte EC2 Instances sollten nach einem bestimmten Zeitraum entfernt werden
-
[EC2.6] Die VPC Flow-Protokollierung sollte in allen aktiviert sein VPCs
-
[EC2.7] Die EBS Standardverschlüsselung sollte aktiviert sein
-
[EC2.8] EC2 Instances sollten Instance Metadata Service Version 2 () IMDSv2 verwenden
-
[EC2.9] EC2 Amazon-Instances sollten keine öffentliche IPv4 Adresse haben
-
[EC2.15] EC2 Amazon-Subnetze sollten öffentliche IP-Adressen nicht automatisch zuweisen
-
[EC2.16] Ungenutzte Network Access Control Lists sollten entfernt werden
-
[EC2.17] EC2 Amazon-Instances sollten nicht mehrere verwenden ENIs
-
[EC2.20] Beide VPN Tunnel für einen AWS Die Site-to-Site-Verbindung sollte bestehen VPN
-
[EC2.21] Das Netzwerk ACLs sollte keinen Zugriff von 0.0.0.0/0 auf Port 22 oder Port 3389 zulassen
-
[EC2.22] Ungenutzte EC2 Amazon-Sicherheitsgruppen sollten entfernt werden
-
[EC2.25] EC2 Amazon-Startvorlagen sollten Netzwerkschnittstellen nicht öffentlich IPs zuweisen
-
[ECR.1] Bei ECR privaten Repositorien sollte das Scannen von Bildern konfiguriert sein
-
[ECR.2] Bei ECR privaten Repositorys sollte die Tag-Unveränderlichkeit konfiguriert sein
-
[ECR.3] Für ECR Repositorys sollte mindestens eine Lebenszyklus-Richtlinie konfiguriert sein
-
[ECS.2] ECS Diensten sollten nicht automatisch öffentliche IP-Adressen zugewiesen werden
-
[ECS.3] ECS Aufgabendefinitionen sollten den Prozess-Namespace des Hosts nicht gemeinsam nutzen
-
[ECS.4] ECS Container sollten ohne Zugriffsrechte ausgeführt werden
-
[ECS.8] Geheimnisse sollten nicht als Container-Umgebungsvariablen übergeben werden
-
[ECS.10] ECS Fargate-Dienste sollten auf der neuesten Version der Fargate-Plattform laufen
-
[EFS.2] EFS Amazon-Volumes sollten in Backup-Plänen enthalten sein
-
[EFS.3] EFS Access Points sollten ein Root-Verzeichnis erzwingen
-
[EFS.4] EFS Access Points sollten eine Benutzeridentität erzwingen
-
[EKS.1] EKS Cluster-Endpunkte sollten nicht öffentlich zugänglich sein
-
[EKS.2] EKS Cluster sollten auf einer unterstützten Kubernetes-Version laufen
-
[ElastiCache.3] Für ElastiCache Replikationsgruppen sollte der automatische Failover aktiviert sein
-
[ElastiCache.4] ElastiCache Replikationsgruppen sollten im Ruhezustand verschlüsselt werden
-
[ElastiCache.5] ElastiCache Replikationsgruppen sollten bei der Übertragung verschlüsselt werden
-
[ElasticBeanstalk.2] Von Elastic Beanstalk verwaltete Plattformupdates sollten aktiviert sein
-
[ELB.5] Die Protokollierung von Anwendungen und Classic Load Balancers sollte aktiviert sein
-
[ELB.6] Für Anwendungen, Gateways und Network Load Balancers sollte der Löschschutz aktiviert sein
-
[ELB.7] Bei Classic Load Balancers sollte der Verbindungsabbau aktiviert sein
-
[ELB.9] Bei Classic Load Balancers sollte der zonenübergreifende Load Balancing aktiviert sein
-
[ELB.10] Classic Load Balancer sollte sich über mehrere Availability Zones erstrecken
-
[EMR.1] Primäre EMR Amazon-Clusterknoten sollten keine öffentlichen IP-Adressen haben
-
[ES.1] Bei Elasticsearch-Domains sollte die Verschlüsselung im Ruhezustand aktiviert sein
-
[ES.2] Elasticsearch-Domains sollten nicht öffentlich zugänglich sein
-
[ES.3] Elasticsearch-Domains sollten Daten verschlüsseln, die zwischen Knoten gesendet werden
-
[ES.4] Die Elasticsearch-Domain-Fehlerprotokollierung in CloudWatch Logs sollte aktiviert sein
-
[ES.5] Für Elasticsearch-Domains sollte die Audit-Protokollierung aktiviert sein
-
[ES.6] Elasticsearch-Domains sollten mindestens drei Datenknoten haben
-
[IAM.1] IAM Richtlinien sollten keine vollen „*“ -Administratorrechte zulassen
-
[IAM.2] IAM Benutzern sollten keine IAM Richtlinien angehängt werden
-
[IAM.3] IAM Die Zugangsschlüssel der Benutzer sollten alle 90 Tage oder weniger gewechselt werden
-
[IAM.4] Der IAM Root-Benutzerzugriffsschlüssel sollte nicht existieren
-
[IAM.5] MFA sollte für alle IAM Benutzer aktiviert sein, die ein Konsolenpasswort haben
-
[IAM.6] Die Hardware MFA sollte für den Root-Benutzer aktiviert sein
-
[IAM.7] Die Passwortrichtlinien für IAM Benutzer sollten stark konfiguriert sein
-
[IAM.8] Unbenutzte IAM Benutzeranmeldedaten sollten entfernt werden
-
[Kinesis.1] Kinesis-Streams sollten im Ruhezustand verschlüsselt werden
-
[Lambda.1] Lambda-Funktionsrichtlinien sollten den öffentlichen Zugriff verbieten
-
[Lambda.2] Lambda-Funktionen sollten unterstützte Laufzeiten verwenden
-
[Lambda.5] VPC Lambda-Funktionen sollten in mehreren Availability Zones funktionieren
-
[MSK.1] MSK Cluster sollten bei der Übertragung zwischen Broker-Knoten verschlüsselt werden
-
[MQ.5] ActiveMQ-Broker sollten den Aktiv-/Standby-Bereitstellungsmodus verwenden
-
[MQ.6] RabbitMQ-Broker sollten den Cluster-Bereitstellungsmodus verwenden
-
[Neptune.1] Neptune-DB-Cluster sollten im Ruhezustand verschlüsselt werden
-
[Neptune.2] Neptune-DB-Cluster sollten Audit-Logs in Logs veröffentlichen CloudWatch
-
[Neptune.3] Neptune-DB-Cluster-Snapshots sollten nicht öffentlich sein
-
[Neptune.4] Bei Neptune-DB-Clustern sollte der Löschschutz aktiviert sein
-
[Neptune.5] Bei Neptune-DB-Clustern sollten automatische Backups aktiviert sein
-
[Neptune.6] Neptune-DB-Cluster-Snapshots sollten im Ruhezustand verschlüsselt werden
-
[Neptune.7] Bei Neptune-DB-Clustern sollte die Datenbankauthentifizierung aktiviert sein IAM
-
[Neptune.8] Neptune-DB-Cluster sollten so konfiguriert sein, dass sie Tags in Snapshots kopieren
-
[NetworkFirewall.6] Die Regelgruppe Stateless Network Firewall sollte nicht leer sein
-
Bei [Opensearch.1] OpenSearch -Domains sollte die Verschlüsselung im Ruhezustand aktiviert sein
-
[Opensearch.2] OpenSearch -Domains sollten nicht öffentlich zugänglich sein
-
[Opensearch.3] OpenSearch -Domains sollten Daten verschlüsseln, die zwischen Knoten gesendet werden
-
Für [Opensearch.5] OpenSearch -Domains sollte die Audit-Protokollierung aktiviert sein
-
[Opensearch.6] OpenSearch -Domains sollten mindestens drei Datenknoten haben
-
Für [Opensearch.7] OpenSearch -Domains sollte eine differenzierte Zugriffskontrolle aktiviert sein
-
[RDS.3] Für RDS DB-Instances sollte die Verschlüsselung im Ruhezustand aktiviert sein
-
[RDS.4] RDS Cluster-Snapshots und Datenbank-Snapshots sollten im Ruhezustand verschlüsselt werden
-
[RDS.5] RDS DB-Instances sollten mit mehreren Availability Zones konfiguriert werden
-
[RDS.6] Die erweiterte Überwachung sollte für RDS DB-Instances konfiguriert werden
-
[RDS.8] Für RDS DB-Instances sollte der Löschschutz aktiviert sein
-
[RDS.9] RDS DB-Instances sollten Protokolle in Logs veröffentlichen CloudWatch
-
[RDS.10] Die IAM Authentifizierung sollte für RDS Instances konfiguriert werden
-
[RDS.11] Für RDS Instances sollten automatische Backups aktiviert sein
-
[RDS.12] Die IAM Authentifizierung sollte für RDS Cluster konfiguriert werden
-
[RDS.13] RDS Automatische Upgrades für kleinere Versionen sollten aktiviert sein
-
[RDS.15] RDS DB-Cluster sollten für mehrere Availability Zones konfiguriert werden
-
[RDS.17] RDS DB-Instances sollten so konfiguriert sein, dass sie Tags in Snapshots kopieren
-
[RDS.18] RDS Instanzen sollten in einem bereitgestellt werden VPC
-
[RDS.23] RDS Instances sollten keinen Standard-Port für die Datenbank-Engine verwenden
-
[RDS.27] RDS DB-Cluster sollten im Ruhezustand verschlüsselt werden
-
[Redshift.1] Amazon Redshift Redshift-Cluster sollten den öffentlichen Zugriff verbieten
-
[Redshift.4] Bei Amazon Redshift Redshift-Clustern sollte die Auditprotokollierung aktiviert sein
-
[Redshift.6] Bei Amazon Redshift sollten automatische Upgrades auf Hauptversionen aktiviert sein
-
[Redshift.7] Redshift-Cluster sollten erweitertes Routing verwenden VPC
-
[Redshift.9] Redshift-Cluster sollten nicht den Standard-Datenbanknamen verwenden
-
[Redshift.10] Redshift-Cluster sollten im Ruhezustand verschlüsselt werden
-
[S3.2] S3-Allzweck-Buckets sollten den öffentlichen Lesezugriff blockieren
-
[S3.3] S3-Allzweck-Buckets sollten den öffentlichen Schreibzugriff blockieren
-
[S3.5] Für S3-Allzweck-Buckets sollten Nutzungsanfragen erforderlich sein SSL
-
[S3.6] Allgemeine S3-Bucket-Richtlinien sollten den Zugriff auf andere einschränken AWS-Konten
-
[S3.8] S3-Allzweck-Buckets sollten den öffentlichen Zugriff blockieren
-
[S3.9] Bei S3-Allzweck-Buckets sollte die Serverzugriffsprotokollierung aktiviert sein
-
[S3.13] S3-Allzweck-Buckets sollten Lifecycle-Konfigurationen haben
-
[S3.17] S3-Allzweck-Buckets sollten im Ruhezustand verschlüsselt werden mit AWS KMS keys
-
[SageMaker.1] SageMaker Amazon-Notebook-Instances sollten keinen direkten Internetzugang haben
-
[SageMaker.3] Benutzer sollten keinen Root-Zugriff auf SageMaker Notebook-Instances haben
-
[SecretsManager.3] Unbenutzte Secrets Manager Manager-Geheimnisse entfernen
-
[SQS.1] SQS Amazon-Warteschlangen sollten im Ruhezustand verschlüsselt sein
-
[SSM.1] EC2 Amazon-Instances sollten verwaltet werden von AWS Systems Manager
-
[WAF.2] AWS WAF Klassische Regionalregeln sollten mindestens eine Bedingung enthalten
-
[WAF.3] AWS WAF Klassische regionale Regelgruppen sollten mindestens eine Regel haben
-
[WAF.10] AWS WAF web ACLs sollte mindestens eine Regel oder Regelgruppe haben
Weitere Informationen zu diesem Standard finden Sie unter Security Hub-Steuerelemente im AWS Control Tower Benutzerhandbuch.