Cosa impedisce a uno sviluppatore di accedere ai dati della carta di credito e ad altri dati segreti di un'azienda

PCI DSS le sezioni 6, 7 e 8 si riferiscono a questa domanda.

Ad esempio, parte della 6.3.2 che richiede la revisione del codice:

Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices.

6.4 con controllo delle modifiche:

A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.

7.1 controllo dell'accesso ... in molti ambienti lo sviluppatore che scrive il codice non accede mai ai sistemi operativi dove viene utilizzato con i dati in tempo reale:

Limit access to system components and cardholder data to only those individuals whose job requires such access.

E un tocco di 8.7 per mettere restrizioni su quelle persone con accesso:

Examine database and application configuration settings to verify that all user access to, user queries of, and user actions on (for example, move, copy, delete), the database are through programmatic methods only (for example, through stored procedures).

Ora, tutto ciò detto, a un insider di fiducia può essere difeso perfettamente? No, a causa della definizione stessa di "trusted". Questo è vero in tutti i luoghi (quante spie sono state "fidate"? John Anthony Walker viene in mente.) Ma ci sono le migliori pratiche per difendersi da una tale minaccia, per mitigarle, e il PCI DSS formalizza come requisiti un numero di queste pratiche (per le carte di credito ... altri segreti sono da soli!)

(E @ Stephen-Touset sottolinea, 3.5.2 richiede:

Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times:

E uno di questi modi è:

Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved point-of-interaction device)

Che ha il vantaggio di affidare il materiale chiave reale lontano dagli utenti e dagli amministratori giorno e giorno.)

A un livello non trascurabile, questo è (come hai detto) un problema di fiducia, non tecnico. Cerchiamo di stare attenti a quanto possiamo, assumiamo persone fidate che non abusino delle loro posizioni.

Detto questo, ci sono una serie di controlli che possono essere implementati per limitare l'accesso non autorizzato e / o per verificare che la fiducia negli individui sia ben posizionata e che, di fatto, non venga abusata.

Ecco alcuni di questi controlli:

• I segreti dovrebbero essere tenuti segreti. Le chiavi dovrebbero non essere incorporate nel software. Dovrebbero essere generati e gestiti da coloro che amministrano e / o utilizzano un'istanza dell'applicazione, non dallo sviluppatore dell'applicazione. Ciò significa che le chiavi utilizzate in un ambiente di sviluppo saranno diverse da quelle dell'ambiente QA e sicuramente diverse da quelle utilizzate in prod, e raramente c'è una ragione per cui uno sviluppatore abbia accesso a un ambiente di produzione, molto meno accesso alle chiavi lì.
• Separazione dei compiti. Ciò continua dalla fine dell'ultimo punto. Gli sviluppatori sviluppano applicazioni, i tecnici di rete gestiscono il traffico e i dispositivi di rete, i tecnici di server amministrano i server, gli amministratori di database controllano i dati e così via. Nella maggior parte dei casi, sarebbe irragionevole per uno sviluppatore avere accesso a server di produzione e database contenenti dati reali e sensibili come le informazioni sulle carte di credito.
• Verifica del lavoro. In questo caso, stiamo parlando principalmente della revisione del codice. Di nuovo, nella maggior parte dei casi, non c'è motivo per cui uno sviluppatore debba essere in grado di spingere il codice che fa chi-sa-cosa attraverso la produzione senza che nessuno lo dia un'occhiata. Sebbene questo sia esplicitamente progettato per catturare errori non intenzionali e che vengano seguite le migliori pratiche e convenzioni, dovrebbe avere l'utile effetto collaterale di assicurare che vengano notate le aggiunte intenzionalmente più dannose e che vengano sollevate le bandiere rosse.

Ci sono innumerevoli altri controlli che potrebbero essere potenzialmente elencati, ma queste sono alcune delle categorie principali in cui cadranno la maggior parte di esse.

Il costo per prevenire questo è enorme e quindi raramente viene fatto al di fuori di enormi gruppi di sviluppo ben finanziati. Le menzioni sopra riportate sulla revisione del codice, sulla revisione della sicurezza, ecc. Sono tutte buone idee, ma in pratica i clienti sono più interessati a ottenere codice funzionante che a ritardare l'utilizzo delle loro risorse per mesi mentre i processi di revisione si verificano.

Il caso di maggioranza della mia azienda riguarda aziende di medie dimensioni che sono disposte a spendere risorse ottenendo software personalizzato scritto per uso interno, ma non facendo splendere su un comitato di sviluppo conforme allo standard ISO solo per il loro sistema di tracciamento dei contatti dei clienti o il database di gestione dei progetti può essere migliorato.

In pratica non c'è quasi modo di prevenire questo tipo di abuso se non quello di trattare solo con i fornitori di software di cui ti fidi. Questa non è una soluzione, ovviamente, ma almeno pone la mente del cliente nel modo giusto e può guidarli a selezionare con cura i partner commerciali - e un fornitore di software è un partner commerciale, uno dei più intimo qualsiasi azienda avrà, anche se le persone sembrano incredibilmente cieche a questa maggior parte del tempo.

Considera gli scandali che sono emersi negli ultimi anni con Google, Apple, Microsoft, ecc. e il coinvolgimento della NSA. O persino le invasioni sulla privacy autogestite di Google. Gli sviluppatori stavano facendo in modo che qualcuno potesse rubare i dati dei loro clienti, e in un modo che i processi di revisione della sicurezza - che queste particolari organizzazioni sono abbastanza grandi da permettere - non catturassero. È davvero un "custode di IPS custodiet ipsos?" problema (acceso. "Chi custodisce le guardie?").

Nel mio caso abbiamo stabilito che non terremo mai i dati dei clienti da soli. Ciò significa che stiamo in piedi su piccoli server economici per i siti dei clienti e quelli servono direttamente l'attività. Questa è l'era di internet follemente veloce e di hardware economico; una piccola impresa non ha bisogno di un servizio cloud per accedere ai propri dati da qualsiasi parte del mondo. Per garantire la sicurezza e la ridondanza dei dati forniamo il backup over-the-wire, ma i suoi blob crittografati, quindi non possiamo leggerlo.

Noi potremmo certamente aprire buchi nei loro server e abusare della loro fiducia se volessimo. Ma non c'è modo di impedire a qualcuno di fare il male. In qualità di proprietario della mia azienda, ho deciso che il miglior equilibrio di sicurezza VS usabilità (per noi e per il cliente) è di avere i loro dati in attesa e di conservare solo i backup crittografati.

Ho menzionato la "nuvola" qui sopra. Questa è probabilmente la più grande minaccia alla sicurezza dei dati mai immaginata da nessuno fino ad ora, e ci sono esattamente zero modi per garantire la protezione dei dati dei clienti una volta che sono fuori dalle loro mani. "Il possesso è il 90% della legge" è una buona lezione, perché nell'era moderna il 90% della sicurezza dei dati.

Per le piccole-medie imprese in cui uno sviluppatore indossa cappelli multipli (DBA, sysadmin, supporto tecnico, webmaster, ecc.), il compito di soddisfare i requisiti PCI DSS sarebbe troppo oneroso. Sulla possibile soluzione per impedire a uno sviluppatore di ottenere dati sensibili, è necessario utilizzare un'API di terze parti in cui l'elaborazione e l'archiviazione di dati sensibili avviene su un sito Web di terze parti fidato anziché il tuo sito web.

Nel caso di transazioni con carta di credito e gestione ricorrente dei pagamenti, puoi utilizzare PayPal, che è conforme allo standard PCI DSS, invece di far girare il tuo sistema. Naturalmente, il codice deve ancora essere sottoposto a controllo per garantire che i clienti vengano effettivamente reindirizzati al sito Web di terzi durante la transazione.

Alla fine della giornata, devi iniziare a fidarti di qualcuno (uno sviluppatore fidato o un terzo di fiducia) che viene assunto per fare il lavoro per te. Altrimenti, devi fare tutto da solo.

Spesso lo sviluppatore non avrà accesso completo al database dei clienti.

Nella mia azienda, tutto il nostro sviluppo è fatto su database anonimi - i numeri delle carte di credito, i dettagli personali, ecc. vengono rimossi e le cose sono mescolate. I database live si trovano sulle macchine del cliente e gli sviluppatori junior / mid level semplicemente non hanno accesso in lettura su quelle tabelle.

Potremmo accedervi utilizzando le password di sistema, ma per fare ciò verremmo registrati sia recuperando il file per estrarre la password, sia accedendo dalla macchina 'sbagliata' al database.

Altri sistemi che ho visto includono la crittografia dei dettagli della carta di credito e la chiave non disponibile allo sviluppatore.

Alla fine della giornata uno sviluppatore sufficientemente determinato poteva accedere a quasi tutto, ma rendendo difficile evitare le tentazioni casuali e registrando si chiarisce che ci saranno ripercussioni.

Sono sorpreso che nessuno abbia menzionato DUKPT , ma forse è perché alcune delle principali porte di pagamento non sono mai arrivate a supportandolo, e forse non lo faranno mai ora che TripleDES è soggetto ad attacchi di forza bruta. Ma è stata una grande idea a suo tempo, e non c'è ragione per cui qualcosa di simile non possa essere fatto con la moderna crittografia. Alcuni venditori vendono ancora lettori di schede con DUKPT o qualcosa del genere, e ci sono alcuni piccoli processori che supportano la crittografia e fungono da proxy per quelli più grandi.

Non posso aggiungere nulla all'articolo di Wiki, e non pretendo di comprendere appieno come funziona, solo quello che fa. Ma in sostanza, l'hardware è resistente alla manomissione e ha una crittografia integrata, ed emette il PAN sia crittografato che redatto. Solo il gateway di pagamento può decrittografarlo, quindi il commerciante o lo sviluppatore del loro software non può comprometterlo per malizia o negligenza.

Oltre a tutte le risposte che spiegano come impedire agli sviluppatori di accedere a tali dati segreti, esiste anche un importante metodo indiretto: log di accesso

possono essere registrate, così come i comandi di shell, ecc. e questi registri dovrebbero essere salvati in modo tale da renderli impossibili da parte di uno sviluppatore individuale - in questo modo, anche se hanno accesso, possono essere visualizzate delle bandiere rosse sollevato - perché vogliono TUTTI i numeri delle carte di credito? in produzione? - La parte importante di questo è che lo sviluppatore utilizza le proprie credenziali per il lavoro e che non ci sono "account condivisi" che non portano a persone specifiche che possono essere ritenute responsabili delle loro azioni.