Dove memorizzo in modo sicuro la chiave per un sistema in cui la sorgente è visibile?

How can I provide decent security on this one to prevent someone grabbing the database (by local access - this machine is NOT Internet connected) ?

C'è molto che puoi fare, ma la maggior parte non è direttamente programmazione di database. Poiché la maggior parte di questo non è la programmazione, potrebbe essere fuori portata per te. Non so cosa sei stato assunto per fare o quale sia il tuo background. Se questo è fuori dal campo di applicazione o non ti senti comodi nell'implementarlo, allora fai sapere al tuo cliente quali sono i tuoi problemi di sicurezza e consiglia di assumere uno specalista.

• Hash i numeri delle carte di credito.

Dipende dallo scopo dei numeri memorizzati delle carte di credito. Se il numero viene utilizzato solo per identificare univocamente un cliente o un acquisto, in realtà non è necessario il numero della carta di credito, solo un valore che mappa in modo inequivocabile il numero della carta di credito. Se questo è il caso, sostituisce il numero della carta di credito con un hash del numero della carta di credito. Alcuni algoritmi di hash: SHA1, MD5, RIPEMD-128/256.

• Elimina il numero della carta di credito.

Se a un certo punto il numero della carta di credito non è più necessario, ma il resto dei dati nella riga è, deselezionare il campo della carta di credito. Se è necessario conservare alcune indicazioni della carta, ma non per la ricarica, mantenere le ultime quattro cifre.

• Spezza il database in pezzi.

Se non hai bisogno di accedere all'intera cosa allo stesso tempo, spezza il database in pezzi a cui devi accedere allo stesso tempo. Se le voci sono indipendenti, suddividili in pezzi di dimensioni uguali. Questo limiterà il danno se un pezzo viene perso o rubato. Prova a caricare pochi pezzi alla volta come è ragionevole. Se la tua applicazione ha solo pochi pezzi accessibili alla volta, questo rallenterà un utente non autorizzato.

• Salva le chiavi dalla macchina.

Ci sono alcuni modi per farlo. Un metodo sta usando un token crittografico. Esistono dispositivi USB, dispositivi smart card e token software. I token software possono essere memorizzati su qualsiasi supporto rimovibile (CD-ROM, DVD, unità USB flah, ecc.). Se rompi il tuo database in pezzi, potresti prendere in considerazione l'utilizzo di chiavi diverse per alcuni pezzi, specialmente se alcuni vengono usati meno frequentemente di altri.

• "Sali" la tua chiave

Un salt è un numero casuale in genere utilizzato con voci di password con hash per rendere difficile per un utente malintenzionato che accede a un database di password per trovare rapidamente tutte le password nel database. PBKDF2 è un algoritmo crittografico che utilizza una password salt e una password per generare una chiave. Generare un salt (numero casuale) per ogni riga e memorizzare il sale in testo in chiaro nella riga. Utilizzare PBKDF2 o un altro algoritmo di generazione della chiave adatto per generare una chiave per la riga e crittografare i dati della carta di credito utilizzando la chiave generata. Lo scopo è di fare in modo che l'utente malintenzionato legga il database e generi una nuova chiave per decrittografare ogni numero di carta di credito.

• Limita l'accesso alla rete al sistema.

Dici che la macchina non è collegata a Internet, ma sospetto che sia ancora su una rete interna. Utilizzare il firewall sul sistema per riattivare l'accesso alla rete a due o tre altri sistemi. Se il sistema deve connettersi a più di due o tre altri sistemi, potrebbe essere necessario pensare a spostare il database su un sistema diverso o creare un sistema dedicato per il database.

• Limita l'accesso degli utenti al sistema.

Configurare la politica di sicurezza per consentire solo a pochi utenti critici di accedere alla macchina. Se più di otto persone hanno bisogno di accedere alla macchina, di nuovo dovrebbe essere un segnale che il database dovrebbe essere spostato su un altro sistema o sul proprio sistema dedicato. Il mio rapido però su otto utenti: Amministratore di sistema, Amministratore di sistema alternativo, Amministratore di sicurezza, Amministratore di sicurezza alternativo, Amministratore di database, Amministratore di database alternativo, Sviluppatore di applicazioni, Sviluppatore di applicazioni alternativo.

• Limita l'accesso fisico al sistema.

Questa è solo la vecchia porta chiusa. Se è necessario trovarsi in un'area condivisa con altri sistemi, provare a renderli sistemi che consentano l'accesso agli stessi utenti. Se tutto ciò che è disponibile è un armadio o un armadietto, assicurati solo che abbia una chiave univoca. Un sacco di serrature per ufficio e mobili comuni condividono chiavi comuni.

• Limita gli utenti che hanno accesso fisico al sistema.

Solo perché hanno bisogno di accedere alla macchina non significa che abbiano bisogno di un accesso fisico al sistema. Scegli chi dare le chiavi e chiedi loro di non fare copie o prestarle a nessun altro.

Per essere onesti direi che se stai facendo funzionare il sistema come un database di accesso, presumibilmente con il front-end sullo stesso sistema, c'è solo una quantità limitata che puoi fare per proteggere i dati, come l'attaccante determinato sarebbe in grado di ottenere l'accesso alla chiave di crittografia (ad esempio, leggendolo dalla memoria quando viene utilizzato).

Detto questo potresti essere in grado di fare alcune cose per alzare un po 'la barra. Da quello che ho visto, un'opzione per la memorizzazione dei segreti su una macchina Windows locale è quella di inserirli nel registro e ACL proteggere la chiave di registro. Ciò potrebbe fornire una certa protezione nell'eventualità che qualcuno acceda al sistema abbastanza a lungo da afferrare il file .mdb ma non abbastanza a lungo per cercare esaustivamente la macchina per la chiave.

Un'altra protezione valida in questo scenario, potrebbe essere quella di implementare la crittografia del disco intero sul sistema stesso. Ciò contribuirebbe a fornire protezione in uno scenario in cui l'intero dispositivo viene rubato (presumendo che si tratti di una macchina desktop che verrebbe probabilmente spenta quando viene rubata).

Ecco alcuni passaggi da prendere in considerazione che potrebbero aiutare a mitigare alcuni rischi:

• Metti il database su una macchina separata. Quella macchina separata dovrebbe essere bloccata, in modo che esegua solo i servizi necessari per supportare un database. È possibile stabilire un firewall, quindi accetta solo connessioni in entrata dal server Web front-end.

  Un'altra opzione è eseguire il server Web front-end in una macchina virtuale ed eseguire il database in una macchina virtuale separata.

• Configura il database per bloccarlo e ridurre alcuni rischi per la sicurezza (ad esempio, configuralo in modo che le stored procedure e le query SQL non possano generare comandi di shell). Non so fino a che punto questo sia applicabile ad Access o quali configurazioni siano consigliate per Access, ma questo è un buon passaggio per alcuni database commerciali.

• A seconda della progettazione e delle esigenze dell'applicazione Web, è possibile che sia necessario solo scrivere numeri di carta di credito nel database e non leggerli. In tal caso, potrebbe essere possibile configurare il database per applicare questa restrizione, utilizzando controlli di accesso a grana fine o utilizzando controlli di accesso a grana grossa e stored procedure (utilizzare il controllo di accesso a livello di tabella o utente per impedire l'applicazione Web dall'accesso diretto ai numeri delle carte di credito, quindi creare una procedura memorizzata che ha la possibilità di scrivere un nuovo numero di carta di credito, dare l'autorizzazione dell'applicazione Web per richiamare la procedura memorizzata e convertire l'applicazione Web in modo che ogni istruzione SQL che tocchi le carte di credito viene convertito per utilizzare questa stored procedure). Tuttavia, è improbabile che questo sia un cambiamento banale nell'applicazione web; questo è nella categoria a più alto rischio e costo più elevato.

• Controlla il codice del cliente per assicurarti che utilizzi le istruzioni preparate (o l'equivalente), anziché la concatenazione delle stringhe, per creare query SQL. Se si utilizza la concatenazione di stringhe, prendere in considerazione la conversione per utilizzare istruzioni preparate. La concatenazione di stringhe comporta rischi significativi di vulnerabilità di SQL injection e rappresenta una pratica di codifica non ottimale.

• Come suggerisce @Rory, puoi prendere in considerazione l'utilizzo della crittografia a disco intero per il server che ospita il database. Tuttavia, questo può avere solo un valore modesto, perché si ritorna all'enigma di "dove memorizzo la passphrase segreta?". Puoi fare in modo che un operatore di server digiti la passphrase FDE all'avvio, ma se si verifica un'interruzione dell'alimentazione o il server si riavvia, il tuo sito non è attivo finché un operatore del server non si presenta personalmente di persona per digitare la passphrase FDE .

• Si potrebbe considerare la conformità PCI-DSS come una misura di attenuazione del rischio. Tuttavia, questo potrebbe essere più costoso di quello per cui il cliente è preparato.

Entro le tue restrizioni, probabilmente non sarai in grado di affrontare completamente il rischio che l'intero database delle carte di credito venga rubato. Nella migliore delle ipotesi è possibile mitigare parzialmente alcuni dei rischi più probabili.

Non farlo.

Seleziona un fornitore di servizi di pagamento, ad es. Stripe.com o Pay-pal, che gestiranno la ri-fatturazione degli abbonati per te.

pro:   Non devi sudare i dettagli della protezione del database o pagare qualcuno per farlo.

con:   Se possiedi già un account / gateway commerciante, potresti MAGGIORARE a pagare un po 'di più. Tuttavia, è probabile che qualsiasi spesa aggiuntiva ti costerà molto meno della responsabilità di una violazione dei dati, o della commissione del consulente per la sicurezza, o anche dei costi operativi del server extra suggerito da D.W.

Il fatto che la vostra azienda / cliente insista nell'utilizzare MS Access per questo suggerisce strongmente che non sono qualificati per prendere decisioni sulla sicurezza IT. Seriamente, non farlo.