Standardsteuerungen in AMS Advanced - AMS-Benutzerhandbuch für Fortgeschrittene

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 Advanced

Im Folgenden sind die Standardsteuerungen in AMS aufgeführt:

Im Folgenden finden Sie die Standardsteuerung für 001 — Tagging-Konfiguration.

  1. Alle AWS Ressourcen, die das AMS-Team für Betriebs- und Managementzwecke benötigt, müssen das folgende Schlüssel-Wert-Paar aufweisen.

    • AppId= AMSInfrastructure

    • Umgebung= AMSInfrastructure

    • AppName = AMSInfrastructure

    • AMSResource=Wahr

  2. Alle Tags, die vom AMS-Team benötigt werden, mit Ausnahme der zuvor aufgeführten, müssen Präfixe haben, die in der Liste der AMS-Präfixe aufgeführt sind (siehe Hinweis).

  3. Die vom AMS-Team benötigten Tagwerte (AppId, Umgebung und AppName) können für alle Ressourcen geändert werden, die Sie auf der Grundlage Ihrer Änderungsanforderungen erstellt haben.

  4. Alle von AMS benötigten Tags auf Stacks dürfen aufgrund Ihrer Änderungsanfragen nicht gelöscht werden.

  5. Sie können die AMS-Tag-Benennungskonvention nicht für Ihre Infrastruktur verwenden, wie in Punkt 2 erwähnt.

  6. Sie können benutzerdefinierte Tags in den von AMS benötigten Ressourcen erstellen lassen (in der Regel für Anwendungsfälle in den Bereichen Abrechnung und Kostenberichterstattung). Benutzerdefinierte Tags werden beibehalten, wenn Ressourcen durch ein Stack-Update und nicht durch das Aktualisieren der Vorlage aktualisiert werden.

Anmerkung

Liste der AMS-Präfixe

  1. ams-*

  2. AWSManagedLeistungen*

  3. /ams/ *

  4. ams*

  5. AMS*

  6. Ams*

  7. mc*

  8. MC*

  9. Mc*

  10. Wächter*

  11. Wächter*

  12. Verwaltete_Dienste*

  13. Neues AMS*

  14. AWS_*

  15. aws*

  16. VPC_*

  17. CloudTrail*

  18. Wolkenspur*

  19. /aws_reserviert/

  20. AUFNEHMEN*

  21. EPSDB*

  22. MMS*

  23. TemplateId*

  24. StackSet-bin*

  25. StackSet-AWS-Landezone

  26. IAMPolicy*

  27. Kunde-mc-*

  28. Wurzel*

  29. LandingZone*

  30. StateMachine*

  31. codedeploy_service_role

  32. Verwaltungshost

  33. sentinel.int.

  34. eps

  35. UnhealthyInServiceBastion

  36. Frau-

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 Die Standard-Stack-Zugriffszeit beträgt 12 Stunden.
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 Für Single-Account-Landingzone-Konten (SALZ) und Multi-Account-Landingzone-Verwaltungskonten (früher bekannt als Master/Billing Konto) muss für das Root-Benutzerkonto virtuelles MFA aktiviert sein und der MFA-Soft-Token wird bei der Kontoeröffnung verworfen, sodass sich weder AMS noch Kunden als Root anmelden können. Das Standardverfahren für den Verlust von AWS Root-Passwörtern muss in Verbindung mit Ihrem AMS Cloud Service Delivery Manager (CSDM) befolgt werden. Diese Konfiguration muss während des Lebenszyklus der von AMS verwalteten Konten beibehalten werden.
2.3 Sie dürfen keine Zugriffsschlüssel für das Root-Konto erstellen.
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 removal/renewal/extension zeitgebundene Richtlinie zur 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 IAM-Benutzer mit programmatischem Zugriff, die benannt customer_servicenow_logging_user sind customer_servicenow_user und für die ServiceNow Integration in das SALZ- oder MALZ-Anwendungskonto und *Kernkonten* erforderlich sind, können ohne zeitlich begrenzte Richtlinien erstellt werden.
3.4 IAM-Benutzer mit programmatischem Zugriff, die die CloudEndure Integration in SALZ customer_cloud_endure_policy - und MALZ-Konten verwenden und customer_cloud_endure_deny_policy (mit schreibgeschütztem Zugriff) benötigen, können zwar erstellt werden, benötigen jedoch eine zeitlich begrenzte Richtlinie für den Zeitraum der geplanten Migration. Die Frist kann für einen Zeitraum von maximal 180 Tagen ohne RA gelten. Der SCP ist auch berechtigt, Änderungen für MALZ-Konten vorzunehmen, damit diese Richtlinien für den erforderlichen Zeitraum gültig sind. Sie definieren geeignete Migrationsfenster für Ihre Bedürfnisse und passen sie nach Bedarf an.
4.0 Richtlinien, Maßnahmen und APIs
4.1 Für alle Ihre IAM-Benutzer und Rollen in SALZ-Konten muss die standardmäßige Customer Deny Policy (CDP) gelten, um die AMS-Infrastruktur vor versehentlicher oder vorsätzlicher Beschädigung zu schützen.
4.2 AMS SCPs muss in allen von AMS verwalteten Konten in MALZ aktiviert sein.
4.3 Identitäten, die administrative Aktionen mit KMS-Schlüsseln ausführen können, wie z. B. und PutKeyPolicyScheduleKeyDeletion, dürfen nur AMS-Operatoren und Automatisierungsprinzipalen zur Verfügung stehen.
4.4 Eine Richtlinie darf den Administratorzugriff nicht mit einer Aussage wie „Wirkung“: „Zulassen“ mit „Aktion“: „*“ statt „Ressource“: „*“ ohne Risikobereitschaft gewähren.
4.5 Die IAM-Richtlinie darf keine Aktion beinhalten, die die Aktion S3: *** für einen beliebigen Bucket ohne Risikoübernahme zulassen beinhaltet.
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.7 Aktionen, die den Change-Management-Prozess (RFC) umgehen, dürfen nicht zugelassen werden, wie z. B. das Starten oder Stoppen der Instance, das Erstellen eines S3-Buckets oder einer RDS-Instanz usw.
4.8 Aktionen, die Änderungen an den DNS-Einträgen der AMS-Infrastruktur in Amazon Route 53 vornehmen, 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 Namespace AWS Secrets Manager innerhalb desselben Kontos können erstellt werden.
4.11 Berechtigungen für AWS Managed Services Change Management (AMSCM) oder AWS Managed Services Service Knowledge Management System (AMSSKMS) können jeder Rolle hinzugefügt werden (Fähigkeit, sie zu öffnen). SR/Incident/RFC
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 Um Zugriff auf S3-Buckets zu gewähren ARNs , die noch nicht in Ihren Konten erstellt wurden, verwenden Sie den dienstspezifischen S3-Bedingungsschlüssel, s3:ResourceAccount um die Kontonummer anzugeben.
4.15 Sie können Ihr benutzerdefiniertes Dashboard anzeigen, erstellen, auflisten und löschen, aber nur auf CloudWatch Amazon-Dashboards anzeigen und auflisten.
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 einem AWS-Service vertrauenswürdigen Principal muss außerdem den technischen Standards von IAM 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 IAM-Richtlinien dürfen keinen uneingeschränkten Lesezugriff auf Amazon S3-Bucket-Objekte (z. B. Amazon S3:GetObject) für alle Buckets in einem Konto zulassen:

  • Konten im Entwicklermodus: Verstöße führen zu einer Risikobenachrichtigung

  • In Konten außerhalb des Entwicklermodus: Verstöße erfordern Risikobereitschaft

4.21 Alle IAM-Berechtigungen für den Ressourcentyp „Savingsplan“ können Kunden gewährt werden.
4.22 AMS-Techniker dürfen Kundendaten (Dateien, S3-Objekte, Datenbanken) nicht manuell in einen der Datenspeicherdienste wie Amazon S3, Amazon Relational Database Service, Amazon DynamoDB usw. oder in das Betriebssystem-Dateisystem kopieren oder verschieben.
4.23 Die SCP-Richtlinie darf nicht geändert werden, um zusätzlichen Zugriff auf eines der von AMS verwalteten Konten zu ermöglichen.
4.24 Jegliche Änderungen der SCP-Richtlinie, die die AMS-Infrastruktur oder die Verwaltungsfunktionen beeinträchtigen könnten, dürfen nicht zugelassen werden. (Hinweis: AMS-Ressourcen haben das Tag AppId= AMSInfrastructure und folgen dem AMS Protected Namespace).
4.25 Die Funktion AMS Automated IAM Provisioning muss in Ihren Konten als Opt-in-Funktion aktiviert sein.
4.26 Von Menschen übernommene Rollen oder Benutzer von AMS dürfen keinen Zugriff auf Kundeninhalte in S3, RDS, DynamoDB, Redshift, Elasticache, EFS und haben. FSx Außerdem muss jeder Zugriff auf bekannte, neue APIs Veröffentlichungen von anderen, die Zugriff auf Kundeninhalte gewähren AWS-Services , in den Rollen des Operators ausdrücklich verweigert werden.
5.0 Verbund
5.1 Die Authentifizierung muss mithilfe des Verbunds im AMS-verwalteten Konto konfiguriert werden.
5.2 Es darf nur eine einseitige ausgehende Vertrauensstellung von AMS AD zu Ihrem Active Directory bestehen (AMS AD vertraut On-Prem AD).
5.3 Ihre Identitätsspeicher, die für die Authentifizierung bei AMS verwendet wurden, dürfen in AMS-verwalteten Anwendungskonten nicht vorhanden sein.
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 für 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,1 Die AMS-Infrastrukturressourcen müssen durch das Hinzufügen von ressourcenbasierten Richtlinien vor der Verwaltung durch unbefugte Identitäten geschützt werden.
8.2 Ihre Ressourcen müssen mit ressourcenbasierten Richtlinien mit den geringsten Rechten konfiguriert werden, sofern Sie nicht ausdrücklich eine andere Richtlinie angeben.
9.0 Bereitgestellte Self-Service-Dienste (SSPS)
9.1 Die standardmäßige IAM-Rolle oder -Richtlinie von AMS (einschließlich Instanzprofil, SSPS, Muster) darf weder mit noch ohne Risikobereitschaft geändert werden. Ausnahmen sind (ohne Risikoakzeptanz) für Vertrauensrichtlinien zulässig. Das Markieren von Rollen-, Richtlinien- oder Benutzeränderungen ist auch in den SSP-Standardrollen zulässig.
9.3 Die SSPS-Richtlinie für die Systems Manager Automation-Konsolenrolle kann mit Ausnahme der Standardrolle keinen benutzerdefinierten Rollen zugewiesen werden. Andere SSPS-Richtlinien dürfen nur dann an benutzerdefinierte IAM-Rollen angehängt werden, wenn sichergestellt ist, dass durch das Anhängen der Richtlinie an eine benutzerdefinierte Rolle keine zusätzlichen Berechtigungen gewährt werden, die über das für den SSPS-Standarddienst vorgesehene Design hinausgehen.

Im Folgenden finden Sie die Standardsteuerung für 003 — Netzwerksicherheit:

ID Technischer Standard
Netzwerkfunktionen
1,0 Auf alle EC2 Instances darf nur über SSH oder RDP über Bastion-Hosts, Bastion-Host-VPC-CIDR-Bereich oder über denselben VPC-CIDR-Bereich der Instanz zugegriffen werden.
2.0 EC2 Elastic IP auf Instances ist zulässig
3.0 Die AMS-Steuerebene und damit auch TLS 1.2+ in der Datenebene müssen verwendet werden.
4,0 Der gesamte ausgehende Datenverkehr muss über das Konto IGW oder TGW weitergeleitet 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 und nicht über eine Sicherheitsgruppe an VPC über DX, VPC-Peer oder VPN weitergeleitet 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 wie Instances, 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 Ä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.
13.0 Der Zugriff auf Kundenbastion an den Ports 3389 und 22 darf nur von privaten IP-Bereichen aus zugelassen werden, die über DX, VPC-Peer oder VPN in die VPC geroutet 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 Die gemeinsame Nutzung von Resolver-Regeln mit Personen, die demselben Kunden AWS-Konto gehören, ist mit einer Risikobenachrichtigung zulässig
19.0 ICMP
19,1 Für eingehende ICMP-Anfragen EC2 von der Kundeninfrastruktur an Amazon ist eine Risikobenachrichtigung erforderlich.
19.2 Eingehende Anfragen von der Öffentlichkeit, die über DX, VPC-Peer oder VPN über eine Sicherheitsgruppe an Amazon VPC IPs weitergeleitet werden, sind zulässig.
19.3 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.
19.4 Ausgehende ICMP-Anfragen von Amazon EC2 an ein beliebiges Ziel sind zulässig.
20.0 Gemeinsame Nutzung von Sicherheitsgruppen
20.1

Wenn eine Sicherheitsgruppe diesen Sicherheitsstandard erfüllt, kann sie von mehreren Mitgliedern VPCs desselben Kontos und von Konten derselben Organisation gemeinsam genutzt werden.

20.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 004 - Penetrationstests

  1. AMS unterstützt keine Pentest-Infrastruktur. Es liegt in der Verantwortung des Kunden. Kali ist beispielsweise keine AMS-unterstützte Linux-Distribution.

  2. Kunden müssen sich an Penetrationstests halten.

  3. AMS muss 24 Stunden im Voraus benachrichtigt werden, falls der Kunde Infrastruktur-Penetrationstests für Konten durchführen möchte.

  4. AMS stellt dem Kunden eine Pentesting-Infrastruktur gemäß den Kundenanforderungen bereit, die ausdrücklich in der Änderungsanfrage oder Serviceanfrage des Kunden angegeben sind.

  5. Das Identitätsmanagement für die Pentesting-Infrastruktur des Kunden liegt in der Verantwortung des Kunden.

Das Folgende ist die Standardsteuerung für 005 - GuardDuty

  1. GuardDuty muss in allen Kundenkonten jederzeit aktiviert sein.

  2. GuardDuty Ergebnisse aus dem Customer Managed Application Account (CMA) in MALZ führen nicht zu Alarmen für das Betriebsteam.

  3. GuardDuty Benachrichtigungen müssen im selben Konto oder in einem anderen verwalteten Konto derselben Organisation gespeichert werden.

  4. 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.

  5. GuardDuty Die Administrator-Delegierung darf in MALZ nicht aktiviert werden, da ein delegierter Administrator in der Lage wäre, Aktionen mit hohen Rechten wie die Deaktivierung der GuardDuty in den anderen Konten durchzuführen, ohne ein Risiko einzugehen.

  6. GuardDuty Automatische Archivierungsfilter sollten den minimalen Bereich für die maximale Rendite verwenden. Wenn AMS beispielsweise mehrere unvorhersehbare Werte IPs in verschiedenen CIDR-Blöcken erkennt und es eine Unternehmens-ASN gibt, die für die Verwendung geeignet ist, verwenden Sie die ASN. Wenn Sie sich jedoch auf bestimmte Bereiche oder /32-Adressen beschränken können, dann sollten Sie sich auf diese Bereiche beschränken.

Im Folgenden finden Sie die Standardsteuerung für 006 - Host Security

  • Ein Antiviren-Agent muss jederzeit auf allen EC2 Instanzen ausgeführt werden. (zum Beispiel Trend Micro DSM).

  • Das Anti-Malware-Modul muss aktiviert sein.

  • Der EPS-Agent muss alle Verzeichnisse und Dateien zum Scannen enthalten.

  • Dateien, die von der Antiviren-Lösung unter Quarantäne gestellt wurden, können bei Bedarf mit Ihnen geteilt werden.

  • Eine Sicherheitslösung für Endgeräte eines Drittanbieters sollte nicht installiert werden.

  • Die Aktualisierungshäufigkeit der Antivirensignaturen muss auf mindestens einmal täglich festgelegt werden.

  • Die geplante Scan-Frequenz muss auf mindestens einmal pro Monat festgelegt werden.

  • Der Echtzeit-Scan (bei Zugriff) muss aktiviert sein und jederzeit ausgeführt werden.

  • AMS darf auf Ihren Instances keine benutzerdefinierten Skripts ausführen, die nicht im Eigentum von AMS stehen oder von AMS erstellt wurden. (Hinweis: Sie können dies tun, indem Sie den Stack-Admin-Zugriff über den Stack-Admin-Zugriff CT oder mithilfe von AWS Systems Manager Automation (AMS SSPS) verwenden.

  • Network Level Authentication (NLA) darf auf dem Windows-Host nicht deaktiviert werden.

  • Das Host-Betriebssystem muss gemäß dem konfigurierten Patch-Zyklus mit den neuesten Sicherheitspatches auf dem neuesten Stand sein.

  • Ein von AMS verwaltetes Konto darf keine nicht verwaltete Instanz im Konto haben.

  • Die Erstellung von lokalen Administratorkonten auf Ihrer Instance durch AMS darf nicht zulässig sein.

  • Das Schlüsselpaar on EC2 darf nicht erstellt werden.

  • Sie dürfen keine Betriebssysteme verwenden, die als „End of Life“ (EOL) deklariert wurden und für die es keinen weiteren Sicherheitssupport durch den Anbieter oder Dritte gibt.

Im Folgenden finden Sie die Standardsteuerung für 007 — 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,6 EPS-Protokolle (Endpoint Protection System): Die Protokollierung der EPS-Lösung muss aktiviert und so konfiguriert sein, dass die Protokolle an eine Logs-Protokollgruppe CloudWatch gesendet werden.
1,7 Anwendungsprotokolle: Kunden können die Protokollierung in ihren Anwendungen aktivieren und sie in einer CloudWatch Protokollgruppe oder 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.1 Sie dürfen keinen Schreib- oder Löschzugriff auf S3-Buckets haben, die von AMS zum Speichern von Protokollen und Logs (Protokollgruppen) benötigt CloudWatch werden.
2.2 Sie müssen nur Lesezugriff auf alle Protokolle in Ihren Konten haben.
2.3 Von AMS vorgeschriebene S3-Buckets, in denen Logs gespeichert werden, dürfen nach den Grundsätzen der Bucket-Richtlinien keine Benutzer von Drittanbieterkonten zulassen.
2.4 CloudWatch Protokolle aus Logs-Protokollgruppen dürfen ohne ausdrückliche Genehmigung Ihres 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 Jegliche 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. Die „Überprüfung der Protokolldatei“ muss in den von den AMS-Teams geforderten AWS CloudTrail Trails konfiguriert werden.
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 nur dann von AMS an ein Nicht-AMS-Konto weitergeleitet werden, wenn das Nicht-AMS-Konto demselben AMS-Kunden gehört.
6.3 Logs von einem Kundenkonto dürfen nicht an ein Drittanbieterkonto weitergeleitet werden (das nicht dem Kunden gehört).

Im Folgenden finden Sie die Standardsteuerung für 008 - AMS-MAD

ID Technischer Standard
1,0 Zugriffsverwaltung
1.1 Nur AMS-privilegierte Benutzer mit interaktiven Anmeldungen und Automatisierungsaufgaben dürfen sich für die Verwaltung von verwaltetem AD in Kundenkonten am Management-Host anmelden.
1.2 AD-Administratoren dürfen nur delegierte Administratorrechte haben (AMS Delegated Administrator Group).
1.3 Techniker, die sich in die AD-Umgebungen des Kunden einloggen (Management-Host oder Instanzen), müssen über einen zeitlich begrenzten Zugriff verfügen.
1.4 Kunden haben mit den Remoteserver-Administratortools in einer EC2 Instanz nur Lesezugriff auf die AD-Objekte.
1.5 Administratorrechte für den Active Directory-Benutzer oder die Active Directory-Gruppe dürfen nicht gewährt werden.
1,6 AWS Die gemeinsame Nutzung von Verzeichnissen mit Personen, die demselben Kunden AWS-Konto gehören, ist mit einer Risikobenachrichtigung zulässig.
2.0 Dienstkonten
2.1 Group Managed Service Accounts (gMSA) müssen überall dort verwendet werden, wo sie von Anwendungen unterstützt werden, und nicht das Standarddienstkonto.
2.2 Alle anderen Servicekonten müssen nach Abschluss des Risikoakzeptanzprozesses erstellt werden.
2.3 AD-Sicherheitsgruppen dürfen nicht wiederverwendet werden, sofern dies nicht ausdrücklich vom Kunden gewünscht wird. Neue AD-Gruppen sollten erstellt werden. Computerobjekte, die Zugriff auf das Dienstkonto anfordern, müssen der neuen Sicherheitsgruppe hinzugefügt werden.
2.4 Alle gMSA-Servicekonten müssen der Organisationseinheit (OU) „Managed Service Account“ hinzugefügt werden.
2.5 Alle Nicht-GMSA-Servicekonten müssen unter der Organisationseinheit „Benutzer→Dienstkonten“ hinzugefügt werden.
3.0 Gruppenrichtlinienobjekte (GPO)
3.1 Alle Einstellungen unter dem Gruppenrichtlinienobjekt „Windows-Einstellungen > Sicherheitseinstellungen“ dürfen nicht geändert werden, wenn dadurch die Sicherheitslage des Kontos gegenüber dem aktuellen Status in irgendeiner Weise beeinträchtigt wird.
3.2 In MALZ muss das GPO, das von einem Anwendungskonto aus RFCs eingereicht wird, das die Erstellung eines Gruppenrichtlinienobjekts anfordert, mit der Organisationseinheit verknüpft sein, die dem App-Konto entspricht. Alle Daten GPOs , die sich auf alle Konten auswirken, müssen aus dem Shared Service-Konto stammen.
3.3 Das standardmäßige Zeitlimit für RDP-Leerlaufsitzungen muss für alle Server unter der Active Directory-Domäne auf 15 Minuten festgelegt werden.
4.0 Active Directory-Vertrauen
4.1 Eine unidirektionale ausgehende Vertrauensstellung (vom AMS gehostetes Verzeichnis zum Kundenverzeichnis) ist zulässig, wenn die IPs bedingten Weiterleitungen über DX, VPC-Peer oder VPN an VPC weitergeleitet werden.
5.0 Andere
5.1 Der Integritätsmechanismus für Protokolldateien muss aktiviert sein. Die „Überprüfung der Protokolldatei“ muss in den von den AMS-Teams geforderten AWS CloudTrail Trails konfiguriert werden.
6.0 Weiterleitung von Protokollen
6.1 Kundenbenutzer, Gruppen, Computerobjekte, OU oder andere Entitäten dürfen die AMS-Namenskonvention nicht gemäß der AMS-Namenskonvention verwenden.
6.2 All dies OUs muss von AMS verwaltet werden.

Im Folgenden finden Sie die Standardsteuerung für 009 - Verschiedenes

  • Wenn die Verschlüsselung in einer Ressource, einem Objekt, einer Datenbank oder einem Dateisystem aktiviert ist, darf sie nicht deaktiviert werden.