Zugriff auf eine Datei per ODBC

[Fuerchau]

Nun leider ist das nicht so einfach.
Es gibt genügend Methoden (z.B. MS-Query) sich andere Libs und Dateien anzuzeigen und dann diese Daten abzugreifen.
Man kann zwar eine neue Lib und View anlegen, muss aber alle anderen Lib's für den einen User dann aber mittels "USER *EXCLUDE" berechtigen.

[KingofKning]

Naja, aber das ist in meinen Augen aber doch einfacher ne Lib für einen User zu sperren als mir Spezial Software zu holen die wohl auch viel Arbeit macht und auch noch Geld kostet.

Bei uns im Haus gibt es keinen der die ODBC Einstellungen ändern könnte.
Und wenn ich fremde Firmen auf meiner Kiste hätte würde ich eine Auditing einstellen und das auch kontrollieren.

GG

[Fuerchau]

Auditing zeichnet auf, wer eingebrochen ist.
Sicherheitssoftware verhindert den Einbruch, so das Auditing nichts merkt.
Klar ist es nett den Einbrecher kennen zu lernen, ich finde es aber besser, den direkt draußen zu lassen.

[angelone]

die idee, den odbc user explizit aus sämtlichen libs auszusperren und nur eine einzige lib mit speziellen odbc daten freizugeben ist nicht schlecht.

allerdings verhindert das nicht, dass die 2000 anderen user, die man so in der firma hat einfach excel aufmachen und in den normalen daten rumwuseln.

ich habe mir das thema auch mal angesehen und bin zu dem schluss gekommen, dass man um eine dazugekaufte odbc exitpoint sicherheitssoftware nicht drumrum kommt.
selbermachen macht an der stelle irgendwie wenig sinn, weil es unglaublich viele fälle gibt, die man bedenken müsste.

ich bin dann bei "powertech network security" gelandet.

[Fuerchau]

Empfehlenswert ist da PCSACC/400, die machen das schon lange.
Was die 2000 anderen User angeht, so wird immer wieder hier vom sog. APP-User geredet.
Für die Anwendung gibt es einen speziellen User und Eigner der Applikation.
Ausschließlich dieser hat Berechtigung an den Objekten, Public ist generell *Exclude.
Alle APP-Programme laufen mit *OWNER-Berechtigung.
Und schon hast du dein System (fast) dicht.

[BenderD]

Naja, aber das ist in meinen Augen aber doch einfacher ne Lib für einen User zu sperren als mir Spezial Software zu holen die wohl auch viel Arbeit macht und auch noch Geld kostet.
GG

... das ist doch der Dreh an der Sache, wenn sich da jemand durchhackert, dann sagt man einfach: "Ich hab' doch extra Geld dafür ausgegeben, was hätte ich denn sonst noch tun sollen." Mach ich das mit Object Security, dann ist das zwar sicherer, aber ich habe die Verantwortung selber ...

D*B

[Fuerchau]

Dieser Ansatz ist falsch da von falschen Voraussetzungen ausgegangen wird:

"Naja, aber das ist in meinen Augen aber doch einfacher ne Lib für einen User zu sperren"

Richtig sollte es lauten:
"Es ist einfacher, ein Objekt (kann auch Lib sein) explizit einem User erlauben".

Schließlich sind ja richtigerweise alle Objekte mit Public *EXCLUDE geschützt.

Nun, was die Sicherheitssoftware angeht so macht die schon noch ein paar Türen mehr zu als ich rein mit Objektberechtigungen hinbekomme.

Spruch eines älteren Kollegen:
"Wer zu allen Seiten offen ist kann nicht ganz dicht sein!"

[holgerscherer]

Mach ich das mit Object Security, dann ist das zwar sicherer, aber ich habe die Verantwortung selber ...

Richtig - vor allem kann man bei der Exit-Point-Programmierung sehr viel falsch machen, wenn man viel Zeit hat, aber wenig Tiefenkenntnisse. Da sind 5000EUR für eine gute und erprobte Lösung eher ein Schnäppchen, verglichen mit dem einen Tag, an dem doch jemand die Kundendatei bei eBay vertickert...

-h

[BenderD]

... wer seine Produktionsdaten für Public Zugriffe freigibt, dem ist mit irgendwelchen auf Exit Programmen basierenden Placebo Lösungen nicht zu helfen!!!

D*B

[Fuerchau]

Wie du schon selber sagst, die Verantwortung gibt man an eine Software ab.

Zu PCSACC/400 kann ich nur sagen:
Damit vereinfacht man die Verwaltung in vielen Dingen und einen verbotenen Zugriff bekommt man durchaus protokolliert und abgewiesen.
Es gibt sicherlich viele Lösungen.
Der Vorteil des "Busch-Tools" ist die spezielle Behandlung durch IBM mit direkten Kontakten nach Rochester. Somit ist die neue Version auch immer passend zum neuen Release schon verfügbar.
Andere hecheln da durchaus hinterher.
Alleine was die Funktionalität von SQL angeht wird jeder SQL im Detail analysiert um die daraus resultierenden Zugriffe zu erlauben. Dabei werden sowohl Umbenennungen im SQL also auch Dateiüberschreibungen (OVRDBF's) berücksichtigt so dass man hier nicht einfach SQL's verbiegen kann.
Somit ist wirklich eine effektive und detaillierte Kontrolle möglich.
Viele dinge passieren bereits vor dem Auditjournal, denn dieses protokolliert nur die tatsächlichen Zugriffe und nicht die im Buschtool verhinderten Zugriffe.
Bei dem oben genannten Tool kann ich das so nicht erkennen.