Nationales Institut für Standards und Technologie (NIST) SP 800-53 Rev. 5

NIST SP 800-53 Rev. 5 ist ein Framework für Cybersicherheit und Compliance, das vom National Institute of Standards and Technology (NIST), einer Behörde, die Teil des US-Handelsministeriums ist, entwickelt wurde. Dieses Compliance-Framework hilft Ihnen, die Verfügbarkeit, Vertraulichkeit und Integrität Ihrer Informationssysteme und kritischen Ressourcen zu schützen. US-Bundesbehörden und Auftragnehmer müssen zum Schutz ihrer Systeme die Anforderungen von NIST SP 800-53 einhalten. Private Unternehmen können sie jedoch freiwillig als Leitfaden zur Reduzierung von Cybersicherheitsrisiken verwenden.

Security Hub bietet Steuerungen, die ausgewählte Anforderungen von NIST SP 800-53 unterstützen. Diese Kontrollen werden im Rahmen automatisierter Sicherheitsüberprüfungen bewertet. Security Hub-Steuerelemente unterstützen keine Anforderungen von NIST SP 800-53, die manuelle Prüfungen erfordern. Darüber hinaus unterstützen Security Hub-Steuerelemente nur die automatisierten NIST SP 800-53-Anforderungen, die in den Details der einzelnen Kontrollen unter Verwandte Anforderungen aufgeführt sind. Wählen Sie ein Steuerelement aus der folgenden Liste aus, um dessen Details zu sehen. Verwandte Anforderungen, die nicht in den Kontrolldetails aufgeführt sind, werden derzeit von Security Hub nicht unterstützt.

Im Gegensatz zu anderen Frameworks schreibt NIST SP 800-53 nicht vor, wie seine Anforderungen bewertet werden sollten. Stattdessen enthält das Framework Richtlinien, und die Security Hub NIST SP 800-53-Steuerelemente stellen das Verständnis dar, das der Service von ihnen hat.

Wenn Sie die Security Hub-Integration mit verwenden AWS Organizations , um mehrere Konten zentral zu verwalten und NIST SP 800-53 für alle Konten stapelweise aktivieren möchten, können Sie vom Administratorkonto aus ein Security Hub-Skript für mehrere Konten ausführen.

Weitere Informationen zu NIST SP 800-53 Rev. 5 finden Sie im NIST Computer Security Resource Center.

Kontrollen, die für NIST SP 800-53 Rev. 5 gelten

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

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

[ACM.1] Importierte und von ACM ausgestellte Zertifikate sollten nach einem bestimmten Zeitraum erneuert 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] Bei den REST-API-Stufen von API Gateway sollte die Ablaufverfolgung aktiviert sein AWS X-Ray

[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 Gateway-Routen sollten einen Autorisierungstyp angeben

[ApiGateway.9] Die Zugriffsprotokollierung sollte für API Gateway V2 Stages konfiguriert sein

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

[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 Instance-Typen 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 sein

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

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

[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

[CloudWatch.15] Für 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

[CodeBuild1.4] CodeBuild Projektumgebungen sollten eine AWS Config Protokollierungsdauer haben

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

[DataFirehose.1] Firehose-Lieferstreams sollten im Ruhezustand verschlüsselt 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] Bei DMS-Endpunkten für Neptune-Datenbanken sollte die IAM-Autorisierung aktiviert sein

[DMS.11] Bei DMS-Endpunkten für MongoDB sollte ein Authentifizierungsmechanismus aktiviert sein

[DMS.12] Auf DMS-Endpunkten für Redis 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

[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

[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 öffentlich wiederherstellbar sein

[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 so konfiguriert sein, dass es VPC-Endpunkte verwendet, die für den Amazon EC2-Service erstellt wurden

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

[EC2.13] Sicherheitsgruppen sollten keinen Zugang von 0.0.0.0/0 oder: :/0 zu Port 22 zulassen

[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 Verkehr 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 eine AWS Site-to-Site-VPN-Verbindung sollten aktiv sein

[EC2.21] Netzwerk-ACLs sollten keinen Zugang von 0.0.0.0/0 zu Port 22 oder Port 3389 zulassen

[EC2.23] Amazon EC2 Transit Gateways sollten VPC-Anhangsanfragen 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

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

[ECR.2] Bei privaten ECR-Repositorys sollte die Tag-Unveränderlichkeit konfiguriert sein

[ECR.3] Für ECR-Repositorys sollte mindestens eine Lebenszyklusrichtlinie konfiguriert sein

[ECS.1] Amazon ECS-Aufgabendefinitionen sollten sichere Netzwerkmodi und Benutzerdefinitionen enthalten.

[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-Container sollten auf den schreibgeschützten Zugriff auf Root-Dateisysteme beschränkt sein

[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

[EFS.1] Elastic File System sollte so konfiguriert sein, dass ruhende Dateidaten verschlüsselt werden mit 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-Zugangspunkte sollten eine Benutzeridentität erzwingen

[EFS.6] EFS-Mount-Ziele sollten keinem öffentlichen Subnetz zugeordnet 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.3] EKS-Cluster sollten verschlüsselte Kubernetes-Geheimnisse verwenden

[EKS.8] Bei EKS-Clustern sollte die Auditprotokollierung aktiviert sein

[ElastiCache.1] Bei ElastiCache Redis-Clustern sollte das automatische Backup aktiviert sein

[ElastiCache.2] ElastiCache Für Redis-Cache-Cluster sollte das auto Upgrade der Nebenversion aktiviert sein

[ElastiCache.3] ElastiCache Für Redis-Replikationsgruppen sollte der automatische Failover aktiviert sein

[ElastiCache.4] ElastiCache für Redis-Replikationsgruppen sollten im Ruhezustand verschlüsselt werden

[ElastiCache.5] ElastiCache für Redis-Replikationsgruppen sollten bei der Übertragung verschlüsselt werden

[ElastiCache.6] ElastiCache Für Redis-Replikationsgruppen vor Version 6.0 sollte Redis AUTH verwendet werden

[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

[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 HTTP-Header gelöscht werden

[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 Verbindungsverlust aktiviert sein

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

[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] Application Load Balancer sollte mit einem defensiven oder strengsten Desync-Minimationsmodus konfiguriert werden

[ELB.13] Anwendungs-, Netzwerk- und Gateway-Load Balancer 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 einer Web-ACL verknüpft sein AWS WAF

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

[EMR.2] Die Amazon EMR-Einstellung zum Blockieren des öffentlichen Zugriffs sollte aktiviert sein

[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

[ES.7] Elasticsearch-Domänen 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

[GuardDuty.1] GuardDuty 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 -Benutzer aktiviert sein, die über ein Konsolenpasswort verfügen

[IAM.6] Hardware-MFA sollte für den Stammbenutzer aktiviert sein.

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

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

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

[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

[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] Die AWS KMS Schlüsselrotation sollte aktiviert 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

[Macie.1] Amazon Macie sollte aktiviert sein

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

[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

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

[MQ.3] Bei Amazon MQ-Brokern sollte das automatische Upgrade der Nebenversion aktiviert sein

[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 IAM-Datenbankauthentifizierung aktiviert sein

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

[NetworkFirewall.4] Die standardmäßige statuslose Aktion für Netzwerk-Firewall-Richtlinien sollte für vollständige Pakete entweder verwerfen oder weiterleiten 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

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

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

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

[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 Root-Zertifizierungsstelle sollte deaktiviert sein

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

[RDS.2] RDS-DB-Instances sollten je nach Dauer den öffentlichen Zugriff verbieten PubliclyAccessible AWS Config

[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 Protokolle in Logs veröffentlichen CloudWatch

[RDS.10] Die IAM-Authentifizierung sollte für RDS-Instances konfiguriert werden

[RDS.11] Bei 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] RDS-DB-Cluster sollten so konfiguriert werden, dass sie Tags in Snapshots kopieren

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

[RDS.18] RDS-Instances sollten in einer VPC bereitgestellt werden

[RDS.19] Bestehende Abonnements für RDS-Ereignisbenachrichtigungen sollten für kritische Cluster-Ereignisse 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 Logs veröffentlichen CloudWatch

[RDS.35] Für RDS-DB-Cluster sollte das automatische Upgrade auf Nebenversionen 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 standardmäßigen Admin-Benutzernamen verwenden

[Redshift.9] Redshift-Cluster sollten nicht den Standard-Datenbanknamen verwenden

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

[Route53.2] Öffentlich gehostete Route 53-Zonen sollten DNS-Abfragen protokollieren

[S3.1] Bei S3-Allzweck-Buckets sollten die Einstellungen für den öffentlichen Zugriff blockieren aktiviert sein

[S3.2] S3-Allzweck-Buckets sollten den öffentlichen Lesezugriff blockieren

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

[S3.5] S3-Allzweck-Buckets sollten Anfragen zur Verwendung von SSL erfordern

[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] Bei S3-Allzweck-Buckets sollte die Serverzugriffsprotokollierung aktiviert sein

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

[S3.11] Bei 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] Bei 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] Bei S3-Allzweck-Buckets sollte MFA Delete 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

[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 nur innerhalb einer AWS Organisation gemeinsam genutzt werden

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

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

[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

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

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

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

[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] Die AWS WAF Web-ACL-Protokollierung sollte aktiviert sein

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