Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Collecte de données auprès de AWS services
Amazon Security Lake peut collecter des journaux et des événements à partir des sites suivants pris en charge de manière native : AWS services
-
AWS CloudTrail événements de gestion et de données (S3, Lambda)
-
Journaux d'audit Amazon Elastic Kubernetes Service (Amazon EKS)
-
Journaux de requête Amazon Route 53 Resolver
-
AWS Security Hub résultats
-
Journaux de flux Amazon Virtual Private Cloud (Amazon VPC)
-
AWS WAF journaux v2
Security Lake transforme automatiquement ces données au Cadre de schéma de cybersécurité ouvert (OCSF) format Apache Parquet.
Astuce
Pour ajouter un ou plusieurs des services précédents en tant que source de journal dans Security Lake, il n'est pas nécessaire de configurer séparément la connexion à ces services, à l'exception CloudTrail des événements de gestion. Si la journalisation est configurée dans ces services, vous n'avez pas besoin de modifier votre configuration de journalisation pour les ajouter en tant que sources de journalisation dans Security Lake. Security Lake extrait les données directement de ces services par le biais d'un flux d'événements indépendant et dupliqué.
Prérequis : vérifier les autorisations
Pour ajouter un en AWS service tant que source dans Security Lake, vous devez disposer des autorisations nécessaires. Vérifiez que la politique AWS Identity and Access Management (IAM) attachée au rôle que vous utilisez pour ajouter une source est autorisée à effectuer les actions suivantes :
-
glue:CreateDatabase
-
glue:CreateTable
-
glue:GetDatabase
-
glue:GetTable
-
glue:UpdateTable
iam:CreateServiceLinkedRole
s3:GetObject
s3:PutObject
Il est recommandé que le rôle réponde aux conditions et à l'étendue des ressources suivantes pour les s3:PutObject
autorisations S3:getObject
et.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowUpdatingSecurityLakeS3Buckets", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::aws-security-data-lake*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ] }
Ces actions vous permettent de collecter des journaux et des événements à partir de l'an AWS service et de les envoyer à la AWS Glue base de données et à la table appropriées.
Si vous utilisez une AWS KMS clé pour le chiffrement côté serveur de votre lac de données, vous devez également obtenir une autorisation pour. kms:DescribeKey
CloudTrail journaux d'événements
AWS CloudTrail vous fournit un historique des appels d' AWS API pour votre compte, y compris les appels d'API effectués à l' AWS Management Console aide AWS des SDK, des outils de ligne de commande et de certains AWS services. CloudTrail vous permet également d'identifier les utilisateurs et les comptes appelés AWS API pour les services pris en charge CloudTrail, l'adresse IP source à partir de laquelle les appels ont été effectués et la date des appels. Pour plus d’informations, consultez le Guide de l’utilisateur AWS CloudTrail.
Security Lake peut collecter les journaux associés aux événements CloudTrail de gestion et aux événements de CloudTrail données pour S3 et Lambda. CloudTrail les événements de gestion, les événements de données S3 et les événements de données Lambda sont trois sources distinctes dans Security Lake. Par conséquent, ils ont des valeurs différentes sourceName
lorsque vous ajoutez l'un d'entre eux en tant que source de journal ingérée. Les événements de gestion, également appelés événements du plan de contrôle, fournissent un aperçu des opérations de gestion effectuées sur les ressources de votre entreprise Compte AWS. CloudTrail les événements de données, également appelés opérations du plan de données, indiquent les opérations de ressources effectuées sur ou au sein des ressources de votre Compte AWS. Ces opérations sont souvent des activités à volume élevé.
Pour collecter les événements CloudTrail de gestion dans Security Lake, vous devez disposer d'au moins un journal d'organisation CloudTrail multirégional qui collecte les événements de CloudTrail gestion en lecture et en écriture. La journalisation doit être activée pour le parcours. Si la journalisation est configurée dans les autres services, vous n'avez pas besoin de modifier votre configuration de journalisation pour les ajouter en tant que sources de journalisation dans Security Lake. Security Lake extrait les données directement de ces services par le biais d'un flux d'événements indépendant et dupliqué.
Un suivi multirégional fournit des fichiers journaux provenant de plusieurs régions vers un seul compartiment Amazon Simple Storage Service (Amazon S3) pour un seul. Compte AWS Si vous avez déjà un parcours multirégional géré via CloudTrail la console AWS Control Tower, aucune autre action n'est requise.
Pour plus d'informations sur la création et la gestion d'un parcours de CloudTrail suivi, consultez la section Création d'un parcours pour une organisation dans le guide de AWS CloudTrail l'utilisateur.
-
Pour plus d'informations sur la création et la gestion d'un parcours de AWS Control Tower suivi, consultez la section Journalisation des AWS Control Tower actions AWS CloudTrail dans le guide de AWS Control Tower l'utilisateur.
Lorsque vous ajoutez CloudTrail des événements en tant que source, Security Lake commence immédiatement à collecter vos journaux CloudTrail d'événements. Il consomme les événements CloudTrail de gestion et de données directement CloudTrail par le biais d'un flux d'événements indépendant et dupliqué.
Security Lake ne gère pas vos CloudTrail événements et n'affecte pas vos CloudTrail configurations existantes. Pour gérer directement l'accès et la rétention de vos CloudTrail événements, vous devez utiliser la console CloudTrail de service ou l'API. Pour plus d'informations, consultez la section Affichage des événements avec l'historique des CloudTrail événements dans le Guide de AWS CloudTrail l'utilisateur.
La liste suivante fournit des liens de GitHub référentiel vers la référence de mappage expliquant comment Security Lake normalise les CloudTrail événements par rapport à OCSF.
GitHub Référentiel OCSF pour les événements CloudTrail
-
Version 1 de la source (v1.0.0-rc.2
) -
Version 2 de la source (v1.1.0
)
Journaux d'audit Amazon EKS
Lorsque vous ajoutez les journaux d'audit Amazon EKS en tant que source, Security Lake commence à collecter des informations détaillées sur les activités effectuées sur les ressources Kubernetes exécutées dans vos clusters Elastic Kubernetes Service (EKS). Les journaux d'audit EKS vous aident à détecter les activités potentiellement suspectes dans vos clusters EKS au sein d'Amazon Elastic Kubernetes Service.
Security Lake utilise les événements du journal d'audit EKS directement depuis la fonction de journalisation du plan de contrôle Amazon EKS via un flux indépendant et duplicatif de journaux d'audit. Ce processus est conçu pour ne pas nécessiter de configuration supplémentaire ni affecter les configurations de journalisation du plan de contrôle Amazon EKS existantes que vous pourriez avoir. Pour plus d'informations, consultez la section Connexion au plan de contrôle Amazon EKS dans le guide de l'utilisateur Amazon EKS.
Les journaux d'audit Amazon EKS ne sont pris en charge que dans OCSF v1.1.0. Pour plus d'informations sur la façon dont Security Lake normalise les événements EKS Audit Logs en OCSF, consultez la référence de mappage dans le référentiel GitHub OCSF pour les événements Amazon EKS Audit Logs (
Journaux de requête Route 53 Resolver
Les journaux de requêtes du résolveur Route 53 suivent les requêtes DNS effectuées par les ressources de votre Amazon Virtual Private Cloud (Amazon VPC). Cela vous permet de comprendre le fonctionnement de vos applications et de détecter les menaces de sécurité.
Lorsque vous ajoutez les journaux de requêtes du résolveur Route 53 en tant que source dans Security Lake, Security Lake commence immédiatement à collecter vos journaux de requêtes du résolveur directement depuis Route 53 via un flux d'événements indépendant et dupliqué.
Security Lake ne gère pas vos journaux Route 53 et n'affecte pas les configurations existantes de journalisation des requêtes de votre résolveur. Pour gérer les journaux de requêtes du résolveur, vous devez utiliser la console de service Route 53. Pour plus d'informations, consultez la section Gestion des configurations de journalisation des requêtes du résolveur dans le manuel du développeur Amazon Route 53.
La liste suivante fournit des liens de GitHub référentiel vers la référence cartographique expliquant comment Security Lake normalise les journaux Route 53 vers OCSF.
GitHub Référentiel OCSF pour les journaux de Route 53
-
Version 1 de la source (v1.0.0-rc.2
) -
Version 2 de la source (v1.1.0
)
Conclusions du Security Hub
Les résultats du Security Hub vous aident à comprendre votre niveau de sécurité AWS et vous permettent de vérifier que votre environnement est conforme aux normes et aux meilleures pratiques du secteur de la sécurité. Security Hub collecte les résultats provenant de diverses sources, y compris les intégrations avec d'autres produits tiers AWS services, et effectue des vérifications par rapport aux contrôles du Security Hub. Security Hub traite les résultats dans un format standard appelé AWS Security Finding Format (ASFF).
Lorsque vous ajoutez les résultats de Security Hub en tant que source dans Security Lake, Security Lake commence immédiatement à collecter vos résultats directement auprès de Security Hub via un flux d'événements indépendant et dupliqué. Security Lake transforme également les résultats de l'ASFF au Cadre de schéma de cybersécurité ouvert (OCSF) (OCSF).
Security Lake ne gère pas les résultats de votre Security Hub et n'affecte pas les paramètres de votre Security Hub. Pour gérer les résultats du Security Hub, vous devez utiliser la console de service Security Hub, l'API ou AWS CLI. Pour plus d'informations, consultez la section Conclusions du guide de AWS Security Hub l'utilisateur. AWS Security Hub
La liste suivante fournit des liens de GitHub référentiel vers la référence cartographique expliquant comment Security Lake normalise les résultats de Security Hub par rapport à l'OCSF.
GitHub Référentiel OCSF pour les résultats de Security Hub
-
Version 1 de la source (v1.0.0-rc.2
) -
Version 2 de la source (v1.1.0
)
Journaux de flux VPC
La fonctionnalité VPC Flow Logs d'Amazon VPC capture des informations sur le trafic IP à destination et en provenance des interfaces réseau au sein de votre environnement.
Lorsque vous ajoutez des journaux de flux VPC en tant que source dans Security Lake, Security Lake commence immédiatement à collecter vos journaux de flux VPC. Il consomme les journaux de flux VPC directement depuis Amazon VPC via un flux indépendant et dupliqué de journaux de flux.
Security Lake ne gère pas vos journaux de flux VPC et n'affecte pas vos configurations Amazon VPC. Pour gérer vos journaux de flux, vous devez utiliser la console de service Amazon VPC. Pour plus d'informations, consultez Work with Flow Logs dans le manuel Amazon VPC Developer Guide.
La liste suivante fournit des liens de GitHub référentiel vers la référence de mappage expliquant comment Security Lake normalise les journaux de flux VPC par rapport à OCSF.
GitHub Référentiel OCSF pour les journaux de flux VPC
-
Version 1 de la source (v1.0.0-rc.2
) -
Version 2 de la source (v1.1.0
)
AWS WAF journaux
Lorsque vous les ajoutez en AWS WAF tant que source de journal dans Security Lake, Security Lake commence immédiatement à collecter les journaux. AWS WAF est un pare-feu d'applications Web que vous pouvez utiliser pour surveiller les requêtes Web que vos utilisateurs finaux envoient à vos applications et pour contrôler l'accès à votre contenu. Les informations enregistrées incluent l'heure à laquelle vous avez AWS WAF reçu une demande Web de votre AWS ressource, des informations détaillées sur la demande et des détails sur les règles auxquelles la demande correspondait.
Security Lake consomme AWS WAF des grumes directement AWS WAF par le biais d'un flux de grumes indépendant et dupliqué. Ce processus est conçu pour ne pas nécessiter de configuration supplémentaire ni affecter les AWS WAF configurations existantes que vous pourriez avoir. Pour plus d'informations sur la manière dont vous pouvez AWS WAF protéger les ressources de votre application, consultez la section AWS WAF Fonctionnement du guide du AWS WAF développeur.
Important
Si vous utilisez Amazon CloudFront Distribution comme type de ressource AWS WAF, vous devez sélectionner USA East (Virginie du Nord) pour ingérer les journaux globaux dans Security Lake.
AWS WAF les journaux ne sont pris en charge que dans OCSF v1.1.0. Pour plus d'informations sur la façon dont Security Lake normalise les événements des AWS WAF journaux en OCSF, consultez la référence de mappage dans le référentiel GitHub OCSF pour les AWS WAF journaux (
Ajouter un AWS service en tant que source
Après avoir ajouté un AWS service en tant que source, Security Lake commence automatiquement à collecter des journaux et des événements de sécurité à partir de celui-ci. Ces instructions vous indiquent comment ajouter une source prise en charge nativement AWS service dans Security Lake. Pour obtenir des instructions sur l'ajout d'une source personnalisée, consultezCollecte de données à partir de sources personnalisées.
Mettre à jour les autorisations des rôles
Si vous ne disposez pas des autorisations ou des ressources requises (nouvelle AWS Lambda fonction et file d'attente Amazon Simple Queue Service (Amazon SQS) pour ingérer les données d'une nouvelle version de la source de données, vous devez mettre à jour les autorisations de rôle et créer un nouvel ensemble de ressources pour traiter les données provenant de AmazonSecurityLakeMetaStoreManagerV2
vos sources.
Choisissez votre méthode préférée et suivez les instructions pour mettre à jour les autorisations de votre rôle et créer de nouvelles ressources pour traiter les données d'une nouvelle version d'une source de AWS journal dans une région spécifiée. Il s'agit d'une action ponctuelle, car les autorisations et les ressources sont automatiquement appliquées aux futures versions des sources de données.
Supprimer le AmazonSecurityLakeMetaStoreManager rôle
Important
Après avoir mis à jour les autorisations de votre rôleAmazonSecurityLakeMetaStoreManagerV2
, vérifiez que le lac de données fonctionne correctement avant de supprimer l'ancien AmazonSecurityLakeMetaStoreManager
rôle. Il est recommandé d'attendre au moins 4 heures avant de supprimer le rôle.
Si vous décidez de supprimer le rôle, vous devez d'abord le AmazonSecurityLakeMetaStoreManager
supprimer de AWS Lake Formation.
Procédez comme suit pour supprimer le AmazonSecurityLakeMetaStoreManager
rôle de la console Lake Formation.
-
Connectez-vous à la AWS Management Console console Lake Formation et ouvrez-la à l'adresse https://console.aws.amazon.com/lakeformation/
. -
Dans la console Lake Formation, dans le volet de navigation, sélectionnez Administrative roles and tasks.
-
Supprimer
AmazonSecurityLakeMetaStoreManager
de chaque région.
Supprimer un AWS service en tant que source
Choisissez votre méthode d'accès et suivez ces étapes pour supprimer une source Security Lake prise AWS service en charge nativement. Vous pouvez supprimer une source pour une ou plusieurs régions. Lorsque vous supprimez la source, Security Lake arrête de collecter les données de cette source dans les régions et les comptes spécifiés, et les abonnés ne peuvent plus consommer de nouvelles données provenant de la source. Toutefois, les abonnés peuvent toujours consommer les données collectées par Security Lake à la source avant leur suppression. Vous ne pouvez utiliser ces instructions que pour supprimer une source prise en charge nativement AWS service . Pour plus d'informations sur la suppression d'une source personnalisée, consultezCollecte de données à partir de sources personnalisées.
Obtenir le statut de la collection de sources
Choisissez votre méthode d'accès et suivez les étapes pour obtenir un aperçu des comptes et des sources pour lesquels la collecte de journaux est activée dans la région actuelle.