Apigee in Google SecOps einbinden

Diese Seite gilt für Apigee und Apigee Hybrid.

In diesem Dokument wird beschrieben, wie Sie Apigee in Google Security Operations (Google SecOps) einbinden. Wenn Sie Google SecOps als SIEM-Lösung verwenden, folgen Sie der Anleitung in diesem Dokument, um Apigee so zu konfigurieren, dass Logdaten an SecOps gesendet werden.

Zur Vereinfachung dieser Integration unterstützt Google SecOps einen Apigee-Parser zum Erfassen von Apigee-Logdaten. Weitere Informationen finden Sie unter Google Cloud-Daten in Google Security Operations aufnehmen. Nachdem Sie die Konfigurationsschritte in diesem Dokument ausgeführt haben, werden Ihre Apigee-Logdaten an Google SecOps gesendet.

Informationen zur Integration von SecOps in andere SIEM-Lösungen finden Sie unter Apigee in Ihre SIEM-Lösung einbinden.

Zielgruppe

Die Zielgruppe für dieses Dokument umfasst:

  • API-Administratoren, die für die API-Sicherheit, die Verwaltung von Plattformkonfigurationen, die Unterstützung der betrieblichen Effizienz und die Einhaltung der Sicherheits-Compliance-Anforderungen verantwortlich sind.
  • Sicherheitsanalysten konzentrieren sich darauf, API-bezogene Sicherheitsvorfälle proaktiv zu erkennen und zu untersuchen, um Risiken zu minimieren und sensible Daten zu schützen.

Konfigurationsübersicht

Bei der in diesem Dokument beschriebenen Konfiguration wird die MessageLogging-Richtlinie von Apigee verwendet, um eine Vielzahl von Apigee-Logdaten, einschließlich bestimmter Ablaufvariablen, an SecOps zu senden.

Google SecOps bietet einen speziellen Cloud Logging-Filter, mit dem bestimmte Logtypen, einschließlich Apigee-Logs, in Echtzeit an Google SecOps gesendet werden können. Google SecOps unterstützt einen Apigee-Parser zum Erfassen von Apigee-Logdaten in Google SecOps. Weitere Informationen finden Sie unter Google Cloud-Daten in Google Security Operations aufnehmen.

Vorbereitung

Wenn diese Voraussetzungen erfüllt sind, folgen Sie der Anleitung in diesem Dokument, um Apigee in Ihre SecOps-Instanz einzubinden. Bevor Sie mit der Integration beginnen, müssen folgende Voraussetzungen erfüllt sein:

  • Ein Apigee- oder Apigee Hybrid-Konto mit Administratorberechtigungen zum Entwickeln und Bereitstellen von API-Proxys
  • Ein Google SecOps-Konto
  • Cloud Logging aktiviert und Erfahrung mit der Konfiguration und Verwendung von Cloud Logging
  • Kenntnisse der Apigee-Ablaufvariablen
  • Kenntnisse der Apigee MessageLogging-Richtlinie und der allgemeinen Richtlinienverwendung und -konfiguration
  • (Optional) Kenntnisse darüber, wie Google SecOps-Parser zum Interpretieren aufgenommener Logs verwendet werden. SecOps-Parser sind standardmäßig integriert, um Apigee-Logs zu parsen und zu interpretieren, die von der MessageLogging-Richtlinie aufgenommen werden.
  • Google Cloud IAM-Berechtigungen zum Verwenden der Cloud Logging API und Zuweisen von IAM-Rollen zum SecOps-Dienstkonto

Apigee in SecOps einbinden

Wenn Sie Google SecOps als SIEM-Lösung verwenden, gehen Sie so vor, um Apigee-Logdaten an SecOps zu senden. Es gibt zwei grundlegende Schritte:

  • MessageLogging-Richtlinie konfigurieren, um Apigee-Logdaten an Cloud Logging zu senden
  • MessageLogging-Richtlinie an einen Apigee-Proxy anhängen

Wenn die in diesem Abschnitt beschriebene Konfiguration der MessageLogging-Richtlinie abgeschlossen ist, werden die an Cloud Logging gesendeten Apigee-Logdaten von SecOps geparst. Ausführliche Informationen zum Parser und dazu, wie Apigee-Ablaufvariablendaten den SecOps-Datenfeldern zugeordnet werden, finden Sie unter Apigee in Google SecOps SIEM einbinden. Siehe auch Apigee-Logs erfassen.

Führen Sie die folgenden Schritte aus, um Apigee mit SecOps zu integrieren und dabei die MessageLogging-Richtlinie zu verwenden:

  1. Konfigurieren Sie eine neue MessageLogging-Richtlinie. Weitere Informationen finden Sie unter Richtlinien in der Benutzeroberfläche anhängen und konfigurieren.

    Im Folgenden finden Sie ein Beispiel für eine MessageLogging-Richtlinie, mit der Daten an Cloud Logging gesendet werden. In der Richtlinie wird eine große Anzahl von Ablaufvariablen angegeben, die an Cloud Logging gesendet werden sollen. Sie können Flussvariablen nach Bedarf hinzufügen oder entfernen, je nachdem, welche Felder für Ihre SecOps-Analyse wichtig sind. Informationen dazu, wie Apigee-Ablaufvariablendaten SecOps-Datenfeldern zugeordnet werden, finden Sie unter Apigee in Google SecOps SIEM einbinden.

    <?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. Die Richtlinie als bedingten Schritt in einem API-Proxy anhängen. Eine Möglichkeit besteht darin, die Richtlinie in einer FaultRule im PostFlow anzuhängen, in der in der Regel sicherheitsrelevante Fehler ausgelöst werden. Beispiel:

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

    Wenn der API-Proxy, der diese Richtlinie verwendet, ausgeführt wird, werden Apigee-Logdaten an Google SecOps gesendet.

    Eine weitere gängige Methode besteht darin, die MessageLogging-Richtlinie im PostClientFlow der ProxyEndpoint-Antwort zu platzieren.

    Beachten Sie die folgenden Hinweise, wenn Sie die MessageLogging-Richtlinie an Ihren API-Proxy anhängen:

    • Platzieren Sie die Richtlinie in einer FaultRule. FaultRule ist der empfohlene Ort, um Sicherheitsausnahmen und Richtlinienverstöße zu protokollieren.
    • Platzieren Sie die Richtlinie im PostFlow. PostFlow ist ein weiterer geeigneter Ort, um Sicherheitsprobleme zu protokollieren.
    • Vermeiden Sie es, erfolgreiche Anfragen zu protokollieren. Beim Sicherheitsmonitoring, das sich auf Bedrohungen konzentriert, werden in der Regel Details protokolliert, wenn etwas schiefgeht (ein Fehler wird gemeldet). Wenn Sie jede erfolgreiche Anfrage mit dem vollständigen Nachrichteninhalte protokollieren, kann das zu einer übermäßigen Anzahl von Logs führen und die Kosten erhöhen.
    • In bestimmten Anwendungsfällen können Sie benutzerdefinierte Variablen verwenden. Wenn Sie beispielsweise die ursprüngliche Anfrage-URI in einem Fehlerablauf erfassen müssen, können Sie die AssignMessage-Richtlinie im Anfrage-PreFlow verwenden, um sie in eine benutzerdefinierte Variable (z. B. original.request.uri) zu kopieren und diese Variable dann in der MessageLogging-Richtlinie zu protokollieren.

Best Practices

Beachten Sie die folgenden Best Practices, wenn Sie Apigee mit Google SecOps konfigurieren:

  • Sicherheitskontext im Blick behalten:Protokollieren Sie nur die Ablaufvariablen, die einen wertvollen Kontext für die Sicherheitsüberwachung und die Erkennung von Bedrohungen bieten. Vermeiden Sie übermäßiges Logging von nicht sicherheitsrelevanten Daten.
  • Einheitliches Logging-Format verwenden:Verwenden Sie ein einheitliches Logging-Format für alle API-Proxys, die SecOps verwenden.
  • Sichere Dienstkonten verwenden:Halten Sie sich an die Sicherheits-Best Practices für die Verwaltung und Sicherung des Google Cloud-Dienstkontos, das für die SecOps-Aufnahme verwendet wird. Beschränken Sie die Berechtigung nach Möglichkeit auf „Log-Betrachter“.
  • SecOps-Feed im Blick behalten:Überprüfen Sie regelmäßig den Status Ihres SecOps-Feeds, um sicherzustellen, dass Logs erfolgreich und ohne Fehler aufgenommen werden.
  • SecOps-Regeln und ‑Dashboards verwenden:Sobald sicherheitsrelevante Logs in SecOps sind, können Sie spezifische Regeln und Dashboards entwickeln, um Sicherheitsrisiken anhand der detaillierten Informationen, die Sie protokollieren, zu erkennen und zu visualisieren.

Fehlerbehebung

In diesem Abschnitt werden verschiedene mögliche Probleme beschrieben, die bei der Konfiguration von Apigee mit SecOps auftreten können, und die Dinge, die Sie prüfen sollten.

Problem: Sicherheitsereignis-Logs werden nicht in Cloud Logging angezeigt

Prüfen Sie Folgendes:

  • Prüfen Sie, ob Ihre MessageLogging-Richtlinie mit dem Condition korrekt konfiguriert ist, damit sie ausgelöst wird, wenn ein Sicherheitsereignis eintritt.
  • Achten Sie darauf, dass die MessageLogging-Richtlinie an den entsprechenden Ablaufkontext angehängt ist, z. B. an eine FaultRule oder einen PostFlow.
  • Prüfen Sie, ob Cloud Logging in Ihrem Google Cloud-Projekt aktiviert ist.
  • Prüfen Sie alle Fehlermeldungen in Ihren Apigee-Proxy-Logs, die sich auf die MessageLogging-Richtlinie beziehen.

Problem: Sicherheitsereignisprotokolle werden nicht in SecOps angezeigt

  • Prüfen Sie, ob Ihr SecOps-Feed mit der richtigen Projekt-ID, dem richtigen Logfilter (damit die Logs aus Ihrer Sicherheits-Logging-Richtlinie erfasst werden) und den richtigen Dienstkontoanmeldedaten konfiguriert ist.
  • Prüfen Sie in der SecOps-Benutzeroberfläche den Status Ihres SecOps-Feeds auf Fehlermeldungen oder Probleme beim Erfassen.
  • Prüfen Sie, ob das von SecOps verwendete Dienstkonto die Rolle „Logs Viewer“ (Log-Betrachter) für Ihr Google Cloud-Projekt hat.
  • Prüfen Sie die JSON-Struktur Ihrer Logs in Cloud Logging, um sicherzustellen, dass sie wohlgeformt sind und die erwarteten Feldnamen enthalten.
  • Prüfen Sie, ob der entsprechende Google Cloud-Parser aktiviert ist.
  • Wenn Sie ein Parsing-Problem vermuten, sehen Sie sich einen Beispiel-Logeintrag in den SecOps-Rohdaten an, um zu sehen, wie er vor dem Parsen aufgenommen wurde. Wenn bestimmte Felder nicht wie erwartet extrahiert werden, müssen Sie möglicherweise die Dokumentation zum SecOps-Parser lesen oder prüfen, ob ein benutzerdefinierter Parser erforderlich ist.

Apigee in Google SecOps SIEM einbinden

In der folgenden Tabelle werden Apigee-Ablaufvariablennamen den entsprechenden Google SecOps SIEM-Feldnamen zugeordnet. Wenn Sie beispielsweise Apigee-Logdaten in Cloud Logging ansehen, wird die Ablaufvariable client.id dem SecOps SIEM-Feld principle_ip zugeordnet. Siehe auch Apigee-Logs erfassen.

Apigee-Ablaufvariable SecOps SIEM-Feldname Beschreibung
client.country principal.hostname Die HTTP-Host-IP, die der Anfrage zugeordnet ist, die vom ProxyEndpoint empfangen wird.
client.host principal.location.country_or_region Das Land im von der Client-App bereitgestellten TLS/SSL-Zertifikat. Proxyanfrage principal.location.country_or_region.
client.ip principle.ip Die IP-Adresse des Clients oder Systems, die die Nachricht an den Load-Balancer senden. Das kann die ursprüngliche Client-IP-Adresse oder die IP des Load-Balancers sein.
client.locality principal.location.city Der Ort (Stadt) im vom Client bereitgestellten TLS/SSL-Zertifikat.
client.port principal.port Der HTTP-Port, der der ursprünglichen Clientanfrage an den ProxyEndpoint zugeordnet ist.
client.state principal.location.state Der Status im vom Client bereitgestellten TLS/SSL-Zertifikat.
organization.name intermediary.cloud.project.name Name der Apigee-Organisation.
proxy.client.ip src.ip Die X-Forwarded-For-Adresse des eingehenden Aufrufs. Dies ist die IP-Adresse, die Apigee vom letzten externen TCP-Handshake erhalten hat. Dies kann der aufrufende Client oder ein Load Balancer sein.
proxy.name intermediary.resource.name Das Namensattribut, das für den ProxyEndpoint konfiguriert wurde.
proxy.pathsuffix intermediary.resource.attribute.labels[pathsuffix] „Der Wert des Pfadsuffixes in der URL, der vom Client gesendet und am ProxyEndpoint empfangen wird. Der Basispfad ist die Pfadkomponente ganz links, die einen API-Proxy innerhalb einer Umgebungsgruppe eindeutig identifiziert. Angenommen, Sie haben einen API-Proxy-Endpunkt mit dem Basispfad /v2/weatherapi konfiguriert. In diesem Fall enthält in einer an https://myhost.example.net/v2/weatherapi/forecastrss?w=12797282 gesendeten Anfrage die Variable „proxy.pathsuffix“ den String „/forecastrss“.
proxy.url intermediary.url „Ruft die vollständige URL ab, die der Proxy-Anfrage zugeordnet ist, die vom ProxyEndpoint erhalten wird, einschließlich eventuell vorhandener Abfrageparameter. Ein Beispiel zum Erstellen einer Anfrage-URL mit dem ursprünglichen Anfragehost (anstelle des in proxy.url verwendeten Routerhosts) finden Sie unter „Auf Anfragenachrichten zugreifen“.
request.uri target.resource.name Der Domainname des Zieldienstes, der die Antwort an den API-Proxy zurückgibt.
request.verb network.http.method Das für die Anfrage verwendete HTTP-Verb. Beispiele: GET, PUT und DELETE.
response.content security_result.description Nutzlastinhalt der Antwortnachricht, die vom Ziel zurückgegeben wird.
response.status.code network.http.response_code Der Antwortcode, der für eine Anfrage zurückgegeben wurde. Mit dieser Variable können Sie den Statuscode der Antwort überschreiben, der in „message.status.code“ gespeichert ist. Weitere Informationen finden Sie in der Nachricht.
system.region.name intermediary.location.name Der Name der Rechenzentrumsregion, in der der Proxy ausgeführt wird.
system.timestamp additional.fields[jsonPayload_system_timestamp] Die 64-Bit-lange Ganzzahl, die die Zeit angibt, zu der diese Variable gelesen wurde. Der Wert ist die Anzahl der seit Mitternacht am 1. Januar 1970 verstrichenen Millisekunden. Beispiel: 1534783015000.
system.uuid intermediary.process.pid oder intermediary.process.product_specific_process_id Die UUID des Nachrichtenverarbeiters des Proxys.
target.country target.location.country_or_region Das Land im vom Zielserver bereitgestellten TLS/SSL-Zertifikat.
target.host target.hostname Der Domainname des Zieldienstes, der die Antwort an den API-Proxy zurückgibt.
target.ip target.ip Die IP-Adresse des Zieldienstes, der die Antwort an den API-Proxy zurückgibt.
target.locality target.location.city Ort (Stadt) im vom Zielserver bereitgestellten TLS/SSL-Zertifikat.
target.organization target.resource_ancestors.name Organisation im vom Zielserver bereitgestellten TLS/SSL-Zertifikat.
target.port target.port Die Portnummer des Zieldienstes, der die Antwort an den API-Proxy zurückgibt.
target.scheme target.network.application_protocol Gibt je nach Anfragenachricht „http“ oder „https“ zurück.
target.state target.location.state Status des vom Zielserver bereitgestellten TLS/SSL-Zertifikats.
target.url target.url Die URL, die in der XML-Datei „TargetEndpoint“ oder in der dynamischen Ziel-URL konfiguriert ist, wenn „target.url“ während des Nachrichtenflusses festgelegt wird. Die Variable enthält keine zusätzlichen Pfadelemente oder Suchparameter. Gibt „null“ zurück, wenn sie außerhalb des Bereichs liegt oder anderweitig nicht festgelegt ist.

Hinweis: Legen Sie diese Variable mithilfe einer JavaScript-Richtlinie fest, die an den TargetEndpoint angehängt ist.