Enmascara y oculta datos

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Cuando depuras llamadas a las API en Apigee, el contenido a veces puede contener datos sensibles, como tarjetas de crédito o información de salud de identificación personal (PHI) que debe enmascararse.

Apigee proporciona diferentes formas de ocultar o enmascarar datos sensibles de sesiones de seguimiento y depuración.

Enmascara datos sensibles

Apigee te permite definir las opciones de configuración de máscaras para enmascarar datos específicos en sesiones de seguimiento y depuración. Cuando se enmascaran los datos, se reemplazan por asteriscos en el seguimiento de resultados. Puedes enmascarar datos sensibles y mantener los datos no sensibles sin cambios. Por ejemplo:

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

La configuración de la máscara es un recurso singleton que defines a nivel del entorno. De forma predeterminada, no está vigente el enmascaramiento de datos.

El enmascaramiento de datos se aplica solo a los datos capturados en una sesión de depuración para un proxy de API. El enmascaramiento de datos no afecta los datos que se envían a destinos o aplicaciones cliente. Si cambias la configuración del enmascaramiento de datos, debes iniciar una nueva sesión de depuración para ver el efecto del cambio.

Estructura de una configuración de la máscara.

Las opciones de configuración de las máscaras son archivos con formato JSON que te permiten identificar datos sensibles en las siguientes fuentes:

Cargas útiles XML: con XPath, puedes identificar elementos XML para filtrar de cargas útiles de solicitud o respuesta.
Cargas útiles JSON: con JSONPath, puedes identificar las propiedades JSON que se filtrarán de las cargas útiles de mensajes de respuesta o solicitud.
Variables de flujo: Puedes especificar una lista de variables que se deben enmascarar en el resultado de la depuración. Cuando especificas las variables de flujo request.content, response.content o message.content, el cuerpo de la solicitud o respuesta también se enmascara.

A continuación, se proporciona un ejemplo de la estructura básica de una configuración de máscara en formato JSON. Para obtener más información sobre los campos de configuración de la máscara que se muestran en el ejemplo, consulta 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"
  ]
}

Visualiza la configuración del enmascaramiento en un entorno mediante la API

Para ver la configuración de la máscara en un entorno, envía una operación GET al siguiente recurso:

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

Por ejemplo:

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

En el ejemplo anterior, $TOKEN está configurado como tu token de acceso de OAuth 2.0, como se describe en Obtén un token de acceso de OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usa curl. Para obtener una descripción de las variables de entorno utilizadas, consulta Configura variables de entorno para solicitudes a la API de Apigee.

A continuación, se proporciona un ejemplo de la respuesta.

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

Actualiza la configuración del enmascaramiento en un entorno mediante la API

Para actualizar el recurso singleton de configuración de la máscara en un entorno, envía una operación PATCH al siguiente recurso:

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

De manera opcional, puedes pasar los siguientes parámetros de búsqueda:

Establece el parámetro de consulta updateMask para que especifique una máscara de campo que incluya una lista separada por comas de los nombres de campos completamente calificados en la máscara de depuración. Por ejemplo: "requestJSONPaths"
Configura el parámetro de búsqueda replaceRepeatedFields para especificar si se deben reemplazar los valores existentes en la máscara de depuración cuando se realiza una actualización. De forma predeterminada, se agregan valores (false)

Por ejemplo:

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

Enmascara XML con alcance de espacio de nombres

Si deseas enmascarar datos XML y esos datos usan espacios de nombres XML, tu configuración de máscara debe hacer referencia a esos espacios de nombres con el elemento namespaces. Esto se aplica sin importar si la carga útil de XML usa un espacio de nombres predeterminado o un prefijo de espacio de nombres.

Por ejemplo, supongamos que deseas enmascarar el nombre del empleado en la carga útil de la solicitud y el XML no usa espacios de nombres XML:

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

Por lo tanto, la configuración de debugmask no requiere el elemento namespaces:

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

Si la carga útil de XML usa espacios de nombres con prefijos:

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

Luego, la configuración de la máscara debe contener el elemento namespaces: Puedes elegir cualquier prefijo de espacio de nombres válido en la configuración de debugmask. El prefijo de espacio de nombres en la configuración de debugmask puede ser el mismo que el prefijo de espacio de nombres usado en el XML, pero eso no es obligatorio.

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

Si la carga útil XML usa un espacio de nombres sin prefijo, es decir, el espacio de nombres predeterminado:

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

Luego, la configuración de la máscara de depuración debe definir un prefijo en el elemento namespaces correspondiente a ese espacio de nombres predeterminado. Puedes usar cualquier prefijo único que desees.

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

Otras notas de configuración

Con los elementos de configuración *XPaths y *JSONPaths, puedes enmascarar los datos que aparecen en los mensajes request, response o fault. Sin embargo, las sesiones de depuración también pueden capturar el contenido completo del mensaje. También puedes configurar request.content o response.content en la sección variables para evitar que se muestren datos sensibles.
Si usas la política ServiceCallout para realizar una solicitud, la información en la solicitud y la respuesta de ese texto destacado no se enmascarará con los elementos de configuración como requestXPaths o responseJSONPaths. Si deseas enmascarar esos datos, debes especificar un nombre de variable para los mensajes de solicitud y respuesta en la política ServiceCallout y, luego, especificar esas variables en la sección variables de la máscara de depuración. Por ejemplo, si tu política ServiceCallout usa lo siguiente:
```
<ServiceCallout name='SC-1'>
  <Request variable='rbacRequest'>
    <Set>
      <Payload contentType='application/json'>{ ... }</Payload>
       ...
```
Entonces, debes incluir rbacRequest.content en el elemento variables para la configuración de debugmask.
```
{
  ...
  "variables": [
    "request.content",
    "response.content",
    "rbacRequest.content"
  ]
}
```

Oculta datos sensibles

Además del enmascaramiento, puedes evitar que los datos sensibles aparezcan en la herramienta de seguimiento y las sesiones de depuración si eliges un nombre que comience con private. para tus variables personalizadas.

Por ejemplo, cuando uses la política de operaciones de mapas de clave-valor para recuperar un valor de un mapa de pares clave-valor, puedes elegir el nombre de la variable de la siguiente manera para asegurarte de que el valor no aparezca en las sesiones de seguimiento o de depuración:

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

Las variables sin el prefijo private. se muestran en texto claro en las sesiones de seguimiento y depuración, incluso si los datos se originan en un almacén de datos encriptado, como un mapa de pares clave-valor. Usa el enmascaramiento si deseas enmascarar estos valores.