Daten maskieren und ausblenden

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Bei der Fehlerbehebung von API-Aufrufen in Apigee können die Inhalte manchmal sensible Daten wie Kreditkartendaten oder personenidentifizierbare Informationen enthalten, die maskiert werden müssen.

Apigee bietet verschiedene Möglichkeiten zum Maskieren oder Ausblenden sensibler Daten von Trace- und Debug-Sitzungen.

Sensible Daten maskieren

Mit Apigee können Sie Maskenkonfigurationen definieren, um bestimmte Daten in Trace- und Debug-Sitzungen zu maskieren. Wenn Daten maskiert werden, werden sie in der Trace-Ausgabe durch Sternchen ersetzt. Sie können sensible Daten maskieren und nicht sensible Daten unverändert lassen. Beispiele:

<ServiceRequest>
  <request-id>B540A938-F551</request-id>
  <customer-name>**********</customer-name>
</ServiceRequest>

Die Maskenkonfiguration ist eine Singleton-Ressource, die Sie auf Umgebungsebene definieren. Standardmäßig ist keine Datenmaskierung aktiviert.

Die Datenmaskierung gilt nur für Daten, die in einer Debug-Sitzung für einen API-Proxy erfasst werden. Die Datenmaskierung wirkt sich nicht auf die Daten aus, die an Ziele oder Clientanwendungen gesendet werden. Wenn Sie Ihre Datenmaskierungskonfiguration ändern, müssen Sie eine neue Debug-Sitzung starten, um die Auswirkungen Ihrer Änderung zu sehen.

Struktur einer Maskenkonfiguration

Maskenkonfigurationen sind JSON-formatierte Dateien, mit denen Sie sensible Daten in den folgenden Quellen identifizieren können:

• XML-Nutzlasten: Mit XPath identifizieren Sie XML-Elemente, die aus den Nutzlasten der Anfrage- oder Antwortnachricht gefiltert werden sollen.
• JSON-Nutzlasten: Mit JSONPath identifizieren Sie JSON-Attribute, die aus der Nutzlast von Anfrage- oder Antwortnachrichten gefiltert werden sollen.
• Flussvariablen: Sie können eine Liste von Variablen angeben, die in der Debug-Ausgabe maskiert werden sollen. Wenn Sie die Flussvariablen request.content, response.content oder message.content angeben, wird der Anfrage-/Antworttext ebenfalls maskiert.

Im Folgenden finden Sie ein Beispiel für die grundlegende Struktur einer Maskenkonfiguration im JSON-Format. Weitere Informationen zu den im Beispiel gezeigten Maskenkonfigurationsfeldern finden Sie unter DebugMask.

{
  "namespaces": {
    "myco": "http://example.com"
  },
  "requestXPaths": [
    "/myco:Greeting/myco:User"
  ],
  "responseXPaths": [
    "/myco:Greeting/myco:User"
  ],
  "faultXPaths": [
    "/myco:Greeting/myco:User"
  ],
  "requestJSONPaths": [
    "$.store.book[*].author"
  ],
  "responseJSONPaths": [
    "$.store.book[*].author"
  ],
  "faultJSONPaths": [
    "$.store.book[*].author"
  ],
  "variables": [
    "request.header.user-name",
    "request.formparam.password",
    "myCustomVariable"
  ]
}

Maskenkonfiguration in einer Umgebung mit der API aufrufen

Sie können die Maskenkonfiguration in einer Umgebung mit GET an die folgende Ressource abrufen:

/organizations/{org}/environments/{env}/debugmask

Beispiele:

curl "https://apigee.googleapis.com/v1/organizations/myorg/environments/test/debugmask" \
  -X GET \
  -H "Authorization: Bearer $TOKEN"

Dabei ist $TOKEN auf Ihr OAuth 2.0-Zugriffstoken festgelegt. Weitere Informationen hierzu finden Sie unter OAuth 2.0-Zugriffstoken abrufen. Informationen zu den in diesem Beispiel verwendeten curl-Optionen finden Sie unter curl verwenden. Eine Beschreibung der verwendeten Umgebungsvariablen findet sich unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

Im Folgenden finden Sie ein Beispiel für die Antwort:

{
  "name": "organizations/myorg/environments/test/debugmask"
  "namespaces": {
    "myco": "http://example.com"
  },
  "requestXPaths": [
    "/myco:Greeting/myco:User"
  ],
  "responseXPaths": [
    "/myco:Greeting/myco:User"
  ]
}

Maskenkonfiguration in einer Umgebung mit der API aktualisieren

Um die Singleton-Ressource für die Maskenkonfiguration in einer Umgebung zu aktualisieren, senden Sie eine PATCH-Funktion an die folgende Ressource:

/organizations/{org}/environments/{env}/debugmask

Optional können Sie die folgenden Abfrageparameter übergeben:

• Legen Sie den Abfrageparameter updateMask fest, um eine Feldmaske anzugeben, die eine durch Kommas getrennte Liste vollständig qualifizierter Feldnamen in der Debug-Maske enthält. Beispiel: "requestJSONPaths"
• Legen Sie den Abfrageparameter replaceRepeatedFields fest, um anzugeben, ob vorhandene Werte in der Debug-Maske ersetzt werden sollen. Standardmäßig werden Werte angehängt (false).

Beispiel:

curl "https://apigee.googleapis.com/v1/organizations/myorg/environments/test/debugmask" \
  -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-type: application/json" \
  -d \
  '{
     "namespaces": {
       "ns1": "http://example.com"
     },
     "requestXPaths": [
       "/ns1:employee/ns1:name"
     ]
   }'

Dabei ist $TOKEN auf Ihr OAuth 2.0-Zugriffstoken festgelegt. Weitere Informationen hierzu finden Sie unter OAuth 2.0-Zugriffstoken abrufen. Informationen zu den in diesem Beispiel verwendeten curl-Optionen finden Sie unter curl verwenden. Eine Beschreibung der verwendeten Umgebungsvariablen findet sich unter Umgebungsvariablen für Apigee API-Anfragen festlegen.

Namespace-bezogenes XML maskieren

Wenn Sie XML-Daten maskieren möchten und diese Daten XML-Namespaces verwenden, muss die Maskenkonfiguration mit dem Element namespaces auf diese Namespaces verweisen. Das gilt unabhängig davon, ob für die XML-Nutzlast ein Standard-Namespace oder ein Namespace-Präfix verwendet wird.

Angenommen, Sie möchten den Namen des Mitarbeiters in der Anfragenutzlast maskieren und die XML verwendet keine XML-Namespaces:

<employee>
  <name>Shanmu Tharman</name>
  <age>50</age>
</employee>

Daher erfordert die debugmask-Konfiguration nicht das Element namespaces:

{
  "requestXPaths": [
    "/employee/name"
  ]
}

Wenn die XML-Nutzlast Namespaces mit Präfixen verwendet:

<cym:employee xmlns:cym="http://cymbalgroup.com" xmlns:id="http://cymbalgroup.com/identity">
  <id:name>Shanmu Tharman</id:name>
  <id:age>50</id:age>
</cym:employee>

Dann sollte die Maskenkonfiguration das Element namespaces enthalten. Sie können in der debugmask-Konfiguration ein gültiges Namespace-Präfix auswählen. Das Namespace-Präfix in der debugmask-Konfiguration kann mit dem in der XML verwendeten Namespace-Präfix identisch sein; dies ist jedoch nicht erforderlich.

{
  "namespaces": {
    "cym": "http://cymbalgroup.com",
    "idns": "http://cymbalgroup.com/identity"
  },
  "requestXPaths": [
    "/cym:employee/idns:name"
  ]
}

Wenn die XML-Nutzlast einen Namespace ohne Präfix verwendet, gilt der Standard-Namespace:

<employee xmlns="http://cymbalgroup.com" xmlns:id="http://cymbalgroup.com/identity">
  <id:name>Shanmu Tharman</id:name>
  <id:age>50</id:age>
</employee>

In der debugmask-Konfiguration muss dann weiterhin ein Präfix im Element namespaces definiert werden, das diesem Standard-Namespace entspricht. Sie können ein beliebiges eindeutiges Präfix verwenden.

{
  "namespaces": {
    "p1": "http://cymbalgroup.com",
    "id": "http://cymbalgroup.com/identity"
  },
  "requestXPaths": [
    "/p1:employee/id:name"
  ]
}

Sonstige Konfigurationshinweise

• Mit den Konfigurationselementen *XPaths und *JSONPaths können Sie Daten maskieren, die in den Nachrichten request, response oder fault erscheinen. Der vollständige Nachrichteninhalt kann jedoch auch von Debug-Sitzungen erfasst werden. Sie können auch request.content oder response.content im Bereich variables konfigurieren, um zu verhindern, dass sensible Daten angezeigt werden.

• Wenn Sie die ServiceCallout-Richtlinie für eine Anfrage verwenden, werden die Informationen in der Anfrage und Antwort für diese Zusatzinformationen nicht mit den Konfigurationselementen wie requestXPaths oder responseJSONPaths maskiert. Wenn Sie diese Daten maskieren möchten, geben Sie in der ServiceCallout-Richtlinie einen Variablennamen für die Anfrage- und Antwortnachrichten an und legen Sie diese Variablen dann im Abschnitt variables der debugmask fest. Wenn Ihre ServiceCallout-Richtlinie beispielsweise Folgendes verwendet:

  <ServiceCallout name='SC-1'>
    <Request variable='rbacRequest'>
      <Set>
        <Payload contentType='application/json'>{ ... }</Payload>
         ...
  

  Dann fügen Sie rbacRequest.content in das Element variables für die debugmask-Konfiguration ein.

  {
    ...
    "variables": [
      "request.content",
      "response.content",
      "rbacRequest.content"
    ]
  }

Sensible Daten ausblenden

Zusätzlich zur Maskierung können Sie sogar verhindern, dass sensible Daten im Trace-Tool und in Debug-Sitzungen angezeigt werden. Wählen Sie dazu für Ihre benutzerdefinierten Variablen einen Namen aus, der mit private. beginnt.

Wenn Sie beispielsweise die Richtlinie KeyValueMapOperations zum Abrufen eines Werts aus einer Schlüssel/Wert-Paar-Zuordnung verwenden, können Sie den Variablennamen so auswählen, dass die Werte nicht in Trace- oder Debug-Sitzungen angezeigt werden:

<KeyValueMapOperations name='KVM-Get-1'>
    <Scope>environment</Scope>
    <ExpiryTimeInSecs>300</ExpiryTimeInSecs>
    <MapName>settings</MapName>
    <Get assignTo='private.privatekey'>
      <Key>
        <Parameter>rsa_private_key</Parameter>
      </Key>
    </Get>
  </KeyValueMapOperations>

Variablen ohne das Präfix private. werden in Trace und in Debug-Sitzungen als Klartext angezeigt, auch wenn die Daten aus einem verschlüsselten Datenspeicher wie einer Schlüssel/Wert-Zuordnung stammen. Verwenden Sie die Maskierung, wenn Sie diese Werte maskieren möchten.