Sicherheit und Compliance - 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.

Sicherheit und Compliance

Für Sicherheit und Compliance sind AMS Advanced und Sie als unser Kunde gemeinsam verantwortlich. Der AMS Advanced Direct Change-Modus ändert nichts an dieser gemeinsamen Verantwortung.

Sicherheit im Direct Change-Modus

AMS Advanced bietet zusätzlichen Mehrwert mit einer präskriptiven landing zone, einem Change-Management-System und einer Zugriffsverwaltung. Bei Verwendung des Direct Change-Modus ändert sich dieses Verantwortungsmodell nicht. Sie sollten sich jedoch zusätzlicher Risiken bewusst sein.

Die Rolle „Update“ im Direktänderungsmodus (sieheIAM-Rollen und -Richtlinien im Direktänderungsmodus) bietet erweiterte Berechtigungen, sodass die Entität, die Zugriff darauf hat, Änderungen an den Infrastrukturressourcen der von AMS unterstützten Dienste in Ihrem Konto vornehmen kann. Bei erhöhten Berechtigungen bestehen je nach Ressource, Service und Aktion unterschiedliche Risiken, insbesondere in Situationen, in denen aufgrund eines Versehens, eines Fehlers oder der mangelnden Einhaltung Ihres internen Prozess- und Kontrollrahmens eine falsche Änderung vorgenommen wird.

Gemäß den technischen Standards von AMS wurden die folgenden Risiken identifiziert, und es werden folgende Empfehlungen ausgesprochen. Detaillierte Informationen zu den technischen Standards von AMS finden Sie unter AWS Artifact. Um darauf zuzugreifen AWS Artifact, wenden Sie sich an Ihren CSDM, um Anweisungen zu erhalten, oder gehen Sie zu Erste Schritte mit AWS Artifact.

AMS-STD-001: Taggen

Normen Geht es kaputt Risiken Empfehlungen
Alle AMS-eigenen Ressourcen müssen das folgende Schlüssel-Wert-Paar haben

Ja. Unterbrechungen für CloudFormation,CloudTrail, EFS, OpenSearch, CloudWatch Logs, SQS, SSM, Tagging-API — da diese Dienste die aws:TagsKey Bedingung, das Tagging für den AMS-Namespace einzuschränken, nicht unterstützen.

Der in der folgenden Tabelle AMS-STD-003 angegebene Standard besagt, dass Sie die Umgebung und ändern AppId können, aber nicht für AMS-eigene Ressourcen. AppName Mit IAM-Berechtigungen nicht erreichbar.

Eine falsche Kennzeichnung von AMS-Ressourcen kann sich nachteilig auf die Berichts-, Warnungs- und Patching-Vorgänge Ihrer Ressourcen auf AMS-Seite auswirken. Der Zugriff muss eingeschränkt werden, um Änderungen an den standardmäßigen AMS-Tagging-Anforderungen für andere Personen als AMS-Teams vorzunehmen.
Alle AMS-eigenen Tags, mit Ausnahme der oben aufgeführten, müssen Präfixe wie oder in case haben. AMS* MC* upper/lower/mix
Alle Tags in AMS-eigenen Stacks dürfen aufgrund Ihrer Änderungsanforderungen nicht gelöscht werden. Ja. CloudFormation unterstützt nicht die aws:TagsKey Bedingung, Tags für den AMS-Namespace einzuschränken.
Es ist Ihnen nicht gestattet, die AMS-Tag-Namenskonvention in Ihrer Infrastruktur zu verwenden, wie in Tabelle AMS-STD-002, weiter unten beschrieben. Ja. Unterbrechungen für CloudFormation, CloudTrail, Amazon Elastic File System (EFS), OpenSearch, CloudWatch Logs, Amazon Simple Queue Service (SQS), Amazon EC2 Systems Manager (SSM), Tagging API; diese Dienste unterstützen nicht die aws:TagsKey Bedingung, das Tagging für den AMS-Namespace einzuschränken.

AMS-STD-002: Identity and Access Management (IAM)

Normen Geht es kaputt Risiken Empfehlungen
4.7 Aktionen, die den Change Management Process (RFC) umgehen, dürfen nicht erlaubt sein, wie z. B. das Starten oder Stoppen einer Instance, das Erstellen von S3-Buckets oder RDS-Instances usw. Konten im Entwicklermodus und Dienste im Self-Service Provisioned Mode (SSPS) sind ausgenommen, solange die Aktionen innerhalb der Grenzen der zugewiesenen Rolle ausgeführt werden.

Ja. Der Zweck von Self-Service-Aktionen ermöglicht es Ihnen, Aktionen unter Umgehung des AMS-RFC-Systems durchzuführen.

Das Modell des sicheren Zugriffs ist ein zentraler technischer Aspekt von AMS, und ein IAM-Benutzer für Konsolen- oder programmatischen Zugriff umgeht diese Zugriffskontrolle. Der Zugriff der IAM-Benutzer wird nicht vom AMS Change Management überwacht. Der Zugriff ist CloudTrail nur angemeldet. Der IAM-Benutzer sollte zeitlich begrenzt sein und ihm sollten Berechtigungen auf der Grundlage der geringsten Rechte und erteilt werden. need-to-know

AMS-STD-003: Netzwerksicherheit

Standards Geht es kaputt Risiken Empfehlungen
S2. Elastic IP auf EC2 Instances darf nur mit einer formellen Risikoakzeptanzvereinbarung oder mit einem gültigen Anwendungsfall durch interne Teams verwendet werden.

Ja. Self-Service-Aktionen ermöglichen es Ihnen, Elastic IP-Adressen (EIP) zuzuordnen und die Zuordnung aufzuheben.

Durch das Hinzufügen einer Elastic IP zu einer Instance wird sie dem Internet zugänglich gemacht. Dies erhöht das Risiko der Offenlegung von Informationen und unberechtigter Aktivitäten. Blockieren Sie jeglichen unnötigen Datenverkehr zu dieser Instance über Sicherheitsgruppen und stellen Sie sicher, dass Ihre Sicherheitsgruppen mit der Instance verknüpft sind, um sicherzustellen, dass der Datenverkehr nur dann zugelassen wird, wenn er aus geschäftlichen Gründen benötigt wird.
S14. VPC-Peering und Endpunktverbindungen zwischen Konten, die demselben Kunden gehören, können zugelassen werden.

Ja. Dies ist im Rahmen der IAM-Richtlinie nicht möglich.

Der Datenverkehr, der Ihr AMS-Konto verlässt, wird nicht überwacht, sobald er die Kontogrenze überschreitet. Wir empfehlen, nur mit AMS-Konten zu peeren, die Sie besitzen. Wenn Ihr Anwendungsfall dies erfordert, verwenden Sie Sicherheitsgruppen und Routingtabellen, um zu begrenzen, welche Datenverkehrsbereiche, Ressourcen und Typen über die entsprechende Verbindung abfließen können.
Die AMS-Basis AMIs kann von AMS-verwalteten und nicht verwalteten Konten gemeinsam genutzt werden, sofern wir überprüfen können, ob sie derselben Organisation gehören. AWS AMIs kann sensible Daten enthalten und unbeabsichtigten Konten ausgesetzt sein. Teilen Sie die Daten nur AMIs mit dem Konto, das Ihrer Organisation gehört, oder überprüfen Sie den Anwendungsfall und die Kontoinformationen, bevor Sie sie an Dritte weitergeben.

AMS-STD-007: Protokollierung

Normen Geht es kaputt Risiken Empfehlungen
19. Jedes Protokoll kann von einem AMS-Konto an ein anderes AMS-Konto desselben Kunden weitergeleitet werden.

Ja. Mögliche Unsicherheiten in Bezug auf Kundenprotokolle, da die Überprüfung, ob sich die Kundenkonten in derselben Organisation befinden, nicht durch die IAM-Richtlinie erreicht werden kann.

Protokolle können vertrauliche Daten enthalten und sie können unbefugten Konten zugänglich gemacht werden. Teilen Sie Protokolle nur mit Konten, die von Ihrer AWS Organisation verwaltet werden, oder überprüfen Sie den Anwendungsfall und die Kontoinformationen, bevor Sie sie an Dritte weitergeben. Wir können dies auf verschiedene Weise überprüfen. Erkundigen Sie sich bei Ihrem Cloud Service Delivery Manager (CSDM).
20. Jedes Protokoll kann 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 sie sich unter demselben AWS Organizations Konto befinden, oder indem die E-Mail-Domain mit dem Firmennamen des Kunden und dem mit PAYER verknüpften Konto abgeglichen wird). Dabei werden interne Tools verwendet.

Arbeiten Sie mit Ihrem internen Autorisierungs- und Authentifizierungsteam zusammen, um die Berechtigungen für die Rollen im Direct Change-Modus entsprechend zu kontrollieren.

Einhaltung der Vorschriften im Modus „Direkter Wandel“

Der Direct Change-Modus ist sowohl mit produktiven als auch mit produktionsfremden Workloads kompatibel. Es liegt in Ihrer Verantwortung, die Einhaltung aller Compliance-Standards (z. B. PHI, HIPAA, PCI) sicherzustellen und sicherzustellen, dass die Verwendung des Direct Change-Modus Ihren internen Kontrollrahmen und Standards entspricht.