PCI DSS - rete VPN?

5

La mia rete è segmentata in interna (che contiene dati di titolari di carta privati), DMZ e VPN. C'è un gateway intermedio che limita l'accesso, ad esempio:

VPN: 10.0.0.0/24 DMZ: 10.1.0.0/24 INT: 10.2.0.0/24

GW / firewall ha ip .1 in tutte e tre le reti. L'accesso da DMZ al titolare della carta (INT) è limitato tramite FW e l'accesso dalle reti pubbliche al titolare della carta (INT) è completamente vietato.

Sono confuso su una cosa: se mi collego alla rete VPN dalla mia stazione di lavoro, sono autorizzato a fare connessioni ai server nella rete INT? Per scopi amministrativi, ho bisogno di accesso ssh a quei nodi, e mi sembra logico che connettersi a loro da VPN IP, tramite gateway / firewall, dovrebbe essere OK.

Ma ricevo risposte confuse da altri colleghi che lavorano su questi argomenti. Pensano che l'accesso da VPN a INT debba essere vietato e l'unico modo per connettersi ai server INT dovrebbe essere la connessione a VPN, quindi ssh-ing a uno dei server DMZ e quindi il passaggio a INT. Non riesco a trovare nessuna di queste nozioni nei documenti PCI DSS ...

Il motivo di questa spiegazione è che la macchina di connessione VPN non è sotto scope PCI DSS, quindi viene considerata come accesso non sicuro / pubblico, oppure VPN elimina tale nozione?

    
posta Jakov Sosic 06.08.2015 - 14:05
fonte

3 risposte

4

Secondo PCI, hai 3 tipi di reti: 1. INTERNO (Dati dei titolari di carta) 2. DMZ 3. INSECURE

Se la tua rete VPN è considerata una rete DMZ, allora è sotto ambito PCI, proprio come ogni altro dispositivo nella zona DMZ.

Se la tua rete VPN è considerata come rete INSECURE, non dovresti consentire la connessione diretta ai server nella rete INTERNA.

Quindi, sei in ambito PCI, o sei INSECURE. Il firewall deve essere configurato per non consentire la comunicazione diretta tra INSECURE e la rete INTERNA.

    
risposta data 06.08.2015 - 14:16
fonte
2

IANAQSA ...

Is the reason for this explanation that the VPN connecting machine is not under PCI DSS scope, so it's treated as unsecure/public access, or does VPN eliminate that notion?

Prima di tutto, se si dispone di una VPN, è necessario disporre dell'autenticazione a 2 fattori per renderla conforme PCI. Non l'hai menzionato, quindi ho pensato che fosse esplicitato.

Una volta che hai la tua VPN a 2 fattori, la domanda se puoi accedere al tuo CDE (in-scope) viene dopo. Puoi farlo, o non farlo. Se lo fai, allora stai mettendo la tua rete VPN in-scope, o non lo sei, a seconda dei controlli di segregazione ( DSS 3.1 p11 ):

To be considered out of scope for PCI DSS, a system component must
be properly isolated (segmented) from the CDE, such that even if the
out-of-scope system component was compromised it could not impact the
security of the CDE. 

Ecco alcuni esempi fatti qui - se i tuoi utenti possono accedere a un portale web nella rete in-scope di CDE tramite la VPN, e tale portale consente loro di gestire i pagamenti ma non per vedere decrittografati Dati PAN, quindi probabilmente non stai mettendo i tuoi dispositivi VPN in portata.

D'altra parte, se i tuoi utenti VPN possono eseguire uno strumento di query database ed esportare dati PAN decifrati dal database in-scope CDE al loro host VPN, allora quella rete VPN non è propriamente segregata ed è in-scope.

But, I'm getting fuzzy responses from other colleagues working on these issues. They think access from VPN to INT should be forbidden, and the only way to connect to INT servers should be by connecting to VPN, then ssh-ing to one of the DMZ servers and then hopping into INT. I can't find any such notion in PCI DSS docs...

Questo è tutto un aspetto del giudizio di QSA, ma la mia esperienza suggerisce che qualsiasi interazione tra la rete VPN e le reti in ambito CDE dovrebbe essere mediata da proxy o da altri punti di controllo del livello dell'applicazione al fine di mantenere la rete VPN fuori di scopo. Indipendentemente dal fatto che il semplice "island-hopping" come descritto sia sufficiente o meno dipende dal QSA.

I "documenti" parlano di questi problemi senza affrontarli chiaramente. Il Open PCI Scoping Toolkit è stato un tentativo di regolarizzare l'approccio che le entità e i QSA hanno preso a progettare, descrivere e controllare le reti; un modo per compensare tale mancanza nel DSS stesso. Non è uno standard, ma può essere molto utile da leggere e se il tuo QSA lo rispetta (alcuni lo fanno, altri no), allora può alleviare le difficoltà a superare i confini dell'ambito della rete.

    
risposta data 06.08.2015 - 14:54
fonte
1

Lascia che ti dia una dichiarazione di non responsabilità prima. Qualsiasi consiglio dato verrà trumpato dal tuo QSA e poiché ho un ambito limitato della tua rete, posso solo fornire una guida.

In base alla tua domanda, dovresti avere almeno due zone, la tua DMZ dove è in esecuzione la tua applicazione e la tua zona interna in cui i dati vengono trattenuti (in genere mi riferisco a questa come alla zona del database come richiede PCI per per separare specificamente questo dal tuo DMZ.

Hai anche una terza zona per l'accesso remoto (la tua zona VPN).

Immagino che la tua VPN non trasferisca CHD attraverso il suo filo e il tuo l'obiettivo è accedere ai server da remoto. In breve, puoi utilizzare VPN e SSH nei tuoi server back-end dalla rete VPN, ma ti verrà richiesto di implementare Two-Factor autenticazione .

Un ambiente PCI è qualsiasi cosa tocchi CHD, in pratica qualsiasi parte della rete che trasferisce o memorizza CHD. Come forse saprai, limitiamo la portata separando le reti. Una rete VPN che è separata può essere eliminata dall'ambito, ma il tuo ambiente PCI deve ancora mantenere la sua parte delle linee guida.

Ciò significa che le connessioni nell'ambiente devono essere registrate, centralmente, ed è necessario utilizzare l'autenticazione a due fattori, con un singolo account. Il proxy attraverso un server sulla DMZ può essere un ulteriore livello di sicurezza, ma questo non ti assolve dal richiedere i requisiti che ho elencato.

    
risposta data 06.08.2015 - 18:37
fonte

Leggi altre domande sui tag