Datenbank-Passwörter speichern

[Jumpy]

Zitat von BUG:

Das Problem bei diesen Lösungen ist einfach, dass es im Programm eine Verbindung zur Datenbank mit Admin-Rechten gibt.

Da ist natürlich was Wahres dran. Die Benutzen User haben viel mehr Rechte, als für den jeweiligen Zweck nötig wäre. Hier wurde einfach der User genommen, mit dem das eigentliche Programm für das Datenbank XYZ gedacht ist, arbeitet vermute ich mal. Ist auf jeden Fall eine Anregung die man beim Neuaufsetzen des Ganzen mit berücksichtigen kann, da muss aber der DB-Admin mit ins Boot.
Und man muss sich mal schlau machen, wieweit genau man so Rechte definieren kann, denn Verändern einer Tabelle könnte u.U. schon zuviel Rechte bedeuten, da evtl. nicht alle Felder der Tabelle für diesen neu angelegten User veränderbar sein sollen.

[Sir Rufo]

Wenn du es so richtig schön sicher haben möchtest, dann wirst du um einen Service (Dienst auf einem Server) nicht herumkommen.

Dieser bietet die zur Verfügung stehenden Funktionen an und führt diese aus. Nur dem Service sind die Passwörter bekannt und die Benutzer identifizieren sich einmal an dem Service.

Allerdings ist das etwas/erheblich mehr Aufwand, als mal eben die Kennwörter zu verschlüsseln. Andererseits kann man auch darüber nachdenken aus der gesamten Anwendung einen (Intranet-)Web-Dienst zu machen. Client-Installationen gibt es dann nicht mehr und sicher ist es, weil die Kennwörter nur auf dem Server liegen.

[Perlsau]

Am sichersten wäre es wohl, wenn jene, die die Paßwörter für die EierlegendeWollmillsausoftware (ELWMS) vergeben, diese irgendwo sicher aufbewahrten, zum Beispiel in einer gut geschützten Paßwort-Datenbank, zu der nur dieser kleine erlauchte Kreis selbst Zugang hat, oder in einer schriftlichen Liste im Safe. Irgendwo notieren muß man sich diese Passwörter, wenn es sich nicht um leicht zu merkende Zeichenketten handeln soll.

Im eigentlichen ELWMS bzw. der dazugehörigen Datenbank werden letztlich nur Hash-Strings abgespeichert, die aus Passwort und Benutzername erzeugt werden. Gibt der Anwender dann Benutzername und Paßwort richtig ein, wird daraus wieder derselbe Hash berechnet und in der Tabelle gesucht, ob er dort existiert. Neue Benutzer können dann natürlich nur von diesen wenigen Berechtigten angelegt werden. Hash-Strings können nicht zurückgerechnet werden, so daß aus dem Hash-Wert niemand die einzugebenden Zeichenketten ermitteln kann. Der Hash-Wert selbst nützt dem potentiellen Datendieb auch nichts, denn er muß ja Benutzername und Passwort eingeben, um die Funktionalität des Programms nutzen zu können.

Selbstverständlich solllte der direkte Zugriff auf die Datenbank, z.B. via Datenbank-Manager (IbExpert, SQL Server Manager usw.) ebenfalls gut gesichert sein. Wie das bei den einzelnen DBMS gelöst ist, muß du allerdings selber ermitteln. Firebird z.B. erlaubt keinen echten Schutz der Datenbank-Datei vor fremden Zugriffen, denn jeder, der sich dieser Datei bemächtigen kann, ist in der Lage, diese auf einem eigenen Firebirdserver zu öffnen. Werden ihm Rechte bei der Änderung von Datensätzen und/oder DB-Strukturen verwehrt, kann er das einfach umgehen, indem er ein Backup (fbk) dieser DB-Datei erzeugt und mit selbigem via Restore und eigener Benutzer- und Passwort-Kombination wieder ein FDB-Datei erzeugt, die danach aller Beschränkungen beraubt ist.

[p80286]

u.U. ist eine weitere Möglichkeit, die notwendige Funktionalität über views zu erreichen. Die entsprechenden Zugriffsrechte werden genau hierfür vergeben.

Gruß
K-H

[Jumpy]

Zitat von Sir Rufo:

Wenn du es so richtig schön sicher haben möchtest, dann wirst du um einen Service (Dienst auf einem Server) nicht herumkommen.

Dieser bietet die zur Verfügung stehenden Funktionen an und führt diese aus. Nur dem Service sind die Passwörter bekannt und die Benutzer identifizieren sich einmal an dem Service.

Allerdings ist das etwas/erheblich mehr Aufwand, als mal eben die Kennwörter zu verschlüsseln. Andererseits kann man auch darüber nachdenken aus der gesamten Anwendung einen (Intranet-)Web-Dienst zu machen. Client-Installationen gibt es dann nicht mehr und sicher ist es, weil die Kennwörter nur auf dem Server liegen.

Damit verschiebt man das Problem natürlich auf den Service, sprich wo bekommt der seine Passworte her. Da er aber, wie du sagst, auf dem Server läuft (wo keiner der Normalo-Benutzer dran kommt) könnte man es im Klartext z.B. in einer Ini-Datei speichern, die "Sicherheit" käme daher, das erst gar keiner an die Dateien dran kommt.
Wobei ich vermute, das du meinst man soll trotzdem verschlüsseln usw. und das mit dem Service ist eine weitere zusätzliche Stufe der Sicherheit?

Ist auf jeden Fall ein guter Gedanke, den ich wenn mal Zeit ist, umsetzen werde. Wäre auch eine schöne Übung, da ich einen Webdienst bisher nch nicht erstellt habe. Da das ein rein internes Programm ist, eilt es ja auch nicht.

Zitat von p80286:

u.U. ist eine weitere Möglichkeit, die notwendige Funktionalität über views zu erreichen. Die entsprechenden Zugriffsrechte werden genau hierfür vergeben.

Kann man den mit Views auch Daten verändern? Die bisherige Anwendung "schießt" im Prinzip nur Datenverändernde SQL-Statements ab.

[Jumpy]

Zitat von Perlsau:

Am sichersten wäre es wohl, wenn jene, die die Paßwörter für die EierlegendeWollmillsausoftware (ELWMS) vergeben, diese irgendwo sicher aufbewahrten, zum Beispiel in einer gut geschützten Paßwort-Datenbank, zu der nur dieser kleine erlauchte Kreis selbst Zugang hat, oder in einer schriftlichen Liste im Safe. Irgendwo notieren muß man sich diese Passwörter, wenn es sich nicht um leicht zu merkende Zeichenketten handeln soll.

Im eigentlichen ELWMS bzw. der dazugehörigen Datenbank werden letztlich nur Hash-Strings abgespeichert, die aus Passwort und Benutzername erzeugt werden. Gibt der Anwender dann Benutzername und Paßwort richtig ein, wird daraus wieder derselbe Hash berechnet und in der Tabelle gesucht, ob er dort existiert. Neue Benutzer können dann natürlich nur von diesen wenigen Berechtigten angelegt werden. Hash-Strings können nicht zurückgerechnet werden, so daß aus dem Hash-Wert niemand die einzugebenden Zeichenketten ermitteln kann. Der Hash-Wert selbst nützt dem potentiellen Datendieb auch nichts, denn er muß ja Benutzername und Passwort eingeben, um die Funktionalität des Programms nutzen zu können.

Es geht nicht so um die Passwörter der Benutzer, die das Programm nutzen wollen. Da wird die Authentifizierung über den Domäne-Benutzer gesteuert, d.h. er muss sich am Programm genauso anmelden, wie an der Domäne.
Es geht eher darum, dass das Programm intern "wissen" muss, wie es an die verschiedenen Datenbanken dran kommt, und wie/wo man diese Info sicher speichert. Da wäre aber die Idee deiner Passwort-Datenbank (im Gegensatz z.B. zu einer Ini-Datei) eine Alternative.

Zitat von Perlsau:

Selbstverständlich solllte der direkte Zugriff auf die Datenbank, z.B. via Datenbank-Manager (IbExpert, SQL Server Manager usw.) ebenfalls gut gesichert sein. Wie das bei den einzelnen DBMS gelöst ist, muß du allerdings selber ermitteln. Firebird z.B. erlaubt keinen echten Schutz der Datenbank-Datei vor fremden Zugriffen, denn jeder, der sich dieser Datei bemächtigen kann, ist in der Lage, diese auf einem eigenen Firebirdserver zu öffnen. Werden ihm Rechte bei der Änderung von Datensätzen und/oder DB-Strukturen verwehrt, kann er das einfach umgehen, indem er ein Backup (fbk) dieser DB-Datei erzeugt und mit selbigem via Restore und eigener Benutzer- und Passwort-Kombination wieder ein FDB-Datei erzeugt, die danach aller Beschränkungen beraubt ist.

Die betroffenen Datenbanken (meist Oracle) liegen auf diversen Servern, die afaik abgesichert sind, d.h. da kommt ausser den Admins keiner dran (an das "System" der Datenbank mein ich damit).

[taveuni]

Zitat von Jumpy:

Es geht nicht so um die Passwörter der Benutzer, die das Programm nutzen wollen. Da wird die Authentifizierung über den Domäne-Benutzer gesteuert, d.h. er muss sich am Programm genauso anmelden, wie an der Domäne.

Eben deshalb gibt es nur eine saubere Lösung. Multitier. Wenn Deine Client Anwendung gestartet wird gibt diese dem Server ausschliesslich den angemeldeten Windowsbenutzer für das Login mit. Der Server (Dienst) überprüft dann via Domänenkontroller ob dieser Windowsbenutzer existiert und ob er in einer oder mehreren (AD-) Gruppen ist welche in Deiner Applikation konfiguriert sind. Diese Gruppen- (Rollen) Rechte können dann kumuliert werden. Auf das Login gibt der Server so die Berechtigungen zurück und der Client handelt entsprechend. Auf diesem Weg muss überhaupt kein Passwort gespeichert werden. Weder auf dem Server noch auf dem Client. Weiterer Vorteil: Die Rechte können so in der Firma via AD konfiguriert werden. Kommt ein neuer Mitarbeiter erhält er einfach vom Administrator die benötigten Rechte. Die Client Applikation kann auf jedem Rechner, VM oder was auch immer via Rollout installiert werden. Der Client muss einzig wissen wohin er sich verbinden soll. usw. usw.

[jobo]

Zitat von Jumpy:

Zitat von p80286:

u.U. ist eine weitere Möglichkeit, die notwendige Funktionalität über views zu erreichen. Die entsprechenden Zugriffsrechte werden genau hierfür vergeben.

Kann man den mit Views auch Daten verändern? Die bisherige Anwendung "schießt" im Prinzip nur Datenverändernde SQL-Statements ab.

Ja, das ist (mindestens bei Oracle) kein Problem. Die Logik allein (und wahrscheinlich auch die Fähigkeiten der DB) gebietet allerdings gewisse Grenzen. Aggregate oder Datenmengen ohne PK, berechnete Felder im Detail usw. lassen sich innerhalb eines Views natürlich nicht updaten.

Es gibt bei Oracle noch eine Reihe weiterer Möglichkeiten.

• Rollen (non default) mit Passwort, kombiniert mit einem Login Mechanismus, der die Rollen aktiviert (set role..).
• aktive Schema Änderung (set schema..)
• Database Links
• diverse Kombinationen davon
• DML per Stored Procs, was auch sehr komplexe Updates erlauben würde. (einhergehend mit Revoke DML auf den Tables direkt)

Dennoch kommst du um eine passable Nutzer/Rollenverwaltung nicht herum. Angenommen, ein AD ist verfügbar (Windows Domäne) bietet sich im Falle von mssql auch trusted login an, was glaube ich auch mit Oracle geht (hab ich aber noch nie gemacht)

[Perlsau]

Zitat von Jumpy:

Es geht nicht so um die Passwörter der Benutzer, die das Programm nutzen wollen. Da wird die Authentifizierung über den Domäne-Benutzer gesteuert, d.h. er muss sich am Programm genauso anmelden, wie an der Domäne. Es geht eher darum, dass das Programm intern "wissen" muss, wie es an die verschiedenen Datenbanken dran kommt, und wie/wo man diese Info sicher speichert. Da wäre aber die Idee deiner Passwort-Datenbank (im Gegensatz z.B. zu einer Ini-Datei) eine Alternative.

Die Datenbank, die eurem wollmilcheierlegenden Tool zugrunde liegt, sollte ebenfalls dort liegen, wo nur Admins rankommen. Die Zugriffsdaten für die verschiedenen Datenbanken sind dann verschlüsselt in dieser Tool-Datenbank gespeichert. Der Key zum entschlüsseln dieser Daten liegt ebenfalls auf dem Server, oder auch der Key zum Entschlüsseln des Keys usw. Ein Sicherheitsschloß, das Fingerabdruck, Retina und Sprachmuster prüft, erlaubt nur den Administratoren, den Serverraum zu betreten.

Scherz beiseite, wo ist hier eigentlich das Problem? Das Tool verwaltet Rechte, Passwörter und sonstige Zugangsdaten. Das Tool kann nur von Berechtigten mit der richtigen User-Passwort-Kombination gestartet werden. Werden falsche Zugangsdaten eingegeben, startet das Tool nicht bzw. beendet sich sofort und legt einen Log-Eintrag an. Ich halte das für einfacher als die Domänenverwaltung von Windows zu bemühen. So wäre z.B. auch sichergestellt, daß nicht ein Unbefugter das Tool startet, während der Domänen-Besitzer gerade auf der Toilette ist – der sollte natürlich vor dem Klogang stets das Tool sperren oder beenden.

[jobo]

Zitat von Perlsau:

der sollte natürlich vor dem Klogang stets das Tool sperren oder beenden.

Das übliche Verfahren ist wohl, den gesamten Rechner zu sperren, wenn man den Arbeitsplatz verlässt. Das geht auch konform mit der Trusted Login Nutzung. Müsste man jedes Tool einzeln sperren, ist ja die Pause rum, bis man mit Sperren fertig ist.