Exporter des journaux vers un système SIEM

Cette page explique comment exporter des journaux de Google Distributed Cloud (GDC) air gap vers un système externe de gestion des informations et des événements de sécurité (SIEM). Cette intégration permet d'analyser les journaux de manière centralisée et d'améliorer la surveillance de la sécurité.

L'exportation de journaux consiste principalement à déployer une ressource personnalisée SIEMOrgForwarder. Cette ressource sert de fichier de configuration, spécifiant les détails de l'instance SIEM externe désignée pour recevoir les journaux. En définissant ces paramètres dans le fichier SIEMOrgForwarder, les administrateurs peuvent établir un pipeline d'exportation de journaux simplifié et sécurisé.

Avant de commencer

Pour obtenir les autorisations nécessaires pour gérer les ressources personnalisées SIEMOrgForwarder, demandez à votre administrateur d'organisation IAM de vous accorder l'un des rôles d'organisation d'exportation SIEM associés.

Selon le niveau d'accès et les autorisations dont vous avez besoin, vous pouvez obtenir des rôles de créateur, d'éditeur ou de lecteur pour cette ressource dans l'espace de noms de votre projet. Pour en savoir plus, consultez Préparer les autorisations IAM.

Une fois que vous avez obtenu les autorisations nécessaires, procédez comme suit avant d'exporter les journaux vers un système SIEM externe :

1. Établir la connectivité : assurez-vous qu'une connexion existe entre GDC et la destination SIEM externe. Si nécessaire, collaborez avec l'opérateur d'infrastructure (IO) pour établir une connexion de liaison montante vers votre réseau client.

2. Définir des variables d'environnement : définissez les variables d'environnement suivantes pour exécuter les commandes de cette page :

   • Chemin d'accès au fichier kubeconfig :

     export KUBECONFIG=KUBECONFIG_PATH
     

     Remplacez KUBECONFIG_PATH par le chemin d'accès au fichier kubeconfig du serveur d'API Management.

   • Votre espace de noms de projet :

     export PROJECT_NAMESPACE=PROJECT_NAMESPACE
     

Configurer l'exportation des journaux

Créez le secret et la ressource personnalisée SIEMOrgForwarder dans le même espace de noms. Vous pouvez utiliser n'importe quel espace de noms de projet. Chaque SIEMOrgForwarder exporte les journaux de plate-forme de tous les clusters de l'organisation. Vous n'avez donc pas besoin de créer ces ressources dans d'autres projets ou clusters.

Il est recommandé d'utiliser l'espace de noms platform-obs, car SIEMOrgForwarder n'exporte que les journaux de la plate-forme. Les rôles d'organisation d'exportation SIEM accordent également un accès en lecture à tous les secrets de l'espace de noms où ils sont accordés. Demandez donc à votre administrateur d'organisation IAM d'accorder ces rôles uniquement aux administrateurs de la plate-forme.

Important : La pile de journalisation limite le nombre de tentatives d'établissement d'une connexion avec la solution SIEM et d'envoi d'un journal d'audit. L'opérateur d'infrastructure peut configurer manuellement le nombre exact de nouvelles tentatives, mais la valeur par défaut est définie sur cinq. Si la connexion échoue après le nombre de tentatives spécifié, la pile de journalisation n'envoie pas de journaux d'audit à la solution SIEM.

Exportez les journaux vers un système SIEM externe :

1. Fournissez un jeton pour connecter la pile de journalisation au système SIEM. Pour effectuer cette action, vous devez créer un secret dans l'espace de noms de votre projet afin de stocker le jeton pour Splunk et le mot de passe pour Elastic SIEM :

   cat <<EOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: SECRET_NAME
     namespace: ${PROJECT_NAMESPACE}
   type: Opaque
   stringData:
     SECRET_FIELD: FIELD_VALUE
   EOF
   

   Remplacez les éléments suivants :

   • SECRET_NAME : nom de votre secret.
   • SECRET_FIELD : nom du champ dans lequel vous souhaitez stocker le secret. Pour Elastic, utilisez la même valeur que HTTP_USER_NAME dans la ressource personnalisée.
   • FIELD_VALUE : FIELD_VALUE est un jeton pour Splunk et un mot de passe pour Elastic.
   • TOKEN : votre jeton.
   Remarque : Envisagez d'utiliser des jetons distincts pour les journaux d'audit et les journaux opérationnels, en déployant deux secrets en conséquence. Vous devez référencer le nom du secret correspondant dans la ressource personnalisée SIEMOrgForwarder.

2. Déployez la ressource personnalisée SIEMOrgForwarder dans l'espace de noms de votre projet. Vous devez spécifier le type de journal en choisissant entre les journaux d'audit ou opérationnels. Pour configurer l'exportation des journaux pour les deux types de journaux, vous devez déployer une ressource SIEMOrgForwarder pour chaque type.

   Important : La ressource personnalisée SIEMOrgForwarder doit se trouver dans le même espace de noms que la ressource Secret que vous avez créée à l'étape précédente.

   L'exemple suivant montre comment appliquer une configuration à une ressource personnalisée SIEMOrgForwarder pour Splunk :

     cat <<EOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -
     apiVersion: logging.gdc.goog/v1
     kind: SIEMOrgForwarder
     metadata:
       name: SIEM_ORG_FORWARDER
       namespace: ${PROJECT_NAMESPACE}
     spec:
       source: LOG_TYPE
       destinations:
         splunkOutputs:
           - host: SIEM_HOST
             token:
               name: SECRET_NAME
               field: SECRET_FIELD
             tls: "TLS"
             netConnectTimeout: NET_CONNECT_TIMEOUT
     EOF
   

   Remplacez les éléments suivants :

   • SIEM_ORG_FORWARDER : nom du fichier de définition SIEMOrgForwarder.
   • LOG_TYPE : type de journal que vous exportez. Les valeurs acceptées sont audit et operational.
   • SIEM_HOST : nom de l'hôte SIEM.
   • SECRET_NAME : nom de votre secret.
   • SECRET_FIELD : nom du champ dans lequel vous avez stocké le secret.
   • TLS : état du protocole TLS (Transport Layer Security). Les valeurs acceptées sont "On" et "Off".
   • NET_CONNECT_TIMEOUT : durée d'attente maximale, en secondes, pour l'établissement d'une connexion. Par exemple, une valeur de 180 signifie qu'il faut attendre 180 secondes.

   L'exemple suivant montre comment appliquer une configuration à une ressource personnalisée SIEMOrgForwarder pour Elastic :

     cat <<EOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -
     apiVersion: logging.gdc.goog/v1
     kind: SIEMOrgForwarder
     metadata:
       name: SIEM_ORG_FORWARDER
       namespace: ${PROJECT_NAMESPACE}
     spec:
       source: LOG_TYPE
       destinations:
         elasticOutputs:
           - host: SIEM_HOST
             port: SIEM_PORT
             http_credential:
               http_user: HTTP_USER_NAME
               http_passwd: SECRET_NAME
             tls: "TLS"
             netConnectTimeout: NET_CONNECT_TIMEOUT
             index: INDEX
     EOF
   

   Remplacez les éléments suivants :

   • SIEM_ORG_FORWARDER : nom du fichier de définition SIEMOrgForwarder.
   • LOG_TYPE : type de journal que vous exportez. Les valeurs acceptées sont audit et operational.
   • SIEM_HOST : nom de l'hôte SIEM.
   • SIEM_PORT : port de l'instance SIEM.
   • HTTP_USER_NAME : nom d'utilisateur de l'instance SIEM. Cette valeur doit également être la clé SECRET_FIELD du secret qui stocke le mot de passe.
   • SECRET_NAME : nom de votre secret.
   • TLS : état du protocole TLS (Transport Layer Security). Les valeurs acceptées sont "On" et "Off".
   • NET_CONNECT_TIMEOUT : durée d'attente maximale, en secondes, pour l'établissement d'une connexion. Par exemple, une valeur de 180 signifie qu'il faut attendre 180 secondes.
   • INDEX : index de l'instance Elastic. Si aucune valeur n'est spécifiée, le type de journal (audit ou operational) sera utilisé. Ce champ est facultatif.

3. Vérifiez l'état de la ressource personnalisée SIEMOrgForwarder déployée :

     kubectl --kubeconfig=${KUBECONFIG} describe siemorgforwarder/SIEM_ORG_FORWARDER \
         -n ${PROJECT_NAMESPACE}
   

   Selon le type de journal, vérifiez l'état suivant :

   • Journaux d'audit : vérifiez l'état de AuditLoggingReady.

   • Journaux opérationnels : vérifiez l'état de OperationalLoggingReady.

     Remarque : La propagation des modifications et la mise à jour de l'état peuvent prendre quelques minutes.