Dodatek za povezljivost
Podpora za strežnik aplikacij v DB2 Universal Database za OS/390 omogoča,
da DB2 Universal Database za OS/390 deluje kot strežnik za zahtevnike
aplikacij DRDA. Odjemalec aplikacij, povezan s strežnikom aplikacij DB2
Universal Database za OS/390, je lahko :
- Zahtevnik DB2 Universal Database za OS/390
- DB2 Connect
- Izdaja DB2 Universal Database za podjetja ali Razširjena izdaja DB2
Universal Database za podjetja z omogočeno podporo za DB2 Connect.
- Zahtevnik DB2 različice 2, ki se lahko izvaja v okoljih AIX, HP-UX, OS/2,
Solaris, Windows 3.1, Windows 3.11 for Workgroups, Windows 95,
ali Windows NT, kot tudi v okoljih Macintosh, SCO, SGI ali SINIX. Ta
funkcija je na voljo v prehodu za več uporabnikov DDCS (Distributed Database
Connection Services) različice 2.3, DDCS za enega uporabnika različice
2.3 in DDCS za Windows različice 2.4.
- Zahtevnik OS/400
- Zahtevnik DB2 za VM
- Katerikoli izdelek, ki podpira protokole zahtevnika aplikacij DRDA
Za katerikoli zahtevnik aplikacij, povezan s strežnikom aplikacij DB2
Universal Database za OS/390, strežnik aplikacij DB2 Universal Database za
OS/390 podpira dostop do baze podatkov takole:
- Zahtevnik aplikacij lahko dostopa do tabel, ki so shranjene na strežniku
aplikacij DB2 Universal Database za OS/390. Zahtevnik aplikacij mora
pred zagonom aplikacije izdelati paket na strežniku aplikacij DB2 Universal
Database za OS/390. Strežnik aplikacij DB2 Universal Database za OS/390
uporablja paket v času izvajanja za iskanje stavkov SQL aplikacije.
- Zahtevnik aplikacij lahko strežnik aplikacij DB2 Universal Database za
OS/390 obvesti, da mora dostop omejiti samo na bralne aktivnosti, če povezava
med strežnikom in odjemalcem DRDA ne podpira postopka potrditve v dveh
korakih. Tako bo na primer zahtevnik DDCS V2R3 s CICS na čelu obvestil
strežnik aplikacij DB2 Universal Database za OS/390, da ažuriranje ni
dovoljeno.
- Zahtevnik aplikacij lahko dostopa tudi do tabel, shranjenih v drugih
sistemih DB2 Universal Database za OS/390 v omrežju, za kar uporabi dostop, ki
ga usmerja sistem. Dostop, ki ga usmerja sistem, zahtevniku aplikacij
omogoča vzpostavitev povezave z več sistemi baz podatkov v eni enoti
dela.
Če želite, da bo strežnik aplikacij DB2 Universal Database za OS/390
pravilno obdelal zahteve porazdeljene baze podatkov, morate narediti
naslednje:
- Definirajte strežnik aplikacij za lokalni Upravljalnik komunikacij.
- Definirajte vse možne cilje sekundarnega strežnika, da bo strežnik
aplikacij DB2 Universal Database za OS/390 lahko preusmeril zahteve SQL na
njihov končni cilj.
- Podajte potrebno zaščito.
- Omogočite predstavitev podatkov.
Če želite, da bo strežnik aplikacij sprejemal zahteve
porazdeljene baze podatkov, mora biti definiran za lokalni Upravljalnik
komunikacij in imeti enkraten RDB_NAME. Naslednja razlaga je povezana s
povezavami SNA. Za pravilno definiranje strežnika aplikacij morate
narediti naslednje:
- Izberite ime LU in RDB_NAME, ki ju bo uporabljal strežnik aplikacij DB2
Universal Database za OS/390. Postopek zapisa teh imen v DB2 Universal
Database za OS/390 in VTAM je enak postopku, ki je opisan v temi Definiranje lokalnega sistema (SNA). RDB_NAME, ki ga izberete za DB2 Universal Database
za OS/390, morate posredovati vsem končnim uporabnikom in zahtevnikom
aplikacij, ki zahtevajo povezljivost s strežnikom aplikacij.
- Vrednost NETID.LUNAME registrirajte za vse strežnike aplikacij DB2
Universal Database za OS/390 z vsemi zahtevniki aplikacij, ki zahtevajo
dostop, da bo zahtevnik aplikacij lahko usmerjal zahteve SNA na strežnik DB2
Universal Database za OS/390. To velja tudi, če zahtevnik aplikacij
lahko izvaja dinamično usmerjanje v omrežju, ker mora zahtevnik aplikacij pred
uporabo dinamičnega usmerjanja v omrežju poznati NETID.LUNAME.
- Za vsak zahtevnik aplikacij podajte privzetek TPN DRDA
(X'07F6C4C2'), ker DB2 Universal Database za OS/390 to vrednost
uporabi samodejno.
- Za vsako ime načina, ki ga potrebuje zahtevnik aplikacij, izdelajte
postavko v tabeli načinov VTAM. Te postavke opisujejo velikosti RU,
velikost okna za krmiljenje takta in razred storitve za vsako ime
načina.
- Definirajte omejitve seje za zahtevnike aplikacij, ki bodo vzpostavili
povezavo s strežnikom aplikacij DB2 Universal Database za OS/390.
Stavek APPL VTAM definira privzete omejitve seje za vse partnerske
sisteme. Če želite za določenega partnerja nastaviti enkratne
privzetke, lahko uporabite tabelo SYSIBM.LUMODES komunikacijske baze
podatkov (CDB).
Za informacije o tem, kako se pregleda omrežje VTAM, preberite Nastavitev velikosti RU in krmiljenja takta.
- V komunikacijski bazi podatkov DB2 Universal Database za OS/390 izdelajte
postavke, s katerimi boste določili, kateri zahtevniki aplikacij lahko
vzpostavijo povezavo s strežnikom DB2 Universal Database za OS/390.
Postavke komunikacijske baze podatkov za zahtevnike aplikacij v omrežju lahko
definirate na dva načina:
- V tabelo SYSIBM.LUNAMES lahko vstavite vrstico, ki podaja uporabo
privzetih vrednosti za vse LU-je, ki niso specifično opisani v komunikacijski
bazi podatkov (privzeta vrstica je v stolpcu LUNAME prazna). Ta način
omogoča, da definirate specifične lastnosti za nekatere LU-je v omrežju, za
vse druge LU-je pa uporabite privzetke.
Tako lahko na primer sistemu DALLAS (drug sistem DB2 Universal Database za
OS/390) omogočite pošiljanje že preverjenih zahtev porazdeljene baze podatkov
(LU 6.2 SECURITY=SAME), in od sistemov upravljalnik baz podatkov
zahtevate, da pošiljajo gesla. V CDB lahko za vsak sistem Upravljalnika
baz podatkov vpišete postavko, še posebej, če je teh sistemov več. Slika 25 kaže, kako lahko CDB uporabite za podajanje SECURITY=SAME za
sistem DALLAS, za vse druge zahtevnike pa uveljavite SECURITY=PGM.
Slika 25. Vzpostavljanje privzetkov za povezave zahtevnika aplikacij (SNA)
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES (' ', ' ', 'C', 'N', 'N', ' ');
|
- CDB lahko uporabite, če želite vsakemu zahtevniku aplikacij v omrežju
ločeno dodeliti pooblastilo; to naredite tako, da CDB nastavite na enega
izmed naslednjih načinov:
- V tabelo SYSIBM.LUNAMES ne vpišite privzete vrstice. Če
privzete vrstice (vrstice, ki vsebuje prazno ime LU) ni, DB2 Universal
Database za OS/390 zahteva vrstico v SYSIBM.LUNAMES, ki vsebuje ime LU
za vsak zahtevnik aplikacij, ki poskusi vzpostaviti povezavo. Če
zahtevnik aplikacij v CDB ne najde ustrezne vrstice, bo dostop
zavrnjen.
- V SYSIBM.LUNAMES vpišite privzeto vrstico, ki podaja, da je
preverjanje izvora zahtevano (stolpec USERNAMES je nastavljen na 'I'
ali 'B'). To povzroči, da DB2 Universal Database za OS/390
omeji dostop samo na zahtevnike aplikacij in končne uporabnike, določene v
tabeli SYSIBM.USERNAMES, kot je opisano v temi Preverjanje izvora. Ta pristop lahko uporabite, če pravila za prevajanje
imena zahtevajo, da je v SYSIBM.LUNAMES vrstica s praznim imenom LU,
vendar ne želite, da DB2 Universal Database za OS/390 to vrstico uporabi za
omogočanje neomejenega dostopa do strežnika aplikacij DB2 Universal Database
za OS/390.
V Slika 26 nobena vrstica v stolpcu LUNAME ne vsebuje praznega polja,
zato DB2 Universal Database za OS/390 zavrne dostop za vse LU-je, razen za
LUDALLAS ali LUNYC.
Slika 26. Določanje posameznih povezav zahtevnika aplikacij (SNA)
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', ' ');
|
Če želite, da bo strežnik aplikacij sprejemal zahteve
porazdeljene baze podatkov prek povezav TCP/IP, mora biti definiran za lokalni
podsistem TCP/IP in imeti enkraten RDB_NAME. Poleg tega mora nabor
znakov s samodejnim zagonom DB2 Universal Database za OS/390 vključevati
potrebne parametre, morda pa bo potrebno tudi ažurirati komunikacijsko bazo
podatkov (CDB) DB2 Universal Database za OS/390.
- Informacije o nastavitvi TCP/IP na strežniku aplikacij lahko najdete v
priročniku DB2 Universal Database za OS/390 Installation
Reference. Nastavitev zahtevnika aplikacij je opisana v
priročnikih Hitri začetki za izdajo DB2 za podjetja za
OS/2 in Windows in Hitri začetki izdaje DB2 Connect za osebno uporabo.
- Slika 18 kaže zgled definicije nabora podatkov s samodejnim
zagonom.
- Ažuriranje komunikacijske baze podatkov ni potrebno, če boste uporabljali
samo vhodne povezave baze podatkov; če torej nameravate DB2 Universal
Database za OS/390 uporabljati samo kot strežnik, komunikacijske baze podatkov
ni potrebne poseliti, saj bodo uporabljene privzete vrednosti. Sledi
preprost zgled, ki kaže ažuriranje tabele SYSIBM.IPNAMES.
Če želite dovoliti vhodne zahteve povezave baze podatkov za vozlišča
TCP/IP, lahko to tabelo ažurirate z ukazom SQL takole:
INSERT INTO SYSIBM.IPNAMES (LINKNAME) VALUES(' ')
Pri tem, ko zahtevnik aplikacij usmerja zahtevo porazdeljene baze podatkov
na strežnik aplikacij DB2 Universal Database za OS/390, morate upoštevati
naslednjo problematiko v zaščiti:
- Preverjanje izvora
- Izbira imen končnih uporabnikov
- Parametri za zaščito omrežja
- Zaščita Upravljalnika baz podatkov
- Zaščita, ki jo uveljavi zunanji zaščitni podsistem
Ko strežnik aplikacij DB2 Universal Database za OS/390 od zahtevnika
aplikacij prejme ime končnega uporabnika, lahko omeji imena končnih
uporabnikov, ki jih prejme od določenega zahtevnika aplikacij. To
doseže z uporabo preverjanja izvora. Preverjanje izvora
strežniku aplikacij omogoča, da poda, da lahko določen ID uporabnika
uporabljajo samo določeni partnerji. Tako lahko na primer strežnik
aplikacij uporabnika JONES omeji na "izvor" DALLAS. Če drug
zahtevnik aplikacij (ki ni DALLAS) poskusi strežniku aplikacij poslati ime
JONES, lahko strežnik aplikacij zavrne zahtevo, ker ime ne prihaja iz
pravilnega omrežnega mesta.
DB2 Universal Database za OS/390 izvaja preverjanje izvora kot del prevoda
vhodnega imena končnega uporabnika, ki je opisano v naslednjem
razdelku.
Opomba: | Za vhodne zahteve se ne izvedeta prevod vhodnega imena in preverjanje
izvora.
|
ID uporabnika, ki ga pošlje zahtevnik aplikacij, morda ni enkraten v
celotnem omrežju SNA. Strežnik aplikacij DB2 Universal Database za
OS/390 bo za izdelavo enkratnih imen končnih uporabnikov v omrežju SNA morda
moral izvesti prevod vhodnega imena. Podobno bo morda moral strežnik
aplikacij DB2 Universal Database za OS/390 za posredovanje enkratnih imen
končnih uporabnikov sekundarnim strežnikom, ki so vključeni v aplikacijo,
prevesti tudi izhodno ime (preberite temo Omogočanje zaščite, kjer boste našli informacije o prevodu izhodnih imen
končnih uporabnikov).
Prevod vhodnega imena omogočite tako, da stolpec USERNAMES tabele
SYSIBM.LUNAMES ali SYSIBM.IPNAMES nastavite na 'I'
(vhodni prevod ) ali na 'B' (vhodni in izhodni prevod ). Če
uveljavite prevod vhodnega imena, DB2 Universal Database za OS/390 prevede ID
uporabnika, ki ga pošlje zahtevnik aplikacij in ime lastnika načrta DB2
Universal Database za OS/390 (če je zahtevnik aplikacij drug sistem DB2
Universal Database za OS/390).
Če zahtevnik aplikacij za besedo APPC ALLOCATE pošlje ID uporabnika in
geslo, bosta oba preverjena pred prevodom ID-ja uporabnika. Stolpec
PASSWORD tabele SYSIBM.USERNAMES se ne uporablja za preverjanje
gesla. Namesto tega sta ID uporabnika in geslo v preverjanje poslana
zunanjemu sistemu za zaščito (RACF ali njemu enakovreden izdelek).
Ko je vhodni ID uporabnika za besedo ALLOCATE preverjen, ima DB2 Universal
Database za OS/390 izhode za pooblastila, ki jih lahko uporabite za
posredovanje seznama sekundarnih AUTHID-ejev in izvajanje dodatnega
preverjanja zaščite. Za podrobnosti glejte DB2 Universal Database
za OS/390 Administration Guide.
Postopek prevajanja vhodnega imena v tabeli SYSIBM.USERNAMES poišče
vrstico, ki se mora ujemati z enim izmed vzorcev, prikazanem na naslednjem
seznamu prednosti (TYPE.AUTHID.LINKNAME):
- I.AUTHID.LINKNAME--Določen končni uporabnik z
določenega zahtevnika aplikacij
- I.AUTHID.blank--Določen končni uporabnik s kateregakoli
zahtevnika aplikacij
- I.blank.LINKNAME--Katerikoli končni uporabnik z
določenega zahtevnika aplikacij
Če vrstica ni najdena, je oddaljeni dostop zavrnjen. Če je vrstica
najdena, bo oddaljeni dostop omogočen, ime končnega uporabnika pa bo
spremenjeno v vrednost, ki jo podaja stolpec NEWAUTHID, pri čemer bo vrednost
NEWAUTHID prazna, kar pomeni, da ime ni spremenjeno. Vsa preverjanja
pooblastil sredstev DB2 Universal Database za OS/390 (na primer pooblastila
tabele SQL), ki jih opravi DB2 Universal Database za OS/390, se izvedejo na
prevedenih imenih končnih uporabnikov in ne na izvirnih imenih.
Ko strežnik aplikacij DB2 Universal Database za OS/390 od zahtevnika
aplikacij prejme ime končnega uporabnika, lahko z zmožnostjo za prevod
vhodnega imena DB2 Universal Database za OS/390 dosežete več stvari:
- Spremenite ime končnega uporabnika tako, da bo enkratno. Tako na
primer naslednji stavki SQL prevedejo ime končnega uporabnika JONES iz
zahtevnika aplikacij NEWYORK (LUNAME LUNYC) v drugo ime (NYJONES).
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'JONES', 'LUNYC', 'NYJONES', ' ');
- Ime končnega uporabnika lahko spremenite tako, da je skupina končnih
uporabnikov predstavljena z enim samim imenom. Morda boste na primer
želeli predstaviti vse uporabnike iz zahtevnika aplikacij NEWYORK (LUNAME
LUNYC) z imenom uporabnika NYUSER. To omogoča, da uporabniku NYUSER
dodelite pooblastila SQL, omogoča pa tudi krmiljenje dostopa SQL, ki je
dodeljen uporabnikom iz zahtevnika aplikacij NEWYORK.
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUNYC', 'NYUSER', ' ');
- Omejite lahko imena končnih uporabnikov, ki jih prenese določen zahtevnik
aplikacij. Ta uporaba prevoda imena končnega uporabnika izpolnjuje
preverjanje izvora, ki je opisano v temi Preverjanje izvora. Tako na primer spodnji stavki SQL dopuščajo samo
SMITH in JONES kot imeni končnih uporabnikov iz zahtevnika aplikacij
NEWYORK. Za vsa druga imena bo dostop zavrnjen, saj niso navedena v
tabeli SYSIBM.USERNAMES.
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'SMITH', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'JONES', 'LUNYC', ' ', ' ');
- Omejite lahko zahtevnike aplikacij, ki lahko vzpostavijo povezavo s
strežnikom aplikacij DB2 Universal Database za OS/390. To je še ena
izmed funkcij preverjanja izvora. Naslednji zgled sprejme katerokoli
ime končnega uporabnika, ki ga pošlje zahtevnik aplikacij NEWYORK (LUNYC) ali
zahtevnik aplikacij CHICAGO (LUCHI). Za druge zahtevnike aplikacij bo
dostop zavrnjen, ker privzeta vrstica SYSIBM.LUNAMES podaja prevod
vhodnega imena za vse vhodne zahteve.
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES (' ', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUCHI', ' ', ' ');
LU 6.2 za povezave SNA nudi tri glavne funkcije za zaščito
omrežja:
- Zaščita na ravni seje
- Zaščita na ravni pogovora
- Šifriranje
Tema Zaščita omrežja razlaga, kako se poda zaščita na ravni seje in šifriranje z
DB2 Universal Database za OS/390. Strežnik aplikacij DB2 Universal
Database za OS/390 uporablja zaščito na ravni seje in šifriranje popolnoma
enako kot zahtevnik aplikacij DB2 Universal Database za OS/390.
Edina problematika, ki je še preostala v zvezi z zaščito omrežja, je
zaščita na ravni pogovora SNA. Nekateri vidiki zaščite na ravni
pogovora so značilni za strežnik aplikacij DB2 Universal Database za
OS/390. Strežnik aplikacij DB2 Universal Database za OS/390 ima v
zaščiti omrežja dve različni vlogi:
- Kot zahtevnik za sekundarne strežnike, je strežnik aplikacij DB2 Universal
Database za OS/390 odgovoren za izdajanje zahtev APPC, ki vsebujejo parametre
zaščite na ravni pogovora, ki jih zahtevajo sekundarni strežniki.
Strežnik aplikacij DB2 Universal Database za OS/390 uporablja stolpec
USERNAMES tabel SYSIBM.LUNAMES in SYSIBM.USERNAMES, da za vsak
sekundarni strežnik definira zahteve za zaščito na ravni pogovora SNA.
Podrobnosti teh zahtev so popolnoma enake zahtevam v temi Zaščita omrežja.
- Kot strežnik za zahtevnik aplikacij, strežnik aplikacij DB2 Universal
Database za OS/390 določa zahteve za zaščito na ravni pogovora SNA za
zahtevnik aplikacij. DB2 Universal Database za OS/390 za določanje
zaščite pogovora, ki jo zahteva vsak zahtevnik aplikacij v omrežju, uporablja
stolpec USERSECURITY tabele SYSIBM.LUNAMES. V stolpcu
USERSECURITY so uporabljene naslednje vrednosti:
- C
- Kaže, da DB2 Universal Database za OS/390 od zahtevnika aplikacij zahteva,
da z vsako zahtevo porazdeljene baze podatkov pošlje ID uporabnika in geslo
(LU 6.2 SECURITY=PGM). Če stolpec ENCRYPTPSWDS tabele
SYSIBM.LUNAMES vsebuje vrednost 'Y', DB2 Universal Database za
OS/390 privzame, da geslo že uporablja šifrirano obliko RACF (to je možno samo
za zahtevnik aplikacij DB2 Universal Database za OS/390). Če stolpec
ENCRYPTPSWDS ne vsebuje vrednosti 'Y', DB2 Universal Database za
OS/390 pričakuje, da bo geslo uporabljalo običajni format LU 6.2
(predstavitev znakov EBCDIC). V obeh primerih DB2 Universal Database za
OS/390 pošlje ID uporabnika in geslo v podsistem za zaščito, ki ju
preveri. Imeti morate podsistem za zaščito, ki omogoča preverjanje
ID-ja uporabnika in gesla APPC; takšen sistem je na primer RACF.
Če podsistem za zaščito zavrne par ID-ja uporabnika in gesla, bo dostop do
porazdeljene baze podatkov zavrnjen.
- Katerakoli druga vrednost
- To kaže, da lahko zahtevnik aplikacij pošlje že preverjeni ID uporabnika
(LU 6.2 SECURITY=SAME) ali ID uporabnika in geslo (LU 6.2
SECURITY=PGM). Če pošlje ID uporabnika in geslo, ju DB2 Universal
Database za OS/390 obdela, kot je opisano za možnost 'C'
zgoraj. Če zahteva vsebuje samo ID uporabnika, bo poklican podsistem za
zaščito, ki overi uporabnika, razen v primeru, če za upravljanje vhodnih
ID-jev uporabnikov uporabljate tabelo sysusernames.
Če je odkrita kršitev zaščite, LU 6.2 od strežnika aplikacij DB2
Universal Database za OS/390 zahteva, da zahtevniku aplikacij vrne kodo
zaznavanja napake v zaščiti SNA ('080F6051'X). Ker ta koda
zaznavanja ne opisuje vzroka napake, DB2 Universal Database za OS/390 nudi dva
načina za beleženje vzroka kršitev v porazdeljeni zaščiti:
- Izdelano je sporočilo DSNL030I, ki podaja LUWID zahtevnika in koda vzroka
DB2, ki opisuje napako. DSNL030I vključuje tudi AUTHID, če je znan,
poslan v zahtevi aplikacije, ki je bila zavrnjena.
- V bazi podatkov za nadzor strojne opreme NETVIEW je zabeleženo opozorilo,
ki vsebuje enake informacije, kot so na voljo v sporočilu DSNL030I.
Kot lastnik sredstev baze podatkov strežnik aplikacij DB2 Universal
Database za OS/390 krmili funkcije za zaščito baze podatkov za objekte SQL, ki
so na strežniku aplikacij DB2 Universal Database za OS/390. Dostop do
objektov, ki jih upravlja DB2 Universal Database za OS/390, krmilijo
pooblastila, ki ji uporabnikom dodelijo skrbnik DB2 Universal Database za
OS/390 ali lastniki posameznih objektov. Dva osnovna razreda objektov,
ki jih krmili strežnik aplikacij DB2 Universal Database za OS/390, sta:
Ko izdelate paket, možnost DISABLE/ENABLE omogoča, da
nadzorujete, kateri tipi povezav DB2 Universal Database za OS/390 lahko
izvajajo paket. Če želite končnim uporabnikom selektivno omogočiti
uporabo DDF, lahko uporabite RACF in izhodne podprograme
za zaščito DB2 Universal Database za OS/390. RLF lahko
uporabite za podajanje omejitev za čas procesorja za oddaljene povezave in
izvajanja dinamičnega SQL.
Za primer vzemimo paket DB2 Universal Database za OS/390 z imenom
MYPKG, katerega lastnik je JOE. JOE lahko SAL omogoči
izvajanje paketa z izdajo stavka DB2 Universal Database za OS/390 GRANT
USE. Če SAL izvede paket, se zgodi naslednje:
- DB2 Universal Database za OS/390 preveri, ali ima SAL pooblastilo za paket
USE.
- SAL lahko izvaja vse stavke statičnega SQL v paketu, ker ima JOE potrebna
pooblastila objekta SQL za izdelavo paketa.
- Če paket vsebuje stavke dinamičnega SQL, mora imeti SAL svoja lastna
pooblastila tabele SQL. Tako na primer SAL more izdati stavka
SELECT * FROM JOE.TABLE5, če za JOE.TABLE5 nima
bralnega dostopa.
Način, na katerega strežnik aplikacij DB2 Universal Database za OS/390
uporablja zaščitni podsistem (RACF ali enakovreden izdelek) je odvisen od
tega, kako v tabeli SYSIBM.LUNAMES definirate funkcijo za prevod
vhodnega imena:
- Če za stolpec USERNAMES podate 'I' ali 'B', je funkcija
prevajanja vhodnega imena aktivna, DB2 Universal Database za OS/390 pa
privzame, da skrbnik DB2 Universal Database za OS/390 prevod vhodnega imena
uporablja kot del izvajanja zaščite sistema. Zunanji podsistem za
zaščito bo poklican samo, če zahtevnik aplikacij pošlje zahtevo, ki vsebuje ID
uporabnika in geslo (SECURITY=PGM). Imeti morate podsistem za zaščito,
ki omogoča preverjanje ID-ja uporabnika in gesla APPC; takšen sistem je
na primer RACF.
Če zahteva zahtevnika aplikacij vsebuje samo ID uporabnika (SECURITY=SAME),
zunanji zaščitni sistem sploh ne bo poklican, ker pravila za prevod vhodnega
imena definirajo, kateri uporabniki lahko vzpostavijo povezavo s strežnikom
aplikacij DB2 Universal Database za OS/390.
- Če za stolpec USERNAMES ne podate 'I' ali 'B',
podsistem za zaščito preveri naslednje:
- Ko zahtevnik aplikacij pošlje zahtevo porazdeljene baze podatkov, DB2
Universal Database za OS/390 pokliče zunanji podsistem za zaščito, ki preveri
ID končnega uporabnika (in geslo, če je podano).
- Poklican bo zunanji podsistem za zaščito, ki preveri, ali ima končni
uporabnik pooblastilo za vzpostavitev povezave s podsistemom DB2 Universal
Database za OS/390.
- V obeh primerih bo izhod za pooblastila posredoval seznam sekundarnih
pooblastitvenih ID-jev. Za dodatne informacije glejte DB2
Universal Database za OS/390 Administration Guide.
Zagotoviti morate, da vaš podsistem DB2 Universal Database
za OS/390 lahko pretvori CCSID posameznih zahtevnikov aplikacij v namestitveni
CCSID podsistema DB2 Universal Database za OS/390. Za podrobnejše
informacije preglejte temo Predstavitev podatkov.
[ Vrh Strani | Predhodna Strani | Naslednja Strani | Obsah | Seznam ]