Wie die Datenbank vor Eingriffen schützen? [Connectionstring & Zugriff]

[Threin]

Hey,

sorry aber ein besserere Titel ist mir nicht eingefallen aber das passt ja wohl, würde ich mal sagen.

Ja, wie sichert man eigentlich die Datenbank vor Fremdzugriffen? Beispielweise gibt es ja bei einigen Programmen zugriff auf große Datenbanken und dafür brauch das Programm doch die Zugangsdaten oder? Die Datenbanken sind ja auch schließlich nicht öffentlich oder? Ich meine damit wie bei dem MySQL Connector den Connection string, also diesen:

string ConnectionTestData = "SERVER=localhost;" + "UID=root;" + PASSWORD=;" +
"DATABASE=datenbank;";

aber dann sind ja auch, wenn man diese Daten im Programm hat einsehbar, also wie sichert man diese am besten?
Die Daten werden ja auch bei jeder Abfrage gebraucht, also müssen diese ja immer verfügbar sein.

Die Datenbank hat ja auch bestimmt, wie oben in dem Beispiel nicht die nativen Zugangsdaten, richtig?
kein Passwort und als User id root ist ein bisschen sehr einfach, also wie macht man das?

Danke schon einmal im voraus für/an alle Antworten(den).

Gruß

[Markus Lahr]

Hallo,

hier könnte "OAuth" die passende Zwischenkomponente sein: http://en.wikipedia.org/wiki/OAuth

[defo]

In einer Windows Domäne gegen sqlserver kann man bspw. trusted connection nutzen.
Die DB Zugriffsrechte werden dabei nicht an einen SQL User gegeben, sondern einen Domänen User, der dann bereits durch sein Windows Login authentifiziert ist.

[Wernfried]

Neben den bereits erwähnten Methoden sollte eine Applikation niemals mit dem Root-Account oder einem anderen hoch priviligiertem Account laufen, sondern nur mit einen applikations-spezifischem Account der nur die Rechte hat welche er auch wirklich benötigt.

Der Root-Account ist nur zum Administrieren da und sonst nichts!

Gruss

[Bernhard Geyer]

Wieso will man denn überhaupt (Standard) Zugriffsdaten fest im Quellcode hinterlegen?
Wieso nicht ganz normal wie man es gewohnt ist das die User sich mit den ihnen mitgeteilten Zugriffdaten anmelden lassen (oder bei MS SQL mit der WIndows-Authentifizierung)

[defo]

Wieso will man denn überhaupt (Standard) Zugriffsdaten fest im Quellcode hinterlegen?
Wieso nicht ganz normal wie man es gewohnt ist das die User sich mit den ihnen mitgeteilten Zugriffdaten anmelden lassen (oder bei MS SQL mit der WIndows-Authentifizierung)

Das will man sicher nicht, weder Standard, noch fest im Quellcode.
Wenn man dem User einen DB Account mitteilt, kann er sich ja mglw. auch auf der DB selbstständig machen. Das will man idR nicht.
Wenn die DB ordentlich gemacht ist, wäre es allerdings egal.

[Bernhard Geyer]

Das will man sicher nicht, weder Standard, noch fest im Quellcode.

Interpretierst Du jetzt hinein.

Wenn man dem User einen DB Account mitteilt, kann er sich ja mglw. auch auf der DB selbstständig machen. Das will man idR nicht.

Damit haben unsere Kunden eigentlich kein Problem. Es kommt halt immer darauf an welches Einsatzszenario (Definierter userkreis, "öffentliche DB", ...) man hat. Das ist aber vom Threadersteller nicht definiert.

Wenn die DB ordentlich gemacht ist, wäre es allerdings egal.

Definiere Ordenlich. Wann ist eine DB ordentlich gemacht?

[defo]

Ich interpretiere nichts. Du hast die Frage selbst gestellt.
Ich halte nichts davon mit einem standarduser auf die DB zu connecten, schon gar nicht, wenn das hart codiert ist.
Die Kunden haben meistens erst ein Problem, wenn irgendwas mit den Daten nicht stimmt. Dann geht es los mit "wie konnte das passieren und wer kommt da überhaupt ran"
Ordentlich ist eine DB in diesem Fall, wenn es egal ist, ob der User sich über eine Anwendung oder über einen direkten DB Zugriff anmeldet. Bedeutet, Rechte, Model, Constraints usw. sind so gemacht, dass nichts schief geht und keine Daten zu sehen oder zu ändern sind, die nicht auch über die Anwendung zu ändern /sehen sind.

[Bernhard Geyer]

Ich interpretiere nichts. Du hast die Frage selbst gestellt.

Ich glaube wir haben uns hier gegenseitig Missverstanden war ich bzw. du mit dem Standarduser meinst.

[defo]

Ich glaube wir haben uns hier gegenseitig Missverstanden war ich bzw. du mit dem Standarduser meinst.

Das kann sein, ich meine einen einzigen User Account, der generell von der Anwendung zur Verbindungserstellung benutzt wird. (Statt das Login des Users, der gerade davor sitzt abzufragen)

[Bernhard Geyer]

Das kann sein, ich meine einen einzigen User Account, der generell von der Anwendung zur Verbindungserstellung benutzt wird. (Statt das Login des Users, der gerade davor sitzt abzufragen)

Dann meinen wir schon das gleiche was gut und schlechtes Design/Inplementierung ist.

[Threin]

Also wie würde man das ganze denn dann richtig machen?
Das Programm brauch aber doch die Adresse der DB um überhaupt die Daten abzufragen oder und dafür wiederrum brauch man doch auch zumindest einen Standarduser, das am Anfang sollte auch nur als Beispiel dienen.
Heißt das, das die DB dann sozusagen öffentlich ist und man dann von einer Tabelle, in der dann die Benutzer gespeichert werden die Daten abfragt? Brauch man denn dafür einen DB User oder nicht?

Ohne diese Verbindungsdaten würde es also doch sowieso gar nicht gehen oder woher soll das Programm dann wissen, wohin die Anfrage gesendet werden soll und wie werden diese Verbindungsdaten gesichert oder wird das irgendwie ganz anders geregelt?

[defo]

Also wie würde man das ganze denn dann richtig machen?

Ich denke da gibt es keinen goldenen Weg.
Es kommt auf das Einsatzgebiet (Schutzbedarf) an, auf die Infrastruktur und die System Architektur.

Wie das bei Dir genau aussieht kann man anhand Deiner Angaben nur ahnen. Wahrscheinlich C# oder so "Fat Client" direkt gegen MS SQL Server im gleichen Netz. Eine klassische Client Server Architektur? MS SQL hab ich leider seit langer Zeit keine praxisrelevante Erfahrung mehr mit. Daher ein Beispiel wie es in einem anderen System gemacht werden kann (als Idee):
Der Anwender meldet sich mit seinem echten, eigenen DB Account an, der aber minder privilegiert ist. Die Anmeldung (Session) wird serverseitig überwacht und auf bestimmte Parameter hin mit einer höher privilegierten Rolle erweitert (on the fly). Die Rolle selber ist PW geschützt und das PW kennt nur der Server.

allgemein (Client Server Szenario oben):
1. eine Anwendung sollte auf keinen Fall im Connection String ein (unverschlüsseltes) Pw speichern.
2. Eine Anwendung sollte es erstmal erlauben, zumindest die DB selbst auszuwählen.
3. Es sollte kein Standardzugriff erlaubt sein, verwendet werden
4. Ein echter / normaler Zugriff über einen privilegierten DB User ist je nach Szenario akzeptabel.
5. zu 4 gibt es diverse Ausnahmen, Randbedingungen.
6. eine Trusted Connection als Windows Domänen User ist für solche Fälle vollkommen legitim und praktikabel, dafür ist sie ja gedacht.

1 ist wohl klar.
2 ist praktisch, flexibel, erlaubt die Anmeldung an Testsystem oder Ausweichsystemen.
In der Praxis gibt es eine Fülle von Möglichkeiten, das umzusetzen, dass es nicht gleich wie ein offen stehendes Fenster im Sommerurlaub wirkt. Default Verhalten ist so angelegt, dass der Benutzer damit nichts am Hut hat. Alles andere kann per Registry, Command Line Parameter geändert werden oder zur interaktiven Änderung freigeschaltet werden.
3. Ich kannte mal eine Firma, die seit Jahren nicht Ihr DB System PW ändern konnte, weil sie Angst hatten, dass dann eine Reihe von System nicht mehr funktionieren. Ich weiß nicht, ob sie das jemals versucht haben. Wäre für mich als Verantwortlicher purer Horror.
(Neulich habe ich allerdings gelernt, dass es für die neueren Fahrzeuge großer Autohersteller auch Zentralschlüssel gibt, naja...)
4. Wie Bernhard Geyer schon schrieb, es ist erstmal ok so, denn so ist es gedacht. Problematisch wird es, wenn das System normale Anwender mit DB Admin oder App Owner Rechten ausstattet und Missbrauch oder Fehlbedienung (mangelhaftes Datenmodell > Inkonsistenzen) Tür und Tor geöffnet sind. Eigentlich gehört es ja zu den Hausaufgaben von Entwicklern und Administratoren, sowas zu vermeiden, aber Zeit und Kostendruck und Bequemlichkeit...
5. Enthält das DB System allerdings sensible Daten dritter, unverschlüsselt (anderes denkbar), kommt das an seine Grenzen. ...
Missbrauch durch 3. sollte ebenfalls auszuschließen sein(bekannte Logindaten- wg Urlaubsvertretung, ungesperrte Arbeitsplatzrechner ,..)
6. Hiermit ist im wesentlichen das Password Handling für Entwickler und Anwender erledigt. Wie auch bei 4 geht man davon aus, dass es sich um einen wohlwollenden User handelt. Ist bei einem Fileserver nicht anders.

Evtl. sind geeignete Audit Maßnahmen zu installieren, die bei Missbrauch greifen bzw helfen. An der Stelle wird vielleicht noch mal deutlich, wie sich das mit den DB Accounts verhält. Ein Audit System das immer nur auf "root" sessions stößt beim Logging, bietet natürlich weniger Anhaltspunkte, als eines, dass "echte Logins" findet.

[Threin]

Naja, das es meist mehrere Wege oder dergleichen gibt ist mir mittlerweile klar.

Ich arbeite mit C# und dem MySQL-Connector aber das ganze war auch eher allgemein gemeint, nicht "nur" mit CSharp.
Aber es ist schon ganz richtig, das es sich um eine Client-Server Architektur handelt mit MySQL.

Noch einmal ein paar Fragen zu deiner sehr ausführlichen Antwort (danke ):
1. Heißt das, das jeder Anwender auch einen eigenen "echten" DB-Account kriegt oder würde das dann über einen laufen?
Was aber dann auch, wenn es sich wirklich um einige hundert handelt, das der Anwender dann, evtl. wenn er das Produkt kauft sich auch irgendwie registrieren muss oder so ist ja dann auch klar aber wird dann ein echter DB Account erstellt?
2. Was mir immer noch nicht ganz klar ist, ist die Sache mit der Verbindung zur DB, also diesen Verbindungsdaten. Die müssen doch aber im Programm hinterlegt sein oder nicht, es ist ja egal, ob der Anwender die Datenbank auswählen kann oder nicht? Die Adresse kann sich ja ruhig ändern oder meinst du auch, das der Benutzer wirklich die Adresse des Servers & Co. eingeben kann?
Wie würde man denn dann die Verbindungsdaten sicher im Programm speichern, denn das Programm brauch diese ja???

Ich würde sowas gerne auch mal richtig machen, hast du da evtl. auch noch ein paar nützliche Links?, vor allem mit dieser Verbindungsdaten Geschichte?

[defo]

auf die Schnelle:
Bei mySQL ist mir nicht bekannt, dass es eine "trusted connection" Möglichkeit gibt, wie bei mssql, kenn ich mich aber nicht so aus.
Egal, Verbindungsdaten brauchst Du auch. Allgemein: Es gibt je DB System verschiedene Verbindungs-Verfahren, die meisten enthalten in irgendeiner Form die Serveradresse/Name, Port, DB und zuletzt natürlich User/pw (außer bei Trusted Connection z.B.) Einige Systeme erlauben über die Treiberschicht auch ein Alias Verfahren zu nutzen. Hier wird dann nicht mit Servernamen/-Adressen gearbeitet, sondern eben einem Alias, der die eigentlichen Parameter via Zwischenschicht alles bereithält und austauschbar macht.
Wenn es also doch nicht ganz so allgemein sein soll, schau Dir mal die Connectivity Optionen von mySQL an. Ansonsten auch von weiteren DB Systemen.

Architektur: Da kam jetzt überraschend von Dir das Stichwort Kaufen ins Spiel.
Das ist was ganz anderes, weil es eine ganz andere Umgebung als angenommen betrifft.
Genauer: Eher kein klassischer Fall von Client / Server. Außer, die Kaufsoftwäre (Deine) verbindet sich zu einer zuvor installierten lokalen oder LAN DB.
100e User: Auch das spricht eher nicht für ein einfaches C/S System. Da kommen Lastspitzen usw. ins Spiel, Loadbalancing, .. eher eine Mehrschicht Architektur.
Hier fehlt noch Information.

Was die Speicherung der Verbindungsdaten angeht, Deiner Phantasie sind keine Grenzen gesetzt. Allerdings nicht unbedingt im Sinne von Obfuscation.
Du kannst Dir z.B. eine Anmeldeschicht bauen, die eine eigene Nutzerverwaltung beinhaltet und nach erfolgreicher Anmeldung die eigentlichen Verbindungsdaten mit echten DB Connections an den User / die Anwendung ausliefert. Damit schaffst Du Dir ein paar Freiheitsgrade. Welche und wie viele Verbindungen und wohin das dann geht, sollte man abhängig von Last und und und machen. Serverausfall usw. kann man dann einfacher abfedern.
Ein System mit Client "in der freien Wildbahn" direkt gegen einen irgendwo gehosteten DB Server oder so- wie es bei Dir grad klingt- würde ich eher nicht schaffen (Stichwort Mehrschichtarchitektur). Die Variante C/S so wie Du es schilderst scheint mir da etwas schräg.
Das Ganze kann man beliebig aufwendig machen, mit VPN, Tokens, SSH und bekannten Authentifizierungsverfahren, abhängig vom Anwendungsfall.