Prevenzione dell'accesso al database MySQL

2

Sto facendo un sito Web PHP per un cliente che si occupa di informazioni finanziarie di terze parti, ed è preoccupato che gli sviluppatori (io) abbiano accesso a tutte le informazioni, il che è ovviamente un problema valido.

Attualmente sto ospitando su un ambiente di hosting condiviso, tuttavia, ho intenzione di raccomandare un server dedicato per questo sito.

Posso compilare tutti i tipi di registrazione nel codice sorgente del sito e avere il codice controllato prima dell'avvio del sito, in modo da evitare che le back-door nel codice possano perdere informazioni. Sono, tuttavia, preoccupato su come impedire l'accesso a phpMyadmin o ad altri strumenti amministrativi per accedere direttamente al database.

Dove dovrei iniziare a togliermi questa preoccupazione? Qualsiasi consiglio sarà apprezzato.

Grazie in anticipo!

    
posta Kobus Myburgh 27.03.2013 - 09:58
fonte

3 risposte

0

PCI-DSS è lo standard di settore applicato alla maggior parte dei siti Web commerciali che si occupano di transazioni finanziarie, pertanto dovresti essere in grado di trovare i protocolli esatti che PCI DSS richiede nella loro documentazione e in grado di basare il tuo sistema.

Pur comprendendo la loro preoccupazione per lo sviluppatore che ha accesso ai dati finanziari, la fiducia è un problema chiave qui. Affidarsi che i dati finanziari dovrebbero essere crittografati abbastanza da garantire che, in caso di discarica diretta del database, non vengano trapelati dati finanziari in formato testo. Ciò richiederà il codice sorgente dell'applicazione (contenente le politiche chiave, ecc.) O l'applicazione stessa per essere compromessa.

Come per prevenire phpMyAdmin e altri strumenti dall'accesso diretto al database, puoi semplicemente modificare la radice MySQL e altre password tramite la riga di comando su MySQL. Questo è un modo approssimativo, ma lascerà phpMyAdmin in grado di sincronizzarsi con MySQL. La modifica della porta predefinita di MySQL è anche un'alternativa secondaria su un server dedicato.

Un approccio più testato, tuttavia, è implementato da sistemi come SAP mentre impedisce ai programmatori di accedere direttamente al database per prevenire danni all'integrità dei dati memorizzati. Lo fanno limitando le applicazioni a un singolo accesso utente del database, la cui password è solo con l'applicazione. Se un altro utente del database tenta di accedere ai dati memorizzati, il tentativo viene registrato e segnalato, in genere causando l'annullamento della garanzia.

    
risposta data 27.03.2013 - 13:23
fonte
3

C'è un numero di controlli che puoi mettere in atto qui per dare al cliente un po 'di conforto sulla sicurezza dei propri dati. Alcuni di questi potrebbero essere eccessivi a seconda del cliente ma comunque idee

  • Assicurarsi che tutte le password di sistema (ad es. account OS, MySQL) siano impostate dal cliente per il sistema di produzione
  • Supponendo che questo sistema sarà presso un provider di hosting invece che sul sito del cliente, si potrebbe osservare l'impostazione delle regole del firewall a livello di sistema operativo e i file .htaccess a livello di server Web per limitare dove è possibile effettuare le connessioni da per gli strumenti di amministrazione (es. SSH, phpmyadmin). Ciò richiederebbe al cliente di avere un indirizzo IP fisso che potrebbe essere utilizzato a tale scopo.
  • Processo di modifica documentato. Un rischio in questo caso sarebbe che un aggiornamento del codice aggiungesse qualcosa di brutto, quindi se vogliono un'assicurazione continua, è necessario disporre di un processo di distribuzione definito in cui ogni release viene messo in produzione dal cliente (presupponendo che solo loro abbiano accesso)
  • Registrazione e monitoraggio. A livello di sistema operativo è possibile registrare tutte le attività maggiori informazioni

Tutto ciò ovviamente dipende dall'idea che il cliente abbia le conoscenze e le risorse per gestire il servizio. Se non lo fanno e hai ancora accesso come amministratore, in realtà è una situazione di fiducia come se avessi accesso root alla casella o al database puoi prendere copie dei dati.

    
risposta data 27.03.2013 - 10:14
fonte
0

Il tuo caso se ho letto bene è un classico che si occupa dei diritti e dei permessi per il codice che viene eseguito in produzione.

innanzitutto perché uno sviluppatore principale della sicurezza non deve in alcun modo avere accesso al codice in esecuzione in produzione. È qui che entra in gioco cincept of libirarian. Tutto il codice dopo i test passa alla versione standard libirary e poi si sposta da lì.

Seconda volta, puoi lasciare che il tuo team tecnico del cliente sia in grado di gestire chi fa la manutenzione di routine.

In terzo luogo, a seconda della sensibilità e della classificazione dei dati che devi dimostrare o dare la necessaria garanzia del tuo sistema, controlli l'efficacia nel bloccare accessi autorizzati. Il controllo dell'accesso dovrebbe essere guidato dai requisiti del cliente.

La registrazione è un controllo detective necessario per iniziare a pensare secondo le linee di sicurezza perventiva.

    
risposta data 27.03.2013 - 15:22
fonte

Leggi altre domande sui tag