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 all'interno di 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 mappa i requisiti PCI alla documentazione Apigee correlata. Per ulteriori informazioni sui requisiti, consulta la guida di riferimento rapido PCI DSS v4.0.1.
| Requisito PCI | Sezione |
| Requisito 3: proteggere i dati dell'account memorizzati | Mascheramento dei dati |
| Requisito 3: proteggere i dati dell'account memorizzati | Archiviazione dei dati |
| Requisito 4: proteggere i dati del titolare della carta con una crittografia efficace durante la trasmissione su reti pubbliche aperte | Configurazione TLS |
| Requisito 4: proteggere i dati del titolare della carta con una crittografia efficace durante la trasmissione su reti pubbliche aperte | Crittografia dei dati |
| Requisito 7: limita l'accesso ai componenti di sistema e ai dati dei titolari delle carte in base alla necessità di conoscerli | Utilizzo/Autorizzazioni |
| Requisito 8: identifica gli utenti e autentica l'accesso ai componenti del sistema | Requisiti di password complessi o SAML |
| Requisito 10: registra e monitora tutti gli accessi ai componenti di sistema e ai dati dei titolari delle carte | Audit trail |
| Requisito 11: verifica regolarmente la sicurezza di sistemi e reti | 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é la sessione di debug 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 dell'account archiviati.
Il mascheramento dei dati NON impedisce la visualizzazione dei dati in posizioni come i file di log, la cache e Analytics. 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 Elementi interni 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 Logging di controllo e Utilizzo di Debug. (Requisito PCI 10: registra e monitora tutti gli accessi ai componenti del sistema 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: identifica gli utenti e autentica l'accesso ai componenti di sistema). 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 sicurezza di sistemi e reti). 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 ed è consigliabile che lo facciano. Il tuo contratto con Apigee non vieta il test degli endpoint API, ma non ti consente di testare l'UI di gestione condivisa. È gradita una notifica ad Apigee in anticipo 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 sono molto variabili e 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 all'indirizzo 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 PCI 3 (Proteggere i dati dell'account archiviati), i dati PCI devono essere archiviati solo in posizioni conformi agli standard 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, quindi è responsabilità del cliente configurarli in modo che non acquisiscano o memorizzino dati CHD. 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 policy 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 (proteggere i dati del titolare della carta con una crittografia efficace durante la trasmissione su reti aperte e pubbliche) consiglia di criptare i dati del titolare della carta su reti aperte e pubbliche. 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 evitino dati sensibili (inclusi, a titolo esemplificativo, i dati del titolare della carta) tramite stringhe di query negli URL.