Hi,
gibt’s eine Möglichkeit dem Nutzer den Zugriff auf die Datenbankstruktur zu beschränken?
Wir haben eine Datenbank entworfen, die vorinstalliert zusammen mit dem Server dem Kunden ausgeliefert wird. Der Kunde soll nur über einen Set von Views auf die Daten zugreifen können, die den Views zugrunde liegende Datenbankstruktur soll aber dem Nutzer nicht zugänglich sein, da sie s.g. “Geistiges Eigentum” unserer Firma bleiben soll.
Gruß
Alger
Darf der Kunde ein Backup machen?
Das wirst Du ihm ja kaum verbieten können, oder? Hat der Kunde physischen Zugang zur Platte, wo das läuft?
Aber hey, ich kann Dir eine Alternative anbieten: Hoste das ganze bei uns, dann können wir den Rest klären 
Andreas
Hi Andreas, der Kunde hat zwar physischen Zugang zur Platte, kann aber nichts tun, da er nicht die root-rechte hat und die Platte komplett verschlüsselt ist. Die Backups werden automatisch erstellt (geplannt) und auf der anderen Platte (ebenfalls verschlüsselt) abgelegt. Der Kunde soll damit ausschließlich den Zugriff auf bestimmte Views haben. Sollen Probleme auftreten übernehmen wir Support. Das Reverse Engineering der Datenbank soll nicht möglich sein. Dies ist deswegen notwendig, da auch die Mitbewerber an der Anlage arbeiten und ihr mögliches Interesse an der Datenbank nicht ausgeschlossen ist. Am besten wäre es also dem Benutzer die Rechte zur Auflistung der Kataloge, information_schema o.ä. zu entziehen. Gruß Alger
Okay. Also, ich fürchte, das wird so nicht so einfach gehen (auch nicht, wenn wir hosten würden …), da Du einem regulären Client nicht die Metatabellen vorenthalten kannst.
Was ich mir vorstellen könnte wäre eine Art Proxy. Nur dieser darf sich einloggen, und dieser nimmt halt ein enges Set von Benutzeranfragen an und leitet es an die DB weiter. Diesen baust Du als Blackbox (C, Quellcode bei Euch …), und schaltest ihn vor die DB.
Andreas
Hi Andreas,
ein Proxy zu implementieren wäre evtl. zu aufwendig. Aber könntest du mir evtl. etwas erklären:
Ich erstelle folgende Test-DB als postgres:
CREATE DATABASE test;
\c test;
CREATE TABLE t
(
id integer,
"name" character varying,
status integer
);
CREATE OR REPLACE VIEW v AS
SELECT t.id, t.name
FROM t;
CREATE ROLE user1 LOGIN PASSWORD 'user1';
REVOKE ALL ON DATABASE test FROM public;
GRANT CONNECT ON DATABASE test TO public;
GRANT ALL ON TABLE v TO public;
Jetzt kann user1 über das Schema pg_catalog alle Informationen zur Tabelle t herusfinden, obwohl er keine Rechte auf die Tabelle hat. Das Gleiche über information_schema geht nicht, da hier nur die infos zur Objekten angezeigt werden auf die der Nutzer Rechte hat. Was hat es für einen Sinn? Eigentlich sollen in beiden Fällen die gleichen Infos angezeigt werden?
Ich kann natürlich auch so was tun:
REVOKE USAGE ON SCHEMA pg_catalog FROM public;
Dann kann aber user1 auf gar keine Objekte zugreifen.
Gruß
Alger
Ja, das ist wohl so. Wenn jemand nicht sehen kann, welche Daten in pg_catalog stehen, dann kann er auch keine Tabellen, die ja dort definiert sind (und VIEWS, Funktionen, Datentypen, …) nutzen.
Daher mein Vorschlag mit dem ‘Proxy’.
Andreas
Ja, das ist jetzt klar, trotzdem hätte ich deine Meinung zu den unterschiedlichen Implementierungen von pg_catalog und information_schema. Das ist doch ein Sicherheitsfehler, wenn jeder Benutzer die Infos aus dem pg_catalog abrufen kann. Eigentlich sollten ihm nur die für ihn relevanten Infos, wie es auch information_schema macht, zur Verfügung gestellt werden, oder? Evtl. verstehe ich nicht ganz der Zweck von /Unterschied zwischen den beiden, aber ich halte diese Differenz für inkonsistent.
Gruß
Alger
Tja. Design-Entscheidungen. Ich mag da nicht drüber urteilen. Ein Kollege von mir hat mal dies geschrieben:
Kannst du das auch begründen?
Das ist ungefähr so wie “Weil jeder jede Nummer im Telefonbuch finden kann, ist das System an sich unsicher”.
Aus meiner Sicht es ist nicht immer von vorteil allen Nutzer die komplette Struktur der Datenbank preiszugeben, da die meisten von ihnen eigentlich nur einen Teil sehen sollen. Da so weit ich weiß gemäß ANSI-SQL alle Nutzer den Zugriff als Systemkataloge wie information_schema haben, sollen sie dort nur die Objekte sehen, auf die sie irgendwelche Rechte haben. Das ist ja auch in information_schema von Postgresql realisiert (siehe Beispeil-DB oben und versuch die Informationen zur Tabelle t aus der information_schema abzuleiten), aber durch pg_catalog kann JEDER ohne irgendwelche Rechte für die Objekte die inspizieren. Deswegen wundere ich mich aus welchem Grund es so implementiert wurde.
Was das Telfonbuch angeht, will ja heutzutage auch nicht jeder dass er dort zu finden wäre. Weil es allgemein bekannt ist, dass jeder Hacker-Angriff damit beginnt, dass man zuerst die öffentliche Infos über das Ziel sammelt: Adresse, Telefon, IP-Range usw.
Wenn ich doch nicht Recht bezüglich den Unterschieden zwischen pg_catalog und information_schema haben sollte, bitte ich mich aufzuklären.
Gruß
Alger
Ich habe keine Ahnung, warum diese Informationen nicht im information_schema auftauchen.
Das hat allerdings sicherlich keine sicherheitspolitischen Gründe - vielmehr würde ich auf irgendetwas tippen, was im SQL Standard geschrieben steht.
Ob du im Telefonbuch gefunden werden willst oder nicht, sei dahin gestellt.
Trotzdem kann jeder deine Nummer anrufen, auch wenn er sie nicht kennt 
Vielleicht ist das, was Du willst, mit SE-PostgreSQL möglich, mal so als Stichwort. Ich weiß es aber nicht.
Andreas