Passwort im Klartext

[michaelmeier]

Unter welchem System läuft der AppServer denn?

Win2003

Und wieviele Nutzer brauchen denn wirklich administrativen Zugang?

Da der Server von einem Dienstleister betreut wird sach ich mal: knapp 20 Administratoren mit Admin-rechten + 5 Applikationsbetreuer mit Rechten des technischen Users haben Zugriff.

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.

Meine Befürchtung. Schade, oder?

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.

*lol*

Nee, würde nicht. Da ich mit dem Login entsprechende Kreditoren und Debitoren anlegen kann und dort ohnehin eine hohe Fluktuation herrscht, würden neue Einträge kaum auffallen. Und wenn der Betrag in angemessenem Rahmen bleiben würde, dann würde das erst sehr spät auffallen.

Da läuft soviel Kohle durch das System - Kleinbeträge fallen da kaum auf.

[michaelmeier]

hi,

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

Yo, hier geht's um beides.

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.

Geht dabei ja weniger um das sendende System als vielmehr um das empfangende System (hier: SAP). Datenübertragung läuft über RFC / BAPI.

Aber ja, du hast natürlich recht, man könnte hoffen, dass die Manuals da was aussagen. Tun sie leider nicht, da hier das empfangende System maßgebend ist. Und SAP gibt heirfür ledliglich die Daten für RFC-Verbindungen vor. Ziemlicher Mist.

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.

Ja, prinzipiell gebe ich dir völlig recht. Man sollte meinen, dass das ausreicht. wie aber die jüngste Vergangenheit gezeigt hat, hält das niemanden mit genügend hoher krimineller Energie davon ab, da aktiv zu werden (vgl. Bankenvorfall in Liechtenstein). Das eine ist das Organisatorische - das ist hinreichend geregelt. Aber das ist (zumindest aus meiner Sicht) nicht ausreichend. Ich will keinen Schutz aufgrund von Verträgen sondern eine tatsächlich sichere Umgebung! Schutz, der nur auf dem Papier steht, interessiert mich weniger. Klar, sobald man nicht alle Systeme selbst kontrolliert, läuft man Gefahr, das jemand mit ausreichend Befugnissen entsprechende Daten zweckentfremdet. Bin ich völlig bei dir. Aber da nur einen Riegel auf Vertragsebene vorzuschieben halte ich für nicht ausreichend.

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.

Sorry, raff ich nicht. Hab's versucht. Mehrfach. Geht nicht.

Kannst Du das so formulieren, dass ich das auch nach 2 Bier noch raffe?

Dank im Voraus!

[geloescht_JesterDay]

Da der Server von einem Dienstleister betreut wird sach ich mal: knapp 20 Administratoren mit Admin-rechten + 5 Applikationsbetreuer mit Rechten des technischen Users haben Zugriff.

Naja, wenn der Server wirklich soo wichtig ist und die Gefahr für solche heimlichen Buchungen so groß, dann würde ich aber sagen: Eigentor. So etwas wichtiges stellt man nicht außer Haus und selbst wenn du eine super Idee hättest, du müsstest dich dann auf den externen Dienstleister verlassen. Den kannst du schlecht kontrollieren, also wer da alles Zugang hat o.ä. (im schlechtesten Fall liegt da irgenwo ein Zettel mit Zugangsdaten für alle Server oder so)

Ok, die Buchungen im System sind ja eine Sache, aber das muss ja alles auch zur Bank und da von einem Bankkonto gebucht werden. Also ihr müsst eine sehr miese Buchhaltung haben, wenn die Kontenbewegungen ungeprüft passieren (zumindest im Nachhinhein).

Und 20 Administratoren... is schon n Wort. Was läuft denn da so viel, dass da soviele Leute Admin-Zugang brauchen? Wenn das System wirklich so wichtig und angreifbar ist, dann würd ich das auf nen eigenen, dedizierten Server legen, wo nur das läuft und sonst nix. Und da haben dann nur ganz wenige Zugang zu.

Oder aber du übertreibst das ganze etwas, weil sonst scheint das ja niemanden interessiert zu haben? Kann ich aber von hier nicht beurteilen.

[TheFinn]

Sorry, raff ich nicht. Hab's versucht. Mehrfach. Geht nicht.

Kannst Du das so formulieren, dass ich das auch nach 2 Bier noch raffe?

Er meinte wohl: Sicherheit kostet Geld und Geld gibt keiner gerne aus

Wie häufig wird dieses Kennwort eigentlich gebraucht? Für jeden Vorgang erneut oder läuft das System nach einer Anmeldung erstmal tagelang durch, braucht das Kennwort womöglich nur einmal beim Start? Falls das Kennwort nur selten benötigt wird: wie schnell muß es im Bedarfsfall verfügbar sein? Innerhalb von Sekundenbruchteilen oder reichen auch fünf Minuten?

[michaelmeier]

Naja, wenn der Server wirklich soo wichtig ist und die Gefahr für solche heimlichen Buchungen so groß, dann würde ich aber sagen: Eigentor. So etwas wichtiges stellt man nicht außer Haus und selbst wenn du eine super Idee hättest, du müsstest dich dann auf den externen Dienstleister verlassen. Den kannst du schlecht kontrollieren, also wer da alles Zugang hat o.ä. (im schlechtesten Fall liegt da irgenwo ein Zettel mit Zugangsdaten für alle Server oder so)

Naja, großer Konzern, gesamte Serverbetreuung via Outsourcing abgegeben. Konzern macht nur Applikationsbetreuung. Dienstleister hat halt nen paar mehr Angestellte, die dann natürlich auch Zugang zwecks Administration der Kiste haben müssen. Nichts ungewöhnliches also.

Ok, die Buchungen im System sind ja eine Sache, aber das muss ja alles auch zur Bank und da von einem Bankkonto gebucht werden. Also ihr müsst eine sehr miese Buchhaltung haben, wenn die Kontenbewegungen ungeprüft passieren (zumindest im Nachhinhein).

Je nachdem, wie der Prozess definiert ist.

Bin zwar nur IT-ler, aber ich meine er läuft grob so ab: die eingehenden Rechnungen werden über das System eingespielt und dort natürlich gem 4-Augen-Prinzip geprüft. Anschließend kommen freigegebene Rechnungen in den Transfer in Richtung SAP. Im SAP wiederum wird der ganze Spaß zur Zahlung angewiesen und per DTA (oder wie auch immer) an die Zahlungsabteilung weitergeleitet. Dort wird sicherlich nochmal geprüft - aber frag mich nicht, in welchem Umfang nun genau. Da aber nicht eben wenig Kohle über den Äther geht, wäre ich mir nicht sicher, ob da wirklich auch kleinste Rechnungen exakt geprüft werden.

Ist ähnlich wie damals bei der Bankangestellten, die bei Devisenwecheln die Nachkommapfennigstellen auf ihr eigenes Konto überwiesen hat. Die Beträge sind viel zu klein um ernsthaft aufzufallen. Nach einer ganzen Weile hat man da aber einiges beisammen. Die gute Frau hatte damals knapp ne Milllionen eingesackt. Ist nur durch Zufall aufgeflogen.

Und 20 Administratoren... is schon n Wort. Was läuft denn da so viel, dass da soviele Leute Admin-Zugang brauchen? Wenn das System wirklich so wichtig und angreifbar ist, dann würd ich das auf nen eigenen, dedizierten Server legen, wo nur das läuft und sonst nix. Und da haben dann nur ganz wenige Zugang zu.

Wie gesagt - großer Konzern, mehrere Rechenzentren, mehrere hundert verschiedene Systeme, Serverbetreuung ausgelagert.

Nein, das System ist sicherlich nicht überlebenswichtig, aber das Grundproblem besteht ja in sehr vielen Applikationen. Mich interessiert weniger eine Lösung für die Applikation selbst sondern viel eher für das allgemeine Szenario.

Oder aber du übertreibst das ganze etwas, weil sonst scheint das ja niemanden interessiert zu haben? Kann ich aber von hier nicht beurteilen.

Was gibt's daran zu übertreiben? Raff ich nicht. :eek Das Grundproblem existiert doch bei den meisten verteilten Systemen. Ob diese nun unternehmenskritisch sind oder nicht, ist dabei doch irrelevant. Was hat das mit Übertreibung zu tun? Daher ja auch das Eingangs erwähnte Beispiel mit PHP und dem Datenbankzugriff. Ein Problem, das ja nun die meisten Leute kennen. Die Applikation ist dabei aber - wie gesagt - völlig irrelevant, ebenso die potentiellen Auswirkungen. Mir ging es nur um Ideen für technische Lösungen des Problems.

[michaelmeier]

Er meinte wohl: Sicherheit kostet Geld und Geld gibt keiner gerne aus

Wie häufig wird dieses Kennwort eigentlich gebraucht? Für jeden Vorgang erneut oder läuft das System nach einer Anmeldung erstmal tagelang durch, braucht das Kennwort womöglich nur einmal beim Start? Falls das Kennwort nur selten benötigt wird: wie schnell muß es im Bedarfsfall verfügbar sein? Innerhalb von Sekundenbruchteilen oder reichen auch fünf Minuten?

Jupp. You get what you've paid for. Nicht vergessen: IT darf nichts kosten. Die bringt ja auch nix ein. Na, so schlimm wird es hier nicht gesehen, aber eine solche Betrachtung ist ja eher der Normalfall. Zumindest im produzierenden Gewerbe.

In dem Fall: mit jedem Batchlauf (alle 15 Minuten) wird die Verbindung angeschubst. Entsprechend wird da auch die Authentifizierung benötigt.

Auf Sekunden kommt es da nicht an, nein. Auf Minuten aber schon.

Aber nochmals: Es geht mit nicht um die Lösung des konkreten Problems in dieser Applikation sondern vielmehr um eine Idee für eine allgemeingültige Lösung bei verteilten Anwendungen mit Passwörten in Konfigurationsdateien.

[TheFinn]

Aber nochmals: Es geht mit nicht um die Lösung des konkreten Problems in dieser Applikation sondern vielmehr um eine Idee für eine allgemeingültige Lösung bei verteilten Anwendungen mit Passwörten in Konfigurationsdateien.

Na ja, "allgemeingültige" Lösungen sind aber doch eher selten :floet:

Da finde ich es schon angemessen, die Klasse der Probleme wenigstens grob zu partitionieren in der Hoffnung, wenigstens für eine der Teilmengen eine Lösung zu finden. Mir fiel halt auf, daß in diesem Thread das Stichwort "One Time Password" noch nicht gefallen ist, da wird nichts in irgendwelchen Dateien hinterlegt und man könnte ein solches OTP über eine SSH- oder RAS-Verbindung übertragen, so daß der externe Dienstleister außen vor wäre. Alle 15 Minuten ist aber natürlich zu häufig für eine manuelle Herangehensweise. Aber wie wäre es denn, wenn in der Tat das Skript zum Verbindungsaufbau nicht durch den beim externen Dienstleister stehenden Server angeschubst wird, der das Kennwort aus einer lokalen Datei ausliest, sondern über eine verschlüsselte Verbindung von Euch aus, dann könnt Ihr das jeweilige (Einmal-)Kennwort über die verschlüsselte Verbindung als Parameter übergeben.

Oder denke ich jetzt zu naiv?

[michaelmeier]

Na ja, "allgemeingültige" Lösungen sind aber doch eher selten :floet:

Da finde ich es schon angemessen, die Klasse der Probleme wenigstens grob zu partitionieren in der Hoffnung, wenigstens für eine der Teilmengen eine Lösung zu finden. Mir fiel halt auf, daß in diesem Thread das Stichwort "One Time Password" noch nicht gefallen ist, da wird nichts in irgendwelchen Dateien hinterlegt und man könnte ein solches OTP über eine SSH- oder RAS-Verbindung übertragen, so daß der externe Dienstleister außen vor wäre. Alle 15 Minuten ist aber natürlich zu häufig für eine manuelle Herangehensweise. Aber wie wäre es denn, wenn in der Tat das Skript zum Verbindungsaufbau nicht durch den beim externen Dienstleister stehenden Server angeschubst wird, der das Kennwort aus einer lokalen Datei ausliest, sondern über eine verschlüsselte Verbindung von Euch aus, dann könnt Ihr das jeweilige (Einmal-)Kennwort über die verschlüsselte Verbindung als Parameter übergeben.

Oder denke ich jetzt zu naiv?

Ja und nein, eine allgemeine Lösung ist natürlich schöner - das Problem ist ja auf beliebige Systeme portierbar.

OTP ist natürlich eine Idee. Thx. Aber wahrscheinlich in diesem Rahmen nicht passend. Es sei denn, man hätte eine Möglichkeit, die OTPs auf beiden Systemen synchron zu etablieren. Ich muss darüber nachdenken.

Aber danke für den Tipp - auf solche Ideen wollte ich doch hinaus. Unabhängig vom konkreten Problem sondern allgemeingültig. Schön mal was nen Schlagwort in den Raum geworfen. Thx.

Any further ideas?

[geloescht_JesterDay]

Je nachdem, wie der Prozess definiert ist.

Bin zwar nur IT-ler, aber ich meine er läuft grob so ab: die eingehenden Rechnungen werden über das System eingespielt und dort natürlich gem 4-Augen-Prinzip geprüft. Anschließend kommen freigegebene Rechnungen in den Transfer in Richtung SAP. Im SAP wiederum wird der ganze Spaß zur Zahlung angewiesen und per DTA (oder wie auch immer) an die Zahlungsabteilung weitergeleitet. Dort wird sicherlich nochmal geprüft - aber frag mich nicht, in welchem Umfang nun genau. Da aber nicht eben wenig Kohle über den Äther geht, wäre ich mir nicht sicher, ob da wirklich auch kleinste Rechnungen exakt geprüft werden.

Ist ähnlich wie damals bei der Bankangestellten, die bei Devisenwecheln die Nachkommapfennigstellen auf ihr eigenes Konto überwiesen hat. Die Beträge sind viel zu klein um ernsthaft aufzufallen. Nach einer ganzen Weile hat man da aber einiges beisammen. Die gute Frau hatte damals knapp ne Milllionen eingesackt. Ist nur durch Zufall aufgeflogen.

Also die Buchhaltung muss jede Buchung irgendwas zuordnen können. Spätestens der Steuerprüfer will das wissen

Dass da einfach Buchungen so als "sonstiges" ungeprüft durchgehen kann ich mir nicht vorstellen.

Vielleicht machst du dich da mal schlau.

Und übertreiben: S.o. Dein Problem ist zwar irgendwo schon da, aber durch eine Prüfung ja doch relativ harmlos. Klar, wenn sowas in der Buchhaltung selbst passiert, kann das natürlich unter den Tisch fallen, wie in deinem Beispiel der Bank.

Sprich: Es gibt keine Lösung wie du sie dir vorstellst. Also komplett so absichern dass da keiner (auch keine 20 Administratoren!) rankommen.

Eben aus dem Grund gibt es ja weitere Prüfungen, und gerade ein großer Konzern wird Geldbuchungen nicht so auf die leichte Schulter nehmen wie du dir das denkst (wobei ich da selbst nur spekuliere, keine direkte Erfahrung habe).

[michaelmeier]

Hi,

nochmal: es geht dabei nicht um das konkrete Szenario, sondern vielmehr um das allgemeine Problem.

Nebenbei: was die Belege betrifft: da ja die Transaktion NACH der Prüfung eingedudelt werden würde, wäre das 4-Augen-Prinzip umlaufen. Die Zahlungsanweisung wird ja dann lediglich gegen die gebuchten Belege geprüft - welche ja korrekt wären.

Wie dem auch sei: da wir hier mit dem Gedankenexperiment (nämlich: wie verhindere ich technisch in Batchjobs über entfernte Systeme das Hinterlegen von Klartextpasswörten in Konfigurationsdateien - organisatorsiche Lösung seien dabei außen vor) nicht voran kommen (wie es scheint gibt es zumindest keine triviale Lösung dafür), kann der Thread geschlossen werden.

So long and thx 4 the fish. :e@sy

[geloescht_JesterDay]

Wie dem auch sei: da wir hier mit dem Gedankenexperiment (nämlich: wie verhindere ich technisch in Batchjobs über entfernte Systeme das Hinterlegen von Klartextpasswörten in Konfigurationsdateien - organisatorsiche Lösung seien dabei außen vor) nicht voran kommen (wie es scheint gibt es zumindest keine triviale Lösung dafür), kann der Thread geschlossen werden.

Ich hatte dich das schonmal gefragt: Wie stellst du dir das denn überhaupt vor? Also nur mal so ganz allgemein gesprochen, Brainstorming mäßig.

Ich hab ja einiges aufgezählt, warum das IMHO gar nicht gehen kann wie du dir das vorstellst. Aber du musst ja zumindest mal eine Grundidee gehabt haben, oder?

Ich frage das, weil mich das schon interessieren würde. Vielleicht ist meine Ansicht ja doch zu sehr eingeschränkt...

Bearbeitet 23. Juni 2008 von JesterDay