Esta página se ha traducido con Cloud Translation API.

Enmascarar y ocultar datos

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

Consulta la documentación de Apigee Edge.

Cuando depuras llamadas a APIs en Apigee, el contenido puede incluir datos sensibles, como tarjetas de crédito o información sanitaria personal identificable (IPI) que debe ocultarse.

Apigee ofrece diferentes formas de enmascarar u ocultar datos sensibles de las sesiones de depuración. Si usas el enmascaramiento para los datos recogidos en sesiones de depuración, Apigee realiza el enmascaramiento en los nodos de la pasarela antes de transmitir los datos de la sesión de depuración al plano de control.

Enmascarar datos sensibles

Apigee te permite definir configuraciones de máscara para enmascarar datos específicos en sesiones de seguimiento y depuración. Cuando se enmascaran los datos, se sustituyen por asteriscos en la salida de la traza. Puedes enmascarar los datos sensibles y mantener los 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 se define a nivel de entorno. De forma predeterminada, no se aplica ningún enmascaramiento de datos.

El enmascaramiento de datos solo se aplica a los datos recogidos en una sesión de depuración de un proxy de API. El enmascaramiento de datos no afecta a los datos que se envían a los destinos ni a las aplicaciones cliente. Si cambia la configuración de la máscara de datos, debe iniciar una nueva sesión de depuración para ver el efecto del cambio.

Estructura de una configuración de máscara

Las configuraciones de máscara son archivos con formato JSON que te permiten identificar datos sensibles en las siguientes fuentes:

Cargas útiles XML: con XPath, identifica los elementos XML que se van a filtrar de las cargas útiles de los mensajes de solicitud o respuesta.
Cargas útiles de JSON: con JSONPath, identificas las propiedades de JSON que se van a filtrar de las cargas útiles de los mensajes de solicitud o respuesta.
Variables de flujo: puedes especificar una lista de variables que se deben enmascarar en la salida de depuración. Cuando especifica las variables de flujo request.content, response.content o message.content, también se enmascara el cuerpo de la solicitud o la respuesta.

A continuación, se muestra 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 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"
  ]
}

Ver la configuración de la máscara en un entorno mediante la API

Para ver la configuración de la máscara en un entorno, envía una solicitud 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"

Donde $TOKEN es tu token de acceso OAuth 2.0, tal como se describe en Obtener un token de acceso OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usar curl. Para ver una descripción de las variables de entorno que puedes usar, consulta Definir variables de entorno para solicitudes a la API de Apigee.

A continuación, se muestra 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"
  ]
}

Actualizar la configuración de la máscara en un entorno mediante la API

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

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

También puede transferir los siguientes parámetros de consulta:

Define el parámetro de consulta updateMask para especificar una máscara de campo que incluya una lista separada por comas de nombres completos de campos en la máscara de depuración. Por ejemplo: "requestJSONPaths"
Define el parámetro de consulta replaceRepeatedFields para especificar si se deben sustituir los valores de la máscara de depuración al hacer una actualización. De forma predeterminada, los valores se añaden (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"
     ]
   }'

Enmascarar XML con permisos de espacio de nombres

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

Por ejemplo, supongamos que quiere enmascarar el nombre del empleado en la carga útil de la solicitud y que 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 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>

A continuación, 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 de la configuración de debugmask puede ser el mismo que el prefijo de espacio de nombres que se usa en el archivo XML, pero 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>

En ese caso, la configuración de debugmask debe definir un prefijo en el elemento namespaces correspondiente a ese espacio de nombres predeterminado. Puedes usar el prefijo único que quieras.

{
  "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, puede enmascarar los datos que aparecen en los mensajes request, response o fault. Sin embargo, es posible que las sesiones de depuración también capturen 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 hacer una solicitud, la información de la solicitud y la respuesta de esa llamada no se ocultará con elementos de configuración como requestXPaths o responseJSONPaths. Si quiere enmascarar esos datos, debe especificar un nombre de variable para los mensajes de solicitud y respuesta en la política ServiceCallout y, a continuación, especificar esas variables en la sección variables de debugmask. Por ejemplo, si tu política ServiceCallout usa:
```
<ServiceCallout name='SC-1'>
  <Request variable='rbacRequest'>
    <Set>
      <Payload contentType='application/json'>{ ... }</Payload>
       ...
```
A continuación, debes incluir rbacRequest.content en el elemento variables para la configuración de debugmask.
```
{
  ...
  "variables": [
    "request.content",
    "response.content",
    "rbacRequest.content"
  ]
}
```

Ocultar datos sensibles

Además de enmascarar datos sensibles, puedes evitar que aparezcan en la herramienta de seguimiento y en las sesiones de depuración eligiendo un nombre que empiece por private. para tus variables personalizadas.

Por ejemplo, al usar la política Operaciones de asignación de clave a valor para recuperar un valor de una asignación de clave a valor, puede elegir el nombre de la variable de la siguiente manera para asegurarse 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 sin cifrar en las sesiones de seguimiento y depuración, aunque los datos procedan de un almacén de datos cifrado, como un mapa de pares clave-valor. Usa el enmascaramiento si quieres enmascarar estos valores.

Enmascarar y ocultar datos Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.