Hallo,
vielleicht ist das eine dumme Idee, aber ich stelle sie einfach mal vor:
Ich würde gerne eine Applikation mit Django bauen, wo sich gewisse Leute anmelden können und sich temporäre Rechte für Datenbanken (mysql, postgres, sql-server, etc) abholen können.
Temporär heißt sowas wie: "3 Stunden kann der eine user auf die mysql drauf und nur lesen". Würde das eigentlich funktionieren?
Grund dafür soll sein, dass User nicht unbegrenzte Zeit auf die Systeme kommen. Als Selbstschutz, falls da mal die Logindaten verloren gehen.
Als Nachteil sehe ich, dass in der Applikation selbst dann schön an einem Ort die ganzen root-accounts für die gewissen Systeme liegen, weil ja mit irgendeinem Account die Rechte für die anderen Nutzer vergeben werden müssen.
LG
Datenbankzugriff temporär vergeben
-
naheliegend
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
-
__blackjack__
- User
- Beiträge: 13077
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
Was soll „Als Selbstschutz, falls da mal die Logindaten verloren gehen.“ denn überhaupt bedeuten? Gegen welches Szenario genau soll da wer oder was geschützt werden?
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
Was für eine Anwendung schwebt Dir vor? Was sind das für Datenbanken? Warum braucht da jemand direkt lesenden Zugriff? Und warum dann nur für kurze Zeit?
Datenbanken sind schwer zu kontrollieren, es sollte daher immer eine Zwischenschicht geben, über die bestimmte Abfragen ermöglicht werden.
Datenbanken sind schwer zu kontrollieren, es sollte daher immer eine Zwischenschicht geben, über die bestimmte Abfragen ermöglicht werden.
Das ist überhaupt keine dumme Idee, jedes größere Unternehmen hat sowas in der Art. Dabei geht es dann aber eher um SSO.
Ansatz dabei ist aber eher dieser: Du baust ein System um ein JWT (oder äquivalent) über ein idealerweise schon existierendes SSO System zu beziehen. Du konfigurierst PAM-basierte Authentication in deiner Datenbank und hast ein PAM-Modul welches deine JWTs verifiziert. Nutzer können dann ein JWT beziehen welches begrenzt gültig ist und sich damit als Passwort bei der Datenbank authentifizieren.
Andere Lösung: Du hast gar kein Passwort bei der Datenbank, nur ident/peer über localhost. Zugriff wird über SSH gesichert, da gibt es auch SSO Integrationen für.
Zalando hat im Prinzip beides, du bekommst temporär (über 4-Augen Prinzip oder auch ohne im Notfall) Rechte auf Produktivsystem zuzugreifen. Das ermöglicht es einen Tunnel zu Datenbanken aufzubauen und dann kann man sich mit JWT einloggen. Hat dann allerdings nicht nur lesenden sondern auch schreibenden Zugriff. Man kann aber auch SSH Nutzen um auf den Datenbank Server zuzugreifen und hat dann superuser Zugriff.
Ansatz dabei ist aber eher dieser: Du baust ein System um ein JWT (oder äquivalent) über ein idealerweise schon existierendes SSO System zu beziehen. Du konfigurierst PAM-basierte Authentication in deiner Datenbank und hast ein PAM-Modul welches deine JWTs verifiziert. Nutzer können dann ein JWT beziehen welches begrenzt gültig ist und sich damit als Passwort bei der Datenbank authentifizieren.
Andere Lösung: Du hast gar kein Passwort bei der Datenbank, nur ident/peer über localhost. Zugriff wird über SSH gesichert, da gibt es auch SSO Integrationen für.
Zalando hat im Prinzip beides, du bekommst temporär (über 4-Augen Prinzip oder auch ohne im Notfall) Rechte auf Produktivsystem zuzugreifen. Das ermöglicht es einen Tunnel zu Datenbanken aufzubauen und dann kann man sich mit JWT einloggen. Hat dann allerdings nicht nur lesenden sondern auch schreibenden Zugriff. Man kann aber auch SSH Nutzen um auf den Datenbank Server zuzugreifen und hat dann superuser Zugriff.
Grundsaetzlich kann man sowas denke ich bauen, zB via https://mariadb.com/kb/en/authentication-plugin-pam/, und entsprechenden Moeglichkeiten, die Backends zu konfigurieren. Da kann man auch problemlos eine gute Separation der Verantwortlichkeiten hinbekommen, statt django mit root-Rechten auszustatten. ZB via einem extra Daemon, der ueber DBus angesprochen wird, oder seinerseits Datenbankeintraege, etc. pp.
Das groessere Problem hier ist in meinen Augen: direkten Zugriff auf eine DB vergibt man aus einer Vielzahl von Gruenden eher nicht. 3h reichen vollkommen aus, die Datenbank leerzufegen oder einen Exploit darauf auszunutzen. Warum kann fuer dieses Problem nicht der uebliche Weg beschritten werden, eine REST-API anzubieten? Deren Authentication kann ja fast beliebig gefasst werden.
Das groessere Problem hier ist in meinen Augen: direkten Zugriff auf eine DB vergibt man aus einer Vielzahl von Gruenden eher nicht. 3h reichen vollkommen aus, die Datenbank leerzufegen oder einen Exploit darauf auszunutzen. Warum kann fuer dieses Problem nicht der uebliche Weg beschritten werden, eine REST-API anzubieten? Deren Authentication kann ja fast beliebig gefasst werden.
Ich gehe hier davon aus dass es darum geht Menschen Zugriff auf die Datenbank zu geben. Den muss man manchmal einfach haben z.B. für Debugging insbesondere dann wenn es um Performance geht. Da muss man sich mal ein (VACUUM) ANALYZE oder pg_repack ausfüren könne, man muss auch mal einen Query Plan anschauen können und auch Antworten auf Fragen finden wie "Was verändert sich wenn ich seqscans nicht mehr erlaube?" oder "Würde dieser Index helfen?". Eine API die dies alles ermöglicht wird mindestens genauso problematisch sein wie direkter Zugriff auf die Datenbank.
Klar kann man dabei auch was schief gehen dafür hat man PITR und Sicherheit erreicht man eben auch dadurch dass man solchen Zugriff nur temporär erlaubt.
Klar kann man dabei auch was schief gehen dafür hat man PITR und Sicherheit erreicht man eben auch dadurch dass man solchen Zugriff nur temporär erlaubt.
-
naheliegend
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
Danke für die vielen Anregungen. Ich versuche mal auf vieles einzugehen.
Zudem soll damit geloggt werden, welcher Mitarbeiter überhaupt gerade noch auf die DB kommen muss und erhält dann mehr Kontrolle im Sinne von least privilege. Am Ende werden damit dann Karteileichen automatisch ausgeschlossen.
Rest ist halt schwer, weil es teilweise um sehr spezifische Abfragen geht. Oder ist es normal, dass die Rest-API dann quasi hunderte von Endpunkten besitzt?
Okey, das ist schon einmal gut. Hättest du einen anderen Vorschlag?
Der Mitarbeiter/in selbst soll geschützt werden. Wenn die Logindaten für den DB-user von jemand Dritten gesichtet werden, dann kann der Dritte auch fröhlich auf die DB.__blackjack__ hat geschrieben: ↑Dienstag 1. März 2022, 10:08 Was soll „Als Selbstschutz, falls da mal die Logindaten verloren gehen.“ denn überhaupt bedeuten? Gegen welches Szenario genau soll da wer oder was geschützt werden?
Zudem soll damit geloggt werden, welcher Mitarbeiter überhaupt gerade noch auf die DB kommen muss und erhält dann mehr Kontrolle im Sinne von least privilege. Am Ende werden damit dann Karteileichen automatisch ausgeschlossen.
Das sind DBs für Shop-Systeme. Wenn es mal zu Problemen kommt, dann schauen Mitarbeiter beispielsweise in die DB, um den Fehler zu finden. Es ist natürlich schwer für Fehler, die man vorher nicht kennt, eine Abfrage in einer Zwischenschicht zu bauen...Sirius3 hat geschrieben: ↑Dienstag 1. März 2022, 10:28 Was für eine Anwendung schwebt Dir vor? Was sind das für Datenbanken? Warum braucht da jemand direkt lesenden Zugriff? Und warum dann nur für kurze Zeit?
Datenbanken sind schwer zu kontrollieren, es sollte daher immer eine Zwischenschicht geben, über die bestimmte Abfragen ermöglicht werden.
SSO = Single Sign-On? Ich schaue mir das mal. Kenne mich damit nicht aus.DasIch hat geschrieben: ↑Dienstag 1. März 2022, 10:42 Das ist überhaupt keine dumme Idee, jedes größere Unternehmen hat sowas in der Art. Dabei geht es dann aber eher um SSO.
Ansatz dabei ist aber eher dieser: Du baust ein System um ein JWT (oder äquivalent) über ein idealerweise schon existierendes SSO System zu beziehen. Du konfigurierst PAM-basierte Authentication in deiner Datenbank und hast ein PAM-Modul welches deine JWTs verifiziert. Nutzer können dann ein JWT beziehen welches begrenzt gültig ist und sich damit als Passwort bei der Datenbank authentifizieren.
(...)
Das mit dem D-Bus verstehe ich nicht.__deets__ hat geschrieben: ↑Dienstag 1. März 2022, 11:00 Grundsaetzlich kann man sowas denke ich bauen, zB via https://mariadb.com/kb/en/authentication-plugin-pam/, und entsprechenden Moeglichkeiten, die Backends zu konfigurieren. Da kann man auch problemlos eine gute Separation der Verantwortlichkeiten hinbekommen, statt django mit root-Rechten auszustatten. ZB via einem extra Daemon, der ueber DBus angesprochen wird, oder seinerseits Datenbankeintraege, etc. pp.
Das groessere Problem hier ist in meinen Augen: direkten Zugriff auf eine DB vergibt man aus einer Vielzahl von Gruenden eher nicht. 3h reichen vollkommen aus, die Datenbank leerzufegen oder einen Exploit darauf auszunutzen. Warum kann fuer dieses Problem nicht der uebliche Weg beschritten werden, eine REST-API anzubieten? Deren Authentication kann ja fast beliebig gefasst werden.
Rest ist halt schwer, weil es teilweise um sehr spezifische Abfragen geht. Oder ist es normal, dass die Rest-API dann quasi hunderte von Endpunkten besitzt?
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
-
naheliegend
- User
- Beiträge: 439
- Registriert: Mittwoch 8. August 2018, 16:42
So genau wollte ich jetzt nicht drauf eingehen, aber das fasst ungefähr genau das zusammen was wir wollen.DasIch hat geschrieben: ↑Dienstag 1. März 2022, 11:24 Ich gehe hier davon aus dass es darum geht Menschen Zugriff auf die Datenbank zu geben. Den muss man manchmal einfach haben z.B. für Debugging insbesondere dann wenn es um Performance geht. Da muss man sich mal ein (VACUUM) ANALYZE oder pg_repack ausfüren könne, man muss auch mal einen Query Plan anschauen können und auch Antworten auf Fragen finden wie "Was verändert sich wenn ich seqscans nicht mehr erlaube?" oder "Würde dieser Index helfen?". Eine API die dies alles ermöglicht wird mindestens genauso problematisch sein wie direkter Zugriff auf die Datenbank.
Klar kann man dabei auch was schief gehen dafür hat man PITR und Sicherheit erreicht man eben auch dadurch dass man solchen Zugriff nur temporär erlaubt.
Welche Lösung gibt es für diesen Fall die Sicherheit zu erhöhen? Mir ist halt nur ein temporärer Zugriff initial eingefallen.
__backjack__: "Jemand der VB oder PHP kann, der also was Programmieren angeht irgendwo im negativen Bereich liegt (...)"
DBus ist einfach nur ein Weg, wie du ein System mit hoeheren Privilegien von einem mit geringeren anrufen kannst. So funktionieren diverse Dinge zb unter einem Desktop-Linux, bei denen auch priviligierte Operationen, wie Netzwerkschnittstellen zu erzeugen, von "ordinaeren" Benutzer aus angestossen werden koennen.
Und du kannst doch mit REST ein beliebiges SQL Interface anbieten. SQL String rein, Antwort raus. Wenn der Zweck so generisch ist. Oder wenn es darum geht, einfach einen Zugang auf PHP myadmin oder aenhliche Weboberflaechen freischalten.
Der Punkt ist, dass du dafuer nicht die Authentifizierung der DB selbst brauchst. Wobei das natuerlich dann auch deren fein-granularen Zugriffe schwieriger macht, aber da kann man ja auch auf eine Reihe von Standard-Usern (einer mit nur-lesen, einer mit lesen/schreiben, ein admin) zugreifen, die wiederum ueber die Weboberflaeche genutzt werden.
Und du kannst doch mit REST ein beliebiges SQL Interface anbieten. SQL String rein, Antwort raus. Wenn der Zweck so generisch ist. Oder wenn es darum geht, einfach einen Zugang auf PHP myadmin oder aenhliche Weboberflaechen freischalten.
Der Punkt ist, dass du dafuer nicht die Authentifizierung der DB selbst brauchst. Wobei das natuerlich dann auch deren fein-granularen Zugriffe schwieriger macht, aber da kann man ja auch auf eine Reihe von Standard-Usern (einer mit nur-lesen, einer mit lesen/schreiben, ein admin) zugreifen, die wiederum ueber die Weboberflaeche genutzt werden.