Utiliser l'UI des flux
Ce document explique comment créer, dépanner et gérer des flux dans l'interface utilisateur de gestion des flux, et fournit des instructions pour les modifier, les activer et les supprimer.
Avant de commencer
Chaque flux de données nécessite des conditions préalables spécifiques avant d'être configuré dans Google Security Operations. Pour connaître les exigences applicables à votre flux, consultez Configuration par type de source et recherchez votre source de données spécifique.
Formats de compression et tailles de fichiers acceptés
Les formats de compression acceptés pour l'ingestion de flux incluent .gz, .tar.gz, .tar et solr.gz. Le tableau suivant présente les différentes tailles de fichiers acceptées par la transformation des flux Google SecOps :
| Opération | Type d'entrée | Taille recommandée | Durée attendue | Taille maximale |
|---|---|---|---|---|
| Modélisation de données | CSV | < 5 Go | < 7 min | 10 Go |
| Modélisation de données | CSV | < 5 Go | ~30 min | 10 Go |
| Modélisation de données | CSV | À déterminer | À déterminer | 2 GB |
| Modélisation de données | XML / JSON | < 1 Go | < 10 min | 2 GB |
| Modélisation de données | XLS / XLSX | < 50 Mo | 1 min environ | 50 Mo |
| Fusionner des fichiers | Tous | < 1 Go | Varie selon le nombre de fichiers | 100 Go |
| Décompresser des fichiers | Non-ZIP | < 5 Go | Varie selon le nombre de fichiers | 10 Go (non compressés) |
| Décompresser des fichiers | ZIP | - | Varie selon le nombre de fichiers | 4 Go (non compressé) |
Limites et délimiteurs des lignes de journal
Lorsque vous ingérez des journaux textuels (JSON, CSV ou Syslog), assurez-vous que vos données respectent les limites d'ingestion spécifiques suivantes :
- Taille maximale d'une ligne : une seule ligne de journal ne peut pas dépasser 4 Mo. Si une seule ligne dépasse cette limite, le flux échoue avec l'erreur
MaxLogLineSize4MBExceeded. - Délimiteurs acceptés : les délimiteurs Saut de ligne (
\n) et Retour chariot + Saut de ligne (\r\n) sont acceptés.
Impact de la modification de votre projet Cloud associé sur les flux de données
Si vous mettez à jour le projet Google Cloud associé à votre instance Google SecOps, tous les flux ingérant des données à l'aide des connecteurs suivants s'arrêteront et devront être recréés manuellement :
- AMAZON_S3_V2
- AMAZON_SQS_V2
- GOOGLE_CLOUD_STORAGE_V2
- AZURE_BLOBSTORE_V2
- GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN
Pour tous les autres flux qui n'utilisent pas ces connecteurs, l'ingestion se poursuit sans interruption. Aucune action n'est requise de la part des clients.
Déroulement de la migration
Pour les flux concernés, vous constaterez les changements suivants :
- État du flux : les flux créés avant la migration cesseront immédiatement d'extraire des données en direct et passeront en lecture seule.
- Données existantes : toutes les données déjà transférées vers Google SecOps avant la migration seront ingérées automatiquement. Aucune donnée ne sera perdue.
- Messages d'erreur : si vous essayez de modifier ou de supprimer un ancien flux, le message suivant s'affiche :
This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed.
Actions requises pour les clients
Pour assurer l'ingestion continue des données, vous devez recréer manuellement vos flux dans le nouvel environnement. Pour limiter les perturbations, procédez comme suit :
- Recréer des flux d'actualités : vous devez créer de nouveaux flux d'actualités pour remplacer ceux qui existaient avant la migration.
- Configurer l'âge maximal des fichiers : lorsque vous configurez vos nouveaux flux d'actualités, définissez l'âge maximal des fichiers sur environ deux heures avant le lancement de la mise à jour BYOP. Ce délai permet d'assurer une transition fluide.
Gérer les données en double : selon l'âge maximal du fichier que vous sélectionnez, vous pouvez rencontrer des transferts de données en double. Pour en savoir plus sur la façon dont Google SecOps filtre ces journaux redondants, consultez Empêcher la déduplication.
Enregistrer et supprimer les flux existants (avant la migration) : avant de commencer la migration BYOP, enregistrez les paramètres de configuration de tous les flux existants qui utilisent les connecteurs concernés (par exemple, Amazon S3 V2), puis supprimez les flux. Si vous ne supprimez pas les flux créés avant la migration, ils deviennent ingérables et restent dans l'interface Web Google SecOps en tant que paramètres orphelins.
Configurer des flux
Les clients Google SecOps peuvent configurer un flux dans la plate-forme de deux manières. Utilisez la méthode la plus adaptée à votre environnement :
- Paramètres SIEM > Flux (standard)
- Content Hub > Packs de contenu (Premium)
Configurer la liste d'autorisation d'adresses IP
Lorsque Google SecOps extrait des données de S3, SQS, Azure et d'API tierces, l'infrastructure Google se connecte au bucket du client ou à l'API tierce.
Pour l'ajout à la liste d'autorisation d'entrée sur vos buckets de stockage ou vos pare-feu, vous devez configurer l'ajout à la liste d'autorisation en fonction du type de flux, comme décrit dans la liste suivante :
- Flux V2 (S3_V2, SQS_V2, Azure_Blobstore_V2) : ces flux utilisent exclusivement le Google Cloud service de transfert de stockage (STS) pour extraire des données du stockage client. Ils nécessitent l'ajout des plages d'adresses IP STS à la liste d'autorisation : ipranges.json.
- API tierces : nécessitent goog.json.
- Anciens flux (S3, Azure_Blobstore) : nécessitent des plages d'adresses IP dédiées. Pour en savoir plus, contactez l'assistance Google SecOps.
- Azure Event Hub : nécessite des plages d'adresses IP spécifiques à la région. Pour en savoir plus, consultez Configurer la sécurité réseau (facultatif) dans Créer un flux Azure Event Hubs.
Étant donné que les plages d'adresses IP des services Google changent de manière dynamique, Google vous recommande de configurer votre pare-feu pour qu'il récupère et analyse régulièrement les flux comme suit :
- Flux V2 (S3_V2, SQS_V2, Azure_Blobstore_V2) : le transfert de données est exécuté exclusivement par les nœuds de calcul du service de transfert de stockage. Il vous suffit de récupérer et d'analyser régulièrement ipranges.json.
- Anciens flux (S3, SQS, Azure_Blobstore, Azure Event Hub) et API tierces : ces connexions proviennent de l'infrastructure Google. Il vous suffit de récupérer et d'analyser régulièrement goog.json et cloud.json.
Configurer vos flux
Cette section décrit comment configurer généralement vos flux, en commençant par le flux procédural standard. Les flux de données listés sur la page Flux incluent tous les flux que Google a configurés pour votre compte, y compris ceux que vous avez configurés vous-même.
Ajouter un flux
Pour ajouter un flux à votre compte Google SecOps, procédez comme suit :
Dans le menu Google SecOps, sélectionnez Paramètres SIEM > Flux.
Cliquez sur Ajouter un flux d'actualités.
Sur la page suivante, cliquez sur Configurer un seul flux. Remarque : Cette étape ne s'applique pas aux clients qui utilisent la plate-forme autonome Google SecOps SIEM.
Ajoutez un nom de flux.
Dans la liste Type de source, sélectionnez le type de source pour importer des données dans Google SecOps. Vous pouvez choisir parmi les types de sources de flux suivants :
- Amazon Data Firehose
- Amazon S3 (obsolète)
- Amazon S3 (V2)
- Amazon SQS (obsolète)
- Amazon SQS (V2)
- Azure Blob Storage (obsolète)
- Azure Blob Storage (V2)
- API personnalisée
- Google Cloud Pub/Sub
- Cloud Storage (obsolète)
- Cloud Storage (V2)
- Cloud Storage basé sur les événements
- API tierce
- Webhook
Important :
- Lorsque vous utilisez des flux Amazon S3 (obsolète), Amazon SQS (obsolète), Azure Blob Storage (obsolète) et Google Cloud Cloud Storage (obsolète), assurez-vous que le chemin d'accès au répertoire est valide.
- Lorsque vous utilisez Amazon SQS (obsolète) ou Amazon SQS (V2), accordez explicitement à Google SecOps les autorisations nécessaires pour supprimer des messages de la file d'attente Amazon SQS.
- Lorsque vous utilisez des flux Amazon SQS (obsolètes), assurez-vous qu'un seul flux consomme les messages de la file d'attente. Les messages lus par une autre application ou un autre flux ne sont pas ingérés dans le flux actuel.
- L'utilisation d'Amazon SQS (obsolète) comme type de source de flux n'est compatible qu'avec les journaux des buckets Amazon S3.
Dans la liste Type de journal, sélectionnez le type de journal correspondant aux journaux que vous souhaitez ingérer. Les journaux disponibles varient en fonction du type de source que vous avez sélectionné précédemment.
Si vous sélectionnez Cloud Storage comme type de source, utilisez l'option Obtenir un compte de service pour obtenir un compte de service unique. Consultez l'exemple de configuration de flux Google Cloud Storage.
Cliquez sur Suivant.
Spécifiez les paramètres nécessaires dans l'onglet Paramètres d'entrée. Les options présentées ici varient en fonction de la source et du type de journal sélectionnés dans l'onglet Définir les propriétés. Maintenez le pointeur de la souris sur l'icône en forme de point d'interrogation de chaque champ pour obtenir des informations supplémentaires sur ce que vous devez fournir.
Facultatif : vous pouvez spécifier un espace de noms dans l'onglet Définir les propriétés. Pour en savoir plus sur les espaces de noms, consultez Utiliser des espaces de noms d'éléments.
Cliquez sur Suivant.
Vérifiez la configuration de votre nouveau flux d'actualités dans l'onglet Finaliser.
Cliquez sur Envoyer. Google SecOps effectue une vérification de la validation du nouveau flux. Si le flux réussit la vérification, un nom lui est attribué, il est envoyé à Google SecOps, et Google SecOps commence à tenter de récupérer les données.
Configurer plusieurs flux pour une famille de produits (clients Google SecOps uniquement)
Vous pouvez configurer plusieurs flux par famille de produits, en fonction du type de journal.
- Types de journaux de référence : marqués comme recommandés. Ces types de journaux sont recommandés pour les fonctionnalités de base de la plate-forme.
- Types de journaux supplémentaires : marqués comme facultatifs. Ces types de journaux fournissent un contexte supplémentaire.
Pour simplifier la configuration, la plate-forme fournit des instructions de configuration spécifiques et des paramètres prédéfinis pour chaque configuration. Par exemple, pour CrowdStrike Falcon, vous pouvez créer plusieurs flux uniques sous les types de journaux recommandés et facultatifs afin de vous assurer que la couverture des données est suffisante.
Configurer le flux pour CrowdStrike EDR
Suivez ces étapes pour configurer un flux de journaux pour CrowdStrike EDR.
- Dans Paramètres> Flux, cliquez sur Ajouter un flux.
- Cliquez sur le produit CrowdStrike Falcon.
- Sélectionnez le type de journal CrowdStrike EDR.
- Vous pouvez également accéder à Content Hub> Content Packs (Hub de contenu > Packs de contenu), puis cliquer sur le produit CrowdStrike Falcon :
- Cliquez sur Commencer.
- Sélectionnez le type de journal CrowdStrike EDR.
Spécifiez les valeurs des champs suivants :
Champ Description Source TypeAmazon SQS RegionRégion AWS S3 associée à l'URI. Queue NameNom de la file d'attente SQS à partir de laquelle lire les données. Account NumberNuméro de compte SQS. Source Deletion OptionIndique si les fichiers et les répertoires doivent être supprimés après le transfert. Queue Access Key IDClé d'accès alphanumérique de 20 caractères pour le compte, par exemple AKIAOSFOODNN7EXAMPLE.Queue Secret Access KeyClé d'accès secrète alphanumérique de 40 caractères pour le compte, par exemple wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.(Facultatif) Configurez les paramètres suivants :
- Nom du flux : nom unique prérempli pour le flux.
- Espace de noms de l'élément : espace de noms associé au flux.
- Étiquettes d'ingestion : étiquettes appliquées aux événements de ce flux.
Cliquez sur Créer un flux.
Vous pouvez répéter ce processus pour créer des flux supplémentaires pour le même type de journal. Vous pouvez également configurer des flux pour d'autres types de journaux disponibles directement depuis cette page. Une fois l'opération terminée, accédez à la page Gestion des flux pour afficher un récapitulatif détaillé de tous les types de journaux configurés.
Supprimer les fichiers sources
L'option de suppression de la source vous permet de supprimer les objets sources du flux (fichiers et dossiers) de l'espace de stockage après un transfert réussi. Cette option n'est disponible que pour certains types de sources de flux, y compris Cloud Storage. Ces types de sources de flux incluent le champ OPTION DE SUPPRESSION DE LA SOURCE dans leurs workflows Ajouter et Modifier le flux.
Options de suppression de la source
Pour les types de sources de flux compatibles, y compris Cloud Storage, le champ OPTION DE SUPPRESSION DE LA SOURCE propose les options suivantes :
- Ne jamais supprimer les fichiers
- Supprimer les fichiers transférés et les répertoires vides
- Supprimer les fichiers transférés
Microsoft Azure Blob Storage (AZURE_BLOBSTORE) ne permet pas de supprimer les fichiers sources. Pour le champ OPTION DE SUPPRESSION DE LA SOURCE, sélectionnez uniquement l'option Ne jamais supprimer les fichiers.
Pour les sources de flux suivantes (
"feedSourceType") :GOOGLE_CLOUD_STORAGE_V2,GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN,AMAZON_S3_V2,AMAZON_SQS_V2etAZURE_BLOBSTORE_V2, le champ OPTION DE SUPPRESSION DE LA SOURCE propose deux options :- NEVER : ne supprime jamais aucun fichier après les transferts.
- ON_SUCCESS : supprime tous les fichiers et répertoires vides après le transfert.
Filtrer les objets par préfixe dans les flux STS
Le champ Inclure les préfixes (include_prefixes) filtre les objets de stockage transférés par le service de transfert de stockage (STS) avant l'ingestion en fonction des préfixes de clé d'objet. Les valeurs que vous spécifiez dans ce champ sont transmises directement à ObjectConditions.include_prefixes de STS.
Types de sources de flux STS acceptés
Le filtrage basé sur un préfixe est compatible avec les types de sources de flux STS suivants (feedSourceType) :
- Cloud Storage (V2) (
GOOGLE_CLOUD_STORAGE_V2) et Cloud Storage Event Driven (GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN) - Amazon S3 (V2) (
AMAZON_S3_V2) et Amazon SQS (V2) (AMAZON_SQS_V2) - Azure Blob Storage (V2) (
AZURE_BLOBSTORE_V2) et Azure Blob Storage basé sur les événements (AZURE_BLOBSTORE_EVENT_DRIVEN)
Syntaxe du préfixe et règles de validation
Lorsque vous configurez des préfixes à inclure (include_prefixes), respectez les règles de syntaxe et de validation suivantes :
- Pas de barre oblique au début : les préfixes sont relatifs à la racine du bucket ou du conteneur et ne doivent pas commencer par une barre oblique (
/). Par exemple, saisissezlogs/audit/au lieu de/logs/audit/. - Barres obliques de fin et correspondance partielle : les barres obliques de fin déterminent si un préfixe correspond uniquement aux objets d'un dossier spécifique ou à toute clé d'objet commençant par le préfixe :
- Avec une barre oblique finale : un préfixe se terminant par
/(par exemple,logs/app/) limite les correspondances strictement aux objets de ce dossier. Incluez une barre oblique finale pour définir le champ d'application au niveau du répertoire. - Sans barre oblique finale : un préfixe sans
/final (par exemple,logs/app) correspond à tout objet commençant par cette chaîne, y comprislogs/app_old/etlogs/application/.
- Avec une barre oblique finale : un préfixe se terminant par
- Sensibilité à la casse : les préfixes de clé d'objet sont strictement sensibles à la casse.
- Pas de caractères génériques ni d'expressions régulières : la mise en correspondance de modèles n'est pas acceptée. Les caractères tels que
*et?sont traités comme des caractères littéraux. - Aucune valeur vide : les entrées de préfixe individuelles ne peuvent pas être vides ni ne contenir que des espaces blancs. Pour ingérer l'intégralité du bucket ou du conteneur, laissez le champ Inclure les préfixes vide.
- Espaces de noms distincts qui ne se chevauchent pas : un préfixe ne peut pas être un préfixe d'un autre préfixe de la même liste. Par exemple,
["logs/", "logs/audit/"]n'est pas valide, tandis que les préfixes frères tels que["logs/audit/", "logs/vpc/"]sont valides. - Limites : un flux accepte jusqu'à 1 000 préfixes. Chaque préfixe peut avoir une longueur maximale de 1 024 octets lorsqu'il est encodé en UTF-8 et ne peut pas contenir de caractères de retour chariot (
\r) ni de saut de ligne (\n).
Configuration et autorisations spécifiques à la source
Les différents types de sources nécessitent des configurations d'authentification et de mise en réseau spécifiques pour communiquer avec Google SecOps. Cette section explique comment configurer les autorisations et les comptes de service. La configuration décrite se concentre sur l'ingestion Cloud Storage (basée sur l'extraction), l'ingestion multicloud (extraction cross-cloud) et l'ingestion basée sur l'envoi (API ou en temps réel).
Exemple de configuration d'un flux Google Cloud Storage
- Dans le menu Google SecOps, sélectionnez Paramètres, puis cliquez sur Flux.
- Cliquez sur Ajouter un flux d'actualités.
- Sur la page suivante, cliquez sur Configurer un seul flux. Cette étape ne s'applique pas si vous utilisez la plate-forme autonome Google SecOps SIEM.
- Sélectionnez Cloud Storage v2 comme Type de source.
- Sélectionnez le type de journal. Par exemple, pour créer un flux pour les journaux d'audit Google Kubernetes Engine, sélectionnez Journaux d'audit Google Kubernetes Engine comme Type de journal.
- Cliquez sur Obtenir un compte de service. Google SecOps fournit un compte de service unique qu'il utilise pour ingérer des données. Vous pouvez également obtenir ce compte de service de manière programmatique à l'aide de l'API. Consultez Récupérer un compte de service.
- Facultatif : configurez le compte de service. Pour en savoir plus, consultez Accorder l'accès au compte de service Google SecOps.
- Cliquez sur Suivant.
En fonction de la configuration Cloud Storage que vous avez créée, spécifiez des valeurs pour les champs suivants :
URI du bucket de stockage
Option de suppression de la source
Facultatif : Inclure des préfixes. Cette fonctionnalité est actuellement en aperçu limité. Pour connaître les règles de syntaxe et les détails de la liste d'autorisation, consultez Filtrer les objets par préfixe dans les flux STS.
Pour en savoir plus sur la configuration des buckets Cloud Storage, consultez Créer des buckets.
Cliquez sur Suivant, puis sur Envoyer.
Accorder l'accès au compte de service Google SecOps
- Dans la console Google Cloud , accédez à la page Buckets de Cloud Storage.
Accordez au compte de service l'accès aux objets Cloud Storage appropriés.
Pour accorder l'autorisation de lecture sur un fichier spécifique, procédez comme suit :
- Sélectionnez le fichier, puis cliquez sur Modifier l'accès.
- Cliquez sur Ajouter un compte principal.
- Dans le champ Nouveaux comptes principaux, saisissez le nom du compte de service Google SecOps.
- Attribuez un rôle contenant l'autorisation de lecture au compte de service Google SecOps. Par exemple, Lecteur des objets Storage (
roles/storage.objectViewer). Cela n'est possible que si vous n'avez pas activé l'accès uniforme au niveau du bucket. - Cliquez sur Enregistrer.
Pour accorder l'autorisation de lecture à plusieurs fichiers, accordez l'accès au niveau du bucket comme suit :
Pour
"feedSourceType": "GOOGLE_CLOUD_STORAGE":- Ajoutez le compte de service Google SecOps en tant que compte principal à votre bucket de stockage et attribuez-lui le rôle IAM Lecteur des objets Storage (
roles/storage.objectViewer). - Si vous configurez le flux pour supprimer les fichiers sources, vous devez ajouter le compte de service Google SecOps en tant que compte principal sur votre bucket et lui attribuer le rôle IAM Administrateur des objets de l'espace de stockage (
roles/storage.objectAdmin).
- Ajoutez le compte de service Google SecOps en tant que compte principal à votre bucket de stockage et attribuez-lui le rôle IAM Lecteur des objets Storage (
Pour
"feedSourceType": "GOOGLE_CLOUD_STORAGE_V2", attribuez les rôles suivants :Attribuez ce rôle :
- Lecteur des objets Storage (
roles/storage.objectViewer) si le transfert se fait vers un autre bucket Cloud Storage.
- Lecteur des objets Storage (
Attribuez l'un des rôles suivants, en fonction de ce que vous sélectionnez pour l'option de suppression de la source. Si vous sélectionnez En cas de réussite, accordez le rôle Rédacteur d'anciens buckets de l'espace de stockage. Si vous sélectionnez Jamais, attribuez le rôle Lecteur des anciens buckets Storage :
- Rédacteur des anciens buckets Storage (
roles/storage.legacyBucketWriter) si une autorisation de suppression d'objet est requise. - Lecteur des anciens buckets Storage (
roles/storage.legacyBucketReader) si l'autorisation de suppression des objets n'est pas requise.
- Rédacteur des anciens buckets Storage (
Pour
"feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN":Attribuez l'un de ces rôles :
- Lecteur des objets Storage (
roles/storage.objectViewer) si le transfert se fait vers un autre bucket Cloud Storage. - Créateur des objets de l'espace de stockage (
roles/storage.objectCreator) si le transfert concerne un système de fichiers.
- Lecteur des objets Storage (
Attribuez l'un de ces rôles :
- Rédacteur des anciens buckets Storage (
roles/storage.legacyBucketWriter) si une autorisation de suppression d'objet est requise. - Lecteur des anciens buckets Storage (
roles/storage.legacyBucketReader) si l'autorisation de suppression des objets n'est pas requise.
- Rédacteur des anciens buckets Storage (
Activer l'accès STS pour Amazon S3 et Azure Storage
Le STS est utilisé par les flux Google Cloud Storage suivants pour transférer des données depuis les blobstores Amazon S3 et Azure Storage vers Google SecOps :
- Amazon S3 (V2)
- Amazon SQS (V2)
- Azure Blob Storage (V2)
Le STS envoie des requêtes de transfert de données aux services de stockage Amazon S3 et Azure à partir d'un ensemble de plages d'adresses IP STS définies. Ces plages d'adresses IP STS sont publiées dans le fichier JSON suivant : Plages d'adresses IP.
Pour utiliser ces types de sources de flux STS, vous devrez peut-être ajuster les restrictions d'accès par adresse IP afin de permettre à STS d'accéder à vos services de stockage Amazon S3 et Azure :
Récupérez les dernières plages d'adresses IP à partir du fichier JSON.
Nous vous recommandons de lire les données de ce fichier JSON au moins une fois par semaine pour maintenir votre configuration de sécurité à jour. Lorsqu'une nouvelle plage est ajoutée au fichier, le système attend au moins sept jours avant d'utiliser cette plage pour les requêtes provenant de STS.
Pour obtenir un exemple de script Python qui récupère des plages d'adresses IP à partir d'un fichier JSON, consultez Adresses IP pour les domaines par défaut.
Comparez la plage d'adresses IP actuelle
creationTimeà la plage d'adresses IPcreationTimelue à partir du fichier JSON précédent. Si elles diffèrent, mettez à jour les restrictions d'accès par adresse IP dans les blobstores Amazon S3 et Azure Storage.Pour Amazon S3
Pour mettre à jour les restrictions d'accès par IP dans votre blobstore Amazon S3 :
Si votre projet AWS utilise des restrictions d'adresses IP pour l'accès au stockage, vous devez ajouter les plages d'adresses IP utilisées par les nœuds de calcul STS à votre liste d'adresses IP autorisées.
Pour ajouter ces plages en tant qu'adresses IP autorisées, utilisez le champ
Conditiondans unbucket policy, comme décrit dans la documentation AWS S3 : Gérer l'accès en fonction d'adresses IP spécifiques.Pour Azure Storage
Pour mettre à jour les restrictions d'accès par IP dans votre magasin d'objets blob Azure Storage :
Si vous limitez l'accès à vos ressources Azure à l'aide d'un pare-feu Azure Storage, vous devez ajouter les plages d'adresses IP utilisées par les nœuds de calcul du service de transfert de stockage à votre liste d'adresses IP autorisées.
Pour ajouter ces plages en tant qu'adresses IP autorisées, suivez les instructions de la page Configurer des pare-feu et des réseaux virtuels Stockage Azure.
Configurer un flux push Pub/Sub
Pour configurer un flux push Pub/Sub, procédez comme suit :
- Créer un flux push Pub/Sub.
- Spécifiez l'URL du point de terminaison dans un abonnement Pub/Sub.
Créer un flux push Pub/Sub
- Dans le menu Google SecOps, sélectionnez Paramètres, puis cliquez sur Flux.
- Cliquez sur Ajouter.
- Dans le champ Nom du flux, saisissez un nom pour le flux.
- Dans la liste Type de source, sélectionnez Google Cloud Pub/Sub Push.
- Sélectionnez le type de journal. Par exemple, pour créer un flux pour Open Cybersecurity Schema Framework, sélectionnez Open Cybersecurity Schema Framework (OCSF) comme Type de journal.
- Cliquez sur Suivant.
- Facultatif : spécifiez des valeurs pour les paramètres d'entrée suivants :
- Délimiteur de division : délimiteur utilisé pour séparer les lignes de journal. Vous ne pouvez utiliser que
\n. - Espace de noms de l'élément : espace de noms de l'élément.
- Étiquettes d'ingestion : étiquette à appliquer aux événements de ce flux.
- Délimiteur de division : délimiteur utilisé pour séparer les lignes de journal. Vous ne pouvez utiliser que
- Cliquez sur Suivant.
- Vérifiez la configuration de votre nouveau flux d'actualités sur l'écran Finaliser, puis cliquez sur Envoyer.
- Dans l'onglet Détails, copiez l'URL du point de terminaison du flux dans le champ Informations sur le point de terminaison. Vous aurez besoin de cette URL de point de terminaison pour créer un abonnement push dans Pub/Sub.
- Facultatif : Cliquez sur le bouton Flux activé pour désactiver le flux. Le flux est activé par défaut.
- Cliquez sur OK.
Spécifier l'URL du point de terminaison
Après avoir créé un flux push Pub/Sub, spécifiez l'URL du point de terminaison comme suit :
- Dans Pub/Sub, créez un abonnement push. Pour en savoir plus sur la création d'un abonnement push, consultez Créer des abonnements push.
- Spécifiez l'URL du point de terminaison, qui est disponible dans le flux push Pub/Sub Google Cloud .
- Sélectionnez Activer l'authentification, puis un compte de service.
- Désactivez les options Désencapsulation de la charge utile push et Désencapsulation de la charge utile push : métadonnées d'écriture de message.
Configurer un flux Amazon Data Firehose
Pour configurer un flux Amazon Data Firehose, procédez comme suit :
- Créez un flux Amazon Data Firehose, puis copiez l'URL du point de terminaison et la clé secrète.
- Créez une clé API pour vous authentifier auprès de Google SecOps. Vous pouvez également réutiliser votre clé API existante pour vous authentifier auprès de Google SecOps.
- Spécifiez l'URL du point de terminaison dans Amazon Data Firehose.
Créer un flux Amazon Data Firehose
- Dans le menu Google SecOps, sélectionnez Paramètres, puis cliquez sur Flux.
- Cliquez sur Ajouter.
- Dans le champ Nom du flux, saisissez un nom pour le flux.
- Dans la liste Type de source, sélectionnez Amazon Data Firehose.
- Sélectionnez le type de journal. Par exemple, pour créer un flux pour Open Cybersecurity Schema Framework, sélectionnez Open Cybersecurity Schema Framework (OCSF) comme Type de journal.
- Cliquez sur Suivant.
- Facultatif : spécifiez des valeurs pour les paramètres d'entrée suivants :
- Délimiteur de division : délimiteur utilisé pour séparer les lignes de journal. Vous ne pouvez utiliser que
\n. - Espace de noms de l'élément : espace de noms de l'élément.
- Étiquettes d'ingestion : étiquette à appliquer aux événements de ce flux.
- Délimiteur de division : délimiteur utilisé pour séparer les lignes de journal. Vous ne pouvez utiliser que
- Cliquez sur Suivant.
- Vérifiez la configuration de votre nouveau flux d'actualités sur l'écran Finaliser, puis cliquez sur Envoyer.
- Cliquez sur Générer une clé secrète pour générer une clé secrète permettant d'authentifier ce flux.
- Copiez et stockez la clé secrète, car vous ne pourrez plus l'afficher. Vous pouvez regénérer une nouvelle clé secrète, mais la regénération de la clé secrète rend la clé secrète précédente obsolète.
- Dans l'onglet Détails, copiez l'URL du point de terminaison du flux dans le champ Informations sur le point de terminaison. Vous aurez besoin de cette URL de point de terminaison lorsque vous spécifierez les paramètres de destination de votre flux de diffusion dans Amazon Data Firehose.
- Facultatif : Cliquez sur le bouton Flux activé pour désactiver le flux. Le flux est activé par défaut.
- Cliquez sur OK.
Créer une clé API pour le flux Amazon Data Firehose
Pour créer une clé API pour le flux Amazon Data Firehose, procédez comme suit :
- Accédez à la page Identifiants de la console Google Cloud .
- Cliquez sur Créer des identifiants et sélectionnez Clé API.
- Limitez l'accès de la clé API à l'API Chronicle.
Spécifier l'URL du point de terminaison
Dans Amazon Data Firehose, spécifiez le point de terminaison HTTPS et la clé d'accès comme suit :
Ajoutez la clé API à l'URL du point de terminaison du flux et spécifiez cette URL comme URL du point de terminaison HTTP au format suivant :
ENDPOINT_URL?key=API_KEYRemplacez les éléments suivants :
ENDPOINT_URL: URL du point de terminaison du flux.API_KEY: clé API permettant de s'authentifier auprès de Google SecOps.
Pour la clé d'accès, spécifiez la clé secrète que vous avez obtenue lors de la création du flux Amazon Data Firehose.
Configurer un flux de webhook HTTPS
Avant de commencer :
- Assurez-vous qu'un projetGoogle Cloud pour Google SecOps est configuré et que l'API Chronicle est activée pour le projet.
Associer une instance Google SecOps aux services Google Cloud
Pour configurer un flux de webhook HTTPS, procédez comme suit :
- Créez un flux de webhook HTTPS, puis copiez l'URL du point de terminaison et la clé secrète.
- Créez une clé API spécifiée avec l'URL du point de terminaison. Vous pouvez également réutiliser votre clé API existante pour vous authentifier auprès de Google SecOps.
- Spécifiez l'URL du point de terminaison dans votre application.
Envoyer plusieurs événements dans une seule requête de webhook
L'exemple de code suivant montre comment mettre en forme un corps de requête unique avec plusieurs objets JSON séparés par un saut de ligne après l'élément curl --location :
--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'
Créer un flux de webhook HTTPS
- Dans le menu Google SecOps, sélectionnez Paramètres, puis cliquez sur Flux.
- Cliquez sur Ajouter.
- Dans le champ Nom du flux, saisissez un nom pour le flux.
- Dans la liste Type de source, sélectionnez Webhook.
- Sélectionnez le type de journal. Par exemple, pour créer un flux pour Open Cybersecurity Schema Framework, sélectionnez Open Cybersecurity Schema Framework (OCSF) comme Type de journal.
- Cliquez sur Suivant.
- Facultatif : spécifiez des valeurs pour les paramètres d'entrée suivants :
- Délimiteur de division : délimiteur utilisé pour séparer les lignes de journal. Vous ne pouvez utiliser que
\n. - Espace de noms de l'élément : espace de noms de l'élément.
- Étiquettes d'ingestion : étiquette à appliquer aux événements de ce flux.
- Délimiteur de division : délimiteur utilisé pour séparer les lignes de journal. Vous ne pouvez utiliser que
- Cliquez sur Suivant.
- Vérifiez la configuration de votre nouveau flux d'actualités sur l'écran Finaliser, puis cliquez sur Envoyer.
- Cliquez sur Générer une clé secrète pour générer une clé secrète permettant d'authentifier ce flux.
- Copiez et stockez la clé secrète, car vous ne pourrez plus l'afficher. Vous pouvez regénérer une nouvelle clé secrète, mais la regénération de la clé secrète rend la clé secrète précédente obsolète.
Dans l'onglet Détails, copiez l'URL du point de terminaison du flux dans le champ Informations sur le point de terminaison. Vous devez spécifier l'URL de ce point de terminaison dans votre application cliente.
Figure 1. Informations sur le point de terminaison du flux de webhook Facultatif : Cliquez sur le bouton Flux activé pour désactiver le flux. Le flux est activé par défaut.
Cliquez sur OK.
Créer une clé API pour le flux de webhook
- Accédez à la page Identifiants de la console Google Cloud .
- Cliquez sur Créer des identifiants, puis sélectionnez Clé API.
- Limitez l'accès de la clé API à l'API Chronicle.
Spécifier l'URL du point de terminaison
- Dans votre application cliente, spécifiez le point de terminaison HTTPS, qui est disponible dans le flux de webhook.
Activez l'authentification en spécifiant la clé API et la clé secrète dans l'en-tête personnalisé au format suivant :
X-goog-api-key = API_KEYX-Webhook-Access-Key = SECRETNous vous recommandons de spécifier la clé API en tant qu'en-tête plutôt que dans l'URL. Si votre client de webhook n'accepte pas les en-têtes personnalisés, vous pouvez spécifier la clé API et la clé secrète à l'aide de paramètres de requête au format suivant :
ENDPOINT_URL?key=API_KEY&secret=SECRETRemplacez les éléments suivants :
ENDPOINT_URL: URL du point de terminaison du flux.API_KEY: clé API permettant de s'authentifier auprès de Google SecOps.SECRET: clé secrète que vous avez générée pour authentifier le flux.
Configurer un flux d'API personnalisé
Les flux d'API personnalisés Google Security Operations (également appelés connecteurs sans code) vous permettent d'ingérer des données de télémétrie à partir d'API REST tierces à l'aide d'un modèle flexible basé sur la configuration. Vous pouvez configurer l'extraction de données en définissant des points de terminaison, l'authentification, des stratégies de pagination et la gestion de l'état directement dans la console.
Principaux avantages
- Accélérez l'intégration : intégrez de nouvelles sources de télémétrie en quelques minutes grâce à un assistant guidé, sans attendre les mises à jour du backend.
- Points de contrôle avec état : évitez toute duplication de données et tout journal manquant entre les cycles d'interrogation.
- Fan-out parent-enfant : compatible avec les workflows de découverte à deux niveaux, tels que la liste des ressources et la récupération de la télémétrie associée.
- Résilience et limitation du débit automatisées : empêche la limitation du débit par le fournisseur et l'épuisement des quotas. Pour une ingestion fiable et ininterrompue, le flux d'API personnalisé gère automatiquement les réponses HTTP 429 avec une intervalle exponentiel entre les tentatives, régule les requêtes avec une limitation du débit configurable et un échelonnement des délais des tâches, et applique des garde-fous de sécurité. Pour en savoir plus, consultez Limitation du débit et de la bande passante.
Prérequis
Vérifiez les conditions préalables suivantes avant de créer un flux d'API personnalisé :
- Autorisations : pour créer ou modifier des flux, vous devez disposer du rôle Administrateur de l'API Chronicle (
roles/chronicle.admin) ou Éditeur de l'API Chronicle (roles/chronicle.editor). - Exigences concernant les API tierces :
- Une URL de base d'API valide (doit utiliser
https://). - Identifiants d'API (clé API, identifiants d'authentification de base ou ID/secret client OAuth 2.0).
- Documentation de l'API du fournisseur détaillant les chemins d'accès aux points de terminaison, les paramètres de requête, les structures de réponse JSON et les limitations du débit.
- Une URL de base d'API valide (doit utiliser
- Accès à Secret Manager : les identifiants sont chiffrés et gérés de manière sécurisée dans Secret Manager. L'identité de service exécutant le connecteur interagit automatiquement avec Secret Manager (
roles/secretmanager.secretAccessoretroles/secretmanager.admin).
Configurer un flux d'API personnalisé
Pour configurer un flux d'API personnalisé, procédez comme suit :
- Accédez à Paramètres SIEM > Flux.
- Cliquez sur Ajouter un flux d'actualités.
- Cliquez sur Configurer un flux unique.
- Dans le champ Nom du flux, saisissez un nom descriptif unique (par exemple,
1Password-Audit-Events). - Dans la liste Type de source, sélectionnez API personnalisée.
- Dans la liste Type de journal, sélectionnez le type de journal Google SecOps cible.
- Cliquez sur Suivant.
Sous Paramètres généraux, configurez les éléments suivants :
URL de base : saisissez l'hôte principal (par exemple,
https://events.1password.com). Il doit commencer parhttps://. N'ajoutez pas de sous-chemins ni de barres obliques finales.Fréquence d'interrogation : spécifiez la fréquence à laquelle la plate-forme interroge l'API pour obtenir de nouvelles données de télémétrie, en minutes. Plage acceptée : de 5 à 2 880 minutes (par défaut : 15 minutes). Pour les flux API standard (séquentielle), un intervalle de 10 à 15 minutes est standard. Pour les flux Liste et détails (parent-enfant), nous recommandons un intervalle de 30 à 60 minutes pour permettre l'exécution complète des tâches de distribution sans chevauchement.
Sous Authentification, sélectionnez l'une des méthodes d'authentification compatibles, puis configurez les champs obligatoires :
- Authentification de base : saisissez le nom d'utilisateur (identité du compte API) et le secret (c'est-à-dire le mot de passe ou le jeton secret).
- Identifiants client OAuth 2.0 : authentifiez-vous à l'aide du flux d'attribution des identifiants client OAuth 2.0. Google SecOps demande, met en cache et actualise automatiquement les jetons d'accès du porteur avant chaque cycle d'ingestion. Saisissez le point de terminaison du jeton OAuth (par exemple,
https://auth.vendor.com/oauth/token), l'ID client OAuth et le code secret du client OAuth. - En-têtes de requête de clé API : authentifiez-vous à l'aide de clés API personnalisées injectées dans les en-têtes de requête (le modèle REST d'entreprise le plus courant). Saisissez le nom de l'en-tête (par exemple,
AuthorizationouX-API-Key) et la valeur de l'en-tête (par exemple,Bearer <SECRET_TOKEN>ou<SECRET_KEY>). - Paramètres de requête de clé API : authentifiez-vous à l'aide de clés API personnalisées injectées dans les paramètres de requête d'URL. Saisissez le nom du paramètre de requête (par exemple,
api_key) et la valeur du paramètre de requête (par exemple,<SECRET_KEY>).
Sélectionnez le modèle de connecteur utilisé par votre API personnalisée :
- API standard (séquentielle) : flux d'interrogation linéaire où chaque interrogation s'appuie directement sur l'état de la précédente. Dans ce modèle, l'interrogation suivante utilise un curseur, un jeton ou un code temporel extrait de l'interrogation précédente pour ne récupérer que les nouvelles données. Sélectionnez cette fiche lorsque le fournisseur fournit un point de terminaison qui renvoie directement les enregistrements d'événements de télémétrie (par exemple, 1Password, Okta, SentinelOne, GitHub ou Slack).
- Liste et détails (parent-enfant) : flux de découverte à deux niveaux. Le flux effectue un appel initial (parent) pour récupérer une liste de ressources ou d'objets (par exemple, une liste d'ID utilisateur ou de zones). Le flux génère ensuite automatiquement des appels de suivi dépendants (enfants) pour récupérer des données de télémétrie détaillées pour chaque ressource individuelle identifiée. Sélectionnez cette fiche lorsque l'API du fournisseur nécessite un modèle de découverte à deux niveaux : d'abord, l'appel d'un point de terminaison pour récupérer une liste dynamique d'entités (par exemple, des zones, des comptes, des projets ou des appareils), puis l'exécution de requêtes de détails de suivi par entité pour récupérer la télémétrie (par exemple, Cloudflare, AWS CloudWatch ou Tenable).
Si vous avez sélectionné API standard (séquentielle), procédez comme suit :
- Sous Point de terminaison de l'API, configurez les paramètres suivants pour définir la route technique et le rythme de la requête :
- Chemin du point de terminaison : route d'API spécifique ajoutée à l'URL de base (par exemple,
/api/v1/auditevents). Elle définit la ressource de télémétrie exacte à interroger. - Méthode HTTP : sélectionnez GET pour récupérer des données à l'aide de paramètres de requête d'URL, ou POST pour envoyer une charge utile de recherche ou un corps de filtre.
- Chemin du point de terminaison : route d'API spécifique ajoutée à l'URL de base (par exemple,
- Corps de la requête : pour les requêtes POST, fournissez la charge utile des données JSON. Vous pouvez intégrer des variables de point de contrôle dynamiques telles que
{"limit": 100, "start_time": "{{.last_timestamp}}"}. - Nombre maximal de requêtes par minute : saisissez le nombre maximal de requêtes à envoyer par minute. Il s'agit d'un limiteur de débit côté client permettant de respecter les limites de débit de l'API du fournisseur (par défaut : 5 RPM = 1 requête toutes les 12 secondes). Ce paramètre évite l'épuisement des quotas lors de la pagination multipage.
- Facultatif : sous En-têtes personnalisés, configurez le Nom de l'en-tête et la Valeur, puis cliquez sur Ajouter pour définir les en-têtes HTTP spécialisés requis par l'API cible (par exemple,
Content-Type: application/json, Accept: application/json). - (Facultatif) Sous Paramètres de requête, configurez la clé et la valeur, puis cliquez sur Ajouter pour spécifier des filtres ou des options supplémentaires ajoutés à la chaîne de requête d'URL (par exemple,
count=1000,status=active) ou lier des variables de modèle dynamiques (par exemple,start={{.last_run_time}}). - Sous Stratégie de pagination, sélectionnez le mécanisme de pagination requis par l'API tierce pour gérer les ensembles de résultats multipages, puis configurez les champs obligatoires :
- Aucun : récupérez les données en une seule requête sans pagination.
- Pagination par jeton : utilisez des jetons (clés personnalisées) pour obtenir la page suivante. Saisissez le chemin JSON du jeton de la page suivante (par exemple,
meta.next_cursor) et le nom du paramètre de requête de pagination du jeton (par exemple,cursor). - Pagination des liens : suivez les URL fournies dans la réponse pour obtenir plus de données. Saisissez le chemin JSON du lien vers la page suivante (par exemple,
links.nextou@odata.nextLink). - Pagination par décalage : ignorez un certain nombre d'enregistrements pour obtenir l'ensemble suivant. Saisissez le nom du paramètre de requête de décalage (par exemple,
offset). - Pagination par numéro de page : accédez au numéro de page suivant. Saisissez le nom du paramètre de requête du numéro de page (par exemple,
page).
Sous Points de contrôle, configurez les paramètres qui permettent au connecteur de mémoriser l'endroit où il s'est arrêté entre les cycles d'interrogation récurrents :
- Stratégie : choisissez l'une des stratégies suivantes et configurez les champs obligatoires :
- Aucun : récupérez toutes les données disponibles sans suivre la progression d'un cycle à l'autre.
- Dernier code temporel : suivez le code temporel de l'enregistrement le plus récent. Saisissez le chemin d'accès JSON de la valeur du point de contrôle (par exemple,
timestampouevent_time) et la variable du point de contrôle (par exemple,last_run_time, référencée dans les interrogations suivantes en tant que{{.last_run_time}}). - Dernier enregistrement : suivez l'ID d'enregistrement le plus élevé pour ne récupérer que les nouveaux enregistrements. Saisissez le chemin JSON de la valeur du point de contrôle (par exemple,
idouevent_id) et la variable du point de contrôle (par exemple,last_id, référencée comme{{.last_id}}). - Jeton d'itérateur : utilisez les jetons de continuation persistants fournis par l'API. Saisissez le chemin d'accès JSON de la valeur du point de contrôle et la variable de point de contrôle (par exemple,
iterator_token, référencé comme{{.iterator_token}}).
- Stratégie : choisissez l'une des stratégies suivantes et configurez les champs obligatoires :
Sous Mappage des réponses, fournissez des règles qui indiquent à la plate-forme comment localiser et extraire les journaux :
- Chemin JSON des données cibles : saisissez le chemin exact dans la charge utile de la réponse de l'API où se trouve la liste des entrées de journal cibles. Pour les tableaux encapsulés dans un objet (par exemple,
{"items": [...]}), saisissezitems. Pour les API qui renvoient directement un tableau JSON racine (par exemple,[{...}, {...}]), laissez ce champ complètement vide ([]).
- Chemin JSON des données cibles : saisissez le chemin exact dans la charge utile de la réponse de l'API où se trouve la liste des entrées de journal cibles. Pour les tableaux encapsulés dans un objet (par exemple,
- Sous Point de terminaison de l'API, configurez les paramètres suivants pour définir la route technique et le rythme de la requête :
Si vous avez sélectionné Liste et détails (parent-enfant), procédez comme suit :
- Requête parente (découverte) : configurez le point de terminaison qui renvoie une liste d'éléments :
- Sous Point de terminaison de l'API, configurez les paramètres suivants pour définir la route technique et le rythme de la requête :
- Chemin du point de terminaison : route d'API spécifique ajoutée à l'URL de base (par exemple,
/api/v1/auditevents). Elle définit la ressource de télémétrie exacte à interroger. - Méthode HTTP : sélectionnez GET pour récupérer des données à l'aide de paramètres de requête d'URL, ou POST pour envoyer une charge utile de recherche ou un corps de filtre.
- Corps de la requête : pour les requêtes POST, fournissez la charge utile des données JSON. Vous pouvez intégrer des variables de point de contrôle dynamiques telles que
{"limit": 100, "start_time": "{{.last_timestamp}}"}.
- Chemin du point de terminaison : route d'API spécifique ajoutée à l'URL de base (par exemple,
- Nombre maximal de requêtes par minute : saisissez le nombre maximal de requêtes à envoyer par minute. Il s'agit d'un limiteur de débit côté client permettant de respecter les limites de débit de l'API du fournisseur (par défaut : 5 RPM = 1 requête toutes les 12 secondes). Ce paramètre évite l'épuisement des quotas lors de la pagination multipage.
- Facultatif : sous En-têtes personnalisés, configurez le Nom de l'en-tête et la Valeur, puis cliquez sur Ajouter pour définir les en-têtes HTTP spécialisés requis par l'API cible (par exemple,
Content-Type: application/json, Accept: application/json). - (Facultatif) Sous Paramètres de requête, configurez la clé et la valeur, puis cliquez sur Ajouter pour spécifier des filtres ou des options supplémentaires ajoutés à la chaîne de requête d'URL (par exemple,
count=1000,status=active) ou lier des variables de modèle dynamiques (par exemple,start={{.last_run_time}}). - Sous Stratégie de pagination, sélectionnez le mécanisme de pagination requis par l'API tierce pour gérer les ensembles de résultats multipages, puis configurez les champs obligatoires :
- Aucun : récupérez les données en une seule requête sans pagination.
- Pagination par jeton : utilisez des jetons (clés personnalisées) pour obtenir la page suivante. Saisissez le chemin JSON du jeton de la page suivante (par exemple,
meta.next_cursor) et le nom du paramètre de requête de pagination du jeton (par exemple,cursor). - Pagination des liens : suivez les URL fournies dans la réponse pour obtenir plus de données. Saisissez le chemin JSON du lien vers la page suivante (par exemple,
links.nextou@odata.nextLink). - Pagination par décalage : ignorez un certain nombre d'enregistrements pour obtenir l'ensemble suivant. Saisissez le nom du paramètre de requête de décalage (par exemple,
offset). - Pagination par numéro de page : accédez au numéro de page suivant. Saisissez le nom du paramètre de requête du numéro de page (par exemple,
page).
- Sous Points de contrôle, configurez les paramètres qui permettent au connecteur de mémoriser l'endroit où il s'est arrêté entre les cycles d'interrogation récurrents :
- Stratégie : choisissez l'une des stratégies suivantes et configurez les champs obligatoires :
- Aucun : récupérez toutes les données disponibles sans suivre la progression d'un cycle à l'autre.
- Dernier code temporel : suivez le code temporel de l'enregistrement le plus récent. Saisissez le chemin d'accès JSON de la valeur du point de contrôle (par exemple,
timestampouevent_time) et la variable du point de contrôle (par exemple,last_run_time, référencée dans les interrogations suivantes en tant que{{.last_run_time}}). - Dernier enregistrement : suivez l'ID d'enregistrement le plus élevé pour ne récupérer que les nouveaux enregistrements. Saisissez le chemin JSON de la valeur du point de contrôle (par exemple,
idouevent_id) et la variable du point de contrôle (par exemple,last_id, référencée comme{{.last_id}}). - Jeton d'itérateur : utilisez les jetons de continuation persistants fournis par l'API. Saisissez le chemin d'accès JSON de la valeur du point de contrôle et la variable de point de contrôle (par exemple,
iterator_token, référencé comme{{.iterator_token}}).
- Stratégie : choisissez l'une des stratégies suivantes et configurez les champs obligatoires :
- Sous Point de terminaison de l'API, configurez les paramètres suivants pour définir la route technique et le rythme de la requête :
- Extraction de données (le pont) : configurez les éléments suivants :
- Chemin JSON de l'identifiant de l'élément : champ spécifique de la réponse parente qui identifie de manière unique une entité individuelle (par exemple,
idouzone_id). Le connecteur extrait cet identifiant de chaque élément du tableau parent. - Nom de la variable de modèle : spécifiez un nom de variable personnalisé pour stocker l'ID extrait (par exemple,
zone_id). L'interface utilisateur affiche un badge dynamique : Utilisez{{.zone_id}}dans votre requête enfant ci-dessous.
- Chemin JSON de l'identifiant de l'élément : champ spécifique de la réponse parente qui identifie de manière unique une entité individuelle (par exemple,
- Requête enfant (détails) : configurez le point de terminaison qui renvoie des journaux détaillés pour chaque élément :
- Sous Point de terminaison de l'API, configurez les paramètres suivants pour définir la route technique et le rythme de la requête :
- Chemin du point de terminaison : route d'API spécifique ajoutée à l'URL de base (par exemple,
/client/v4/zones/{{.zone_id}}/logs/received). Elle définit la ressource de télémétrie exacte à interroger. - Méthode HTTP : sélectionnez GET pour récupérer des données à l'aide de paramètres de requête d'URL, ou POST pour envoyer une charge utile de recherche ou un corps de filtre.
- Corps de la requête : pour les requêtes POST, fournissez la charge utile des données JSON. Vous pouvez intégrer des variables de point de contrôle dynamiques telles que
{"limit": 100, "start_time": "{{.last_timestamp}}"}.
- Chemin du point de terminaison : route d'API spécifique ajoutée à l'URL de base (par exemple,
- Nombre maximal de requêtes par minute : saisissez le nombre maximal de requêtes à envoyer par minute. Il s'agit d'un limiteur de débit côté client permettant de respecter les limites de débit de l'API du fournisseur (par défaut : 5 RPM = 1 requête toutes les 12 secondes). Ce paramètre évite l'épuisement des quotas lors de la pagination multipage.
- Facultatif : sous En-têtes personnalisés, configurez le Nom de l'en-tête et la Valeur, puis cliquez sur Ajouter pour définir les en-têtes HTTP spécialisés requis par l'API cible (par exemple,
Content-Type: application/json, Accept: application/json). - (Facultatif) Sous Paramètres de requête, configurez la clé et la valeur, puis cliquez sur Ajouter pour spécifier des filtres ou des options supplémentaires ajoutés à la chaîne de requête d'URL (par exemple,
count=1000,status=active) ou lier des variables de modèle dynamiques (par exemple,start={{.last_run_time}}). - Sous Stratégie de pagination, sélectionnez le mécanisme de pagination requis par l'API tierce pour gérer les ensembles de résultats multipages, puis configurez les champs obligatoires :
- Aucun : récupérez les données en une seule requête sans pagination.
- Pagination par jeton : utilisez des jetons (clés personnalisées) pour obtenir la page suivante. Saisissez le chemin JSON du jeton de la page suivante (par exemple,
meta.next_cursor) et le nom du paramètre de requête de pagination du jeton (par exemple,cursor). - Pagination des liens : suivez les URL fournies dans la réponse pour obtenir plus de données. Saisissez le chemin JSON du lien vers la page suivante (par exemple,
links.nextou@odata.nextLink). - Pagination par décalage : ignorez un certain nombre d'enregistrements pour obtenir l'ensemble suivant. Saisissez le nom du paramètre de requête de décalage (par exemple,
offset). - Pagination par numéro de page : accédez au numéro de page suivant. Saisissez le nom du paramètre de requête du numéro de page (par exemple,
page).
- Sous Points de contrôle, configurez les paramètres qui permettent au connecteur de mémoriser l'endroit où il s'est arrêté entre les cycles d'interrogation récurrents :
- Stratégie : choisissez l'une des stratégies suivantes et configurez les champs obligatoires :
- Aucun : récupérez toutes les données disponibles sans suivre la progression d'un cycle à l'autre.
- Dernier code temporel : suivez le code temporel de l'enregistrement le plus récent. Saisissez le chemin d'accès JSON de la valeur du point de contrôle (par exemple,
timestampouevent_time) et la variable du point de contrôle (par exemple,last_run_time, référencée dans les interrogations suivantes en tant que{{.last_run_time}}).
- Stratégie : choisissez l'une des stratégies suivantes et configurez les champs obligatoires :
- Sous Point de terminaison de l'API, configurez les paramètres suivants pour définir la route technique et le rythme de la requête :
- Requête parente (découverte) : configurez le point de terminaison qui renvoie une liste d'éléments :
Configurez les paramètres Planification et libellés suivants :
- Fréquence d'interrogation : sélectionnez un intervalle standard (par exemple,
5m,1h). - Espace de noms : tag d'organisation facultatif.
- Étiquettes d'ingestion : paires clé/valeur pour le RBAC des données.
- Fréquence d'interrogation : sélectionnez un intervalle standard (par exemple,
Cliquez sur Envoyer. Google SecOps effectue une vérification automatique des identifiants et des points de terminaison. Si la validation réussit, l'interrogation du flux commence.
Exemple de configuration 1 : Événements d'audit 1Password (modèle d'API standard (séquentiel))
La configuration JSON déclarative suivante illustre un modèle d'API standard (séquentielle), avec un point de contrôle basé sur un curseur pour 1Password :
{
"base_url": "https://events.1password.com",
"polling_frequency": 15,
"header_auth": {
"header_key_values": [
{
"key": "Authorization",
"value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
}
]
},
"primary_request": {
"request_settings": {
"endpoint_path": "/api/v1/auditevents",
"http_method": "POST",
"request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
"custom_headers": [
{
"key": "Content-Type",
"value": "application/json"
}
],
"max_requests_per_minute": 5
},
"pagination_strategy": {
"token": {
"next_page_token_json_path": "additional_items_url",
"query_param": "cursor"
}
},
"checkpointing": {
"latest_timestamp_strategy": {
"checkpoint_value_path": "timestamp",
"checkpoint_variable": "last_run_time"
}
},
"response_mapping": {
"target_data_path": ["items"]
}
}
}
Exemple de configuration concret 2 : télémétrie de zone Cloudflare (modèle Liste et détails (parent-enfant))
La configuration JSON déclarative suivante illustre un modèle de distribution Liste et détails (parent-enfant) pour Cloudflare :
{
"base_url": "https://api.cloudflare.com",
"polling_frequency": 30,
"header_auth": {
"header_key_values": [
{
"key": "Authorization",
"value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
}
]
},
"primary_request": {
"request_settings": {
"endpoint_path": "/client/v4/zones",
"http_method": "GET"
},
"response_mapping": {
"target_data_path": ["result"]
},
"pagination_strategy": {
"none": {}
},
"checkpointing": {
"none_strategy": {}
},
"dependent_requests_config": {
"item_id_json_path": "id",
"item_id_variable": "zone_id",
"dependent_requests": [
{
"request_settings": {
"endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
"http_method": "GET",
"query_parameters": [
{
"key": "start",
"value": "{{.last_run_time}}"
},
{
"key": "count",
"value": "1000"
}
],
"max_requests_per_minute": 5
},
"pagination_strategy": {
"none": {}
},
"checkpointing": {
"latest_timestamp_strategy": {
"checkpoint_value_path": "EdgeStartTimestamp",
"checkpoint_variable": "last_run_time"
}
},
"response_mapping": {
"target_data_path": []
}
}
]
}
}
}
Bonnes pratiques concernant les API personnalisées
- Conseils sur la fréquence d'interrogation :
- Commencez par des intervalles d'interrogation modérés : définissez l'intervalle d'interrogation initial sur 15 ou 30 minutes pour les points de terminaison à volume élevé afin d'observer le comportement des quotas d'API du fournisseur avant de le réduire à 5 minutes.
- Optimiser pour une distribution à volume élevé : pour les flux Parent-enfant (liste et détails) qui découvrent des dizaines ou des centaines de ressources, Google vous recommande vivement de définir la fréquence d'interrogation sur 30 à 60 minutes pour permettre à toutes les tâches enfants de se terminer correctement avant le début du cycle de découverte suivant.
- Validez les chemins d'ingestion : utilisez la documentation du fournisseur ou des outils de test d'API pour confirmer le nom exact du champ JSON pour les codes temporels avant de configurer les points de contrôle d'état.
- Décomposer les API multi-enfants : si une API tierce nécessite de récupérer des alertes et des journaux d'audit pour une seule liste d'utilisateurs, créez deux flux enfant uniques distincts (un pour les alertes et un pour les journaux d'audit) afin de maintenir une isolation optimale.
Limitation du débit et limitation des requêtes
Pour éviter que les configurations de flux client ne dépassent les quotas des fournisseurs tiers ou ne monopolisent les ressources système, le type de flux d'API personnalisé met en œuvre les garde-fous automatisés suivants :
- Rythme des requêtes configurable (limitation du débit) : les requêtes HTTP sortantes sont automatiquement rythmées pour éviter de dépasser les limites de débit des fournisseurs. Le rythme par défaut est de cinq requêtes par minute (une requête toutes les 12 secondes). Vous pouvez ajuster ce paramètre par point de terminaison à l'aide du champ Nombre maximal de requêtes par minute dans les paramètres du point de terminaison pour qu'il corresponde aux quotas d'API publiés de votre fournisseur.
- Plafond de requêtes enfants : pour les flux parent-enfant (liste et détails), une requête de découverte peut envoyer jusqu'à 500 requêtes enfants par cycle d'interrogation.
- Profondeur de fan-out à un seul niveau : le connecteur applique strictement une profondeur de fan-out maximale d'un niveau (découverte du parent → détails de l'enfant). Les requêtes dépendantes imbriquées (appels de petits-enfants) ne sont pas acceptées.
- Plafond de la taille de la charge utile de réponse : la taille maximale autorisée de la réponse HTTP pour une requête ou une page unique est de 50 Mo. Si une API non paginée renvoie une réponse supérieure à 50 Mo, la récupération échoue avec une erreur de ressource épuisée. Pour éviter cela, configurez toujours les paramètres de requête de pagination (comme
limitoupage_size) pour récupérer les enregistrements par lots plus petits. - Reprise automatique après une erreur HTTP 429 : si l'API d'un fournisseur tiers renvoie une erreur HTTP 429 (Too Many Requests), Google SecOps capture automatiquement l'état et lance une période de reprise exponentielle, en mettant en pause l'exécution de la tâche jusqu'à ce que la fenêtre de quota du fournisseur se remplisse à nouveau.
Limites des API personnalisées
Lorsque vous planifiez vos chemins d'ingestion, notez que le type de flux API personnalisée présente les limites suivantes :
- Compatibilité stricte avec JSON : seules les réponses de l'API JSON sont acceptées. Les autres formats tels que XML, CSV, Parquet et Avro ne sont pas acceptés.
- Pas de signature de requête dynamique : les API nécessitant des signatures cryptographiques dynamiques par requête ne sont pas compatibles (par exemple, AWS SigV4, Akamai ou Oracle OCI).
- Pas d'authentification en plusieurs étapes : les API qui nécessitent un appel de connexion programmatique initial pour échanger des identifiants contre un jeton de session temporaire (comme Saviynt) avant l'interrogation ne sont pas compatibles.
- Pas d'ingestion WebSockets ni push : les flux d'API personnalisés sont compatibles avec l'interrogation pull HTTPS standard. Les connexions de streaming persistantes (WebSockets) et les webhooks entrants ne sont pas acceptés.
- Pas de TLS mutuelle (mTLS) : l'authentification doit reposer sur des clés API, une authentification de base ou des identifiants client OAuth 2.0 standards. Les handshakes de certificats côté client ne sont pas acceptés.
Résoudre les problèmes liés aux flux d'API personnalisés
Pour examiner les erreurs des flux d'API personnalisés dans l'explorateur de journaux Cloud Logging, utilisez les requêtes suivantes :
resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
Remplacez FEED_ID par l'ID de votre flux.
Pour filtrer spécifiquement les requêtes HTTP ayant échoué, utilisez la requête suivante :
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400
Remplacez FEED_ID par l'ID de votre flux.
Modes de défaillance courants et solutions
| Symptôme / Erreur | Cause principale | Solution / Remède |
|---|---|---|
| HTTP 401 Unauthorized / HTTP 403 Forbidden | Clé API, mot de passe ou identifiants OAuth expirés ou non valides. | Modifiez le flux, saisissez à nouveau des identifiants valides, puis cliquez sur Envoyer. |
| HTTP 404 Introuvable | L'URL de base ou le modèle de chemin d'accès du point de terminaison sont incorrects. | Inspectez le point de terminaison dans la documentation de l'API du fournisseur. Assurez-vous que l'URL de base se termine correctement et que le chemin du point de terminaison commence par /. |
| HTTP 429 : Trop de requêtes | Vous avez dépassé les limites de débit de l'API du fournisseur. | Augmentez la fréquence d'interrogation ou réduisez le paramètre limit dans les paramètres de requête. |
| Erreur d'extraction JSON (items_path vide) | Incohérence dans le chemin de configuration de la réponse. | Vérifiez la structure de la charge utile de la réponse de l'API et mettez à jour le chemin d'accès JSON des données cibles. |
| Ingestion de données en double | Code temporel de configuration d'état ou chemin d'extracteur d'ID non valide. | Vérifiez le nom du champ d'enregistrement de journal pour le code temporel et mettez à jour le chemin d'accès de l'extracteur. |
Gérer les flux
Après avoir configuré vos flux de données, utilisez les outils de gestion pour surveiller l'état de l'ingestion, modifier les paramètres existants et gérer le cycle de vie des flux. Cette section explique comment interpréter les états des flux et effectuer les tâches de maintenance essentielles pour assurer une visibilité continue des données.
La page Flux propose plusieurs outils pour vous aider à parcourir et à organiser votre liste de flux configurés :
Rechercher : utilisez la barre de recherche pour trouver un flux par son nom, son ID ou son type de source.
Filtrer : cliquez sur l'icône de filtre pour affiner la liste en fonction d'attributs de flux spécifiques.
Télécharger au format CSV : cliquez sur Télécharger au format CSV pour exporter la liste actuelle des flux vers un fichier CSV.
Pagination : utilisez les commandes de pagination pour :
Modifiez le nombre de lignes par page.
Parcourez les différentes pages de flux à l'aide des onglets et des flèches.
Heure de la dernière actualisation : consultez le code temporel pour savoir quand la liste des flux a été mise à jour pour la dernière fois.
Afficher les flux configurés
La page Flux affiche tous les flux que vous avez configurés.
- Accédez à Paramètres SIEM> Flux. La page principale affiche tous les flux que vous avez configurés.
- Pointez sur chaque ligne pour afficher le menu Plus more_vert .
- Dans le menu, vous pouvez afficher les détails du flux, le modifier, le désactiver ou le supprimer.
Surveiller l'état du flux
Vous pouvez surveiller l'état du flux sur la page Flux initiale, où les flux peuvent avoir les états suivants :
Actif : le flux est configuré et prêt à ingérer des données dans votre compte Google SecOps.
InProgress : Google SecOps tente d'extraire les données du tiers configuré.
Terminé : les données ont bien été récupérées par ce flux.
Archivé : flux désactivé.
Échec : le flux ne parvient pas à récupérer les données. Cela est probablement dû à un problème de configuration. Cliquez sur la question pour afficher l'erreur de configuration. Une fois que vous avez corrigé l'erreur et renvoyé le flux, revenez à la page Flux pour vérifier si le flux fonctionne désormais.
Modifier des flux existants
Sur la page Flux, vous pouvez modifier un flux existant comme suit :
Pointez sur un flux existant, puis cliquez sur more_vert dans la colonne de droite.
Cliquez sur Modifier le flux. Vous pouvez maintenant modifier les paramètres d'entrée du flux et le renvoyer à Google SecOps, qui tentera d'utiliser le flux mis à jour.
Activer (réactiver) et désactiver (mettre en veille) des flux
Lorsque vous désactivez un flux, Google SecOps cesse d'ingérer de nouvelles données provenant de cette source. Pour arrêter immédiatement l'ingestion de données, vous devez supprimer le flux. Les transferts actifs ou limités existants se poursuivent jusqu'à leur terme. Lorsque vous réactivez le flux, Google SecOps peut récupérer les données qui ont été manquées pendant que le flux était désactivé. Cette fonctionnalité est appelée "backfillability".
Dans la colonne État, les flux activés sont libellés comme suit : Actif, En cours, Terminé ou Échec. Les champs désactivés sont étiquetés comme Archivés. Pour en savoir plus, consultez Surveiller l'état du flux.
Sur la page Flux, vous pouvez activer (réactiver) ou désactiver (mettre en veille) n'importe quel flux existant :
Pointez sur un flux existant, puis cliquez sur more_vert dans la colonne de droite.
Facultatif : cliquez sur le bouton Flux activé pour activer le flux.
Facultatif : Cliquez sur le bouton Désactiver le flux pour désactiver le flux. Le flux est désormais marqué comme Archivé.
Récupération des données lorsque vous réactivez les flux (remplissage)
La capacité de Google SecOps à effectuer un backfill des données dépend du type de flux : basé sur l'extraction (compatible) ou basé sur l'envoi (non compatible).
Flux basés sur l'extraction
Grâce à ces flux, Google SecOps extrait des données de sources externes. Les flux d'extraction incluent :
- Buckets de stockage cloud, tels qu'Amazon S3, Google Cloud Storage, Azure Blob Storage
- Serveurs SFTP
API tierces, telles que Microsoft 365, Okta, Proofpoint
Lorsque vous réactivez les flux basés sur l'extraction, Google SecOps peut récupérer les données générées pendant que le flux était désactivé.
Flux basés sur le push
Avec ces flux, les systèmes externes "poussent" les données vers Google SecOps. Les flux push incluent :
- Webhooks HTTPS
- Google Cloud Pub/Sub
- Amazon Kinesis Data Firehose
- Ingestions directes d'API/d'agents, comme Bindplane
Google SecOps ne peut pas lancer automatiquement le remplissage de données à partir de flux push. Lorsque le flux est désactivé et que votre système transmet des données, Google SecOps envoie une erreur HTTP 403 Forbidden ou une erreur 4xx générique.
Si votre système ne stocke pas les données et ne tente pas de les renvoyer à Google SecOps, elles seront perdues. De plus, si votre système est configuré pour supprimer les données en cas d'échec ou pour vider son tampon, les données sont définitivement perdues pour la période concernée. Pour éviter toute perte de données, vous devez configurer votre système de manière à mettre en mémoire tampon et à renvoyer les données une fois qu'un flux est réactivé. Google SecOps peut ensuite ingérer les données manquantes lorsque le flux reprend.
Remarques concernant le backfill
- Limites du système source : la quantité de données historiques que Google SecOps peut remplir à partir de flux basés sur l'extraction est limitée par la durée de conservation des données par le système source et par ce que son API autorise. Par exemple, certaines API ne permettent d'accéder qu'aux données des sept derniers jours.
- Tampon Google SecOps : pour la récupération automatisée, le tampon interne de Google SecOps pour les flux basés sur l'extraction conserve les données pendant 90 jours maximum, après quoi elles sont supprimées.
- Restrictions liées aux locataires : les locataires non payants, tels que les démonstrations de faisabilité, peuvent être soumis à des limites concernant le backfill des données plus anciennes.
- Quotas d'ingestion : pour éviter d'avoir un impact sur l'ingestion des données en temps réel, les données de backfill sont traitées avec une priorité inférieure à celle des données actives. Le remplissage de données basé sur l'extraction est également limité, généralement à un tiers (33%) de la limite de burst de votre locataire par type de journal. Cela permet de s'assurer que les flux push critiques, tels que les agents EDR, ne sont pas affectés négativement.
- Limitation limitation du débit : si le backfill consomme l'intégralité du quota d'extraction disponible, l'ingestion est suspendue pour le reste de l'intervalle de cinq minutes et reprend automatiquement au début de l'intervalle suivant.
- Cloud Storage : vous pouvez utiliser les paramètres de flux pour contrôler le remplissage, par exemple des filtres pour les fichiers nouveaux ou mis à jour, ou des filtres de plage de dates, comme "Âge maximal du fichier".
- Backlogs volumineux : si un backlog volumineux provenant d'un flux basé sur l'extraction cause des problèmes lors de la réactivation, vous pouvez contacter l'assistance Google pour l'effacer. Cela signifie que le flux ne commencera à ingérer que les nouvelles données à l'avenir, et que les données manquantes ne seront pas remplacées.
- Modification des flux désactivés : toute modification de configuration apportée à un flux alors qu'il est désactivé s'appliquera dès qu'il sera réactivé.
Supprimer des flux
Sur la page Flux, vous pouvez également supprimer un flux existant :
Pointez sur un flux existant, puis cliquez sur more_vert dans la colonne de droite.
Cliquez sur Supprimer le flux. La fenêtre SUPPRIMER LE FLUX s'ouvre. Pour supprimer définitivement le flux, cliquez sur Oui, supprimer.
Pour les flux d'API personnalisés, une boîte de dialogue s'affiche avec une case à cocher facultative : Supprimer les données en attente.
- Décochée (par défaut) : la configuration et les identifiants du flux sont supprimés, mais les données en attente dans la file d'attente sont traitées jusqu'à l'ingestion.
- Option cochée : la configuration du flux, les identifiants et toutes les données en attente sont définitivement supprimés.
Contrôler le taux d'ingestion
Lorsque le taux d'ingestion de données d'un locataire atteint un certain seuil, Google Security Operations limite le taux d'ingestion des nouveaux flux de données pour éviter qu'une source ayant un taux d'ingestion élevé n'affecte le taux d'ingestion d'une autre source de données. Dans ce cas, il y a un délai, mais aucune donnée n'est perdue. Le volume d'ingestion et l'historique d'utilisation du locataire déterminent le seuil.
Vous pouvez demander une augmentation de la limite de débit en contactant Cloud Customer Care.
Résoudre les problèmes liés aux flux ayant échoué
Sur la page Flux, vous pouvez afficher des détails tels que le type de source, le type de journal, l'ID de flux et l'état des flux existants, comme suit :
Pointez sur un flux existant, puis cliquez sur more_vert dans la colonne de droite.
Cliquez sur Afficher le flux. Une boîte de dialogue s'affiche avec les détails du flux. Pour un flux ayant échoué, vous trouverez des détails sur l'erreur sous Détails > État.
Pour un flux ayant échoué, les détails incluent la cause de l'erreur et les étapes à suivre pour la corriger.
Consultez le tableau Erreurs de source et d'ingestion pour connaître les messages d'erreur que vous pouvez rencontrer lorsque vous utilisez des flux de données.
Pour analyser et résoudre les problèmes liés à l'activité des flux, vous pouvez consulter les journaux dans Cloud Logging. Consultez Analyser l'activité des flux avec Cloud Logging.
Erreur
Generic::failed_precondition:Erreur :
Generic::failed_precondition: include_prefixes is not enabled for this customerCette erreur se produit lorsque vous enregistrez un flux STS avec des valeurs dans le champ Inclure les préfixes (
include_prefixes), mais que votre locataire Google SecOps ne figure pas sur la liste d'autorisation pour le filtrage basé sur les préfixes.Pour résoudre cette erreur, effectuez l'une des opérations suivantes :
- Supprimez tous les préfixes du champ Inclure les préfixes (
include_prefixes), puis enregistrez à nouveau le flux pour ingérer l'intégralité du bucket ou du conteneur. - Contactez l'équipe chargée de votre compte Google Cloud , votre responsable de compte technique (TAM) ou Cloud Customer Care pour demander l'accès à la fonctionnalité
include_prefixes(enable_feed_include_prefixes) pour votre locataire. Pour en savoir plus, consultez Filtrer les objets par préfixe dans les flux STS.
- Supprimez tous les préfixes du champ Inclure les préfixes (
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.