Quando devo implementare l'autenticazione in un database?

1

Attualmente mi sto imbarcando in un progetto MongoDB (un semplice sistema di accesso utente) e noto che esiste un'opzione per l'autenticazione. Ecco la stringa del server, con userinfo mostrato come informazione opzionale.

mongodb://[username:password@]host1[:port1][,host2[:port2:],...]/db

Dal Manuale MongoDB :

Before gaining access to a system all clients should identify themselves to MongoDB. This ensures that no client can access the data stored in MongoDB without being explicitly allowed.

Perché dovrei scegliere di utilizzare questa funzione? Non dovrebbe spettare ai programmatori di server (ad esempio quelli che implementano PHP, Python o qualsiasi altra cosa) per autenticare l'utente per determinare quali informazioni visualizzare?

    
posta Marcus McLean 01.10.2014 - 22:41
fonte

2 risposte

2

Utilizzerai questa funzione per accedere al database. Il tuo programma (indipendentemente dal fatto che venga eseguito sul server o sul client) dovrà identificarsi e autenticarsi da solo - sia sul database (MongoDB) stesso, sia su un servizio proxy.

In entrambi i casi, per farlo è necessario almeno un ID utente e una password. Le chiavi crittografiche o i token fidati sono persino più potenti, più sicure nell'identificare e autenticare le credenziali. Ma questo è un altro livello per dopo.)

Quindi, se il tuo sistema di login utente "semplice" vuole / ha bisogno di contattare direttamente il DBMS, dovrà costruire qualcosa di simile al modello di URL che hai pubblicato. (Questo vale anche per altri database come MySQL.)

Se non fornisci credenziali come questa, il DBMS non riconoscerà il tuo programma come uno che può legittimamente accedere ai dati e non permetterà al tuo programma di "entrare". (Nota, questo è separato dal processo di login dell'utente, che si basa presumibilmente sui dati in MongoDB per navigare.)

Come sottolinea @Matthew, i tuoi account / credenziali utente DBMS devono essere tenuti separati dagli account utente / credenziali che stai gestendo.

Un'ultima nota importante: Non ci sono semplici sistemi di accesso utente. Piccoli problemi come le esposizioni alla sicurezza li rendono piuttosto complicati e difficili da ottenere. Quando sono semplici, di solito sono dolorosamente insicuri - soggetti a spoofing, intercettazioni telefoniche e altri exploit. Puoi farla franca su una rete locale, privata con bassa probabilità che altri vogliano attaccare il tuo sistema. Ma se è su Internet più ampia, o protegge qualcosa di valore, la protezione della sicurezza è essenziale . C'è una probabilità del 99,999999999% che non lo si otterrà con una "semplice" soluzione homegrown; soprattutto non la prima volta fuori dal fienile.

    
risposta data 01.10.2014 - 23:14
fonte
3

Il motivo tecnico principale è che la maggior parte dei database richiede l'autenticazione per capire a quale "schema" o "applicazione" ci si sta collegando. Altrimenti, non sa chi sei.

Il principale motivo di sicurezza è che le connessioni dalla rete locale non dovrebbero essere considerate attendibili. Se un altro nodo sulla tua rete è compromesso (un PC, un server, un ospite wifi, l'amministratore sys adolescente nella stanza sul retro che scarica warez), allora lo è anche il tuo database non autenticato. Ovviamente il database e il server delle app dovrebbero risiedere dietro un firewall in ogni caso.

È possibile limitare le connessioni a localhost (stesso computer), ma in molte architetture, il codice dell'app viene eseguito su un nodo diverso dal database. Se la tua app è in co-residenza con il tuo DB e hai un singolo DB dedicato per la tua app, allora puoi farla franca.

Con database che supportano schemi / account multipli, gli utenti sono spesso dedicati a applicazioni uniche. MongoDB lo incoraggia. Ciò garantisce che più applicazioni possano condividere in sicurezza un'unica infrastruttura di database. Ospito spesso più applicazioni Web con un singolo database fisico. App1 non dovrebbe essere in grado di connettersi liberamente all'archivio dati di App2.

Infine, per motivi di controllo / conformità, gli utenti devono autenticarsi per identificare chi ha fatto cosa, retroattivamente. Se sei in un'azienda coperta da controlli normativi, HIPAA, SOX, ecc. È necessario un accurato controllo. Gli utenti generici o condivisi non sono conformi.

Per quanto riguarda chi è responsabile? È responsabilità di ogni programmatore, ma in particolare il programmatore dell'app e l'amministratore del database. Spesso quelli sono la stessa cosa.

Forse alcuni di questi non si applicano alla tua app, ma è comunque una buona pratica.

    
risposta data 01.10.2014 - 23:45
fonte

Leggi altre domande sui tag