Anmelden

View Full Version : Wie sichert ihr den ODBC-Zugriff



Seiten : [1] 2

JonnyRico
02-08-05, 10:54
Hi,

mal eine Frage an die Allgemeinheit. Wie sichert ihr die Maschine gegen potentielle ODBC-Zugriffe? Jeder User der den CA-ODBC Treiber installiert hat, könnte sich doch eine Verbindung einrichten und Daten per Exel oder Access Daten von der Maschine ziehen. Welches Komzept ist denn hier das richtige? ODBC-ZUgriff über Exit-Points "blocken"? Eine Software dafür kaufen? Objektberechtiungen (eine Menge Arbeit :( )? Windowsberechtigungen?

Gruß

Sascha

NEich
02-08-05, 11:30
Wir benutzen gekaufte Software.
Ohne Werbung machen zu wollen, wir benutzen PCSACC/400 von Busch und Partner (www.pcsacc400.de (http://www.pcsacc400.de)), und sind damit sehr zufrieden. Wir halten damit ca. 1500 Userprofile davon ab, sich alles anschauen und ändern zu dürfen.
Eigene Exit-Programme fände ich zu aufwendig und man muss sich sehr viel Know-How verschaffen. Blocken auf Port-Ebene mit einer Firewall fällt auch flach, da einige ODBC Anwendungen genutzt werden müssen.

Andreas Herzfeldt
02-08-05, 11:48
Hallo Sascha, ich hatte letztes Jahr die gleiche Problematik und bin auch über PCSACC/400 gestolpert, nur war deren Homepage plötzlich nicht mehr verfügbar. Also habe ich eine FREEWARE gefunden = ODBCLOG. Diese installiert und siehe da es funktioniert. Such mit Google nach ODBLOG und klicke dann JOBWATCH an. Das Produkt habe ich dann modifiziert und lasse jetzt nur noch den Zugriff von bestimmten IP-Adressen zu, das API QUSRJOBI habe ich dazu verwendet.

Andreas

Andreas Herzfeldt
02-08-05, 11:49
Hallo Sascha, ich hatte letztes Jahr die gleiche Problematik und bin auch über PCSACC/400 gestolpert, nur war deren Homepage plötzlich nicht mehr verfügbar. Also habe ich eine FREEWARE gefunden = ODBCLOG. Diese installiert und siehe da es funktioniert. Such mit Google nach ODBCLOG und klicke dann JOBWATCH an. Das Produkt habe ich dann modifiziert und lasse jetzt nur noch den Zugriff von bestimmten IP-Adressen zu, das API QUSRJOBI habe ich dazu verwendet.

Andreas

kuempi von stein
02-08-05, 11:50
Hi,

mal eine Frage an die Allgemeinheit. Wie sichert ihr die Maschine gegen potentielle ODBC-Zugriffe? Jeder User der den CA-ODBC Treiber installiert hat, könnte sich doch eine Verbindung einrichten und Daten per Exel oder Access Daten von der Maschine ziehen. Welches Komzept ist denn hier das richtige? ODBC-ZUgriff über Exit-Points "blocken"? Eine Software dafür kaufen? Objektberechtiungen (eine Menge Arbeit :( )? Windowsberechtigungen?

Gruß

Sascha
löle,

dann gibts da doch auch noch
extdbse (http://www.geocities.com/alex_nubla/extdbse.txt)Dieses Pgm ist für den QIBM_QZDA_INIT exit point gedacht. Es überwacht die ODBC Sicherheit und weist die User ab, die nicht über die ODBC *AUTL authorisiert sind
auf help400.de?
kann ich aber nix zu sagen...

k.

JonnyRico
02-08-05, 11:51
Hi,

danke ihr beiden. 4.500€ finde ich ne Menge Geld. Eine Maschinenabhänige lizensierung würde ich da glaube ich bevorzugen. Naja ich werde mir das Freewaretool mal anschauen. Danke.

Gruß

Sascha

JonnyRico
02-08-05, 11:53
löle,

dann gibts da doch auch noch
extdbse (http://www.geocities.com/alex_nubla/extdbse.txt)Dieses Pgm ist für den QIBM_QZDA_INIT exit point gedacht. Es überwacht die ODBC Sicherheit und weist die User ab, die nicht über die ODBC *AUTL authorisiert sind
auf help400.de?
kann ich aber nix zu sagen...

k.

Hi,

das habe ich schon getestet. Finde ich nicht so toll. Wenn ich eine OBDC-Verbindung für "NUR SELECT-Anweisungen" anlege, dann kann ich die Daten immer noch nach Excel bzw. Access ziehen. Vielleicht gibt es ja aber auch noch einen anderen Exit-Point den man dann benutzen muss, nur leider kenne ich diesen nicht.

akorb
02-08-05, 12:42
Hallo,

wir nutzen seit Jahren das APOS CA Security Module der Firma APOS aus der Schweiz - http://www.apos.ch. Wir sind damit sehr zufrieden.
Mit diesem Programm kann man den gesamten externen Zugriff auf die AS/400 regeln (ODBC / FTP / IFS ...).

Gruss
akorb

Sven Schneider
02-08-05, 22:33
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/infocenter/iseries/v5r3/ic2929/info/rbapk/sc415300.pdf
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2929/info/rbapk/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

NEich
03-08-05, 06:57
PCSACC/400 hat natürlich immer Aufwand, wie jede andere Methode auch.
Man muss auch beachten, dass PCSACC/400 eigentlich nur eine Schwäche der "historisch gewachsenen" AS400-Welten kittet, nämlich dass aus bequemlichkeitsgründen auf Objektberechtigungen weitesgehend verzichtet wurde.
Mit ein paar selbstgestrickten Tools könnte man aber auch diese einfach verwalten (z.B. Rollenbasiert) und hätte damit eine bessere Absicherung als ein Exit-Point Programm.

Zudem gilt bei Exit-Point Software(ich nenn das mal so), dass man bei Client-Server Anwendungen (und sei es nur ein Excel-Export mit VB Makros) immer einen zusätzlichen Point of failure schafft, mit denen sich die Entwickler auseinandersetzen müssen.

Die Idee von Sven klingt erstmal umständlich, ist aber im Endeffekt die sauberste Lösung in meinen Augen.