Masquer et ne pas afficher des données

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

Consultez la documentation d'Apigee Edge.

Lorsque vous déboguez des appels d'API dans Apigee, le contenu peut parfois contenir des données sensibles, telles que des cartes de crédit ou des informations médicales personnellement identifiables qui doivent être masquées.

Apigee propose des méthodes permettant de masquer ou de ne pas afficher les données sensibles des sessions Trace et de débogage.

Masquer les données sensibles

Apigee vous permet de définir des configurations de masque pour masquer des données spécifiques dans les sessions de trace et de débogage. Lorsque les données sont masquées, elles sont remplacées par des astérisques dans le résultat de la trace. Vous pouvez masquer les données sensibles et conserver les données non sensibles telles quelles. Exemple :

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

La configuration du masque est une ressource unique (Singleton) que vous définissez au niveau de l'environnement. Par défaut, aucun masquage de données n'est appliqué.

Le masquage des données ne s'applique qu'aux données capturées dans une session de débogage pour un proxy d'API. Le masquage des données n'a pas d'incidence sur les données envoyées aux cibles ou aux applications clientes. Si vous modifiez la configuration de masquage de données, vous devez démarrer une nouvelle session de débogage pour voir l'effet de votre modification.

Structure d'une configuration de masque

Les configurations de masque sont des fichiers au format JSON qui vous permettent d'identifier des données sensibles dans les sources suivantes :

Charges utiles XML : à l'aide de XPath, vous identifiez les éléments XML à filtrer à partir des charges utiles de requête ou de message de réponse.
Charges utiles JSON : à l'aide de JSONPath, vous identifiez les propriétés JSON à filtrer à partir des charges utiles de requête ou de message de réponse.
Variables de flux : vous pouvez spécifier une liste de variables qui doivent être masquées dans la sortie de débogage. Lorsque vous spécifiez les variables de flux request.content, response.content ou message.content, le corps de la requête/réponse est également masqué.

Voici un exemple de structure de base d'une configuration de masque au format JSON. Pour en savoir plus sur les champs de configuration de masque présentés dans l'exemple, consultez la section 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"
  ]
}

Afficher la configuration de masque dans un environnement à l'aide de l'API

Pour afficher la configuration de masque dans un environnement, envoyez une requête GET à la ressource suivante :

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

Exemple :

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

Où $TOKEN est défini sur votre jeton d'accès OAuth 2.0, comme décrit dans la section Obtenir un jeton d'accès OAuth 2.0. Pour en savoir plus sur les options curl utilisées dans cet exemple, consultez la section Utiliser curl. Pour obtenir une description des variables d'environnement utilisées, consultez la section Définir des variables d'environnement pour les requêtes API Apigee.

Voici un exemple de réponse :

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

Mettre à jour la configuration de masque dans un environnement à l'aide de l'API

Pour mettre à jour la ressource unique de la configuration de masque dans un environnement, envoyez une requête PATCH à la ressource suivante :

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

Vous avez également la possibilité de transmettre les paramètres de requête suivants :

Définissez le paramètre de requête updateMask pour spécifier un masque de champ qui inclut une liste de noms de champs complets séparés par une virgule dans le masque de débogage. Par exemple : "requestJSONPaths"
Définissez le paramètre de requête replaceRepeatedFields pour indiquer si vous souhaitez remplacer les valeurs existantes dans le masque de débogage lors de la mise à jour. Les valeurs (false) sont ajoutées par défaut.

Exemple :

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"
     ]
   }'

Masquer des XML à l'échelle d'un espace de noms

Si vous souhaitez masquer des données XML et que ces données utilisent des espaces de noms XML, votre configuration de masque doit référencer ces espaces de noms avec l'élément namespaces. Cela est valable que la charge utile XML utilise un espace de noms par défaut ou un préfixe d'espace de noms.

Par exemple, supposons que vous souhaitiez masquer le nom de l'employé dans la charge utile de la requête et que le XML n'utilise pas les espaces de noms XML :

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

Par conséquent, la configuration du masque de débogage ne nécessite pas l'élément namespaces :

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

Si la charge utile XML utilise des espaces de noms avec des préfixes :

<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>

La configuration du masque doit alors contenir l'élément namespaces. Vous pouvez choisir n'importe quel préfixe d'espace de noms valide dans la configuration de masque de débogage. Le préfixe d'espace de noms dans la configuration de masque de débogage peut être identique au préfixe d'espace de noms utilisé dans le fichier XML, mais ce n'est pas obligatoire.

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

Si la charge utile XML utilise un espace de noms sans préfixe (et donc l'espace de noms par défaut) :

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

La configuration du masque de débogage doit toujours définir un préfixe dans l'élément namespaces correspondant à cet espace de noms par défaut. Vous pouvez utiliser n'importe quel préfixe unique.

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

Autres remarques concernant la configuration

Avec les éléments de configuration *XPaths et *JSONPaths, vous pouvez masquer les données qui apparaissent dans les messages request, response ou fault. Cependant, le contenu complet du message peut également être capturé par des sessions de débogage. Vous pouvez également configurer request.content ou response.content dans la section variables pour empêcher l'affichage des données sensibles.
Si vous utilisez la règle ServiceCallout pour effectuer une requête, les informations incluses dans la requête et la réponse pour cet appel ne sont pas masquées à l'aide des éléments de configuration tels que requestXPaths ou responseJSONPaths. Si vous souhaitez masquer ces données, vous devez spécifier un nom de variable pour les messages de requête et de réponse dans la règle ServiceCallout, puis spécifier ces variables dans la section variables du masque de débogage. Par exemple, si votre règle ServiceCallout utilise ce qui suit :
```
<ServiceCallout name='SC-1'>
  <Request variable='rbacRequest'>
    <Set>
      <Payload contentType='application/json'>{ ... }</Payload>
       ...
```
Vous devez alors inclure rbacRequest.content dans l'élément variables pour la configuration du masque de débogage.
```
{
  ...
  "variables": [
    "request.content",
    "response.content",
    "rbacRequest.content"
  ]
}
```

Masquer les données sensibles

En plus du masquage, vous pouvez empêcher l'affichage des données sensibles dans l'outil Trace et les sessions de débogage en choisissant un nom commençant par private. pour vos variables personnalisées.

Par exemple, lorsque vous utilisez la la règle des opérations de mappage clé-valeur pour récupérer une valeur à partir d'un mappage clé-valeur, vous pouvez choisir le nom de la variable comme suit pour vous assurer que la valeur n'apparaît pas dans les sessions Trace ou de débogage :

<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>

Les variables sans le préfixe private. s'affichent en clair dans les sessions Trace et de débogage, même si les données proviennent d'un datastore chiffré tel qu'un mappage clé-valeur. Utilisez le masquage si vous souhaitez masquer ces valeurs.