Scénarios d'exportation de données de journalisation : analyse de la sécurité et des accès

Ce document explique comment exporter des journaux de Cloud Logging vers des destinations telles que BigQuery, Chronicle ou un système SIEM tiers pour répondre aux exigences de sécurité. et les exigences d'analyse de l'environnement d'infrastructure cloud de votre organisation. Les entreprises utilisent souvent ces outils d'analyse de sécurité pour prévenir, détecter et contrer les menaces telles que les logiciels malveillants, l'hameçonnage, les rançongiciels et les erreurs de configuration potentielles des éléments. Pour vous aider à répondre à ces exigences de sécurité et d'analyse, ce document présente d'abord les différents journaux liés à la sécurité de votre environnement Google Cloud, des journaux d'application aux journaux de la plate-forme, en plus des journaux d'audit tels que les journaux des activités d'administration et Journaux d'accès aux données.

À l'aide de l'outil de champ d'application des journaux, vous pouvez d'abord évaluer ces types de journaux pertinents à la sécurité, en termes de visibilité et de couverture de détection des menaces. Cet outil vous aide à identifier les tactiques et techniques de menace allant du modèle de menace MITRE ATT&CK® populaire aux types de journaux Google Cloud spécifiques qui vous aideront à étudier ces problèmes courants. De même, il mappe les modules Event Threat Detection de Security Command Center sur les sources de journal Google Cloud correspondantes dont ils dépendent.

Dans ce scénario, les journaux exportés sont diffusés vers un ensemble de données dans BigQuery que vous configurez dans le cadre de l'exportation en plus du filtre de journalisation défini par l'utilisateur. Vous accordez des autorisations pour, le cas échéant, limiter l'accès aux journaux. Vous pouvez simplifier la gestion et l'interrogation des données en organisant les données exportées dans des tables partitionnées par date. Cette approche peut contribuer à réduire les coûts des requêtes en limitant la quantité de données à analyser dans le cadre des requêtes. L'un des avantages du partitionnement est que vous pouvez définir une date d'expiration pour les partitions et ainsi ne conserver les données de journalisation que tant que vous le jugez utile. Par exemple, vous pouvez conserver les données des journaux d'audit pendant 3 ans, puis les supprimer.

Ce scénario fait partie de la série Modèles de conception pour les exportations Cloud Logging.

Évaluer les journaux à exporter

Outil de champ d'application des journaux

L'outil de champ d'application interactif suivant répertorie les journaux utiles à la sécurité présents sur Google Cloud, comme les journaux d'audit Cloud, les journaux Access Transparency et plusieurs journaux de plate-forme. Pour vous aider à déterminer quels journaux exporter et analyser afin de répondre à vos propres besoins de sécurité et de conformité, cet outil met en correspondance chaque type de journal avec les éléments correspondants:

Sélectionnez les types de journaux souhaités pour générer automatiquement un filtre de journal approprié à utiliser dans la section Configurer l'exportation de journaux.

Enregistrer le filtre de journal

Dans Cloud Shell, créez une variable pour enregistrer le filtre de journal généré automatiquement précédemment. Vous pouvez également l'affiner davantage en fonction de vos besoins. Par exemple, vous pouvez filtrer (ou exclure) des ressources uniquement dans un ou plusieurs projets spécifiques.

export LOG_FILTER='log-filter'

Configurer l'exportation de journaux

Le diagramme suivant illustre les étapes à suivre pour activer l'exportation des fichiers journaux vers BigQuery.

  • Configurez l'ensemble de données de journalisation à exporter dans BigQuery.
  • Activez la journalisation d'audit pour tous les services Google Cloud.
  • Activez les journaux de plate-forme pour des services Google Cloud spécifiques.
  • Configurez l'exportation de journaux.
  • Définissez les autorisations de stratégie IAM pour l'ensemble de données BigQuery.

Activez l'exportation de la journalisation vers BigQuery.

Configurer l'ensemble de données dans BigQuery

Suivez les instructions pour configurer un jeu de données qui hébergera les journaux exportés. Si vous utilisez des journaux agrégés, l'ensemble de données BigQuery doit se trouver dans l'un des projets Google Cloud de votre organisation. Si vous exportez les journaux d'un seul projet, l'ensemble de données BigQuery doit faire partie du même projet.

Bonne pratique : Lorsque vous créez la table, définissez une date d'expiration de partition pour limiter la taille du stockage nécessaire pour les exportations de journaux et ainsi, les coûts de stockage cumulés au fil du temps.

Activer les journaux d'audit pour tous les services

Les journaux d'audit pour l'accès aux données sont désactivés par défaut (sauf dans BigQuery). Pour activer tous les journaux d'audit, suivez les instructions pour mettre à jour la stratégie IAM avec la configuration répertoriée dans la documentation de la stratégie d'audit. Les étapes sont les suivantes :

  • Télécharger la stratégie IAM actuelle sous forme de fichier
  • ajouter au fichier de stratégie actuel l'objet JSON ou YAML de stratégie pour le journal d'audit ;
  • mettre à jour le projet avec le fichier de stratégie modifié.

Voici un exemple d'objet JSON qui active tous les journaux d'audit pour tous les services.

"auditConfigs": [
    {
        "service": "allServices",
        "auditLogConfigs": [
            { "logType": "ADMIN_READ" },
            { "logType": "DATA_READ"  },
            { "logType": "DATA_WRITE" },
        ]
    },
]

Activer les journaux de plate-forme spécifiques au service

Les journaux de plate-forme doivent être activés service par service, généralement au niveau des ressources. Par exemple, les journaux Cloud DNS sont activés au niveau du réseau VPC, les journaux de flux VPC sont activés au niveau du sous-réseau pour toutes les VM du sous-réseau et les journaux des règles de pare-feu sont activés au niveau de la règle de pare-feu individuelle. Pour savoir comment activer un type de journal spécifique, consultez la section Outil de champ d'application des journaux et cliquez sur le lien Activer dans chaque ligne.

Configurer l'exportation de la journalisation

À partir de l'outil de ligne de commande gcloud, exécutez la commande gcloud logging sinks create ou appelez l'API organizations.sinks.create pour créer un récepteur doté des filtres de journal appropriés. L'exemple de commande gcloud suivant crée un récepteur nommé gcp_logging_sink_bq22 pour l'organisation. Le récepteur inclut tous les projets enfants et spécifie le filtre de journal enregistré dans la variable $LOG_FILTER créée ci-dessus.

gcloud logging sinks create gcp_logging_sink_bq22 \
     bigquery.googleapis.com/projects/compliance-logging-export/datasets/gcp_logging_export \
     --log-filter='$LOG_FILTER' \
     --include-children \
     --organization=324989855333

Le résultat ressemble à ce qui suit :

Created [https://logging.googleapis.com/v2/organizations/324989855333/sinks/gcp_logging_sink_bq].
Please remember to grant `serviceAccount:gcp-logging-sink-bq@logging-o324989855333.iam.gserviceaccount.com` the WRITER role on the dataset..
More information about sinks can be found at /logging/docs/export/configure_export

Dans l'entrée serviceAccount renvoyée par l'appel d'API, l'identité gcp-logging-sink-bq@logging-o324989855333.iam.gserviceaccount.com est incluse dans la réponse. Cette identité représente un compte de service Google Cloud créé pour l'exportation. Tant que vous n'accordez pas à cette identité un accès en écriture à l'ensemble de données de destination, les exportations d'entrées de journal issues de ce récepteur échoueront. Pour en savoir plus, consultez la section sur les autorisations requises pour un ensemble de données BigQuery.

Définir les autorisations de stratégie IAM pour l'ensemble de données BigQuery

En ajoutant le compte de service gcp-logging-sink-bq@logging-o324989855333.iam.gserviceaccount.com à l'ensemble de données gcp_logging_export avec les autorisations "Éditeur", vous accordez au compte de service l'autorisation d'écrire sur la destination. Tant que vous n'aurez pas ajouté ces autorisations, les opérations d'exportation depuis le récepteur échoueront.

Pour ajouter les autorisations au compte de service, procédez comme suit :

  1. Dans Cloud Console, accédez à BigQuery :

    Accéder à BigQuery

  2. À côté de l'ensemble de données gcp_logging_export, cliquez sur , puis sur Partager l'ensemble de données.

  3. Dans le champ Ajouter des personnes, saisissez le compte de service.

    Autorisations de stratégie IAM – Éditeur

Une fois que vous avez créé l'exportation des journaux au moyen de ce filtre, les fichiers journaux commencent à remplir l'ensemble de données BigQuery du projet configuré.

Bonne pratique : Mettez en œuvre une stratégie de moindre autorisation suivant vos besoins. Vous configurez les autorisations sur l'ensemble de données en fonction de comptes utilisateur Google Cloud, de groupes Google ou de comptes de service Google Cloud spécifiques. Utilisez les autorisations IAM pour accorder l'accès à l'ensemble de données BigQuery.

À titre d'exemple d'ensemble d'autorisations, vous pouvez :

  • supprimer tous les utilisateurs non essentiels des autorisations sur l'ensemble de données BigQuery ;
  • ajouter un contrôle total pour l'administrateur BigQuery ;
  • accorder à l'utilisateur exportateur les autorisations nécessaires pour écrire les journaux d'exportation ;
  • autoriser les autres utilisateurs à accéder aux exportations de journaux Google Cloud.

Vous pouvez mettre à jour les autorisations IAM de l'ensemble de données directement dans Cloud Console, via l'utilitaire de ligne de commande gsutil ou via l'API IAM.

Utiliser les journaux exportés

Lorsque vous exportez des journaux vers un ensemble de données BigQuery, Cloud Logging crée des tables datées pour contenir les entrées de journal exportées. Le nom de ces tables est basé sur le nom des entrées de journaux.

Tables datées.

La liste des tables présente le suffixe AAAAMMJJ, comme illustré dans l'exemple suivant.

Liste des tables.

Les journaux exportés étant des journaux d'audit, les journaux des activités d'administration et les journaux des accès aux données sont chargés dans BigQuery au format protoPayload.

Accorder un accès externe

Vous pouvez souhaiter accorder l'accès aux journaux exportés à certains utilisateurs spécifiques, par exemple des analystes de sécurité, votre équipe DevOps ou encore des auditeurs. BigQuery propose un certain nombre d'options permettant d'accorder un accès sécurisé aux journaux.

Stratégies de localisation des journaux

Plusieurs options permettent de sélectionner quels journaux peuvent être consultés par les utilisateurs dans BigQuery.

  • Créer des copies des journaux à partager.

    Créez manuellement ou automatiquement une copie d'une table de journalisation individuelle ou d'un ensemble de tables de journalisation, et placez les copies dans un ensemble de données BigQuery séparé. Utilisez ensuite les autorisations distinctes du second ensemble de données BigQuery pour partager les journaux avec des utilisateurs spécifiques lorsque cela est nécessaire.

    Avantages : Vous pouvez restreindre la quantité de données exposée aux données copiées uniquement.

    Inconvénients : Vous devez créer, partager et gérer des autorisations et des ensembles de données distincts, ce qui peut entraîner des coûts plus élevés.

  • Accorder un accès en lecture seule à tous les journaux.

    Définissez manuellement ou automatiquement des autorisations en lecture seule sur les tables BigQuery d'exportation des journaux, ce qui autorise l'accès à toutes les exportations de journaux.

    Avantages : L'accès est facile à accorder.

    Inconvénients : Vous devez accorder l'accès à tous les journaux au lieu de fichiers journaux spécifiques.

Stratégies de contrôle de l'accès utilisateur

Il existe plusieurs options pour accorder l'accès aux journaux dans BigQuery.

  • Utiliser un groupe Google.

    Créez un groupe Google tel que auditors@example.com avec un accès en lecture seule à l'ensemble de données BigQuery d'exportation de journaux. Vous gérez ensuite la liste des comptes Google en ajoutant ou en supprimant des auditeurs du groupe Google.

    Avantages : L'accès via un groupe est facile à gérer. L'objectif de l'accès des utilisateurs est clair.

    Inconvénients : Il est impossible de savoir qui dispose d'un accès sans consulter la liste des membres du groupe.

  • Utiliser des comptes Google individuels.

    Accordez à des comptes Google individuels, pour chaque utilisateur en ayant besoin, l'accès à l'ensemble de données BigQuery hébergeant les exportations de fichiers journaux.

    Avantages : L'ajout d'utilisateurs individuels est simple, que ce soit manuellement ou de manière automatisée.

    Inconvénients : Il n'est pas possible de distinguer les utilisateurs de l'audit des autres visiteurs.

Exemples de questions et de requêtes

Vous pouvez exécuter un large éventail de requêtes sur les journaux d'audit. Ces requêtes effectuent une analyse pour comprendre qui accède aux données dans Google Cloud ou comment vos autoscalers fonctionnent au fil du temps.

Quels sont les utilisateurs ayant le plus consulté des données durant la semaine passée ?

La requête suivante utilise les journaux d'accès aux données de Cloud Audit Logging pour identifier le compte d'utilisateur apparaissant le plus fréquemment dans les journaux d'accès aux données.

SELECT
   protopayload_auditlog.authenticationInfo.principalEmail,
   COUNT(*) AS COUNTER
FROM
(TABLE_DATE_RANGE(
Logging_export.cloudaudit_googleapis_com_data_access_,
DATE_ADD(CURRENT_TIMESTAMP(),-7,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  protopayload_auditlog.methodName = "jobservice.query"
GROUP BY
   protopayload_auditlog.authenticationInfo.principalEmail
ORDER BY
   protopayload_auditlog.authenticationInfo.principalEmail,
   COUNTER desc
LIMIT
  1000

Quels utilisateurs ont accédé aux données de la table "accounts" le mois passé ?

La requête suivante utilise les journaux d'accès aux données de Cloud Audit Logging pour identifier le compte d'utilisateur ayant le plus fréquemment interrogé la table "accounts". Remplacez your-project-id par votre ID de projet :

SELECT
   protopayload_auditlog.authenticationInfo.principalEmail,
   COUNT(*) AS COUNTER
FROM
(TABLE_DATE_RANGE(logging_export.cloudaudit_googleapis_com_data_access_,DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),CURRENT_TIMESTAMP()))
WHERE
  protopayload_auditlog.methodName = "jobservice.query" AND
  protopayload_auditlog.authorizationInfo.permission = "bigquery.tables.getData"
AND
  protopayload_auditlog.authorizationInfo.resource = "projects/your-project-id/datasets/bqtesting/tables/accounts"
GROUP BY
   protopayload_auditlog.authenticationInfo.principalEmail
ORDER BY
   protopayload_auditlog.authenticationInfo.principalEmail,
   COUNTER desc
LIMIT
  1000

Quels utilisateurs ont supprimé des machines virtuelles au cours de la semaine passée ?

La requête suivante utilise les journaux des activités d'administration de Cloud Audit Logging pour identifier les comptes utilisateur ayant supprimé des machines virtuelles au cours de la semaine écoulée.

SELECT
  timestamp,
  resource.labels.instance_id,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_activity_,
DATE_ADD(CURRENT_TIMESTAMP(),-7,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  resource.type = "gce_instance"
  AND operation.first IS TRUE
  AND protopayload_auditlog.methodName = "v1.compute.instances.delete"
ORDER BY
  timestamp,
  resource.labels.instance_id
LIMIT
  1000

La requête suivante est une requête de synthèse qui effectue un simple décompte par compte.

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  count(*) as counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_activity_,
DATE_ADD(CURRENT_TIMESTAMP(),-7,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  resource.type = "gce_instance"
  AND operation.first IS TRUE
  AND protopayload_auditlog.methodName = "v1.compute.instances.delete"
GROUP BY
  protopayload_auditlog.authenticationInfo.principalEmail
ORDER BY
  protopayload_auditlog.authenticationInfo.principalEmail,
  counter
LIMIT
  1000

La requête suivante utilise les journaux des activités d'administration de Cloud Audit Logging pour identifier la fréquence d'utilisation de l'autoscaling au cours du mois passé.

SELECT
  protopayload_auditlog.methodName,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_activity_,
DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  resource.type = "gce_instance_group_manager"
GROUP BY
  protopayload_auditlog.methodName,
ORDER BY
  protopayload_auditlog.methodName
LIMIT
  1000

Grâce à la requête suivante, vous pouvez visualiser les tendances des opérations du gestionnaire d'instances de Compute Engine au fil du temps.

SELECT
  timestamp,
  protopayload_auditlog.methodName AS methodName,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_activity_,
DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  resource.type = "gce_instance_group_manager"
GROUP BY
  timestamp,
  methodName
ORDER BY
  timestamp,
  methodName

Vous pouvez utiliser la requête ci-dessus comme requête personnalisée de source de données dans Google Data Studio pour visualiser la tendance au fil du temps, comme illustré dans le graphique suivant.

Visualisation dans Data Studio.

Pour plus d'informations, consultez la page Requêtes personnalisées dans Data Studio.

Quels sont les ensembles de données les plus fréquemment utilisés et par qui ?

La requête suivante utilise les journaux d'accès aux données de Cloud Audit Logging pour identifier les ensembles de données BigQuery les plus fréquemment utilisés et afficher les comptes d'utilisateurs responsables de cette utilisation.

SELECT
  protopayload_auditlog.authorizationInfo.resource,
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_data_access_,
DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),
CURRENT_TIMESTAMP())
)
WHERE
  protopayload_auditlog.authorizationInfo.permission = "bigquery.tables.getData"
GROUP BY
  protopayload_auditlog.authorizationInfo.resource,
  protopayload_auditlog.authenticationInfo.principalEmail
ORDER BY
  protopayload_auditlog.authorizationInfo.resource,
  protopayload_auditlog.authenticationInfo.principalEmail,
  counter DESC
LIMIT
  1000

Quelles sont les 10 requêtes les plus fréquentes dans BigQuery au cours de la semaine écoulée ?

La requête suivante utilise les journaux d'accès aux données de Cloud Audit Logging pour identifier les requêtes les plus courantes.

SELECT
  protopayload_auditlog.servicedata_v1_bigquery.jobQueryRequest.query,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
Logging_export.cloudaudit_googleapis_com_data_access_,
DATE_ADD(CURRENT_TIMESTAMP(),-7,'DAY'),
CURRENT_TIMESTAMP()))
WHERE
  protopayload_auditlog.methodName = "jobservice.query"
GROUP BY
  protopayload_auditlog.servicedata_v1_bigquery.jobQueryRequest.query
ORDER BY
  counter DESC
LIMIT
  1000

Quelles sont les actions les plus courantes enregistrées dans le journal d'accès aux données au cours des 30 derniers jours ?

La requête suivante utilise les journaux d'accès aux données de Cloud Audit Logging pour identifier les actions les plus courantes enregistrées au cours des 30 derniers jours.

SELECT
  protopayload_auditlog.methodName,
  resource.type,
  COUNT(*) AS counter
FROM
(TABLE_DATE_RANGE(
logging_export.cloudaudit_googleapis_com_data_access_,
DATE_ADD(CURRENT_TIMESTAMP(),-30,'DAY'),
CURRENT_TIMESTAMP())
)
GROUP BY
  protopayload_auditlog.methodName,
  resource.type
ORDER BY
  COUNTER DESC
LIMIT
  1000

Étape suivante