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 für die Aufnahme 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-Protokolldaten, 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 für die Aufnahme von Apigee-Logdaten in Google SecOps. Weitere Informationen finden Sie unter Google Cloud-Daten in Google Security Operations aufnehmen.

Vorbereitung

Sobald 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 ist aktiviert und Sie haben Erfahrung mit der Konfiguration und Verwendung von Cloud Logging.
  • Kenntnisse über Apigee-Ablaufvariablen
  • Sie sollten mit der Apigee MessageLogging-Richtlinie und der allgemeinen Verwendung und Konfiguration von Richtlinien vertraut sein.
  • (Optional) Kenntnisse darüber, wie Google SecOps-Parser zum Interpretieren aufgenommener Logs verwendet werden. SecOps-Parser sind standardmäßig integriert, um Apigee-Logs zu analysieren und zu verstehen, die gemäß der Message Logging-Richtlinie aufgenommen wurden.
  • Google Cloud IAM-Berechtigungen für die Verwendung der Cloud Logging API und IAM-Rollen für das SecOps-Dienstkonto

Apigee in SecOps einbinden

Wenn Sie Google SecOps als SIEM-Lösung verwenden, folgen Sie dieser Anleitung, um Apigee-Protokolldaten 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 Apigee-Logdaten, die an Cloud Logging gesendet werden, von SecOps analysiert. Ausführliche Informationen zum Parser und dazu, wie Apigee-Variablendaten in SecOps-Datenfeldern zugeordnet werden, finden Sie unter Apigee in Google SecOps SIEM integrieren. Siehe auch Apigee-Logs erfassen.

So integrieren Sie Apigee mit SecOps unter Verwendung der Richtlinie „MessageLogging“:

  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. Die Richtlinie gibt eine große Anzahl von Ablaufvariablen an, die an Cloud Logging gesendet werden sollen. Sie können beliebig viele Flussvariablen hinzufügen oder entfernen, je nachdem, welche Felder Sie für Ihre SecOps-Analyse als wichtig erachten. Informationen dazu, wie Daten von Apigee-Ablaufvariablen zu 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. Hängen Sie die Richtlinie als bedingten Schritt in einem API-Proxy an. Eine Möglichkeit besteht darin, die Richtlinie in einer FaultRule im PostFlow anzuhängen, wo in der Regel sicherheitsbezogene Fehler auftreten. 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 übliche Praxis 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.
    • Protokollieren Sie keine erfolgreichen Anfragen. Bei der sicherheitsorientierten Überwachung von Bedrohungen werden in der Regel Details protokolliert, wenn etwas schiefgeht (ein Fehler auftritt). Wenn Sie jede erfolgreiche Anfrage mit dem vollständigen Nachrichteninhalt protokollieren, kann das zu einer übermäßigen Anzahl von Protokollen und höheren Kosten führen.
    • Für bestimmte Anwendungsfälle können Sie benutzerdefinierte Variablen verwenden. Wenn Sie beispielsweise den ursprünglichen Anfrage-URI in einem Fehlerablauf erfassen möchten, können Sie die Richtlinie „Nachricht zuweisen“ im PreFlow-Abschnitt der Anfrage verwenden, um ihn in eine benutzerdefinierte Variable (z. B. original.request.uri) zu kopieren und diese Variable dann in der Richtlinie „Nachrichtenprotokollierung“ zu erfassen.

Best Practices

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

  • Konzentrieren Sie sich auf den Sicherheitskontext: Protokollieren Sie nur die Ablaufvariablen, die einen wertvollen Kontext für die Sicherheitsüberwachung und Bedrohungserkennung bieten. Vermeiden Sie eine übermäßige Protokollierung nicht sicherheitsbezogener Daten.
  • Verwenden Sie ein einheitliches Logging-Format: Verwenden Sie für alle API-Proxys, die SecOps verwenden, dasselbe Logging-Format.
  • Sichere Dienstkonten verwenden:Beachten Sie die Best Practices für die Verwaltung und Sicherheit des Google Cloud-Dienstkontos, das für die SecOps-Aufnahme verwendet wird. Beschränken Sie die Berechtigung nach Möglichkeit auf den Log-Betrachter.
  • SecOps-Feed überwachen:Überwachen Sie regelmäßig den Zustand und den Status Ihres SecOps-Feeds, um sicherzustellen, dass Protokolle erfolgreich und ohne Fehler aufgenommen werden.
  • SecOps-Regeln und -Dashboards verwenden:Sobald sich sicherheitsrelevante Protokolle in SecOps befinden, können Sie spezielle Regeln und Dashboards entwickeln, um Sicherheitsbedrohungen anhand der detaillierten Informationen zu erkennen und zu visualisieren, die Sie protokollieren.

Fehlerbehebung

In diesem Abschnitt werden einige mögliche Probleme beschrieben, die beim Konfigurieren von Apigee mit SecOps auftreten können, und es wird erläutert, was Sie prüfen sollten.

Problem: Sicherheitsereignisprotokolle werden in Cloud Logging nicht angezeigt

Prüfen Sie Folgendes:

  • Prüfen Sie, ob Ihre MessageLogging-Richtlinie mit dem Condition-Element richtig konfiguriert ist, um bei einem Sicherheitsereignis ausgelöst zu werden.
  • Die Richtlinie „Nachrichten-Logging“ muss dem entsprechenden Ablaufkontext angehängt sein, z. B. einer FaultRule oder einem 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 in SecOps nicht angezeigt

  • Prüfen Sie, ob Ihr SecOps-Feed mit der richtigen Projekt-ID, dem richtigen Log-Filter (damit die Logs aus Ihrer Sicherheitsprotokollierungsrichtlinie erfasst werden) und den Anmeldedaten für das Dienstkonto konfiguriert ist.
  • Prüfen Sie den Status Ihres SecOps-Feeds in der SecOps-Benutzeroberfläche auf Fehlermeldungen oder Probleme bei der Datenaufnahme.
  • Das von SecOps verwendete Dienstkonto muss die Rolle „Logs Viewer“ für Ihr Google Cloud-Projekt haben.
  • Prüfen Sie die JSON-Struktur Ihrer Protokolle in Cloud Logging, um sicherzustellen, dass sie korrekt formatiert sind und die erwarteten Feldnamen enthalten.
  • Prüfen Sie, ob der entsprechende Google Cloud-Parser aktiviert ist.
  • Wenn Sie vermuten, dass ein Problem beim Parsen vorliegt, 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 des SecOps-Parsers lesen oder überlegen, 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 sich 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 Name des SecOps SIEM-Felds 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 klar identifiziert. Angenommen, Sie haben einen API-Proxy-Endpunkt mit dem Basispfad /v2/weatherapi konfiguriert. In diesem Fall enthält in einer an https://myhost.beispiel.de/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 „Zugriffsanfragenachrichten“.
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. Beispiel: 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. Dieser 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.