SQL Datenbankdesign

[ascer]

Hallo Community,


nehmen wir mal an, es wird eine Webapplikation entwickelt, in der die Nutzer keinerlei Möglichkeit haben, in irgend einer Art und Weise direkt auf den Datenbankserver zuzugreifen.

Nehmen wir nun an, n Benutzer aus m verschiedenen Unternehmen nutzen die Webapplikation.

Wäre es sicherheitstechnisch gesehen dann noch relevant, sowas wie Benutzerkonten jeweils in einer eigenen DB für jedes Unternehmen (mit unterschiedlichen Zugängen natürlich) zu speichern?

Oder reicht es vollkommen, da die User eh keinen Datenbankzugriff haben, eine DB einzurichten und für Benutzerkonten & Co jeweils die Daten nur in eine Tabelle zu schreiben, in der dann unzählige Benutzer verschiedenster Unternehmen gelistet sind und per zusätzlichem Key die User jeweils ihrem Unternehmen zuzordnen?


Grüße & Danke

ascer

 

[hroessler]

Wenn die Benutzer keinen Zugriff auf die Datenbank haben, wie sollen diese dann darauf zugreifen. Du musst den Benutzern schon Zugriffsrechte auf die Datenbank gewähren. Oder habe ich da was falsch verstanden?

Greetz
hroessler

 

[ascer]

Keinen direkten Zugriff.
D.h. in der Front-End Applikation authentifiziert sich Benutzer XYZ, dass Backend auf dem Server antwortet & erstellt eine entsprechende Session. Fragt der Nutzer nun Daten an, z.B. durch Klick auf einen Link, wird der entsprechende http-request per AJAX zum Server geschickt, der übprüft, ob Benutzer XYZ Zugang zu den Daten erhalten darf und antwortet entsprechend.

Damit hat der Nutzer keinerlei direkten Zugriff auf PHP oder Python Skripte sowie die Datenbank.

Die Frage die sich mir stellt ist aber nun: Macht es sicherheitsmäßig dann noch irgend einen Unterschied, ob in der Applikation z.B. alle Logindaten jeweils in einziger "users"-Tabelle in einer DB gespeichert sind oder sollte trotzdem noch für jedes Unternehmen eine eigene DB mit jeweils eigener "users"-Tabelle (und weiteren Daten) angelegt werden?

 

[New_Escaflowne]

@hroessler
Die Nutzer können wohl indirekt über die WebApp auf die DB zugreifen, d.h. die WebApp nutzen, die selbst die DB braucht.

Aus Datenbankdesign würde ich eine Tabelle empfehlen.
Ich wüsste auch nicht, was mehrere Tabellen bringen sollen. Ein Benutzerkonto besteht doch sowieso nur aus Username + (gehashtem) Password. Wieso m Tabellen, mit der gleichen Struktur? Das würde Abfragen nur komplexer machen. Wenn sowieso angenommen ist, dass die User keinen Zugriff haben (und wir Angriffe außer Acht lassen), hat nur der Anbieter auf die Daten Zugriff. Der hat aber auf alle Daten Zugriff, so dass eine oder m Tabellen keinen Unterschied in der Sicherheit macht.

 

[Miuwa]

in der die Nutzer keinerlei Möglichkeit haben, in irgend einer Art und Weise direkt auf den Datenbankserver zuzugreifen.

Ich glaube das ist eine gefährliche Annahme. Bugs und Sicherheitslücken gibts in jedem Programm.

Wie groß der Gewinn oder Verlust an Sicherheit durch getrennte Datenbanken ist lässt sich so pauschal kaum beantworten und hängt natürlich auch davon ab, wie die DBs genau gesichert sind. Sofern dein System genug separate DBs handeln kann und die Programmlogik die Einträge sowiso unabhängig behandelt würde ich aber keine gemeinsame DB nutzen.

 

[hroessler]

Hallo,
danke für deine Erläuterung.

Aus meiner Sicht ist es OK ist, wenn die Konten in einer einzelnen Tabelle zu halten. Das hält deine Applikation zudem einfacher.

Viel wichtiger für die Sicherheit ist meiner Ansicht nach, wie du die Daten abspeicherst. So solltest du z.B. Passwörter nicht im Klartext, sondern nur als gesalzenen Hash ablegen.

Eine andere Überlegung wäre noch die Länge und Güte der Passwörter (Gesamtanzahl der Zeichen, Anzahl der Zahlen, der Sonderzeichen, sowie vorhandene Groß- und Kleinschreibung etc.).

Greetz
​hroessler

 

[Miuwa]

@New_Escaflowne: Ich denke es geht nicht um getrennte Tabellen, sondern Datenbanken

 

[ascer]

Naja, man könnte ja theoretisch gesehen eben für jedes Unternehmen eine eigene Datenbank erstellen mit jeweils eigenem User, sodass falls tatsächlich jemand sich den Zugang mal erschleicht, nur eine DB eines Unternehmens betroffen ist, die anderen aber noch sicher sind.

Aber ja, das bestätigt mich nochmals in der Idee einfach nur eine DB mit einer Tabelle zu nutzen


Vielen Dank für die Antworten!

 

[thecain]

Vielleicht versteh ichs falsch, aber ich würde die DBs trennen. Aus verschienden Gründen.

1. Ein Unternehmen welches deine Applikation benutzt und extra dafür zahlt möchte höchstwahrscheinlich einen "eigene" DB, so hast du das schonmal abgedeckt. Falls dann auch mal die Anforderung kommt, das sie Zugriff wollen/bekommen bist du abgesichtert

2. Sicherheit, SQL Injections... wenn du die DBs sauber trennst, erwischsts, wenn nicht der ganze Server übernommen wird nur einen Kunden.

3. Administrativ (Backup zurückspielen, System platt machen, usw...) Das ist alles einfacher, wenn du verschiedene DBs hast..

4. Neue Anforderungen von Kunde... Kunde A braucht eine spezielle Spalte mehr => Du kannst ihm das bieten, ohne alle anderen Kunden zu beeinflussen.

Hoffe ich hab die Frage richtig verstanden... Sonst halt einfach ignorieren

 

[New_Escaflowne]

@ascer
Ja, danke für die Korrektur. Ist leider doch schon später...
Meine Argumentation würde ich trotzdem analog gestalten. Solange die Annahme besteht, dass von außen kein Zugriff möglich ist, erhöhen zusätzliche DBs nur die Komplexität, aber nicht die Sicherheit.

Wenn man diese Annahme fallen lässt oder wirklich die reale Situation betrachtet, kann es einen Unterschied machen. Man kann dann bspw. auch betrachten, dass manche Unternehmen darauf bestehen, dass ihre Daten physisch getrennt gespeichert werden müssen.
In Szenarien, die Angriffe erlauben, würden mehrere DBs auch die Anzahl der gestohlenen Daten im Fall, dass ein Hacker erfolgreich ist, vielleicht begrenzen. (wobei bei richtigen Sicherheitsmaßnahmen die Passwörter nicht geknackt werden sollten und wenn eine DB gehackt wurde, muss sowieso davon ausgegangen werden, dass die anderen DBs auch kompromittiert sein könnten und kompromittiert werden können => also überall Passwörter ändern).

Wenn man mehr als nur die Sicherheit betrachtet, kommen weitere Argumentationsdimensionen hinzu, wie der Post über mir schön aufzählt.

 

[ascer]

Vielleicht versteh ichs falsch, aber ich würde die DBs trennen. Aus verschienden Gründen.

1. Ein Unternehmen welches deine Applikation benutzt und extra dafür zahlt möchte höchstwahrscheinlich einen "eigene" DB, so hast du das schonmal abgedeckt. Falls dann auch mal die Anforderung kommt, das sie Zugriff wollen/bekommen bist du abgesichtert

2. Sicherheit, SQL Injections... wenn du die DBs sauber trennst, erwischsts, wenn nicht der ganze Server übernommen wird nur einen Kunden.

3. Administrativ (Backup zurückspielen, System platt machen, usw...) Das ist alles einfacher, wenn du verschiedene DBs hast..

4. Neue Anforderungen von Kunde... Kunde A braucht eine spezielle Spalte mehr => Du kannst ihm das bieten, ohne alle anderen Kunden zu beeinflussen.

Danke für das Feedback!
Das sind in der Tat auch nicht unwichtige Punkte..

Ebenfalls nochmals Danke an den Rest

 

[Miuwa]

@ascer:
Was ich auf jeden Fall getrennt halten würde ist eine Datenbank für Logins und Datenbank (en) für Programmdaten.

 

[Fritz]

5. bei deiner Applikation musst du dir weniger Gedanken um die Datensicherheit zu machen, bei eigenen DB ist es durch diese gegeben. Wenn du alles in einer DB machst, dann musst du bei jedem Zugriff auf eine Datensatz (z.B. Personendaten, Adressen, spezielle Inhalte) nicht überprüfen, ob die Resourcen demenstprechender Firma gehört. Das gleiche gilt auch, wenn der Kunde Zugriff haben will, oder später mal die Daten anderstweitig verwenden will. Wird dann kompliziert einen speziellen DB Dump z.b. über 30 Tabellen zu erstellen, welche nur die Daten des Unternehmens XY hat.

Anmerkung.
Da ich solche Sachen beruflich mache, würde ich persönlich extrem unprofessionel halten, wenn meine Daten mit anderen Unternehmen in einer DB geteilt sind, ausser wenn eine bekannte "Bullet Proof" Applikation dahinter steckt, welche lange getestet wurde. Wenn ein kleines Unternehmen mir eine Lösung macht, die ich nicht einschätzen kann, die DB zwischen den Unternehmen nicht getrennt wäre, würde ich davon absehen, mit denen was zu machen, weil ich es als unseriös ansehe.
Hostingpreise, speziell bei MySQL Datenbanken sind niedrig.