Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Affinché un cliente sia conforme allo standard PCI su Apigee Edge Public Cloud, 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 hanno acquistato il pacchetto di conformità PCI e sono tenuti a rispettare i requisiti PCI. Questi elementi sono self-service all'interno di Edge e devono essere gestiti affinché l'organizzazione del cliente sia conforme a PCI. Il concetto generale è "Google protegge la piattaforma, il cliente protegge i propri dati".
Matrice delle responsabilità del cliente
I clienti devono fare riferimento alla Google Cloud Plaform: PCI DSS v4.0.1 Shared Responsibility Matrix e condividerla con il proprio Qualified Security Assessor PCI durante l'esecuzione del proprio audit PCI.
Mappatura dei requisiti PCI
| Requisito PCI | Sezione |
|---|---|
| Requisito 7: Limita l'accesso ai componenti di sistema e ai dati dei titolari delle carte in base alle necessità aziendali di sapere | |
| Requisito 3: proteggere i dati dell'account memorizzati | |
| Requisito 10: registra e monitora tutti gli accessi ai componenti del sistema e ai dati dei titolari delle carte | |
| Requisito 8: identifica gli utenti e autentica l'accesso ai componenti del sistema | |
| Requisito 11: verifica regolarmente la sicurezza di sistemi e reti | |
| Requisito 4: Proteggi i dati del titolare della carta con una crittografia efficace durante la trasmissione su reti pubbliche aperte | |
| Requisito 3: proteggere i dati dell'account memorizzati | |
| Requisito 4: Proteggi i dati del titolare della carta con una crittografia efficace durante la trasmissione su reti pubbliche aperte |
Per ottenere un'attestazione di conformità (AOC) allo standard PCI Data Security, apri un ticket con l'assistenza Apigee o contatta il team di vendita Apigee.
Traccia / Debug
Trace/Debug è 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 Apigee processore di messaggi. Trace e Debug sono due nomi dello stesso servizio, ma a cui si accede tramite meccanismi diversi. Trace è il nome di questo servizio all'interno della UI Edge. Debug è il nome dello stesso servizio quando viene utilizzato tramite chiamate API. L'utilizzo del termine Trace in questo documento è valido sia per Trace che per Debug.
Durante una sessione di Trace, viene applicata la "Mascheratura dei dati". Questo strumento può bloccare la visualizzazione dei dati durante una traccia. Consulta la sezione Mascheramento dei dati di seguito.
Le mappe chiave-valore (KVM) criptate possono essere utilizzate per i clienti PCI. Se è in uso una KVM criptata, Trace può comunque essere utilizzato, ma alcune variabili non saranno visibili nella schermata di visualizzazione di Trace. È possibile eseguire passaggi aggiuntivi per visualizzare queste variabili anche durante una traccia.
Istruzioni dettagliate sull'utilizzo di Trace sono disponibili in Utilizzo dello strumento Trace.
I dettagli sulle KVM, incluse quelle criptate, sono disponibili in Utilizzare le mappe chiave-valore.
Utilizzo/Autorizzazioni
L'accesso a Trace è gestito tramite il sistema RBAC (controllo degli accessi basato su ruoli) per gli account utente all'interno di Edge. Istruzioni dettagliate sull'utilizzo del sistema RBAC per concedere e revocare i privilegi di Trace sono disponibili in Assegnazione dei ruoli e Creazione di ruoli personalizzati nell'interfaccia utente. Le autorizzazioni di tracciamento consentono all'utente di avviare una traccia, interromperla e accedere all'output di una sessione di tracciamento.
Poiché Trace ha accesso al payload delle chiamate API (formalmente chiamato "corpo del messaggio"), è importante considerare chi ha accesso per eseguire una traccia. Poiché la gestione degli utenti è responsabilità del cliente, anche la concessione delle autorizzazioni di tracciamento è responsabilità del cliente. Apigee, in qualità di proprietario della piattaforma, ha la possibilità di aggiungere un utente a un'organizzazione cliente e di assegnare i privilegi. Questa funzionalità viene utilizzata solo su richiesta del cliente per l'assistenza in una situazione in cui sembra che il servizio clienti non funzioni e si ritiene che la revisione di una sessione di Trace fornisca le informazioni migliori sulla causa principale.
Mascheramento dei dati
Il mascheramento dei dati impedisce la visualizzazione di dati sensibili solo durante una sessione di Trace/Debug, sia in Trace (UI Edge) sia nel backend tramite Debug (API Edge). 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 nei file di log, nella cache, in Analytics, ecc. Per assistenza con il mascheramento dei dati nei log, valuta la possibilità di aggiungere un pattern regex al file logback.xml. 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.
Cache L1 e L2
La memorizzazione nella cache è disponibile per i clienti PCI solo per l'utilizzo con dati non regolamentati. La cache non deve essere utilizzata per i dati dei titolari di carte PCI (CHD); non è approvata dall'audit di conformità PCI di Apigee come posizione di archiviazione per i dati CHD. In base alle indicazioni PCI (Requirement 3: Protect stored cardholder data) , i dati PCI devono essere archiviati solo in una posizione conforme a PCI. L'utilizzo della cache L1 utilizzerà automaticamente anche la cache L2. La cache L1 è "solo memoria", mentre la cache L2 scrive i dati sul disco per la sincronizzazione tra più cache L1. La cache L2 mantiene sincronizzati più Message Processor all'interno di una regione e a livello globale. Al momento non è possibile attivare la cache L1 senza una cache L2. La cache L2 scrive i dati sul disco in modo che possano essere sincronizzati con altri processori di messaggi per l'organizzazione del cliente. Poiché la cache L2 scrive i dati sul disco, l'utilizzo della cache per i dati CHD o altri dati con limitazioni non è supportato.
L'utilizzo della cache da parte dei clienti è consentito per i dati non CHD e altri dati senza limitazioni. Per impostazione predefinita, non disattiviamo la cache per i clienti PCI, perché alcuni clienti eseguono chiamate API correlate e non correlate a PCI tramite una singola organizzazione. Poiché la funzionalità è ancora abilitata per i clienti PCI, è responsabilità del cliente utilizzare il servizio in modo appropriato e formare i propri utenti a non utilizzare la cache quando è probabile che i dati PCI siano nella chiamata API. L'audit di conformità PCI di Apigee non supporta i dati della carta memorizzati nella cache.
Istruzioni dettagliate sull'utilizzo della cache sono disponibili in Aggiunta di memorizzazione nella cache e persistenza.
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 Trace. Istruzioni dettagliate sono disponibili qui e in Utilizzo dello strumento Traccia. (PCI Requirement 10: Track and monitor all access to network resources and cardholder data)
Requisiti di password complessi o SAML
I clienti con requisiti di password specifici devono utilizzare SAML per soddisfare i propri requisiti individuali. Consulta Attivazione dell'autenticazione SAML per Edge. Edge offre anche l'autenticazione a più fattori (requisito 8 di PCI: assegna un ID univoco a ogni persona con accesso al computer). Consulta Attivare l'autenticazione a due fattori per il tuo account Apigee.
Sicurezza degli endpoint
Scansione degli endpoint
L'analisi e il test degli host sono necessari per la conformità PCI (Requirement 11: Regularly test security systems and processes). Per Edge Cloud, i clienti sono responsabili della scansione e del test dei propri endpoint API (a volte chiamati "componenti di runtime") in Edge. I test dei clienti devono coprire i servizi proxy API effettivi ospitati su Edge, dove il traffico API viene inviato a Edge 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. Tuttavia, se sono necessari ulteriori chiarimenti, apri una richiesta di assistenza facendo riferimento ai test pianificati. È gradita la 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 risolti consultando la documentazione di Edge. 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 in Edge. I requisiti dei clienti relativi a crittografia, protocollo e selezione dell'algoritmo 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 all'indirizzo TLS/SSL.
Archiviazione dei dati
L'archiviazione dei dati all'interno di Edge non è necessaria per il corretto funzionamento di Edge. Tuttavia, esistono servizi disponibili per l'archiviazione dei dati in Edge. I clienti possono scegliere di utilizzare la cache, le mappe chiave-valore o l'analisi per l'archiviazione dei dati. Nessuno di questi servizi è autorizzato all'archiviazione di dati della carta per il controllo PCI di Apigee. Ai sensi del requisito 3 di PCI (Proteggere i dati archiviati dei titolari di carte), 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 altri dati senza restrizioni soggetti 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 i dati della carta. Per evitare un utilizzo accidentale o dannoso dei servizi di archiviazione dati in Edge 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 in Edge. Tuttavia, i clienti sono liberi di crittografare i propri dati PCI prima di inviarli a Edge. PCI Requisito 4: (Crittografa 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 Edge. Alcune norme di Edge 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 Edge. Tuttavia, altre norme e pacchetti e norme creati dai clienti funzioneranno anche se il payload di dati è criptato.