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.