CRI-Profil v2.2 im Security Hub CSPM

Das CRI-Profil ist ein Cybersicherheits-Framework, das vom Cyber Risk Institute (CRI), einer gemeinnützigen Koalition von Finanzinstituten und Handelsverbänden, entwickelt wurde. Das Framework vereinheitlicht die Cybersicherheit und die regulatorischen Erwartungen an den Finanzdienstleistungssektor in einem gemeinsamen Anforderungskatalog. Auf diese Weise kann sich ein Unternehmen einmal selbst bewerten und dann anhand mehrerer Vorschriften Bericht erstatten. Weitere Informationen zum Framework und seinen Anforderungen finden Sie in der CRI-Profilübersicht auf der Website des Cyber Risk Institute.

AWS Security Hub CSPM bietet Sicherheitskontrollen, die einen Teil der Anforderungen von CRI Profile v2.2 unterstützen. Die Kontrollen führen automatisierte Sicherheitsprüfungen für bestimmte Ressourcen durch. AWS-Services Um diese Kontrollen zu aktivieren und zu verwalten, können Sie CRI Profile v2.2 standardmäßig in Security Hub CSPM aktivieren. Beachten Sie, dass die Steuerelemente die Anforderungen von CRI Profile v2.2 nicht unterstützen, die manuelle Prüfungen erfordern.

Die Aktivierung dieses Standards und das Bestehen der Prüfungen für seine Kontrollen allein stellen noch keine Bestätigung der Einhaltung von CRI Profile v2.2 dar. Die Einhaltung der Vorschriften hängt von organisatorischen und betrieblichen Praktiken ab, die Security Hub CSPM nicht bewerten kann.

Kontrollen, die für den Standard gelten

In der folgenden Liste wird angegeben, welche Security Hub CSPM-Steuerelemente für CRI Profile v2.2 gelten. Um die Details eines Steuerelements zu überprüfen, wählen Sie das Steuerelement aus.

• [Account.1] Sicherheitskontaktinformationen sollten für eine bereitgestellt werden AWS-Konto

• [Account.2] AWS-Konten sollte Teil eines sein AWS Organizations Organisation

• [ACM.1] Importiert und ACM-issued Zertifikate sollten nach einem bestimmten Zeitraum erneuert werden

• [ACM.2] Von ACM verwaltete RSA-Zertifikate sollten eine Schlüssellänge von mindestens 2.048 Bit verwenden

• [Amplify.2] Amplify-Zweige sollten markiert werden

• [APIGateway.1] API Gateway REST und WebSocket API-Ausführungsprotokollierung sollten aktiviert sein

• [APIGateway.2] API Gateway REST API-Stufen sollten so konfiguriert werden, dass sie SSL-Zertifikate für die Backend-Authentifizierung verwenden

• [APIGateway.3] API Gateway REST API-Stufen sollten haben AWS X-Ray Ablaufverfolgung aktiviert

• [APIGateway.4] API Gateway sollte mit einer WAF-Web-ACL verknüpft sein

• [APIGateway.5] API Gateway REST API-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 Stages konfiguriert werden

• [AppFlow.1] AppFlow Amazon-Flows sollten markiert werden

• [AppRunner.1] App Runner-Dienste sollten markiert sein

• [AppSync.2] AWS AppSync sollte die Protokollierung auf Feldebene aktiviert haben

• [AppSync.5] AWS AppSync GraphQL-APIs sollten nicht mit API-Schlüsseln authentifiziert werden

• [Athena.4] Bei Athena-Arbeitsgruppen sollte die Protokollierung aktiviert sein

• [AutoScaling.1] Auto Scaling Scaling-Gruppen, die einem Load Balancer zugeordnet sind, sollten ELB-Zustandsprüfungen verwenden

• [AutoScaling.2] Die Amazon EC2 Auto Scaling Scaling-Gruppe sollte mehrere Availability Zones abdecken

• [AutoScaling.3] Auto Scaling Scaling-Gruppenstartkonfigurationen sollten EC2-Instances so konfigurieren, dass sie Instance Metadata Service Version 2 (IMDSv2) benötigen

• [Autoscaling.5] Amazon EC2 EC2-Instances, die mit Auto Scaling Scaling-Gruppenstartkonfigurationen gestartet wurden, sollten keine öffentlichen IP-Adressen haben

• [AutoScaling.6] Auto Scaling Scaling-Gruppen sollten mehrere Instanztypen in mehreren Availability Zones verwenden

• [AutoScaling.9] Amazon EC2 Auto Scaling Scaling-Gruppen sollten Amazon EC2 EC2-Startvorlagen verwenden

• [Backup.1] AWS Backup Wiederherstellungspunkte sollten im Ruhezustand verschlüsselt werden

• [Batch.2] Richtlinien zur Batch-Planung sollten markiert werden

• [Batch.4] Eigenschaften von Rechenressourcen in verwalteten Batch-Computing-Umgebungen sollten mit Tags versehen werden

• Bei [CloudFront.1] CloudFront Distributionen sollte ein Standard-Root-Objekt konfiguriert sein

• [CloudFront.3] CloudFront Distributionen sollten während der Übertragung verschlüsselt werden müssen

• [CloudFront.4] Bei CloudFront Distributionen sollte das Origin-Failover konfiguriert sein

• [CloudFront.5] Bei CloudFront Distributionen sollte die Protokollierung aktiviert sein

• [CloudFront.6] Bei CloudFront Distributionen sollte WAF aktiviert sein

• [CloudFront.7] CloudFront Distributionen sollten benutzerdefinierte SSL/TLS Zertifikate verwenden

• [CloudFront.8] CloudFront Distributionen sollten SNI verwenden, um HTTPS-Anfragen zu bearbeiten

• [CloudFront.9] CloudFront Distributionen sollten den Datenverkehr zu benutzerdefinierten Ursprüngen verschlüsseln

• [CloudFront.10] CloudFront Distributionen sollten keine veralteten SSL-Protokolle zwischen Edge-Standorten und benutzerdefinierten Ursprüngen verwenden

• [CloudFront.12] CloudFront Distributionen sollten nicht auf nicht existierende S3-Ursprünge verweisen

• [CloudFront.13] CloudFront Distributionen sollten die Origin-Zugriffskontrolle verwenden

• [CloudFront.15] CloudFront Distributionen sollten die empfohlene TLS-Sicherheitsrichtlinie verwenden

• [CloudTrail.1] CloudTrail sollte aktiviert und mit mindestens einem regionsübergreifenden Trail konfiguriert sein, der Verwaltungsereignisse für Lese- und Schreibvorgänge umfasst

• [CloudTrail.2] CloudTrail sollte die Verschlüsselung im Ruhezustand aktiviert haben

• [CloudTrail.3] Mindestens ein CloudTrail Trail sollte aktiviert sein

• [CloudTrail.4] Die Überprüfung der CloudTrail Protokolldatei sollte aktiviert sein

• [CloudTrail.5] CloudTrail Trails sollten in Amazon CloudWatch Logs integriert werden

• [CloudTrail.6] Stellen Sie sicher, dass der zum Speichern von CloudTrail Protokollen verwendete S3-Bucket nicht öffentlich zugänglich ist

• [CloudTrail.7] Stellen Sie sicher, dass die Protokollierung des S3-Bucket-Zugriffs auf dem CloudTrail S3-Bucket aktiviert ist

• [CloudWatch.1] Es sollten ein Log-Metrikfilter und ein Alarm für die Verwendung durch den Benutzer „root“ vorhanden sein

• [CloudWatch.2] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für nicht autorisierte API-Aufrufe vorhanden sind

• [CloudWatch.3] Stellen Sie sicher, dass ein Protokollmetrikfilter und ein Alarm für die Anmeldung an der Management Console ohne MFA vorhanden sind

• [CloudWatch.4] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für IAM-Richtlinienänderungen vorhanden sind

• [CloudWatch.5] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für CloudTrail Konfigurationsänderungen vorhanden sind

• [CloudWatch.6] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm vorhanden sind für AWS-Managementkonsole Fehler bei der Authentifizierung

• [CloudWatch.7] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für die Deaktivierung oder das geplante Löschen von vom Kunden verwalteten Schlüsseln vorhanden sind

• [CloudWatch.8] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für Änderungen der S3-Bucket-Richtlinien vorhanden sind

• [CloudWatch.9] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm vorhanden sind für AWS Config Änderungen an der Konfiguration

• [CloudWatch.10] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für Änderungen an Sicherheitsgruppen vorhanden sind

• [CloudWatch.11] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für Änderungen an den Network Access Control Lists (NACL) vorhanden sind

• [CloudWatch.12] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für Änderungen an Netzwerk-Gateways vorhanden sind

• [CloudWatch.13] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für Änderungen an der Routentabelle vorhanden sind

• [CloudWatch.14] Stellen Sie sicher, dass ein Log-Metrikfilter und ein Alarm für VPC-Änderungen vorhanden sind

• Für [CloudWatch.15] CloudWatch Alarme sollten bestimmte Aktionen konfiguriert sein

• [CloudWatch.16] CloudWatch Protokollgruppen sollten für einen bestimmten Zeitraum aufbewahrt werden

• [CloudWatch.17] CloudWatch Alarmaktionen sollten aktiviert sein

• [CodeBuild.1] Die URLs des CodeBuild Bitbucket-Quell-Repositorys sollten keine vertraulichen Anmeldeinformationen enthalten

• [CodeBuild.2] CodeBuild Projektumgebungsvariablen sollten keine Klartext-Anmeldeinformationen enthalten

• [CodeBuild.3] CodeBuild S3-Protokolle sollten verschlüsselt sein

• [CodeBuild.4] CodeBuild Projektumgebungen sollten über eine Protokollierung verfügen AWS Config Dauer

• [CodeBuild.7] Exporte von CodeBuild Berichtsgruppen sollten im Ruhezustand verschlüsselt werden

• [CodeGuruProfiler.1] CodeGuru Profiler-Profiling-Gruppen sollten markiert werden

• [CodeGuruReviewer.1] CodeGuru Reviewer-Repository-Verknüpfungen sollten markiert werden

• [Cognito.2] Cognito-Identitätspools sollten keine nicht authentifizierten Identitäten zulassen

• [Cognito.3] Passwortrichtlinien für Cognito-Benutzerpools sollten starke Konfigurationen haben

• [Config.1] AWS Config sollte aktiviert sein und die dienstbezogene Rolle für die Ressourcenaufzeichnung verwenden

• [Connect.2] Bei Connect Customer-Instanzen sollte die CloudWatch Protokollierung aktiviert sein

• [DataFirehose.1] Firehose-Lieferstreams sollten im Ruhezustand verschlüsselt werden

• Bei [DataSync.1] DataSync Aufgaben sollte die Protokollierung aktiviert sein

• [DataSync.2] DataSync Aufgaben sollten mit Tags versehen werden

• [DMS.1] Replikationsinstanzen des Database Migration Service sollten nicht öffentlich sein

• [DMS.6] Für DMS-Replikationsinstanzen sollte das automatische Upgrade der Nebenversionen aktiviert sein

• [DMS.7] Bei DMS-Replikationsaufgaben für die Zieldatenbank sollte die Protokollierung aktiviert sein

• [DMS.8] Bei DMS-Replikationsaufgaben für die Quelldatenbank sollte die Protokollierung aktiviert sein

• [DMS.9] DMS-Endpunkte sollten SSL verwenden

• [DMS.10] DMS-Endpunkte für Neptune-Datenbanken sollten die IAM-Autorisierung aktiviert haben

• [DMS.11] DMS-Endpunkte für MongoDB sollten einen Authentifizierungsmechanismus aktiviert haben

• [DMS.12] Auf DMS-Endpunkten für Redis OSS sollte TLS aktiviert sein

• [DocumentDB.1] Amazon DocumentDB-Cluster sollten im Ruhezustand verschlüsselt werden

• [DocumentDB.2] Amazon DocumentDB-Cluster sollten über eine angemessene Aufbewahrungsfrist für Backups verfügen

• [DocumentDB.3] Manuelle Cluster-Snapshots von Amazon DocumentDB sollten nicht öffentlich sein

• [DocumentDB.4] Amazon DocumentDB-Cluster sollten Auditprotokolle in Logs veröffentlichen CloudWatch

• [DocumentDB.5] Bei Amazon DocumentDB-Clustern sollte der Löschschutz aktiviert sein

• [DocumentDB.6] Amazon DocumentDB-Cluster sollten bei der Übertragung verschlüsselt werden

• [DynamoDB.1] DynamoDB-Tabellen sollten die Kapazität automatisch bei Bedarf skalieren

• [DynamoDB.2] Bei DynamoDB-Tabellen sollte die Point-in-Time-Wiederherstellung aktiviert sein

• [DynamoDB.3] DynamoDB Accelerator (DAX) -Cluster sollten im Ruhezustand verschlüsselt werden

• [DynamoDB.4] DynamoDB-Tabellen sollten in einem Backup-Plan vorhanden sein

• [DynamoDB.6] Bei DynamoDB-Tabellen sollte der Löschschutz aktiviert sein

• [DynamoDB.7] DynamoDB Accelerator-Cluster sollten bei der Übertragung verschlüsselt werden

• [EC2.1] Amazon EBS-Snapshots sollten nicht so konfiguriert werden, dass sie öffentlich wiederherstellbar sind

• [EC2.2] VPC-Standardsicherheitsgruppen sollten keinen eingehenden oder ausgehenden Datenverkehr zulassen

• [EC2.3] Angehängte Amazon EBS-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 VPCs aktiviert sein

• [EC2.7] Die EBS-Standardverschlüsselung sollte aktiviert sein

• [EC2.8] EC2-Instances sollten Instance Metadata Service Version 2 (IMDSv2) verwenden

• [EC2.9] Amazon EC2 EC2-Instances sollten keine öffentliche IPv4-Adresse haben

• [EC2.10] Amazon EC2 sollte für die Verwendung von VPC-Endpunkten konfiguriert werden, die für den Amazon EC2-Service erstellt wurden

• [EC2.12] Ungenutzte Amazon EC2 EC2-EIPs sollten entfernt werden

• [EC2.13] Sicherheitsgruppen sollten ab Version 0.0.0 keinen Zugriff mehr zulassen. 0/0 oder: :/0 zu Port 22

• [EC2.14] Sicherheitsgruppen sollten ab Version 0.0.0 keinen Zugriff zulassen. 0/0 oder: :/0 zu Port 3389

• [EC2.15] Amazon EC2-Subnetze sollten öffentliche IP-Adressen nicht automatisch zuweisen

• [EC2.16] Unbenutzte Network Access Control Lists sollten entfernt werden

• [EC2.17] Amazon EC2 EC2-Instances sollten nicht mehrere ENIs verwenden

• [EC2.18] Sicherheitsgruppen sollten nur uneingeschränkten eingehenden Datenverkehr für autorisierte Ports zulassen

• [EC2.19] Sicherheitsgruppen sollten keinen uneingeschränkten Zugriff auf Ports mit hohem Risiko zulassen

• [EC2.20] Beide VPN-Tunnel für ein AWS Site-to-Site Die VPN-Verbindung sollte bestehen

• [EC2.21] Netzwerk-ACLs sollten ab Version 0.0.0 keinen Zugriff mehr zulassen. 0/0 zu Port 22 oder Port 3389

• [EC2.22] Unbenutzte Amazon EC2-Sicherheitsgruppen sollten entfernt werden

• [EC2.23] Amazon EC2 Transit Gateways sollten VPC-Anhangsanforderungen nicht automatisch akzeptieren

• [EC2.24] Paravirtuelle Amazon EC2 EC2-Instance-Typen sollten nicht verwendet werden

• [EC2.25] Amazon EC2 EC2-Startvorlagen sollten Netzwerkschnittstellen keine öffentlichen IPs zuweisen

• [EC2.28] EBS-Volumes sollten durch einen Backup-Plan abgedeckt werden

• [EC2.51] Bei EC2-Client-VPN-Endpunkten sollte die Client-Verbindungsprotokollierung aktiviert sein

• [EC2.53] EC2-Sicherheitsgruppen sollten keinen Zugriff ab Version 0.0.0 zulassen. 0/0 zu den Verwaltungsports des Remoteservers

• [EC2.54] EC2-Sicherheitsgruppen sollten keinen Zugriff von: :/0 zu Remote-Serveradministrationsports zulassen

• [EC2.170] EC2-Startvorlagen sollten Instance Metadata Service Version 2 (IMDSv2) verwenden

• [EC2.171] Bei EC2-VPN-Verbindungen sollte die Protokollierung aktiviert sein

• [EC2.173] EC2 Spot Fleet-Anfragen mit Startparametern sollten die Verschlüsselung für angehängte EBS-Volumes ermöglichen

• [EC2.174] EC2-DHCP-Optionssätze sollten markiert werden

• [EC2.176] EC2-Präfixlisten sollten mit Tags versehen werden

• [EC2.177] EC2-Traffic-Mirror-Sitzungen sollten mit Tags versehen werden

• [EC2.178] EC2-Traffic-Spiegelfilter sollten mit Tags versehen werden

• [EC2.180] Bei EC2-Netzwerkschnittstellen sollte die Überprüfung aktiviert sein source/destination

• [EC2.181] EC2-Startvorlagen sollten die Verschlüsselung für angehängte EBS-Volumes ermöglichen

• [ECR.1] Bei privaten ECR-Repositorys sollte das Scannen von Bildern konfiguriert sein

• [ECR.2] Für private ECR-Repositorys sollte die Tag-Unveränderlichkeit konfiguriert sein

• [ECR.3] Für ECR-Repositorys sollte mindestens eine Lebenszyklusrichtlinie 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.5] ECS-Aufgabendefinitionen sollten Container so konfigurieren, dass sie auf den schreibgeschützten Zugriff auf Root-Dateisysteme beschränkt sind

• [ECS.8] Geheimnisse sollten nicht als Container-Umgebungsvariablen übergeben werden

• [ECS.9] ECS-Aufgabendefinitionen sollten über eine Protokollierungskonfiguration verfügen

• [ECS.10] ECS Fargate-Dienste sollten auf der neuesten Fargate-Plattformversion laufen

• [ECS.12] ECS-Cluster sollten Container Insights verwenden

• [ECS.16] ECS-Aufgabensätze sollten öffentliche IP-Adressen nicht automatisch zuweisen

• [ECS.17] ECS-Aufgabendefinitionen sollten nicht den Host-Netzwerkmodus verwenden

• [EFS.1] Elastic File System sollte so konfiguriert sein, dass es Dateidaten im Ruhezustand verschlüsselt AWS KMS

• [EFS.2] Amazon EFS-Volumes sollten in Backup-Plänen enthalten sein

• [EFS.3] EFS-Zugriffspunkte sollten ein Stammverzeichnis erzwingen

• [EFS.4] EFS-Zugriffspunkte sollten eine Benutzeridentität erzwingen

• [EFS.6] EFS-Mount-Ziele sollten nicht mit Subnetzen verknüpft werden, die beim Start öffentliche IP-Adressen zuweisen

• [EFS.7] Bei EFS-Dateisystemen sollten automatische Backups aktiviert sein

• [EFS.8] EFS-Dateisysteme sollten im Ruhezustand verschlüsselt werden

• [EKS.1] EKS-Cluster-Endpunkte sollten nicht öffentlich zugänglich sein

• [EKS.2] EKS-Cluster sollten auf einer unterstützten Kubernetes-Version ausgeführt werden

• [EKS.8] Bei EKS-Clustern sollte die Audit-Protokollierung aktiviert sein

• Bei [ElastiCache.1] ElastiCache (Redis OSS) -Clustern sollten automatische Backups aktiviert sein

• [ElastiCache.2] Bei ElastiCache Clustern sollten automatische Upgrades für kleinere Versionen aktiviert sein

• [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

• [ElastiCache.6] ElastiCache (Redis OSS) -Replikationsgruppen früherer Versionen sollten Redis OSS AUTH aktiviert haben

• [ElastiCache.7] ElastiCache Cluster sollten nicht die Standard-Subnetzgruppe verwenden

• [ElasticBeanstalk.1] Elastic Beanstalk Beanstalk-Umgebungen sollten erweiterte Gesundheitsberichte aktiviert haben

• [ElasticBeanstalk.2] Von Elastic Beanstalk verwaltete Plattformupdates sollten aktiviert sein

• [ElasticBeanstalk.3] Elastic Beanstalk sollte Logs streamen nach CloudWatch

• [ELB.1] Application Load Balancer sollte so konfiguriert sein, dass alle HTTP-Anfragen an HTTPS umgeleitet werden

• [ELB.2] Classic Load Balancer mit SSL/HTTPS Listenern sollten ein Zertifikat verwenden, das bereitgestellt wird von AWS Certificate Manager

• [ELB.3] Classic Load Balancer Balancer-Listener sollten mit HTTPS- oder TLS-Terminierung konfiguriert werden

• [ELB.4] Application Load Balancer sollte so konfiguriert sein, dass ungültige HTTP-Header gelöscht werden

• [ELB.5] Die Protokollierung von Anwendungen und Classic Load Balancers sollte aktiviert sein

• [ELB.6] Bei Anwendung, Gateway und Network Load Balancers sollte der Löschschutz aktiviert sein

• [ELB.7] Bei Classic Load Balancers sollte der Verbindungsverlust aktiviert sein

• [ELB.8] Classic Load Balancer mit SSL-Listenern sollten eine vordefinierte Sicherheitsrichtlinie mit starken AWS Config Dauer

• [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

• [ELB.12] Der Application Load Balancer sollte mit einem defensiven oder strengsten Desync-Minimationsmodus konfiguriert werden

• [ELB.13] Load Balancer für Anwendungen, Netzwerke und Gateways sollten sich über mehrere Availability Zones erstrecken

• [ELB.14] Classic Load Balancer sollte mit einem defensiven oder strengsten Desync-Minimationsmodus konfiguriert werden

• [ELB.16] Application Load Balancers sollten mit einem verknüpft sein AWS WAF Web-ACL

• [ELB.17] Anwendungs- und Netzwerk-Load-Balancer mit Listenern sollten die empfohlenen Sicherheitsrichtlinien verwenden

• [ELB.18] Anwendungs- und Network Load Balancer Balancer-Listener sollten sichere Protokolle verwenden, um Daten während der Übertragung zu verschlüsseln

• [ELB.21] Anwendungs- und Network Load Balancer Balancer-Zielgruppen sollten verschlüsselte Health Check-Protokolle verwenden

• [ELB.22] ELB-Zielgruppen sollten verschlüsselte Transportprotokolle verwenden

• [EMR.1] Primäre Amazon EMR-Clusterknoten sollten keine öffentlichen IP-Adressen haben

• [EMR.2] Die Einstellung Amazon EMR Block Public Access sollte aktiviert sein

• [EMR.3] Amazon EMR-Sicherheitskonfigurationen sollten im Ruhezustand verschlüsselt werden

• [EMR.4] Amazon EMR-Sicherheitskonfigurationen sollten bei der Übertragung verschlüsselt werden

• [ES.1] Für 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 Logs sollte aktiviert sein CloudWatch

• [ES.5] Für Elasticsearch-Domains sollte die Audit-Protokollierung aktiviert sein

• [ES.6] Elasticsearch-Domains sollten mindestens drei Datenknoten haben

• [ES.7] Elasticsearch-Domains sollten mit mindestens drei dedizierten Master-Knoten konfiguriert werden

• [ES.8] Verbindungen zu Elasticsearch-Domains sollten mit der neuesten TLS-Sicherheitsrichtlinie verschlüsselt werden

• [EventBridge.3] An EventBridge benutzerdefinierte Eventbusse sollte eine ressourcenbasierte Richtlinie angehängt werden

• [EventBridge.4] Auf EventBridge globalen Endpunkten sollte die Ereignisreplikation aktiviert sein

• [FSx.1] FSx für OpenZFS-Dateisysteme sollte so konfiguriert sein, dass Tags auf Backups und Volumes kopiert werden

• [FSx.2] FSx for Lustre-Dateisysteme sollten so konfiguriert sein, dass Tags in Backups kopiert werden

• [FSx.3] FSx für OpenZFS-Dateisysteme sollte für die Bereitstellung konfiguriert sein Multi-AZ

• [FSx.5] FSx for Windows File Server Server-Dateisysteme sollten für Multi-AZ die Bereitstellung konfiguriert sein

• [Glue.3] AWS Glue Transformationen für maschinelles Lernen sollten im Ruhezustand verschlüsselt werden

• [Glue.4] AWS Glue Spark-Jobs sollten auf unterstützten Versionen von ausgeführt werden AWS Glue

• [GuardDuty.1] GuardDuty sollte aktiviert sein

• [GuardDuty.5] GuardDuty EKS Audit Log Monitoring sollte aktiviert sein

• [GuardDuty.6] GuardDuty Lambda Protection sollte aktiviert sein

• [GuardDuty.7] GuardDuty EKS Runtime Monitoring sollte aktiviert sein

• [GuardDuty.8] Der GuardDuty Malware-Schutz für EC2 sollte aktiviert sein

• [GuardDuty.9] GuardDuty RDS-Schutz sollte aktiviert sein

• [GuardDuty.10] GuardDuty S3-Schutz sollte aktiviert sein

• [GuardDuty.11] GuardDuty Runtime Monitoring sollte aktiviert sein

• [GuardDuty.12] GuardDuty ECS Runtime Monitoring sollte aktiviert sein

• [GuardDuty.13] GuardDuty EC2 Runtime Monitoring sollte aktiviert sein

• [IAM.1] IAM-Richtlinien sollten keine vollen „*“ -Administratorrechte zulassen

• [IAM.2] IAM-Benutzern sollten keine IAM-Richtlinien zugeordnet sein

• [IAM.3] Die Zugriffsschlüssel von IAM-Benutzern 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] Hardware-MFA sollte für den Root-Benutzer aktiviert sein

• [IAM.7] Passwortrichtlinien für IAM-Benutzer sollten starke Konfigurationen haben

• [IAM.8] Unbenutzte IAM-Benutzeranmeldedaten sollten entfernt werden

• [IAM.9] MFA sollte für den Root-Benutzer aktiviert sein

• [IAM.10] Die Kennwortrichtlinien für IAM-Benutzer sollten stark konfiguriert sein

• [IAM.11] Stellen Sie sicher, dass die IAM-Passwortrichtlinie mindestens einen Großbuchstaben erfordert

• [IAM.12] Stellen Sie sicher, dass die IAM-Passwortrichtlinie mindestens einen Kleinbuchstaben erfordert

• [IAM.13] Stellen Sie sicher, dass die IAM-Passwortrichtlinie mindestens ein Symbol erfordert

• [IAM.14] Stellen Sie sicher, dass die IAM-Passwortrichtlinie mindestens eine Zahl erfordert

• [IAM.15] Stellen Sie sicher, dass die IAM-Passwortrichtlinie eine Mindestkennwortlänge von 14 oder mehr erfordert

• [IAM.16] Stellen Sie sicher, dass die IAM-Kennwortrichtlinie die Wiederverwendung von Passwörtern

• [IAM.17] Stellen Sie sicher, dass die IAM-Passwortrichtlinie Passwörter innerhalb von 90 Tagen oder weniger abläuft

• [IAM.18] Stellen Sie sicher, dass eine Support-Rolle für die Verwaltung von Vorfällen eingerichtet wurde AWS Support

• [IAM.19] MFA sollte für alle IAM-Benutzer aktiviert sein

• [IAM.21] Kundenverwaltete IAM-Richtlinien, die Sie erstellen, sollten keine Platzhalteraktionen für Dienste zulassen

• [IAM.22] IAM-Benutzeranmeldedaten, die 45 Tage lang nicht verwendet wurden, sollten entfernt werden

• [IAM.26] Abgelaufene SSL/TLS Zertifikate, die in IAM verwaltet werden, sollten entfernt werden

• [IAM.27] IAM-Identitäten sollte die Richtlinie nicht angehängt sein AWSCloudShellFullAccess

• [IAM.28] Der externe Zugriffsanalysator von IAM Access Analyzer sollte aktiviert sein

• [Inspector.1] Amazon Inspector EC2-Scannen sollte aktiviert sein

• [Inspector.2] Amazon Inspector ECR-Scannen sollte aktiviert sein

• [Inspector.3] Das Scannen von Amazon Inspector Lambda-Code sollte aktiviert sein

• [Inspector.4] Das Standardscannen von Amazon Inspector Lambda sollte aktiviert sein

• [IoTTwinMaker.2] AWS TwinMaker IoT-Arbeitsbereiche sollten markiert werden

• [IVS.1] Schlüsselpaare für die IVS-Wiedergabe sollten markiert werden

• [IVS.2] IVS-Aufnahmekonfigurationen sollten mit Tags versehen werden

• [Keyspaces.1] Amazon Keyspaces-Keyspaces sollten markiert werden

• [Kinesis.1] Kinesis-Streams sollten im Ruhezustand verschlüsselt werden

• [KMS.1] Kundenverwaltete IAM-Richtlinien sollten keine Entschlüsselungsaktionen für alle KMS-Schlüssel zulassen

• [KMS.2] IAM-Prinzipale sollten keine IAM-Inline-Richtlinien haben, die Entschlüsselungsaktionen für alle KMS-Schlüssel zulassen

• [KMS.3] AWS KMS keys sollte nicht unbeabsichtigt gelöscht werden

• [KMS.4] AWS KMS Die Schlüsselrotation sollte aktiviert sein

• [KMS.5] KMS-Schlüssel sollten nicht öffentlich zugänglich sein

• [Lambda.1] Lambda-Funktionsrichtlinien sollten den öffentlichen Zugriff verbieten

• [Lambda.2] Lambda-Funktionen sollten unterstützte Laufzeiten verwenden

• [Lambda.3] Lambda-Funktionen sollten sich in einer VPC befinden

• [Lambda.5] VPC-Lambda-Funktionen sollten in mehreren Availability Zones funktionieren

• [Lambda.7] Lambda-Funktionen sollten haben AWS X-Ray aktives Tracing aktiviert

• [Macie.1] Amazon Macie sollte aktiviert sein

• [Macie.2] Die automatische Erkennung sensibler Daten durch Macie sollte aktiviert sein

• [MQ.2] ActiveMQ-Broker sollten Audit-Logs streamen an CloudWatch

• [MQ.5] ActiveMQ-Broker sollten den Bereitstellungsmodus verwenden active/standby

• [MQ.6] RabbitMQ-Broker sollten den Cluster-Bereitstellungsmodus verwenden

• [MSK.1] MSK-Cluster sollten bei der Übertragung zwischen Broker-Knoten verschlüsselt werden

• [MSK.2] Für MSK-Cluster sollte die erweiterte Überwachung konfiguriert sein

• [MSK.3] MSK Connect-Anschlüsse sollten bei der Übertragung verschlüsselt werden

• [MSK.4] Bei MSK-Clustern sollte der öffentliche Zugriff deaktiviert sein

• [MSK.5] Für MSK-Konnektoren sollte die Protokollierung aktiviert sein

• [MSK.6] MSK-Cluster sollten den nicht authentifizierten Zugriff deaktivieren

• [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] Neptune-DB-Cluster sollten die IAM-Datenbankauthentifizierung aktiviert haben

• [Neptune.8] Neptune-DB-Cluster sollten so konfiguriert sein, dass sie Tags in Snapshots kopieren

• [Neptune.9] Neptune-DB-Cluster sollten in mehreren Availability Zones bereitgestellt werden

• [NetworkFirewall.1] Netzwerk-Firewall-Firewalls sollten in mehreren Availability Zones eingesetzt werden

• [NetworkFirewall.2] Die Netzwerk-Firewall-Protokollierung sollte aktiviert sein

• [NetworkFirewall.3] Netzwerk-Firewall-Richtlinien sollten mindestens eine Regelgruppe zugeordnet sein

• [NetworkFirewall.4] Die standardmäßige statuslose Aktion für Netzwerk-Firewall-Richtlinien sollte für vollständige Pakete Drop oder Forward sein

• [NetworkFirewall.5] Die standardmäßige statuslose Aktion für Netzwerk-Firewall-Richtlinien sollte für fragmentierte Pakete Drop oder Forward sein

• [NetworkFirewall.6] Die Regelgruppe Stateless Network Firewall sollte nicht leer sein

• [NetworkFirewall.9] Bei Netzwerk-Firewall-Firewalls sollte der Löschschutz aktiviert sein

• [NetworkFirewall.10] Bei Netzwerk-Firewall-Firewalls sollte der Subnetzänderungsschutz aktiviert sein

• Bei [Opensearch.1] OpenSearch Domänen 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

• [Opensearch.4] OpenSearch Die Protokollierung von Domain-Fehlern in Logs sollte aktiviert sein CloudWatch

• [Opensearch.5] Für OpenSearch Domains sollte die Audit-Protokollierung aktiviert sein

• [Opensearch.6] OpenSearch Domains sollten mindestens drei Datenknoten haben

• Bei [Opensearch.7] OpenSearch Domänen sollte eine differenzierte Zugriffskontrolle aktiviert sein

• [Opensearch.8] Verbindungen zu OpenSearch Domains sollten mit der neuesten TLS-Sicherheitsrichtlinie verschlüsselt werden

• Auf [Opensearch.10] OpenSearch Domains sollte das neueste Softwareupdate installiert sein

• [Opensearch.11] OpenSearch Domains sollten mindestens drei dedizierte Primärknoten haben

• [PCA.1] AWS Private CA Die Stammzertifizierungsstelle sollte deaktiviert sein

• [RDS.1] Der RDS-Snapshot sollte privat sein

• [RDS.2] RDS-DB-Instances sollten, wie in der Konfiguration festgelegt, den PubliclyAccessible öffentlichen Zugriff verbieten

• [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.7] Bei RDS-Clustern sollte der Löschschutz aktiviert sein

• [RDS.8] Für RDS-DB-Instances sollte der Löschschutz aktiviert sein

• [RDS.9] RDS-DB-Instances sollten CloudWatch Protokolle in Logs veröffentlichen

• [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] Automatische RDS-Upgrades für Nebenversionen sollten aktiviert sein

• [RDS.14] Bei Amazon Aurora Aurora-Clustern sollte Backtracking aktiviert sein

• [RDS.15] RDS-DB-Cluster sollten für mehrere Availability Zones konfiguriert werden

• [RDS.16] Aurora-DB-Cluster sollten so konfiguriert sein, dass sie Tags in DB-Snapshots kopieren

• [RDS.17] RDS-DB-Instances sollten so konfiguriert sein, dass sie Tags in Snapshots kopieren

• [RDS.19] Bestehende Abonnements für RDS-Ereignisbenachrichtigungen sollten für kritische Clusterereignisse konfiguriert werden

• [RDS.20] Bestehende Abonnements für RDS-Ereignisbenachrichtigungen sollten für kritische Ereignisse der Datenbankinstanz konfiguriert werden

• [RDS.21] Ein Abonnement für RDS-Ereignisbenachrichtigungen sollte für kritische Datenbankparametergruppenereignisse konfiguriert werden

• [RDS.22] Ein Abonnement für RDS-Ereignisbenachrichtigungen sollte für kritische Datenbanksicherheitsgruppenereignisse konfiguriert werden

• [RDS.23] RDS-Instances sollten keinen Standard-Port für die Datenbank-Engine verwenden

• [RDS.24] RDS-Datenbankcluster sollten einen benutzerdefinierten Administratorbenutzernamen verwenden

• [RDS.25] RDS-Datenbank-Instances sollten einen benutzerdefinierten Administrator-Benutzernamen verwenden

• [RDS.26] RDS-DB-Instances sollten durch einen Backup-Plan geschützt werden

• [RDS.27] RDS-DB-Cluster sollten im Ruhezustand verschlüsselt werden

• [RDS.34] Aurora MySQL-DB-Cluster sollten Audit-Logs in CloudWatch Logs veröffentlichen

• [RDS.35] Für RDS-DB-Cluster sollte das automatische Upgrade der Nebenversion aktiviert sein

• [RDS.36] RDS für PostgreSQL-DB-Instances sollten Protokolle in Logs veröffentlichen CloudWatch

• [RDS.37] Aurora PostgreSQL-DB-Cluster sollten Protokolle in Logs veröffentlichen CloudWatch

• [RDS.38] RDS für PostgreSQL-DB-Instances sollte bei der Übertragung verschlüsselt werden

• [RDS.39] RDS für MySQL-DB-Instances sollte bei der Übertragung verschlüsselt werden

• [RDS.41] RDS für SQL Server-DB-Instances sollten bei der Übertragung verschlüsselt werden

• [RDS.44] RDS für MariaDB-DB-Instances sollte bei der Übertragung verschlüsselt werden

• [RDS.45] Bei Aurora MySQL-DB-Clustern sollte die Auditprotokollierung aktiviert sein

• [Redshift.1] Amazon Redshift Redshift-Cluster sollten den öffentlichen Zugriff verbieten

• [Redshift.2] Verbindungen zu Amazon Redshift Redshift-Clustern sollten bei der Übertragung verschlüsselt werden

• [Redshift.3] Bei Amazon Redshift Redshift-Clustern sollten automatische Snapshots aktiviert sein

• [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 VPC-Routing verwenden

• [Redshift.8] Amazon Redshift Redshift-Cluster sollten nicht den Standard-Admin-Benutzernamen verwenden

• [Redshift.10] Redshift-Cluster sollten im Ruhezustand verschlüsselt werden

• [Redshift.15] Redshift-Sicherheitsgruppen sollten den Zugriff auf den Cluster-Port nur von eingeschränkten Quellen zulassen

• [Redshift.16] Redshift-Cluster-Subnetzgruppen sollten Subnetze aus mehreren Availability Zones haben

• [Redshift.18] Für Redshift-Cluster sollten Multi-AZ Bereitstellungen aktiviert sein

• [RedshiftServerless.1] Serverlose Amazon Redshift Redshift-Arbeitsgruppen sollten erweitertes VPC-Routing verwenden

• [RedshiftServerless.2] Für die Verwendung von SSL sollten Verbindungen zu Redshift Serverless-Arbeitsgruppen erforderlich sein

• [RedshiftServerless.3] Redshift Serverless-Arbeitsgruppen sollten den öffentlichen Zugriff verbieten

• [RedshiftServerless.6] Redshift Serverless Namespaces sollten Protokolle in Logs exportieren CloudWatch

• [Route53.2] In öffentlich gehosteten Zonen von Route 53 sollten DNS-Abfragen protokolliert werden

• [S3.1] Für S3-Allzweck-Buckets sollten die Einstellungen zum Blockieren des öffentlichen Zugriffs aktiviert sein

• [S3.2] S3-Buckets für allgemeine Zwecke sollten den öffentlichen Lesezugriff blockieren

• [S3.3] S3-Allzweck-Buckets sollten den öffentlichen Schreibzugriff blockieren

• [S3.5] Für S3-Allzweck-Buckets sollten Anfragen zur Verwendung von TLS erforderlich sein

• [S3.6] Allgemeine S3-Bucket-Richtlinien sollten den Zugriff auf andere einschränken AWS-Konten

• [S3.7] S3-Allzweck-Buckets sollten die regionsübergreifende Replikation verwenden

• [S3.8] S3-Allzweck-Buckets sollten den öffentlichen Zugriff blockieren

• [S3.9] Für S3-Allzweck-Buckets sollte die Serverzugriffsprotokollierung aktiviert sein

• [S3.10] S3-Allzweck-Buckets mit aktivierter Versionierung sollten Lifecycle-Konfigurationen haben

• [S3.11] Für S3-Allzweck-Buckets sollten Ereignisbenachrichtigungen aktiviert sein

• [S3.12] ACLs sollten nicht verwendet werden, um den Benutzerzugriff auf S3-Allzweck-Buckets zu verwalten

• [S3.13] S3-Allzweck-Buckets sollten Lifecycle-Konfigurationen haben

• [S3.14] Für S3-Allzweck-Buckets sollte die Versionierung aktiviert sein

• [S3.15] Für S3-Allzweck-Buckets sollte Object Lock aktiviert sein

• [S3.17] S3-Allzweck-Buckets sollten im Ruhezustand verschlüsselt werden mit AWS KMS keys

• [S3.19] Bei S3-Zugriffspunkten sollten die Einstellungen zum Blockieren des öffentlichen Zugriffs aktiviert sein

• [S3.20] Für S3-Allzweck-Buckets sollte MFA Delete aktiviert sein

• [S3.22] S3-Buckets für allgemeine Zwecke sollten Schreibereignisse auf Objektebene protokollieren

• [S3.23] S3-Allzweck-Buckets sollten Leseereignisse auf Objektebene protokollieren

• [S3.24] Bei Multi-Region S3-Zugangspunkten sollten die Einstellungen zum Blockieren des öffentlichen Zugriffs aktiviert sein

• [SageMaker.1] SageMaker Amazon-Notebook-Instances sollten keinen direkten Internetzugang haben

• [SageMaker.2] SageMaker Notebook-Instances sollten in einer benutzerdefinierten VPC gestartet werden

• [SageMaker.3] Benutzer sollten keinen Root-Zugriff auf SageMaker Notebook-Instances haben

• [SageMaker.4] Bei Produktionsvarianten für SageMaker Endgeräte sollte die anfängliche Anzahl der Instances größer als 1 sein

• [SageMaker.5] SageMaker Bei Modellen sollte die Netzwerkisolierung aktiviert sein

• [SageMaker.8] SageMaker Notebook-Instances sollten auf unterstützten Plattformen laufen

• [SecretsManager.1] Bei Secrets Manager Manager-Geheimnissen sollte die automatische Rotation aktiviert sein

• [SecretsManager.2] Secrets Manager Manager-Geheimnisse, die mit automatischer Rotation konfiguriert sind, sollten erfolgreich rotieren

• [SecretsManager.3] Unbenutzte Secrets Manager Manager-Geheimnisse entfernen

• [SecretsManager.4] Secrets Manager Manager-Geheimnisse sollten innerhalb einer bestimmten Anzahl von Tagen rotiert werden

• [ServiceCatalog.1] Servicekatalog-Portfolios sollten innerhalb eines gemeinsam genutzt werden AWS nur Organisation

• [SNS.1] SNS-Themen sollten im Ruhezustand verschlüsselt werden mit AWS KMS

• [SNS.4] Richtlinien für den Zugriff auf SNS-Themen sollten keinen öffentlichen Zugriff zulassen

• [SQS.1] Amazon SQS SQS-Warteschlangen sollten im Ruhezustand verschlüsselt sein

• [SQS.3] Die Richtlinien für den Zugriff auf SQS-Warteschlangen sollten keinen öffentlichen Zugriff zulassen

• [SSM.1] Amazon EC2 EC2-Instances sollten verwaltet werden von AWS Systems Manager

• [SSM.2] Von Systems Manager verwaltete Amazon EC2 EC2-Instances sollten nach einer Patch-Installation den Patch-Compliance-Status COMPLIANT haben

• [SSM.3] Von Systems Manager verwaltete Amazon EC2 EC2-Instances sollten den Zuordnungs-Compliance-Status COMPLIANT haben

• [SSM.4] SSM-Dokumente sollten nicht öffentlich sein

• [SSM.6] Bei SSM Automation sollte die Protokollierung aktiviert sein CloudWatch

• [SSM.7] Bei SSM-Dokumenten sollte die Einstellung „Öffentliches Teilen blockieren“ aktiviert sein

• [StepFunctions.1] Step Functions Functions-Zustandsmaschinen sollten die Protokollierung aktiviert haben

• [Transfer.2] Transfer Family Family-Server sollten kein FTP-Protokoll für die Endpunktverbindung verwenden

• [Transfer.3] Bei Connectoren der Transfer Family sollte die Protokollierung aktiviert sein

• [Transfer.4] Transfer Family Familienverträge sollten gekennzeichnet werden

• [Transfer.6] Steckverbinder der Transfer Family sollten gekennzeichnet sein

• [WAF.1] AWS WAF Die klassische globale Web-ACL-Protokollierung sollte aktiviert sein

• [WAF.2] AWS WAF Klassische Regionalregeln sollten mindestens eine Bedingung enthalten

• [WAF.3] AWS WAF Klassische regionale Regelgruppen sollten mindestens eine Regel haben

• [WAF.4] AWS WAF Klassische regionale Web-ACLs sollten mindestens eine Regel oder Regelgruppe haben

• [WAF.6] AWS WAF Klassische globale Regeln sollten mindestens eine Bedingung haben

• [WAF.7] AWS WAF Klassische globale Regelgruppen sollten mindestens eine Regel haben

• [WAF.8] AWS WAF Klassische globale Web-ACLs sollten mindestens eine Regel oder Regelgruppe haben

• [WAF.10] AWS WAF Web-ACLs sollten mindestens eine Regel oder Regelgruppe haben

• [WAF.11] AWS WAF Die Web-ACL-Protokollierung sollte aktiviert sein

• [WAF.12] AWS WAF Für Regeln sollten CloudWatch Metriken aktiviert sein

• [WorkSpaces.1] WorkSpaces Benutzervolumes sollten im Ruhezustand verschlüsselt werden

• [WorkSpaces.2] WorkSpaces Root-Volumes sollten im Ruhezustand verschlüsselt werden