Passwort aus Windows-Programm ändern ( CHGPWD )

[DVE]

@BENDER
Das Gefühl kenn ich seit zu langer Zeit. Am Anfang bist du Cassandra (Schwarzmaler) und wenn's passiert bist du ein besserwisser der nur "Glück" hatte.

der seine Tätigkeiten im Bereich Security eingestellt hat, weil er keine Lust mehr hatte seinen Kunden Dinge zu erzählen, die sie nicht hören wollten und Sachen zu zeigen, die sie nicht sehen wollten.

[Sven Schneider]

Schaut euch doch professionelle ERP-Systeme an, welche schon immer im Client/Server-Umfeld betrieben wurden.
"Bestes" Bsp. ist SAP, hier gibt es auf der I5 unter I5/OS genau einen DB2/400 User für die Anwendung --> SAPUSER.

Die eigentlichen ERP-User und Passworte sind in SAP eigenen Datenbanktabellen hinterlegt, da ja auch ERPseitig zusätzliche Merkmale/Berechtigungen/Rollen am Benutzer notwendig sind.

Wie kann man trotzdem kontrollieren, wer einen Datensatz wann mit welcher Anwendung geändert hat.
Ganz einfach, man fügt jeder Datenbanktabelle ein Feld (letzter) USER hinzu, in dieses Feld schreibt man bei jedem Update/Insert den angemeldeten Anwendungsuser.
Über das DB2/400 Journal lässt sich jede Änderung verfolgen.

Oder besser man schafft sich einen eigenen zentralen Datenbank-Layer und bildet hier einen eigenen Audit Trail nach. Wichtig ist, das der DB-Layer den angemeldeten Benutzer mitbekommt.
Die Änderungsprotokolle schreibt man dann in eine eigene log-Tabelle.

[holgerscherer]

der seine Tätigkeiten im Bereich Security eingestellt hat, weil er keine Lust mehr hatte seinen Kunden Dinge zu erzählen, die sie nicht hören wollten und Sachen zu zeigen, die sie nicht sehen wollten.

kenne ich. Soll ja Leute geben, die glauben, eine AS/400 ist von Haus aus sicher...

Aber deswegen stell ich meine Tätigkeit nicht ein, ab und an brauche ich was zum Aufregen, wenn grade kein Kaffee da ist.

-h

[holgerscherer]

Wie kann man trotzdem kontrollieren, wer einen Datensatz wann mit welcher Anwendung geändert hat.
Ganz einfach, man fügt jeder Datenbanktabelle ein Feld (letzter) USER hinzu, in dieses Feld schreibt man bei jedem Update/Insert den angemeldeten Anwendungsuser.

Prima, aber hoffentlich über einen System-Trigger und nicht über die Applikation. Sonst wäre diese Angabe nicht vertrauenswürdig <g>

-h

[BenderD]

ob man dem Trigger trauen darf, sei noch dahingestellt...(ich sage nur mal strsrvjob und strdbg)
die Schreiberei überhaupt dem Database access Layer zu überlassen, hat nebenbei bemerkt durchaus Charme, da sage ich nur mal EJBs und für die POJO Fans Hibernate...

mfg

Dieter Bender

Prima, aber hoffentlich über einen System-Trigger und nicht über die Applikation. Sonst wäre diese Angabe nicht vertrauenswürdig <g>

-h

[holgerscherer]

ob man dem Trigger trauen darf, sei noch dahingestellt...

einem Trigger traue ich auch nicht weiter, als ich ihn selbst gelöscht und neu angelegt habe. Allerdings... wenn ich so recht überlege, gehen wir doch lieber zur /36 zurück. Da gab es nicht viel, was man falsch machen konnte.

Und jetzt Schluss mit der Diskussion, wir haben schon 5 Meinungen zu 6 Varianten der besten Methode...

-h

[Fuerchau]

Deswegen läßt sich ja SAP aus gutem Grund nicht in die Karten gucken.
An die Datenbank kommt man vernünftig nun mal nur per ABAP (oder so) und damit kann man diese Journale nicht unterlaufen.
Allerdings, die Performance .....

[BenderD]

Aber security by obfuscation, das ist kein anerkanntes Merkmal für Sicherheit....

Deswegen läßt sich ja SAP aus gutem Grund nicht in die Karten gucken.
An die Datenbank kommt man vernünftig nun mal nur per ABAP (oder so) und damit kann man diese Journale nicht unterlaufen.
Allerdings, die Performance .....

[DVE]

Aber security by obfuscation, das ist kein anerkanntes Merkmal für Sicherheit....

.. und trotzdem gibt man dafür sehr viel Geld aus

Gruß
DVE