Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
Affinché un cliente sia conforme allo standard PCI (Payment Card Industry) su Apigee, esistono alcune azioni e procedure di proprietà del cliente nell'ambito del "modello di responsabilità condivisa". I seguenti elementi devono essere esaminati dai clienti che vogliono essere conformi a PCI. Questi elementi sono self-service in Apigee e devono essere risolti affinché l'organizzazione (org) del cliente soddisfi i requisiti PCI. Il concetto generale è "Google protegge la piattaforma, il cliente protegge i propri dati".
Mappatura dei requisiti PCI
La tabella seguente mappa i requisiti PCI alla documentazione di Apigee correlata. Per ulteriori informazioni sui requisiti, consulta la Guida di riferimento rapido PCI DSS v3.2.1.
| Requisito PCI | Sezione |
| Requisito 3: proteggere i dati del titolare della carta archiviati | Masking dei dati |
| Requisito 3: proteggere i dati del titolare della carta archiviati | Archiviazione dei dati |
| Requisito 4: cripta la trasmissione dei dati del titolare della carta su reti pubbliche aperte | Configurazione TLS |
| Requisito 4: cripta la trasmissione dei dati del titolare della carta su reti pubbliche aperte | Crittografia dei dati |
| Requisito 7: limitare l'accesso ai dati del titolare della carta in base alle necessità dell'attività | Utilizzo/autorizzazioni |
| Requisito 8: assegna un ID univoco a ogni persona con accesso al computer | Requisiti complessi per le password o SAML |
| Requisito 10: monitorare e controllare tutto l'accesso alle risorse di rete e ai dati dei titolari della carta | Audit trail |
| Requisito 11: testare regolarmente i sistemi e le procedure di sicurezza | Scansione degli endpoint |
Per ottenere una certificazione di conformità (AOC) allo standard PCI Data Security Standard, visita Google Compliance Report Manager o contatta il team di vendita di Apigee.
Sessioni di debug
Le sessioni di debug sono uno strumento per la risoluzione dei problemi che consente all'utente di visualizzare lo stato e i contenuti di una chiamata API durante l'elaborazione tramite la piattaforma Apigee.
Durante una sessione di debug, viene applicato il mascheramento dei dati. La mascheratura dei dati può impedire la visualizzazione dei dati durante una sessione di debug. Consulta la sezione Mascheramento dei dati di seguito.
Istruzioni dettagliate sull'utilizzo del debug sono disponibili in Utilizzare il debug.
Utilizzo/autorizzazioni
L'accesso alla sessione di debug viene gestito tramite il sistema RBAC (Controllo dell'accesso basato su ruoli) di Cloud IAM (Identity Access Management). Istruzioni dettagliate sull'utilizzo del sistema RBAC per concedere e revocare i privilegi di sessione di debug sono disponibili in Ruoli Apigee e Gestire gli utenti nell'interfaccia utente di Apigee. Le autorizzazioni per le sessioni di debug consentono all'utente di avviare una sessione di debug e di accedere all'output di una sessione di debug.
Poiché la sessione di debug ha accesso al payload delle chiamate API (ufficialmente chiamato "corpo del messaggio"), è importante considerare chi ha accesso per eseguire una sessione di debug. Poiché la gestione degli utenti è responsabilità del cliente, anche la concessione delle autorizzazioni per le sessioni di debug è responsabilità del cliente.
Mascheramento dei dati
La mascheratura dei dati impedisce la visualizzazione di dati sensibili solo durante una sessione di debug, sia nello strumento di debug (interfaccia utente di Apigee) sia nel backend tramite il debug (API Apigee). Per informazioni dettagliate su come configurare il mascheramento, consulta Mascheramento e occultamento dei dati. Il mascheramento dei dati sensibili fa parte del Requisito PCI 3: Proteggi i dati dei titolari di carte archiviati.
Il mascheramento dei dati NON impedisce che i dati siano visibili in luoghi come i file di log, la cache e gli analytics. In genere, i dati sensibili non devono essere scritti nella cache o in Analytics senza una giustificazione aziendale valida e la revisione da parte dei team legali e di sicurezza dei clienti.
Memorizzazione nella cache
La memorizzazione nella cache è disponibile per tutti i clienti. Per ulteriori informazioni, consulta Cache internals.
Audit trail
I clienti hanno la possibilità di esaminare la cronologia delle attività amministrative eseguite all'interno della loro organizzazione, incluso l'utilizzo del debug. Per istruzioni dettagliate, consulta Log di controllo e Utilizzare il debug. Requisito PCI 10: monitora e tieni traccia di tutto l'accesso alle risorse di rete e ai dati dei titolari di carte.
Requisiti complessi per le password o SAML
Per i clienti PCI, le password utente sono configurate per soddisfare la maggior parte dei requisiti previsti dal PCI DSS. Cloud Identity offre anche l'autenticazione a più fattori (Requisito 8 del PCI: assegna un ID univoco a ogni persona con accesso al computer). SAML, come descritto nella Panoramica di SAML, può essere utilizzato come alternativa ai controlli di autenticazione.
Nota:ai clienti con requisiti specifici per le password è consigliato di utilizzare SAML per soddisfare le loro esigenze individuali.
Sicurezza degli endpoint
Scansione degli endpoint
La scansione e il test degli host sono obbligatori per la conformità PCI (Requisito 11: testare regolarmente i sistemi e le procedure di sicurezza). Per Apigee, i clienti sono responsabili della scansione e del test dei propri endpoint API (a volte chiamati "componenti di runtime") in Apigee. I test del cliente devono coprire i servizi proxy API effettivi ospitati su Apigee, dove il traffico API viene inviato ad Apigee prima di essere elaborato e poi inviato al data center del cliente. I test delle risorse condivise, come l'interfaccia utente del portale di gestione, non sono approvati per i singoli clienti (un report di terze parti che copre i test dei servizi condivisi è disponibile per i clienti ai sensi di un contratto di non divulgazione e su richiesta).
I clienti devono testare i propri endpoint API e sono incoraggiati a farlo. Il tuo contratto con Apigee non vieta il test degli endpoint API, ma non ti consente di testare l'interfaccia utente di gestione condivisa. Ti invitiamo a inviare una notifica ad Apigee in anticipo per consentirci di essere a conoscenza del traffico di test.
I clienti che testano i propri endpoint devono cercare eventuali problemi specifici dell'API, eventuali problemi relativi ai servizi Apigee e anche controllare TLS e altri elementi configurabili. Eventuali elementi correlati ai servizi Apigee devono essere comunicati ad Apigee tramite una richiesta di assistenza.
La maggior parte degli elementi relativi all'endpoint sono elementi self-service per i clienti e possono essere corretti esaminando la documentazione di Apigeee. Se non sai come risolvere i problemi relativi a determinati elementi, apri una richiesta di assistenza.
Configurazione TLS
In base agli standard PCI, è necessario eseguire la migrazione da SSL e TLS precedenti alle versioni protette. I clienti sono responsabili della definizione e della configurazione dei propri endpoint TLS per i proxy API. Si tratta di una funzionalità self-service in Apigee. I requisiti dei clienti relativi alla crittografia, al protocollo e alle scelte di algoritmi sono molto variabili e specifici per i singoli casi d'uso. Poiché Apigee non conosce i dettagli del design dell'API e dei payload di dati di ogni cliente, è responsabilità del cliente determinare la crittografia appropriata per i dati in transito. Istruzioni dettagliate sulla configurazione di TLS sono disponibili in TLS/SSL.
Archiviazione dei dati
L'archiviazione dei dati all'interno di Apigee non è necessaria per il corretto funzionamento di Apigee. Tuttavia, in Apigee sono disponibili servizi per l'archiviazione dei dati. I clienti possono scegliere di utilizzare cache, mappe chiave-valore o analisi per l'archiviazione dei dati. Analytics non è autorizzato allo stoccaggio dei dati dei titolari di carte (CHD) per l'audit PCI di Apigee. Ai sensi del Requisito 3 del PCI (Protezione dei dati dei titolari di carte archiviati), i dati PCI devono essere archiviati solo in posizioni conformi a PCI. L'utilizzo di questi servizi è disponibile per i clienti per l'archiviazione di dati non PCI o di altri dati non soggetti a limitazioni, in base ai requisiti di sicurezza e legali del cliente. Poiché si tratta di elementi self-service per i clienti, è responsabilità del cliente configurarli in modo da non acquisire o archiviare CHD. Si consiglia di effettuare revisioni di configurazione, criteri e implementazioni da parte degli amministratori dei clienti per evitare l'uso accidentale o dannoso dei servizi di archiviazione dei dati in Apigee in modo non conforme .
Crittografia dei dati
Gli strumenti di crittografia dei dati non vengono offerti ai clienti per il loro utilizzo all'interno di Apigee. Tuttavia, i clienti sono liberi di criptare i propri dati PCI prima di inviarli ad Apigee. Il Requisito 4 del PCI (Crittografia della trasmissione dei dati dei titolari di carte su reti pubbliche aperte) consiglia di criptare i dati dei titolari di carte su reti pubbliche aperte. I dati criptati nel payload (o nel corpo del messaggio) non impediscono il funzionamento di Apigee. Alcuni criteri Apigee potrebbero non essere in grado di interagire con i dati se vengono ricevuti criptati dal cliente. Ad esempio, una trasformazione non è possibile se i dati stessi non sono disponibili per la modifica da parte di Apigee. Tuttavia, altri criteri e bundle creati dal cliente funzioneranno anche se il payload dei dati è criptato.
Acquisizione dati
I clienti possono utilizzare le norme di acquisizione dei dati per inviare attributi personalizzati alla piattaforma di analisi Apigee. Apigee consiglia di non utilizzare la funzionalità di acquisizione dei dati per memorizzare le informazioni del titolare della carta.
Esposizione delle informazioni tramite stringhe di query nell'URL
Apigee consiglia di progettare API che evitino i dati sensibili (inclusi, a titolo esemplificativo, i dati del titolare della carta) tramite stringhe di query negli URL.