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.

Datenschutz in Amazon Security Lake

Das Modell der AWS https://aws.amazon.com/compliance/shared-responsibility-model/ gilt für den Datenschutz in Amazon Security Lake. Wie in diesem Modell beschrieben, AWS ist es für den Schutz der globalen Infrastruktur verantwortlich, auf der das gesamte System läuft 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 in der Region . Weitere Informationen zum Datenschutz in Europa finden Sie im Zentrum für die Datenschutz-Grundverordnung (DSGVO).

Aus Datenschutzgründen empfehlen wir, Ihre AWS-Konto Anmeldeinformationen zu schützen und einzelne Benutzer mit AWS IAM Identity Center oder AWS Identity and Access Management (IAM) einzurichten. 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:

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 AWS-Services über die Konsole, die API oder die SDKs arbeiten. 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 mithilfe von AWS Verschlüsselungslösungen sicher. Rohdaten aus Sicherheitsprotokollen und Ereignissen werden in quellenspezifischen, mandantenfähigen Amazon Simple Storage Service (Amazon S3) -Buckets in einem Konto gespeichert, das Security Lake verwaltet. Jede Protokollquelle hat ihren eigenen Bucket mit mehreren Mandanten. 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 für die Verwendung in mehreren Konten verwaltet. AWS

Security Lake führt ETL-Jobs (Extrahieren, Transformieren und Laden) auf Rohdaten aus Protokoll- und Ereignisdaten aus.

Nach Abschluss der ETL-Jobs erstellt Security Lake S3-Buckets für einen Mandanten in Ihrem Konto (ein Bucket für jeden AWS-Region , in dem Sie Security Lake aktiviert haben). Daten werden nur vorübergehend in den Multi-Tenant-S3-Buckets gespeichert, bis Security Lake die Daten zuverlässig an die Single-Tenant-S3-Buckets liefern kann. Die Single-Tenant-Buckets enthalten 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 S3-managed Verschlüsselungsschlüssel oder einen vom Kunden verwalteten Schlüssel (von) wählen. AWS KMS Beide Optionen verwenden eine symmetrische Verschlüsselung.

Verwenden Sie einen KMS-Schlüssel zur Verschlüsselung Ihrer Daten

Standardmäßig werden die von Security Lake an Ihren S3-Bucket übermittelten Daten durch serverseitige Amazon-Verschlüsselung mit S3-managed Amazon-Verschlüsselungsschlüsseln (SSE-S3) verschlüsselt. Um eine Sicherheitsebene bereitzustellen, die Sie direkt verwalten, können Sie stattdessen die 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. Für die Verwendung SSE-KMS mit der Security Lake-API oder CLI 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 auswählen. Für vom Kunden verwaltete Schlüssel gewährt Security Lake in Ihrem Namen einen Zuschuss, indem eine CreateGrant Anfrage an gesendet wird. 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 Zuschuss, um Ihren vom Kunden verwalteten Schlüssel für die folgenden internen Vorgänge verwenden zu können:

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 Hinweise 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 Standort des Lake Formation Data Lake 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 im AWS Key Management Service Entwicklerhandbuch unter Erstellen einer Schlüsselrichtlinie.

Hängen Sie Ihrem KMS-Schlüssel die folgende Schlüsselrichtlinie an:

{
  "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 sollen mit anderen IAM-Identitäten geteilt werden. Sie ermöglichen es einer benutzerdefinierten Quelle, Daten in den Data Lake zu schreiben, und einem Abonnenten, Daten aus dem Data Lake zu konsumieren. Eine AWS verwaltete Richtlinie namens AmazonSecurityLakePermissionsBoundary legt die Berechtigungsgrenzen für diese Rollen fest.

Verschlüsselung von Amazon 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 standardmäßige serverseitige Verschlüsselung (SSE), die von Amazon Simple Queue Service bereitgestellt wird, reicht nicht aus. Sie müssen einen vom Kunden verwalteten Schlüssel in AWS Key Management Service (AWS KMS) erstellen, um die Warteschlangen zu verschlüsseln, und dann dem Amazon S3-Serviceprinzipal Berechtigungen für die Arbeit mit den verschlüsselten Warteschlangen gewähren. Anweisungen zum Erteilen dieser Berechtigungen finden Sie unter Warum werden Amazon S3-Ereignisbenachrichtigungen nicht an eine Amazon SQS-Warteschlange gesendet, die serverseitige Verschlüsselung verwendet? im AWS Knowledge Center.

Da Security Lake 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-Warteschlangen erteilen. Weitere Informationen finden Sie im Entwicklerhandbuch unter Berechtigungen für https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-permissions Ausführungsrollen. AWS Lambda

Verschlüsselung während der Übertragung

Security Lake verschlüsselt alle Daten bei der Übertragung zwischen AWS Diensten. Security Lake schützt Daten bei der Übertragung zum und vom Dienst, indem alle Netzwerkdaten automatisch mit dem Transport Layer Security (TLS) 1.2-Verschlüsselungsprotokoll 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.