Dodatek za povezljivost
Podpora za strežnik aplikacij v DB2 za MVS/ESA omogoča, da DB2 za MVS/ESA
deluje kot strežnik za zahtevnike aplikacij DRDA. Odjemalec aplikacij,
povezan s strežnikom aplikacij DB2 za MVS/ESA, je lahko:
- Zahtevnik DB2 za MVS/ESA
- DB2 Connect Različica 7, ki se lahko izvaja v okoljih AIX, HP-UX, OS/2,
SCO, Solaris, Linux, Windows 9x ali Windows NT.
- Izdaja DB2 Universal Database za podjetja Različica 7 ali Razširjena
izdaja DB2 Universal Database za podjetja z omogočeno podporo za DB2
Connect.
- Zahtevnik DDCS (Distributed Database Connection Services) 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 SCO, SGI ali SINIX.
- 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 za
MVS/ESA, strežnik aplikacij DB2 za MVS/ESA podpira dostop do baze podatkov
takole:
- Odjemalec aplikacij lahko dostopa do tabel, shranjenih na strežniku
aplikacij DB2 za MVS/ESA. Odjemalec aplikacij mora pred zagonom
aplikacije izdelati paket na strežniku aplikacij DB2 za MVS/ESA.
Strežnik aplikacij DB2 za MVS/ESA uporablja paket v času izvajanja za iskanje
stavkov SQL aplikacije.
- Če povezava med strežnikom in odjemalcem DRDA ne podpira postopka
potrditve v dveh korakih, lahko zahtevnik aplikacij strežnik aplikacij DB2 za
MVS/ESA obvesti, da mora biti dostop omejen samo na bralne aktivnosti.
Tako bo na primer zahtevnik V2R3 DB2 za MVS/ESA s CICS na čelu obvestil
strežnik aplikacij DB2 za MVS/ESA, da ažuriranje ni dovoljeno.
- Odjemalec aplikacij ima lahko tudi omogočen dostop do tabel, shranjenih v
drugih sistemih DB2 za MVS/ESA 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 za MVS/ESA 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 lahko strežnik
aplikacij DB2 za MVS/ESA 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. Za pravilno definiranje
strežnika aplikacij morate narediti naslednje:
- Izberite ime LU in RDB_NAME, ki ju bo uporabljal strežnik aplikacij DB2 za
MVS/ESA. Postopek zapisa teh imen v DB2 za MVS/ESA in VTAM je enak
postopku, ki je opisan v temi Definiranje lokalnega sistema. RDB_NAME, ki ga izberete za DB2 za MVS/ESA, morate
posredovati vsem končnim uporabnikom in zahtevnikom aplikacij, ki zahtevajo
povezljivost s strežnikom aplikacij.
- Vrednost NETID.LUNAME registrirajte za vsak strežnik aplikacij DB2
za MVS/ESA z vsakim zahtevnikom aplikacij, ki zahteva dostop, da bo zahtevnik
aplikacij lahko usmerjal zahteve SNA na strežnik DB2 za MVS/ESA. 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 za MVS/ESA 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 za MVS/ESA. Stavek APPL VTAM
definira privzete omejitve seje za vse partnerske sisteme. Če želite
nastaviti enkratne privzetke za določenega partnerja, lahko uporabite tabelo
SYSIBM.SYSLUMODES komunikacijske baze podatkov (CDB).
Za informacije o tem, kako se pregleda omrežje VTAM, preberite Nastavitev velikosti RU in krmiljenja takta.
- Izdelajte postavke v DB2 za MVS/ESA CDB, da boste določili, kateri
zahtevniki aplikacij lahko vzpostavijo povezavo s strežnikom aplikacij DB2 za
MVS/ESA. Postavke komunikacijske baze podatkov za zahtevnike aplikacij
v omrežju lahko definirate na dva načina:
- V SYSIBM.SYSLUNAMES lahko vstavite vrstico, ki podaja uporabo
privzetih vrednosti za vse LU-je, ki niso specifično opisani v CDB (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 (drugi sistem DB2 za MVS/ESA) 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 10 kaže, kako lahko CDB uporabite za podajanje SECURITY=SAME za
sistem DALLAS, za vse druge zahtevnike pa uveljavite SECURITY=PGM.
Slika 10. Vzpostavljanje privzetkov za povezave zahtevnika aplikacij
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, 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 SYSIBM.SYSLUNAMES ne vpišite privzete vrstice. Če privzete
vrstice (vrstica, ki vsebuje prazno ime LU) ni, DB2 za MVS/ESA zahteva vrstico
v SYSIBM.SYSLUNAMES, 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.SYSLUNAMES vpišite privzeto vrstico, ki podaja, da je
preverjanje izvora zahtevano (stolpec USERNAMES je nastavljen na 'I'
ali 'B'). To povzroči, da DB2 za MVS/ESA omeji dostop samo na
zahtevnike aplikacij in končne uporabnike, ki so določeni v tabeli
SYSIBM.SYSUSERNAMES, kot je opisano v temi Preverjanje izvora. Ta pristop lahko uporabite, če pravila za
prevajanje imena zahtevajo, da je v SYSIBM.SYSLUNAMES vrstica s praznim
imenom LU, vendar ne želite, da DB2 za MVS/ESA to vrstico uporabi za
omogočanje neomejenega dostopa do strežnika aplikacij DB2 za MVS/ESA.
V Slika 11 nobena vrstica v stolpcu LUNAME ne vsebuje praznega polja,
zato DB2 za MVS/ESA zavrne dostop za vse LU-je, razen za LUDALLAS ali
LUNYC.
Slika 11. Določanje posameznih povezav zahtevnika aplikacij
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' ');
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', ' ');
|
DB2 za MVS/ESA strežnika baz podatkov ne izvaja, kot je definirano v
DRDA. Namesto tega ima DB2 za MVS/ESA na voljo sekundarne strežnike, ki
omogočajo dostop do več sistemov DB2 za MVS/ESA v eni enoti dela, za kar
uporabijo dostop, ki ga usmerja sistem.
SQL, ki ga podpira dostop, ki ga usmerja sistem, se v veliki meri
razlikuje od oddaljene enote dela DRDA:
Ko strežnik aplikacij DB2 za MVS/ESA prejme zahtevo SQL, pregleda ime
objekta SQL, da določi, kje v omrežju se nahaja objekt. DB2 za MVS/ESA
sprejme eno-, dvo- ali tridelna imena objektov SQL, pri čemer ima ime eno
izmed naslednjih oblik:
Objectname podaja ime tabele, pogleda, sopomenke ali vzdevka
DB2 za MVS/ESA.
authid.objectname podaja lastnika objekta in ime
objekta.
location.authid.objectname podaja lastniški
sistem, lastniškega uporabnika in ime objekta.
Če se ime položaja (prvi del tridelnega imena objekta) ujema z RDB_NAME
lokalnega sistema DB2 za MVS/ESA, zahteva določa lokalni objekt DB2 za
MVS/ESA.
Če se ime položaja ne ujema z RDB_NAME lokalnega sistema DB2 za MVS/ESA,
strežnik aplikacij DB2 za MVS/ESA preusmeri zahtevo v sistem, ki ga določa ime
položaja, za kar uporabi dostop, ki ga usmerja sistem. Ciljni sistem
mora biti drug sistem DB2 za MVS/ESA, ker je dostop, ki ga usmerja sistem,
podprt samo med sistemi DB2 za MVS/ESA. Dostop, ki ga usmerja sistem,
ne podpira nobenih funkcij za oddaljeno povezovanje, zato ni potrebno, da je
aplikacija pred izvajanjem povezana na strežniku. Slika 12 povzema postopek, ki ga DB2 za MVS/ESA uporablja za
razrešitev imen objektov SQL.
Slika 12. Razrešitev imena objekta DB2 za MVS/ESA SQL
Če želite, da bo strežnik aplikacij DB2 za MVS/ESA preusmeril zahteve
SQL, morate vsak sekundarni strežnik definirati v CDB in VTAM. Večina
postopka definiranja je podobna postopku, ki ga opisuje tema Definiranje oddaljenih sistemov. Če želite povezati sekundarne strežnike, naredite
naslednje:
- Zapišite vrednosti za RDB_NAME in ime LU za vsak strežnik v CDB in
VTAM. Vrednost TPN, ki jo uporablja dostop, ki ga usmerja sistem, se
razlikuje od privzete vrednosti DRDA. Vendar ta razlika ni pomembna,
saj DB2 za MVS/ESA samodejno izbere pravilno vrednost.
- V SYSIBM.SYSLUNAMES definirajte zaščitne zahteve za vsak sekundarni
strežnik. Ta postopek je opisan v temi Omogočanje zaščite.
- Definirajte ime načina (ali imena), ki se uporablja med strežnikom
aplikacij DB2 za MVS/ESA in sekundarnimi strežniki, nato pa ta imena načinov
postavite v tabelo načinov VTAM. Privzeto ime načina je
IBMDB2LM.
- Definirajte omejitve seje za vse sekundarne strežnike. Postopek, ki
se uporablja za določitev omejitev seje, je enak kot postopek, ki je opisan v
temi Definiranje lokalnega sistema. Vendar lahko dostop, ki ga usmerja sistem, za vsako
aplikacijo vzpostavi več pogovorov. Za povezave z dostopom, ki ga
usmerja sistem, bo morda potrebno nastaviti višje omejitve seje kot za
povezave DRDA.
Podrobnejše informacije o tem, kako se izračuna število sej LU 6.2, ki
jih zahtevajo aplikacije z dostopom, ki ga usmerja sistem, preberite poglavje
"Connecting Distributed Database Systems" priročnika DB2
Administration Guide.
Kot lastnik sredstev baze podatkov sekundarni strežnik krmili zaščito baze
podatkov za objekte SQL, ki se nahajajo na strežniku. Vendar to
odgovornost deli s strežnikom aplikacij DB2 za MVS/ESA, ki izvajajo
zahtevo. Strežnik dostop do objektov SQL krmili tako:
- Sekundarni strežnik nima kopije načrta DB2 za MVS/ESA, zato je odvisen od
povpraševalnega strežnika aplikacij DB2 za MVS/ESA, ki preveri, ali ima končni
uporabnik pravico za izvajanje paketa v povpraševalnem sistemu (strežnik
aplikacij).
- Statični stavki SQL se na sekundarnem strežniku izvajajo dinamično, za kar
uporabljajo pooblastila, dodeljena osebi, ki je lastnik paketa DB2 za MVS/ESA
na povpraševalnem strežniku aplikacij DB2 za MVS/ESA.
- Dinamični stavki SQL se izvajajo z uporabo pooblastil, ki so dodeljena
končnemu uporabniku na zahtevniku aplikacij.
Pri tem, ko zahtevnik aplikacij usmerja zahtevo porazdeljene baze podatkov
na strežnik aplikacij DB2 za MVS/ESA, 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 za MVS/ESA od zahtevnika aplikacij prejme ime
končnega uporabnika, lahko strežnik aplikacij 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 za MVS/ESA izvaja preverjanje izvora kot del prevoda vhodnega imena
uporabnika, ki je opisano v naslednjem razdelku.
ID uporabnika, ki ga pošlje zahtevnik aplikacij, morda ni enkraten v
celotnem omrežju SNA. Strežnik aplikacij DB2 za MVS/ESA 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 za
MVS/ESA 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.SYSLUNAMES nastavite na 'I' (vhodni prevod) ali
'B' (vhodni in izhodni prevod). Če uveljavite prevod vhodnega
imena, DB2 za MVS/ESA prevede ID uporabnika, ki ga pošlje zahtevnik aplikacij,
in ime lastnika načrta DB2 za MVS/ESA (če je zahtevnik aplikacij drug sistem
DB2 za MVS/ESA).
Č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.SYSUSERNAMES 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 za MVS/ESA
izhode za pooblastila, ki jih lahko uporabite za posredovanje seznama
sekundarnih AUTHID-jev in izvajanje dodatnega preverjanja zaščite.
Podrobnejše informacije lahko najdete v priročniku DB2 Administration
Guide.
Postopek prevajanja vhodnega imena v tabeli SYSIBM.SYSUSERNAMES
poišče vrstico, ki se mora ujemati z enim izmed vzorcev, prikazanem na
naslednjem seznamu prednosti (TYPE.AUTHID.LUNAME):
- I.AUTHID.LUNAME--Določen končni uporabnik z določenega
zahtevnika aplikacij.
- I.AUTHID.blank--Določen končni uporabnik s kateregakoli
zahtevnika aplikacij
- I.blank.LUNAME--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 za MVS/ESA (na primer pooblastila tabele SQL), ki jih
opravi DB2 za MVS/ESA, se opravijo na prevedenih imenih končnih uporabnikov in
ne na izvirnih imenih.
Ko strežnik aplikacij DB2 za MVS/ESA od zahtevnika aplikacij prejme ime
končnega uporabnika, lahko z zmožnostjo za prevod vhodnega imena DB2 za
MVS/ESA 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.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, 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.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, 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.SYSUSERNAMES.
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'SMITH', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', 'JONES', 'LUNYC', ' ', ' ');
- Omejite lahko zahtevnike aplikacij, ki lahko vzpostavijo povezavo s
strežnikom aplikacij DB2 za MVS/ESA. 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.SYSLUNAMES podaja prevod vhodnega
imena za vse vhodne zahteve.
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS,
MODESELECT, USERNAMES)
VALUES (' ', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('I', ' ', 'LUCHI', ' ', ' ');
LU 6.2 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 za MVS/ESA. Strežnik aplikacij DB2 za MVS/ESA uporablja zaščito na
ravni seje in šifriranje popolnoma enako kot zahtevnik aplikacij DB2 za
MVS/ESA.
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 za MVS/ESA. Strežnik
aplikacij DB2 za MVS/ESA ima v zaščiti omrežja dve različni vlogi:
- Kot zahtevnik za sekundarne strežnike, je strežnik aplikacij DB2 za
MVS/ESA odgovoren za izdajanje zahtev APPC, ki vsebujejo parametre zaščite na
ravni pogovora SNA, ki jih zahtevajo sekundarni strežniki. Strežnik
aplikacij DB2 za MVS/ESA uporablja stolpec USERNAMES tabele
SYSIBM.SYSLUNAMES in tabelo SYSIBM.SYSUSERNAMES, da za vsak
sekundarni strežnik definira zahteve zaščite 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 za MVS/ESA
določa zahteve za zaščito na ravni pogovora SNA za zahtevnik aplikacij.
DB2 za MVS/ESA uporablja stolpec USERSECURITY tabele SYSIBM.SYSLUNAMES,
da določi zaščito pogovora, ki jo zahteva vsak zahtevnik aplikacij v
omrežju. V stolpcu USERSECURITY so uporabljene naslednje
vrednosti:
- C
- Kaže, da DB2 za MVS/ESA 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.SYSLUNAMES vsebuje vrednost 'Y', DB2 za MVS/ESA
privzame, da geslo že uporablja šifrirano obliko RACF (to je možno samo za
zahtevnik aplikacij DB2 za MVS/ESA). Če stolpec ENCRYPTPSWDS ne vsebuje
vrednosti 'Y', DB2 za MVS/ESA pričakuje, da bo geslo uporabljalo
običajni format LU 6.2 (predstavitev znakov EBCDIC). V obeh
primerih DB2 za MVS/ESA 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 za MVS/ESA
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 za
MVS/ESA zahteva, da zahtevniku aplikacij vrne kodo zaznavanja napake v zaščiti
SNA ('080F6051'X). Ker ta koda zaznavanja ne opisuje vzroka
napake, DB2 za MVS/ESA nudi dva načina za beleženje vzroka kršitev
porazdeljene zaščite:
- 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 za MVS/ESA krmili
funkcije za zaščito baze podatkov za objekte SQL, ki se nahajajo na strežniku
aplikacij DB2 za MVS/ESA. Dostop do objektov, ki jih upravlja DB2 za
MVS/ESA, krmilijo pooblastila, ki jih uporabnikom dodelijo skrbnik DB2 za
MVS/ESA ali lastniki posameznih objektov. Dva osnovna razreda objektov,
ki jih krmili strežnik aplikacij DB2 za MVS/ESA, sta:
Ko izdelate paket, možnost DISABLE/ENABLE omogoča, da
nadzorujete, kateri tipi povezav DB2 za MVS/ESA lahko izvajajo paket.
Če želite končnim uporabnikom selektivno omogočiti uporabo DDF,
lahko uporabite RACF in izhodne podprograme za zaščito DB2 za
MVS/ESA. RLF lahko uporabite za podajanje omejitev za čas
procesorja za oddaljene povezave in izvajanja dinamičnega SQL.
Za primer vzemimo paket DB2 za MVS/ESA z imenom MYPKG, katerega
lastnik je JOE. JOE lahko SAL omogoči izvajanje paketa z izdajo stavka
DB2 za MVS/ESA GRANT USE. Če SAL izvede paket, se zgodi
naslednje:
- DB2 za MVS/ESA preveri, ali ima SAL za paket pooblastilo 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 za MVS/ESA uporablja podsistem za
zaščito (RACF ali enakovreden izdelek), je odvisen od tega, kako v tabeli
SYSIBM.SYSLUNAMES definirate funkcijo za prevod vhodnega imena:
- Če za stolpec USERNAMES podate 'I' ali 'B', je funkcija
prevajanja vhodnega imena aktivna, DB2 za MVS/ESA pa privzame, da jo skrbnik
DB2 za MVS/ESA 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 sistem za zaščito ne bo poklican, ker pravila za prevajanje vhodnega
imena definirajo, kateri uporabniki lahko vzpostavijo povezavo s strežnikom
aplikacij DB2 za MVS/ESA.
- Č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 za
MVS/ESA za preverjanje ID-ja končnega uporabnika (in gesla, če je podano),
pokliče zunanji podsistem za zaščito.
- Poklican bo zunanji podsistem za zaščito, ki preveri, ali ima končni
uporabnik pooblastilo za povezavo s podsistemom DB2 za MVS/ESA.
- V obeh primerih bo izhod za pooblastila posredoval seznam sekundarnih
pooblastitvenih ID-jev. Podrobnejše informacije lahko najdete v
priročniku DB2 Administration Guide.
Zagotoviti morate, da vaš podsistem DB2 za MVS/ESA lahko
pretvori CCSID posameznih zahtevnikov aplikacij v namestitveni CCSID
podsistema DB2 za MVS/ESA. Za podrobnejše informacije preglejte temo Predstavitev podatkov.
[ Vrh Strani | Predhodna Strani | Naslednja Strani | Obsah | Seznam ]