Machen SQL Daten in den Setting Sinn?

Hi Leute,

ich habe meine SQL Zugangsdaten in den Settings meiner Anwendung abgelegt und sie fü die Anwendung zugänglich gemacht. Aber macht das ganze überhaupt Sinn? Denn so wie ich das bisher hier im Forum, im MSDN und in diversen Google Beiträgen gelesen habe, kann man doch nachdem die Anwendung veröffentlicht wurde die Settings aus einer XML Datei auslesen. Also ich meine jeder.
Das wäre ja ziemlich unsicher. Da das meine erste Anwendung ist mit C# möchte ich natürlich vermeiden das diese gleich ein gefundenes Fressen wird. 🙂

Viele Grüße
c0ntr0l

Hallo c0ntr0l,

ein sicheres Speichern gibt es sowieso nicht: [FAQ] DB-Passwort/Connection-String sicher speichern, aber besser verstecken als in einer Konfigdatei kann man Zugangsdaten schon.

herbivore

Also ich speichere alle connectionstring in der xml datei das passwort allerdings verschlüsselt.

In meinen Datenbankanwendungen wird Benutzername und Passwort immer vom Benutzer eingegeben. Wenn er die Zugangsdaten kennt dann Vertraue ich ihm.

Alles andere ist unsicher...

Nachtrag:
Die gesamte Rechteverwaltung findet dann auf DBMS-Ebene statt.

Man kann vom User auch nur 1 Wort verlangen (Passwort)... dieses wird dann als Key verwendet um den Verbindungsstring zu decrypten.

Hallo Programmierhans,

das nützt aber dann nichts, wenn der User der Angreifer ist. 🙂 Und das wird in den meisten Fällen so sein.

herbivore

@herbivore

Kommt natürlich darauf an, was im Connectionstring gespeichert wird... Es sollte natürlich nur ein USER-Connectionstring sein (also dass er im extremfal nur mit SEINEN Rechten Zugriff auf die DB erhält)...

Gruss
Programmierhans

Hallo Programmierhans,

ok, dann ist es schon ein Stück besser. Aber leider ist es oft so, dass ein Benutzer eigentlich nur mit dem Programm die Daten verändern darf, das ist der Regel nur sehr viel eingeschränktere Operationen erlaubt, als es auf der Datenbank an Rechten benötigt. Wenn der Benutzer sich also direkt auf die Datenbank verbindet, hat er trotzdem noch sehr viel mehr Möglichkeiten als mit dem Programm. Immerhin kann man ihn dann eher als Übeltäter identifizieren.

herbivore

Wenn es um höchste Sicherheit geht, dann macht man z.B: Stored-Procs und nur auf diese hat der USER Rechte...

Die ganzen logischen Prüfungen gehören auf die DB und nicht in die Anwendung (ok die Anwendung darf vorprüfen ob die Bedingungen welche in der Stored-Proc sind auch erfüllt sind)...

Man soll immer dort schützen wo die schützenswerten Daten liegen (also auf der DB)... alles andere ist nur eine Pseudo-Sicherheit.

Also ohne App-Server kann man keine richtigen Schutz garantieren, es muss immer irgendwo eine Verbindung und die dazugehörigen Berechtiungsdaten geben.

Auf dem App-Server ist der Zugriff auf die App.config nicht mehr so leicht rauszubekommen, dann müsste er schon Zugriff darauf haben, was Sicherheitstechnisch äußerst bedenklich.

Liebe Grüße
LastGentleman

Original von herbivore
Aber leider ist es oft so, dass ein Benutzer eigentlich nur mit dem Programm die Daten verändern darf, das ist der Regel nur sehr viel eingeschränktere Operationen erlaubt, als es auf der Datenbank an Rechten benötigt.

Ich habe bis jetzt zwar nur mit MySQL und SQLite gearbeitet, aber ich denke doch das "grössere" Datenbanken (DB/2, Oracle...) es ermöglichen die Rechte so fein einzustellen das der User bei einer Direktverbindung zur DB die selben Rechte hat, die er auch im Programm hätte. Oder wie hier breits gesagt wurde: Nur das Ausführen von stored procedures erlauben.

Hallo tscherno,

wenn de Anwendung denn so programmiert ist, dass sie alles über stored procedures macht (inkl. des Updates und des Inserts neuer Daten), dann hast du Recht. Aber die wenigsten Anwendungen, die ich kenne, arbeiten nur mit stored procedures, sondern im mindestens auch auf Tabellen, wenn nicht sogar eher nur auf Tabellen (also select, insert, update, delete).

herbivore

Hallo herbivore,

das ist richtig, aber man kann dem Benutzer Zugriff auf einzelne Tabellen oder die Anwendung von DELETE oder SELECT auf eine bestimmten Tabelle verbieten.

Das nächste Problem ist, das er vieleicht nicht auf alle Datensätze in einer Tabelle zugreifen darf. Hier würden sich dann evtl. Views anbieten.

Oder nicht?

tscherno

Hallo tscherno,

ich glaube kaum, dass es sinnvoll ist, die Rechte so eng zu setzen, dass nur genau die SQL-Statements erlaubt sind, die die Anwendung benutzt, weil dann bei jeder Änderung der Anwendung auch die Rechte angepasst werden müssen. Das ist unpraktisch und fehleranfällig. Und selbst dann hat man immer noch das Problem, dass der Benutzer Felder in einer Weise ändern kann, die durch die Anwendung nicht erlaubt ist. Man kann also die Tabellenrechte ohnehin nie so eng setzen, dass nur die Operationen erlaubt sind, die durch die Anwendung möglich sind.

herbivore

Ich denke da muss man von Fall zu Fall einfach abwägen ob die Daten den Sicherheitsaufwand Wert sind. Bei Sachen wie Rechnungswesen oder Personalverwaltung mit z.b 2000+ Mitarbeitern würde ich die Unbequemlichkeit in Kauf nehmen.

Immer noch besser als Connectionstrings die auf Laptops oder PDAs von Ausendienstlern rumliegen. 😉

Und selbst dann hat man immer noch das Problem, dass der Benutzer Felder in einer Weise ändern kann, die durch die Anwendung nicht erlaubt ist. Man kann also die Tabellenrechte ohnehin nie so eng setzen, dass nur die Operationen erlaubt sind, die durch die Anwendung möglich sind.

Als agnostisch denkender Mensch sage ich mal das Oracle & Co sicherlich irgendwelche mir unbekannten Möglichkeiten bieten, Transaktionen auf plausibilität zu prüfen. 😁