Varnost gradnikov in spletnega
strežnika
Poleg osnovne varnosti operacijskega sistema, ki jo predstavlja preverjanje
pristnosti entitet ter dovoljenja za uporabo virov, lahko zaš itimo tudi komponente
s srednjega sloja namenskih programov. V primeru, da moramo vzpostaviti varno
komunikacijo med entitetami v medmrežju, pa je pomembno, da vemo, kakšne
varnostne mehanizme nam ponuja spletni strežnik. V pri ujo em lanku se bomo
usmerili na COM+ komponente in IIS.
Avtorizacija z vlogami
Varovanje COM+ komponent poteka prvenstveno preko vlog (Roles). Vloga je
ime, ki je povezano z uporabnikom ali skupino uporabnikov in svojim lanom
omogo a izvajanje komponent. Tako, kot je uporabnik lahko lan v ve vlogah,
lahko vloga vsebuje ve uporabnikov in skupin. Komponento lahko nato izvajajo
vsi uporabniki, ki so lani katerekoli od vlog, ki pripadajo komponenti. Podoben
odnos, kot je med uporabniki in vlogami, je tudi med vlogami in komponentami.
Pripadnost vlog in uporabnikov komponentam, je mogo e izvesti
administrativno s pomo jo Komponentnih storitev (Component Services) ali
programsko. Ko ustvarimo nov COM+ namenski program, ta nima nobenih
varnostnih nastavitev. V takšnem stanju ga lahko izvaja vsak, ki se uspe
prijaviti na ra unalnik. Administrativno varovanje komponent izvedemo z
naslednjimi šestimi koraki:
1. Omogo imo avtorizacijo tako, da potrdimo Enforce Access Checks for
This Application v dialognem oknu Lastnosti (Properties) COM+
namenskega programa (ki vsebuje eno ali ve komponent).
2. V varnostnem zavihku dialognega okna Lastnosti izberemo ali zaš ito
na nivoju komponent (kar je privzeta nastavitev) ali na nivoju procesov.
3. Še vedno v tem istem zavihku dolo imo stopnjo avtentikacije in
poosebljanja.
4. Ustvarimo množico vlog za strežniški namenski program, ki ga bomo
varovali.
5. Dodamo vloge vsem komponentam, vmesnikom in metodam, ki jih
nameravamo varovati.
6. Posami na in skupinska uporabniška imena dodelimo posameznim
vlogam.
Kadar odjemalec skuša pognati dolo eno komponento, vmesnik ali metodo, ki
je varovana, COM+ v ozadju preveri ali je za to avtoriziran in v tem primeru
dobi pravice za zagon in dostop.
Tako je, kadar odjemalec (uporabnik) izvaja, le z njim neposredno povezane
komponente. Sedaj poglejmo, kako je, kadar imamo položaj, kot je na Sliki 2.
Slika 2
Recimo, da je uporabnik lan ene od vlog povezane s komponento A, ni pa
lan nobene od vlog komponente B. Uporabnik lahko sproži metodo
komponente A (ker je zato avtoriziran), ta pa lahko nadalje sproži metodo
komponente B (ker sta obe del istega COM+ namenskega programa). Kaj pa,
e bi bila komponenta B v drugem COM+ namenskem programu? Pri akovali
bi, da bi uporabnik moral biti avtoriziran tudi za njega. Vendar ni tako. COM+
namre izvaja varnostna preverjanja le med neposredno povezanimi
namenskimi programi. Zato moramo poznati razliko med neposrednim (direct)
in izvornim (original) klicateljem. Kljub temu, da namenski programi naprej v
verigi klicev, ne preverjajo pooblastil izvornega klicatelja, se njegova identiteta
prenaša vse do konca, tako da lahko zanj vedno vemo. Kot verjetno
predpostavljate, je to narejeno predvsem zaradi sledenja.
Potrebno je biti tudi previden, saj s tem, ko uporabniku damo pravico
izvajanja dolo ene komponente, damo tudi dostop do vseh virov (druge
komponente, podatkovne zbirke, datote ni in spletni strežniki…), do katerih
dostopajo ta ali naslednje komponente v verigi. Držimo se tudi na ela, da
odjemalce preverimo imprej, ne pa nekje na sredini ali koncu verige klicev.
Programsko varovanje
Programsko varovanje dopolnjuje in razširja administrativno varnost. Izdelamo
lahko naša lastna varnostna preverjanja, ki nam jih omogo ata ObjectContext in
SecurityCallContext vmesnika. Ta vmesnika sta dolo ena v COM+ Services type
library in se v veliki meri prekrivata, zato lahko pogosto uporabimo, kateregakoli
od njiju. Oglejmo si preprost primer uporabe SecurityCallContext vmesnika z
Visual Basicom.
‘ Definiramo standardni HRESULT za prepovedan dostop
Const E_ACCESSDENIED = &H80070005
Dim scc As SecurityCallContext
Set scc = GetSecurityCallContext
If scc.IsSecurityEnabled() Then
‘ Izvedba varovane operacije
Else
‘ Obvestilo uporabniku, da nima pravice dostopa
Err.Raise E_ACCESSDENIED, “MojDll.MojRazred.MojaMetoda”, “Nedovoljen dostop”
End If
Primer 1: Program preveri ali se metoda izvaja v varovanem COM+ namenskem programu
Metoda IsSecurityEnabled pove ali se trenutni klic izvaja v varovanem
namenskem programu in ali je komponenta oblikovana tako, da preveri
pooblaš enost odjemalca na stopnji komponente, vmesnika ali metode.
Naslednji primer kaže, kako preverimo ali je klicatelj lan dolo ene vloge:
Const E_ACCESSDENIED = &H80070005
Dim scc As SecurityCallContext
Set scc = GetSecurityCallContext
If scc.IsSecurityEnabled() And scc.IsCallerInRole(“Vodstvo”) Then
‘ Izvedba varovane operacije, ki jo smejo uporabljati le lani uprave
Else
‘ Obvestilo uporabniku, da nima pravice dostopa
Err.Raise E_ACCESSDENIED, “MojDll.MojRazred.MojaMetoda”, “Nedovoljen dostop”
End If
Primer 2: Procedura preveri ali je klicatelj
lan ustrezne vloge
Zanimiva je tudi metoda IsUserInRole, ki je sicer samo del SecurityCallContext
vmesnika (ne pa tudi ObjectContext vmesnika) z njo ugotovimo ali je specifi en
posamezen uporabnik, lan podane vloge. Z naslednjo proceduro ugotovimo ali
je izvorni klicatelj lan v vlogi Vodstvo.
Dim oc As ObjectContext
Set oc = GetObjectContext()
Dim scc As SecurityCallContext
Set scc = GetSecurityCallContext()
Dim IzvorniKlicatelj As String
IzvorniKlicatelj = oc.Security.GetOriginalCallerName()
If scc.IsSecurityEnabled() And scc.IsUserInRole(IzvorniKlicatelj,“Vodstvo”) Then
‘ Operacija, ki jo lahko izvaja samo uprava
Else
‘ Obvestilo uporabniku, da nima pravice dostopa
Err.Raise E_ACCESSDENIED, “MojDll.MojRazred.MojaMetoda”, “Nedovoljen dostop”
End If
Primer 3: Procedura, ki jo lahko sprožijo le
lani vodstva.
Te metode ne uporabljamo, e ni nujno, ker je asovno zahtevna in je v
nasprotju s politiko, ki zahteva, da izvajalne pravice preverimo ob vstopu v
vmesni sloj oziroma takoj, ko je to mogo e.
Poleg preverjanja ali ima odjemalec pravico uporabe dolo ene metode ali
komponente, programsko esto izvajamo tudi sledenje. Vedno lahko izvemo tako
identiteto odjemalca, ki je ustvaril predmet, kot tistega, ki ga je klical (ta dva sta
obi ajno eden in isti odjemalec). Oglejmo si primer 4.
Dim Klicatelj As String, Sporocilo As String
Dim oc As ObjectContext
Set oc = GetObjectContext()
Klicatelj = oc.Security.GetOriginalCallerName()
Sporocilo = Klicatelj & “ je skušal pogledati direktorjevo pla o.”
App.LogEvent Sporocilo, vbLogEventTypeError
Primer 4: Beležimo poizkuse nepooblaš enega izvajanja metod(e)
Predmet SecurityCallContext vsebuje kolekcijo Item, ki ima ve uporabnih
elementov, kot so: število klicateljev, najnižja stopnja avtentikacije ter podatke o
neposrednem in izvornem klicatelju.
Item
NumCallers
MinAuthenticationLevel
Callers
DirectCaller
OriginalCaller
Tip
Integer
Integer
Referenca SecurityCallers
Referenca SecurityIdentity
Referenca SecurityIdentity
Tabela 1: Zbirka Item predmeta SecurityCallContext
Predmet SecurityIdentity ima prav tako kolekcijo Item, ki tudi vsebuje nekatere
zanimive elemente. Z njimi izvemo naziv klicateljevega ra una, njegov SID,
izbrani SSP, stopnjo avtentikacije in poosebljanja. Ti elementi so prikazani v
Tabeli 2.
Item
SID
AccountName
AuthenticationService
AuthenticationLevel
ImpersonationLevel
Tip
Binary array
String
Integer
Integer
Integer
Tabela 2: Zbirka Item predmeta SecurityIdentity
Primer uporabe teh dveh kolekcij kaže Primer 5.
Dim scc As SecurityCallContext
Set scc = GetSecurityCallContext()
Dim Klicatelj As SecurityIdentity
Set Klicatelj = scc.Item(“OriginalCaller”)
Dim UporIme As String, StopnjaAvtentikacije As Integer
UporIme = Klicatelj.Item(“AccountName”)
StopnjaAvtentikacije = Klicatelj.Item(“AuthenticationLevel”)
Primer 5: Uporaba kolekcije Item predmetov SecurityCallContext in SecurityIdentity
S COM+ lahko izvemo tudi vse o vsakem od klicateljev v logi ni verigi, kar je
znano kot vzro nost (causality). Pri tem si pomagamo s predmeti
SecurityCallContext, SecurityIdentity in SecurityCallers. Na in uporabe teh treh
predmetov je prikazan v Primeru 6.
Dim
Set
Dim
Set
Dim
Dim
For
scc As SecurityCallContext
scc = GetSecurityCallContext()
Klicatelji As SecurityCallers
Klicatelji = scc.Item(“Callers”)
Klicatelj As SecurityIdentity
i As Integer
i = 0 To (Klicatelji.Count – 1)
Set Klicatelj = Klicatelji.Item(i)
‘ Dostop do identitete klicatelja
Next i
Primer 6: Obdelava logi ne verige klicateljev
Ponovimo, da COM+ hrani navedene informacije in vsebuje potrebne metode,
predvsem zato, da lahko izdelamo skoraj poljuben sistem sledenja.
Spletni strežnik
Ker se vse ve poslovanja odvija preko medmrežja, je tudi varnost spletnih
strežnikov vse pomembnejša. Odjemalci morajo skozi spletni strežnik v omrežnih
namenskih programih, ki uporabljajo ASP strani za dostop do COM+ gradnikov,
ki uporabljajo HTML uporabniške vmesnike ali pa uporabljajo HTTP protokol ne
pa tudi HTML. Zato je važno, da vemo, kako se dopolnjujeta varnost IIS in
varnost COM+ gradnikov. Slika 3 kaže delovanje zna ilnega omrežnega
namenskega programa.
Slika 3: Povezava med odjemalci, spletnim strežnikom in COM+ gradniki
Vidimo, da je INETIINFO.EXE vstopna to ka uporabnikov v vmesni sloj, kar
pomeni, da mora spletni strežnik izvajati avtentikacijo odjemalcev. IIS uporablja
poosebljanje zato, da zahteve odjemalcev ne te ejo s sistemsko identiteto, saj bi
v tem primeru imele prevelika pooblastila, ki bi jih bilo mogo e zlorabiti. Kljub
temu, da poosebljanje dela pravilno, obstaja majhna možnost, da nepridiprav
uspe preklopiti zahtevo nazaj na sistemsko identiteto. Tudi to pa lahko
prepre imo s tem, da IIS namenski program izvajamo v osamitvi (isolation). S
tem tudi izboljšamo odpornost na napake (fault tolerance), žal se na drugi strani
zaradi tega zmanjša odzivnost.
IIS torej preklaplja zahteve na razli ne uporabniške ra une, toda kateri ra uni
so to? To je odvisno od na ina avtentikacije. Preden pa se poglobimo vanje, si
oglejmo varnostne standarde povezane s HTTP protokolom.
Avtentikacija s HTTP
HTTP protokol, kot tak je zelo splošen, saj ni vezan ne na posamezno strojno
in ne programsko platformo, kar mu omogo a, da igra pomembno povezovalno
vlogo. Ker ni vezan na okensko platformo, lahko hitro ugotovimo, da varnostna
mehanizma, kot sta NTLM in Kerberos, ne zadostujeta. Tudi s Kerberosem
povezano simetri no šifriranje klju a ni izvedljivo, ker bi moral imeti vsak
avtorizator dvosmerni zaupni odnos z vsakim drugim avtorizatorjem.
Ker pa se je na razvoju HTTP varnosti veliko delalo, imamo danes ve ali manj
splošno sprejet varnostni protokol, ki se imenuje SSL (Secure Sockets Layer). Pri
SSL eni strani ni potrebno razkriti svojega skritega klju a drugi strani, šifriranje
pa temelji na dveh klju ih namesto na enem. En se uporablja za šifriranje, drugi
pa za dešifriranje vsebine. Entiteta en klju objavi, drugega pa varuje, kar je
znano kot asimetri no šifriranje klju a.
Njegovo visokonivojsko delovanje je naslednje: Entiteta A, da entiteti B svoj
javni klju , sporo ilo pa šifrira s svojim skrivnim klju em. Entiteta B to sporo ilo
razpozna z javnim klju em, ki ga je dobila od entitete A. e entiteta B zaupa, da
ima edino entiteta A skrivni klju za šifriranje sporo il, je lahko prepri ana, da je
sporo ilo resni no poslala entiteta A. Podobno lahko entiteta B uporabi javni klju
entitete A, za šifriranje sporo il, ki jih ji pošilja. Ponovno je lahko prepri ana, da
jih bo brala le entiteta A, e zaupa, da ima samo ta potreben skrivni klju
potreben za razpoznavo sporo il.
Ta na in ne omogo a vzajemne avtentikacije: entiteta B ve za entiteto A, toda
entiteta A ne ve ni o B. Vzajemno avtentikacijo dosežemo, e tudi entiteta B
pošlje svoj javni klju entiteti A in hrani svoj zaupni klju . V tem primeru morata
torej obe entiteti imeti svoj javni in svoj skrivni klju .
Zavedati pa se moramo, da je uporaba asimetri nega šifriranja klju a, v
primerjavi s simetri nim, tudi do tiso krat po asnejša.
Overitelji
Sedaj, ko smo preu ili delovanje SSL, vidimo, da mora ena od entitet, ki se
povezujeta, zaupati, da je javni klju , res javni klju druge entitete in ne morda
nekoga, ki se je lažno predstavil in bo s svojim skrivnim klju em bral njena
zaupna sporo ila namenjena drugi entiteti.
Zaradi tega je vzpostavljen osrednji avtorizator (Central Authority), ki izdaja
javne klju e in mu morajo zaupati vse entitete, ki prejemajo javne klju e. Osrednji
avtorizator izdaja javne klju e s potrdili (Certificates). Potrdilo overja pripadnost
javnega klju a entiteti, kot je podjetje ali oseba. Skupni medmrežni standard za
potrdila je vsebovan v ITU-T priporo ilu X.509. Tako potrdilo vsebuje naslednja
polja:
• Ina ica (Version)
• Zaporedna številka (Serial number)
• Oznaka algoritma za podpis (Signature algorithm ID)
• Ime izdajatelja (Issuer name)
• Obdobje veljavnosti (Validity period)
• Ime subjekta (Subject (user) name)
• Javni klju subjekta (Subject public key information)
• Unikatna oznaka izdajatelja (Issuer unique identifier)
• Unikatna oznaka subjekta (Subject unique identifier)
• Podpis izdajatelja (Issuer signature)
Potrdilo mora biti podpisano z izdajateljevim skrivnim klju em, ker je druga e
brez pomena. Izdajateljev podpis je mogo e preveriti z uporabo izdajateljevega
javnega klju a. e entiteta zaupa izdajatelju, sme verjeti, da javni klju naveden
v potrdilu, res pripada subjektu s taistega potrdila.
Potrdila izdajajo avtorizatorji za potrdila (Certificate Authorities CA). CA je
zaupna storitev oziroma entiteta, ki jam i za tiste, ki so od nje dobili potrdilo.
Nekatera podjetja, kot je na primer VeriSign igrajo vlogo CAjev. Kdor ho e od
njih pridobiti potrdilo, mora dokazati svojo identiteto. Ko zahtevamo potrdilo od
CAja, mu moramo poslati javni klju , za katerega imamo ustrezen skrivni klju .
CA ustvari potrdilo, v katerega vklju i naše ime in javni klju , skupaj s svojim
podpisom (signiture).
Opazimo lahko, da je potrdilo brez pomena, e nimamo CAjevega javnega
klju a, ki ga moramo prejeti na zanesljiv in varen na in (druga e se lahko kdo
lažno predstavlja za CA). Javni klju i CAjev , kot je VeriSign, so splošno znani in
naloženi z brskalniki, kot sta Navigator in Explorer. e imata obe entiteti, ki
komunicirata, javna klju a izdana pri istem CAju, si lahko zaupata.
CA lahko potrdi podrejene CAje, ki lahko nato izdajajo svoja lastna potrdila.
Tako je mogo e ustvariti celotno strukturo CAjev, z relacijo starš-otroci, pri emer
moramo v najvišjega v strukturi zaupati brez potrdila od drugega CAja.
SSL protokoli
Microsoft podpira varno komunikacijo na osnovi potrdil s štirimi podobnimi
protokoli. To so SSL (Secure Sockets Layer) 2 in 3, TLS (Transport Layer
Security) 1 ter PCT (Private Communication Technology) 1. Najve se uporablja
SSL3, ki je postal standard za uporabo s protokolom http. PCT je prišel iz
uporabe, medtem ko je TLS1 v bistvu nova ina ica SSL3. In kaj je SCHANNEL
(Secure channel), ki je tudi eden od SSPjev namenjenih omrežnemu preverjanju
pristnosti v Oknih 2000? SCHANNEL ni ni drugega, kot Microsoftova izvedba
teh štirih protokolov.
SSL se uporablja na dva na ina: s strežnikovim potrdilom (Server Certificate)
in z potrdili odjemalcev s strežnikovim potrdilom. Pri prvem na inu strežnik ne ve
ni o odjemalcih, medtem ko lahko pri drugem na inu strežnik vodi uporabniške
ra une odjemalcev in na tej osnovi omogo a varovanje z vlogami (role-based
security). Težava je le to, da mora imeti vsak odjemalec svoje potrdilo. Microsoft
je zaradi tega izdelal namenski program Microsoft Certificate Server (MCS), ki
podjetju omogo a, da izdaja svoja lastna potrdila.
e obstajajo ustrezna potrdila, strežnikovo oziroma strežnikovo in odjemalcev,
lahko uporabljamo HTTPS. HTTPS ni ni drugega, kot http s SSL.
Na ini avtentikacije v IIS
Sedaj, ko smo obdelali potrdila in SSL, si oglejmo, kako se uporabljajo v IIS.
Ker je IIS namenjen vsem vrstam uporabe, omogo a pet na inov avtentikacije, ki
se med seboj razlikujejo po stopnji varnosti ter hitrosti delovanja. Zbrani so v
Tabeli 3.
Na in avtentikacije
Anonymous Access
Certificate-Based Authentication
Integrated Windows Authentication
Digest Authentication
Basic Authentication
Na kaj pooseblja
Na IUSR_Machine
Na ra une uporabnikov
Na ra une uporabnikov
Na ra une uporabnikov
Na ra une uporabnikov
Prednastavljeno
Da
Da
Da
Ne
Ne
Tabela 3: Na ini avtentikacije v IIS
Prvi na in je najhitrejši, vendar ne izvaja nobenega preverjanja varnosti. IIS
vseeno izvaja poosebljanje, zato da se zahteve odjemalcev ne procesirajo s
sistemsko identiteto. IIS pravzaprav vedno skuša procesirati zahteve, brez
preverjanja odjemalcev, zato moramo pri preostalih na inih avtentikacije,
onemogo iti brezimen na in dostopa.
Drugi na in omogo a avtentikacijo s SSL in potrdili. Ta na in ima dale
najve je stroške vzpostavitve in vzdrževanja, toda omogo a izvajanje na ra unu
posameznega uporabnika.
Tretji na in temelji na NTLMju oziroma Kerberusu. Ta na in se izvaja tako, kot
smo opisali v lanku o varnosti v Oknih 2000. Pri tem na inu imamo dodatno
omejitev, ker deluje le pri Oknih in brskalniku Internet Explorer. Pravzaprav je
najprimernejši za povezave znotraj lokalne mreže.
etrti na in prihaja na novo z razli ico IIS 5.0. Avtentikacija z njegovo pomo jo
se izvaja s šifriranim geslom in IISjem na domenskem nadzorniku z Okni 2000.
Prav to je posebej neprikladno, ker vdor omogo a prevzem pooblastil nad
ra unalniki v domeni. Deluje podobno kot NTLM, uporabnik pa mora ob prijavi na
spletno mesto podati uporabniško ime in geslo.
Tudi pri petem na inu moramo na za etku, podobno kot pri prejšnjem, vnesti
ime in geslo, za razliko od njega pa pri prenosu nista šifrirana. Zaradi tega, ga
uporabljamo v glavnem le skupaj s HTTPS. Ta na in se s http protokolom, že
dolgo uporablja, zato ga podpira ve ina brskalnikov, deluje preko požarnih zidov
in ne zahteva mnogo nastavljanja.
Kateri na in avtentikacije torej izbrati: vsi imajo svoje prednosti in slabosti, za
varno komunikacijo v medmrežju, pa se najve uporabljata drugi in peti.
Za zaklju ek
V lanku smo osvetlili nekaj vidikov varnosti v sodobni informacijski tehnologiji.
Opisano je samo osnova in splošno znanje, ki ga mora poznati vsak informatik,
strokovnjakom, ki delajo prav na podro ju varnosti, pa je opisano verjetno tako
znano, tako kot o enaš gore emu kristjanu.
Nadaljnje informacije je mogo e najti v datotekah pomo i Oken 2000 in Oken
XP, na spletnih straneh http://msdn.microsoft.com/security, kdor pa se ho e
poglobiti v varnostno tematiko, mu predlagam knjigo Programming Windows
Security avtorja Keith Brown-a.