IS TDE PCI-Compliant?

Suppongo che tu stia parlando della funzione "TDE" fornita da Microsoft SQL Server.

TDE significa Crittografia dati trasparente , enfasi su "trasparente" ". Questo è un livello di crittografia applicato ai dati così come sono memorizzati; ogni singolo byte gestito da SQL Server viene crittografato prima di essere scritto su disco e decifrato quando letto. Le applicazioni che utilizzano SQL Server non devono essere a conoscenza di tale processo; è una questione che risiede puramente nel dialogo tra SQL Server e i suoi file di archiviazione. Quindi la trasparenza. Il lato positivo è che è facile da applicare e funziona molto bene (sovraccarico della CPU da piccolo a trascurabile, senza I / O extra, senza spazio extra ...). Il lato oscuro è che SQL Server stesso, non l'applicazione, è il gatekeeper: chiunque abbia accesso a SQL Server sarà in grado di vedere i dati chiari.

Per la conformità PCI, vedi questo documento che include questo paragrafo (alla fine):

Some cryptography solutions encrypt specific fields of informatio n stored in a database; others encrypt a singular file or even the entire disk where data is stored. If full-disk encryption is used, logical access must be managed independently of native operating system access control mechanisms. Decryption keys must not be tied to user accounts. Encryption keys used for encryption of cardholder data must be protected against both disclosure and misuse. All key management processes and procedures for keys used for encryption of cardholder data must be fully documented and implemented. For more details, see PCI DSS Requirement 3.

"La crittografia del disco completo" è ciò che si applica a TDE (TDE è nominalmente applicato su file , ma tutti). In TDE, la chiave di crittografia effettiva è gestita da SQL Server, che concede o meno l'accesso logico agli utenti in base a ... la sua configurazione, che può o meno mappare sugli account utente. Quindi direi che il fatto che TDE garantisca la conformità PCI dipende da come viene utilizzato .

Non ho il diritto di dare una risposta definitiva su come si possa raggiungere la conformità PCI con TDE, ma noto che la pagina di Wikipedia include un estratto incoraggiante: "In genere le aziende utilizzano TDE per risolvere problemi di conformità come PCI DSS." Quindi si può supporre che soddisfare i requisiti PCI con TDE sia possibile , o almeno molte persone sembrano fermamente convinte che sia possibile, il che è quasi altrettanto buono.

Microsoft ha documentazione su come SQL Server deve essere configurato e utilizzato in un contesto di conformità. Hanno anche un Webcast che può includere molto di informazioni utili (non l'ho visualizzato).

La conformità PCI e la crittografia riguardano la crittografia dal punto di vista della sicurezza della gestione delle chiavi. Mentre fa riferimento a una crittografia strong, in genere viene utilizzato per indicare standard di settore come 3DES 112, AES 128/256, ecc. Quando si fa riferimento alla crittografia a chiave pubblica, si sta cercando RSA2048.

I dati dei titolari di carta (PAN) devono essere crittografati a riposo utilizzando la crittografia avanzata. Con TDE, i dati vengono crittografati a riposo usando la tua scelta da SQL, quindi probabilmente AES128 o AES256.

Per la conformità PCI, devi essere in grado di mostrare il doppio controllo e dividere la conoscenza delle chiavi di crittografia. Se puoi dimostrare questo (che dovresti essere in grado di) con TDE, allora lo sei. Potrebbe valerne la pena discuterne con il tuo QSA se ne hai uno.

Dovresti pensare al motivo per cui vuoi la crittografia e da cosa ti protegge (a meno che tu non voglia semplicemente un segno di spunta nella casella per PCI). Con TDE, la crittografia è trasparente quindi, se il disco viene rubato, il ladro visualizza i dati crittografati nello spazio del database mentre gli utenti locali vedono i dati in chiaro in ogni momento. A causa dei controlli di sicurezza fisica, il furto fisico non è il problema, ma piuttosto il furto dei dati. L'utilizzo di TDE significa che i dati saranno copiabili e visualizzabili dal personale interno e, a seconda dei controlli sul front-end, potrebbero anche essere estratti in chiaro da un utente [malevolo].