Internetsichere DB

[wanne]

Also die übliche Variante um fremde Nutzer auf eine DB zugreifen zu lassen ist der:
Anwendung->PHP-Rest-Web-Server->MySQL
Wobei der Webserver die Überprüfung von credentials escaping... macht damit die User keinen Sch* bauen.
Im Prinzip finde ich das extrem unelegant, dass ich mir da jedes mal ähnliche Anwendungen baue die sich um Zugriffsrechte kümmert.
Jetzt ist meine Frage: Gibt es irgend eine DB bzw. Konfiguration die von Anfang an auf bösartige Zugriffe aus dem Internet o.ä. ausgelegt ist?
Ich stell mir das so vor: Lege da irgend wie Tabellen an und sag dann ich hab hier ne Nutzergruppe a) und die kann da halt Zeilen einfügen und eine die da drauf suchen kann. Und sonst dürfen die nichts.
Halt so per default secure und nicht erst durch ein Sicherheitslayer marke Eigenbau davor. Gerne auch irgend welche nosql DBs.

[bluestar]

Also bei PostgreSQL kannst du die Rechte pro Benutzer auf die Datenbank, einzelne Tabellen und einzelne Spalten beschränken.

Das Problem liegt wohl eher darin begründet, dass Web-Applikationen diese Features nicht nutzen und meist ein eigenes (ggfs. buggy) Securitylayer selbst über eine DB bauen.

Dann stellt sich mir natürlich die Frage dies praktisch umzusetzen, ein klassischer Wenspace+DB Anbieter hat sicher niemals ein Interesse die Sicherheit aus der Web-App, dem Verantwortungsbereich seines Kunden, in den Datenbank-Server, seinen Verantwortungsbereich, zu verlagern.

Ich gehe mal weiter und vergleiche das mit einem Mailserver-Setup, wo die Mails aller Benutzer im System dem Benutzer „mail“ oder „vmail“ gehören.

Sicherheitstechnisch ist dies alles relativ murksig

[schorsch_76]

Postgres, mysql und mariadb kann das. Ich denke das dieses Rechtemanagement eben oft via "GRANT ALL PRIVILEGES on..." umgangen wird. Ich denke man sollte das Layer der Anwendung besser (tm) bauen und dieses Rechtemanagement der DB nutzen. Sind die Rechte eingeschränkt, kann auch nicht "Litte Bobby Drop tables" nichts löschen. [1]

Beispiel:

AnnonReader: GRANT SELECT on unimportant tables ....
User 1: GRANT SELECT and insert into more important tables....
Service: GRANT SELECT and insert and delete into ....
Admin: Grant all ...
Dabei kann man unter Postgres auch die Verbindung in der pg_hba.conf mit berücksichtigen. Bsp. Admin kann sich nur über VPN Vollzugriff auf diese DB verschaffen.

Admin != root der Datenbank. Also Admin ist nicht postgres user.

[1] https://xkcd.com/327/

[novalix]

Beispiel:

AnnonReader: GRANT SELECT on unimportant tables ....
User 1: GRANT SELECT and insert into more important tables....
Service: GRANT SELECT and insert and delete into ....
Admin: Grant all ...

Mmh, und woher weiß das RDBMS, wer "AnnonReader", "User 1", etc. ist? Muss das nicht vorher die WebApp entscheiden? Und die holt ihre Informationen aus der Datenbank, braucht dafür in jedem Fall schon mal ein "GRANT SELECT on important table". Da sie ja entscheidet, wer was darf, muss sie diese Information aber auch in der Datenbank hinterlegen können: GRANT SELECT and insert and delete into.
Wenn man sich dann noch die Möglichkeit offen halten will, dass so eine WebApp durch ein verfeinertes DB-Schema verbessert werden kann (z.B. hinsichtlich Zugriffsrechte), braucht es wohl ein GRANT all.

[schorsch_76]

Kein Password -> User: AnnonReader

Wer darauf zugreift, muss ja schon mal wissen auf was er zugreift. Wenn er nichtmal den User "AnnonReader" kennt -> Access Denied.

[uname]

Ist es nicht so, dass die Zugangsdaten in irgendeiner Form in PHP-Konfigurationen stehen müssen? Für die Web-App selbst wird man darum wohl nicht rumkommen, da sie ja ohne Anmeldung des Datenbank-Benutzers funktionieren soll. Aber vielleicht kann man bei administrativen Tätigkeiten neben der Anmeldung als "Admin" die Eingabe des "Admin-DB-Passwortes" manuell erzwingen (bzw. temporär vorher in der Konfig setzen). Auch könnte man vielleicht die Administration in andere Bereiche (z. B. geschützt per Htaccess), über Datenbank-Admin-Software oder über eine Remote-DB-Administration z. B. durch einen SSH-Tunnel auslagern. Natürlich muss man dann die Berechtigungen an den Datenbanken noch entsprechend anpassen (siehe Beispiel oben, viel mehr als 2 Benutzer sehe ich aber nicht). Und wichtig: regelmäßiges Backup.

Folgendes hat zwar mit DBs nichts zu tun kann diese jedoch indirekt auch auslesen. Sehr interessant sind die vorgeschlagenden Konfigurationsänderungen an Apache2. Das Thema ist aber nur relevant wenn man das Upload-Plugin direkt oder indirekt über ein CMS verwendet.

https://www.heise.de/security/meldung/S ... 96771.html

[novalix]

OK, es geht um dynamische Anwendungen für im Browser drin (neudeutsch: Web-App).
Die Zuständigkeit dafür liegt zweifelsfrei beim http-daemon. Klassisch liefert der Dateien aus dem Document Root aus. Das kann aber über unterschiedliche Schnittstellen (Module, CGI, Proxy-Schnittstelle) aufgebohrt werden, so dass man über ausführbaren Programmcode (Brainfuck, PHP, Ruby on Rails, Lisp on Lines, Assembler, etc.) die auszuliefernden Inhalte dynamisch erzeugen kann. Die notwendigen Daten, die für die dynamische Zusammenführung gebraucht werden, könnte man weiterhin vollständig im Dateisystem speichern (z.B. in Templates und CSV-Dateien).
Noch dynamischer wird es, wenn man als Daten-Backend zusätzlich ein Datenbank-Management-System einsetzt.

Die Programmlogik braucht also Zugriff auf eine Datenbank. Dazu muss der DB-Admin zunächst einmal eine DB anlegen und den Zugriff darauf festlegen.
Innerhalb der Datenbank muss jetzt eine Tabellenstruktur angelegt werden, die den funktionalen Ansprüchen der Programmlogik der Web-App entspricht.

Wenn ich jetzt mit dem Modell unterschiedliche Datenbanknutzer für unterschiedliche Aufgaben innerhalb der Web-App arbeite, dann müssen diese Nutzer entweder im Vorfeld vom DB-Admin angelegt werden, oder der DB-Admin muss dem administrativen Nutzer der Web-App das recht einräumen weitere DB-Benutzer anzulegen (nicht so gute Idee).

Wir haben jetzt einen Klon des Debianforums in C mit unterschiedlichen Datenbankbenutzerrollen gebaut. Ich rufe die Seite auf, die Programmlogik verbindet sich als "Annon User" "annonuserpw" zur Datenbank. Das ist der Default. Diese User-Rolle lässt nur Selects zu, die für die öffentlich lesbaren Teile des Auftritts taugen.
Ich lese einen Beitrag von @wanne und will mich dazu äußern, also melde ich mich mit "novalix" "Passwort" an.
Die Programmlogik muss jetzt dafür sorgen, dass eine neue Verbindung zur Datenbank als "User 1" "user1pw" aufgebaut wird, damit auch Selects ausführbar sind, die Inhalte in bestimmte Tabellen einfügen können.

An der Stelle habe ich schon einen Haufen Probleme. Das Management der Http-Session muss absolut gleichlaufend mit dem der DB-Session sein. Neue DB-Session, neue Http-Session sonst sind Hopfen und Malz verloren.
Das ständige Öffnen und Schließen von Sessions und DB-Verbindungen hat dann ja auch Konsequenzen für Nutzbarkeit und Performance.
Außerdem liegen ja die Nutzerinformationen "novalix" "Passwort" irgendwo rum. Sinnvollerweise in einer besonders schützenswerten Tabelle der Datenbank. Entweder hat also "Annon User" schon die Möglichkeit einer Abfrage auf diese Tabelle, oder irgendeine Aktion davor muss bereits den DB-User-Wechsel triggern.

Leider haben wir die Programmlogik unseres Klons etwas schlampig implementiert. Weil ich über "Neue Beiträge" eingesprungen bin, läuft der Puffer über. Bei meiner Anmeldung ist fehlerhafter Weise die Datenbankbenutzerrolle "Service" "servicepw" aufgerufen worden. Ich bin jetzt Moderator und werde ganz grün im Gesicht.

Ich kann nicht sehen, wie die Verschiebung der Verantwortung für die Verwaltung der Zugriffsrechte hin zum DBMS einen Sicherheitszugewinn bringen soll. Mal abgesehen davon, dass es in der Praxis bedeutet, dass bei jeder Änderung des Layouts der Zugriffsrechte der Software ein Datenbankadministrator eingreifen müßte.

[wanne]

AnnonReader: GRANT SELECT on unimportant tables ...

Habe das gerade mal ausprobiert.
Und dann getestet:

Code: Alles auswählen

AnnonReader=> \! cat /proc/1/cmdline
/sbin/init

Das stelle ich mir nicht ganz so vor. Insbesondere kann der auch die Datenbank dumpen...

[schorsch_76]

AnnonReader ist ein Systemuser oder ein reiner DB User aka Role?

EDIT:
Siehe https://www.postgresql.org/docs/9.0/sta ... manag.html
https://www.postgresql.org/docs/9.0/sta ... butes.html

[uname]

@novalix:
Sehr schön geschrieben.

Ich bin jetzt Moderator und werde ganz grün im Gesicht.

Sehr geil.

[wanne]

OK, es geht um dynamische Anwendungen für im Browser drin (neudeutsch: Web-App).

Nein. Genau nicht. Ich will den httpd gerne vollständig beseitigen. Es geht um Java anwendungen die auf der gleichen (sich ändernden) Datenbasis arbeiten.

[schorsch_76]

Bisher werden deine https/REST Anfragen ja in SQL umgesetzt und dann die Antwort eben zurück gegeben. Richtig?

Was spricht denn dann dagegen sich mit der DB direkt zu verbinden und dem jeweiligen Nutzer nur die Rechte für diese Abfrage zu geben? Den Transport eben per SSL sichern (ist klar). Wenn du dem Nutzer alle Rechte genommen hast und ihm nur den SELECT auf den benötigten Tabellen gibst, wie soll er dann die DB dumpen können?

Dann hättest du halt das SQL wieder direkt in deiner Anwendung und nicht im Php/Rest Server. Eventuell kannst du aber auch eine Anwendung auf dem DB Server laufen lassen die deine anwendungsspezifischen Anforderungen abdeckt. Ich denke da an das Actormodel [1]. Du könntest auch für den Message Transport RabbitMQ [2] nutzen. Das wird bsp. in World of Tanks [3] benutzt um die Nachrichten zwischen den Servern zu handhaben.

[1] https://de.wikipedia.org/wiki/Actor_Model
[2] https://www.rabbitmq.com/
[3] https://hackmag.com/devops/interview-wi ... evelopers/
[4] https://content.pivotal.io/rabbitmq/und ... ache-kafka

[novalix]

OK, es geht um dynamische Anwendungen für im Browser drin (neudeutsch: Web-App).

Nein. Genau nicht. Ich will den httpd gerne vollständig beseitigen. Es geht um Java anwendungen die auf der gleichen (sich ändernden) Datenbasis arbeiten.

Das geht aus Deinem Eingangspost aber nicht deutlich hervor. Auch jetzt ist mir der Problemaufriss noch nicht ganz klar.
Mehrere Java-Anwendungen greifen auf eine DB zu, richtig?
Tun sie das ausschließlich lokal, oder soll da auch ein Netzwerkprotokoll (was anderes als http) involviert sein?
Eine REST-Schnittstelle ohne http gibt es nicht. PHP hat da nur im Einzelfall was mit zu tun.
Man kann eine REST-API bauen ohne Webfrontend. Python Flask wäre da ein hipper Kandidat. Wenn es etwas in Java sein soll, gibt es da mit Sicherheit auch irgendwelche Baukästen.

Falls Deine Java-Anwendungen entfernte Clients sein sollten, könntest Du diese sich natürlich über TCP/IP direkt mit dem DBMS verbinden lassen, wie @schorsch_76 vorschlägt. Da gibt es allerdings zwei Bedenken:

1. Kompliziert, weil schon kleine Fehler im Aufbau und der Konfiguration die ganze Sache zur "Methode Scheunentor" machen.

2. Kompliziert, weil eng geführt. Bei so einem Aufbau hängt vieles von einander ab. Hast Du eine einheitliche API für die Clients, ist selbst ein kompletter Wechsel des DB-Backends relativ einfach durchführbar. Im anderen Fall musst Du bei trivialen Schema-Updates o.ä. an unterschiedlichen Stellen (in jedem Client) rumlöten.

Musst Du halt abwägen, welche Anforderungen dafür sprechen, den einigermaßen stabilen Weg einer einheitlichen API zu verlassen. Du zahlst mit einiger Sicherheit mit erhöhtem Wartungsaufwand bzw. geringerer Flexibilität bei der Weiterentwicklung.

[wanne]

Also im Moment ziehen sich die Clients die ganze DB als CSV-Dump (nur 2 Tabellen) von einem stock dummen http-Server, packen das in ihre lokale SQL-Datenbank und arbeiten dann da drauf. Sprich danach ist alles lokal.
Die csvs sind im einstelligen MiB Bereich. Das kann man schon so machen. Ist aber eher unelegant. Ein SELECT das nur die relevanten Daten holt und vor allem dann auch updates (Zeilen haben einen Zeitstempel) holen kann wäre ganz nett.
Kurz die Sache ist eigentlich super primitiv und braucht das ganze Zeug, was man da sonst noch so rein haut eben nicht. Deswegen wollte ich es einfacher haben. Es ist auch Wurst wenn die Anwendungen mal einen Tag split-Brain haben.

Man kann eine REST-API bauen ohne Webfrontend.

Ja ich habe hier einige laufen. Tomcat mit java, python C. Ganz unbedarft bin ich nicht. Ist im Prinzip auch kein großes Ding das zu bauen. Nur eigentlich stinkt mir das jedes mal ne eigene Webanwendung zu schreiben nur damit man irgend wie remote Daten abfragen kann. SQL gibt es ja schon.
Deswegen die frage nach einer fertigen Variante.
So wie der Apache der hat auch erstmal PUT u.ä. Sachen, die man eher nicht am Internet haben will aus, weil er halt dazu gedacht ist am Internet zu laufen. Potentielle in den Fuß schieß-Hindernisse sind da erstmal aus dem Weg geräumt.

Kompliziert, weil schon kleine Fehler im Aufbau und der Konfiguration die ganze Sache zur "Methode Scheunentor" machen.

Genau deswegen frage ich ja nach DB, die von Anfang an auf sowas ausgelegt ist.

Hast Du eine einheitliche API für die Clients, ist selbst ein kompletter Wechsel des DB-Backends relativ einfach durchführbar. Im anderen Fall musst Du bei trivialen Schema-Updates o.ä. an unterschiedlichen Stellen (in jedem Client) rumlöten.
Musst Du halt abwägen, welche Anforderungen dafür sprechen, den einigermaßen stabilen Weg einer einheitlichen API zu verlassen. Du zahlst mit einiger Sicherheit mit erhöhtem Wartungsaufwand bzw. geringerer Flexibilität bei der Weiterentwicklung.

Ganz im Gegenteil. SQL ist eine Standartisierte Sprache. Da kann ich einfach die DB austauschen. – Im krassen Genteil zu irgend welchen REST-APIs marke Eigenbau, die es in Milliarden von verschiedenen Varianten gibt.
Wenn es irgend was gibt was absolut uneinheitlich ist, dann ist es REST.
Und das Selber schreiben weniger Wartungsaufwändig sein soll als was bestehendes nutzen höre ich jetzt auch zum ersten mal.
Genau darum geht es: Ich will eben nicht 50 hippe tolle Web-Frameworks die morgen 5Mio. Sicherheitslücken haben, die nicht gefixt werden, weil die hippster jetzt was anders nutzen auf meinem Server laufen lassen.
Sondern einen Server der einigermaßen Stabiel über die nächsten Jahre abfragen machen kann. OHNE dass ich da irgend was selber geschriebenes dazu bauen muss.

Den Transport eben per SSL sichern (ist klar).

Sind öffentliche Daten im Prinzip braucht es das nicht mal. admin-zugriff gibst sowieso nur über unix-sockets. Aber läuft auch jetzt schon über TLS. Werde das vermutlich auch weiter machen. Schadet ja auch nichts. Hat nebenbei den Vorteil, dass man die Daten auf dem Client nicht validieren muss.

Dann hättest du halt das SQL wieder direkt in deiner Anwendung

So hätte ich das gerne und so ist es ja schon.

RabbitMQ

Bin eigentlich froh wenn ich den eher nicht drin hab. Wir verstehen uns nicht so gut.

Wenn du dem Nutzer alle Rechte genommen hast und ihm nur den SELECT auf den benötigten Tabellen gibst, wie soll er dann die DB dumpen können?

Ich kann da halt immer noch shell Kommandos ausführen mit denen könnte ich den Memory der DB dumpen und damit hab ich die Daten anderer Tabellen.
Ich wette, das bekommt man irgend wie weg. Aber weiß der Kuckkuck was ich da sonst noch übersehen habe. Deswegen halt die Frage nach ner DB die mal per default davon ausgehe, das die Nutzer eben nicht vertrauenswürdig sind.
Das ich dadurch etwas an Flexibilität einbüße ist mir klar. Aber wenn das irgend wann mal wirklich sein muss kann ich immer noch den Weg über die REST-API gehen. Für mehr flexibilität müsste ich auch die brechen. Im moment will ich einfach etwas Flexibilität aufgeben und mir dafür Wartungsaufwand sparen.

[bluestar]

Ich kann da halt immer noch shell Kommandos ausführen mit denen könnte ich den Memory der DB dumpen und damit hab ich die Daten anderer Tabellen.

Kannst du mal ein Beispiel posten, wie du über Java dein Shell-Kommando in der Datenbank ausführst.

Wenn ich deinem Thread so folge, dann spielst du auf darauf an:

Habe das gerade mal ausprobiert.
Und dann getestet:

Code: Alles auswählen

AnnonReader=> \! cat /proc/1/cmdline
/sbin/init

Das stelle ich mir nicht ganz so vor. Insbesondere kann der auch die Datenbank dumpen...

Das ist \! ist in dem PostgreSQL Client ein Kommando um auf dem Rechner, wo der Client läuft, also normalerweise nicht dein DB-Server, einen Shell-Befehl auszuführen.

[wanne]

Das ist \! ist in dem PostgreSQL Client ein Kommando um auf dem Rechner, wo der Client läuft, also normalerweise nicht dein DB-Server, einen Shell-Befehl auszuführen.

Ah danke für den Hinweis. Das hatte ich so nicht kapiert. Dann ist das ja eher harmlos.
Du meinst also auch, das man die Zugangsdaten von einem User, der nur SELECT erlaubt bekommen hat ohne Probleme veröffentlichen kann?

[novalix]

Ganz im Gegenteil. SQL ist eine Standartisierte Sprache. Da kann ich einfach die DB austauschen.

Na, ganz so einfach ist das dann meistens doch nicht. Den SQL-Standard interpretieren die einzelnen RDBMS z.T. recht frei, bzw. erweitern ihn mit je eigenen Mitteln. Und das die Abfragesprache SQL standardisiert ist, heißt ja nicht, dass jede Lösung, die damit umgesetzt wird, eine Standardlösung darstellt.

Nach Deinem Eingangspost war SQL ja auch keine Voraussetzung.

Mittlerweile ist auch mir etwas klarer, wonach Du eigentlich suchst. Da hätte ich eine möglicherweise erwägenswerte Alternative anzubieten: Die Replikations-Features der feschen NoSQL-DBs.

Beispiel: Scaling, sharding and replication von RethinkDB.

Natürlich hast Du dann wieder die Aufgabe, die Abfragelogik der Clients im jeweils benutzten "Jargon" (hier: ReQL) umzuschreiben und Dein vorhandenes anscheinend relationales DB-Schema zu übersetzen. Vielleicht ist das zu aufwändig.
Eine standardisierte Lösung für Deine konkrete Aufgabe ist das selbstverständlich auch nicht.
Die NoSQL-Dinger sind aber letztlich im Hinblick auf verteilte, konkurrierende Zugriffe konzipiert. Proxy Nodes erscheinen hier besonders praktisch.

[bluestar]

Ich kann dir PostgreSQL Doku empfehlen.

https://www.postgresql.org/docs/9.5/sta ... urity.html