Zugriff auf fremde Datenbank - Risiken?
0 
suit
0 suit
0 
dedlfix
0 0 Sonderfall?
0 dedlfix
Zugriff auf fremde Datenbank - Risiken?
Hallo,
zum ersten Mal möchte ich lesend auf eine fremde Datenbank zugreifen und dessen Besitzer Zugriff auf meine DB gewähren.
So weit, so gut. Von meiner MySQL-DB kenne ich es, dass sie keinen "eigenen" Zugang hat, sondern sich das Login auf den gesamten Rechner bezieht, ich damit also auch Verzeichnisse und Dateien manipulieren kann.
Ich will das ausschliessen. Wenn auf dem Fremdrechner irgendwas passiert, darf es nicht an meinem Zugriff gelegen haben. Und natürlich umgekehrt.
Was müssen wir beachten?
Gruß,
Linuxbär
-
Was müssen wir beachten?
Dem Datenbankbenutzer nur die Rechte geben, die er braucht. Und wenn er recht braucht, die das Löschen von Daten implizieren, gibt es keine technische Lösung - da musst du vertrauen, dass die andere Stelle diese Rechte nicht ausnutzt.
-
[...] gibt es keine technische Lösung [...]
Um das klarzustellen: es gibt keine Lösung, wenn du Zugriff auf die Datenbank geben willst. Wenn es dir hingegen um den Austausch von Daten geht, gibt es sehrwohl Lösungen - die erfordern aber dann keinen direkten Zugriff auf die Daten sondern eben auf eine Schnittstelle, die dann entsprechede Sicherungsmaßnahmen trifft.
-
Hello,
[...] gibt es keine technische Lösung [...]
Um das klarzustellen: es gibt keine Lösung, wenn du Zugriff auf die Datenbank geben willst. Wenn es dir hingegen um den Austausch von Daten geht, gibt es sehrwohl Lösungen - die erfordern aber dann keinen direkten Zugriff auf die Daten sondern eben auf eine Schnittstelle, die dann entsprechede Sicherungsmaßnahmen trifft.
Derartige Zugriffe gebe ich immer nur über eine stored Procedure. Diese kann dann nämlich auch vertikale Rechte berücksichtigen und ein Logging veranlassen, auch bei Select und Delete.
Der Direktzugriff auf Tabellen wird nicht gewährt.
Das funktioniert mit MySQL inzwischen sehr schön.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom,
Derartige Zugriffe gebe ich immer nur über eine stored Procedure. Diese kann dann nämlich auch vertikale Rechte berücksichtigen und ein Logging veranlassen, auch bei Select und Delete.
Der Direktzugriff auf Tabellen wird nicht gewährt.
Das funktioniert mit MySQL inzwischen sehr schön.
ich habe leider von stored procedures keine Ahnung. Könntest du ein Beispiel geben oder eine kleine Erklärung für Dummies? Wäre sehr nett, somit könnte auch der faule Problembär auf seine alten Tage sein Wissen noch etwsa erweitern. Im Gegenzug überbringe ich dir gerne einen Topf Honig, falls ich mich mal im Oberharz rumtreiben sollte.
-
Hallo Tom,
Derartige Zugriffe gebe ich immer nur über eine stored Procedure.
ich habe leider von stored procedures keine Ahnung.Meine Ahnung ist ein Jahrzehnt alt (Oracle). Damals konnte mySQL 3 keine stored procedures. Und ich sehe in phpmyadmin dieses Stichwort auch bei Version 5 nirgendwo. Ich kann nur Tabellen anlegen, keine stored procedures.
Könntest du ein Beispiel geben oder eine kleine Erklärung für Dummies?
Ja bitte.
Linuxbär
-
Hello,
Derartige Zugriffe gebe ich immer nur über eine stored Procedure.
ich habe leider von stored procedures keine Ahnung.Meine Ahnung ist ein Jahrzehnt alt (Oracle). Damals konnte mySQL 3 keine stored procedures. Und ich sehe in phpmyadmin dieses Stichwort auch bei Version 5 nirgendwo. Ich kann nur Tabellen anlegen, keine stored procedures.
Dann lad Dir mal "Heidi SQL" runter http://www.heidisql.com/
Mit dem Tool kann man derartige Dinge auch zusammenbasteln.
Den phpMyAdmin habe ich schon ewig nicht mehr benutzt, weiß also leider nicht, ob der die Verwaltung von Stored Procedures und Triggers unterstützt. Das weiß hier aber bestimmt jemand anderer.Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Linuxbär,
Meine Ahnung ist ein Jahrzehnt alt (Oracle). Damals konnte mySQL 3 keine stored procedures. Und ich sehe in phpmyadmin dieses Stichwort auch bei Version 5 nirgendwo. Ich kann nur Tabellen anlegen, keine stored procedures.
so ähnlich gehts mir auch. Ich hatte damals in einer Forschungseinrichtung gearbeitet, wo ich mich mit PL/SQL beschäftigen musste. Über 15 Jahre ist das nun her.. mein Wissen darüber ist mittlerweile gleich null. So, wie ich das verstehe, sind also Stored Procedures das gleiche (oder ähnliches) für MySQL...? Praktisch wäre das ja, vor allem, wenn man den procedures auch noch Rechte zuweisen kann. Leider nuze ich ja von MySQL die vielen tollen neuen Möglichkeiten nur sehr begrenzt. Prepared Statements war so das letze, mit dem ich mich beschäftigt hatte.
Zu deiner Schnittstelle: ich hab mal für ein Unternehmen ne Menge Importschnittstellen entwickelt für verschiedene Datenprovider. Da ging es um den Import und die Verarbeitung großer Datenmengen (Geowissenschaften). Im Endeffekt war es dann das beste, eine einheitliche Schnittstelle zu entwickeln, um nicht jedes mal wieder von vorne anfangen zu müssen. Heute musst du auf MySQL zugreifen, morgen ist es SOAP, übermorgen werden dir die Sachen via XML-Dump oder als CSV geliefert. Allerdings ist die Entwicklung so einer Schnittstelle a) nicht trivial, wenn sich das Format und Menge der Daten nicht ähnelt, und b) nur empfehlenswert, wenn die Zahl der zu importierenden Datenquellen etwas größer ist.
@Tom
Danke, dass du dir die Mühe machst! Sehr nett von dir!-
Hallo Problembär,
... mich mit PL/SQL beschäftigen musste. ... So, wie ich das verstehe, sind also Stored Procedures das gleiche (oder ähnliches) für MySQL...?
Nein, PL/SQL ist eine Programmiersprache (wenn ich mich recht erinnere für den Client, also PC), Stored Procedures sind auf dem Host vorgefertigte SQL- Kommandos, die mit Parametern gefüttert werden.
Wenn ich also einen Kundensatz löschen möchte, könnte eine Stored Procedure (SP) prüfen, ob noch offene Rechnungen vorliegen und das Löschen ggf. verweigern. So kann ich aus verschiedenen Programmen dieselbe SP aufrufen. Wenn dann Bedingungen hinzukommen, muss ich nicht in die Programme eingreifen, sondern "nur" die betr. SPs anpassen. Gute Sache, mache ich jetzt mit PHP-includes, gehört aber eigentlich in die Datenbank.
Gruß,
Linuxbär-
Hello,
Wenn ich also einen Kundensatz löschen möchte, könnte eine Stored Procedure (SP) prüfen, ob noch offene Rechnungen vorliegen und das Löschen ggf. verweigern. So kann ich aus verschiedenen Programmen dieselbe SP aufrufen. Wenn dann Bedingungen hinzukommen, muss ich nicht in die Programme eingreifen, sondern "nur" die betr. SPs anpassen. Gute Sache, mache ich jetzt mit PHP-includes, gehört aber eigentlich in die Datenbank.
Genau das ist der Grund, warum ich sie auch dort unterbringen würde.
Man kann dann mit seinem "normalen" Webinterface zugreifen, mit einem nicht näher spezifizierten Programm über dessen API und Port 3306 (als Beispiel), oder auch direkt mit einem Client aus der Entfernung oder vom Localhost.Und es gelten immer die in MySQL eingestellten Rechte sowie die in den Procedures verdrahteten.
So kann man z.B. erreichen, dass User "Albert" beim Select (über die entsprechende SP) nur "seine" Datensätze angezeigt bekommt. Auf andere Selects, als die für ihn vorbereiteten, bekommt er keine Rechte. Und man kann in der SP verdrahten, dass dieser Zugriff logged wird, wobei das bei Selects dann schon ein ziemliches "Voratsdatenaufkommen" geben kann. Aber in üblicher Bankensoftware oder aber bei Behörden ist das oft so geregelt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
Hello,
Derartige Zugriffe gebe ich immer nur über eine stored Procedure. Diese kann dann nämlich auch vertikale Rechte berücksichtigen und ein Logging veranlassen, auch bei Select und Delete.
Der Direktzugriff auf Tabellen wird nicht gewährt.
Das funktioniert mit MySQL inzwischen sehr schön.
ich habe leider von stored procedures keine Ahnung. Könntest du ein Beispiel geben oder eine kleine Erklärung für Dummies? Wäre sehr nett, somit könnte auch der faule Problembär auf seine alten Tage sein Wissen noch etwsa erweitern. Im Gegenzug überbringe ich dir gerne einen Topf Honig, falls ich mich mal im Oberharz rumtreiben sollte.
Ich bastel mal ein Beispiel mit einem Trigger, einer einfachen vertikalen Rechtekontrolle durch Stored Procedure, sowie einem Logging. Ob ich das heute noch schaffe, weiß ich nicht. Müsste ja schließlich auch ein wenig dokumentiert werden und es sollte ein "Create-Tool" dafür da sein.
Ich denke, es wird eher Dienstag werden.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo Tom
ich habe leider von stored procedures keine Ahnung. Könntest du ein Beispiel geben oder eine kleine Erklärung für Dummies? Wäre sehr nett, somit könnte auch der faule Problembär auf seine alten Tage sein Wissen noch etwsa erweitern. Im Gegenzug überbringe ich dir gerne einen Topf Honig, falls ich mich mal im Oberharz rumtreiben sollte.
Ich bastel mal ein Beispiel mit einem Trigger, einer einfachen vertikalen Rechtekontrolle durch Stored Procedure, sowie einem Logging. Ob ich das heute noch schaffe, weiß ich nicht. Müsste ja schließlich auch ein wenig dokumentiert werden und es sollte ein "Create-Tool" dafür da sein.
schon ein Beispiel gebastelt?
grüße
der Problembär-
Hello,
Ich bastel mal ein Beispiel mit einem Trigger, einer einfachen vertikalen Rechtekontrolle durch Stored Procedure, sowie einem Logging. Ob ich das heute noch schaffe, weiß ich nicht. Müsste ja schließlich auch ein wenig dokumentiert werden und es sollte ein "Create-Tool" dafür da sein.
schon ein Beispiel gebastelt?
Bin noch dran.
Es mutiert schon wieder zur eierlegenden Wollmilchsau.
Das ist eigentlich mehr, als ich wollte.Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
-
-
-
Tach!
Von meiner MySQL-DB kenne ich es, dass sie keinen "eigenen" Zugang hat, sondern sich das Login auf den gesamten Rechner bezieht, ich damit also auch Verzeichnisse und Dateien manipulieren kann.
Da kennst du aber das Rechtesystem MySQLs nicht. Man kann bis hinunter auf Felder Berechtigungen erstellen. Und die MySQL-Kennungen haben nichts mit dem Zugang auf den restlichen Rechner zu tun.
Was müssen wir beachten?
MySQLs Rechtesystem und dass man den MySQL-Server so konfigurieren kann, dass er gar keine oder nur eingeschränkt Netzwerkverbindungen entgegennimmt. (Firewalls und andere Netzwerkgeschichten können ebenfalls noch mitspielen, liegen aber außerhalb des MySQL-Verantwortungsbereichs.)
dedlfix.
-
Was müssen wir beachten?
Ich würde, wenn möglich, mit nem ssh-Tunnel arbeiten. in Verbindung mit nem Public-Key ist das verschlüsselt und recht sicher und die Passworteingabe entfällt.
Der Zugriff erfolgt dann im Prinzip per localhost der den Port dann tunnelt.
Dazu müssen aber auf beiden Servern Konsolenzugriffe möglich sein.Besser ist IMO aber eine echte Schnittstelle, z.B. per XML. Damit kann serverseitig sichergestellt werden, dass nur bestimmte Datenabgerufen werden können.
-
Hello,
Besser ist IMO aber eine echte Schnittstelle, z.B. per XML. Damit kann serverseitig sichergestellt werden, dass nur bestimmte Datenabgerufen werden können.
Die Begrenzung und Kontrolle der Datenzugriffe für Datenbankbenutzer sollte man nicht in eine API verlagern, wenn man sie direkt im DBMS verankern kann. MySQL kann Stored Procedures und Triggers, mit denen man dann die Zugriffe gestalten kann. Die Triggers haben mWn zwar immer noch keine Möglichkeit, gezielt Exceptions zu schmeißen (außer mit schmutzigen Tricks), aber für diesen Anwendungsfall geht das auch ohne.
Die Verwendung eines Tunnels, also quasi Aufbau eines VPN, ist sicherlich gut.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Die Begrenzung und Kontrolle der Datenzugriffe für Datenbankbenutzer sollte man nicht in eine API verlagern, wenn man sie direkt im DBMS verankern kann.
Wenn es um das pure durchreichen von Daten geht, stimmt das natürlich.
Eine API macht erst dann wirklich Sinn, wenn die Daten vorher noch validiert und aufbereitet werden.Bei Raw-Daten wäre eine API nur ein unötiger Flaschenhals.
-
-
-
So weit, so gut. Von meiner MySQL-DB kenne ich es, dass sie keinen "eigenen" Zugang hat, sondern sich das Login auf den gesamten Rechner bezieht, ich damit also auch Verzeichnisse und Dateien manipulieren kann.
Hmm, ist wohl ein Sonderfall. Ich greife aus der Sicht von PHP auf "localhost" zu und nutze für die Datenbank User und Passwort, der auch andere Dinge machen kann, etwa SSH.
Sollte ich wohl mal ändern?
Der "Fernzugriff" von PHP auf eine meiner anderen Datenbanken funktioniert nicht mit "localhost", sondern mit "mysql.example.com" und eigenem DB-User, hatte ich übersehen.
Linuxbär
-
Tach!
Von meiner MySQL-DB kenne ich es, dass sie keinen "eigenen" Zugang hat, sondern sich das Login auf den gesamten Rechner bezieht, ich damit also auch Verzeichnisse und Dateien manipulieren kann.
Hmm, ist wohl ein Sonderfall. Ich greife aus der Sicht von PHP auf "localhost" zu und nutze für die Datenbank User und Passwort, der auch andere Dinge machen kann, etwa SSH.Dann sind zufällig beide Kennungen mit gleichem Namen und Passwort eingerichtet.
Sollte ich wohl mal ändern?
Sinnvoll wäre das vermutlich. Gleiche Zugangsdaten sind immer ein Risiko, wenn ein Pärchen davon in falsche Hände gerät.
Der "Fernzugriff" von PHP auf eine meiner anderen Datenbanken funktioniert nicht mit "localhost", sondern mit "mysql.example.com" und eigenem DB-User, hatte ich übersehen.
Logisch. Und wenn nur dieser eine PHP-Host mit fester IP-Adresse oder zumindest festem DNS-Namen mit dieser Kennung arbeiten soll, kannst du die Kennung auch auf die IP-Adresse oder den DNS-Namen einschränken.
dedlfix.
-