Zugriff auf AS400 Dateien über ISeries Access verhindern.

[schellchr2]

Gibt es die Möglichkeit über ein CL oder
eine API-Schnittstelle Filetransfer für bestimmte Dateien bzw. Bibliotheken zu verhindern?

[Fuerchau]

Natürlich.

Allerdings ist der Aufwand da releativ hoch.
Schau mal über WRKREGINF nach den Schnittstellen.

Da gibts gleich eine ganze Reihe, je nach Art des Zugriffs:
ODBC-SQL (QZDA-Job's)
DRDA
FTP
u.v.m.

Am besten wendest du dich da aber an PCSACC/400_BUSCH&PARTNER, SOFTWARE

Lass dich nicht vom Preis abschrecken, wenn du selber was entwickeln willst, wird's mit Sicherheit erheblich teurer.

[BenderD]

wenn mans ordentlich macht, dann kommt man an Objekt Security meist nicht vorbei. und wenn mans ganz huddelig macht, dann muss das nicht teurer werden, so kompliziert sind die Exits ja nun nicht.

D*B

Natürlich.

Allerdings ist der Aufwand da releativ hoch.
Schau mal über WRKREGINF nach den Schnittstellen.

Da gibts gleich eine ganze Reihe, je nach Art des Zugriffs:
ODBC-SQL (QZDA-Job's)
DRDA
FTP
u.v.m.

Am besten wendest du dich da aber an PCSACC/400_BUSCH&PARTNER, SOFTWARE

Lass dich nicht vom Preis abschrecken, wenn du selber was entwickeln willst, wird's mit Sicherheit erheblich teurer.

[Fuerchau]

Kompliziert nicht, aber bei SQL (ODBC) bekommt man den originären SQL-String.
Nun muss man schon einen SQL-Interpreter stricken um bei allen möglichen SQL-Befehlen die verwendeten Dateien/Tabellen zu eruieren.

Ob Select, Insert, Update oder Delete erlaubt sind, ob Administrationsbefehle, Call's oder Create's möglich sind, u.v.m.

Allein die Select-Varianten sind schon sehr vielzählig.
Ausserdem kann man "einfache" Prüfungen durch Kombinationen von
CALL QCMDEXC "OVRDBF ..."
Select * from AnyTable
oder CREATE ALIAS/CREATE VIEW mit anschliessendem Select unterlaufen.

PCSACC/400 (ohne hier Werbung machen zu wollen) deckt alle diese Varianten zur korrekten Verhinderung von unerlaubten Zugriffen ab.

Standard-Objekt-Berechtigungen (App-User, Owner-PGM'e) werden immer noch zu selten verwendet und decken eben nicht alle Möglichkeiten ab.

[BenderD]

was ist an Objektberechtigung hier komplizuert? Die Production Libs werden dicht gemacht und man stellt in einer extra Lib ein separates View Layewr bereit, mit den Daten, die für indiiduelle Auswertungen bereit stehen. Einfach, sicher und wesentlich Leistungsstärker als jeder Exit Mechanismus (geht bis auf Satzlevel runter). Die Krux mit den Exitprogrammen ist doch, dass bei Wechsle zu einer Client Server Lösung das ganze Kartenhaus zusammenbricht.

D*B

Kompliziert nicht, aber bei SQL (ODBC) bekommt man den originären SQL-String.
Nun muss man schon einen SQL-Interpreter stricken um bei allen möglichen SQL-Befehlen die verwendeten Dateien/Tabellen zu eruieren.

Ob Select, Insert, Update oder Delete erlaubt sind, ob Administrationsbefehle, Call's oder Create's möglich sind, u.v.m.

Allein die Select-Varianten sind schon sehr vielzählig.
Ausserdem kann man "einfache" Prüfungen durch Kombinationen von
CALL QCMDEXC "OVRDBF ..."
Select * from AnyTable
oder CREATE ALIAS/CREATE VIEW mit anschliessendem Select unterlaufen.

PCSACC/400 (ohne hier Werbung machen zu wollen) deckt alle diese Varianten zur korrekten Verhinderung von unerlaubten Zugriffen ab.

Standard-Objekt-Berechtigungen (App-User, Owner-PGM'e) werden immer noch zu selten verwendet und decken eben nicht alle Möglichkeiten ab.

[Fuerchau]

Naja, schön ist alle Theorie.
Leider wird eben auch bei Client-Server-Anwendungen nicht mit App-Usern gearbeitet, da man die SQL-Funktion USER benötigt (Journale, Trigger, Prüfungen, Berechtigungen).

Daher ist gerade bei Client-Server-Anwendungen dem freien Zugriff per ODBC an der Anwendung vorbei Tür und Tor geöffnet.

Hier helfen selbst die API's nicht mehr, da nun mal der Clientuser ja für die Zugriffe berechtigt sein muss.

Die Anwendung an sich muss da schon generell anders konzipiert sein.
Um mit dem originären User auf der DB arbeiten zu können, muss der SQL-Job sich ja quasi ummelden (QSYSETPH), damit das USER-Register wieder korrekt gefüllt ist.

Allerdings meldet das API nun wieder den umgemeldeten User.

So richtig habe ich bei Client-Anwendungen keine Lösung, ODBC-Zugriffe ausserhalb der Anwendung zu sperren.

Standard-Objekt-/DB-Rechte ziehen da einfach nicht.

Generelle Konzepte mit Stored-Procedures, die Datenzugriffe grundsätzlich verbergen, finde ich da auch eher selten, obwohl mir das die einzige Lösung scheint.

[BenderD]

aus der Java Perspektive gibt es da durchaus gängige Konzepte (mal unabhängig davon, was man im einzelnen davon hält). Zugriffsregeln wandern in die Applikation, alleine schon aus Caching Gründen; die Anwendung arbeitet dann mit einem Apllikations Benutzer der Datenbank (schon wegen Connection Pooling). Bei Fat Clients legt man dann die gesamte DB Zugriffsschicht auf eine Application Server und das Authentifizierungsproblem wandert von der Datenbank zur Verbindung zum Appserver.
Die stored Porcedures reissen mich nicht gerade vom Hocker, das riecht doch eher nach Verstoß gegen Schichtentrennung und zwingt zur Neuerfindung von Rädern trotz Comtainer managed Persistence von EJBs und Object relational mapping Frameworks.
Ich würde da persönlich immer ein eigenes View Layer für ODBC Zugriffe von Benutzern favorisieren, das leistet wesentlich mehr als Berechtigungskontrolle.

Dieter Bender

Naja, schön ist alle Theorie.
Leider wird eben auch bei Client-Server-Anwendungen nicht mit App-Usern gearbeitet, da man die SQL-Funktion USER benötigt (Journale, Trigger, Prüfungen, Berechtigungen).

Daher ist gerade bei Client-Server-Anwendungen dem freien Zugriff per ODBC an der Anwendung vorbei Tür und Tor geöffnet.

Hier helfen selbst die API's nicht mehr, da nun mal der Clientuser ja für die Zugriffe berechtigt sein muss.

Die Anwendung an sich muss da schon generell anders konzipiert sein.
Um mit dem originären User auf der DB arbeiten zu können, muss der SQL-Job sich ja quasi ummelden (QSYSETPH), damit das USER-Register wieder korrekt gefüllt ist.

Allerdings meldet das API nun wieder den umgemeldeten User.

So richtig habe ich bei Client-Anwendungen keine Lösung, ODBC-Zugriffe ausserhalb der Anwendung zu sperren.

Standard-Objekt-/DB-Rechte ziehen da einfach nicht.

Generelle Konzepte mit Stored-Procedures, die Datenzugriffe grundsätzlich verbergen, finde ich da auch eher selten, obwohl mir das die einzige Lösung scheint.

[Fuerchau]

Also favorisierst du auf jeden Fall den App-User.
D.h., die Standard-Hilfsmittel der Verursacherauswertung müssen mit der Anwendung neu realisiert werden (welcher User hat wann was gemacht).

Allerdings würden im Gegenzug alle User, die nicht dem App-User entsprechen als nicht autorisiert erkannt werden.

Native auf der AS/400 ist das insofern einfacher, als dass der APP-User als Owner der Programme auftritt, während die User selber als info der DB bekannt bleiben (SQL-User-Register und Journale).

Die wir aber immer noch mit Standard-Anwendungen (incl. defizitär organisiertem Zugriffsschutz) auf der AS/400 arbeiten, wird PCSACC/400 seinen Weg erfolgreich weiter beschreiten.

[holgerscherer]

Also favorisierst du auf jeden Fall den App-User.
D.h., die Standard-Hilfsmittel der Verursacherauswertung müssen mit der Anwendung neu realisiert werden (welcher User hat wann was gemacht).

Aus diesem Grunde bevorzuge ich immer noch OS-User und scheue in manchen Umgebungen ODBC wie das Weihwasser den Teufel. Ansonsten kriegt man schnell mal Probleme, bei einer forensischen Untersuchung rauszufinden, was passiert ist (arbeite gerade an so einem Fall...)

Dieter hat auf jeden Fall Recht, ohne Objektsicherheit ist alles andere nur nachträgliches Dokumentieren von Konfigurationsfehlern.

Da wir nicht wissen, wie die Umgebung bei schellchr2 aussieht, können wir nur raten und uns um die optimale Möglichkeit prügeln. Die praktikabelste Möglichkeit können wir nur raten :-)

Im übrigen spricht ja nichts dagegen, originär nur mit *owner zugreifen zu lassen, per ODBC nur über - wie von Dieter angesprochenen - berechtigte Views und im Bedarfsfalle via APIs (und bei Bedarf mit zusätzlichen Programmen) ein Zahlenschloss an die Tür zu montieren.

-h

[BenderD]

im Java Mainstream ist das so und für die entsprechende Protokollierung auf Applikationsebene gibt es Standardmechanismen (log4j). Was und wann tatsächlich mit der Datenbank passiert, entscheidet dann die persistence Schicht (EJBs oder Hibernate und Co.).
Was ich persönlich favorisiere sind einfache, transparente und dokumentierte Lösungen, nur diese sind fehlerarm implementierbar, aber bei letzterem darf man oft nicht genauer hinsehen. Allobj User, adopted Authority und LIBL, Tools kaufen statt Anforderungsdefinition schreiben, Schwachstellenanlysen statt Lösungen...

D*B

Also favorisierst du auf jeden Fall den App-User.
D.h., die Standard-Hilfsmittel der Verursacherauswertung müssen mit der Anwendung neu realisiert werden (welcher User hat wann was gemacht).

Allerdings würden im Gegenzug alle User, die nicht dem App-User entsprechen als nicht autorisiert erkannt werden.

Native auf der AS/400 ist das insofern einfacher, als dass der APP-User als Owner der Programme auftritt, während die User selber als info der DB bekannt bleiben (SQL-User-Register und Journale).

Die wir aber immer noch mit Standard-Anwendungen (incl. defizitär organisiertem Zugriffsschutz) auf der AS/400 arbeiten, wird PCSACC/400 seinen Weg erfolgreich weiter beschreiten.