View Full Version : Passwort aus Windows-Programm ändern ( CHGPWD )
@Fuerchau
*DISABLED gerade ausprobiert. Geht nicht, der Benutzer muss *ENABLED sein.
Aber die Idee "es muss gehen" ist ein guter Ansatz. Wenn jemand weiß wie, bescheid sagen. Das ist weder lakonisch noch ironisch gemeint, sonder ernst. Mir gehen die Diskussionen hier ziemlich auf die Nerven. Sogar die Forderung alle Anwender sind ja MA der Firma und damit berechtigt die Daten zu sehen/ändern wird gestellt, um den "kleinen" Störenfried ruhigzustellen.
Gruß
DVE
Hallo,
man muss sich erst mal entscheiden ob der Client (sprich der Rechner) vertrauenswürdig ist, oder nicht; wenn selbiger bei der Anmeldung abprüft und dann Berechtigungen steuern kann, dann vertraut man ihm im allgemeinen, tut man das nicht, dann muss der Anwender vor Aufruf einer gesicherten Anwendung einen Bewis erbringen wer er ist (Benutzer Kennwort oder etwas adäquates).
Jetzt kommt die Anmeldung am Server (AppServer oder Datenbank Server, oder what ever). Selbige erfolgt tunlichst nicht mit einer persönlichen Berechtigung des Anwenders, sonst darf er das alles ja auch unkontrolliert mit einem beliebigen Frontend über ODBC, JDBC, oder das entsprechende Protokoll der Anwendung. Also braucht man jetzt einen AnwendungsBenutzer, der sich connected, dessen Kennwort muss geschützt abgelegt sein, also lokal verschlüsselt (sonst kanns der Anwender lesen), oder hart im Programm, oder remote auf einem entsprechenden Authentikations Server.
Die Berechtigungs Differenzierung innerhalb der entsprechenden Server Domain (in unserem Fall Datenbank), kann jetzt in der Applikation, oder der Datenbank erfolgen, wenn die Anwendung jetzt auf einem Server läuft (WebServer oder AppServer), dann entscheidet man sich meist für Applikations Level (aus Pooling und Cashing Gründen), handelt es sich um einen Fat Client, dann kann man das auch der Datenbank überlassen, wenn die das kann. Persönliche Benutzer scheiden hier meist wegen des zu treibenden Aufwands aus, meist hat man ein paar Rollen, für die jeweils ein Benutzer zur Verfügung steht. Für den Wechsel zur passenden Rolle muss der Anwender einen Beweis haben, dass er diese Rolle spielen darf und im diskutierten Beispiel braucht er noch einen Beweis, dass es die Applikation ist, die den Wechsel zu der Rolle vornimmt, für die Anmeldung kann man durchaus die API Lösung mit dem Profile Switch nehmen. Bei ODBC dürfte das etwas schwieriger als bei JDBC sein (soweit der Benutzer an die DSN auch mit Excel drankommt), dann muss man halt die Kennwörter in der entsprechenden Datei nochmal mit einem Schlüssel verschschlüsseln, den nur die Applikation und nicht der Benutzer kennt (der kann wieder verschlüsselt lokal abgelegt sein, oder hard codiert in der Anwendung, oder remote auf einem Authentikations Server).
Noch ein paar Anmerkungen zur "schönen alten Welt": ich habe bisher so gut wie keine Umgebung gesehen, in der adopted Authority korrekt und sicher implementiert war. Spätestens, wenn man eine Command Line mit der Berechtigung eines solchen Einstiegsprogrammes kombiniert, dann frisst einem der Rechner aus der Hand.
Dieter Bender,
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.
Selbst wenn die Prozedur bekannt ist sollten die dazu benötigten Parameter eben nicht bekannt sein.
Die Prozedur muss die Sicherheit leisten dass Sie eben nicht einfach so aufgerufen werden kann.
Andererseits darf es auch kein Benutzerprofil geben, dass eine 5250-lose Anmeldung erlaubt (also ODBC).
So auf die Schnelle fällt mir hierzu nichts ein, es muss aber gehen. Schließlich haben auch andere Datenbanken (SQL-Server, Oracle o.ä.) die selben Probleme wenn es um freie ODBC-Zugriffe geht.
Andere DB's noch um so mehr als dass dort ein Umschiessen des Users nicht möglich ist.
Die Anwendung meldet sich mit eine APP-User an. Dieses Kennwort hierzu muss verschlüsselt abgelegt oder programmiert werden so dass eine normale Anmeldung ausserhalb der Anwendung mit diesem Userprofil unmöglich gemacht wird.
Dann klappt auch das Umschiessen des Users mit einem temporären internen Kennwort dass ausschließlich der Anwendung bekannt ist.
Die dazu nötigen Profile sind selbst wiederum nicht anmeldefähig.
Man kann sogar mal probieren ob QSYGETPH/QSYSETPH mit disabled Profilen möglich ist.
Vielleicht hat ja mal jemand Zeit dies zu probieren.
@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
08-11-06, 15:37
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
08-11-06, 18:38
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
08-11-06, 18:39
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
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
08-11-06, 19:34
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
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 .....
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 .....