Ein ordentliches Sicherheitskonzept ist wohl preisgünstiger ,aber ohne Aufwand geht nix.

Kurzer Abriss :

- originäre Anwenderprofile haben keinen R/W-Zugrifff auf die Bibliotheken mit Datenbankobjekten (PF, LF etc.).
- Es existiert ein Application-Benutzerprofil ohne Passwort bzw. ohne Anmeldemöglichkeit. Dies Profil ist Eigner aller Datenbankobjekte in der Lib. - Stichwort Resource security
- Alle Anwendungen laufen unter diesem Profil - ggf. über ein definiertes Startprogramm - Konzept 'Adopted Authority' / CHGPGM USRPRF(*OWNER) USEADPAUT(*YES)
- Für Zugriffe von "aussen" - Store procedures mit exakt definiertem Funktionsumfang bzw. Business code.
- Für originäre Anwender können dann immer noch gezielt über LF's/bzw. Views in einer anderen Lib Readonly! Zugriffe gestattet werden.

Anmerkung :
- Für Dateien im IFS ist das ganze etwas komplizierter, da hier 'Adopted Authority' nicht unterstützt wird.
Hier hilft nur ein swap des Profils über das QSYGET/SETPH API.

Und folgende Bücher kann ich nur wärmstens ans Herz legen :

http://publib.boulder.ibm.com/infoce...k/sc415300.pdf
http://publib.boulder.ibm.com/infoce...k/sc415302.pdf

Der Verwaltungsaufwand für ein Tool ala PCSACC/400 ist, aus eigener Erfahrung, auch nicht zu unterschätzen.
Wenn immer möglich sollte "ressource security" verwendet werden - hier sind die betroffenen Objekte generell unabhängig von der Zugriffsmethode (ODBC, FTP, DDM, DRDA etc.) geschützt.

Sven