Announcement

Collapse
No announcement yet.

Benutzerverwaltung von Interbase nutzen

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Benutzerverwaltung von Interbase nutzen

    Moin,

    Ich plane gerade ein Projekt mit dem Builder 6 Ent. und Interbase 6. Nun hab ich mich gestern ein bissel mit der Benutzerverwaltung bei IB auseinandergesetzt und blick da nicht wirklich durch:

    Wenn die Software später von einem Kunden installiert wird, werden die in der jeweiligen Datenbank verwalteteten Benutzer und Passwörter doch durch das Standard-"Master"-Passwort SYSDBA ausgehebelt. Das heißt doch für mich das ich bei einer Installation beim Kunden vor Ort sein muß um das SYSDBA-Passwort abzuändern, andernfalls kann jeder, der Kenntnis von Interbase hat, mittels IBConsole auf jede Datenbank zugreifen?!

    Irgendwie ergibt das für mich keinen Sinn, hab ich da was übersehen? Kann man das SYSDBA-Passwort Softwareseitig ändern(ist jedoch in der ISC4.gdb verschlüsselt)?

    MFG DGriesa

  • #2
    Hallo,<br><br>
    du könntest die Services API von IB 6 mit der Komponente TIBSecurityService (ich glaub die heißt so) verwenden. Damit kannst Du aus einer Delphi/Builder Anwendung heraus, die InterBase Benutzer modifizieren.<br><br>
    Solltest Du etwas während der Installationsroutine brauchen, dann könnt ich Dir ein Tool von mir anbieten (AddIBUser). Mit dem kannst Du skriptgesteuert InterBase Benutzer verändern. AddIBUser könnte somit während der Installation mit dem entsprechenden Skript ausgeführt werden, um z.B. das SYSDBA Passwort 'masterkey' zu ändern. Bei Interesse, gib mir bescheid ([email protected])<br><br>
    Gruss,<br>
    Thomas Steinmaurer<br>
    IB LogManager 2.0 - The Logging/Auditing Tool for InterBase and Firebird<br>
    http://www.iblogmanager.com<br&gt
    Thomas Steinmaurer

    Firebird Foundation Committee Member
    Upscene Productions - Database Tools for Developers
    Mein Blog

    Comment


    • #3
      @Thomas Steinmaurer

      Danke für Deine schnelle Antwort, das klappt soweit...

      Nur hab ich jetzt nen bißchen weiter gedaacht und eine Sache ergibt für mich weiterhin keinen Sinn:

      Bei der Istallation meiner Software wird das SYSDBA-Passwort automatisch geändert sodaß dann niemand per IBConsole auf die Datendateien zugreifen kann... Soweit so gut nur was ist, wenn jemand die Datendatei nimmt und auf einen anderen Rechner spielt wo ich keinen Einfluß auf das SYSDBA-Passwort habe(genau so wenn jemand IB auf dem Rechner neu installiert)? Dann ist doch jedem weiterhin möglich auf die Datendatei zuzugreifen, sogar die Metadaten anzuschauen... Gibt es denn keine Möglichkeit den Zugriff nur in der Datendatei zu verwalten, so daß nur mit den in der DDatei gespeicherten User bzw. Passwörtern möglich ist darauf zuzugreifen? Wenn dem nicht so wäre, würde ich ernsthaft erwägen auf eine andere Datenbank umzusteigen...Denn das würde für mich keinen Sinn ergeben!

      MFG DGries

      Comment


      • #4
        Hallo,<br><br>
        Benutzer werden für den gesamten Server und nicht pro Datenbank gespeichert. D.h. wenn Du Deine Datenbank mit SYSDBA erzeugt hast, und die Datenbank auf einen anderen Rechner kopierst (wo natürlich InterBase installiert sein muß), dann kann auch darauf zugegriffen werden, wenn man das Passwort für SYSDBA kennt (z.B. mit 'masterkey' wenn auf dem anderen Rechner InterBase neu installiert wurde). Das ist leider so, weil das Sicherheitskonzept auf Betriebssystemebene erfolgen muss (Rechtevergabe im Dateisystem). Einen primitiven Trick gibt es, dass man SYSDBA von der Datenbank aussperren kann, d.h. dass er sich nicht mehr anmelden kann. Hierzu muss man eine Role mit dem Namen SYSDBA direkt in der Systemtabelle einfügen. Dies macht allerdings wieder nur Sinn, wenn die Datenbank und alle Datenbankobjekte mit einem anderen Benutzer erzeugt wurden. Dann hat man aber immer noch das Problem, dass man sich mit einem anderen Benutzer anmelden und die Metadaten einsehen kann. In der kostenpflichtigen InterBase 6.5 Version gibt es ein erweitertes Metadaten-Security-Konzept, das verhindern soll, dass "fremde" Benutzer (nicht der DB-Owner?) die Metadaten einsehen kann. Ich habs mir allerdings noch nie angesehen, wie das wirklich funktioniert.<br><br>
        Gruss,<br>
        Thoma
        Thomas Steinmaurer

        Firebird Foundation Committee Member
        Upscene Productions - Database Tools for Developers
        Mein Blog

        Comment


        • #5
          @Thomas Steinmaurer

          Ich geb nicht auf ;-)

          Wenn ich mir in der IBConsole einen neuen User erstelle schaff ich es in der Version 6 nicht, mich mit dem neuen User am Local Server einzuloggen...(war das nicht in der Version 4.5 möglich?!)Ein ähnliches Problem hab ich wenn ich mir mittels TIBSecurityService-Objekt einen neuen User anlege: Mit dem neuen User hab ich nicht die Erlaubnis etwas in der ISC4.gdb zu ändern...Wie geb ich dem neuen User denn die administrativen Rechte? Mittels SQLRole?

          Danke für Deine Geduld,

          MFG DGries

          Comment


          • #6
            Hallo,<br><br>
            die Benutzerinformationen werden in der isc4.gdb in der Tabelle USERS gespeichert. Per Default hat nur SYSDBA alle Rechte auf dieser Tabelle und PUBLIC (ein Synonym für 'alle Benutzer') hat nur das Recht lesend zuzugreifen. Da die isc4.gdb eine InterBase Datenbank ist wie jede andere, kann der SYSDBA einem oder mehreren Benutzern durch Benutzerberechtigungen (werden vergeben mit GRANT) entsprechende Rechte einräumen, dass Benutzer geändert, gelöscht und hinzugefügt werden können. Einen interessanten Artikel darüber gibt es hier http://www.volny.cz/iprenosil/interbase/ip_ib_isc4.htm<br><br>
            Gruss,<br>
            Thoma
            Thomas Steinmaurer

            Firebird Foundation Committee Member
            Upscene Productions - Database Tools for Developers
            Mein Blog

            Comment


            • #7
              Hallo,

              &gt;Bei der Istallation meiner Software wird das SYSDBA-Passwort automatisch geändert ...

              Das halte ich für sehr problematisch. Der InterBase "gehört" nicht der eigenen Anwendung, sondern dem Besitzer dieses Rechners. Der Besitzer/Administrator muss jederzeit auf alle Datenbanken seines Rechners zugreifen können und andere Anwendungen müssen ebenfalls in der Lage sein, neue Datenbanken und neue Benutzer einrichten zu können

              Comment


              • #8
                @Andreas Kosch

                <I>Bei der Istallation meiner Software wird das SYSDBA-Passwort automatisch geändert ...

                Das halte ich für sehr problematisch...</I>

                Der Kunde stellt für die Datenpflege mit der Software eigens einen Rechner zur Verfügung, der auch nur für die Benutzung der Software vorgesehen ist - d.h. mit dem Kunden ist das Vorgehen abgesprochen, er hat ja über das Programm administrativen Zugriff auf die Datenbanken...

                MFG DGries

                Comment


                • #9
                  @Andreas Kosch

                  Außerdem halte ich es für viel problematischer die Metadaten der Datendatei praktisch frei verfügbar zu machen, an der ein Programmierteam von 4 Mann mehrere Monate sitzt.

                  Da das Konzept für die Datenbank beinhaltet, daß alle Abfragen über StoredProcedures laufen, hieße das ja für uns, daß wir sogar bei einer Demoversion unserer Software Angst haben müssen, daß in dem Haus ein Programmierteam sitzt, das für eine eigene Softwareumsetzung unsere datenbankseitige Lösung(die sehr gewichtig ist!) als Vorlage benutzen kann...

                  MFG DGries

                  Comment


                  • #10
                    @dgriesa
                    Wenn unsere InterBase basierende Software auf so einen Rechner trifft, wird ein InterBase Server installiert der SYSDBA kennt und schon hat es sich. Wenn Eure Software das dann wieder ändert wird eine der beiden Softwaren (Softwares?) nicht laufen. Also nicht wirklich eine Lösung.

                    Zudem ist das es wirklich nicht damit getan, ein Datenbankschema abzukupfern, so genial ist *kein* Datenbankschema. Die Anwendung beinhaltet zwar nicht alles, aber vieles.

                    Es ist nicht der Sinn von Datenbanksystemen das man sie zu macht.

                    Es gibt aber einen Trick. In den Systemtabellen stehen die Proceduren und Views im SourceCode und in "übersetzter" optimierter Version. Es soll geglückt sein, den SourceCode zu entferen und die DB läuft noch, was Datensicherung und Rücksicherung dazusagen weiß ich nich

                    Comment


                    • #11
                      Hi,<br>
                      im Firebird Source gibt es einen define ISC_DATABASE_ENCRYPTION. Ich hab das allerdings noch nicht ausprobiert und auch nicht wirklich viel dazu im Netz gefunden. In der devel - Mailing Liste steht, dass man die Verschluesselungsroutienen allerdings noch schreiben muss, und dass es wohl noch nie ausgeliefert wurde.
                      <br>

                      CU Chri

                      Comment

                      Working...
                      X