Posizionamento PCI DSS del server puppet (o chef)?

3

Sono perplesso sul fatto che sia consentito configurare un server fantoccio in un ambiente PCI DSS e, se lo sono, dove dovrebbe essere posizionato?

Stavo pensando di installarlo sul gateway e tutti gli host si collegherebbero al gateway https / 8140 per raccogliere i manifesti dei nodi.

Questo violerebbe i requisiti PCI DSS e, se lo fosse, c'è un posto migliore per metterlo? Forse DMZ?

Quali sono le tue esperienze Puppet / Chef / Salt in ambienti PCI DSS?

Grazie

    
posta Jakov Sosic 06.03.2016 - 15:09
fonte

1 risposta

3

Ho lavorato per un'azienda di QSA per 2 anni, quindi ecco una visione ex-assessor del tuo caso.

È assolutamente necessario utilizzare gli strumenti di gestione della configurazione (CM) dal punto di vista PCI DSS. In breve, per essere conforme alla conformità standard, è necessario rendere questo sistema PCI DSS conforme e allineare i processi di gestione e supporto della configurazione con i requisiti PCI DSS.

Prima di tutto, gestisci l'ambito PCI DSS. Mentre strumenti come Puppet / Chef non sono direttamente coinvolti nell'elaborazione dei dati delle carte di pagamento, influenzano la sicurezza di tali componenti di sistema. Non sarà considerato parte dell'ambiente di dati dei titolari di carta (CDE), quindi non è richiesto di sedersi all'interno di un segmento di rete isolato. Anche le eventuali dipendenze del servizio Puppet / Chef che influenzano la propria sicurezza rientreranno nell'ambito della revisione PCI DSS. Questi possono includere: server AV, server di registro, autenticazione, controllo di versione, server di repository di pacchetti e così via. Pertanto, nel caso in cui si disponga di tale infrastruttura nell'ambito dell'ambito PCI DSS, è consigliabile riutilizzarla (ad esempio, inoltrare i registri al server di registro dell'ambito già in PCI).

Di solito ci sono due schemi consigliati quando si incorporano gli strumenti CM nel proprio ambiente:

  1. Installa il server autonomo all'interno di CDE e utilizzalo solo per la gestione dei componenti di sistema relativi a PCI. In questo modo, si riduce al minimo l'impatto sull'ambito PCI DSS esistente ma si perde la flessibilità.
  2. Utilizzare l'architettura multiserver e installarne una parte all'interno di CDE. In questo modo, ottieni una maggiore flessibilità, ma alcuni sistemi della tua rete "normale" non PCI avranno anche lo scopo.

In ogni caso, dovresti lavorare a stretto contatto con il tuo QSA per determinare se l'ambito previsto è stato definito correttamente e nessun sistema importante lasciato indietro.

Dopo aver compreso quali modifiche all'ambito PCI DSS verranno apportate incorporando gli strumenti di gestione della configurazione, è possibile pianificare come implementare i requisiti PCI tecnici e procedurali per questo ambito modificato. Qui non descriverò il processo, poiché è troppo lungo e non è diverso da quello che dovresti fare già con la tua infrastruttura esistente.

Un punto importante che voglio sottolineare però: l'introduzione di strumenti CM di solito influenza notevolmente le routine di gestione dei cambiamenti stabilite. Per i requisiti elencati nella clausola 6.4, ci sono molti compiti da svolgere quando si applicano le modifiche. Questo significa letteralmente tutto ciò che fai con tutto il tuo sistema CM deve essere pianificato / testato / rivisto / approvato in modo prescritto PCI. E questo è il motivo per cui molti negozi DevOps finiscono per utilizzare un sistema CM completamente isolato per gestire i sistemi relativi a PCIDSS. Ad ogni modo, assicurati di avere aggiornato le tue procedure di gestione delle modifiche.

Spero che questo aiuti - è difficile affrontare questo problema e non scrivere un lungo documento con molti condizionali "if else".

    
risposta data 06.04.2016 - 17:48
fonte

Leggi altre domande sui tag