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.
Standardsteuerungen in AMS Accelerate
Im Folgenden sind die Standardsteuerungen in AMS aufgeführt:
| ID | Technischer Standard |
|---|---|
| 1,0 | Dauer des Timeouts |
| 1.1 | Das standardmäßige Timeout einer Sitzung für Verbundbenutzer beträgt eine Stunde und kann auf bis zu vier Stunden erhöht werden. |
| 1.2 | Das RDP-Sitzungstimeout für Microsoft Windows Server ist auf 15 Minuten festgelegt und kann je nach Anwendungsfall verlängert werden. |
| 2.0 | AWS Nutzung des Root-Kontos |
| 2.1 | Wenn aus irgendeinem Grund ein Root-Konto genutzt wird, GuardDuty muss Amazon so konfiguriert werden, dass relevante Ergebnisse generiert werden. |
| 2.2 | Zugriffsschlüssel für das Root-Konto dürfen nicht erstellt werden. |
| 3.0 | Erstellung und Änderung von Benutzern |
| 3.1 | IAM users/roles mit programmatischem Zugriff und nur Leseberechtigungen können ohne zeitlich begrenzte Richtlinien erstellt werden. Die Erlaubnis, das Lesen von Objekten (z. B. S3:GetObject) in allen Amazon Simple Storage Service-Buckets des Kontos zuzulassen, ist jedoch nicht zulässig. |
| 3.1.1 | Menschliche IAM-Benutzer für Konsolenzugriff und mit Leseberechtigungen können mit der zeitgebundenen Richtlinie (bis zu 180 Tage) erstellt werden, während die Richtlinie mit zeitgebundenem Zugriff zu removal/renewal/extension einer Risikobenachrichtigung führt. Die Erlaubnis, das Lesen von Objekten (z. B. S3:GetObject) in allen S3-Buckets des Kontos zuzulassen, ist jedoch nicht zulässig. |
| 3.2 | IAM-Benutzer und -Rollen für den Konsolen- und programmatischen Zugriff mit allen infrastrukturverändernden Berechtigungen (Schreib- und Rechteverwaltung) im Kundenkonto dürfen nicht ohne Risikobereitschaft erstellt werden. Ausnahmen bestehen für S3-Schreibberechtigungen auf Objektebene, die ohne Risikoübernahme zulässig sind, sofern sich die spezifischen Buckets im Gültigkeitsbereich und bei Tagging-Vorgängen für Tags befinden, die nichts mit AMS zu tun haben. |
| 3.3 | Auf Microsoft Windows-Servern muss nur das Microsoft Group Managed Service Account (gMSA) erstellt werden. |
| 4.0 | Richtlinien, Maßnahmen und APIs |
| 4.4 | Eine Richtlinie darf den Administratorzugriff nicht mit einer Aussage wie „Wirkung“: „Zulassen“ mit „Aktion“: „*“ statt „Ressource“: „*“ ohne Risikobereitschaft gewähren. |
| 4.6 | API-Aufrufe gegen KMS-Schlüsselrichtlinien für AMS-Infrastrukturschlüssel in den IAM-Richtlinien des Kunden dürfen nicht zulässig sein. |
| 4.8 | Aktionen, die die DNS-Einträge der AMS-Infrastruktur in Amazon Route 53 ändern, dürfen nicht zugelassen werden. |
| 4,9 bis 4,9 | Menschliche IAM-Benutzer mit Konsolenzugriff, die nach Ablauf des ordnungsgemäßen Verfahrens erstellt wurden, dürfen keine Richtlinien direkt angehängt haben, mit Ausnahme der Richtlinien „Vertrauen“, „Rolle übernehmen“ und „Zeitbegrenzung“. |
| 4.10 | EC2 Amazon-Instanzprofile mit Lesezugriff auf ein bestimmtes Geheimnis oder einen bestimmten Namespace AWS Secrets Manager innerhalb desselben Kontos können erstellt werden. |
| 4.12 | Die IAM-Richtlinie darf keine Aktion beinhalten, zu der auch die Aktionen Logs zulassen: DeleteLogGroup und Logs: DeleteLogStream für eine CloudWatch AMS-Amazon-Protokollgruppe gehören. |
| 4.13 | Berechtigungen zur Erstellung von Schlüsseln für mehrere Regionen dürfen nicht zulässig sein. |
| 4.14 | Der Zugriff auf S3-Bucket-ARN, die noch nicht in den Kundenkonten erstellt wurden, kann bereitgestellt werden, indem der Zugriff auf die Buckets auf die Kundenkonten beschränkt wird, indem die Kontonummer mithilfe des dienstspezifischen S3-Bedingungsschlüssels s3: angegeben wird. ResourceAccount |
| 4.15.1 | Sie können Zugriff auf Ihr benutzerdefiniertes S3 Storage Lens Dashboard haben, es anzeigen, erstellen, auflisten und löschen. |
| 4.16 | Für die Arbeit mit Amazon Redshift Redshift-Datenbanken können vollständige Berechtigungen im Zusammenhang mit SQL Workbench erteilt werden. roles/users |
| 4.17 | Als Alternative zur CLI können Kundenrollen beliebige AWS CloudShell Berechtigungen erteilt werden. |
| 4.18 | Eine IAM-Rolle mit AWS Service als vertrauenswürdigem Principal muss ebenfalls den technischen IAM-Standards entsprechen. |
| 4.19 | Service Linked Roles (SLRs) unterliegen nicht den technischen Standards von AMS IAM, da sie vom IAM Service Team erstellt und verwaltet werden. |
| 4.20 | Die IAM-Richtlinie sollte das Lesen von Objekten (z. B. S3:GetObject) in allen S3-Buckets des Kontos nicht zulassen. |
| 4.21 | Alle IAM-Berechtigungen für den Ressourcentyp „Savingsplan“ können Kunden gewährt werden. |
| 4.22 | Der AMS-Techniker ist nicht berechtigt, Kundendaten (Dateien, S3-Objekte, Datenbanken usw.) manuell in einem der Datenspeicherdienste wie Amazon S3, Amazon Relational Database Service, Amazon DynamoDB usw. oder im Dateisystem des Betriebssystems zu kopieren oder zu verschieben. |
| 6.0 | Kontenübergreifende Richtlinien |
| 6.1 | IAM-Rollen und Vertrauensrichtlinien zwischen AMS-Konten, die laut Kundendatensätzen demselben Kunden gehören, können konfiguriert werden. |
| 6.2 | Vertrauensrichtlinien für IAM-Rollen zwischen AMS- und Nicht-AMS-Konten müssen nur konfiguriert werden, wenn das Nicht-AMS-Konto demselben AMS-Kunden gehört (indem bestätigt wird, dass sie sich unter demselben AWS Organizations Konto befinden, oder indem die E-Mail-Domain dem Firmennamen des Kunden zugeordnet wird). |
| 6.3 | Vertrauensrichtlinien für IAM-Rollen zwischen AMS-Konten und Konten von Drittanbietern dürfen nicht ohne Risikobereitschaft konfiguriert werden. |
| 6.4 | Kontoübergreifende Richtlinien für den Zugriff auf alle Kunden, die CMKs zwischen AMS-Konten desselben Kunden verwaltet werden, können konfiguriert werden. |
| 6,5 | Kontoübergreifende Richtlinien für den Zugriff auf jeden KMS-Schlüssel innerhalb eines Nicht-AMS-Kontos über ein AMS-Konto können konfiguriert werden. |
| 6.6 | Kontoübergreifende Richtlinien für den Zugriff auf alle KMS-Schlüssel innerhalb eines AMS-Kontos durch ein Drittanbieterkonto dürfen nur zulässig sein, wenn das Risiko eingegangen wird. |
| 6.6.1 | Kontoübergreifende Richtlinien für den Zugriff auf jeden KMS-Schlüssel innerhalb eines AMS-Kontos über ein Nicht-AMS-Konto können nur konfiguriert werden, wenn das Nicht-AMS-Konto demselben AMS-Kunden gehört. |
| 6.7 | Kontoübergreifende Richtlinien für den Zugriff auf alle S3-Bucket-Daten oder Ressourcen, in denen Daten gespeichert werden können (wie Amazon RDS, Amazon DynamoDB oder Amazon Redshift), zwischen AMS-Konten desselben Kunden können konfiguriert werden. |
| 6.8 | Kontoübergreifende Richtlinien für den Zugriff auf alle S3-Bucket-Daten oder Ressourcen, in denen Daten gespeichert werden können (wie Amazon RDS, Amazon DynamoDB oder Amazon Redshift), können von einem AMS-Konto mit schreibgeschütztem Zugriff in einem Nicht-AMS-Konto aus konfiguriert werden. |
| 6.9 | Kontoübergreifende Richtlinien für den Zugriff auf alle S3-Bucket-Daten oder Ressourcen, in denen Daten gespeichert werden können (wie Amazon RDS, Amazon DynamoDB oder Amazon Redshift) mit Schreibberechtigungen von AMS auf ein Nicht-AMS-Konto (oder ein Nicht-AMS-zu-AMS-Konto), müssen nur konfiguriert werden, wenn das Nicht-AMS-Konto demselben AMS-Kunden gehört (indem bestätigt wird, dass sie sich unter demselben AWS Organizations Konto befinden, oder indem die E-Mail-Domain dem Firmennamen des Kunden zugeordnet wird). |
| 6.10 | Kontoübergreifende Richtlinien für den Zugriff auf alle S3-Bucket-Daten oder Ressourcen, in denen Daten gespeichert werden können (wie Amazon RDS, Amazon DynamoDB oder Amazon Redshift), können von einem AMS-Konto mit schreibgeschütztem Zugriff aus einem Drittanbieter-Konto konfiguriert werden. |
| 6.11 | Kontoübergreifende Richtlinien für den Zugriff auf S3-Bucket-Daten oder Ressourcen, in denen Daten gespeichert werden können (wie Amazon RDS, Amazon DynamoDB oder Amazon Redshift), von einem AMS-Konto mit Schreibzugriff in einem Drittanbieter-Konto aus dürfen nicht konfiguriert werden. |
| 6.12 | Kontoübergreifende Richtlinien von Drittanbieterkonten für den Zugriff auf einen S3-Bucket eines AMS-Kunden oder auf Ressourcen, in denen Daten gespeichert werden können (wie Amazon RDS, Amazon DynamoDB oder Amazon Redshift), dürfen nicht ohne Risikobereitschaft konfiguriert werden. |
| 7.0 | User Groups (Benutzergruppen) |
| 7.1 | IAM-Gruppen mit schreibgeschützten und nicht mutativen Berechtigungen sind zulässig. |
| 8.0 | Ressourcenbasierte Richtlinien |
| 8,4 | Die AMS-Infrastrukturressourcen sollten durch das Hinzufügen von ressourcenbasierten Richtlinien vor der Verwaltung durch unbefugte Identitäten geschützt werden. |
| 8.2 | Kundenressourcen sollten mit ressourcenbasierten Richtlinien mit den geringsten Rechten konfiguriert werden, es sei denn, der Kunde spezifiziert ausdrücklich eine andere Richtlinie. |
Im Folgenden finden Sie die Standardsteuerung für X003 — Netzwerksicherheit:
| ID | Technischer Standard |
|---|---|
| Netzwerkfunktionen | |
| 1,0 | Reserviert für future Kontrolle |
| 2.0 | Elastic IP auf EC2 Instances ist zulässig |
| 3.0 | Die AMS-Steuerebene und damit auch TLS 1.2+ in der Datenebene müssen verwendet werden. |
| 5.0 | Eine Sicherheitsgruppe darf in der Regel für eingehenden Datenverkehr nicht die Quelle 0.0.0.0/0 haben, wenn sie nicht gemäß 9.0 an einen Load Balancer angehängt ist |
| 6.0 | S3-Buckets oder Objekte dürfen nicht ohne Risikobereitschaft veröffentlicht werden. |
| 7.0 | Der Serververwaltungszugriff auf die Ports SSH/22 oder SSH/2222 (nicht SFTP/2222), TELNET/23, RDP/3389, WinRM/5985-5986, VNC/ 5900-5901 TS/CITRIX/1494 oder 1604, LDAP/389 oder 636 und RPC/135, NETBIOS/137-139 darf nicht von außerhalb der VPC über Sicherheitsgruppen zugelassen werden. |
| 8.0 | Der Zugriff auf die Datenbankverwaltung auf Ports (MySQL/3306, PostgreSQL/5432, Oracle/1521, MSSQL/1433) oder auf einem benutzerdefinierten Port darf nicht von öffentlich zugelassen werden, nicht über DX, VPC-Peer oder VPN über eine Sicherheitsgruppe an VPC geroutet werden. IPs |
| 8.1 | Jede Ressource, in der Kundendaten gespeichert werden können, sollte nicht direkt dem öffentlichen Internet zugänglich gemacht werden. |
| 9.0 | Direkter Anwendungszugriff über die Ports HTTP/80, HTTPS/8443 und HTTPS/443 aus dem Internet ist nur für Load Balancer zulässig, nicht jedoch für direkte Rechenressourcen, z. B. Instanzen, Container usw. EC2 ECS/EKS/Fargate |
| 10.0 | Der Zugriff auf Anwendungen über die Ports HTTP/80 und HTTPS/443 aus dem privaten IP-Bereich des Kunden kann zugelassen werden. |
| 11.0 | Jegliche Änderungen an den Sicherheitsgruppen, die den Zugriff auf die AMS-Infrastruktur kontrollieren, dürfen nicht ohne Risikobereitschaft zugelassen werden. |
| 12.0 | AMS Security bezieht sich jedes Mal auf die Standards, wenn eine Sicherheitsgruppe aufgefordert wird, einer Instance zugeordnet zu werden. |
| 14.0 | Die kontenübergreifende Zuordnung von privaten gehosteten Zonen mit einem VPCs AMS-Konto zu einem Nicht-AMS-Konto (oder einem Nicht-AMS-Konto zu AMS-Konto) muss nur konfiguriert werden, wenn das Nicht-AMS-Konto demselben AMS-Kunden gehört (indem bestätigt wird, dass sie sich unter demselben AWS-Organisationskonto befinden, oder indem die E-Mail-Domain dem Firmennamen des Kunden zugeordnet wird). Verwenden Sie dazu interne Tools. |
| 15.0 | VPC-Peering-Verbindungen zwischen Konten, die demselben Kunden gehören, können zugelassen werden. |
| 16.0 | Die AMIs AMS-Basis kann mithilfe interner Tools mit einem anderen Konto gemeinsam genutzt werden, sofern beide Konten demselben Kunden gehören (indem bestätigt wird, dass sie sich unter demselben AWS Organizations Konto befinden, oder indem die E-Mail-Domain dem Firmennamen des Kunden zugeordnet wird). |
| 17.0 | FTP-Port 21 darf in keiner der Sicherheitsgruppen konfiguriert werden, ohne dass ein Risiko eingegangen ist. |
| 18.0 | Kontoübergreifende Netzwerkkonnektivität über das Transit-Gateway ist zulässig, solange sich alle Konten im Besitz des Kunden befinden. |
| 19.0 | Es ist nicht zulässig, ein privates Subnetz öffentlich zugänglich zu machen |
| 20.0 | VPC-Peering-Verbindungen mit Konten von Drittanbietern (die nicht dem Kunden gehören) dürfen nicht zugelassen werden. |
| 21.0 | Eine Verbindung mit einem Drittanbieterkonto (das nicht dem Kunden gehört) durch Transit Gateway darf nicht zugelassen werden. |
| 22.0 | Jeglicher Netzwerkverkehr, der für AMS zur Bereitstellung der Dienste für Kunden erforderlich ist, darf am Netzwerkausgangspunkt des Kunden nicht blockiert werden. |
| 23,0 | Für eingehende ICMP-Anfragen EC2 von der Kundeninfrastruktur an Amazon ist eine Risikobenachrichtigung erforderlich. |
| 24,0 | Eingehende Anfragen von der Öffentlichkeit, die über DX, VPC-Peer oder VPN über eine Sicherheitsgruppe an Amazon VPC IPs weitergeleitet werden, sind zulässig. |
| 25.0 | Eingehende Anfragen von der Öffentlichkeit, die IPs nicht über DX, VPC-Peer oder VPN über eine Sicherheitsgruppe an Amazon VPC weitergeleitet werden, erfordern eine Risikoakzeptanz. |
| 26,0 | Ausgehende ICMP-Anfragen von Amazon EC2 an ein beliebiges Ziel sind zulässig. |
| 27,0 | Gemeinsame Nutzung von Sicherheitsgruppen |
| 27.1 | Wenn eine Sicherheitsgruppe diesen Sicherheitsstandard erfüllt, kann sie von mehreren Mitgliedern VPCs desselben Kontos und von Konten derselben Organisation gemeinsam genutzt werden. |
| 27.2 | Wenn eine Sicherheitsgruppe diesen Standard nicht erfüllt und zuvor eine Risikoakzeptanz für diese Sicherheitsgruppe erforderlich war, ist die Verwendung der Funktion zur gemeinsamen Nutzung von Sicherheitsgruppen zwischen VPCs Konten innerhalb desselben Kontos oder zwischen Konten in derselben Organisation ohne Risikoakzeptanz für diese neue VPC oder dieses neue Konto nicht zulässig. |
Im Folgenden finden Sie die Standardsteuerung für X004 — Penetrationstests
AMS unterstützt keine Pentest-Infrastruktur. Es liegt in der Verantwortung des Kunden. Kali ist beispielsweise keine AMS-unterstützte Linux-Distribution.
Kunden müssen sich an Penetrationstests
halten. AMS muss 24 Stunden im Voraus benachrichtigt werden, falls der Kunde Infrastruktur-Penetrationstests für Konten durchführen möchte.
AMS stellt dem Kunden eine Pentesting-Infrastruktur gemäß den Kundenanforderungen bereit, die ausdrücklich in der Änderungsanfrage oder Serviceanfrage des Kunden angegeben sind.
Das Identitätsmanagement für die Pentesting-Infrastruktur des Kunden liegt in der Verantwortung des Kunden.
Das Folgende ist die Standardsteuerung für X005 - GuardDuty
GuardDuty muss in allen Kundenkonten jederzeit aktiviert sein.
GuardDuty Benachrichtigungen müssen in demselben Konto oder in einem anderen verwalteten Konto derselben Organisation gespeichert werden.
Die Funktion „Liste vertrauenswürdiger IP-Adressen“ von GuardDuty darf nicht verwendet werden. Stattdessen kann die automatische Archivierung als Alternative verwendet werden, was für Auditzwecke nützlich ist.
Im Folgenden finden Sie die Standardsteuerung für X007 — Logging
| ID | Technischer Standard |
|---|---|
| 1,0 | Typen von Protokollen |
| 1.1 | Betriebssystemprotokolle: Alle Hosts müssen mindestens Host-Authentifizierungsereignisse, Zugriffsereignisse für alle Nutzungen erhöhter Rechte und Zugriffsereignisse für alle Änderungen an der Zugriffs- und Rechtekonfiguration protokollieren, einschließlich Erfolg und Misserfolg. |
| 1.2 | AWS CloudTrail: Die Protokollierung von CloudTrail Verwaltungsereignissen muss aktiviert und konfiguriert sein, um Protokolle an einen S3-Bucket zu übermitteln. |
| 1.3 | VPC Flow Logs: Alle Netzwerkverkehrsprotokolle müssen über VPC Flow Logs protokolliert werden. |
| 1.4 | Amazon S3 S3-Serverzugriffsprotokollierung: Für von AMS vorgeschriebene S3-Buckets, in denen Protokolle gespeichert werden, muss die Serverzugriffsprotokollierung aktiviert sein. |
| 1.5 | AWS Config Snapshots: AWS Config müssen Konfigurationsänderungen für alle unterstützten Ressourcen in allen Regionen aufzeichnen und die Konfigurations-Snapshot-Dateien mindestens einmal täglich an S3-Buckets liefern. |
| 1,7 | Anwendungsprotokolle: Kunden können die Protokollierung in ihren Anwendungen aktivieren und diese in der Protokollgruppe CloudWatch Logs oder in einem S3-Bucket speichern. |
| 1.8 | S3-Protokollierung auf Objektebene: Kunden können die Protokollierung auf Objektebene in ihren S3-Buckets aktivieren. |
| 1.9 | Serviceprotokollierung: Kunden sind berechtigt, Protokolle für SSPS-Dienste wie für alle Kerndienste zu aktivieren und weiterzuleiten. |
| 1.10 | Elastic Load Classic/Application Load Balancer/Network Balancing (Load Balancer) -Protokolle: Zugriffs- und Fehlerprotokolleinträge müssen in den von AMS 2.0 verwalteten S3-Buckets gespeichert werden. |
| 2.0 | Zugriffskontrolle |
| 2.3 | Von AMS vorgeschriebene S3-Buckets, in denen Logs gespeichert werden, dürfen laut den Bucket-Richtlinien grundsätzlich keine Benutzer von Drittanbieterkonten zulassen. |
| 2.4 | CloudWatch Protokolle aus Logs-Protokollgruppen dürfen ohne ausdrückliche Genehmigung des vom Kunden autorisierten Sicherheitskontakts nicht gelöscht werden. |
| 3.0 | Aufbewahrung von Protokollen |
| 3.1 | Für CloudWatch Protokollgruppen, die von AMS vorgeschrieben sind, muss eine Mindestaufbewahrungsdauer von 90 Tagen für die Protokolle gelten. |
| 3.2 | Von AMS vorgeschriebene S3-Buckets, in denen die Protokolle gespeichert werden, müssen eine Mindestaufbewahrungsdauer von 18 Monaten für die Protokolle haben. |
| 3.3 | AWS Backup Snapshots sollten mit einer Mindestdauer von 31 Tagen auf den unterstützten Ressourcen verfügbar sein. |
| 4.0 | Verschlüsselung |
| 4.1 | Die Verschlüsselung muss in allen S3-Buckets aktiviert sein, die von AMS Teams, das Protokolle speichert, benötigt werden. |
| 4.2 | Jede Protokollweiterleitung von Kundenkonten zu anderen Konten muss verschlüsselt sein. |
| 5.0 | Integrität |
| 5.1 | Der Integritätsmechanismus für Protokolldateien muss aktiviert sein. Das bedeutet, dass Sie die „Überprüfung der Protokolldateien“ in den von den AMS-Teams benötigten AWS CloudTrail Pfaden konfigurieren müssen. |
| 6.0 | Weiterleitung von Protokollen |
| 6.1 | Jedes Protokoll kann von einem AMS-Konto an ein anderes AMS-Konto desselben Kunden weitergeleitet werden. |
| 6.2 | Jedes Protokoll kann mithilfe interner Tools nur dann von AMS an ein Nicht-AMS-Konto weitergeleitet werden, wenn das Nicht-AMS-Konto demselben AMS-Kunden gehört (indem bestätigt wird, dass es sich um dasselbe AWS Organizations Konto handelt, oder indem die E-Mail-Domain dem Firmennamen des Kunden und dem mit PAYER verknüpften Konto zugeordnet wird). |
