FTP contra ODBC

[BenderD]

Hallo,

hier wirds zwar ein wenig OT, aber...
Java sollte grundsätzlich mit einem Connection Pool arbeiten und dann sind wir bei einem Applikations User und Kontrolle in der Applikation angelangt.

zum Thema fällt mir nochwas ein: ODBC lässt sich über ein View Layer schützen, was bei FTP nicht geht, das ist a) ein Vorteil gegenüber FTP und dieser Weg macht auch b) in vielen Fällen die REGINF Work arounds überflüssig.

Dieter Bender,

der Placebos im Bereich der Medizin für gesünder als pharmakologische Alternativen hält, wenn diese auch dort manchmal nicht mehr als Security technische Pendants helfen.

Fuerchau ist wieder schneller. Die Produzenten der Software versprechen jeden neuen Exitpoint (REGINF) zu bedienen, damit sind sie auf jeden Fall schneller als der Heimprogrammierer.
Argumente gegen diesen Schutz sind "selbstbetrug", denn selbst mit *PUBLIC *EXCLUDE kommt man nicht mehr weiter. Das beste Beispiel liefern zur Zeit unsere Javaprogrammierer deren Javaprogramme gegen eine Wand laufen, weil die Javaprogramme mit der iSeries Berechtigung nicht klar kommen. Also wieder zurück auf los und die Berechtigung lockern ?? Aber dann kann jeder die Daten 'runterladen .. also zusätzlich zum iSeries Objektschutz die hier angesprochene Software zur Bedienung der REGINF.

Gruß
DVE

[DVE]

@ Dieter: Was meinst du mit OT ??
Gruß
DVE

Placebos helfen in der Regel nur wenn man nicht weiß, dass es Placebos sind.

[Fuerchau]

OffTopic !

Gerade das mit dem ApplikationsUser (feste Anmeldung mit einem internen Profil und Kennwort) gestaltet sich gerade bei Java-Anwendungen als schwierig, da viele Aktionen mit dem DB-Register "Current User" geregelt werden. Arbeiten nun alle unter dem selben User gibts schon Probleme (z.B. Applikations-Berechtigung auf User-Ebene), insbesonder bei einer späteren vom Betriebsrat ungern gesehenen Journal-Auswertung (naja, der Betriebsrat fände die Idee wieder Klasse) sowie dem User-gesteuerten Accounting (Account-Codes im User-Profil).

Solange ich reine 5250-Anwendungen habe kann ich mit dem AppUser (Owner-Trick) ganz gut arbeiten.
Bei ODBC funktioniert das leider nicht mehr oder ich machs auf die ganz harte Tour:

Zugriffe ausschließlich mittels SQL-Prozeduren, die wiederum unter Owner (AppUser) laufen.
Native DB-Zugriffe sind dann natürlich verboten.
Charmanter Vorteil: es gibt nur zugelassene und performante Zugriffe und keinen Wildwuchs

Aber ehrlich, wer designed so eine Anwendung ?

[Fuerchau]

@DVE

Du kannst hier ruhig Namen nennen. Welches Produkt hast du genommen, da es wohl nicht PCSACC/400 ist ?

[DVE]

Ich wollte keine Reklame machen, Mama sollte sich selbst ein Bild machen. Wir haben BSafe gekauft. PCSACC/400 habe ich vor ein paar Jahre bei einer Livepräsentation gesehen und es war "das Grauen". Ich hoffe, es ist heute besser handlebar.

In bezug auf Java stehen wir hier so ziemlich am Anfang und die bisherigen Vorschäge aus der Javafraktion sind "schrecklich". Benutzer-Id und Kennwort (ein Superuser für den "aktuellen Benutzer") in einer IFS-Datei hinterlegen oder gleich *ALL Berechtigung für alle Anwender.
Es bleibt auf jeden Fall spannend.

Gruß
DVE

[BenderD]

<KALAUER>
Papa auch!
</KALAUER>

Was da Java angeht, da gibt es bewährte Wege mit einem zentralen Connection Pool zur Datenbank, ob man dann einen Appserver dazwischen hat, oder einen Object Relational Mapper, das ist auch ein Stück Geschmacksache; aber mit jeder darf alles, das sieht doch sehr selbstgestrickt und nach RPG aus...

mfg

Dieter Bender

Ich wollte keine Reklame machen, Mama sollte sich selbst ein Bild machen. Wir haben BSafe gekauft. PCSACC/400 habe ich vor ein paar Jahre bei einer Livepräsentation gesehen und es war "das Grauen". Ich hoffe, es ist heute besser handlebar.

In bezug auf Java stehen wir hier so ziemlich am Anfang und die bisherigen Vorschäge aus der Javafraktion sind "schrecklich". Benutzer-Id und Kennwort (ein Superuser für den "aktuellen Benutzer") in einer IFS-Datei hinterlegen oder gleich *ALL Berechtigung für alle Anwender.
Es bleibt auf jeden Fall spannend.

Gruß
DVE

[DVE]

@ Dieter, jetzt wird es wirklich OT.
Ne kein RPG sondern <KALAUER> "naives" </KALAUER> Java .. Denn ich habe das Gefühl, dass unsese Javafraktion einen guten Teil ihrer Programme aus dem Internet heruntengeladen hat und froh ist, dass sie halbwegs vernünftig funktionieren.

Gruß
DVE

PS
wirklich Betriebsrat ??

[BenderD]

naja, mit dem Betriebsrat - zu meinen Angestelltenzeiten hatte ich mal einen, der war nicht gekauft, der war geschenkt, der machte das umsonst - ich finds schon gut, wenn die Jungs (und Mädels) ein offenes Auge haben.

mit den stored Procedures - das wäre Applikationslogik in der Datenbank, das ist gegenwärtig out.

mit dem Owner - das ist originäre SQL Logik:
- Benutzername = Schemaname ist Owner der Datenbank
- Ownerprofile sind nicht anmeldbar
- alle Berechtigungen sind ohne GRANT exclude
- Applikation connected mit selbigem User
- die SQL Zugriffe brauchen nicht qualifiziert werden
- die Applikation darf alles
- ohne den Owner Connect darf man nix
- Zugriff nur über Views mit Grants
dies alles geht mit embedded SQL (und CLI) in RPG in lokalen Applikationen nicht, weil man automatisch connected wird.

mfg

Dieter Bender

OffTopic !

Gerade das mit dem ApplikationsUser (feste Anmeldung mit einem internen Profil und Kennwort) gestaltet sich gerade bei Java-Anwendungen als schwierig, da viele Aktionen mit dem DB-Register "Current User" geregelt werden. Arbeiten nun alle unter dem selben User gibts schon Probleme (z.B. Applikations-Berechtigung auf User-Ebene), insbesonder bei einer späteren vom Betriebsrat ungern gesehenen Journal-Auswertung (naja, der Betriebsrat fände die Idee wieder Klasse) sowie dem User-gesteuerten Accounting (Account-Codes im User-Profil).

Solange ich reine 5250-Anwendungen habe kann ich mit dem AppUser (Owner-Trick) ganz gut arbeiten.
Bei ODBC funktioniert das leider nicht mehr oder ich machs auf die ganz harte Tour:

Zugriffe ausschließlich mittels SQL-Prozeduren, die wiederum unter Owner (AppUser) laufen.
Native DB-Zugriffe sind dann natürlich verboten.
Charmanter Vorteil: es gibt nur zugelassene und performante Zugriffe und keinen Wildwuchs

Aber ehrlich, wer designed so eine Anwendung ?

[Fuerchau]

Der Owner-Connect ist ja gerade das Problem da per Design am User viel zu viel hängt.
Und die AppDB kann ich auch an die DFTRDBCOL oder wie immer das bei anderen DB's heißt, hängen.

Im M$-SQL-Server benenne ich eine Datenbank beim Connect.
Im Oracle-Server benenne ich diese ebenso, bei der Firebird auch.
Warum macht die AS/400 das da so anders ?!

Und was den automatischen RPG-Connect angeht, so kann ich natürlich im 1. Programm einen eigenen Connect kodieren, so dass alle folgenden SQL's der seleben ActGrp mit dem selben DB-User arbeiten.

Und wieso sind auf einmal StoredProcs out ?
Das war doch gerade der Vorteil, dass ich BI in die Procedure/Function lege ?!
(Gut, ich sollte SQL-Code und keine externe Sprache nehmen, allerdings kennt z.B. SQL-Server nur externe und ob die SQL-Procedure-Dialekte so kompatibel sind.)

Aber wer kümmert sich schon tatsächlich um Berechtigungen wenn man doch die entsprechenden Tools hat

@DVE
Von der Bedienung ist PCSACC/400 nicht besser geworden, das liegt aber nicht an der Software sondern an der Vielzahl der offenen REGINF's die einen Angriff ermöglichen.
Ich kenne keine andere Software, die ALLES bezgl. dieser Schnittstellen abdeckt und das mit hoher Variabilität.
Die meisten anderen Tools schenken sich eine SQL-Analyse incl. temporärer Umbenennung mittels ALIAS oder OVRDBF !
(Gut, den Tipp mit dem Alias habe ich gegeben).

Mit dieser Methode haben wir dann sogar einen externen PC entdeckt der da einen pollenden Zugriff startetet von dem aber auch wirklich niemand was wusste.

[BenderD]

Letzteres geht eben beim lokalen Connect eben gerade nicht!!! Man darf lokal nicht connecten und kann genau deswegen eben keinen anderen Benutzer als den angemeldeten Benutzer mitgeben. Was da ursprünglich als Erleichterung gedacht war, wurde dann einzementiert, damit die Datenbank Workload in 5250 Jobs mit CFINT gestraft wird, führt in OPM dazu, dass man nur einen Connect hat (weswegen da Commit Steuerung nicht wirklich geht), brachte dann in ILE den fürchterlichen Work around mit den Activation Groups und schließlich und endlich macht man das notgedrungen auf der AS400 völlig anders als mit Sequel, Oracle und Co und auch anders als in nicht AS400 DB2 - soviel auch zu UDB.

Dieter Bender

Im M$-SQL-Server benenne ich eine Datenbank beim Connect.
Im Oracle-Server benenne ich diese ebenso, bei der Firebird auch.
Warum macht die AS/400 das da so anders ?!

Und was den automatischen RPG-Connect angeht, so kann ich natürlich im 1. Programm einen eigenen Connect kodieren, so dass alle folgenden SQL's der seleben ActGrp mit dem selben DB-User arbeiten.

[Fuerchau]

Also das mit dem lokalen Connect ist ja wirklich sch.... !
Habs mal ausprobiert.
Da bleibt mir ja nur noch das API QSYSETPH um den User-Status vor dem 1.Connect zu ändern.

[DVE]

Hallo mama,
solltest du Interesse daran haben, wie ich die Umsetzung zu verschärften Objektrechte gemacht habe, schick eine Nachricht.
Gruß
DVE