Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
Affinché un cliente sia conforme allo standard PCI su Apigee Edge Public Cloud, esistono alcune azioni e processi di proprietà del cliente in base al "modello di responsabilità condivisa". Gli elementi seguenti devono essere esaminati dai clienti che hanno acquistato il pacchetto di conformità PCI e devono essere conformi allo standard PCI. Questi elementi sono self-service all'interno di Edge e devono essere risolti affinché l'organizzazione del cliente (organizzazione) sia conforme allo standard PCI. Il concetto generale è "Google protegge la piattaforma, il cliente protegge i suoi dati".
Matrice delle responsabilità del cliente
I clienti devono fare riferimento alla matrice di responsabilità PCI-DSS 3.2.1 di Google Apigee e condividerla con il proprio Assessor della sicurezza PCI qualificato quando eseguono i propri controlli PCI.
Mappatura dei requisiti PCI
| Requisito PCI | Sezione |
|---|---|
| Requisito 7: limitare l'accesso ai dati dei titolari di carte in base alle esigenze aziendali | |
| Requisito 3: proteggere i dati del titolare della carta memorizzati | |
| Requisito 10: monitorare e monitorare tutti gli accessi alle risorse di rete e ai dati del titolare della carta | |
| Requisito 8: assegna un ID univoco a ogni persona che ha accesso al computer | |
| Requisito 11: testare regolarmente i sistemi e i processi di sicurezza | |
| Requisito 4: criptare la trasmissione dei dati dei titolari di carte su reti aperte e pubbliche | |
| Requisito 3: proteggere i dati del titolare della carta memorizzati | |
| Requisito 4: criptare la trasmissione dei dati dei titolari di carte su reti aperte e pubbliche |
Per ottenere un'attestazione di conformità (AOC) PCI Data Security Standard, apri un ticket con l'assistenza Apigee o contatta il team di vendita Apigee.
Traccia / Debug
Trace/Debug è uno strumento per la risoluzione dei problemi che consente all'utente di visualizzare lo stato e i contenuti di una chiamata API mentre viene elaborata tramite il processore di messaggi Apigee. Trace e Debug sono due nomi per lo stesso servizio ma a cui si accede tramite meccanismi diversi. Trace è il nome di questo servizio all'interno dell'interfaccia utente Edge. "Debug" è il nome dello stesso servizio utilizzato tramite le chiamate API. L'uso del termine Trace in questo documento è valido sia per Trace che per Debug.
Durante una sessione di traccia, 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.
Per i clienti PCI è possibile utilizzare le mappe chiave-valore crittografate (KVM). Se è in uso un KVM criptato, è possibile che venga comunque usata Trace, ma alcune variabili non saranno visibili nella schermata di visualizzazione Trace. Durante una traccia, è possibile intraprendere ulteriori passaggi per visualizzare queste variabili.
Istruzioni dettagliate sull'uso di Trace sono disponibili nella pagina relativa all'utilizzo dello strumento Trace.
I dettagli sui KVM, inclusi quelli criptati, sono disponibili nella pagina Utilizzo delle mappe chiave-valore.
Utilizzo/Autorizzazioni
L'accesso a Trace è gestito tramite il sistema RBAC (Role-Based Access Control) per gli account utente all'interno di Edge. Istruzioni dettagliate sull'utilizzo del sistema RBAC per concedere e revocare privilegi di Trace sono disponibili in Assegnare ruoli e Creare ruoli personalizzati nella UI. Le autorizzazioni di Trace consentono all'utente di avviare una traccia, interromperne una e accedere all'output da una sessione di Trace.
Poiché Trace ha accesso al payload delle chiamate API (precedentemente chiamato "Corpo del messaggio"), è importante valutare chi ha accesso all'esecuzione di Trace. Poiché la gestione utenti è una responsabilità del cliente, anche la concessione delle autorizzazioni Trace è responsabilità del cliente. Apigee, in qualità di proprietario della piattaforma, ha la possibilità di aggiungere un utente all'organizzazione di un cliente e di assegnare i privilegi. Questa funzionalità viene utilizzata solo su richiesta di assistenza da parte del cliente in una situazione in cui sembra che l'assistenza clienti non sia disponibile e si ritiene che l'esame di una sessione di Trace fornisca le informazioni migliori sulla causa principale.
Mascheramento dei dati
Il mascheramento dei dati impedisce la visualizzazione dei dati sensibili solo durante una sessione di traccia/debug, sia in Trace (UI Edge) che nel backend tramite il debug (API Edge). 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 archiviati
Il mascheramento dei dati NON impedisce che i dati siano visibili nei file di log, nella cache, nell'analisi e così via. Per assistenza con il mascheramento dei dati nei log, valuta l'aggiunta di un pattern regex al file logback.xml. In genere, i dati sensibili non devono essere scritti nella cache o ad analisi senza una solida giustificazione aziendale e una revisione da parte del team legale e per la sicurezza del cliente.
Cache L1 e L2
La memorizzazione nella cache è disponibile per i clienti PCI per l'utilizzo solo con dati non regolamentati. La cache non deve essere utilizzata per i dati PCI Card Holder (CHD); non è approvata dal controllo di conformità PCI di Apigee come posizione di archiviazione per CHD. Secondo le linee guida PCI (Requisito 3: proteggere i dati dei titolari di carte archiviati) , i dati PCI devono essere archiviati solo in una posizione conforme allo standard PCI. L'utilizzo della cache L1 utilizzerà automaticamente anche la cache L2. La cache L1 è di "solo memoria", mentre la cache L2 scrive i dati su disco per sincronizzarli su più cache L1. La cache L2 è ciò che mantiene sincronizzati più processori di messaggi all'interno di una regione e a livello globale. Al momento non è possibile avere la cache L1 abilitata senza una cache L2. La cache L2 scrive i dati su disco in modo che possano essere sincronizzati con altri processori di messaggi per l'organizzazione del cliente. Poiché la cache L2 scrive i dati su disco, l'uso della cache per CHD o altri dati limitati non è supportato.
L'utilizzo della cache da parte dei clienti è consentito per i dati non CHD e altri dati senza limitazioni. Non disabilitiamo la cache per impostazione predefinita per i clienti PCI, perché alcuni clienti eseguono chiamate API sia PCI che non PCI attraverso una singola organizzazione. Poiché la funzionalità è ancora abilitata per i clienti PCI, è responsabilità del cliente utilizzare il servizio in modo appropriato e addestrare gli utenti a non utilizzare la cache quando è probabile che i dati PCI siano nella chiamata API. Il controllo della conformità PCI di Apigee non supporta le immagini CHD archiviate 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 della loro organizzazione, incluso l'utilizzo di Trace. Istruzioni dettagliate sono disponibili qui e nell'articolo sull'utilizzo dello strumento Trace. (Requisito PCI 10: monitorare e monitorare tutti gli accessi alle risorse di rete e ai dati dei titolari di carte)
Requisiti per password complesse o SAML
I clienti con requisiti specifici per le password devono utilizzare SAML per soddisfare le proprie esigenze individuali. Vedi Attivazione dell'autenticazione SAML per Edge. Edge offre inoltre l'autenticazione a più fattori (Requisito PCI 8: assegna un ID univoco a ogni persona con accesso al computer). Vedi Abilitare l'autenticazione a due fattori per il tuo account Apigee.
Sicurezza degli endpoint
Analisi degli endpoint
L'analisi e il test degli host sono necessari per la conformità PCI (Requisito 11: testare regolarmente sistemi e processi di sicurezza). Per Edge Cloud, i clienti sono responsabili della scansione e dei test dei loro endpoint API (a volte chiamati "componenti di runtime") in Edge. I test dei clienti devono riguardare gli effettivi servizi proxy API 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, 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 loro 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. Anche se sono necessari ulteriori chiarimenti, apri una richiesta di assistenza che faccia riferimento ai test pianificati. Si prega di inviare una notifica ad Apigee in anticipo per consentirci di essere a conoscenza del traffico di test.
I clienti che testano i loro endpoint devono cercare eventuali problemi specifici delle API, eventuali problemi relativi ai servizi Apigee e anche controllare il protocollo TLS e altri elementi configurabili. Tutti gli elementi trovati relativi ai servizi Apigee devono essere comunicati ad Apigee tramite una richiesta di assistenza.
La maggior parte degli elementi relativi all'endpoint sono self-service del cliente e possono essere risolti esaminando la documentazione di Edge. Se non è chiaro come risolvere il problema, apri una richiesta di assistenza.
Configurazione TLS
Secondo gli standard PCI, è necessario eseguire la migrazione di SSL e TLS iniziale a versioni protette. È responsabilità dei clienti definire e configurare i propri endpoint TLS per i proxy API. Questa è una funzionalità self-service di Edge. I requisiti dei clienti in merito alla selezione di crittografia, protocollo e algoritmi sono ampiamente variabili e specifici dei singoli casi d'uso. Poiché Apigee non conosce i dettagli della progettazione delle API e dei payload dei dati di ogni cliente, questi 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 Edge non è necessaria per il corretto funzionamento di Edge. Tuttavia, sono disponibili servizi per l'archiviazione dei dati in Edge. I clienti possono scegliere di utilizzare la cache, le mappe chiave-valore o le analisi per l'archiviazione dei dati. Nessuno di questi servizi è autorizzato per l'archiviazione di CHD in base al controllo PCI di Apigee. In base al Requisito PCI 3 (Proteggere i dati dei titolari di carte archiviati), i dati PCI devono essere archiviati solo in posizioni conformi allo standard PCI. L'utilizzo di questi servizi è disponibile per i clienti per l'archiviazione di dati non PCI o altri dati non soggetti a restrizioni, in conformità con i 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 i contenuti CHD. Sono consigliate le revisioni della configurazione, dei criteri e dei deployment da parte degli amministratori dei clienti per evitare l'uso accidentale o dannoso dei servizi di archiviazione dati in Edge 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 Edge. Tuttavia, i clienti sono liberi di criptare i propri dati PCI prima di inviarli a Edge. Requisito PCI 4: (crittografia della trasmissione dei dati dei titolari di carte su reti aperte e pubbliche) consiglia di criptare i dati dei titolari di carte su reti pubbliche e aperte. I dati criptati nel payload (o nel corpo del messaggio) non impediscono il funzionamento di Edge. Alcuni criteri perimetrali 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 a Edge. Tuttavia, altri criteri e pacchetti creati dal cliente funzioneranno anche se il payload dei dati è criptato.