Det giver mening at beskytte databasen med adgangskode, hvis du sikrer dig adgang til programmets konfigurationsfil, der indeholder almindelig tekst. Når du kun begrænser læseadgang til applikationens konto, kræver angriberen rodadgang for at se adgangskoden. Hvis han overtrådte en anden (mindre privilegeret) konto, kan han ikke få adgang til databasen.

Det er en slags løg beskyttelse (også kendt som " Layered Security " eller " Defense in Depth " som f.eks. set , i SANS 'whitepaper " Layered Security: Why It Works". Hvis en hacker kan nå maskinen (e), kan han ikke få fuld databaseadgang. Applikationen skal have en begrænset adgang begrænset til kun de krævede tabeller, og alt, hvad der ikke behøver at blive skrevet, skal være skrivebeskyttet. Enhver højere adgang skal kræve en anden adgangskode, der aldrig bruges i applikationen.

Fordelen er, at en hacker, der har netværksadgang til databasen, men ikke filsystemadgang til serveren, ikke er i stand til faktisk at logge ind i databasen.

Om dette giver ekstra sikkerhed, afhænger af dit trusselsscenarie og dine sikkerhedsmål. Jeg kender mindst to situationer, hvor det tilføjer sikkerhed:

• Det giver dig mulighed for at finere kontrol af legitim adgang til databasen: Der kan være mennesker, der legitimt har brug for adgang til databasen, men ikke til dataene inde, såsom DB-administratorer, der udfører vedligeholdelse. En krypteret database kan (afhængigt af opsætning) tillade tildeling af DB-adgang, mens data stadig holdes hemmelig.
  På samme måde giver kryptering af en del af databasen (f.eks. Kun kolonner med adgangskoder) begrænset adgang (f.eks. til fejlfindingsproblemer, til rapportering eller til et datalager ), mens kritisk information beskyttes.
• Det kan beskytte sikkerhedskopier af databasen. Hvis databasen er sikkerhedskopieret på filniveau eller med et sikkerhedskopieringsværktøj, der understøtter krypterede databaser, krypteres sikkerhedskopien. Dette er nyttigt, fordi sikkerhedskopier kan være en kilde til databrud, da de ofte ikke er sikret såvel som de servere, de blev taget fra (se for eksempel Dårlig sikkerhedskopiering af sikkerhed fører til Ameriprise-klientdatalækage).

Fordele ved adgangskodebeskyttelse af DB

• Hvis det ikke er muligt at bruge det usikkert, reducerer det risikoen for, at hvis DB og serveren skal deles på et senere tidspunkt, vil blive efterladt på en usikker måde, hvilket fører til fremtidige udnyttelser.

• Hvis en angriber kan bryde maskinen med en begrænset konto, kan de muligvis oprette forbindelse til lokale tjenester, men ikke nulstil databaseadgangskoden at kræve, at angriberen godkender, begrænser den skade, de kan gøre.

• Hvis et angreb kan bruges til at reflektere / videresende trafik, kan en fjern modstander synes at være på den lokale maskine et eksempel ville være en proxy, der kan overbevises om at indlæse en DB API eller en tjeneste, der viser modtagne data, når en forbindelse mislykkes til en given URL)

• Hvis der bruges adgangskoder så kan forskellige systemer og brugere forhindres i at bruge hinandens konti, ellers kan en angriber fra ethvert system foregive at være et hvilket som helst andet system.

Hvis du ikke har store skaleringsproblemer i din fremtid, tilføjer det muligvis ikke nogen sikkerhed for at have en adgangskode , men vær opmærksom på, at "ikke at have en adgangskode " er ikke den samme ", der stoler på nogen, der hævder at være din applikation. "

Hvis din applikation kører som sin egen bruger på serveren *, i nogle databaser kan du muligvis bruge tredjepartsgodkendelse (f.eks. hvad Postgres kalder peer -godkendelse), som giver serveren mulighed for at bruge netværks- eller operativsystemmekanismer til at bestemme, hvilke brugere der er, de siger, de er. For eksempel, under den rette konfiguration, kunne shell-bruger "bob" få adgang til databasekontoen "bob" uden at give en adgangskode. At have tingene enkle kan gøre det lettere at beskytte din database og applikation.

Når det er sagt, som jrtapsell s svar antyder, skal du muligvis flytte dit applikation til en anden server af omkostnings- eller ydeevneårsager. I så fald har du sandsynligvis brug for en gemt adgangskode eller anden hemmelighed som en privat nøgle, selvom der er nogle metoder primært inden for private netværk, der kan bruges til at undgå dette.

Hvis du synes, der er en anstændig chance for, at du har brug for en adgangskode (eller anden gemt hemmelighed) i fremtiden, så skal du bare lave ordningerne nu, så de ikke bliver lavet usikkert senere af nogen med kortere tid eller oplevelse.

_{* Ideelt set skal denne konto være stærkt adgangskode eller kun tilgængelig for at logge ind via sudo eller tilsvarende mekanisme}

Kender du alle de databrud, der skete for nylig? Dem, hvor folk fandt sikkerhedskopier af databaser uden kodeord i usikrede Amazon S3-spande? Yeah.

Antag aldrig , at din database kun nogensinde vil leve på din sikre server bag tyve milliarder firewalls. Det mindre besvær med en adgangskode på din DB er en lille pris at betale for den i det væsentlige gratis sikkerhed, den giver.

Som et supplement til Serge Ballestas svar.

Dette bliver især vanskeligt, hvis du bruger en NoSQL-database, f.eks. MongoDB, som standard vil enhver databasebruger have skrivebeskyttet privilegier for alle databaser, og det kommer ikke engang konfigureret til at have en db-bruger ud af boksen . Der er ganske få svagheder som angivet af Spider Labs Blog for nogen tid siden (omkring 2013), men anbefalingerne følges normalt ikke engang for store virksomheder, f.eks. MacKeeper hændelse (sidst i 2015).

I begge referencer finder du en liste over de mest almindelige sårbarheder. Hvis du hellere vil læse 'officielle' retningslinjer, kan du finde dem her, de skal være analoge for SQL-databaser. Jeg kan dog godt lide at tro, at der ikke er nogen overkillelser, når emnet er sikkerhed.