etops Geschrieben 11. Oktober 2005 Teilen Geschrieben 11. Oktober 2005 Hallo, ich habe eine möglicherweise etwas seltsame Frage, bei der ich mich mal rückversichern muß, daß da meine Sicht der Dinge stimmt. Ich habe mit PHP/MySQL/FPDF ein System programmiert, das meinen Kollegen das Führen eines Schichtberichts ermöglicht. Nun hat unser Betriebsrat Bedenken, daß dort zu viele persönliche Daten enthalten sein könnten; deswegen soll der Zugriff auf die Daten extrem beschränkt werden. Die Anfrage des Betriebsrats war nun, ob es zwingend notwendig ist, daß der Sys-Admin Zugriff auf die Daten (bzw hier die Einträge) haben muß oder ob es möglich wäre, dem Admin nur Zugriff auf die technische Seite der Datenbank zu geben. Wäre super, wenn dazu jemand einen Kommentar abgeben könnte, wie das nun wirklich ist...(idealerweise mit Quelle, wo das dann zu finden wäre) Danke + Gruß -etops- Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
robotto7831a Geschrieben 11. Oktober 2005 Teilen Geschrieben 11. Oktober 2005 Einen Admin auszusperren halte ich für eine schlechte Idee. Wenn dann keiner mehr an die Daten dran kommt ist das geschrei groß. Man könnte rein theoretisch den Admin den Zugriff auf die Daten verweigern. Frank Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
bmg4ever Geschrieben 11. Oktober 2005 Teilen Geschrieben 11. Oktober 2005 wie soll denn "nur zugriff auf die technische Seite der Datenbank" aussehen. prinzipiell unterstütz mysql ein sehr feines vergeben von rechten. du kannst einem user eben nur zugriff auf administrationszugriffe, wie "show database" oder "lock tables" geben. Des Weiteren kannst du jeden einzelnen Befehl, wie INSERT, ALTER, SELECT einzeln erlauben oder verbieten. Du müsstest dir also in diesem Fall ein SELECT verbieten, was prinzipiell kein Problem ist. Hast du phpmyadmin? Da kannst du die Rechteeinstellungen wunderbar vornehmen und sehen, welche Befehle du alles einzeln freischalten kannst. Allerdings darf man dann auch nicht vergessen das PHP-Backend so unterzubringen, dass der sysadmin die Include-Datei mit den Datenbankzugriffsinformationen nicht lesen und beschreiben darf. Nachdem selbige vorher von der trusted_person, die dann in zukunft hüter des passworts für die entsprechende Datenbank ist, geändert wurden. Dann müsste dein Betriebsrat eigentlich zufrieden sein. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
perdian Geschrieben 11. Oktober 2005 Teilen Geschrieben 11. Oktober 2005 Na du wirst immer jemanden habe, der letzten Endes den Vollzugriff auf alles hat - das liegt in der Natur der Sache. Irgendwer muss schließlich festlegen und kontrollieren "User A hat Zugriff auf Resource X" bzw. sagen dürfen "Ab sofort jat User B keinen Zugriff mehr auf Resource Y, User C hingegen darf ab sofort (wieder) auf Resource Z zugreifen". Und genau dieser Super-User, Sysadmin, oder wie man ihn auch immer nennen will muss existieren. Und selbst wenn man jetzt sagt er darf nur auf die Struktur und nicht auf die Daten selber zugreifen: Wer hindert ihn dann daran, sich diese Rechter selbst wieder zu geben? Es liegt in der Natur der Sache: Er muss und kann nur Vollzugriff haben. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
bmg4ever Geschrieben 11. Oktober 2005 Teilen Geschrieben 11. Oktober 2005 @perdi: ich hab ihn aber so verstanden, dass er mit sysadmin nicht den root von mysql meint, sondern die Person SysAdmin des Betriebes. Jemand anders (jemand, dem man diese daten eher anvertrauen will) würde logischerweise das root-passwort für den fall der fälle mit sich rumtragen, aber der eigentlich Admin dieses Systems soll halt die Daten nicht abrufen können. Damit war ja nicht gemeint MySQL den root zu klauen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
etops Geschrieben 11. Oktober 2005 Autor Teilen Geschrieben 11. Oktober 2005 Ihr habt mir schon alle sehr geholfen - das bestätigt mich ja in der Auffassung, daß es Unsinn ist, diese Trennung vorzunehmen (und nichts anderes als eine Unterstützung dieser Meinung war mir wichtig). Danke + viele Grüße, -etops- Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Jaraz Geschrieben 11. Oktober 2005 Teilen Geschrieben 11. Oktober 2005 Hi, derjenige der für die Daten verantwortlich ist, hat den Rootzugriff auf die Maschine und somit auf Mysql. Muss nun der normale Admin was mit der Kiste anstellen, muss halt der Root User sich einloggen und daneben stehen und den Admin überwachen. Ob das praktikabel ist, müsst ihr dann halt abschätzen. Schwierig wird es wenn Daten von verschiedenen kritischen Bereichen auf einer Maschine sind. Gruß Jaraz Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
bmg4ever Geschrieben 11. Oktober 2005 Teilen Geschrieben 11. Oktober 2005 @etops: so unsinnig finde ich das garnicht Wie ich bereits sagte kann man jedem Mysql-Benutzer ganz feine Rechte verteilen, so dass man jemandem ganz gezielt das ausführen von SELECTs auf eine Tabelle und nur diese eine Tabelle verbieten kann. Mit einem solchen Benutzerkonto kann ein Admin arbeiten auch ohne das MySQL-Root-Passwort zu kennen. Das einzig größere Problem dabei ist, dass selbiger Admin auch keinen root-Zugriff auf den PC haben darf, auf dem das PHP-Projekt liegt. Sein Benutzer darf dann nämlich auch nicht auf die DB-Einstellungen des Servers lesend zugreifen. Grunsätzlich ist das aber alles machbar, wenn man das will. Schwierig wird es wenn Daten von verschiedenen kritischen Bereichen auf einer Maschine sind. Ja da hast du natürlich Recht. Es muss dann immer einen geben, der alles darf. Dass muss man dann entweder in Kauf nehmen oder einfach trennen, was auch getrennt behandelt werden soll. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.