michaelmeier

Eine schriftliche Zustimmung ist definitiv NICHT erfroderlich, um Abbuchungen vornehmen zu können. Dies kann seit Jahren schon ohne Genehmigung vorgenommen werden. Dies habe mehrfach mit meiner Hausbank durchgespielt. Hintergund: Umzug -> neuer Stromanbieter -> Vertrag am Telefon -> Abbuchung OHNE schriftliche Verträge -> Bank sagt: ist erlaubt und legal. Gab da eine Gesetzesädnerung... habe aber gerade nix genaues zur Hand. Natürlich kann man die Buchung wieder rückgängig machen - das ist kostenlos möglich. Zeitraum: bis 6 Wochen (und nun aufgepasst!!!) nach Feststellung der falschen Buchung. In der Konsequenz heißt das: Wenn ich erst nach 2 Monaten die Kontoauszüge ziehe, habe ich dann noch 6 Wochen Zeit, Einspruch einzulegen. Natürlich werden sich Gerichte im Zweifelsfall schwer tun, wenn man behauptet, man würde nur alle 5 Jahre seine Kontoauszüge checken... schließlich hat man auch als Bankkunde eine gewisse Sorgfaltspflicht. Aber prinzipiell hat man genügend Zeit dafür. Also: don't panic - lieber mal regelmäßig die Bankbewegungen checken.

wtf... warum kein bier? wegen der fahne? hm.. dann wodka. mich beruhigt auch ne gute runde q3 arena. schön vorher noch ne runde daddeln... ^^ aber im ernst: habe mir sagen lassen, dass bei echter prüfungsangst / prüfungspanik die rescue tropfen helfen (vgl. Bach-Blütentherapie â€â€œ Wikipedia - aber das muss wohl jeder für sich entscheiden.

Mittagspause -> Kantine

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

Ohne jetzt überheblich sein zu wollen: warum probierst du nicht alle drei Möglichkeiten und findest heraus, was für dich am besten ist? Oder befragst mal Google. Wieder ernsthaft: im wesentlichen gibt's zwei Optionen, Dinge zu lernen. 1) anlesen. 2) ausprobieren. Gerade als FI(AE/SI) ist das mit dem ausprobieren eigentlich zwingend erforderlich. Leg los, schau was passiert. Und merk dir, was wann passiert. Und wenn du nicht weiterkommst, dann lies nach oder poste konkrete Fragen. Es ist anstregend und nervig, ja. Aber langfristig der beste Weg. Have phun!

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?

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.

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. 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. 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. 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.

Yo, hier geht's um beides. 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. 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. 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!

Win2003 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. Meine Befürchtung. Schade, oder? *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.

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?

Ich dachte da eher an SingleSignOn. Einmal angemeldet, alles pocco. Nein?

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.

Ack. Das ist ja der aktuelle Stand und Hintergrund meiner Frage. Prinzipiell: ja. Jupp - ich befürchte es. 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. 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. 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!

@Crash: vielen Dank für deine ausführliche Antwort. Aber ich glaube, wir reden da aneinander vorbei. Das ist klar, aber in den meisten Fällen nicht zu ändern. Jupp - Standardverfahren für SSH. Trifft hier aber nicht zu. Lokale User. Ein Admin. Full ack. Ebenfalls hier nicht zutreffend. 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. Ebenfalls full ack, ebenfalls nicht zutreffend. 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??? ja, alles Standard, Überall fullack. 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.

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.

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. 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.

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?

^ kaffee ist fertig. milch und zucker? < holt sich nun noch einen eigenen kaffee. schwarz, doppelt zucker. v kann kaffeejunkies (verbrauch > 1 Kanne pro Tag) nicht verstehen und kann auch ohne Kaffee erfolgreich in den Tag starten.

das ist keine Anwort auf die Frage, denn: hier wird nur geklärt, dass die Daten herausgegeben werden müssen, sofern entsprechende Merkmale vorliegen. Mit anderen Worten: ich muss - sofern ich dazu verdonnert werden. Aber von freiwillig steht da nix. bzgl. Klingt arg nach "hätte, könnte, sollte". Aber konkretes scheint sich ja nirgendwo zu finden. Eigentlich bemerkenswert.

^ richtig - bin eh 24/7 vor ort und damit auch erreichbar. lang lebe das bw-klappbett! < will heute früh nach hause. mehr fussball. wird aber wohl nix. einer muss ja die stellung halten. v haut heute bestimmt früh ab und wird die spiele schön was im biergarten verfolgen.

Was die ISP angeht: sicherlich ein sehr spannendes Feld. Um aber das Ausgangsposting nochmal aufzugreifen: Wer oder was sollte mich denn daran hindern, nach belieben die IPs rauszugeben? Gibt es da konkrete gesetzliche Vorgaben, dass ich das nicht darf? Oder anders: was wäre denn, wenn ich die enstprechende IP einfach mal neben das Posting pinne? Verboten? Wenn jemand da was hat: bitte mal das entsprechende Gesetz / Verordnung / was auch immer posten. Thx a lot.

Hi, erstmal Glückwunsch zur Entscheidung, dich mit weiteren Betriebssystemen zu beschäftigen. Sehr schön! Zu Deinen Fragen: Ja. Bei der Installation wird ein Bootloader erzeugt und (normalerweise) in den Masterbootrecord der Platte geschrieben. Hier wird angegeben, welche Optionen zum Booten verfügbar sind (kurz und knapp gesagt). Auch wenn ich die 8.04er Ubuntu noch nicht selbst installiert habe: die meisten großen LInux-Distributionen raffen selbstständig, das noch ein anderes Betriebssystem installiert ist und passen den Bootloader entsprechend an (übrigend ganz im Gegensatz zu ***-Produkten, die immer da ziemlich gnadenlos sind). Don't panic! Bei der von dir genannten Konfig sollte es zu keinen Problemen kommen. Einzig bei der ATI weiß ich nicht, ob Ubuntu mitlerweile den ATI-Treiber mitbring (ist kein OpenSource bzw. GPL, daher ist es lizenzrechtlich nicht so einfach, den Treiber zu integrieren). Das hätte zur Folge, dass die Karte keine 3D-Beschleunigerfunktionalität besitzt. Das System läuft aber trotzdem. Wenn du die treiber installieren möchtest: bei ATI Treiber runterladen, Anweisung befolgen, fertig. Klappt in den meisten Fällen (bzw. ich habe bei älteren ATI-Karten und non-bleeding-edge-x-server-versionen nix Gegenteiliges gehört). Aber: mach doch den Test. Zieh dir die LIve-CD. Wenn es damit rennt und du keine Probleme hast, dann zieh die Installation auf Platte. Wenn es bei der Live-CD zu Problemen kommt, dann einfach Rechner durchstarten und alles wird gut. Dir viel Erfolg und vor allem: viel Spaß mit dem neuen Betriebssystem!

naja, das kommt ganz darauf an, wie man das Gesetz interpretiert. Fangen wir mal harmlos an. Netzwerk sniffen - gerade am Internetgateway -heißt u.U. auch Passwörter für http-Seiten greppen. Dazu §202a Abs 1 Strafgesetzbuch: Ist das da schon erfüllt? Besser §202b Strafgesetzbuch: damit wäre man dann in jedem Fall dran. Der neue Paragraf ist dabei eher uninteressant. Wie dem auch sei: als Admin sage ich: hey, wenn es dem Job dient - dann muss man mal ne Runde Gesetze dehnen. Aber es wird nicht lange dauern, bis der erste dafür vor den Kadi gezerrt wird.

Also der Anlass, aus dem heraus man mitsnifft, ist eigentlich völlig irrelevant. Fakt ist, dass es so möglich ist, personenbezogene Daten auszuwerten bzw. Mitarbeiter zu überwachen. Je nach Betriebsvereinbarung ist man da ziemlich schnell am Allerwertesten. Nicht umsonst ist man als Admin immer mit einem Bein im Knast. BTW: sind das nicht inzwischen auch "Hacker-Tools", die mitlerweile verboten sind? Oder ist das Gesetz noch nicht durch?