Collecte de données auprès des AWS services - Amazon Security Lake
Prérequis : vérifier les autorisationsCloudTrail journaux d'événementsJournaux d'audit Amazon EKSJournaux de requête Route 53 ResolverConclusions du Security HubJournaux de flux VPCAjouter un Service AWS en tant que sourceMettre à jour les autorisations des rôlesSupprimer le AmazonSecurityLakeMetaStoreManager rôleSupprimer un Service AWS en tant que sourceObtenir le statut de la collection de sources

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 des AWS services

Amazon Security Lake peut collecter des journaux et des événements à partir des sites suivants pris en charge de manière native : Services AWS

  • 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)

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 Service AWS 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 Service AWS 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 à laquelle les appels ont été effectués. 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 sourceNamelorsque 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.

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 via 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

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 ne nécessite aucune configuration supplémentaire et n'affecte aucune configuration de journalisation du plan de contrôle Amazon EKS existante 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.

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

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, notamment les intégrations avec d'autres produits tiers Services AWS, et les vérifie 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

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 duplicatif 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

Ajouter un Service AWS en tant que source

Après avoir ajouté un Service AWS 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 Service AWS dans Security Lake. Pour obtenir des instructions sur l'ajout d'une source personnalisée, consultezCollecte de données à partir de sources personnalisées.

Console

  1. Ouvrez la console Security Lake à l'adresse https://console.aws.amazon.com/securitylake/.

  2. Choisissez Sources dans le volet de navigation.

  3. Sélectionnez Service AWS celui à partir duquel vous souhaitez collecter les données, puis choisissez Configurer.

  4. Dans la section Paramètres de la source, activez la source et sélectionnez la version de la source de données que vous souhaitez utiliser pour l'ingestion des données. Par défaut, la dernière version de la source de données est ingérée par Security Lake.

    Important

    Si vous ne disposez pas des autorisations de rôle requises pour activer la nouvelle version de la source de AWS journal dans la région spécifiée, contactez votre administrateur Security Lake. Pour plus d'informations, consultez la section Mettre à jour les autorisations des rôles.

    Pour que vos abonnés puissent ingérer la version sélectionnée de la source de données, vous devez également mettre à jour les paramètres de vos abonnés. Pour en savoir plus sur la modification d'un abonné, consultez la section Gestion des abonnés dans Amazon Security Lake.

    Vous pouvez éventuellement choisir d'ingérer uniquement la dernière version et de désactiver toutes les versions source précédentes utilisées pour l'ingestion de données.

  5. Dans la section Régions, sélectionnez les régions dans lesquelles vous souhaitez collecter des données pour la source. Security Lake collectera les données à la source à partir de tous les comptes des régions sélectionnées.

  6. Sélectionnez Activer.

API

Pour ajouter un Service AWS en tant que source par programmation, utilisez le CreateAwsLogSourcefonctionnement de l'API Security Lake. Si vous utilisez le AWS Command Line Interface (AWS CLI), exécutez la create-aws-log-sourcecommande. Les paramètres sourceName et regions sont obligatoires. Vous pouvez éventuellement limiter la portée de la source à un élément spécifique accounts ou spécifiquesourceVersion.

Important

Lorsque vous ne fournissez aucun paramètre dans votre commande, Security Lake suppose que le paramètre manquant fait référence à l'ensemble complet. Par exemple, si vous ne fournissez pas le accounts paramètre, la commande s'applique à l'ensemble des comptes de votre organisation.

L'exemple suivant ajoute les journaux de flux VPC en tant que source dans les comptes et régions désignés. Cet exemple est formaté pour Linux, macOS ou Unix et utilise le caractère de continuation de ligne barre oblique inverse (\) pour améliorer la lisibilité.

Note

Si vous appliquez cette demande à une région dans laquelle vous n'avez pas activé Security Lake, vous recevrez un message d'erreur. Vous pouvez résoudre l'erreur en activant Security Lake dans cette région ou en utilisant le regions paramètre pour spécifier uniquement les régions dans lesquelles vous avez activé Security Lake.

$ aws securitylake create-aws-log-source \
--sources sourceName=VPC_FLOW,accounts='["123456789012", "111122223333"]',regions=["us-east-2"],sourceVersion="1.0"

Mettre à jour les autorisations des rôles

Console

Si vous ne disposez pas des autorisations de rôle requises pour ingérer les données d'une version de la source de données, vous devez mettre à jour les autorisations de AmazonSecurityLakeMetaStoreManagerV2 rôle pour traiter les données provenant de vos sources.

Suivez les étapes pour mettre à jour les autorisations de votre rôle afin de traiter les données d'une nouvelle version de la source du AWS journal dans une région spécifiée. Il s'agit d'une action ponctuelle, car les autorisations sont automatiquement appliquées aux futures versions des sources de données.

  1. Ouvrez la console Security Lake à l'adresse https://console.aws.amazon.com/securitylake/.

    Connectez-vous avec les informations d'identification de l'administrateur délégué de Security Lake.

  2. Dans le volet de navigation, sous Paramètres, choisissez General.

  3. Choisissez Mettre à jour les autorisations de rôle.

  4. Dans la section Accès au service, effectuez l'une des opérations suivantes :

    • Créer et utiliser un nouveau rôle de service : vous pouvez utiliser le rôle AmazonSecurityLakeMetaStoreManagerV2 créé par Security Lake.

    • Utiliser un rôle de service existant : vous pouvez choisir un rôle de service existant dans la liste des noms de rôle de service.

  5. Choisissez Appliquer.

API

Si vous ne disposez pas des autorisations de rôle requises pour ingérer les données d'une version de la source de données, vous devez mettre à jour les autorisations de AmazonSecurityLakeMetaStoreManagerV2 rôle pour traiter les données provenant de vos sources. Il s'agit d'une action ponctuelle, car les autorisations sont automatiquement appliquées aux futures versions des sources de données.

Pour mettre à jour les autorisations par programmation, utilisez le UpdateDataLakefonctionnement de l'API Security Lake. Pour mettre à jour les autorisations à l'aide de AWS CLI, exécutez la update-data-lakecommande.

Pour mettre à jour les autorisations de votre rôle, vous devez associer la AmazonSecurityLakeMetastoreManagerpolitique au rôle.

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.

  1. Connectez-vous à la AWS Management Console console Lake Formation et ouvrez-la à l'adresse https://console.aws.amazon.com/lakeformation/.

  2. Dans la console Lake Formation, dans le volet de navigation, sélectionnez Administrative roles and tasks.

  3. Supprimer AmazonSecurityLakeMetaStoreManager de chaque région.

Supprimer un Service AWS en tant que source

Choisissez votre méthode d'accès et suivez ces étapes pour supprimer une source Security Lake prise Service AWS 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 Service AWS . Pour plus d'informations sur la suppression d'une source personnalisée, consultezCollecte de données à partir de sources personnalisées.

Console

  1. Ouvrez la console Security Lake à l'adresse https://console.aws.amazon.com/securitylake/.

  2. Choisissez Sources dans le volet de navigation.

  3. Sélectionnez une source, puis choisissez Désactiver.

  4. Sélectionnez une ou plusieurs régions dans lesquelles vous souhaitez arrêter de collecter des données à partir de cette source. Security Lake cessera de collecter les données à la source à partir de tous les comptes des régions sélectionnées.

API

Pour supprimer un Service AWS en tant que source par programmation, utilisez le DeleteAwsLogSourcefonctionnement de l'API Security Lake. Si vous utilisez le AWS Command Line Interface (AWS CLI), exécutez la delete-aws-log-sourcecommande. Les paramètres sourceName et regions sont obligatoires. Vous pouvez éventuellement limiter l'étendue de la suppression à un champ spécifique accounts ou spécifiquesourceVersion.

Important

Lorsque vous ne fournissez aucun paramètre dans votre commande, Security Lake suppose que le paramètre manquant fait référence à l'ensemble complet. Par exemple, si vous ne fournissez pas le accounts paramètre, la commande s'applique à l'ensemble des comptes de votre organisation.

L'exemple suivant supprime les journaux de flux VPC en tant que source dans les comptes et régions désignés.

$ aws securitylake delete-aws-log-source \
--sources sourceName=VPC_FLOW,accounts='["123456789012", "111122223333"]',regions='["us-east-1", "us-east-2"]',sourceVersion="1.0"

L'exemple suivant supprime Route 53 en tant que source dans le compte et les régions désignés.

$ aws securitylake delete-aws-log-source \
--sources sourceName=ROUTE53,accounts='["123456789012"]',regions='["us-east-1", "us-east-2"]',sourceVersion="1.0"

Les exemples précédents sont formatés pour Linux, macOS ou Unix, et ils utilisent le caractère de continuation de ligne inversée (\) pour améliorer la lisibilité.

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.

Console
Pour connaître l'état de la collecte des journaux dans la région actuelle

  1. Ouvrez la console Security Lake à l'adresse https://console.aws.amazon.com/securitylake/.

  2. Dans le volet de navigation, sélectionnez Accounts.

  3. Passez le curseur sur le nombre dans la colonne Sources pour voir quels journaux sont activés pour le compte sélectionné.

API

Pour connaître l'état de la collecte de logs dans la région actuelle, utilisez le GetDataLakeSourcesfonctionnement de l'API Security Lake. Si vous utilisez le AWS CLI, exécutez la get-data-lake-sourcescommande. Pour le accounts paramètre, vous pouvez spécifier un ou plusieurs Compte AWS identifiants sous forme de liste. Si votre demande aboutit, Security Lake renvoie un instantané de ces comptes dans la région actuelle, y compris les AWS sources auprès desquelles Security Lake collecte des données et le statut de chaque source. Si vous n'incluez pas le accounts paramètre, la réponse inclut l'état de la collecte des journaux pour tous les comptes dans lesquels Security Lake est configuré dans la région actuelle.

Par exemple, la AWS CLI commande suivante permet de récupérer l'état de collecte des journaux pour les comptes spécifiés dans la région actuelle. Cet exemple est formaté pour Linux, macOS ou Unix et utilise le caractère de continuation de ligne barre oblique inverse (\) pour améliorer la lisibilité.

$ aws securitylake get-data-lake-sources \
--accounts "123456789012" "111122223333"