nochmal Sicherheit ..

[loeweadolf]

Guten Tag,

ich habe das vergangene Wochenende mißbraucht, um mich näher mit dem Thema "Sicherheit" auseinanderzusetzen.

(Als Einzelkämpfer bin ich froh, dass es dieses Forum gibt, da ich sonst kaum Gelegenheit habe zum Gedankenaustausch, nur nebenbei ..)

Bei einem Kunden mit "offenem Scheunentoren" soll jetzt ein Sicherheitskonzept (möglichst mit wenig Aufwand) erstellt werden. Wenn Berechtigungslisten für Objekte und Gruppenprofile erstellt werden, und entspr. Zuordnungen, dann ist das schon ein Menge Arbeit.

Bei diesem Kunden werden ca. 50% der Anwendungen (alles, was von mir kommt) über ein Startprogramm (hinterlegt im Benutzerprofil) aufgerufen. Dieses Startprogramm ruft ein Menü-Programm auf. Hier ist in pflegbaren Dateien hinterlegt, wer welches Programm aufrufen darf, und weiterhin ist angegeben, wer in welchem programm welche Daten ändern darf und wer nicht.
(z.B.: Kundenstamm: eingie dürfen ändern, viele dürfen ansehen)

Soweit ich verstanden habe, werden die Berechtigungen
des Eigners des ersten aufgerufenen Programmes übernommen für alle weitere daraus resultierenden Aufrufe und Datenbankzugriffe.
Das Startprogramm, das ja automatisch beim Anmelden aufgerufen wird, ist als oberste Ebene während der
ganzen SItzung aktiv.

Wenn ich jetzt hingehen würde und alle entspr. Bibliotheken mit der Berechtigung *PUBLIC = *EXCLUDE kennzeichnen würde, dann würden die Programme, die über das Startprogramm aufgerufen würden, weiter funktiobieren, aber es wäre keinem "Gemeinen User" gestattet, auf anderem Wege Zugriff zu bekommen, zumal ich im Userprofil dann noch für alle User die "Möglichkeit einschränken" mit *YES beantworten würde (das heisst: keine Eingabe über Befehlszeile).

Sollte das mit den Bibliotheken nicht ausreichen, so könnte ich den Systemarameter QCRTAUT von *ALL !! ändern auf *EXCLUDE, alle Programme + Dateien in eine andere Bilbliothek kopieren (dadurch würden diese ja neu erstellt werden, oder?).

Mich würde interessieren, ob ich richtig liege mit meinem Ansatz oder ob ich was falsch verstanden habe oder übersehen habe.

Wäre mit obigem Schutz auch ein Zugriff von außerhalb durch FTP unterbunden ?


Vielen Dank für Feedback.


mfg. Ludger

[Fuerchau]

Teileweise bist du auf dem richtigen Weg.

Das Startprogramm:
Wenn das Startprogramm in einer Lib steht, die geschützt ist (*PUBLIC *EXCLUDE) kann dieses erst gar nicht zur Ausführung kommen (kein Zugriff auf die Lib).
Also:
Das Startprogramm muss schon mal in eine Lib mit *PUBLIC *USE !

Für Dialogprogramme ist das dann soweit in Ordnung.

Aber wie siehts beim Batch aus ?
Batch kennt kein Startprogramm !!!
Meistens wird ein Programm als Batch vom aktuellen User übergeben. Dieses Programm muss natürlich in einer Lib mit *PUBLIC *USE liegen und die gleichen Bedingungen wie das Dialog-Startprogramm aufweisen (*OWNER usw.), es ist ja schließlich das Startprogramm des Batchjobs.

Verwendest du JOBD's ? Dann benötigt der Benutzer auch *USE-Berechtigung an diesen Objekten, da diese zum initialisieren eines Job's benötigt werden.

Die Anwendung muss also in mind. 2 Lib's getrennt werden.
1. Daten-Lib (*PUBLIC *EXCLUDE)
2. PGM-Lib (*PUBLIC *USE) *USE ist deshalb wichtig, damit keine Benutzer die Lib verändern kann, dies heisst auch hinzufügen/löschen von Objekten ist nicht erlaubt.

Es reicht nur die sog. Start-Programme in die PGM-Lib zu legen. Wenn diese allerdings nicht immer alle bekannt sind, eben alle PGM'e rein umd mit *OWNER-Ausführung kennzeichnen.

Dein FTP/ODBC/DRDA-Problem ist damit gelöst.

Bleibt nur noch dein Anmelde-Problem

Ach ja, einen hab ich noch:
*ALLOBJ-Berechtigung macht alles kaputt !

[loeweadolf]

Hallo Baldur,

das finde ich ja klasse, dass Du Dir die Zeil genommen hast, mich mit meinem Beitrag auseinanderzusetzen.

Mir ist dazu noch folgendes aufgefallen:

Wenn ich alle "Startprogramme", d.h., die mit SBMJOB aufgerufenen Programme auch in die Extra-Lib mit *USE-Berechtigung einstelle, könnte dann nicht jemand von außerhalb (PC) so ein Startprogrammt aufrufen ?.
Durch den eingetragenen OWNER würde er dann alle Berechtiungen haben.
Gibt es nicht einen Weg, die Batch-Startprogramme in der geschützen Bibliothek zu belassen und die Berechtigungen beim Aufruf dieses Programmes mitzugeben ?

JOBD: ja, wird teilweise verwendet, z.B.: um eine bestimmte JOBQ anzusprechen, okay ändern auf *USE

*ALLOBJ, der User darf natürlich nicht *ALLOBJ haben. Ich gehe davon aus, das der OWNER des Startprogrammes, welches bei den Usern im Benutzerprofil als Startprogramm steht, das schon wohl haben darf (muss).


mfg. Ludger

[Fuerchau]

Nun, welchen Sinn könnte es haben, die Startprogramme von aussen aufzurufen ?
Verhindern könnte man das mit verborgenen Aufrufparametern, *LDA-Init's, o.ä.
Ausserdem sind Batch-Programme ja für ganz bestimmte Aufgaben konzipiert und machen nix anderes als das wofür sie gedacht sind.

Der Owner benötigt auch kein *ALLOBJ, da er ja die Berechtigung an den Objekten bereits hat.

[loeweadolf]

Nun, welchen Sinn könnte es haben, die Startprogramme von aussen aufzurufen ?
Verhindern könnte man das mit verborgenen Aufrufparametern, *LDA-Init's, o.ä.

Bei Hackern braucht man keinen Sinn.

Das mit dem *LDA-Inits ist sicher ein gangbarer Weg.

Ich habe allerdings nochmal in Unterlagen nachgeschlagen und dort den Hinweis erhalten, dass den Start-Propgrammen der JOBQ die Berechtigung eines berechtigten Users mitgegeben werden kann.

Beim SBMJOB den Paramer: USER mit einem berechtigten User-Namen füllen. Ich weiß allerdings nicht, welche Auswirkungen das sonst noch haben könnte.

mfg. Ludger

[Fuerchau]

Wenn ein SBMJOB ... USER(XYZ) übergeben wird, benötigt der submittende User natürlich eine *USE-Berechtigung an dem User XYZ !
Was hindert einen Hacker daran dies auch zu tun ?

Das einzig sinnvolle ist, kein Batch-PGM OHNE Aufrufparameter zu erstellen.
Ein Hacker weiß selten, welche Parameter benötigt werden. Dies läßt sich auch nicht herausfinden.

PS:
Bei ILE-Programmen mit Parametern läßt sich per DSPPGM die Anzahl der Parameter nicht mehr feststellen, sie sind immer 0 bis 255.
Bei OPM-CLP's ist die Anzahl fest, bei OPM-HLL's immer 0 bis Anzahl-Parameter.
ILE würde das Herausfinden der Aufrufe also erschweren.

[LGALF]

Hallo Ludger, ich betreue LOHN-Anwendungen hier sind die Berechtigungen über USER-Profile und Bibliotheken geregelt.

Bei allen Objekten (ausser USER-Profile) ist der Eigener LOHNINST und PUBLIC *CHANGE.
Nur wer rechte auf die LIB hat kann Programme der LIB laufen lassen.
Programme laufen unter der Berechtigung von LOHNINST.

Hinweis zur Druckausgabe:
!! Bei USER-Profilen *SPLCTL für Druckausgabe herausnehmen und Drucker/OUTQs je USER bzw. je Gruppe steuern. !!
------------------------------------------------------------
USER LOHNxx können nur innerhalb ihrer Anwendung Abläufe durchführen.
Andere USER (Normal-USER ohne ALLOBJ) kommen aufgrund *EXCLUDE nicht in die LIB und somit nicht an die Objekte.
------------------------------------------------------------
Bibliotheken: LGIALIB - LGIOLIB = Anwendungssteuerungsobjekte,
Programme, OUTQs
LGIDLIBxx = Daten (xx=Bestand)
(Dies ist nur ein Auszug von Bibliotheken als Beispiel)
------------------------------------------------------------
USER:
LOHNINST = Benutzerprofil zum Installieren
= Eigner aller Objekte.
Benutzerklasse . . . . . . . . . . : *USER
Sonderberechtigung . . . . . . : *JOBCTL *SAVSYS
---
LOHNxx = Benutzerprofil des Anwenders für Daten aus LGIDLIBxx
Benutzerklasse . . . . . . . . . . . . : *USER
Sonderberechtigung . . . . . . . . : *NONE
Gruppenprofil . . . . . . . . . . . . . : *NONE
Startprogramm . . . . . . . . . . : CLGIMN0
Bibliothek . . . . . . . . . . .. . . . : LGIALIB
(weitere LOHNyy-User mögich)
------------------------------------------------------------
Berechtigungen LIBs:
---
DSPOBJAUT OBJ(LGIALIB) OBJTYPE(*LIB)
- Objektberechtigung anzeigen
---
Objekt . . . . : LGIALIB Eigner . . .. : LOHNINST
Bibliothek . . : QSYS Primärgruppe . . : *NONE
Objektart . . . . . : *LIB Objekt durch Berechtigungsliste geschützt . : *NONE

Benutzer Gruppe Objektberechtg.
LOHNINST *ALL LOHNxx *CHANGE
(weitere LOHNyy möglich)
*PUBLIC *EXCLUDE
------------------------------------------------------------
DSPOBJAUT OBJ(LGIdLIBxx) OBJTYPE(*LIB)
Objektberechtigung anzeigen
---
Objekt . . . : LGIDLIBxx Eigner . . .. . . : LOHNINST
Bibliothek. . : QSYS Primärgruppe . . . . : *NONE
Objektart . . . . . :LIB
Objekt durch Berechtigungsliste geschützt . . . : *NONE

Benutzer Gruppe Objektberechtg.
LOHNINST *ALL
LOHNxx *CHANGE (nur LOHNxx alleine)
*PUBLIC *EXCLUDE
------------------------------------------------------------
Berechtigungen Programme (Startprogramm):
---
DSPOBJAUT OBJ(LGIALIB/CLGIMN0) OBJTYPE(*PGM)
Objektberechtigung anzeigen
---
Objekt . . . : CLGIMN0 Eigner . . . .. . : LOHNINST
Bibliothek . : LGIALIB Primärgruppe . . . : *NONE
Objektart . . . . . :*PGM Objekt durch Berechtigungsliste geschützt . . . : *NONE

Benutzer Gruppe Objektberechtg.
LOHNINST *ALL
*PUBLIC *CHANGE
(da Berechtigung über Bibliothek)
------------------------------------------------------------
Berechtigungen Daten (Anwender-Datei):
---
DSPOBJAUT OBJ(LGIDLIBxx/LGILASTA) OBJTYPE(*FILE)
Objektberechtigung anzeigen
---
Objekt . . . : LGILASTA Eigner . . . . . : LOHNINST
Bibliothek. : LGIDLIBxx Primärgruppe . . . : *NONE
Objektart . . . . . :*FILE Objekt durch Berechtigungsliste geschützt . . : *NONE
---
Benutzer Gruppe Objektberechtg.
LOHNINST *ALL
*PUBLIC *CHANGE

-----------------------------------------------------------
Viele Grüsse Alf

[Fuerchau]

@Alf

Genau das ist ja das Problem !
Wenn ich als LOHNxx-User Berechtigung an der LGIDLIBxx habe, komme ich eben auch per ODBC/DRDA an die Dateien. Und genau DAS soll verhindert werden.

Es ist ja generell so, dass ich normalerweise als User die Berechtigungen benötige um die Programme zu starten die wiederum die Daten bearbeiten.
Aber genau hier ist ja die Sicherheitslücke seit dem Einsatz von PC's (siehe auch PC-Support).
Wenn ich als User Berechtigungen besitze, komme ich eben auch an den Programmen VORBEI an die Daten und kann sie ggf. manipulieren.
Da helfen mir auch keine komplexen Menü-Berechtigungen und PGM-Steuerungen, da ich die ja nicht verwende.

Und genau DARUM ist dein Berechtigungsschema für die Katz !!!!!

Es brauch sich ja nur einer ein Kennwort von einem LOHNxx "besorgen" und kann schon lustig per ODBC mit den Daten spielen. MS-Access (o.ä.) unterstützt dabei sogar freundlicherweise.

[loeweadolf]

@Alf
Vielen Dank für Dein Beispiel

@Baldur
Ich werde es mit den submitteten Jobs so machen, wie vorgeschlagen, überprüfen auf Übergabeparameter und gegebenfalls welche hinzufügen bzw. LDA-Übergabe überprüfen.

Bei dem Konzept sollte es für einen berechtigten User, auch vom PC aus, keine Möglichkeit geben, ausserhalb der Möglichkeiten, die ihm das Startprogramm bietet, tätig zu werden.
Dabei muss natürlich noch geprüft werden, dass wirklich nur ganz bestimmte Nutzer *ALLOBJ haben.

Für gewollte Zugriffe per FTP (zum Beispiel um Daten abzuholen), werde ich eine eigene Bibliothek einrichten nur mit den benötigten Dateien, die mit *EXCLUDE geschützt sind und nur entspr, Berechtigungen erlauben für einen bestimmten Personenkreis.

Ich denke, viel mehr kann man nicht tun, ausser natürlich eine Möglichkeit einzusetzen, den Datenstrom vom PC zu verschlüsseln, um ein Auslesen der Kennwörter zu verhindern.

mfg. Ludger

[Fuerchau]

Da bist du auf dem richtigen Weg.
Prüfe aber vorrangig die Verwendung von AUTL's (CRTAUTL/WRKAUTL).
An einem Objekt kannst du entweder max. 50 User oder 1 Autl schützen.
Hängst du an die Objekte eine AUTL brauchst du nur die AUTL zu pflegen, ansonsten ist jedes Objekt einzeln zu bearbeiten.

Für ODBC/DRDA-Zugriffe solltest du auch entsprechende Lib's mit View's bzw. LF's einrichten. Hier kann man dann sogar Mandanteneinschränkungen treffen.