Protection des données dans Amazon Security Lake

Le modèle de responsabilité AWS partagée de s'applique à la protection des données dans Amazon Security Lake. Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez Questions fréquentes (FAQ) sur la confidentialité des données. Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog Modèle de responsabilité partagée AWS et RGPD (Règlement général sur la protection des données) sur le Blog de sécuritéAWS .

À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou AWS Identity and Access Management (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :

• Utilisez l’authentification multifactorielle (MFA) avec chaque compte.

• Utilisez le protocole SSL/TLS pour communiquer avec les ressources. AWS Nous exigeons TLS 1.2 et recommandons TLS 1.3.

• Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail.

• Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS.

• Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.

• Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-2 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS (Federal Information Processing Standard) disponibles, consultez Federal Information Processing Standard (FIPS) 140-2 (Normes de traitement de l’information fédérale).

Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ Name (Nom). Cela inclut lorsque vous travaillez avec Security Lake ou un autre utilisateur Services AWS à l'aide de la console, de l'API ou AWS des SDK. AWS CLI Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.

Chiffrement au repos

Amazon Security Lake stocke vos données au repos en toute sécurité à l'aide de solutions de AWS chiffrement. Les données brutes du journal de sécurité et des événements sont stockées dans un bucket Amazon Simple Storage Service (Amazon S3) multi-tenant dans un compte géré par Security Lake. Security Lake chiffre ces données brutes à l'aide d'une cléAWS détenue par AWS Key Management Service (AWS KMS). AWS les clés détenues sont un ensemble de AWS KMS clés qu'un AWS service (dans ce cas Security Lake) possède et gère pour une utilisation dans plusieurs comptes. AWS

Security Lake exécute des tâches d'extraction, de transformation et de chargement (ETL) sur les données brutes des journaux et des événements. Les données traitées restent cryptées dans le compte de service Security Lake.

Une fois les tâches ETL terminées, Security Lake crée des compartiments S3 à locataire unique dans votre compte (un compartiment pour chacun des compartiments dans Région AWS lesquels vous avez activé Security Lake). Les données ne sont stockées dans le compartiment S3 à locataire multiple que temporairement jusqu'à ce que Security Lake puisse les fournir de manière fiable aux compartiments S3 à locataire unique. Les compartiments à locataire unique incluent une politique basée sur les ressources qui autorise Security Lake à écrire des données de journal et d'événement dans les compartiments. Pour chiffrer les données de votre compartiment S3, vous pouvez choisir une clé de chiffrement gérée par S3 ou une clé gérée par le client (à partir de). AWS KMS Les deux options utilisent le chiffrement symétrique.

Utilisation d'une clé KMS pour le chiffrement de vos données

Par défaut, les données fournies par Security Lake à votre compartiment S3 sont chiffrées par chiffrement côté serveur Amazon avec des clés de chiffrement gérées par Amazon S3 (SSE-S3). Pour fournir une couche de sécurité que vous gérez directement, vous pouvez plutôt utiliser le chiffrement côté serveur avec AWS KMS clés (SSE-KMS) pour vos données Security Lake.

Le SSE-KMS n'est pas pris en charge dans la console Security Lake. Pour utiliser SSE-KMS avec l'API ou la CLI de Security Lake, vous devez d'abord créer une clé KMS ou utiliser une clé existante. Vous attachez une politique à la clé qui détermine quels utilisateurs peuvent utiliser la clé pour chiffrer et déchiffrer les données de Security Lake.

Si vous utilisez une clé gérée par le client pour chiffrer les données écrites dans votre compartiment S3, vous ne pouvez pas choisir une clé multirégionale. Pour les clés gérées par le client, Security Lake crée une subvention en votre nom en envoyant une CreateGrant demande à AWS KMS. Les subventions AWS KMS sont utilisées pour donner à Security Lake l'accès à une clé KMS dans un compte client.

Security Lake a besoin de l'autorisation d'utiliser votre clé gérée par le client pour les opérations internes suivantes :

• Envoyez GenerateDataKey des demandes AWS KMS à pour générer des clés de données chiffrées par votre clé gérée par le client.

• Envoyez vos RetireGrant demandes à AWS KMS. Lorsque vous mettez à jour votre lac de données, cette opération permet de retirer la subvention qui a été ajoutée à la clé AWS KMS pour le traitement ETL.

Security Lake n'a pas besoin d'Decryptautorisations. Lorsque les utilisateurs autorisés de la clé lisent les données de Security Lake, S3 gère le déchiffrement et les utilisateurs autorisés peuvent lire les données sous forme non cryptée. Toutefois, un abonné a besoin Decrypt d'autorisations pour utiliser les données sources. Pour plus d'informations sur les autorisations des abonnés, consultezGestion de l'accès aux données pour les abonnés de Security Lake.

Si vous souhaitez utiliser une clé KMS existante pour chiffrer les données de Security Lake, vous devez modifier la politique de clé pour la clé KMS. La politique clé doit autoriser le rôle IAM associé à l'emplacement du lac de données de Lake Formation à utiliser la clé KMS pour déchiffrer les données. Pour savoir comment modifier la politique clé d'une clé KMS, consultez la section Modification d'une politique clé dans le manuel du AWS Key Management Service développeur.

Votre clé KMS peut accepter des demandes de subvention, ce qui permet à Security Lake d'accéder à la clé, lorsque vous créez une politique clé ou que vous utilisez une politique clé existante avec les autorisations appropriées. Pour obtenir des instructions sur la création d'une politique clé, consultez la section Création d'une politique clé dans le Guide du AWS Key Management Service développeur.

Associez la politique clé suivante à votre clé KMS :

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

Autorisations IAM requises pour l'utilisation d'une clé gérée par le client

Consultez la section Mise en route : conditions préalables pour obtenir un aperçu des rôles IAM que vous devez créer pour utiliser Security Lake.

Lorsque vous ajoutez une source personnalisée ou un abonné, Security Lake crée des rôles IAM dans votre compte. Ces rôles sont destinés à être partagés avec d'autres identités IAM. Ils permettent à une source personnalisée d'écrire des données dans le lac de données et à un abonné de consommer les données du lac de données. Une politique AWS gérée appelée AmazonSecurityLakePermissionsBoundary définit les limites d'autorisation pour ces rôles.

Chiffrement des files d'attente Amazon SQS

Lorsque vous créez votre lac de données, Security Lake crée deux files d'attente Amazon Simple Queue Service (Amazon SQS) non chiffrées dans le compte administrateur délégué de Security Lake. Vous devez chiffrer ces files d'attente pour protéger vos données. Le chiffrement côté serveur (SSE) par défaut fourni par Amazon Simple Queue Service n'est pas suffisant. Vous devez créer une clé gérée par le client dans AWS Key Management Service (AWS KMS) pour chiffrer les files d'attente et accorder au service Amazon S3 les autorisations principales pour travailler avec les files d'attente chiffrées. Pour obtenir des instructions sur l'octroi de ces autorisations, consultez Pourquoi les notifications d'événements Amazon S3 ne sont-elles pas envoyées à une file d'attente Amazon SQS qui utilise le chiffrement côté serveur ? dans le AWS Knowledge Center.

Étant donné que Security Lake prend AWS Lambda en charge les tâches d'extraction, de transfert et de chargement (ETL) sur vos données, vous devez également accorder à Lambda des autorisations pour gérer les messages dans vos files d'attente Amazon SQS. Pour plus d'informations, consultez la section Autorisations relatives aux rôles d'exécution dans le Guide du AWS Lambda développeur.

Chiffrement en transit

Security Lake chiffre toutes les données en transit entre les AWS services. Security Lake protège les données en transit, lorsqu'elles sont acheminées vers et depuis le service, en chiffrant automatiquement toutes les données interréseaux à l'aide du protocole de cryptage TLS (Transport Layer Security) 1.2. Les demandes HTTPS directes envoyées aux API de Security Lake sont signées à l'aide de l'algorithme AWS Signature version 4 pour établir une connexion sécurisée.