Come implementare il requisito 3.5.2 PCI DSS?

Question

Come implementare il requisito 3.5.2 PCI DSS?

#1 da (3 voti)
#2 da (1 voti)

2

Secondo Requisito PCI-DSS 3.5.2 :

Le chiavi segrete e private utilizzate per crittografare / decodificare i dati dei titolari di carta dovrebbero essere archiviati in uno dei seguenti moduli in ogni momento:

Crittografato con una chiave di crittografia della chiave che è strong almeno quanto la chiave di crittografia dei dati, e cioè memorizzato separatamente dalla chiave di crittografia dei dati .
all'interno di un dispositivo crittografico sicuro (come un modulo di sicurezza host ( HSM ) o PTS -approved point-of- dispositivo di interazione).
Almeno due componenti chiave a lunghezza intera o condivisioni di chiavi, in conformità con un metodo accettato dal settore .

Le mie domande:

Come archiviare Key-Encrypting Key separatamente dalla chiave di crittografia dei dati e è una best practice ?
Se decidiamo di archiviare KEK separatamente da DEK , allora dovremmo memorizzare DEK in un server e KEK in un server separato
Se decidi di memorizzare le chiavi in un dispositivo crittografico , allora quale sarà una best practice tra HSM e PTS ?
Quali sono i due componenti chiave o le condivisioni di chiavi a lunghezza intera ? Qualcuno potrebbe spiegarlo?

Sono disponibili link o documenti utili?

pci-dss

posta RajeshKannan 25.02.2014 - 20:21

fonte

2 risposte

Leggi altre domande sui tag pci-dss

Lo stack mnet / iis di .net supporta le whitelist per l'autenticazione bidirezionale per le connessioni SSL / TLS? Il reverse proxy tra due server Web influisce sulla sicurezza di entrambi?

score 3 · Answer 1

Pensa alla chiave di crittografia dei dati come a una "chiave di sessione" in SSL. Può / dovrebbe essere un valore casuale da far ruotare allo scopo di crittografare un numero di conto. La chiave di crittografia chiave sarebbe la chiave pubblica recuperata da un certificato. Si utilizza KEK per crittografare il DEK, quindi eliminare il DEK in chiaro dopo aver crittografato i dati. Nel frattempo, la chiave privata (abbinata alla chiave pubblica sul certificato) rimane protetta in modo sicuro all'interno di un ambiente protetto, lontano dall'ambiente dei dati. E sì, questa è una buona pratica.
Non memorizzerei mai il DEK in chiaro. Invece, crittografare il DEK con KEK e memorizzare solo il DEK crittografato.
Un HSM fornisce un ambiente antimanomissione per ospitare operazioni crittografiche ed è preferito per operazioni sensibili come la decrittografia di chiavi.
Usa un algoritmo come Shamir's Secret Sharing. Ti permette di dividere la chiave in più parti e richiede un certo numero di parti per rimontarla.

score 1 · Answer 2

Bene, lascia che provi ad aiutarti.

Immaginiamo di avere una cassastrong in un cassetto pieno di diamanti, conserverai la combinazione o la chiave della cassastrong nello stesso cassetto? Questo è lo stesso, solo buon senso. Quindi, per rispondere alle tue domande:

Sì, è una buona pratica. Se non usi molto il tuo KEK, potresti persino tenerlo in una pendrive all'interno di una cassastrong. Ma dal momento che potresti usarlo molto, puoi salvarlo su un altro server (o su un PC diverso).
Bene spetta a te, se qualcuno ha accesso all'intero disco troverà entrambi: KEK e DEK, questo problema vale di per sè i soldi per un nuovo server? Dovrai fare qualche analisi al riguardo. In caso contrario, considera almeno la memorizzazione in gruppi di autorizzazioni diversi (forse utenti diversi con capacità diverse ...).
PTS non ha nulla da fare qui vai per HSM se ti puoi permettere dato che è una soluzione da sola e sembri un po 'insicuro su questi argomenti.
Questo è semplicemente un modo per coinvolgere diverse persone / processi durante la decodifica di una chiave, questa è chiamata condivisione segreta e ci sono diversi algoritmi là fuori.