Passwort im Klartext

[michaelmeier]

Moin zusammen,

bei vielen verteilten Applikationen (hier: Applikationen, bei denen Programmlogik und Datenhaltung auf verschiedenen Servern liegen) findet sich an diversen Stellen das für eine Datenübertragung zwischen Logig und Datenhaltung notwendige Login im Klartext in Konfigurationsdateien.

Gibt es eigentlich eine Möglichkeit, dies zu umgehen? Denn: in den meisten Fällen benötigt man dann ja nur diese Dateien, um von anderen Servern aus entsprechende Logins zu realisieren.

Klar kann man die Dateien entsprechend absichern, aber der Zugriff ist (oft) noch immer möglich. Beispiel sei die Kommunikation zwischen einem PHP-Skript und einer Datenbank. Haben mehr Menschen außer mir die entsprechende Berechtigung das File zu lesen (z.B. root bei vservern oder so), dann war's das mit "vertraulichen" Infos in der Datenbank.

Any ideas?

[ninetyone]

Das passwort einfach verschlüsselt eintragen? MD5 wäre eine möglichkeit.

Dann bei jedem login das "echte" passwort in einen MD5 Hash umwandeln und schaun ob dieser passt.. Wäre jetz meine Idee gewesen..

//sorry falls das nicht gerade die beste möglichkeit ist aber ich bin noch ein frischling^^

[PieDie]

Das passwort einfach verschlüsselt eintragen? MD5 wäre eine möglichkeit.

Dann bei jedem login das "echte" passwort in einen MD5 Hash umwandeln und schaun ob dieser passt.. Wäre jetz meine Idee gewesen..

Ein MD5-Hash in der Konfigurationsdatei? Das würde bedeuten, dass über den Hash nochmals gehasht wird (wenn das Passwort als solcher in der DB liegt), und da kommt dann natürlich Grütze raus.

@michaelmeier:

Wenn jemand Zugang zum root-Benutzer hat, sollte der schon einen verdammt guten Grund dafür haben. Und dann sollte ebendem auch bekannt sein, dass er verpflichtet ist, die Daten vertraulich zu behandeln.

[michaelmeier]

Wenn jemand Zugang zum root-Benutzer hat, sollte der schon einen verdammt guten Grund dafür haben. Und dann sollte ebendem auch bekannt sein, dass er verpflichtet ist, die Daten vertraulich zu behandeln

Ja, sicher. Aber Du weißt doch, wie das in der Systembetreuung ist. Da haben diverse Leute plötzlich Zugriff auf die Systeme zwecks Betreuung. Und sich da ausschließlich auf die Vertraulichkeit der Daten und die entsprechende Regelung im Arbeitsvertrag zu verlassen ist etwas arg dürftig. Ich hätte da lieber etwas handfestes.

MD5 wäre eine möglichkeit

Naja, klar kann ich davon nen MD5-hash erzeugen. Sicher. Den könnte ich dann übertragen und auf die entsprechenden password-Funktionen verzichten, damit ich die md5-hashes vergleichen kann. aber mal ehrlich: wo ist dann der unterschied? dann hätte ich ja wieder den klartext bzw. genau die Infos, die ich für den Login brauche.

[Guybrush Threepwood]

Wenn der Server bzw. die Anwendung sich automatisch authentifizieren soll dann braucht er auch das Passwort (oder was auch immer zur Authentifizierung verwendet wird), die einzige Möglichkeit das zu umgehen ist das Passwort immer vom Benutzer eingeben zu lassen.

[ninetyone]

Wenn der Server bzw. die Anwendung sich automatisch authentifizieren soll dann braucht er auch das Passwort (oder was auch immer zur Authentifizierung verwendet wird), die einzige Möglichkeit das zu umgehen ist das Passwort immer vom Benutzer eingeben zu lassen.

Davon bin ich ausgegangen, das ein Benutzer ein PW eingeben muss...

[geloescht_JesterDay]

Ja, sicher. Aber Du weißt doch, wie das in der Systembetreuung ist. Da haben diverse Leute plötzlich Zugriff auf die Systeme zwecks Betreuung.

Naja, dann musst du das System eben so aufbauen, dass auf die entscheidenden Server nur die Leute drauf dürfen mit root rechten, die das müssen.

Für alle anderen aufgaben die Skripte o.ä. erledigen sollen werden neue Benutzer angelegt auf den Servern, und die dürfen nur das (sehen) was sie unbedingt brauchen.

Bei deinem php-DB Beispiel ja genauso. Da legst du für jede Anwendung eine DB an und einen Benutzer. Der Benutzer (der im Skript steht) darf dann nur das was er braucht, und nur für diese DB (Lesen, evtl. Schreiben, aber kein Create, Drop o.ä.)

Wenn jeder alles darf, ist das sowieso schonmal ein Problem.

[Crash2001]

Bei lokal hinterlegten Klartextdaten besteht immer das Problem, dass jeder User, der physischen Zugriff auf den PC hat, auf dem diese hinterlegt sind rein theoretisch dran kommen kann. Daher sollte das auch möglichst vermieden werden.

Verbindungen übers Netzwerk sollten möglichst verschlüsselt werden und mit Zertifikaten abgesichert werden. Ich verwende für die SSH-Verbindung zu meinem Root-Server z.B. ein Zertifikat, das auf einem USB-Stick gespeichert ist. Somit ist die Verbindung verschlüsselt und nur mit meiner private-key-Datei kann man sich per remote dort einloggen.

Lokal sind alle Benutzer von mir eingerichtet und nur ich habe die Passwörter.

Die einzige Möglichkeit, an meine Daten zu kommen wäre also, wenn jemand meinen privaten SChlüssel klauen würde (dann bräuchte er aber immer noch zwei Passwörter, um Root-Rechte zu erhalten - meines und das vom root), lokalen Zugriff hat und das root-Passwort kennt, oder aber die Festplatte ausbaut.

Das Passwort der Datenbank ist ein "starkes" Passwort und zum Zugriff auf PHPMyAdmin braucht man noch ein anderes Passwort, da das Verzeichnis in dem PHPMyAdmin liegt geschützt ist durch den Apache. Das Passwort dafür liegt dort nicht in Klartext, sondern verschlüsselt vor.

Direkt mit root-rechten auf einen Server verbinden sollte man eh unterbinden. Immer nur Verbindungen mit usern erlauben und diese müssen sich dann noch einmal als root identifizieren, bevor sie root-Rechte erlangen. So werden mindestens 2 Passwörter gebraucht.

Hier mal eine kleine Richtlinie (ohne Anspruch auf Vollständigkeit natürlich):

• Keine Passwörter im Klartext speichern, sondern mit hashes oder verschlüsselten Daten arbeiten (Truecrypt bietet sich da z.B. auch an, wenn denn ein Programm ein Passwort unbedingt im Klartext hinterlegt haben will).
  
• Verbindungen wenn möglich verschlüsseln
  
• Digitale Zertifikate wo möglich zur Autentifizierung verwenden.
  
• Rechte konservativ vergeben.
  
• Passwörter sicher lagern und die User auch dazu anhalten (also z.B. nicht wie das gerne gemacht wird, Zettel an den Monitor oder unter die Tastatur).
  
• Passwortrichtlinien festlegen, dass schwache Passwörter nicht verwendet werden können
  
• den Zugriff, falls möglich, auf bestimmte PCs begrenzen (Access-Listen)
  
• den Zugang zu berechtigten PCs begrenzen und Zugangskontrollen einführen
  
• beim entfernen vom Rechner sich immer ausloggen oder den Bildschirm sperren (Windowstaste+L unter Windows)
  
• Passwörter in regelmässigen Abständen, sowie falls eines bekannt geworden sein könnte, austauschen
  
• aktuelle Versionen der verwendeten Software verwenden und Sicherheitspatche einspielen.
  
• Logdateien analysieren auf unerlaubte Zugriffe
  
• möglichst nicht die Standardports für Anwendungen verwenden, wo man dies umstellen kann (SSH, SQL, (S)FTP, ...)
  
• ...

[michaelmeier]

Naja, dann musst du das System eben so aufbauen, dass auf die entscheidenden Server nur die Leute drauf dürfen mit root rechten, die das müssen.

Für alle anderen aufgaben die Skripte o.ä. erledigen sollen werden neue Benutzer angelegt auf den Servern, und die dürfen nur das (sehen) was sie unbedingt brauchen.

Bei deinem php-DB Beispiel ja genauso. Da legst du für jede Anwendung eine DB an und einen Benutzer. Der Benutzer (der im Skript steht) darf dann nur das was er braucht, und nur für diese DB (Lesen, evtl. Schreiben, aber kein Create, Drop o.ä.)

Wenn jeder alles darf, ist das sowieso schonmal ein Problem.

Na, das ist ja arg platt formuliert. Aber natürlich habt mehr als eine Person (notwendiger Weise) den root-Account. Darüber hinaus haben natürlich auch mehrere User den Account unter dem (in diesem Beispiel) die Skripte gestrickt wurden. Etwas, was sich bei Teams > 1 Person kaum vermeiden läßt.

Aber es geht ja auch nicht um den Zugriff auf diese Datei. Es geht darum, diesen ganzen Batchvorgang so umzustricken, dass das Hinterlegen von Passwörtern in Batchskripten/Konfigurationsdateien/whatever nicht mehr erforderlich ist. Darum (und nur darum) geht es. Ob es dafür (mitlerweile) neue Strukturen / Verfahren gibt.

[michaelmeier]

@Crash: vielen Dank für deine ausführliche Antwort. Aber ich glaube, wir reden da aneinander vorbei.

Bei lokal hinterlegten Klartextdaten besteht immer das Problem, dass jeder User, der physischen Zugriff auf den PC hat, auf dem diese hinterlegt sind rein theoretisch dran kommen kann. Daher sollte das auch möglichst vermieden werden.

Das ist klar, aber in den meisten Fällen nicht zu ändern.

Verbindungen übers Netzwerk sollten möglichst verschlüsselt werden und mit Zertifikaten abgesichert werden. Ich verwende für die SSH-Verbindung zu meinem Root-Server z.B. ein Zertifikat, das auf einem USB-Stick gespeichert ist. Somit ist die Verbindung verschlüsselt und nur mit meiner private-key-Datei kann man sich per remote dort einloggen.

Jupp - Standardverfahren für SSH. Trifft hier aber nicht zu.

Lokal sind alle Benutzer von mir eingerichtet und nur ich habe die Passwörter.

Die einzige Möglichkeit, an meine Daten zu kommen wäre also, wenn jemand meinen privaten SChlüssel klauen würde (dann bräuchte er aber immer noch zwei Passwörter, um Root-Rechte zu erhalten - meines und das vom root), lokalen Zugriff hat und das root-Passwort kennt, oder aber die Festplatte ausbaut.

Lokale User. Ein Admin. Full ack. Ebenfalls hier nicht zutreffend.

Das Passwort der Datenbank ist ein "starkes" Passwort und zum Zugriff auf PHPMyAdmin braucht man noch ein anderes Passwort, da das Verzeichnis in dem PHPMyAdmin liegt geschützt ist durch den Apache. Das Passwort dafür liegt dort nicht in Klartext, sondern verschlüsselt vor.

Trennen wir uns mal von PHP. War nur das einzige Beispiel, das mir spontan einfiel, womit die meisten was anfangen können.

Oder kennt jemand zufällig Basware?

Nein, es geht im allgemeinen um das Problem, das bei Trennung von Datenlogik und Datenhaltung auf getrennte Maschinen normalerweise immer irgendwo eine konfig-Datei mit Passwort im Klartext rumliegt. Das soll vermieden werden.

Direkt mit root-rechten auf einen Server verbinden sollte man eh unterbinden. Immer nur Verbindungen mit usern erlauben und diese müssen sich dann noch einmal als root identifizieren, bevor sie root-Rechte erlangen. So werden mindestens 2 Passwörter gebraucht.

Ebenfalls full ack, ebenfalls nicht zutreffend.

Hier mal eine kleine Richtlinie (ohne Anspruch auf Vollständigkeit natürlich):

• [*]Keine Passwörter im Klartext speichern, sondern mit hashes oder verschlüsselten Daten arbeiten (Truecrypt bietet sich da z.B. auch an, wenn denn ein Programm ein Passwort unbedingt im Klartext hinterlegt haben will).

Je weiter ich lese, desto eher glaube ich, das wir aneinander vorbei reden. Die Logik auf Server A braucht eine Möglichkeit, die Datenhaltung auf Server B zu erreichen. Ich muss für die Verbindung ein Passwort nutzen. Wie schaffe ich es, dass das, was auf dem Server A in einer Konfigurationsdatei abgelegt ist, nicht das zum Login bei der Datenhaltung erforderliche Passwort ist???

[*]Verbindungen wenn möglich verschlüsseln

[*]Digitale Zertifikate wo möglich zur Autentifizierung verwenden.

[*]Rechte konservativ vergeben.

ja, alles Standard, Überall fullack.

[*]Passwörter sicher lagern und die User auch dazu anhalten (also z.B. nicht wie das gerne gemacht wird, Zettel an den Monitor oder unter die Tastatur).

Und da kommen wir zum entscheidenden Punkt. Die Lagerung des Passwortes in einer Konfigurationsdatei ist ziemlich unschön. Wie kann ich das verhindern???

Und beim Rest: full ack, allerdings alles hier nicht zutreffend.

Wie gesagt - vielen Dank für Dein ausführliches Posting, allerdings reden wir hier aneinander vorbei. Es geht hier nicht um Serverabsicherung für Einsteiger, sondern es geht hier um ein Grundsätzliches Problem bei verteilten Anwendungen. Ich bin mir nichtmal sicher, ob es zu dem Verfahren ernsthaft eine Alternative gibt. Daher frage ich spontan mal so in die Runde, ob ihr vielleicht was wisst.

Nochmals thx a lot @Crash.

Bearbeitet 13. Juni 2008 von michaelmeier

[geloescht_JesterDay]

Und da kommen wir zum entscheidenden Punkt. Die Lagerung des Passwortes in einer Konfigurationsdatei ist ziemlich unschön. Wie kann ich das verhindern???

Je nach DB-Systen (wenn wir von einer DB ausgehen für die Datenhaltung) gar nicht. Für einen Zugriff auf die Daten brauchst du eine Anmeldung, ist halt so. Und bei Skripten ist es auch relativ einfach die zugriffsmethode auszulesen, selbst wenn du die Zugangsdaten verschlüsselt irgendwo ablegst.

eine Idee ist noch, den Zugang für den DB-Zugriff auf eine Rechner zu beschränken. Bei MySQL (andere DBMS ja wohl auch) kannst du für jeden User noch angeben, von welcher Adresse aus er Zugreifen darf.

Es ist nunmal so, dass ein entferntet Zugriff eine authentifizierung braucht. Die musst du irgendwo ablegen. Wenn das nicht interaktiv geschieht musst du auch evtl. ein Passwort irgendwo hinterlegen. dieses Passwort kannst du natürlich auch irgendwo geschützt ablegen, nur auch das muss ja wieder irgendwo hinterlegt sein. Bei vielen Usern mit Zugriff darauf kannst du gar nicht verhindern, dass da niemand rankommt. Du kannst das nur soweit es geht einschränken.

Z.B. dass sich an der DB nur ein Rechner anmelden kann, bzw der User nur von einer IP-Adresse. Oder aber du legst diese Applikationen auf einem Server ab, der nur von einer einzigen Person benutzt werden kann. Also dein "App-Server" hat eben keine Erlaubnis für alle möglichen Leute aus der IT-Abteilung.

Wenn dennoch viele ein Skript aufrufen müssen kannst du diesen aufruf ja veröffentlichen, aber eben auch restriktiv. Z.b. ein Skript auf einem Server der für alle zugänglich ist, dieses Skript meldet sich, per private key, über ssh am App-Server an mit einem User mit ganz eingeschränkten Rechten und führt dort das eigentliche Skript aus. die ausgabe sieht ja der aufrufende User, kann aber sonst nichts tun. Datenabfragen kannst du so ähnlich machen.

Mag sein dass das platt formuliert ist, aber es gibt nunmal keine andere möglichkeit einen Zugriff zu automatisieren, ohne irgendwo etwas zu hinterlegen. Deswegen sollte der Benutzer der mit dem hinterlegten Zugriff benutzt wird eben kein root o.ä. sein.

Bei meinem letzten AG hatte erstmal auch die IT Vollzugriff auf alle Server (natürlich auch nicht überall Admin-Zugriff, aber halt auch auf Servern woanders Schreibzugriff auf einige Bereiche), die gesamte IT. Das wurde dann später geändert, dass nur die Netzwerkabteilung Zugriff hatte und der Rest (softwareentwicklung) eben zur Not zu denen musste wenn da was auf nen Server musste o.ä.

Am Ende wurde auch das eingeschränkt, mit den neuen Servern, und nur die beiden Abteilungsleiter hatten Vollzugriff, die anderen Mitarbeiter bei den Netzwerkern hatten einen eingeschränkten Zugriff und konnten selbst nicht mehr alles. Die waren natürlich auch nicht immer glücklich darüber, aber so ist das eben wenn du dir um die Sicherheit deines Netzes Gedanken machst.

Bearbeitet 13. Juni 2008 von JesterDay

[michaelmeier]

Je nach DB-Systen (wenn wir von einer DB ausgehen für die Datenhaltung) gar nicht. Für einen Zugriff auf die Daten brauchst du eine Anmeldung, ist halt so. Und bei Skripten ist es auch relativ einfach die zugriffsmethode auszulesen, selbst wenn du die Zugangsdaten verschlüsselt irgendwo ablegst.

Ack. Das ist ja der aktuelle Stand und Hintergrund meiner Frage.

eine Idee ist noch, den Zugang für den DB-Zugriff auf eine Rechner zu beschränken. Bei MySQL (andere DBMS ja wohl auch) kannst du für jeden User noch angeben, von welcher Adresse aus er Zugreifen darf.

Prinzipiell: ja.

Es ist nunmal so, dass ein entferntet Zugriff eine authentifizierung braucht. Die musst du irgendwo ablegen. Wenn das nicht interaktiv geschieht musst du auch evtl. ein Passwort irgendwo hinterlegen. dieses Passwort kannst du natürlich auch irgendwo geschützt ablegen, nur auch das muss ja wieder irgendwo hinterlegt sein. Bei vielen Usern mit Zugriff darauf kannst du gar nicht verhindern, dass da niemand rankommt. Du kannst das nur soweit es geht einschränken.

Jupp - ich befürchte es.

Z.B. dass sich an der DB nur ein Rechner anmelden kann, bzw der User nur von einer IP-Adresse. Oder aber du legst diese Applikationen auf einem Server ab, der nur von einer einzigen Person benutzt werden kann. Also dein "App-Server" hat eben keine Erlaubnis für alle möglichen Leute aus der IT-Abteilung.

Wenn dennoch viele ein Skript aufrufen müssen kannst du diesen aufruf ja veröffentlichen, aber eben auch restriktiv. Z.b. ein Skript auf einem Server der für alle zugänglich ist, dieses Skript meldet sich, per private key, über ssh am App-Server an mit einem User mit ganz eingeschränkten Rechten und führt dort das eigentliche Skript aus. die ausgabe sieht ja der aufrufende User, kann aber sonst nichts tun. Datenabfragen kannst du so ähnlich machen.

Ja, darüber habe ich auch schon nachgedacht. Identity-Files hinterlegen, Verbindungsaufbau per SSH mittels I-File und dann auf der anderen Maschine die Befehle absetzen. Dumm nur: natürlich darf sich der technische User nicht an der anderen Maschine anmelden wg. Sicherheitsrisiko. Da gehts dann nur per sudo.

Mag sein dass das platt formuliert ist, aber es gibt nunmal keine andere möglichkeit einen Zugriff zu automatisieren, ohne irgendwo etwas zu hinterlegen. Deswegen sollte der Benutzer der mit dem hinterlegten Zugriff benutzt wird eben kein root o.ä. sein.

Na, nen root ist es natürlich nicht. Aber eben (notwendiger Weise) ein User mit Schreibrechten in den entsprechenden Schemata. Schliesslich soll er ja inserts und updates auf der Datenbank fahren.

Wie gesagt: das war meine Befürchtung. Eigentlich traurig, oder? Tausende von Authentifizierungsverfahren aber da wurde noch nix neues gebaut. Ein Trauerspiel.

Bei meinem letzten AG hatte erstmal auch die IT Vollzugriff auf alle Server (natürlich auch nicht überall Admin-Zugriff, aber halt auch auf Servern woanders Schreibzugriff auf einige Bereiche), die gesamte IT. Das wurde dann später geändert, dass nur die Netzwerkabteilung Zugriff hatte und der Rest (softwareentwicklung) eben zur Not zu denen musste wenn da was auf nen Server musste o.ä.

Am Ende wurde auch das eingeschränkt, mit den neuen Servern, und nur die beiden Abteilungsleiter hatten Vollzugriff, die anderen Mitarbeiter bei den Netzwerkern hatten einen eingeschränkten Zugriff und konnten selbst nicht mehr alles. Die waren natürlich auch nicht immer glücklich darüber, aber so ist das eben wenn du dir um die Sicherheit deines Netzes Gedanken machst.

Ja, das ist ja das Standardverfahren. Aber es geht dann eher um organisatorische Fragen im Umgang mit der Serverinfrastruktur und schränkt das Problem auch nur auf eine kleinere Gruppe ein. Je nach Unternehmen(sgröße) kann dieser Kreis aber natürlich auch schnell mal 20 Mann umfassen. Und egal wie ich es drehe und wende, solange die Zahl > 1 ist habe ich da einfach ein Problem.

Mit anderen Worten: gibt derzeit nix anderes. Schade. Muss man sich mal Gedanken machen. Ich behaupte: da kann man so manchen Euro mit verdienen.

Also auf liebe Fi-ler... super Projektthema für die nächste Runde.

Lösungen bzw. Implementierungsvorschläge bitte CC an mich.

Wieder ernsthaft: da muss man sich wirklich mal Gedanken machen. Trauerspiele dieser Art müssen (finde ich zumindest) nicht sein.

Btw: Wie siehts denn in dem Umfeld mit Kerberos-Authentifizierung o.ä. in dem Umfeld aus? Dann wäre ich immerhin das Problem los, dass da Daten im Klartext in einem Konfigfile liegen. Gibt zwar schöne neue Probleme, aber Schritt 1 wäre doch damit behoben, oder nicht?

Ich muss da mal drüber nachdenken. Dumm nur: während der EM werde ich da wohl kaum dazu kommen. Und bis danach habe ich es sicherlich wieder vergessen.

Thx @ all für die rege Beteiligung und Anregung!

[Crash2001]

Also wenn du bei der Anwendung einen Pfad für das Config-File angeben kannst, kannst du es ja in einem mit Truecrypt verschlüsselten Laufwerk bereit stellen. Somit müsste ein eventueller Eindringling erst einmal das Passwort davon haben, um Zugriff zu bekommen. Dafür muss der normale User natürlich jedesmal das File erst noch mounten, bevor er mit dem Programm Zugriff hat.

Die Frage die sich mir stellt ist aber folgende: Willst du verhindern, dass interne User Mist bauen, oder willst du den Fall verhindern, dass jemand, der da nichts zu suchen hat, Zugriff erhält?

Existieren für jeden User in der Datenbank einzelne User, oder gibt es da nur Gruppenaccounts, die mehrere User sich teilen? Zumindest die Insert/Update/drop-Rechte u.s.w. sollten wirklich nur die User haben, die sie auch wirklich benötigen.

[geloescht_JesterDay]

Btw: Wie siehts denn in dem Umfeld mit Kerberos-Authentifizierung o.ä. in dem Umfeld aus? Dann wäre ich immerhin das Problem los, dass da Daten im Klartext in einem Konfigfile liegen.

Hmm...

Um den Kerberos-Dienst nutzen zu können, muss sich ein Client zuerst beim Kerberos-Server anmelden. Er fordert vom Kerberos-Server ein sog. Ticket Granting Ticket (TGT) an. Hierzu muss der Nutzer des Clients entweder ein Passwort eingeben oder das TGT wird direkt bei der Benutzeranmeldung angefordert.

Wie willst du dich denn da durch ein Skript anmelden, ohne die Daten irgendwo hinterlegt zu haben? die nutzung von digitalen Zertifikaten ohne Passwort ist ja wie ein Private Key ohne Passwort, bringt also auch nicht viel wenn das jeder (der Zugriff hat) Auslesen kann.

Ich wüsste schon vom Ansatz her keine Idee wie man das (automatische Anmeldung durch ein Skript) denn ohne irgendwo hinterlegtes PW machen sollte. Oder hast du da eine Vorstellung? Ja, so ein Zertifikat bzw ein PK ist ja eine Idee, nur kann den ja jeder mit Zugriff auf den Server kopieren und auch nutzen für eine Anmeldung, also keine Lösung.

[geloescht_JesterDay]

Also wenn du bei der Anwendung einen Pfad für das Config-File angeben kannst, kannst du es ja in einem mit Truecrypt verschlüsselten Laufwerk bereit stellen. Somit müsste ein eventueller Eindringling erst einmal das Passwort davon haben, um Zugriff zu bekommen. Dafür muss der normale User natürlich jedesmal das File erst noch mounten, bevor er mit dem Programm Zugriff hat.

Das Skript müsste das aber auch können (oder der TC-Container ist schon gemountet, und das ständig), und da ein Skript meist plaint/text ist ist die Schwierigkeit das TC-PW zu bekommen auch nur 1%% größer als direkt in der Config-Datei

[michaelmeier]

Also wenn du bei der Anwendung einen Pfad für das Config-File angeben kannst, kannst du es ja in einem mit Truecrypt verschlüsselten Laufwerk bereit stellen. Somit müsste ein eventueller Eindringling erst einmal das Passwort davon haben, um Zugriff zu bekommen. Dafür muss der normale User natürlich jedesmal das File erst noch mounten, bevor er mit dem Programm Zugriff hat.

Die Frage die sich mir stellt ist aber folgende: Willst du verhindern, dass interne User Mist bauen, oder willst du den Fall verhindern, dass jemand, der da nichts zu suchen hat, Zugriff erhält?

Existieren für jeden User in der Datenbank einzelne User, oder gibt es da nur Gruppenaccounts, die mehrere User sich teilen? Zumindest die Insert/Update/drop-Rechte u.s.w. sollten wirklich nur die User haben, die sie auch wirklich benötigen.

jupp - mit nem passwort in dem batchskript, dass den container mountet.

die katze beißt sich da schön watt in den schwanz.

bzgl. der datenbank: ich will verhindern, dass interne user mist bauen. dass jemand abteilungsfremdes überhaupt auf server a (der mit dem batchfile inkl. Passwort) kommt - nee, das wird schon unterbunden.

[michaelmeier]

Hmm...

Wie willst du dich denn da durch ein Skript anmelden, ohne die Daten irgendwo hinterlegt zu haben? die nutzung von digitalen Zertifikaten ohne Passwort ist ja wie ein Private Key ohne Passwort, bringt also auch nicht viel wenn das jeder (der Zugriff hat) Auslesen kann.

Ich wüsste schon vom Ansatz her keine Idee wie man das (automatische Anmeldung durch ein Skript) denn ohne irgendwo hinterlegtes PW machen sollte. Oder hast du da eine Vorstellung? Ja, so ein Zertifikat bzw ein PK ist ja eine Idee, nur kann den ja jeder mit Zugriff auf den Server kopieren und auch nutzen für eine Anmeldung, also keine Lösung.

Ich dachte da eher an SingleSignOn.

Einmal angemeldet, alles pocco.

Nein?

[Guybrush Threepwood]

Um was für einen Server und DB System handelt es sich eigentlich?

Unter Windows und MS SQL Server kannst du ja im SQL Server direkt die Benutzer aus deinem Active Directory mit entsprechenden (eigeschränkten) Rechten anlegen und dann als authentifizierungsmethode Integrated Security auswählen. Dann versucht das System automatisch mit dem Benutzeraccount der im Betriebssystem angemeldet ist zu authentifizieren.

Das sollte bei anderen System ja eigentlich auch ähnlich funktionieren...

[geloescht_JesterDay]

Ich dachte da eher an SingleSignOn.

Einmal angemeldet, alles pocco.

Nein?

Schon, nur was machst du bei einem Stromausfall, Serverneustart o.ä.?

Und dann müssen die Clients (Skripte, DB-Treiber o.ä.) das auch noch unterstützen...

[geloescht_JesterDay]

Dann versucht das System automatisch mit dem Benutzeraccount der im Betriebssystem angemeldet ist zu authentifizieren.

Das bringt ihm das ja nichts. Angenommen IT-Mitarbeiter X meldet sich am Server an und startet das Skript, dann wird versucht mit der Anmeldung X sich am System zu authentifizieren. Und es geht ja darum, dass nicht jeder der sich da anmeldet (und das Skript startet oder das Skript bzw die Config lesen kann) auf die DB einen Zugriff hat.

[Crash2001]

Das Skript müsste das aber auch können (oder der TC-Container ist schon gemountet, und das ständig), und da ein Skript meist plaint/text ist ist die Schwierigkeit das TC-PW zu bekommen auch nur 1%% größer als direkt in der Config-Datei

Neneee, also schon wenn man sich einloggt so, dass man noch das Passwort für den Container manuell eingeben muss - nicht scriptgesteuert oder automatisch geladen und Passwort gespeichert. Das würde das ja sonst ad absurdum führen...

@michaelmeier:

Wird denn immer das gleiche da gemacht (also immer die selben SQL(?)-Querries), oder wird immer etwas anderes gemacht?

Wenn immer das gleiche gemacht wird, kann man ja ein Script für basteln, das einfach gestartet wird. Wenn es hingegen immer etwas anderes ist, was auch joins, updates u.s.w. enthält, dann wäre es eigentlich Schwachsinn, das in ein Script auszugliedern, da man dann statt direkt auf der DB man mit dem Script alles machen könnte...

Bearbeitet 13. Juni 2008 von Crash2001

[geloescht_JesterDay]

Neneee, also schon wenn man sich einloggt so, dass man noch das Passwort für den Container manuell eingeben muss - nicht scriptgesteuert oder automatisch geladen und Passwort gespeichert. Das würde das ja sonst ad absurdum führen...

Ja, eben. Also ich versteh das Problem des OP so, dass er auf verschiedenen Servern Skripte u.ä. hat, die ihrerseits wieder auf andere, z.B. DB-Server zugreifen. Für diese Zugriffe muss er irgendwo Passwörter hinterlegen, so dass sich das Skript authentisieren kann. Und genau diese PWs kann jeder auslesen, der Zugriff auf den Rechner hat, und das sind halt schon ein paar Leute, in der IT-Abteilung. (Dieses "Problem" hatte ich auch früher öfter)

Er will aber nicht, dass alle diese Leute dadurch theoretisch auch Zugriff auf die DB z.B. bekommen.

Also entweder verstehe ich das falsch, oder du, oder ich verstehe deine TC Lösung falsch.

[michaelmeier]

Es geht (in diesem Konkreten Fall) um ein Modul zum scannen und automatischen Verbuchen von Rechnungen.

Hierbei hat der Anwender den Client installiert und scannt bei sich die Rechnungen. Diese werden im neuen Format mit sämtlichen Daten an den Applikationsserver übergeben. Der Applikationsserver wiederum schreibt die Daten zum einen in die Datenbank, zum anderen nimmt er automatisch die entsprechenden Buchungen in SAP vor.

Für die Verbindung zur Datenbank sind entsprechende Konfigurationsdateien hinterlegt. Hierbei ist aber die Datenbank weniger interessant - diese dient (hauptsächlich) zur Aufbewahrung der Rechnungen sowie zur Vorhaltung von Steuerinformationen (hier im Sinne von: wer hat was wann mit welcher Belegnummer gebucht, ...). Der interessante Teil ist die Weiterleitung und Verbuchung in Richtung SAP. Hierfür sind ebenfalls entsprechende Konfigurationsdateien inkl. Passwort angelegt.

Für den Austausch zwischen dem Applikationsserver und SAP gibt es einen Scheduler, der die Jobs (und diverse weitere zwecks Kreditorenabgleich etc) regelmäßig antriggert.

Soweit, so gut. Bzw. so unschön. Kurz formuliert: auf dem Applikationsserver liegen Benutzerdaten für SAP vor, welche schön was buchen dürfen. Natürlich hat nur ein kleiner Kreis Zugriff auf den Applikationsserver (sowohl für den technischen Applikationsuser als auch für den administrativen Account), aber jeder dieser User kann - sofern er es drauf anlegt - die entsprechenden Logindaten rausfischen.

Natürlich kann sich der SAP-User nicht direkt via Gui Anmelden (kein Dialog-User), allerdings kann man nun natürlich entsprechende Bapis stricken und in Richtung SAP feuern. Sehr unschön.

Daher meine Frage: gibt es für solche Settings auch Möglichkeiten, ohne Passwörter in Konfigurationsdateien auszukommen?

[geloescht_JesterDay]

auf dem Applikationsserver liegen Benutzerdaten für SAP vor, welche schön was buchen dürfen. Natürlich hat nur ein kleiner Kreis Zugriff auf den Applikationsserver (sowohl für den technischen Applikationsuser als auch für den administrativen Account), aber jeder dieser User kann - sofern er es drauf anlegt - die entsprechenden Logindaten rausfischen.

Unter welchem System läuft der AppServer denn? Und wieviele Nutzer brauchen denn wirklich administrativen Zugang?

Ob es eine andere Möglichkeit gibt an SAP anzumelden, keine Ahnung (keine Ahnung von SAP). Aber du könntest den admin. Zugang schonmal auf den allernötigsten Kreis einschränken. Das war bei uns ja damals auch so. Auf die eigentlichen Server hatten nur die 2 Abteilungsleiter admin. Zugang. Wenn das keine Zeitkritische anwendung ist die auch mal kurze Zeit stillstehen kann zur Not, dann solltest du das auch so machen. Bei uns war es auch so, dass u.U. keiner der beiden da war, und dann musste eben etwas warten. Unschön für alle anderen, aber kein Weltuntergang. Irgendwann am Tag (oder Nacht) kamen die schon, zur Not über VPN.

Also Zugangsdaten nur für Admin und den User, unter dem die App läuft lesbar. Wobei ja nichtmal für den Admin, der kann sich dann halt nur die nötigen Rechte holen im Zweifel, aber das fällt ja auch auf.

ansonsten ist das ja eher wie das Henne/Ei-Problem. Du willst keine Zugangsdaten in irgendwelcher Art hinterlegen, aber gleichzweitig muss sich für einen zugriff irgendwie authentisiert werden. Egal wie du das machst, außer durch solche "externen Maßnahmen" kann diese Daten jeder rausfischen, abfangen was auch immer, der Zugsng hat. Mit externe Maßnahmen meine ich z.B. Zugriffsbeschränkung auf die Daten, Zugriff nur über eine IP u.ä., also die mit den Zugangsdaten direkt nichts zu tun haben.

* Zugang über Public/Private-Key: Den kann man rausfischen und ein PW dafür muss auch irgendwo abgelegt werden.

* Zugang über ldap: die ldap-anmeldedaten müssen auch irgendwo hinterlegt sein oder könnten von jemand irgendwie bekommen.

* Zugangsdaten verschlüsselt ablegen: Um da ran zu kommen müssen die entschlüsselbar sein - kann man auch rankommen

* einmalige Kerberos-Anmeldung: Diese Daten reichen auch, wenn sie jemand hat.

Also ok, das ist alles schon schwieriger als einfach eine Textdatei auszulesen... hm... habt ihr eigentlich kein Controlling, was die Buchungen prüft?

Falsche Buchungen sollten doch sehr schnell jemand auffallen.

Bearbeitet 17. Juni 2008 von JesterDay

[another1]

hi,

geht es hier eigentlich um das generelle Problem der automatischen Authentifizierung oder speziell um Basware?

Ich kenne Basware zwar nicht - allerdings sollte doch mit RTFM heraus zu finden sein, welche Authentifizierungsmöglichkeiten das entsprechende Stück SW am Zielrechner akzeptiert?!

Daraus ergeben sich die weiteren Schritte - die ganzen gut gemeinten

Ratschläge bleiben nur gut gemeint, wenn diese für Basware nicht möglich sind.

Noch ein anderer Aspekt:

Generell muß ich anmerken, dass in einem größerem Unternehmen

mit mehreren Admins bestimmte Probleme nur organisatorisch praxisgerecht

und unkompliziert gehalten werden können. Mir fällt hier das immer wiederkehrende Argument der Entscheidungsträger ein "Jeder muß im Vertretungsfall das können was die anderen auch können".

Aber nochmals zurück zum Thema Zugriff von Admins auf vertrauliche Daten: In den meisten Fällen wird im Arbeitnehmervertrag beim Eintritt immer eine Datenschutzklausel mit unterschrieben.

Sollte eine Datenumgebung wirklich so vertraulich sein, so muß

"von oben" eine entsprechende Arbeitsanweisung, Bildung einer entsprechenden high-confidential Umgebung und Auswahl der Zuständigen vorgegeben werden.

P.S:

Nach meiner Erfahrung wurde bei dieser Fragestellung (abhängig von der gelebten Security-Policy in dem Unternehmen) an die Vorgesetztenreihen schon sehr viel von der notwendigen Datenvertraulichkeit

wegen zu erwartenden Zeitaufwand und aus ökonomischen Gründen verworfen.