Sicherheitskonzept ODBC

[JonnyRico]

Hi,

ich hab mal ne Frage. Wie würdet ihr sowas regeln?
Wir haben Leute bei uns die Accessdatenbanken mit eingebundenen AS/400-"Tabellen" haben. Das alles halt über den ODBC-Treiber von CA400 und einer Quelle für die Bibliothek. Der Benutzer könnte also ganz leicht mit ein bissel krimineller Energie z.B. unseren Kundenstamm löschen oder verändern, da *PUBLIC auf die Datenbankdatei *CHANGE hat. Das ist ja nicht wirklich schön.
Das einzige was mir zur Abhilfe einfällt, ist dem User nur AccessRuntime zu installieren und per Windows2000/XP Richtline das installieren neuer Software zu unterbinden, sodass er keine Möglichkeit hat per Access oder wie auch immer die ODBC-Verbindung für andere AS/400 Datenbanken anzuwenden.
Wie würdet ihr denn verfahren?

Btw. Die Objektberechtigung kann nicht geändert werden.

Sascha

[Fuerchau]

Also, zum Thema Objektberechtigung sehe ich das anders.
Die *PUBLIC-Berechtigung ist ganz leicht zu entziehen und über ein entsprechendes Menü-Startprogramm die Anwendungsberechtigung zu belassen.

Für die ODBC-User bietet sich am besten ein LF in einer eigenen Bibliothek an, die ausschließlich *PUBLIC(*READ) zuläßt.

Ein weiterer Ansatz ist das Tool PCSACC/400, in dem die Zugriffe explizit gesteuert werden können.

[BenderD]

Hallo,

kriminelle Energie unterstellt, hilft der ganze Zinnober mit dem verknipsen des ODBC nix. Da gibt es zum Beispiel eine schöne Freeware Squirrel, die macht SQL über einen JDBC Treiber, der unter jtOpen frei verfügbar ist.

Alternativen sind:

kein Start der Datenbank Serverdienste:

scheidet meist aus, da sie für bestimmte Anwender/Anwendungen gebraucht werden.

Exitprogramme mit oder ohne entsprechende Software:

Werden gerne gekauft, funktionieren sogar mehr oder weniger.
zwingen allerdings dazu was doppelt zu administrieren, was man einfacher haben könnte.

Adäquate Nutzung der Object Security:

Wird meist gescheut, weil man sichn nicht damit beschäftigen will und sich lieber Tools aufschwatzen lässt, die man eigentlich nicht braucht. Richtig durchgeführt geht sowas einfach und glatt. Für einen einfachen Weg, der oft schon reicht, siehe auch meinen Vorposter.

mfg

Dieter Bender

[Fuerchau]

@Dieter

Wie kommt Squirrel denn an der Objektberechtigung vorbei ? Oder habe ich da was missverstanden ?

[BenderD]

Hi,

Objektberechtigung zieht, aber dem ist ODBC und alles, was man hier schraubt scnurz

Dieter

[Fuerchau]

Nun, wenn Objektberechtigung zieht, würde ich meine Lösung auf jeden Fall vorziehen, da ich nun mal auch mit Java nur an freigegebene Objekte drankomme.

[dbausnnd]

Hallo zu diesem Thema habe ich nochmal eine Frage. Seitdem ist ja einiges vergangen getan auch in der DB.

Wenn ich eine Lib habe wo Public *EXCLUDE ist aber es Anwender gibt die bestimmte Dateien auswerten dürfen, wie kann ich dabei am besten vorgehen.

Meine erste Idee war mittels Views die in einer anderen LIB stehen den Zugriff zu gewähren. Bedeutet der Mitarbeiter hat Zugriff auf die View aber nicht auf die Tabelle. Das geht so nicht, da der Benutzer auch hier auf die Tabelle zugreif haben muss.

Wie kann ich es realisieren, das der Mitarbeiter nicht auf die Ursprungstabelle zugreifen kann

Über Tipps und Anregungen bin ich dankbar.

dbausnnd

[Fuerchau]

Da hilft folgende Einstellung:
LIB bleibt auf *public *exclude,
die Objekte der Lib (PF/LF) stehen auf *PUBLIC *READ.

2. Lib mit der View auf die 1. Lib mit *PUBLIC *READ.

[holgerscherer]

Btw. Die Objektberechtigung kann nicht geändert werden.

Das ist der erste Ansatz für ein Sicherheitskonzept - alles andere artet in Bastelei aus.

Eine schnelle Nothilfe wäre, dass die User nur mit einer Kopie der wichtigen Daten arbeiten können.

-h

[Fuerchau]

Wenn an den Berechtigungen nichts geändert werden darf, dann hilft eben nur ein Tool wie PCSACC/400 dass einem das Leben in dieser Hinsicht wirklich vereinfacht (auch wenn Dieter gegen solche Tools ist).