Protection des données dans Amazon Security Lake

Le modèle de responsabilitéAWS partagée modèle de de de responsabilité partagée s'applique à la protection des données dans Amazon Security Lake. Comme décrit dans ce modèle, AWS est responsable de la protection de l'infrastructure globale sur laquelle l'ensemble du AWS Cloud s'exécute. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Ce contenu comprend les tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour en savoir plus 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 AWSet RGPD (Règlement général sur la protection des données) sur le AWSBlog de sécurité.

À des fins de protection des données, nous vous recommandons de protéger les informations d'identification Compte AWS et de configurer les comptes utilisateur individuels avec AWS IAM Identity Center (successor to AWS Single Sign-On) 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 les certificats SSL/TLS pour communiquer avec les ressources AWS. Nous avons besoin du TLS 1.2 et recommandons TLS 1.3.

• Configurez une API (Interface de programmation) et le journal de l'activité des utilisateurs avec AWS CloudTrail.

• Utilisez des solutions de chiffrement AWS, ainsi que tous les contrôles de sécurité par défaut au sein des 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 FIPS (Federal Information Processing Standard) 140-2 lorsque vous accédez à AWS via une CLI (Interface de ligne de commande) ou une API (Interface de programmation), utilisez un point de terminaison FIPS (Federal Information Processing Standard). Pour en savoir plus 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 s'applique aussi lorsque vous utilisez Security Lake ou d'autres services àServices AWS l'aide de la console, de l'APIAWS CLI, de la ouAWS des SDK. Toutes les données que vous saisissez 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 deAWS cryptage. Les données brutes des journaux de sécurité et des événements sont stockées dans un compartiment Amazon Simple Storage Service (Amazon S3) à plusieurs comptes gérés par Security Lake. Security Lake chiffre ces données brutes à l'aide d'une cléAWS appartenant àAWS Key Management Service (AWS KMS). AWSLes clés détenues par unAWS service, dans ce cas Security Lake, possède et gère pour une utilisation dans plusieursAWS comptes.AWS KMS

Security Lake exécute des tâches d'extraction, de transformation et de chargement (ETL) sur des données de journaux et d'événements brutes. Les données traitées restent cryptées sur 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 chaque compartiment dansRégion AWS lequel vous avez activé Security Lake). Les données ne sont stockées que temporairement dans le compartiment S3 mutualisé jusqu'à ce que Security Lake puisse les transmettre 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énements dans les compartiments. Pour crypter 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 deAWS KMS). Les deux options utilisent un cryptage symétrique.

Utilisation d'une clé KMS pour chiffrer vos données

Par défaut, les données livrées par Security Lake à votre compartiment S3 sont chiffrées par Amazon côté serveur 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 utiliser le chiffrement côté serveur avec desAWS KMS clés (SSE-KMS) pour vos données Security Lake.

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 crypter les données écrites dans votre compartiment S3, vous ne pouvez pas choisir une clé multirégion. Pour les clés gérées par le client, Security Lake crée une subvention en votre nom en envoyant uneCreateGrant demande àAWS KMS. AWS KMSLes octrois dans sont utilisés pour accorder à Security Lake l'accès à une clé KMS dans un compte client.

Security Lake requiert l'octroi d'utiliser votre clé gérée par le client pour les opérations internes suivantes :

• EnvoyezGenerateDataKey des demandesAWS KMS à pour générer des clés de données cryptées par votre clé gérée par le client.

• EnvoyezRetireGrant des 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 sont capables de lire les données sous forme non chiffrée. Toutefois, un abonné a besoinDecrypt d'autorisations pour consommer 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 à Security Lake.

Votre clé KMS peut accepter des demandes d'autorisation, ce qui permet à Security Lake d'accéder à la clé lorsque vous créez une politique de clé ou que vous utilisez une politique de 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 stratégie clé dans le Guide duAWS Key Management Service développeur. Attachez la stratégie de 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 une vue d'ensemble 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 politiqueAWS gérée appeléeAmazonSecurityLakePermissionsBoundary définit les limites d'autorisation pour ces rôles.

Chiffrement en transit

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