Datenschutz in Amazon Security Lake

Das AWS Modell der mit gilt für den Datenschutz in Amazon Security Lake. Wie in diesem Modell beschrieben, AWS ist verantwortlich für den Schutz der globalen Infrastruktur, auf der alle Systeme laufen AWS Cloud. Sie sind dafür verantwortlich, die Kontrolle über Ihre in dieser Infrastruktur gehosteten Inhalte zu behalten. Sie sind auch für die Sicherheitskonfiguration und die Verwaltungsaufgaben für die von Ihnen verwendeten AWS-Services verantwortlich. Weitere Informationen zum Datenschutz finden Sie unter Häufig gestellte Fragen zum Datenschutz. Informationen zum Datenschutz in Europa finden Sie im Blog-Beitrag AWS -Modell der geteilten Verantwortung und in der DSGVO im AWS -Sicherheitsblog.

Aus Datenschutzgründen empfehlen wir, dass Sie AWS-Konto Anmeldeinformationen schützen und einzelne Benutzer mit AWS IAM Identity Center oder AWS Identity and Access Management (IAM) einrichten. So erhält jeder Benutzer nur die Berechtigungen, die zum Durchführen seiner Aufgaben erforderlich sind. Außerdem empfehlen wir, die Daten mit folgenden Methoden schützen:

• Verwenden Sie für jedes Konto die Multi-Faktor-Authentifizierung (MFA).

• Verwenden Sie SSL/TLS, um mit Ressourcen zu kommunizieren. AWS Wir benötigen TLS 1.2 und empfehlen TLS 1.3.

• Richten Sie die API und die Protokollierung von Benutzeraktivitäten mit ein. AWS CloudTrail

• Verwenden Sie AWS Verschlüsselungslösungen zusammen mit allen darin enthaltenen Standardsicherheitskontrollen AWS-Services.

• Verwenden Sie erweiterte verwaltete Sicherheitsservices wie Amazon Macie, die dabei helfen, in Amazon S3 gespeicherte persönliche Daten zu erkennen und zu schützen.

• Wenn Sie für den Zugriff AWS über eine Befehlszeilenschnittstelle oder eine API FIPS 140-2-validierte kryptografische Module benötigen, verwenden Sie einen FIPS-Endpunkt. Weitere Informationen über verfügbare FIPS-Endpunkte finden Sie unter Federal Information Processing Standard (FIPS) 140-2.

Wir empfehlen dringend, in Freitextfeldern, z. B. im Feld Name, keine vertraulichen oder sensiblen Informationen wie die E-Mail-Adressen Ihrer Kunden einzugeben. Dies gilt auch, wenn Sie mit Security Lake oder anderen Geräten arbeiten und die Konsole, die API oder SDKs AWS-Services verwenden. AWS CLI AWS Alle Daten, die Sie in Tags oder Freitextfelder eingeben, die für Namen verwendet werden, können für Abrechnungs- oder Diagnoseprotokolle verwendet werden. Wenn Sie eine URL für einen externen Server bereitstellen, empfehlen wir dringend, keine Anmeldeinformationen zur Validierung Ihrer Anforderung an den betreffenden Server in die URL einzuschließen.

Verschlüsselung im Ruhezustand

Amazon Security Lake speichert Ihre Daten im Ruhezustand sicher mithilfe von AWS Verschlüsselungslösungen. Unformatierte Sicherheitsprotokoll- und Ereignisdaten werden in einem Amazon Simple Storage Service (Amazon S3) -Bucket mit mehreren Mandanten in einem Konto gespeichert, das von Security Lake verwaltet wird. Security Lake verschlüsselt diese Rohdaten mit einem AWS eigenen Schlüssel von AWS Key Management Service ()AWS KMS. AWS Eigene Schlüssel sind eine Sammlung von AWS KMS Schlüsseln, die ein AWS Dienst — in diesem Fall Security Lake — besitzt und verwaltet, sodass sie in mehreren Konten verwendet werden können. AWS

Security Lake führt ETL-Jobs (Extrahieren, Transformieren und Laden) für rohe Protokoll- und Ereignisdaten aus. Die verarbeiteten Daten bleiben im Security Lake-Dienstkonto verschlüsselt.

Nach Abschluss der ETL-Jobs erstellt Security Lake S3-Buckets mit einem Mandanten in Ihrem Konto (ein Bucket für jeden Bucket AWS-Region , in dem Sie Security Lake aktiviert haben). Daten werden nur vorübergehend im Multi-Tenant-S3-Bucket gespeichert, bis Security Lake die Daten zuverlässig an die Single-Tenant-S3-Buckets liefern kann. Die Single-Tenant-Buckets beinhalten eine ressourcenbasierte Richtlinie, die Security Lake die Erlaubnis erteilt, Protokoll- und Ereignisdaten in die Buckets zu schreiben. Um Daten in Ihrem S3-Bucket zu verschlüsseln, können Sie entweder einen von S3 verwalteten Verschlüsselungsschlüssel oder einen vom Kunden verwalteten Schlüssel (von) wählen. AWS KMS Beide Optionen verwenden symmetrische Verschlüsselung.

Verwenden Sie einen KMS-Schlüssel für die Verschlüsselung Ihrer Daten

Standardmäßig werden die von Security Lake an Ihren S3-Bucket übermittelten Daten durch serverseitige Amazon-Verschlüsselung mit von Amazon S3 verwalteten Verschlüsselungsschlüsseln (SSE-S3) verschlüsselt. Um eine Sicherheitsebene bereitzustellen, die Sie direkt verwalten, können Sie stattdessen serverseitige Verschlüsselung mit AWS KMS Schlüsseln (SSE-KMS) für Ihre Security Lake-Daten verwenden.

SSE-KMS wird in der Security Lake-Konsole nicht unterstützt. Um SSE-KMS mit der Security Lake API oder CLI zu verwenden, erstellen Sie zunächst einen KMS-Schlüssel oder verwenden einen vorhandenen Schlüssel. Sie fügen dem Schlüssel eine Richtlinie hinzu, die festlegt, welche Benutzer den Schlüssel zum Verschlüsseln und Entschlüsseln von Security Lake-Daten verwenden können.

Wenn Sie einen vom Kunden verwalteten Schlüssel verwenden, um Daten zu verschlüsseln, die in Ihren S3-Bucket geschrieben werden, können Sie keinen Schlüssel für mehrere Regionen wählen. Für vom Kunden verwaltete Schlüssel gewährt Security Lake in Ihrem Namen einen Zuschuss, indem es eine CreateGrant Anfrage an sendet. AWS KMS Grants in AWS KMS werden verwendet, um Security Lake Zugriff auf einen KMS-Schlüssel in einem Kundenkonto zu gewähren.

Security Lake benötigt den Grant, um Ihren vom Kunden verwalteten Schlüssel für die folgenden internen Operationen zu verwenden:

• Senden Sie GenerateDataKey Anfragen AWS KMS zur Generierung von Datenschlüsseln, die mit Ihrem vom Kunden verwalteten Schlüssel verschlüsselt sind.

• Senden Sie RetireGrant Anfragen an AWS KMS. Wenn Sie Ihren Data Lake aktualisieren, ermöglicht dieser Vorgang die Außerbetriebnahme des Zuschusses, der dem AWS KMS KMS-Schlüssel für die ETL-Verarbeitung hinzugefügt wurde.

Security Lake benötigt keine Decrypt Berechtigungen. Wenn autorisierte Benutzer des Schlüssels Security Lake-Daten lesen, verwaltet S3 die Entschlüsselung, und die autorisierten Benutzer können Daten in unverschlüsselter Form lesen. Ein Abonnent benötigt jedoch Decrypt Berechtigungen, um Quelldaten nutzen zu können. Weitere Informationen zu Abonnentenberechtigungen finden Sie unterVerwaltung des Datenzugriffs für Security Lake-Abonnenten.

Wenn Sie einen vorhandenen KMS-Schlüssel zum Verschlüsseln von Security Lake-Daten verwenden möchten, müssen Sie die Schlüsselrichtlinie für den KMS-Schlüssel ändern. Die Schlüsselrichtlinie muss es der IAM-Rolle, die dem Data Lake-Standort Lake Formation zugeordnet ist, ermöglichen, den KMS-Schlüssel zum Entschlüsseln der Daten zu verwenden. Anweisungen dazu, wie Sie die Schlüsselrichtlinie für einen KMS-Schlüssel ändern können, finden Sie unter Ändern einer Schlüsselrichtlinie im AWS Key Management Service Entwicklerhandbuch.

Ihr KMS-Schlüssel kann Zuschussanfragen annehmen, sodass Security Lake auf den Schlüssel zugreifen kann, wenn Sie eine Schlüsselrichtlinie erstellen oder eine vorhandene Schlüsselrichtlinie mit den entsprechenden Berechtigungen verwenden. Anweisungen zum Erstellen einer Schlüsselrichtlinie finden Sie unter Erstellen einer Schlüsselrichtlinie im AWS Key Management Service Entwicklerhandbuch.

Fügen Sie Ihrem KMS-Schlüssel die folgende Schlüsselrichtlinie hinzu:

{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/ExampleRole"}
  "Action": [
    "kms:CreateGrant",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Erforderliche IAM-Berechtigungen bei Verwendung eines vom Kunden verwalteten Schlüssels

Im Abschnitt Erste Schritte: Voraussetzungen finden Sie einen Überblick über die IAM-Rollen, die Sie für die Verwendung von Security Lake erstellen müssen.

Wenn Sie eine benutzerdefinierte Quelle oder einen Abonnenten hinzufügen, erstellt Security Lake IAM-Rollen in Ihrem Konto. Diese Rollen sind für die gemeinsame Nutzung mit anderen IAM-Identitäten vorgesehen. Sie ermöglichen es einer benutzerdefinierten Quelle, Daten in den Data Lake zu schreiben, und einem Abonnenten, Daten aus dem Data Lake zu nutzen. Eine AWS verwaltete Richtlinie namens AmazonSecurityLakePermissionsBoundary legt die Berechtigungsgrenzen für diese Rollen fest.

Verschlüsseln von Amazon SQS SQS-Warteschlangen

Wenn Sie Ihren Data Lake erstellen, erstellt Security Lake zwei unverschlüsselte Amazon Simple Queue Service (Amazon SQS) -Warteschlangen im delegierten Security Lake-Administratorkonto. Sie sollten diese Warteschlangen verschlüsseln, um Ihre Daten zu schützen. Die von Amazon Simple Queue Service bereitgestellte standardmäßige serverseitige Verschlüsselung (SSE) ist nicht ausreichend. Sie müssen in AWS Key Management Service (AWS KMS) einen vom Kunden verwalteten Schlüssel erstellen, um die Warteschlangen zu verschlüsseln, und dann dem Amazon S3-Serviceprinzipal die Rechte zur Arbeit mit den verschlüsselten Warteschlangen gewähren. Anweisungen zur Erteilung dieser Berechtigungen finden Sie unter Warum werden Amazon S3 S3-Ereignisbenachrichtigungen nicht an eine Amazon SQS SQS-Warteschlange gesendet, die serverseitige Verschlüsselung verwendet? im AWS Knowledge Center.

Da Security Lake früher AWS Lambda ETL-Jobs (Extrahieren, Übertragen und Laden) für Ihre Daten unterstützt, müssen Sie Lambda auch Berechtigungen zur Verwaltung von Nachrichten in Ihren Amazon SQS SQS-Warteschlangen erteilen. Weitere Informationen finden Sie unter Berechtigungen für Ausführungsrollen im Entwicklerhandbuch.AWS Lambda

Verschlüsselung während der Übertragung

Security Lake verschlüsselt alle Daten, die zwischen AWS Diensten übertragen werden. Security Lake schützt Daten während der Übertragung zum und vom Dienst, indem alle Daten zwischen Netzwerken automatisch mit dem Verschlüsselungsprotokoll Transport Layer Security (TLS) 1.2 verschlüsselt werden. Direkte HTTPS-Anfragen, die an die Security Lake-APIs gesendet werden, werden mithilfe des AWS Signature Version 4-Algorithmus signiert, um eine sichere Verbindung herzustellen.