M 4.419z Rakenduste juhtimine AppLockeriga alates Windows 7-st


Algatamise eest vastutavad: infoturbespetsialist, IT-juht
Rakendamise eest vastutab: administraator

Tarkvara konfigureerimine ja installimine
Kliendi tarkvara konfiguratsioon võib mõnel juhul ise kohe pärast standardkonfiguratsiooni loomist etteantud nõuetest kõrvale kalduda, v.a juhul, kui on võetud tehnilisi meetmeid, mis seda takistavad. Kõrvalekaldumiste hulk kasvab enamasti sedamööda, kui pikalt on klienti kasutatud. Kõrvalekaldumiste põhjus seisneb lõppkasutajate installimistes, mille puhul ei järgita muudatuste haldamise protsessi standardseid ettekirjutusi. Tegu võib olla ka näiteks igapäevatööks vajalike tarkvaratööriistadega. Samas võivad kasutajad sageli installida ka sellist tarkvara, mida igapäevatööks üldse tarvis ei ole. Mõlemal juhul tuleb installimisel läbi teha muudatuste haldamise protsessis ette nähtud protseduurid. Täiendava tarkvara installimisel kaotab administraator peagi ülevaate kliendi tarkvara konfiguratsioonist. Selle tagajärjel võib tekkida olukord, kus võimalike vigade korral jäävad nende põhjused administraatori jaoks hoomamatuks. Sellest veelgi olulisem on aga fakt, et juurde installitud tarkvara suhtes ei toimi ei turvapaikade ega ka muudatuste haldus (vt M 2.273 Turvalisust mõjutavate paikade ja värskenduste kiire paigaldamine). Nii saavad ründajad tarkvaras leiduvaid turvaauke enda huvides ära kasutada ning klientsüsteemidesse näiteks pahavara koodi sisse smugeldada ja selle käivitada. Ka serverisüsteemidesse ei tohi tarkvara kontrollimatult juurde installida. Näiteks kui andmevarunduse eest vastutav administraator tahab endale mõnda konkreetset tarkvaratööriista juurde installida, et tohi ta seda teha niisama, vaid ta peab selleks kasutama muudatuste haldamise protsessi. Nii tagatakse, et installatsioon dokumenteeritakse ja tarkvaratööriist kaasatakse ka turvapaikade haldamise protsessi.

AppLocker
Alates versioonidest Windows 7 Ultimate, Windows 7 Enterprise ja Windows Server 2008 R2 kasutusele võetud AppLocker aitab administraatoril süsteemide üle kontrolli säilitada sellega, et tõkestab tehniliselt kasutajate jaoks nii tarkvara installimise kui ka selle käivitamise. AppLockerit tuleks kasutada süsteemi tervikluse kaitsmiseks. AppLocker on varem operatsioonisüsteemides Microsoft Windows Vista ja Server 2003 kasutatud tarkvarapiiramispoliitikate (Software Restriction Policies – SRP) edasiarendus (vt M 4.286 Windows Server 2003 Software Restriction Policy rakendamine). Nende poliitikate konfigureerimiseks peab administraator kahjuks iga tarkvara ja iga vajaliku värskenduse kohta koostama eraldi reegli. Selle tagajärjel võib haldustööde maht paisuda väga suureks. Erinevalt tarkvarapiiramispoliitikatest on AppLockeri puhul administraatoril palju rohkem võimalusi suuniste defineerimiseks ning see aitab ka palju täpsemalt reageerida institutsiooni vajadustele. Näidetena võib siinkohal tuua viisardid ja reeglite koostamise tööriistad, mille abil saab reegleid koostada ka automaatselt. Neid tuleks kasutada näiteks oluliste süsteemifailide käivitamist lubavate standardsete reeglite defineerimiseks. Kasutajatele mõeldud reeglite defineerimisel on administraatori töö lihtsustamiseks olemas ka sammsammulised juhised ja integreeritud abifunktsioon. Standardsete reeglite kõrval tuleks eraldi suunised koostada ka käitusfailidele, installimisprogrammidele, skriptidele ja DLL-idele. Suuniseid saab eraldi konfigureerida ja need pakuvad süsteemidele paremat kaitset, sest nende mõju ei piirdu üksnes käitusfailidega.

Reeglid
Reegleid on kolme tüüpi: lubatud, keelatud ja erandid. Nende põhjal saab koostada reeglid, mis lubavad institutsiooni jaoks defineeritud standardtarkvara käivitada (positiivne loetelu) või mis keelavad teadaolevate kahjurprogrammide käivitamise (negatiivne loetelu). Soovitame rakendada põhimõtet, et kõik rakendused tuleb keelata. Lubada tohib üksnes positiivses loendis kajastatud tarkvara installimist ja käivitamist. Nii tõkestatakse negatiivsesse loetellu seni veel sisse kandmata tarkvara installimine ja käivitamine. Standardsed reeglid analüüsivad ja hindavad andme- või kataloogiteed või tarkvara käitusfaili räsiväärtust (file hash). Lisareegleid saab kehtestada rakenduste signatuuride põhjal. Siinkohal tuleb arvestada järgmiste aspektidega.

Faili või kausta andmeteel (path) põhinevad reeglid
Kui defineeritakse reegel, mis lubab asukohas „C:\Programms” käivitada mis tahes tarkvara, saab turbemehhanismist möödahiilimiseks tõsta keelatud tarkvara käitusfaili ümber eelnimetatud kausta. Selle eelduseks on lokaalsete lõppkasutajate haldamist võimaldavad administraatorivolitused. Sellist olukorda tuleks asjakohaste meetmetega vältida (vt M 2.32 Piiratud kasutajakeskkonna loomine).

Faili räsiväärtusel (file hash) põhinevad reeglid
Faili räsiväärtust võib käsitleda kui faili krüptograafilist sõrmejälge. Seda tüüpi reegleid saab kasutada juhtudel, kus käitusfail ei ole digitaalselt signeeritud. Pärast igat tarkvaravärskendust tuleb koostada uus räsi ja kohandada kehtivaid reegleid. Selle tagajärjel võib haldustööde maht paisuda väga suureks. Seetõttu tuleks räsil põhinevatele reeglitele eelistada kas faili või kausta andmeteel või ka rakenduste digitaalsignatuuridel põhinevaid reegleid.

Rakenduste signatuuridel põhinevad reeglid
Kui fail on elektrooniliselt signeeritud, tuleks defineerida rakenduste digisignatuuridel põhinevad väljastajareeglid (publisher rules). Selle meetodi puhul tuleb tagada, et kliendis käivitataks rakenduse identiteediteenus (AppIDSvc). Rakenduse signatuuride kasutamisel ei tohi turbeastmeks valida „Mis tahes väljastaja”, vaid väljastaja tuleb defineerida. Reegli mõjuala saab piirata muude atribuutidega, nt versiooni numbri kasutamisega. Selliste piirangute puhul lubatakse rakendusi käivitada ainult alates teatud versioonist, eeldusel et väljastaja on selle ka signeerinud. Vanemaid versioone ei käivitata, seevastu uuemaid versioone lubatakse kasutada automaatselt. Positiivsete ja negatiivsete loetelude koostamise eest vastutavad infoturbespetsialist ja IT-juht. Nad peaksid koos osakonna juhtide ja lõppkasutajatega välja selgitama töötajate vajadused, need kokku koondama ja kontrollima, kas kõik vajadused said fikseeritud. Asjakohaseid loetelusid tuleb regulaarselt kontrollida. Vajaduse korral tuleb teha ka muudatusi.

Grupipoliitikate haldamine
Rakenduste juhtimine peaks olema kindla administraatori ülesanne. Domeenivõrgustiku puhul tuleb reegleid konfigureerida tsentraalselt grupipoliitikate haldamise mehhanismidega. Selleks läheb tarvis versioonis Windows Server 2008 R2 kasutatavaid domeenifunktsioone. Windows Server 2008 domeenifunktsioonide puhul saab rakenduste juhtimiseks kasutada vastavaid kliendipõhiseid haldustööriistu (nt Remote Server Administration Tools for Windows 7). Grupipoliitikaobjektidega (Group Policy Objects – GPOs) tuleb defineerida erinevad reeglikomplektid ning seejärel need kasutajate ja kasutajarühmadega siduda. Näiteks saab sel viisil kindlaks määrata, et tsentraalse andmebaasi haldamiseks kasutatavat tarkvaratööriista tohib käivitada üksnes arendusosakond. Seevastu Microsofti Office Suite’i kasutuse võib vabaks anda kõikidele institutsiooni töötajatele ilma funktsioone piiramata. Vajalikud seadistused leiate grupipoliitikate haldamise redaktorprogrammist Group Policy Editor asukohas „Computer Configuration I Policies I Windows settings I Security settings I Application Control Policies I AppLocker ”.

Logimine
Kui kasutaja üritab käivitada mõnda AppLockeris defineeritud reeglitele mittevastavat rakendust, katkestab AppLocker selle programmi käivitamise ja dokumenteerib aset leidnud protsessi, tehes selleks süsteemilogisse sissekande. Manipuleerimiskatsete avastamiseks ja nende tagamaade selgitamiseks tuleb süsteemilogis kajastuvaid AppLockeri sissekandeid regulaarselt analüüsida. Ideaaljuhul tuleks süsteemilogid selleks mõnda tsentraalsesse logiserverisse kokku koondada ja automaatselt läbi analüüsida. Juhul, kui AppLocker võetakse kasutusele tootmissüsteemis, saab seda üleminekuperioodil käitada ka seirerežiimil. Seirerežiimi korral programmide käivitamist reeglite vastu eksimisel ei tõkestata, kuid logisse tehakse selle kohta siiski sissekanne. Logide analüüsimisega saab välja selgitada programmid, mille suhtes reeglid õigesti veel ei toimi.

Kontrollküsimused:
  • Kas klientides kasutatakse tarkvara volitamata installimise ja käivitamise tõkestamiseks AppLockerit?
  • Kas AppLockeri kasutamisel lähtutakse positiivse loetelu põhimõttest „kõik, mis ei ole otseselt lubatud, on keelatud”?
  • Kas AppLockeri kasutamiseks mõeldud reeglite defineerimisel eelistatakse rakenduste signatuuridel ja kindlaksmääratud väljastajatel põhinevaid reegleid?
  • Kas domeenipõhises võrgus rakendatakse AppLockeri reeglistike haldamiseks kasutajatel/kasutajarühmadel põhinevaid grupipoliitikaobjekte?
  • Kas süsteemilogide analüüsimisel pööratakse piisavalt tähelepanu ka sissekannetele, mis kajastavad AppLockeri reeglite rikkumise katseid?
  • Kas AppLockeri reeglite toimimist katsetatakse esmalt mõnes katsesüsteemis või AppLockeri käitamisega seirereþiimis ning alles seejärel võetakse need tootmissüsteemides kasutusele?