Questa pagina si applica a Apigee e Apigee ibridi.
Visualizza documentazione di Apigee Edge.
Quando esegui il debug delle chiamate API in Apigee, i contenuti a volte possono contenere dati sensibili, carte di credito o dati sanitari che consentono l'identificazione personale (PHI) che devono essere mascherati.
Apigee offre diversi modi per mascherare o nascondere i dati sensibili Trace e sessioni di debug.
Mascheramento dei dati sensibili
Apigee consente di definire
<ServiceRequest>
<request-id>B540A938-F551</request-id>
<customer-name>**********</customer-name>
</ServiceRequest>
La configurazione della maschera è una risorsa singleton che definisci a livello di ambiente. Per impostazione predefinita, non è attivo alcun mascheramento dei dati.
Il mascheramento dei dati si applica solo ai dati acquisiti in una sessione di debug per un proxy API. Il mascheramento dei dati non influisce sui dati inviati a destinazioni o applicazioni client. Se modifichi la configurazione di mascheramento dei dati, devi avviare una nuova sessione di debug per vedere l'effetto della modifica.
Struttura della configurazione di una maschera
Maschera sono file in formato JSON che consentono di identificare i dati sensibili nelle seguenti origini:
- Payload XML: utilizzando XPath, identifica gli elementi XML da filtrare dalla richiesta o payload dei messaggi di risposta.
- Payload JSON: utilizzando JSONPath, identifichi le proprietà JSON da cui filtrare payload dei messaggi di richiesta e risposta.
- Variabili di flusso: puoi specificare un elenco di variabili che devono essere mascherate nel debug.
come output. Se specifichi
request.content
,response.content
, omessage.content
variabili di flusso, anche il corpo della richiesta/risposta mascherato.
Di seguito è riportato un esempio della struttura di base di una configurazione di maschera in formato JSON. Per ulteriori informazioni sui campi di configurazione della maschera mostrati nell'esempio, 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" ] }
Visualizzazione della configurazione della maschera in un ambiente utilizzando l'API
Per visualizzare la configurazione della maschera in un ambiente, invia un comando GET alla seguente risorsa:
/organizations/{org}/environments/{env}/debugmask
Ad esempio:
curl "https://apigee.googleapis.com/v1/organizations/myorg/environments/test/debugmask" \ -X GET \ -H "Authorization: Bearer $TOKEN"
Dove $TOKEN
è impostato sul tuo token di accesso OAuth 2.0, come descritto in
Ottenere un token di accesso OAuth 2.0. Per informazioni sulle opzioni curl
utilizzate in questo esempio, vedi
Con curl. Per una descrizione delle variabili di ambiente utilizzate,
consulta Impostare le variabili di ambiente per le richieste API Apigee.
Di seguito viene fornito un esempio della risposta:
{ "name": "organizations/myorg/environments/test/debugmask" "namespaces": { "myco": "http://example.com" }, "requestXPaths": [ "/myco:Greeting/myco:User" ], "responseXPaths": [ "/myco:Greeting/myco:User" ] }
Aggiornamento della configurazione della maschera in un ambiente mediante l'API
Per aggiornare la risorsa singleton di configurazione della maschera in un ambiente, invia una PATCH alla seguente risorsa:
/organizations/{org}/environments/{env}/debugmask
Facoltativamente, puoi passare i seguenti parametri di ricerca:
- Imposta il parametro di query
updateMask
per specificare una maschera di campo che includa un elenco separato da virgole di nomi completi dei campi presenti nella maschera di debug. Ad esempio:"requestJSONPaths"
- Imposta il parametro di query
replaceRepeatedFields
per specificare se sostituire i valori esistenti nella maschera di debug quando esegui un aggiornamento. Per impostazione predefinita, i valori vengono aggiunti (false
)
Ad esempio:
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" ] }'
Dove $TOKEN
è impostato sul tuo token di accesso OAuth 2.0, come descritto in
Ottenere un token di accesso OAuth 2.0. Per informazioni sulle opzioni curl
utilizzate in questo esempio, vedi
Con curl. Per una descrizione delle variabili di ambiente utilizzate,
consulta Impostare le variabili di ambiente per le richieste API Apigee.
Mascheramento del file XML con ambito dello spazio dei nomi
Se vuoi mascherare i dati XML che utilizzano spazi dei nomi XML, la configurazione della maschera
deve fare riferimento a questi spazi dei nomi con l'elemento namespaces
. Ciò avviene indipendentemente dal fatto che
Il payload XML utilizza uno spazio dei nomi predefinito o un prefisso dello spazio dei nomi.
Ad esempio, supponiamo di voler mascherare il nome del dipendente nel payload della richiesta. e il file XML non utilizza spazi dei nomi XML:
<employee>
<name>Shanmu Tharman</name>
<age>50</age>
</employee>
Pertanto, la configurazione della maschera di debug non richiede l'elemento namespaces
:
{ "requestXPaths": [ "/employee/name" ] }
Se il payload XML utilizza spazi dei nomi con prefissi:
<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 configurazione della maschera dovrebbe quindi contenere namespaces
. Puoi scegliere qualsiasi prefisso dello spazio dei nomi valido nella configurazione della maschera di debug.
il prefisso dello spazio dei nomi nella configurazione della maschera di debug può essere uguale al prefisso dello spazio dei nomi
usato nel file XML, ma non è obbligatorio.
{ "namespaces": { "cym": "http://cymbalgroup.com", "idns": "http://cymbalgroup.com/identity" }, "requestXPaths": [ "/cym:employee/idns:name" ] }
Se il payload XML utilizza uno spazio dei nomi senza prefisso, ovvero lo spazio dei nomi predefinito:
<employee xmlns="http://cymbalgroup.com" xmlns:id="http://cymbalgroup.com/identity">
<id:name>Shanmu Tharman</id:name>
<id:age>50</id:age>
</employee>
La configurazione della maschera di debug deve quindi definire un prefisso nel namespaces
corrispondente allo spazio dei nomi predefinito. Puoi utilizzare qualsiasi prefisso univoco.
{ "namespaces": { "p1": "http://cymbalgroup.com", "id": "http://cymbalgroup.com/identity" }, "requestXPaths": [ "/p1:employee/id:name" ] }
Altre note di configurazione
-
Con gli elementi di configurazione
*XPaths
e*JSONPaths
, puoi dati mascherati visualizzati inrequest
,response
ofault
messaggi. Tuttavia, le sessioni di debug potrebbero anche essere acquisiti l'intero contenuto del messaggio. Puoi inoltre vuoi configurarerequest.content
oresponse.content
nelvariables
per impedire la visualizzazione di dati sensibili. -
Se utilizzi le norme ServiceCallout per effettuare una richiesta, ma le informazioni nella richiesta e nella risposta per il callout non verrà mascherato utilizzando elementi di configurazione quali
requestXPaths
oresponseJSONPaths
. Se vuoi mascherare questi dati, devi specificare un il nome della variabile per i messaggi di richiesta e risposta nel criterio ServiceCallout specificare queste variabili nella sezionevariables
della maschera di debug. Ad esempio: se il criterio ServiceCallout utilizza:<ServiceCallout name='SC-1'> <Request variable='rbacRequest'> <Set> <Payload contentType='application/json'>{ ... }</Payload> ...
Poi devi includere
rbacRequest.content
nelvariables
per la configurazione della maschera di debug.{ ... "variables": [ "request.content", "response.content", "rbacRequest.content" ] }
Nascondere i dati sensibili
Oltre al mascheramento, puoi impedire la visualizzazione dei dati sensibili nello strumento Trace
e sessioni di debug scegliendo un nome che inizi con private.
per le variabili personalizzate.
Ad esempio, quando utilizzi Chiave il criterio relativo alle operazioni di mappa valori per recuperare un valore da una mappa chiave-valore. puoi scegliere il nome della variabile come segue per assicurarti che il valore non viene visualizzato nelle sessioni di Trace o di debug:
<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>
Le variabili senza il prefisso private.
vengono visualizzate in chiaro in Trace e
sessioni di debug anche se i dati provengono da un datastore criptato, ad esempio una coppia chiave-valore
mappa. Utilizza il mascheramento se vuoi mascherare questi valori.