Intégrer Apigee à Google SecOps

Cette page s'applique à Apigee et à Apigee hybrid.

Ce document explique comment intégrer Apigee à Google Security Operations (Google SecOps). Si vous utilisez Google SecOps comme solution SIEM, suivez la procédure décrite dans ce document pour configurer Apigee afin qu'il envoie des données de journal à SecOps.

Pour faciliter cette intégration, Google SecOps est compatible avec un analyseur Apigee pour l'ingestion des données de journal Apigee. Consultez également Ingérer des données Google Cloud dans Google Security Operations. Une fois que vous aurez suivi les étapes de configuration de ce document, vos données de journal Apigee seront transmises à Google SecOps.

Pour savoir comment intégrer SecOps à d'autres solutions SIEM, consultez Intégrer Apigee à votre solution SIEM.

Audience

Ce document s'adresse aux personnes suivantes:

  • Administrateurs d'API chargés de garantir la sécurité des API, de gérer les configurations de la plate-forme, de favoriser l'efficacité opérationnelle et de respecter les exigences de conformité en matière de sécurité.
  • Les analystes de sécurité se sont concentrés sur la détection et l'investigation proactives des incidents de sécurité liés aux API afin de minimiser les risques et de protéger les données sensibles.

Présentation de la configuration

La configuration décrite dans ce document utilise la règle MessageLogging d'Apigee pour envoyer un large éventail de données de journalisation Apigee, y compris des variables de flux spécifiques, à SecOps.

Google SecOps fournit un filtre Cloud Logging spécial qui peut envoyer des types de journaux spécifiques, y compris les journaux Apigee, à Google SecOps en temps réel. Google SecOps est compatible avec un analyseur Apigee pour ingérer les données de journal Apigee dans Google SecOps. Consultez également Ingérer des données Google Cloud dans Google Security Operations.

Prérequis

Une fois ces conditions préalables remplies, suivez les instructions de ce document pour intégrer Apigee à votre instance SecOps. Avant de commencer l'intégration, assurez-vous de disposer des éléments suivants:

  • Un compte Apigee ou Apigee hybrid avec des droits d'administrateur pour développer et déployer des proxys d'API
  • Un compte Google SecOps
  • Cloud Logging activé et expérience de configuration et d'utilisation de Cloud Logging
  • Connaissance des variables de flux Apigee
  • Connaissance de la règle MessageLogging d'Apigee et de l'utilisation et de la configuration générales des règles
  • (Facultatif) Connaissances sur l'utilisation des analyseurs Google SecOps pour interpréter les journaux ingérés. Les analyseurs SecOps sont intégrés par défaut pour analyser et comprendre les journaux Apigee ingérés par la règle MessageLogging.
  • Autorisations Google Cloud IAM pour utiliser l'API Cloud Logging et attribuer des rôles IAM au compte de service SecOps

Intégrer Apigee à SecOps

Si vous utilisez Google SecOps comme solution SIEM, procédez comme suit pour envoyer les données de journal Apigee à SecOps. Il existe deux étapes de base:

  • Configurer une règle MessageLogging pour envoyer les données de journal Apigee à Cloud Logging
  • Associer la règle MessageLogging à un proxy Apigee

Une fois la configuration de la règle MessageLogging décrite dans cette section terminée, les données de journal Apigee envoyées à Cloud Logging seront analysées par SecOps. Pour en savoir plus sur l'analyseur et sur la façon dont les données de variable de flux Apigee sont mappées sur les champs de données SecOps, consultez Intégrer Apigee au SIEM Google SecOps. Consultez également Collecter les journaux Apigee.

Pour intégrer Apigee à SecOps à l'aide de la stratégie MessageLogging:

  1. Configurez une nouvelle règle MessageLogging. Consultez la section Associer et configurer des règles dans l'UI.

    Voici un exemple de règle MessageLogging qui envoie des données à Cloud Logging. La règle spécifie un grand nombre de variables de flux à envoyer à Cloud Logging. Vous pouvez ajouter ou supprimer des variables de flux à votre guise, en fonction des champs que vous jugez importants pour votre analyse SecOps. Pour en savoir plus sur le mappage des données de variable de flux Apigee sur les champs de données SecOps, consultez Intégrer Apigee au SIEM Google SecOps.

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <MessageLogging continueOnError="false" enabled="true" name="ML-CloudLoggingSecOps">
   <DisplayName>ML-CloudLoggingSecOps</DisplayName>
   <CloudLogging>
     <LogName>projects/{organization.name}/logs/Apigee-SecOps-Integration-{environment.name}</LogName>
     <Message contentType="application/json">{
   "apiproduct.name": "{apiproduct.name}",
   "app.name": "{developer.app.name}",
   "cachehit":"{cachehit}",
   "client.country": "{client.country}",
   "client.cn": "{client.cn}",
   "client.ip": "{proxy.client.ip}",
   "client.locality": "{client.locality}",
   "client.port": "{client.port}",
   "client.scheme": "{client.scheme}",
   "client.state": "{client.state}",
   "developer.email": "{developer.email}",
   "environment.name": "{environment.name}",
   "error":"{is.error}",
   "error.state":"{error.state}",
   "error.message":"{escapeJSON(error.message)}",
   "fault.name":"{fault.name}",
   "messageid":"{messageid}",
   "organization.name": "{organization.name}",
   "proxy.name": "{apiproxy.name}",
   "proxy.basepath": "{proxy.basepath}",
   "proxy.pathsuffix": "{proxy.pathsuffix}",
   "proxy.proxyendpoint.name": "{proxy.name}",
   "proxy.revision":"{apiproxy.revision}",
   "request.content-length":"{request_msg.header.content-length}",
   "request.content-type":"{request_msg.header.content-type}",
   "request.host":"{request_msg.header.host}",
   "request.httpversion": "{request.version}",
   "request.url": "{client.scheme}://{request_msg.header.host}{request_msg.uri}",
   "request.user-agent":"{request.header.user-agent}",
   "request.verb": "{request.verb}",
   "request.x-b3-traceid": "{request.header.x-b3-traceid}",
   "request.x-cloud-trace-context": "{request.header.x-cloud-trace-context}",
   "response.content-length":"{response.header.content-length}",
   "response.content-type":"{response.header.content-type}",
   "response.status.code": "{message.status.code}",
   "system.region.name": "{system.region.name}",
   "system.timestamp": "{system.timestamp}",
   "system.uuid": "{system.uuid}",
   "target.cn": "{target.cn}",
   "target.country": "{target.country}",
   "target.host": "{target.host}",
   "target.ip": "{target.ip}",
   "target.locality": "{target.locality}",
   "target.organization": "{target.organization}",
   "target.port": "{target.port}",
   "target.scheme": "{target.scheme}",
   "target.state": "{target.state}",
   "target.url": "{request.url}"
  }
     </Message>
     <ResourceType>api</ResourceType>
   </CloudLogging>
  </MessageLogging>

  2. Associez la règle en tant qu'étape conditionnelle dans un proxy d'API. Une option consiste à associer la stratégie à une règle d'erreur dans PostFlow, où les erreurs liées à la sécurité sont généralement générées. Exemple :

    <PostFlow name="PostFlow">
  <Request>
    <Step>
      <Condition>flow.isError == true)</Condition>
      <Name>ML-CloudLoggingSecOps</Name>
    </Step>
  </Request>
</PostFlow>

    Désormais, lorsque le proxy d'API qui utilise cette stratégie s'exécute, les données de journal d'Apigee sont transmises à Google SecOps.

    Une autre pratique courante consiste à placer la règle MessageLogging dans le PostClientFlow de la réponse ProxyEndpoint.

    Tenez compte des conseils suivants lorsque vous associez la règle MessageLogging à votre proxy d'API:

    • Placez la stratégie dans une FaultRule. FaultRule est l'emplacement recommandé pour consigner les exceptions de sécurité et les cas de non-respect des règles.
    • Placez la règle dans le PostFlow. PostFlow est un autre emplacement approprié pour consigner les problèmes de sécurité.
    • Évitez de consigner les requêtes réussies. Pour la surveillance de la sécurité axée sur les menaces, vous enregistrez généralement des informations détaillées en cas de problème (une erreur est générée). La journalisation de chaque requête réussie avec le contenu complet du message peut générer des journaux excessifs et augmenter les coûts.
    • Envisagez d'utiliser des variables personnalisées pour certains cas d'utilisation. Par exemple, si vous devez capturer l'URI de la requête d'origine dans un flux d'erreur, vous pouvez utiliser la règle AssignMessage dans le PreFlow de la requête pour la copier dans une variable personnalisée (telle que original.request.uri), puis consigner cette variable dans la règle MessageLogging.

Bonnes pratiques

Tenez compte des bonnes pratiques suivantes lorsque vous configurez Apigee avec Google SecOps:

  • Concentrez-vous sur le contexte de sécurité:n'enregistrez que les variables de flux qui fournissent un contexte utile pour la surveillance de la sécurité et la détection des menaces. Évitez de journaliser excessivement des données non liées à la sécurité.
  • Utilisez un format de journalisation cohérent:maintenez un format de journalisation cohérent dans vos proxys d'API qui utilisent SecOps.
  • Utilisez des comptes de service sécurisés:respectez les bonnes pratiques de sécurité pour gérer et sécuriser le compte de service Google Cloud utilisé pour l'ingestion SecOps. Dans la mesure du possible, limitez l'autorisation à la visionneuse de journaux.
  • Surveillez le flux SecOps:surveillez régulièrement l'état et la santé de votre flux SecOps pour vous assurer que les journaux sont ingérés correctement et sans erreur.
  • Utilisez des règles et des tableaux de bord SecOps:une fois les journaux pertinents pour la sécurité dans SecOps, développez des règles et des tableaux de bord spécifiques pour détecter et visualiser les menaces de sécurité en fonction des informations détaillées que vous consignez.

Dépannage

Cette section décrit plusieurs problèmes possibles que vous pouvez rencontrer lors de la configuration d'Apigee avec SecOps, ainsi que les éléments à vérifier.

Problème: les journaux des événements de sécurité n'apparaissent pas dans Cloud Logging

Points à vérifier:

  • Vérifiez que votre stratégie MessageLogging est correctement configurée avec Condition pour se déclencher lorsqu'un événement de sécurité se produit.
  • Assurez-vous que la stratégie MessageLogging est associée au contexte de flux approprié, tel qu'une règle d'erreur ou un PostFlow.
  • Vérifiez que Cloud Logging est activé dans votre projet Google Cloud.
  • Examinez les messages d'erreur liés à la règle MessageLogging dans les journaux du proxy Apigee.

Problème: les journaux des événements de sécurité n'apparaissent pas dans SecOps

  • Vérifiez que votre flux SecOps est correctement configuré avec l'ID de projet, le filtre de journaux (en vous assurant qu'il capture les journaux de votre stratégie de journalisation de sécurité) et les identifiants du compte de service appropriés.
  • Vérifiez l'état de votre flux SecOps dans l'interface utilisateur SecOps pour détecter d'éventuels messages d'erreur ou problèmes d'ingestion.
  • Assurez-vous que le compte de service utilisé par SecOps dispose du rôle "Lecteur de journaux" sur votre projet Google Cloud.
  • Examinez la structure JSON de vos journaux dans Cloud Logging pour vous assurer qu'ils sont valides et qu'ils contiennent les noms de champ attendus.
  • Vérifiez que l'analyseur Google Cloud approprié est activé.
  • Si vous pensez qu'il existe un problème d'analyse, examinez un exemple d'entrée de journal dans les données brutes SecOps pour voir comment elle a été ingérée avant l'analyse. Si des champs spécifiques ne sont pas extraits comme prévu, vous devrez peut-être consulter la documentation de l'analyseur SecOps ou déterminer si un analyseur personnalisé est nécessaire.

Intégrer Apigee au SIEM Google SecOps

Le tableau suivant met en correspondance les noms de variables de flux Apigee avec les noms de champs SIEM Google SecOps équivalents. Par exemple, lorsque vous consultez les données de journal Apigee dans Cloud Logging, la variable de flux client.id est mappée sur le champ SIEM SecOps appelé principle_ip. Consultez également Collecter les journaux Apigee.

Variable de flux Apigee Nom du champ du SIEM SecOps Description
client.country principal.hostname Adresse IP de l'hôte HTTP associée à la requête reçue par le ProxyEndpoint.
client.host principal.location.country_or_region Pays spécifié dans le certificat TLS/SSL présenté par l'application cliente. Demande de proxy principal.location.country_or_region.
client.ip principle.ip Adresse IP du client ou du système qui envoie le message à l'équilibreur de charge. Il peut s'agir, par exemple, de l'adresse IP du client d'origine ou d'une adresse IP d'équilibreur de charge.
client.locality principal.location.city Localité (ville) du certificat TLS/SSL présenté par le client.
client.port principal.port Port HTTP associé à la requête du client d'origine au ProxyEndpoint.
client.state principal.location.state État spécifié dans le certificat TLS/SSL présenté par le client.
organization.name intermediary.cloud.project.name Nom de l'organisation Apigee.
proxy.client.ip src.ip Adresse X-Forwarded-For de l'appel entrant, qui correspond à l'adresse IP reçue par Apigee lors du dernier handshake TCP externe. Il peut s'agir du client à l'origine de l'appel ou d'un équilibreur de charge.
proxy.name intermediary.resource.name Attribut de nom configuré pour le ProxyEndpoint.
proxy.pathsuffix intermediary.resource.attribute.labels[pathsuffix] "Valeur du suffixe de chemin dans l'URL envoyée par le client et reçue au niveau du ProxyEndpoint. Le chemin de base est le composant de chemin le plus à gauche qui identifie de manière unique un proxy d'API au sein d'un groupe d'environnements. Supposons que vous ayez un point de terminaison de proxy d'API configuré avec un chemin de base de /v2/weatherapi. Dans ce cas, une requête envoyée à https://myhost.example.net/v2/weatherapi/forecastrss?w=12797282, la variable proxy.pathsuffix contiendra la chaîne /forecastrss."
proxy.url intermediary.url "Récupère l'URL complète associée à la requête de proxy reçue par le ProxyEndpoint, y compris les paramètres de requête présents. Pour obtenir un exemple de construction d'une URL de requête à l'aide de l'hôte de la requête d'origine (plutôt que l'hôte du routeur utilisé dans proxy.url), consultez la section "Accéder aux messages de requête"."
request.uri target.resource.name Nom de domaine du service cible qui renvoie la réponse au proxy d'API.
request.verb network.http.method Verbe HTTP utilisé pour la requête. Par exemple, GET, PUT et DELETE.
response.content security_result.description Contenu de la charge utile du message de réponse renvoyé par la cible.
response.status.code network.http.response_code Code de réponse renvoyé pour une requête. Vous pouvez utiliser cette variable pour remplacer le code d'état de la réponse, stocké dans message.status.code. Pour en savoir plus, consultez le message.
system.region.name intermediary.location.name Nom de la région du centre de données dans laquelle le proxy est exécuté.
system.timestamp additional.fields[jsonPayload_system_timestamp] Entier (long) de 64 bits représentant l'heure à laquelle cette variable a été lue. La valeur correspond au nombre de millisecondes écoulées depuis minuit, le 1er janvier 1970 UTC. Par exemple, 1534783015000.
system.uuid intermediary.process.pid ou intermediary.process.product_specific_process_id UUID du processeur de messages gérant le proxy.
target.country target.location.country_or_region Pays du certificat TLS/SSL présenté par le serveur cible
target.host target.hostname Nom de domaine du service cible qui renvoie la réponse au proxy d'API.
target.ip target.ip Adresse IP du service cible qui renvoie la réponse au proxy d'API.
target.locality target.location.city Localité (ville) du certificat TLS/SSL présenté par le serveur cible
target.organization target.resource_ancestors.name Organisation du certificat TLS/SSL présenté par le serveur cible.
target.port target.port Numéro de port du service cible qui renvoie la réponse au proxy d'API.
target.scheme target.network.application_protocol Renvoie HTTP ou HTTPS en fonction du message de la requête.
target.state target.location.state État du certificat TLS/SSL présenté par le serveur cible.
target.url target.url URL configurée dans le fichier XML de TargetEndpoint ou dans l'URL de la cible dynamique (si target.url est défini lors du flux de messages). La variable n'inclut aucun élément de chemin ou paramètre de requête supplémentaire. Renvoie la valeur "null" si elle est appelée hors du champ d'application ou non définie.

Remarque: Utilisez une règle JavaScript associée au TargetEndpoint pour définir cette variable.