Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info
Affinché un cliente sia conforme a PCI su Apigee Edge Public Cloud, esistono alcune azioni e alcuni 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 devono essere conformi a PCI. Questi elementi sono self-service in Edge e devono essere risolti 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 matrice di responsabilità PCI-DSS 3.2.1 di Google Apigee e condividerla con il proprio Qualified Security Assessor PCI quando eseguono il proprio audit PCI.
Mappatura dei requisiti PCI
| Requisito PCI | Sezione |
|---|---|
| Requisito 7: limitare l'accesso ai dati del titolare della carta in base alle necessità dell'attività | |
| Requisito 3: proteggere i dati del titolare della carta memorizzati | |
| Requisito 10: monitorare e controllare tutto l'accesso alle risorse di rete e ai dati dei titolari della carta | |
| Requisito 8: assegna un ID univoco a ogni persona con accesso al computer | |
| Requisito 11: testare regolarmente i sistemi e le procedure di sicurezza | |
| Requisito 4: cripta la trasmissione dei dati del titolare della carta su reti aperte e pubbliche | |
| Requisito 3: proteggere i dati del titolare della carta memorizzati | |
| Requisito 4: cripta la trasmissione dei dati del titolare della carta su reti aperte e pubbliche |
Per ottenere l'Attestazione di conformità (AOC) al PCI Data Security Standard, apri un ticket con l'assistenza Apigee o contatta il team di vendita di Apigee.
Traccia / debug
La funzionalità di traccia/debug è 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 il Message Processor di Apigee. Trace e Debug sono due nomi per lo stesso servizio, a cui si accede tramite meccanismi diversi. Trace è il nome di questo servizio all'interno dell'interfaccia utente di Edge. Debug è il nome dello stesso servizio quando viene utilizzato tramite chiamate API. L'utilizzo del termine Traccia in questo documento è valido sia per la traccia sia per il debug.
Durante una sessione di monitoraggio, viene applicato il "mascheramento dei dati". Questo strumento può impedire la visualizzazione dei dati durante una traccia. Consulta la sezione Mascheramento dei dati di seguito.
Per i clienti PCI possono essere utilizzate mappe di valori delle chiavi (KVM) criptate. Se è in uso un KVM criptato, è comunque possibile utilizzare la funzionalità di monitoraggio, ma alcune variabili non saranno visibili nella schermata di visualizzazione di Monitoraggio. È possibile eseguire ulteriori passaggi per visualizzare anche queste variabili durante una traccia.
Istruzioni dettagliate sull'utilizzo di Trace sono disponibili in Utilizzare lo strumento Trace.
I dettagli sulle mappe di valori chiave, incluse quelle criptate, sono disponibili nella pagina Utilizzare le mappe di valori chiave.
Utilizzo/autorizzazioni
L'accesso a Trace viene gestito tramite il sistema RBAC (Controllo dell'accesso basato sui ruoli) per gli account utente in Edge. Istruzioni dettagliate sull'utilizzo del sistema RBAC per concedere e revocare i privilegi di Trace sono disponibili in Assegnare i ruoli e Creare ruoli personalizzati nell'IDE. Le autorizzazioni di monitoraggio consentono all'utente di avviare un monitoraggio, interrompere un monitoraggio e accedere all'output di una sessione di monitoraggio.
Poiché Trace ha accesso al payload delle chiamate API (chiamato formalmente "corpo del messaggio"), è importante valutare chi ha accesso per eseguire un monitoraggio. Poiché la gestione degli utenti è responsabilità del cliente, anche la concessione delle autorizzazioni di monitoraggio è responsabilità del cliente. Apigee, in qualità di proprietario della piattaforma, ha la possibilità di aggiungere un utente a un'organizzazione cliente e di assegnargli i privilegi. Questa funzionalità viene utilizzata solo su richiesta di assistenza da parte del cliente in una situazione in cui sembra che il servizio clienti non funzioni e si ritiene che l'esame di una sessione di traccia fornisca le migliori informazioni sulla causa principale.
Mascheramento dei dati
La mascheratura dei dati impedisce la visualizzazione di dati sensibili solo durante una sessione di traccia/debug, sia in Trace (interfaccia utente di Edge) sia nel backend tramite Debug (API Edge). Per informazioni dettagliate su come configurare il mascheramento, consulta Nascondimento e mascheramento dei dati. Il mascheramento dei dati sensibili fa parte del Requisito 3 del PCI: Proteggi i dati dei titolari di carte archiviati
Il mascheramento dei dati NON impedisce la visibilità dei dati nei file di log, nella cache, negli analytics e così via. Per assistenza con il mascheramento dei dati nei log, ti consigliamo 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 valida giustificazione aziendale e la 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 CHD. In base alle indicazioni PCI (Requisito 3: Proteggi i dati dei titolari di carte archiviati) , i dati PCI devono essere archiviati solo in una posizione conforme a PCI. L'utilizzo della cache L1 comporterà automaticamente anche l'utilizzo della cache L2. La cache L1 è "solo memoria", mentre la cache L2 scrive i dati sul disco per sincronizzarli su più cache L1. La cache L2 mantiene sincronizzati più elaboratori di messaggi all'interno di una regione e a livello globale. Al momento non è possibile attivare la cache L1 senza una cache L2 di supporto. La cache L2 scrive i dati su disco in modo che possano essere sincronizzati con altri elaboratori di messaggi per l'organizzazione del cliente. Poiché la cache L2 scrive i dati su 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 per altri dati senza limitazioni. Non disattiviamo la cache per impostazione predefinita per i clienti PCI, perché alcuni clienti eseguono chiamate API sia PCI che non PCI tramite una singola organizzazione. Poiché la funzionalità è ancora attiva 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 presenti nella chiamata dell'API. L'audit di conformità PCI di Apigee non supporta i file CHD memorizzati nella cache.
Istruzioni dettagliate sull'utilizzo della cache sono disponibili in Aggiunta della memorizzazione nella cache e della persistenza.
Audit trail
I clienti hanno la possibilità di esaminare la cronologia di controllo di tutte le attività amministrative svolte all'interno dell'organizzazione del cliente, incluso l'utilizzo di Trace. Le istruzioni dettagliate sono disponibili qui e nella pagina Utilizzo dello strumento di tracciamento. (Requisito 10 del PCI: monitora e controlla tutto l'accesso alle risorse di rete e ai dati dei titolari di carte)
Requisiti complessi per le password o SAML
I clienti con requisiti specifici per le password devono utilizzare SAML per soddisfare le loro esigenze individuali. Consulta Attivare l'autenticazione SAML per Edge. Edge offre anche l'autenticazione a più fattori (Requisito 8 del 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
La scansione e il test degli host sono obbligatori per la conformità PCI (Requisito 11: testa regolarmente i sistemi e le procedure di sicurezza). 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 del cliente devono coprire i servizi proxy API effettivi ospitati su Edge, dove il traffico API viene inviato a Edge prima di essere elaborato e poi inviato al data center del cliente. I test delle risorse condivise, come l'interfaccia utente del portale di gestione, non sono approvati per i singoli clienti (un report di terze parti che copre i test dei servizi condivisi è disponibile per i clienti ai sensi di un contratto 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 l'interfaccia utente di gestione condivisa. Tuttavia, se sono necessari ulteriori chiarimenti, apri una richiesta di assistenza facendo riferimento ai test pianificati. Ti invitiamo a inviare una notifica ad Apigee in anticipo per consentirci di essere a conoscenza del traffico di test.
I clienti che testano i propri endpoint devono cercare eventuali problemi specifici dell'API, eventuali problemi relativi ai servizi Apigee e anche controllare TLS e altri elementi configurabili. Eventuali elementi correlati ai servizi Apigee devono essere comunicati ad Apigee tramite una richiesta di assistenza.
La maggior parte degli elementi relativi all'endpoint sono elementi self-service per i clienti e possono essere corretti esaminando la documentazione di Edge. Se non sai come risolvere alcuni problemi, apri una richiesta di assistenza.
Configurazione TLS
In base agli standard PCI, è necessario eseguire la migrazione da SSL e TLS precedenti alle versioni protette. I clienti sono responsabili della definizione e della configurazione dei propri endpoint TLS per i proxy API. Si tratta di una funzionalità self-service in Edge. I requisiti dei clienti relativi alla crittografia, al protocollo e alle scelte di algoritmi sono molto variabili e specifici per i singoli casi d'uso. Poiché Apigee non conosce i dettagli del design dell'API e dei payload di dati di ogni cliente, è responsabilità dei clienti determinare la crittografia appropriata per i dati in transito. Istruzioni dettagliate sulla configurazione di TLS sono disponibili in TLS/SSL.
Archiviazione dei dati
L'archiviazione dei dati all'interno di Edge non è necessaria per il corretto funzionamento di Edge. Tuttavia, in Edge sono disponibili servizi per l'archiviazione dei dati. I clienti possono scegliere di utilizzare cache, mappe chiave-valore o analisi per l'archiviazione dei dati. Nessuno di questi servizi è autorizzato allo stoccaggio di CHD in base all'audit PCI di Apigee. Ai sensi del Requisito 3 (Protezione dei dati dei titolari di carte archiviati) del PCI, 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 di altri dati non soggetti a limitazioni, in base ai requisiti di sicurezza e legali del cliente. Questi servizi sono elementi self-service per i clienti, pertanto è responsabilità del cliente configurarli in modo da non acquisire o archiviare CHD. Per evitare un uso accidentale o dannoso dei servizi di archiviazione dati in Edge in modo non conforme, è consigliabile che gli amministratori dei clienti esaminino la configurazione, i criteri e i deployment .
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 criptare i propri dati PCI prima di inviarli a Edge. Requisito 4 del PCI: (Crittografa la trasmissione dei dati del titolare della carta su reti pubbliche aperte) consiglia di criptare i dati del titolare della carta su reti pubbliche aperte. I dati criptati nel payload (o nel corpo del messaggio) non impediscono il funzionamento di Edge. Alcuni criteri 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 la modifica da parte di Edge. Tuttavia, altri criteri e set di criteri e pacchetti creati dal cliente funzioneranno anche se il payload dei dati è criptato.