Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

Thema: Zugriff auf Struktur einer Datenbank beschränken?

  1. #1
    alger ist offline Neuer Benutzer
    Registriert seit
    14.12.2009
    Beiträge
    22

    Standard Zugriff auf Struktur einer Datenbank beschränken?

    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

  2. #2
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von alger Beitrag anzeigen
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  3. #3
    alger ist offline Neuer Benutzer
    Registriert seit
    14.12.2009
    Beiträge
    22

    Standard

    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

  4. #4
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von alger Beitrag anzeigen
    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.

    Re: Hide schemas and tables

    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  5. #5
    alger ist offline Neuer Benutzer
    Registriert seit
    14.12.2009
    Beiträge
    22

    Standard

    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:
    Code:
    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:
    Code:
    REVOKE USAGE ON SCHEMA pg_catalog FROM public;
    Dann kann aber user1 auf gar keine Objekte zugreifen.

    Gruß

    Alger

  6. #6
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von alger Beitrag anzeigen
    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:
    Code:
    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:
    Code:
    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
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  7. #7
    alger ist offline Neuer Benutzer
    Registriert seit
    14.12.2009
    Beiträge
    22

    Standard

    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

  8. #8
    akretschmer ist gerade online Super-Moderator
    Registriert seit
    29.10.2006
    Ort
    Dresden
    Beiträge
    5.467

    Standard

    Zitat Zitat von alger Beitrag anzeigen
    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:

    Shared Database Hosting - PostgreSQL wiki


    Andreas
    --
    ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
    https://www.xing.com/profile/Andreas_Kretschmer7

  9. #9
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.055

    Standard

    Zitat Zitat von alger Beitrag anzeigen
    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?
    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".
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  10. #10
    alger ist offline Neuer Benutzer
    Registriert seit
    14.12.2009
    Beiträge
    22

    Standard

    Zitat Zitat von ads Beitrag anzeigen
    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

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Zugriff auf die Datenbank nur mit Kennwort erlauben
    Von OlliT im Forum Benutzer- & Rechteverwaltung
    Antworten: 4
    Letzter Beitrag: 01.03.2010, 09:51
  2. Datenbank mit einer Datei füttern
    Von columbus im Forum SQL
    Antworten: 3
    Letzter Beitrag: 31.12.2009, 19:27
  3. Antworten: 1
    Letzter Beitrag: 28.11.2007, 07:06
  4. Zugriff von extern auf interne Datenbank
    Von Shortybabe im Forum Konfiguration
    Antworten: 16
    Letzter Beitrag: 06.11.2007, 22:13
  5. Struktur einer Datenbank anzeigen lassen
    Von trauter im Forum Allgemeines
    Antworten: 3
    Letzter Beitrag: 18.07.2006, 21:27

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum