Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
Affinché un cliente sia conforme al settore delle carte di pagamento (PCI) su Apigee, il cliente deve eseguire alcune azioni e procedure nell'ambito del "modello di responsabilità condivisa". Gli elementi seguenti devono essere esaminati dai clienti che vogliono essere conformi allo standard PCI. Questi elementi sono self-service all'interno di Apigee e devono essere risolti affinché l'organizzazione del cliente (organizzazione) 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 maggiori informazioni sui requisiti, consulta la guida di riferimento rapida PCI DSS v3.2.1.
| Requisito PCI | Sezione |
| Requisito 3: proteggere i dati memorizzati dei titolari di carta | Mascheramento dei dati |
| Requisito 3: proteggere i dati memorizzati dei titolari di carta | Archiviazione dei dati |
| Requisito 4: criptare la trasmissione dei dati dei titolari di carte su reti pubbliche aperte | Configurazione TLS |
| Requisito 4: criptare la trasmissione dei dati dei titolari di carte su reti pubbliche aperte | Crittografia dei dati |
| Requisito 7: limitare l'accesso ai dati del titolare della carta in base alle esigenze aziendali | Utilizzo/Autorizzazioni |
| Requisito 8: assegna un ID univoco a ogni persona che ha accesso a un computer | Requisiti per password complessi o SAML |
| Requisito 10: tracciare e monitorare tutti gli accessi alle risorse di rete e ai dati del titolare della carta | Audit trail |
| Requisito 11: testare regolarmente i sistemi e i processi di sicurezza | Scansione degli endpoint |
Per ottenere un'attestazione di conformità (AOC) dello standard PCI Data Security Standard, visita il gestore dei report di conformità di Google o contatta il team di vendita di Apigee.
Sessioni di debug
Debug Sessions è 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 in modo forzato il mascheramento dei dati. Il mascheramento dei dati può bloccare 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 nella pagina Utilizzo di debug.
Utilizzo/Autorizzazioni
L'accesso alla sessione di debug è gestito tramite il sistema RBAC (Role-Based Access Control) di Cloud IAM (Identity Access Management). Istruzioni dettagliate sull'utilizzo del sistema RBAC per concedere e revocare privilegi per le sessioni di debug sono disponibili nei ruoli Apigee e nella Gestione degli utenti nell'interfaccia utente di Apigee. Le autorizzazioni della sessione di debug consentono all'utente di avviare una sessione di debug e di accedere all'output da una sessione di debug.
Poiché la sessione di debug ha accesso al payload delle chiamate API (precedentemente chiamato "Corpo del messaggio"), è importante considerare chi ha accesso per eseguire una sessione di debug. Poiché la gestione utenti è una responsabilità del cliente, anche la concessione delle autorizzazioni per le sessioni di debug è responsabilità del cliente.
Mascheramento dei dati
Il mascheramento dei dati impedisce la visualizzazione dei dati sensibili solo durante una sessione di debug, sia nello strumento di debug (UI Apigee) sia nel backend tramite il debug (API Apigee). I dettagli su come configurare il mascheramento sono disponibili nella sezione Mascheramento e occultamento dei dati. Il mascheramento dei dati sensibili fa parte del Requisito PCI 3 - Proteggere i dati dei titolari di carte memorizzati.
Il mascheramento dei dati NON ne impedisce la visualizzazione in posizioni quali i file di log, la cache e l'analisi. In genere, i dati sensibili non devono essere scritti nella cache o sull'analisi senza una solida giustificazione aziendale ed essere esaminati dal team legale e di sicurezza del cliente.
Memorizzazione nella cache
La memorizzazione nella cache è disponibile per tutti i clienti. Per ulteriori informazioni, consulta Dati interni della cache.
Audit trail
I clienti hanno la possibilità di esaminare l'audit trail di tutte le attività amministrative eseguite all'interno della loro organizzazione, incluso l'utilizzo di Debug. Per istruzioni dettagliate, consulta Audit logging e Utilizzo del debug. Requisito PCI 10: monitorare e monitorare tutti gli accessi alle risorse di rete e ai dati dei titolari della carta).
Requisiti per password complesse o SAML
Per i clienti PCI, le password utente sono configurate in modo da soddisfare la maggior parte dei requisiti previsti dallo standard PCI DSS. Cloud Identity offre inoltre l'autenticazione a più fattori (Requisito PCI 8: assegna un ID univoco a ogni persona che ha accesso al computer). SAML, come descritto in Panoramica di SAML, può essere utilizzato come alternativa per i controlli di autenticazione.
Nota: consigliamo ai clienti con requisiti specifici di password di utilizzare SAML per soddisfare i loro requisiti individuali.
Sicurezza degli endpoint
Analisi degli endpoint
L'analisi e il test degli host sono necessari per la conformità PCI (Requisito 11: testare regolarmente i sistemi e i processi di sicurezza). Per Apigee, i clienti sono responsabili della scansione e del test dei loro endpoint API (a volte chiamati "componenti di runtime") in Apigee. I test dei clienti devono riguardare gli effettivi servizi proxy API ospitati su Apigee, dove il traffico API viene inviato ad Apigee prima di essere elaborato e poi consegnato al data center del cliente. Il test delle risorse condivise, ad esempio l'interfaccia utente del portale di gestione, non è approvato per i singoli clienti (un report di terze parti relativo ai test dei servizi condivisi è disponibile per i clienti ai sensi di un accordo di non divulgazione e su richiesta).
I clienti dovrebbero testare i propri endpoint API e sono incoraggiati a farlo. Il tuo contratto con Apigee non vieta i test degli endpoint API, ma non ti consentiamo di testare l'UI di gestione condivisa. Consigliamo di informare in anticipo Apigee in modo da poter essere a conoscenza del traffico di test.
I clienti che testano i loro endpoint devono cercare eventuali problemi specifici delle API e dei servizi Apigee, nonché controllare il protocollo TLS e altri elementi configurabili. Qualsiasi elemento trovato relativo ai servizi Apigee deve essere comunicato ad Apigee tramite una richiesta di assistenza.
La maggior parte degli elementi relativi all'endpoint sono elementi self-service del cliente e può essere corretta esaminando la documentazione di Apigeee. In caso di dubbi sul problema, apri una richiesta di assistenza.
Configurazione TLS
In base agli standard PCI, è necessario eseguire la migrazione di SSL e TLS anticipato a versioni protette. È responsabilità dei clienti definire e configurare i propri endpoint TLS per i proxy API. Questa è una funzionalità self-service di Apigee. I requisiti dei clienti in merito alla selezione di crittografia, protocollo e algoritmi sono ampiamente variabili e specifici per i singoli casi d'uso. Poiché Apigee non conosce i dettagli del design delle API e dei payload dei dati di ogni cliente, questi hanno la responsabilità di determinare la crittografia adeguata per i dati in transito. Istruzioni dettagliate sulla configurazione TLS sono disponibili in TLS/SSL.
Archiviazione dei dati
L'archiviazione dei dati in Apigee non è necessaria per il corretto funzionamento di Apigee. Tuttavia, sono disponibili servizi per l'archiviazione dei dati in Apigee. I clienti possono scegliere di utilizzare la cache, le mappe chiave-valore o le analisi per l'archiviazione dei dati. Analytics non è autorizzato ad archiviare i dati dei titolari di carte (CHD) in base al controllo PCI di Apigee. In base al Requisito PCI 3 (Proteggere i dati dei titolari delle carte memorizzati), questi dati devono essere archiviati solo in posizioni conformi allo standard PCI. Questi servizi possono essere utilizzati dai clienti per l'archiviazione di dati non PCI o altri dati senza limitazioni, in conformità ai requisiti legali e di sicurezza del cliente. Questi servizi sono articoli self-service del cliente, pertanto è responsabilità del cliente configurarli in modo da non acquisire o archiviare il CHD. Consigliamo di rivedere configurazione, criteri e deployment da parte degli amministratori dei clienti per evitare l'uso accidentale o dannoso dei servizi di archiviazione 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. Requisito PCI 4: (crittografare la trasmissione dei dati dei titolari di carte su reti aperte e pubbliche) consiglia di criptare i dati dei titolari su reti aperte e pubbliche. I dati criptati nel payload (o nel corpo del messaggio) non impediscono il funzionamento di Apigee. Alcuni criteri di Apigee potrebbero non essere in grado di interagire con i dati se il cliente li riceve criptati. Ad esempio, una trasformazione non è possibile se i dati stessi non sono disponibili per la modifica in Apigee. Tuttavia, altri criteri e pacchetti creati dal cliente funzioneranno anche se il payload dei dati è criptato.
Acquisizione dei dati
I clienti possono utilizzare il criterio di acquisizione dei dati per inviare attributi personalizzati alla piattaforma di analisi Apigee. Apigee consiglia di non utilizzare Data Capture per archiviare le informazioni del titolare della carta.
Esposizione delle informazioni tramite stringhe di query nell'URL
Apigee consiglia progettazioni di API che evitano dati sensibili (inclusi, a titolo esemplificativo, le informazioni del titolare della carta) tramite stringhe di query negli URL.