FTP contra ODBC

[BenderD]

Hallo,

technische Möglichkeiten sind nur eine Seite der Medaille, korrekt implementiert muss es sein und einfach verifizierbar.

Firewall brauche ich immer, mit entsprechenden Filtern und Protokollierungen.
Zumindest die Public Berechtigung muss für Produktionsdaten dicht sein.
typische Implementierungsfallen auf AS400 sind zum Beispiel:
untergrabbbare Programme mit adopted Authority
Ein Exit Point ist dicht, ein anderer (neuerer) ein Scheunentor.
Bodenloser Leichtsinn nach dem Motto: wir haben den sichersten Rechner der Welt (was nicht einmal stimmt!!!)

mfg

Dieter Bender

Schöne diskussion.
REGINF Klamotte. Sobald die entsprechende Software gekauft oder selbst geschrieben in den REGINF hinterlegt ist, wird jeder Datenbankzugriff überprüft. Und selbst wenn jemand Leseberechtigung an einer bestimmte Datei hat, so kann er die Datei nicht 'runterladen, wenn der Zugriff über die Software verweigert wird .. oder habe ich unrecht ??
Gruß
DVE

Zu MAMA. Dieter hat trotzdem recht. Erstens die Datenbanken müssen mit den Berechtigungsmöglichkeiten der iSeries geschützt werden und zweitens solltest du dir 'ne Software (in diesem Forum sind drei Softwarepakete angesprochen worden) kaufen.

[Fuerchau]

@Dieter
Die klassischen Anwendungen arbeiten mit dem normalen Objektschutz der AS/400 ganz gut. Da gibts auch kein *PUBLIC *ALL sondern meistens das Gruppenprofil.
Da aber die Anwendung selber die Objektberechtigung benötigt stehen die Dateien den meisten Usern eben auch per FTP/ODBC zur Verfügung.
Sicherlich kann ich Anwendungen mit dem OWNER-Trick schützen, aber wer macht das schon.

Und was die Client-Software angeht so gibt es da schon simple ODBC-Treiber und bei Java sogar kostenlose.

Und genau DAGEGEN kann ich mich etwas besser über REGINF-Klamotten schützen.

[Fuerchau]

Achja wie heists da nochmal ?

Wer nach allen Seiten offen ist, kann nicht ganz dicht sein !

[DVE]

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

[Fuerchau]

Und zumindest zu PCSACC/400 kann ich sagen, dass gerade hier neue AccessPoints sofort bedient werden, da zwischen dem Hersteller und IBM PreReleases ausgeliefert und getestet werden.
Mit offizieller Einführung des V5R4 war PCSACC/400 für V5R4 bereits verfügbar.

[DVE]

@ MAMA
Ich habe in unserem Haus die Objektberechtigung erstmals 1998 (*PUBLIC *USE) durchgeführt und anfang des Jahres verschärft (*PUBLIC *EXCLUDE). Zusätzlich haben wir jetzt eine der drei genannten SW-Produkte gekauft um den externen Zugrif (ODBC, FTP etc.) zu reglementieren.
Das ganze ist wie ein Griff in die braune Masse und kann nicht in zwei Sätze abgehandelt werden, weil viele Faktoren eine Rolle spielen. Da gibt es Benutzer die Daten 'runterladen müssen, andere die Daten hochladen und wenn ihr mit Javaprogrammierung anfangt, fängt das Spiel an Interessant zu werden, weil Java nach anderen Regeln spielt als die iSeries.
Also (MAMA) nicht verzweifeln, sondern hinsetzten und genau definieren (lassen) wer was machen will. Die Aussage ODBC ist sicherer als FTP ist jedenfalls nicht richtig.

Gruß
DVE

[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]

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 ?