Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di
Apigee Edge.
Affinché un cliente sia conforme al Payment Card Industry (PCI) su Apigee, esistono alcune azioni e processi di proprietà del cliente nell'ambito del "modello di responsabilità condivisa". I seguenti elementi devono essere esaminati dai clienti che intendono ottenere la conformità PCI. Questi elementi sono self-service in Apigee e devono essere gestiti affinché l'organizzazione del cliente soddisfi i requisiti PCI. Il concetto generale è "Google protegge la piattaforma, il cliente protegge i propri dati".
Mappatura dei requisiti PCI
La seguente tabella mette in relazione i requisiti PCI con la documentazione Apigee correlata. Per maggiori informazioni sui requisiti, consulta la guida di riferimento rapido PCI DSS v3.2.1.
| Requisito PCI | Sezione |
| Requisito 3: proteggere i dati memorizzati dei titolari delle carte | Mascheramento dei dati |
| Requisito 3: proteggere i dati memorizzati dei titolari delle carte | Archiviazione dei dati |
| Requisito 4: crittografa la trasmissione dei dati del titolare della carta su reti pubbliche aperte | Configurazione TLS |
| Requisito 4: crittografa la trasmissione dei dati del titolare della carta su reti pubbliche aperte | Crittografia dei dati |
| Requisito 7: limitare l'accesso ai dati dei titolari di carte in base alla necessità di conoscerli dell'attività | Utilizzo/Autorizzazioni |
| Requisito 8: assegna un ID univoco a ogni persona con accesso al computer | Requisiti di password complessi o SAML |
| Requisito 10: monitora e registra tutti gli accessi alle risorse di rete e ai dati dei titolari delle carte | Audit trail |
| Requisito 11: testare regolarmente i sistemi e i processi di sicurezza | Scansione degli endpoint |
Per ottenere una certificazione di conformità (AOC) agli standard di sicurezza dei dati PCI, visita Google Compliance Report Manager o contatta il team di vendita di Apigee.
Sessioni di debug
Debug Sessions è uno strumento di 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 applicata la mascheratura dei dati. La maschera 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 di Debug sono disponibili in Utilizzo di Debug.
Utilizzo/Autorizzazioni
L'accesso alla sessione di debug viene gestito tramite il sistema RBAC (controllo dell'accesso basato sui 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 Apigee. Le autorizzazioni per la sessione di debug consentono all'utente di avviare una sessione di debug e accedere all'output di una sessione di debug.
Poiché Debug Session ha accesso al payload delle chiamate API (formalmente chiamato "corpo del messaggio"), è importante considerare chi ha accesso all'esecuzione di una sessione di debug. Poiché la gestione degli utenti è una responsabilità del cliente, anche la concessione delle autorizzazioni per la sessione di debug è una responsabilità del cliente.
Mascheramento dei dati
Il mascheramento dei dati impedisce la visualizzazione di dati sensibili solo durante una sessione di debug, sia nello strumento di debug (interfaccia utente Apigee) sia nel backend tramite Debug (API Apigee). I dettagli su come configurare il mascheramento sono disponibili in Mascheramento e occultamento dei dati. Il mascheramento dei dati sensibili fa parte del requisito 3 di PCI: proteggere i dati memorizzati dei titolari di carte.
Il mascheramento dei dati NON impedisce la visualizzazione dei dati in posizioni come file di log, cache e analisi. In genere, i dati sensibili non devono essere scritti nella cache o in Analytics senza una solida giustificazione aziendale e una revisione da parte dei team legali e di sicurezza dei clienti.
Memorizzazione nella cache
La memorizzazione nella cache è disponibile per tutti i clienti. Per saperne di più, consulta la sezione Internals della cache.
Audit trail
I clienti hanno la possibilità di esaminare l'audit trail di tutte le attività amministrative eseguite all'interno dell'organizzazione del cliente, incluso l'utilizzo di Debug. Per istruzioni dettagliate, vedi Registrazione dei log di controllo e Utilizzo di Debug. Requisito PCI 10: monitora e registra tutti gli accessi alle risorse di rete e ai dati dei titolari di carte).
Requisiti di password complessi o SAML
Per i clienti PCI, le password utente sono configurate in modo da soddisfare la maggior parte dei requisiti previsti dal PCI DSS. Cloud Identity offre anche l'autenticazione a più fattori (requisito 8 di PCI: assegna un ID univoco a ogni persona con accesso al computer). SAML, come descritto in Panoramica di SAML, può essere utilizzato come alternativa per i controlli di autenticazione.
Nota:ai clienti con requisiti di password specifici è consigliabile utilizzare SAML per soddisfare i propri requisiti individuali.
Sicurezza degli endpoint
Scansione degli endpoint
La scansione e il test degli host sono necessari per la conformità PCI (Requisito 11: esegui regolarmente test di sistemi e 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 dei clienti devono coprire i servizi proxy API effettivi 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, come l'UI del portale di gestione, non è approvato per i singoli clienti (un report di terze parti che copre il test dei servizi condivisi è disponibile per i clienti in base a un accordo 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 la UI di gestione condivisa. È gradita una notifica anticipata ad Apigee in modo da poter essere a conoscenza del traffico di test.
I clienti che testano i propri endpoint devono verificare la presenza di problemi specifici dell'API, di problemi relativi ai servizi Apigee e controllare anche TLS e altri elementi configurabili. Eventuali elementi trovati correlati ai servizi Apigee devono essere comunicati ad Apigee tramite una richiesta di assistenza.
La maggior parte degli elementi correlati all'endpoint sono elementi self-service per i clienti e possono essere corretti consultando la documentazione di Apigee. Se ci sono elementi per i quali non è chiaro come risolverli, apri una richiesta di assistenza.
Configurazione TLS
In base agli standard PCI, SSL e TLS precedenti devono essere migrati a versioni sicure. I clienti sono responsabili della definizione e della configurazione dei propri endpoint TLS per i proxy API. Questa è una funzionalità self-service di Apigee. I requisiti dei clienti in merito a crittografia, protocollo e selezione degli algoritmi variano notevolmente e sono specifici per i singoli casi d'uso. Poiché Apigee non conosce i dettagli della progettazione delle API e dei payload di dati di ogni cliente, i clienti hanno la responsabilità di determinare la crittografia appropriata 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, esistono servizi disponibili per l'archiviazione dei dati in Apigee. I clienti possono scegliere di utilizzare la cache, le mappe chiave-valore o Analytics per l'archiviazione dei dati. Analytics non è autorizzato alla memorizzazione dei dati dei titolari di carte (CHD) in base all'audit PCI di Apigee. In base al requisito 3 del PCI (Proteggere i dati memorizzati dei titolari di carte), i dati PCI devono essere archiviati solo in posizioni conformi al PCI. L'utilizzo di questi servizi è disponibile per i clienti per l'archiviazione di dati non PCI o altri dati senza restrizioni, in base ai requisiti legali e di sicurezza del cliente. Questi servizi sono elementi self-service per i clienti, pertanto è responsabilità del cliente configurarli in modo che non acquisiscano o memorizzino dati della carta. Per evitare l'utilizzo accidentale o dannoso dei servizi di archiviazione dei dati in Apigee in modo non conforme, è consigliabile che gli amministratori clienti esaminino la configurazione, le norme e le implementazioni .
Crittografia dei dati
Gli strumenti di crittografia dei dati non vengono offerti ai clienti per l'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 (crittografare la trasmissione dei dati dei titolari di carte su reti pubbliche aperte) consiglia di crittografare 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. Alcune norme 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 Apigee per la modifica. Tuttavia, altre norme, norme e bundle creati dai clienti funzioneranno anche se il payload di 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 Data Capture per memorizzare i dati del titolare della carta.
Esposizione di informazioni tramite stringhe di query nell'URL
Apigee consiglia progettazioni API che evitano dati sensibili (inclusi, a titolo esemplificativo, i dati del titolare della carta) tramite stringhe di query negli URL.