It would seem to me that most payment systems would encrypt all the
credit card information at [the database] (making the information itself
un-obtainable?)
Hai ragione sul fatto che tutti i sistemi di pagamento dovrebbero crittografare i dati della carta di credito nel database. Tuttavia, la tua ipotesi che ciò renda le informazioni introvabili non è corretta.
Molto semplicemente, i dati nel database sono lì per essere utilizzati. Per essere utilizzato, deve essere decodificato. Pertanto, i sistemi aziendali e gli utenti legittimi devono essere in grado di decodificarlo. Un utente malintenzionato può accedervi mentre è decifrato legittimamente, tentare di compromettere le chiavi di crittografia o utilizzare i processi legittimi che sfruttano tali chiavi.
Ecco una citazione dal Servizio di archiviazione dati PCI
Some cryptography solutions encrypt specific fields of information
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.
Quindi, prendiamo in considerazione tre metodi di crittografia dei dati delle carte che si trovano in un database e i punti deboli che consentono agli aggressori di ottenere comunque i dati della carta:
- Codifica del disco completo
- Crittografia dati trasparente
- Crittografia a livello di applicazione
Crittografia su disco completo
Con la crittografia a disco intero (e con la crittografia a livello di file dei file di database a livello di sistema operativo), i dati vengono crittografati solo quando il database non è in esecuzione. Affinché il database possa essere eseguito, i file devono essere decodificati. Con qualcosa come Bitlocker, EFS o LUKS + dm-crypt, una volta che il filesystem è sbloccato (di solito al momento del boot) i dati sono leggibili come se non fosse crittografato.
Una volta che i file sono sbloccati e il database attivo e funzionante, l'utente malintenzionato può interrogare le carte fuori dal database utilizzando SQL. Possono copiare i file di database decrittografati dal sistema e esaminare i loro contenuti. Possono anche usare qualcosa come "stringhe" e "grep" per estrarre informazioni dai file dalla riga di comando.
La crittografia dell'intero disco protegge i dati se qualcuno ruba il server o il disco. Non protegge da un utente malintenzionato che ottiene l'accesso al sistema in esecuzione. Incoraggia il doppio controllo (gli amministratori di database potrebbero richiedere all'IT di sbloccare il disco per loro).
Crittografia dati trasparente
TDE è simile alla crittografia a disco intero, tranne per il fatto che è stata mantenuta a livello di DBMS (Database) anziché il livello del sistema operativo. E ha la stessa debolezza; una volta che il database viene attivato e le chiavi fornite per sbloccare i dati, i dati sono disponibili per gli utenti e gli utenti del sistema come se non fossero crittografati.
Una volta che il database è attivo e funzionante, l'utente malintenzionato può interrogare le carte fuori dal database utilizzando SQL. Questa è l'intera cosa "Trasparente".
A differenza della crittografia a disco intero, TDE spesso mette sia le chiavi che i dati crittografati nelle mani dei DBA.
Crittografia a livello di applicazione
In Crittografia a livello di applicazione, le chiavi di crittografia sono conservate dall'applicazione e i dati sensibili vengono archiviati crittografati nel database. Poiché il database e il codice dell'applicazione di solito vengono eseguiti su server diversi, questo fornisce un livello di separazione: un utente malintenzionato che ottiene il controllo completo sul server del database non può decodificare i dati a meno che non compromettano anche un server delle applicazioni.
I dati vengono decifrati in modo "just in time"; solo i numeri delle carte discreti vengono decifrati secondo necessità. A differenza delle altre due opzioni, l'intero set di dati non è in giro decrittografato in un sistema in esecuzione.
Un utente malintenzionato deve compromettere sia le chiavi che i dati o compromettere un processo di decrittografia (ad esempio, se possono eseguire il programma applicativo che estrae una scheda e la decrittografa, possono estrarla e decrittografarla finché non vengono catturate ).
I sistemi a livello di applicazione supportano il vantaggio che la decrittografia può essere registrata dall'applicazione. Se l'attaccante compromette un processo piuttosto che una chiave, può generare una traccia di registrazione che rende evidente la loro attività. Se è normale vedere 200.000 decriptati all'ora, e questo salta a 2.000.000, qualcosa sta succedendo.
Il doppio controllo è in qualche modo standard con la crittografia a livello di applicazione.
Quindi - tre diversi metodi, alcuni più forti, alcuni più deboli. Tutti soddisfano i requisiti PCI. Tutti possono essere compromessi da un utente malintenzionato, poiché consentono a tutti gli utenti legittimi di accedere ai dati riservati.